Skip Menu | will be shut down on March 1st, 2021.

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 4524
Status: resolved
Priority: 0/
Queue: POE

Owner: SUNGO [...]
Requestors: apocalypse [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Date: Sat, 29 Nov 2003 04:38:25 -0500
From: Apocalypse <apocalypse [...]>
To: bug-POE [...]
Subject: POE::Wheel::ReadLine not working perfectly
Download (untitled) / with headers
text/plain 1.7k
The program will simply wait until I pressed two keys, then somehow lock up doing select()'s all over the map... Using POE's TRACE_DEFAULT method, I was unable to pinpoint the error, other than seeing the select's scroll up the screen after pressing a second key... I've reduced the problem to this minimal program: # Standard stuff to catch errors use strict qw(subs vars refs); # Make sure we can't mess up use warnings FATAL => 'all'; # Enable warnings to catch errors # Turn on extensive debugging sub POE::Kernel::ASSERT_DEFAULT () { 1 } sub POE::Session::ASSERT_STATES () { 1 } sub POE::Kernel::TRACE_DEFAULT () { 1 } # Use POE! use POE; use POE::Wheel::ReadLine; # Create the session POE::Session->create( 'inline_states' => { '_start' => \&SetupWheel, '_stop' => sub {}, 'Got_Input' => \&GotInput, }, ); POE::Kernel->run; # Setup the wheel sub SetupWheel { my $heap = $_[ HEAP ]; # Create the wheel. $heap->{wheel} = POE::Wheel::ReadLine->new( InputEvent => 'Got_Input' ); # Trigger the wheel to read a line of input. $heap->{wheel}->get( 'Prompt: ' ); } # Input handler. If $input is defined, then it contains a line of # input. Otherwise $exception contains a word describing some kind # of user exception. Currently these are 'interrupt' and 'cancel'. sub GotInput { my ($heap, $input, $exception) = @_[HEAP, ARG0, ARG1]; if (defined $input) { $heap->{wheel}->put("\tGot: $input"); $heap->{wheel}->get('Prompt: '); # get another line } else { $heap->{wheel}->put("\tException: $exception"); } } -- Apocalypse Homepage: IRC: IRC: Apocal@EFnet CPAN ID: APOCAL
Download (untitled) / with headers
text/plain 1.7k
I posted a non-POE test case to the mailing list a couple weeks ago. I received a good amount of feedback: So far I have six (6) failure reports: Terminal settings are probably not at fault. The "stty -a" reports (in and out of canonical mode) are consistent with a BSD system where the test case works. An interesting coincidence comes up in the "perl -V" output. Four (4) systems are running identical versions of Perl, built on identical versions of Red Hat Linux: gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)' osvers=2.4.21-1.1931.2.382.entsmp perl5 (revision 5.0 version 8 subversion 0) An historical failure report in POE's RT queue include: gccversion='3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)' osvers=2.4.20-gentoo-r5 perl5 (revision 5.0 version 8 subversion 0) Another, without perl -V output This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Linux 2.4.20-18.9smp And a couple reports of working versions: gccversion='3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)' osvers=2.4.26-gentoo-r9 perl5 (revision 5 version 8 subversion 4) gccversion='3.3.3 (Debian 20040314)' osvers=2.4.25-ti1211 perl5 (revision 5.0 version 8 subversion 3) So, what could it be? - It's usually (but not always) attributed to Red Hat Linux. Gentoo also fails. - It may be localized to Linux kernels 2.4.20 - 2.4.21. - It may be localized to Perl 5.8.0, but I couldn't reproduce the problem on FreeBSD with 5.8.0 (with or without iThreads). - It may be localized to gcc 3.2.2 - 3.2.3. - Dear gods, I hope it's not a combination of factors! Things to try: - Try a different version of Perl on the affected systems. - Gather good data points to rule out kernel, perl, and gcc versions.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to