Re^3: sending data over TCP channel using POE::Component::Server::TCP

I took a look at the "Prototype mismatch" error you describe here (after upgrading to POE version 1.002), and although I'm not running activestate perl, the version of POE I have running on my Apple Mac, shows the following code:

.../POE/Kernel.pm
BEGIN {
   ...
    if ($^O eq 'MSWin32') {
        *{ __PACKAGE__ . '::RUNNING_IN_HELL' } = sub { 1 };
    } else {
        *{ __PACKAGE__ . '::RUNNING_IN_HELL' } = sub { 0 };
    }
   ...
}

.../POE/Resource/FileHandles.pm:
### Some portability things.

# Provide dummy constants so things at least compile.  These constants
# aren't used if we're RUNNING_IN_HELL, but Perl needs to see them.

BEGIN {
  if (RUNNING_IN_HELL) {
    eval '*F_GETFL = sub { 0 };';
    eval '*F_SETFL = sub { 0 };';
  }
}
[download]

I think we'll need to take a peek at your Kernel.pm and FileHandles.pm to see what's going on here. Anybody else have any thoughts on this? In any case, I don't think its part of your original problem (well, not yet anyways).

One other interesting thing is that this same error shows up in the Activestate build here.

-Craig

Comment on Re^3: sending data over TCP channel using POE::Component::Server::TCP Download Code

Replies are listed 'Best First'.
Re^4: sending data over TCP channel using POE::Component::Server::TCP by cta (Acolyte) on Jul 31, 2008 at 17:57 UTC
What I can find in these 2 files is not the same as yours. Here is the code: `../POE/kernel.pm ... { no strict 'refs'; if ($^O eq 'MSWin32') { { __PACKAGE__ . '::RUNNING_IN_HELL' } = sub { 1 }; } else { { __PACKAGE__ . '::RUNNING_IN_HELL' } = sub { 0 }; } ... .../POE/Resource/FileHandles.pm BEGIN { eval 'F_GETFL'; if ($@) { F_GETFL = sub () { 0 }; F_SETFL = sub () { 0 }; }` [download] There's eval 'F_GETFL' come up. This certainly means something but I don't know what it is. I use windows platform and my version of perl is 5.8.	[reply] [d/l]
Re^5: sending data over TCP channel using POE::Component::Server::TCP by rcaputo (Chaplain) on Aug 08, 2008 at 20:05 UTC
The BEGIN block intends to define F_GETFL and F_SETFL as constants if there's an error while evaluating F_GETFL. These constants are used elsewhere in the module, and it's more efficient to make sure they're defined and work rather than to make redundant checks over the lifetime of the program. Various versions of Perl for Windows use different prototypes for the F_GETFL and F_SETFL constants, despite the empty prototype being standard for Perl constants. POE tracks the latest build rather than try to do the right thing for every version out there. If someone wants to step up and do the necessary diligence, we'll be happy to accept a patch. Meanwhile, these warnings are ugly but otherwise harmless. `-- Rocco Caputo - http://poe.perl.org/`	[reply]