RE: Happy Birthday, POE!
I will second that. if you have a paypal account, would you put it up on the site? -Original Message- From: Peter Chen [mailto:[EMAIL PROTECTED]] Sent: Friday, August 16, 2002 12:54 PM To: Rocco Caputo Cc: [EMAIL PROTECTED] Subject: Re: Happy Birthday, POE! On Fri, 2002-08-16 at 15:42, Rocco Caputo wrote: August 15, 2002 marked the fourth anniversary of POE's first public release. As lead designer and developer of the project, I would like to thank the hundreds of people who have helped make POE as great as it is today. Unfortunately, I cannot thank you individually. Thank you, everybody! -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net If you have a wish list on Amazon or some site of the sort, I will be happy to send you/POE a birthday gift. POE has been good to me. :-) Pete
RE: ANNOUNCE: POE 0.23 is released
RPM now available at the usual place: http://www.arix.com/ftp/pub/rpmz/perl/POE/perl-POE-0.23-1.i386.rpm - e -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 12, 2002 4:26 PM To: [EMAIL PROTECTED] Subject: ANNOUNCE: POE 0.23 is released POE 0.23 has been released to the CPAN and the web. This is mainly a bugfix release with a couple of useful features thrown in. Most of POE's improvements would not have happened without feedback and discussion on this list. Thank you. Change highlights since 0.22: - Added IPv6 support. - Added Unicode support. - Improved Cygwin support. - Improved Event, Gtk, and Tk bridges. - Improved child process management. - Improved TCP client and server components. - Improved documentation. - Improved sample programs (see http://poe.perl.org/?POE_Cookbook). Detailed changes are available on the web. - http://poe.perl.org/?POE_CHANGES The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. - http://poe.perl.org/?Where_to_Get_POE Thanks again to everyone who helped with this release. Keep that feedback coming. :) -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
RE: :Component::Client::FTP problem
Bart,
the session you are creating needs an alias set to try since you're
telling the ftp client to use try to send its events...
you can do it like this:
sub start {
$_[KERNEL]-alias_set(try);
print *** test\n;
}
dngnand was going to add an arg to the session create function so you could
name it at creation time... but I don't know if that's released yet.
- e
-Original Message-
From: Bart [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 17, 2002 3:04 AM
To: [EMAIL PROTECTED]
Subject: POE::Component::Client::FTP problem
Hi
I'm trying to run Poco::Client::FTP in a self-made module file, but somehow,
it's going wrong.
I execute the function try::try($kernel, $1, $who); somewhere in the main
..pl file. The try function searches for $adname ($1) in the database, and if
it can find it, it logs into the ftp with the host/ip user/pass for that
ftp. Everything is going fine, POE connects to the server, executes the
start function as it should (*** test gets printed) and logs in. Then, it
should execute the inline authenticated() function, but it doesn't. I have
absolutely no idea why this is. The other 2 functions won't get executed
either, when they should.
Does anyone have an idea of what's going wrong ?
Thanks
Bart
--
use strict;
use warnings;
sub POE::Component::Client::FTP::DEBUG () { 1 };
use POE qw (Session Component::Client::FTP);
package try;
return 1;
sub login_error {
print *** no login\n;
}
sub authenticated {
print *** yes\n;
}
sub connect_error {
print *** no connection\n;
}
sub start {
print *** test\n;
}
sub try {
my ($kernel, $adname, $who) = @_;
my $number = -1;
my $counter = 0;
my $ftp = main::getAdByName($adname);
while ($number 0) {
if (!$main::leeches[$counter]) {
$number = $counter;
}
$counter ++;
}
POE::Component::Client::FTP-spawn(
Alias = try,
Username = $main::database[$ftp][4],
Password = $main::database[$ftp][5],
RemoteAddr = $main::database[$ftp][2],
RemotePort = $main::database[$ftp][3],
Timeout = 5,
Events = [qw (authenticated login_error connect_error
cmd_connected) ]
);
POE::Session-create(
inline_states = {
authenticated = sub { print test; }, #DOES NOT
GET EXECUTED
_start = \start, # GETS EXECUTED
login_error = \login_error, #DOES NOT GET EXECUTED
cmd_connected = sub { print CONNECTED
\n; }, #DOES NOT GET EXECUTED
connect_error = \connect_error, #DOES NOT GET
EXECUTED
}
);
}
RE: :Component::Client::FTP problem
=~
/look|browse/i) {
$info{look}[0] = $user;
$info{look}[1] = $pass;
}
elsif (!$info{download}[0]) {
$info{download}[0] = $user;
$info{download}[1] = $pass;
}
}
elsif (/^(ip:[ ]?)?(.+\..+\..+[\..+]*)$/i
!$info{address}) {
$info{address} = $2;
}
elsif (/^req(uest)?(ing)?(s)?(:)?\s*(.*)/i) {
$info{request} = $5;
}
elsif (!$info{other}) {
$info{other} = $_;
}
$counter++;
}
return %info;
}
sub getAdByName {
my ($name) = @_;
for (my $x = 0; $x scalar(@database); $x++) {
if ($database[$x][0] eq $name) {
return $x;
}
}
return -1;
}
sub getAdByOwner {
my ($owner) = @_;
for (my $x = 0; $x $#database; $x++) {
if ($database[$x][1] eq $owner) {
return $x;
}
}
return -1;
}
sub insertDB {
my (%info) = @_;
#
0. Name
1. Owner
my @ftpsite = ( $info{name},$info{owner},
# 2. IP 3. Port
$info{address}, $info{port},
#
4. Download User5. Download Pass
$info{download}[0],
$info{download}[1], # 7. Upload User 7.
Upload Pass
$info{upload}[0], $info{upload}[1],
#
8. Look User9. Look Pass
$info{look}[0], $info{look}[1], #
10. Requests11. Other
$info{request}, $info{other},
#
12. Status 13. Last Check
NOCHK,0,
# 14. Last time ad seen 15. Last login
time, 0,
#
16. Login OK ? 17. Total FTP Size
0,0,
);
if (getAdByName($info{name}) == -1) {
push (@database, [@ftpsite]);
}
else {
my $ad = getAdByName($info{name});
foreach(12, 13, 15, 16, 17) {
$ftpsite[$_] = $database[$ad][$_];
}
$ftpsite[14] = time;
$database[$ad] = [@ftpsite];
}
writeDB();
}
Erick Calder wrote:
grr.. I keep hitting reply and I keep getting the messages bounced back
to
me.
you should post the code so we know what you're doing. I suggest you drop
by #poe on EFNET or feel free to contact me on AIM/YM: svekkis or ICQ
1005378
RE: PoCo::Child
FYI, the link on perl.arix.com seems to be broken: http://perl.arix.com/POE-Component-Child-1.7.tar.gz thx. I've fixed it. -Original Message- From: Peter Chen [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 7:11 AM To: Erick Calder Cc: [EMAIL PROTECTED] Subject: Re: PoCo::Child On Thu, 2002-09-19 at 00:49, Erick Calder wrote: Rocco thought it'd be useful to have a component made out of POE::Wheel::Run so as to eliminate having to create an interim session just to receive events from the wheel... so I've put one together under the name in the subject header. It should be available on CPAN or you can pick up a copy from: http://perl.arix.com hope you find it useful. That's great. I found it on CPAN http://search.cpan.org/author/ECALDER/POE-Component-Child-1.7/Child.pm FYI, the link on perl.arix.com seems to be broken: http://perl.arix.com/POE-Component-Child-1.7.tar.gz Pete
PoCo::Player::Mpg123
Matt Cashner (sungo) has graciously agreed to relinquish ownership of PoCo::MPG123 so I could re-implement it using PoCo::Child. First pass at it is done and available on CPAN. the RPM may be found at the usual place: ftp://arix.com/ekkis/POE/ I've renamed the component in the hopes of having other players under this category (requests for other wrappers gladly accepted) and the thing now sports a new oo interface, full docs and a comprehensive test suite. bugs/suggestions, etc. should come to me directly at [EMAIL PROTECTED] until I figure out how to use the new bug tracker (if I even have access to it) enjoy! - ekkis p.s. if you're going to use this module, do also pick up the latest copy of PoCo::Child (v 1.16)
RE: Pseudo Lexical State Parameters
Actually, you can save you 2 additional keystrokes: laughing! now ekkis truly happy. my vote for that approach! -Original Message- From: Garrett Goebel [mailto:garrett;scriptpro.com] Sent: Tuesday, November 12, 2002 10:53 AM To: 'Erick Calder'; [EMAIL PROTECTED] Subject: RE: Pseudo Lexical State Parameters Erick Calder wrote: I like the simplicity of this syntax. me too. I still prefer $kernel-yield() as it is simple, but certainly kernel()-yield would be better than $message-kernel-yield()? i.e. where better == shorter - me lazy and hate to read/type I have to :) Actually, you can save you 2 additional keystrokes: kernel-yield() -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
naming quandary
need a little input: I have a component that detects changes to directories and files that I originally called PoCo::Dir::Watch because it only detected directory changes... now I thought to call it PoCo::Detect::Filesystem... but then it occurred to me to rename PoCo::CD::Detect to PoCo::Detect::CD... trouble is I also have PoCo::CD::Rip... so now I don't know what makes sense. also, these names are getting rather long... would PoCo::Detect::Fs, or PoCo::Detect::Path be better? feedback guys?
RE: naming quandary
so should I have Detect::CD or CD::Detect? -Original Message- From: Dmitri Tikhonov [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 3:50 PM To: Erick Calder Cc: [EMAIL PROTECTED] Subject: Re: naming quandary On Mon, 16 Dec 2002, Erick Calder wrote: also, these names are getting rather long... would PoCo::Detect::Fs, or PoCo::Detect::Path be better? I think PoCo::Detect::Fs looks prettier. To make it prettier yet, use caps: PoCo::Detect::FS. - Dmitri.
RE: RFC: Persistent Object Client/Server Scheme
In my case, lack of response means I'm busy I'll second that motion. I do have an interest in this idea and will reread the original message before commenting but given that Philip mentions object persistence I should just hit that I'm working at a schema layer, perhaps similar to Java Entity Beans. someday I foresee a nice mixture of this with IKC to do replication stuff. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 12:06 AM To: Rocco Caputo; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: RFC: Persistent Object Client/Server Scheme On 11-Feb-2003 Rocco Caputo wrote: Would a server helper module like OOPersistServer be a candidate to be a genuine POE::Component::Server? The lack of response to this message seems to indicate no. :( In my case, lack of response means I'm busy. Object persistance is something I've wrestled with often. My latest stab was for JAAS (just another application server). I have some ideas about object persistance that I would like to share, but lack of tuits has held me back. -Philip
RE: ANNOUNCEMENT: POE 0.25 is released
for those who care, the RPM is now also available and may be found at the usual place. the binaries I distribute are built on a Redhat 7.0 i386 platform but I do also provide the source rpms so you can --rebuild on your platform. I've only compiled the POE rpm for now, if anyone needs any other modules packaged, just let me know, or download cpan2rpm (which may be found at http://perl.arix.com) and do it yourself. - erick -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 3:28 PM To: [EMAIL PROTECTED] Subject: ANNOUNCEMENT: POE 0.25 is released POE 0.25 is finally released. Thanks, everyone, for the work you've put into it. Special thanks go to our new committers and testers. Their help is invaluable. This release fixes several bugs reported in IRC and on this mailing list. ActivePerl 5.8.0 is supported, to the extent that it can be. Gentoo Linux's Perl should stop dumping core. TCP clients and servers have interesting enhancements. Much of this would not have happened without your feedback. Thank you. - http://poe.perl.org/?POE_CHANGES Even now the latest tarball should be hurtling towards your favorite CPAN mirror. It is also on the web, with an improved ActiveState PPD and tarball. - http://poe.perl.org/?Where_to_Get_POE Thanks again for making this release possible. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
RE: RFC: Persistent Object Client/Server Scheme
if what you develop is a perl RMI interface, POE programs could be written to interoperate in Java environments, allowing those of us who prefer it to code in perl rather than Java. I see that as big positive :) -Original Message- From: Phil Crow [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 6:11 AM To: [EMAIL PROTECTED] Subject: RE: RFC: Persistent Object Client/Server Scheme Since some discussion has started I think it is time for my true confession. Though I love Perl, I am really mostly a Java programmer. My intent with the project I mentioned is to provide schemes like Java has, but with a heavy Perl spin. With them I might some day convince my employer that Perl is ready for prime time. While I think Perl is ready, they don't see it, hence the need for more tools. In this case the scheme is RMI (Remote Method Invocation). In case you aren't familiar, I'll bore you with details. An rmiregistry daemon keeps track of all registered rmi services on one host by name. As service daemons start, they register. When a client asks the registry daemon for a service, the daemon connects the two. This allows the client to make calls on persistent objects in the remote registered service. The protocol is proprietary (but published) and travels over TCP sockets. So, my current scheme is RMI for Perl. The clients instantiate remote objects and use them without worrying about event call backs. Simply say $result = $remote_objet-method(@args). The servers use POE, but without having to think about it. This means (among other things) that the exposed objects don't explicitly know they are exposed. This creates modularity since the same code can be used locally or remotely. The primary purpose for an RMI like scheme is to allow separation of application components across servers (what patterns people call layering). That's what the current project allows. It does so with simplistic API's. My goal is to eventually provide the kinds of functionality that has made the Java platform successful without introducing the unPerlish complications that dominate the Java frameworks. In this case that means no rmic (rmi compiler), no interfaces or stubs, etc. It also means a clean Perlish set of support modules. Currently there is a server module, a client module, and a registry daemon which just uses the server module. Thanks for all comments so far. I'm interested in hearing more and in working with anyone. Now back to my Java programming job :(, Phil Crow __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
RE: Feedback on POE::Wheel::Run changes
some simple additions to the POE::Wheel::Run module
I'm interested in what other changes beyond the directory argument you have
in mind. I've implemented the chdir feature in PoCo::Child which is a layer
on top of Wheel::Run and would be interested in whatever improvements you or
anyone might suggest.
- e
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 4:00 PM
To: [EMAIL PROTECTED]
Subject: Feedback on POE::Wheel::Run changes
I understand that there is a long-term goal to supercede POE::Wheel::Run
with a component module with the tentative title of POE::Component::Process
(http://poe.perl.org/?V1.0-TODOS) and there has been a discussion on the
mailing list previously about how the POE::Wheel::Run module could be
improved. In spite of this, or perhaps because of it, I have made some
simple additions to the POE::Wheel::Run module which I have needed for some
in-house projects which I would like to get some feedback on.
The first of these changes is a simple addition to include a Directory
parameter to specific the location from within which the program specified
is executed. The diff for these changes against the CVS version of
POE::Wheel::Run (version 1.44) is as follows:
7c7
use vars qw($VERSION);
---
use vars qw($CWD $VERSION);
64a65,74
BEGIN {
use Cwd;
sub FETCH { cwd }
sub STORE { defined $_[1] and ( chdir $_[1] or die $! ) }
sub TIESCALAR { bless \$_, shift }
tie $CWD, __PACKAGE__;
};
111a122,123
my $directory = delete $params{Directory};
357a370,373
# Change the current working directory and maintain within this scope
local $CWD = $CWD;
$CWD = $directory if defined $directory;
Note that this creates a locally scoped directory change for execution and
should not affect execution of other components and wheels.
I also have changes for username and group specification with name rather
than UID/GID, bute these changes are very minor and depends upon the
getpwnam and getgrnam functions which may affect portability of the change.
Comments and feedback welcomed.
Regards,
Rob
Rob Casey
Implementation Analyst
Essential and Direct Mail Development
Hermes Precisa Australia (Victoria)
Phone : (03) 9217-5501
Email : [EMAIL PROTECTED]
**
IMPORTANT
The contents of this e-mail and its attachments are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed. If you received this e-mail in error, please notify
the HPA Postmaster, [EMAIL PROTECTED], then delete
the e-mail.
This footnote also confirms that this e-mail message has been swept for
the presence of computer viruses by MimeSweeper. Before opening or
using any attachments, check them for viruses and defects.
Our liability is limited to resupplying any affected attachments.
HPA collects personal information to provide and market our services.
For more information about use, disclosure and access see our Privacy
Policy at www.hpa.com.au
**
RE: Feedback on POE::Wheel::Run changes
I think it's an interesting feature, but I don't use Wheel::Run enough to know how generally useful it is. I'm looking for more discussion on it before making any decisions. I think it's fairly useful. I've implemented it in PoCo::Child but was hoping to hear the other ideas Robert mentioned before releasing. -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:51 PM To: [EMAIL PROTECTED] Subject: Re: Feedback on POE::Wheel::Run changes On Thu, Mar 06, 2003 at 11:00:26AM +1100, [EMAIL PROTECTED] wrote: I understand that there is a long-term goal to supercede POE::Wheel::Run with a component module with the tentative title of POE::Component::Process (http://poe.perl.org/?V1.0-TODOS) and there has been a discussion on the mailing list previously about how the POE::Wheel::Run module could be improved. In spite of this, or perhaps because of it, I have made some simple additions to the POE::Wheel::Run module which I have needed for some in-house projects which I would like to get some feedback on. The first of these changes is a simple addition to include a Directory parameter to specific the location from within which the program specified is executed. The diff for these changes against the CVS version of POE::Wheel::Run (version 1.44) is as follows: [patch] Note that this creates a locally scoped directory change for execution and should not affect execution of other components and wheels. I think it's an interesting feature, but I don't use Wheel::Run enough to know how generally useful it is. I'm looking for more discussion on it before making any decisions. I also have changes for username and group specification with name rather than UID/GID, bute these changes are very minor and depends upon the getpwnam and getgrnam functions which may affect portability of the change. Comments and feedback welcomed. POE::Wheel::Run is already very UNportable. We can probably work around missing get(gr|pw)nam functions, or at least throw unsupported errors wherever they fail. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
RE: definitely a POE::Wheel::ReadLine understanding problem....
Bruno,
just as a side comment, the
inline_states = { method = \method }
can also be expressed as:
package_states = [ method ]
which allows for something like:
package_states = [ qw/_start _stop got_input/ ]
-Original Message-
From: Bruno Boettcher [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2003 11:01 AM
To: [EMAIL PROTECTED]
Subject: definitely a POE::Wheel::ReadLine understanding problem
ok,
sorry bothering so much and beeing too dumb as it seems
just to test (and maybe that would be a better code snippet (once
commented..) for the man page script is at the bottom of this
mail...
set up the smallest possible sample program that uses readline...
but here too, as soon as i run it, it blocks on the first char i type...
so seems i missed something somewhere
this example is surely easier to parse than the other stuff...
- cut here readLine.pl --
#!/usr/bin/perl
use warnings;
use strict;
use POE;
use POE::Filter::Reference;
use POE::Wheel::ReadLine;
POE::Session-create(
#Alias = leveShell,
inline_states =
{ _start = \_start,
_stop = \_stop,
got_input = \got_input_handler,
},
);
$poe_kernel-run();
# 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 got_input_handler {
my ($heap, $input, $exception) = @_[HEAP, ARG0, ARG1];
if (defined $input) {
$heap-{wheel}-addhistory($input);
$heap-{wheel}-put(\tGot: $input);
$heap-{wheel}-get('Prompt: '); # get another line
}
else {
$heap-{wheel}-put(\tException: $exception);
}
}
##
=pod
=item start of the poe session
=cut
##
sub _start
{
my ($this, $kernel, $heap, $dsn, $queries,$session) = @_[OBJECT, KERNEL,
HEAP, ARG0, ARG1,SESSION];
$kernel-alias_set(leveShell);
# 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: ' );
}#sub _start
##
=pod
=item stop of the poe session
=cut
##
sub _stop
{
my ($this, $kernel, $heap) = @_[OBJECT, KERNEL, HEAP];
# Clear the terminal.
$heap-{wheel}-clear();
}#sub _stop
- cut here --
--
ciao bboett
==
[EMAIL PROTECTED]
http://inforezo.u-strasbg.fr/~bboett
===
RE: Grandwheels or wheel-wheels question
Markus, also check out POE::Component::Child which makes setup easier. - e -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 6:23 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Grandwheels or wheel-wheels question Markus, Take a look at POE::Wheel::Run. Run can be initiated as spawning a separate program or subroutine. Use a ReadWrite wheel to connect the subprocess back to the Run Wheel. In the subroutine or separate script, run a kernel inside of that to handle the IO, multiwhatevers, etc. Dougie! In a message dated 8/19/03 5:10:39 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Hi, I have a program where I need to execute some longish tasks in parallel. So far I have understood that POE is some first class choice, and that the way to go is to have some POE::Filter::Reference wheels spawned off. However, these wheels have to deal with collecting the longish data itself. Recently, I learned that this may be some n GBytes each, so backquotes or even file redirection could turn out improper. I would like to employ POE also - does anybody have experience with wheel processes (children) creating one or more wheels again? Of course I could fold the output handling into one hierarchy, but this would make a line oriented processing problematic, and a load oriented job spawning quite hard. Any help is appreciated. Best regards, Markus -- Markus Jansen Senior IS/IT Support Engineer, EED/IT Ericsson Eurolab Deutschland GmbH Email : [EMAIL PROTECTED] Ericsson Allee 1 Phone : +49 2407 575 5157 52134 Herzogenrath Fax : +49 2407 575 7289 GermanyMobile: +49 172 274 2003
RE: Proposal: Registered PIDs
as long as the child's process id remains available in the current place you
won't break existing code like PoCo::Child so no objections here :)
-Original Message-
From: Rocco Caputo [mailto:[EMAIL PROTECTED]
Sent: Friday, February 13, 2004 8:32 PM
To: [EMAIL PROTECTED]
Subject: Proposal: Registered PIDs
Proposal: Registered PIDs.
Currently SIGCHLD is broadcast to every session that registers a CHLD
signal handler. Quite often, this means every session with child
processes receives signals for every other one. They all must track
their children and filter the incoming signals against theirs.
A conversation in IRC reminded me about this issue. I suggested the
customary pattern for dealing with broadcast SIGCHLD.
One of the parameters is the child PID. You can return unless
exists $heap-{mine}{$pid}
Philip Gwyn and I had just covered the heavyhanded _signal event,
which is in the throes of deprecation. It further occurred to me that
dispatching SIGCHLD to every session with a handler is often useless,
since most of them don't care one whit about any other session's
process IDs.
Maybe an optimization would be a Kernel registry mapping child PIDs
to sessions. After you fork, you can call $kernel-forked($pid) to
focus that PIDs SIGCHLD on the current session. POE::Wheel::Run
could do it internally.
Unregistered PIDs would still be broadcast around. And to be fair,
I guess multiple sessions could register interest in a child PID.
For whatever that's worth.
This would require a new POE::Kernel method. I wish it could be
incorporated into something like sig(CHLD = event), but re-
registering the SIGCHLD handler shouldn't be necessary for every new
process.
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Test Reforms
Randal L. Schwartz Don't remove all examples from the distro. At 30K feet, they were very helpful for me while I was trying to write code, but couldn't get to the website. Or maybe make a simple one-stop-download link on the website. they can at least be packaged separately. in fact, a -doc package could include all the sample code and recipes from the web
Re: Test Reforms
At some point, the cookbook and possibly the tutorials should be bundled into CPAN distributions. Perhaps POE::Tutorials or POE::Examples I'm almost tempted to suggest that should be left to each distro... in RH one often finds packages like -doc containing all that stuff.
Re: Test Reforms
At some point, the cookbook and possibly the tutorials should be bundled into CPAN distributions. Perhaps POE::Tutorials or POE::Examples I'm almost tempted to suggest that should be left to each distro... in RH one often finds packages like -doc containing all that stuff.
RE: POE::Sweeten::Args
pulling it into the core with a name like POE::Arguments side note: my vote would go for POE::Args. one thing I've always liked about perl and detested about Java is the length of namespaces. I for one hate to type so shorter names are better! - e p.s. don't I remember that there had been some discussion about creating a PoCo in place of POE::Component? -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 8:27 PM To: [EMAIL PROTECTED] Cc: sungo Subject: Re: POE::Sweeten::Args On Mon, Feb 23, 2004 at 04:54:02PM -0500, sungo wrote: so the question is: newbies seem to not understand $_[KERNEL] and friends. what to do about it? my answer is this: POE::Sweeten::Args, written by Casey West, specifically to alleviate this problem. Let's document it in the core (Don't like this argument style? POE::Sweeten::Args offers two other varieties.). If it really becomes must, lets talk to casey about pulling it into the core with a name like POE::Arguments. basically, i think this is a solved problem and we just need to add more docs about the possibilities. the key here is to add more possibilities not remove old ones. I agree that the documentation should point to POE::Sugar::Args, POE::Session::MessageBased, and whatever @_ alternatives are out there. If it goes into the core, though, we're stuck with it forever. We should make sure it's a good and lasting solution. Another idea to throw into the mix: While documenting different calling conventions, it might be good to describe how to subclass or replace POE::Session. POE::Session's generic interface would get documented, and the interaction between POE::Kernel and POE::Session outlined. The perldoc for POE::Loop has the sort of documentation I'm thinking of here. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
RE: small wishes to poe::wheel::run can't figure out.
you might also want to look at PoCo::Child for inspiration
-Original Message-
From: Andy Levine [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 09, 2004 3:23 AM
To: [EMAIL PROTECTED]
Subject: RE: small wishes to poe::wheel::run can't figure out.
Michael,
I would like to get an error_level for each program i run in parallel...
Pass the param ErrorEvent when you instantiate the POE::Wheel::Run to trap
errors.
And it would also be nice to get a value back so i can track which program
that return a
given answer...
I get program exit codes by trapping SIGCHLD to tell when my child process
die. In your 'start' handler, add something like this:
$kernel-sig(CHLD = '__sig_child');
Then handle the __sig_child event. The program exit code is one of the
parms, as follows:
sub onSIGCHLD {
my($self, $heap, $signalname, $kidPID, $kidRC) =
@_[ OBJECT, HEAP, ARG0..ARG2 ];
Thanks a lot in advance...
Michael , Denmark.
- snip ---
#!/usr/bin/perl
use warnings;
use strict;
use POE;
use POE::Wheel::Run;
my $time1=time();
# Start a multitasking session to manage several child processes. Map
# each event to a function which will handle it. Run POE::Kernel,
# which manages the session's activity. run() will return when the
# session is done, and so we exit.
POE::Session-new
( _start = \start_processes,
process_stdout = \read_stdout,
process_stderr = \read_stderr,
process_closed = \cleanup_proc_wheel,
);
POE::Kernel-run();
my $time2=time();
my $usedtime=$time2-$time1;
print$time2 - $time1 - $usedtime\n;
exit 0;
# Start a number of child processes. Record their abstractions
# (wheels) in the session's local storage (its heap). All the
# process events include the IDs of the wheels that have activity.
# We'll use that later to clean up after finished processes.
sub start_processes {
my $session_storage = $_[HEAP];
my $nr;
my @servers;
my $t;
my $command=uptime;
$nr = @servers = qw(xxx.xxx.xxx.xxx);
for (1..1) {
for ($t=0;$t$nr;$t++) {
my $program=ssh $servers[$t] $command;
my $proc_wheel = POE::Wheel::Run-new
( Program = $program,
StdoutEvent = process_stdout,
StderrEvent = process_stderr,
CloseEvent = process_closed,
);
$session_storage-{$proc_wheel-ID} = $proc_wheel;
}
}
}
# Process stdout and stderr from the child process.
sub read_stdout {
my ($stdout, $proc_wheel_id) = @_[ARG0, ARG1];
print Wheel $proc_wheel_id stdout: $stdout\n;
}
sub read_stderr {
my ($stderr, $proc_wheel_id) = @_[ARG0, ARG1];
print Wheel $proc_wheel_id stderr: $stderr\n;
}
# Clean up after a process when it's done.
sub cleanup_proc_wheel {
my ($session_storage, $proc_wheel_id) = @_[HEAP, ARG0];
delete $session_storage-{$proc_wheel_id};
}
RE: New PoCo Guidelines
I always prefer more flexibility so one thing I'd like to see is call
signatures that can take a hash or list of hashrefs so I can write:
$y = { three = 'tre' };
$x-(one = 'ett', two = 'tva', $y, etc = 'whatever');
-Original Message-
From: sungo [mailto:[EMAIL PROTECTED]
Sent: Monday, July 26, 2004 6:48 AM
To: David Davis
Cc: [EMAIL PROTECTED]
Subject: Re: New PoCo Guidelines
On (07/25 16:56), David Davis wrote:
-call conventions (use hashrefs instead of arrays?)
are you talking about the insides of a component object? if so, don't
meddle there. any guidelines for components really need to stick to
interface alone. let the components do what is necessary to get their
jobs done.
--
sungo
http://eekeek.org
RE: New PoCo Guidelines
The doco for both is thin. :( I thought I did a pretty decent job at doc for ::Child... if you have any suggestions I'd be happy to consider them. PoCo::Child has the strangely named parm Alias, which doesn't set the alias of the component but the alias of the session postbacks are posted to. why would you want to set the alias of the component's internal session when you are never going to address it? and what's strange about naming it alias? what would you name it? POE::Component::Base I love it. and now that we're talking about this, could we shorten the base name? I have components like POE::Component::Player::Mp3 - which is entirely too long! Could we at least do POE::Co? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 9:44 AM To: sungo Cc: [EMAIL PROTECTED] Subject: Re: New PoCo Guidelines On 26-Jul-2004 sungo wrote: On (07/25 16:56), David Davis wrote: -call conventions (use hashrefs instead of arrays?) are you talking about the insides of a component object? if so, don't meddle there. any guidelines for components really need to stick to interface alone. let the components do what is necessary to get their jobs done. I was the one who proposed talking about PoCo guidelines. I came to this conclusion after playing with PoCo::Server::HTTPD and PoCo::Child. The doco for both is thin. PoCo::HTTPD doesn't allow post-backs. PoCo::Child has the strangely named parm Alias, which doesn't set the alias of the component but the alias of the session postbacks are posted to. Things like this made me that there had to be a better way. No, I don't think the guidelines should dictate internal component implementation. With one exception : if you are doing OO and want people to overload your component, then following a standard object model would be nice. Actually, 2 exceptions, if/when we agree on a standard, it would be nice to implement POE::Component::Base which would help in conforming to the standard. In that case, internals would be dictated by that component. Mind you, there could also be POE::Component::Helper which would export subroutines that did some of the dirty work to help non-OO implementations conform. -Philip
RE: New PoCo Guidelines
Maybe I skimmed to fast through the doco, but I had to read the code to
find the arguments that were pasted to the postbacks.
unless you have an ancient version of the ::Child you should have seen this:
Event handlers are passed two arguments: ARG0 which is a reference to
the component instance being used (i.e. $self), and ARG1, a hash
refer-
ence containing the wheel id being used (as wheel) + values specific
to
the event. Callbacks are passed the same arguments but as @_[0,1]
instead.
or maybe that is not sufficient. I will think about rewriting it in greater
depth.
rather then having to hold on to the object reference
huh? what's wrong with keeping the object? why would you prefer to post
messages to an internal session when there is a perfectly good abstraction
behind $o-run()?
I can't currently
I suppose I can always just add a method to return the name of the internal
session so you can send it messages directly... but I don't get it.
In my mind you shouldn't even have an argument like this,
if you don't tell ::Child what session to throw its events at, how are you
supposed to get callbacks?
it should be set with the postback. Or it should use $_[SENDER].
*ekkis feels clueless
POE::Component::Child-spawn
what are you looking at?? ::Child doesn't offer spawn()!
[EMAIL PROTECTED] is a proposed way of saying event
command_error in session monitor
you can currently ask that events be sent to the session indicated by
alias
Note these are much more complex use scenarios then PoCo::Child
currently allows.
perhaps you'll need to elaborate because from the posted code I don't see
anything you couldn't do with ::Child
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 10:56 AM
To: Erick Calder
Cc: [EMAIL PROTECTED]
Subject: RE: New PoCo Guidelines
On 29-Jul-2004 Erick Calder wrote:
The doco for both is thin.
:( I thought I did a pretty decent job at doc for ::Child... if you have
any suggestions I'd be happy to consider them.
Maybe I skimmed to fast through the doco, but I had to read the code to
find the arguments that were pasted to the postbacks.
PoCo::Child has the strangely named parm Alias, which doesn't
set the alias of the component but the alias of the session
postbacks are posted to.
why would you want to set the alias of the component's internal session
when you are never going to address it?
You see, I do expect to address it. Looking at your code, I see that it
is designed to handle executing concurrent commands. So I expect to be
able to do
$poe_kernel-post('Child' = 'run', 'lpr -P lp1');
or equiv from my code, rather then having to hold on to the object
reference. I can't currently, unless I write a wrapper session around the
PoCo::Child object and session.
and what's strange about naming it alias? what would you name it?
Most other components use that param to name their alias. At least one
other person was supprised at PoCo::Child's behaviour in this regard.
what would you name it?
This is part of what I want the PoCo Guidelines to describe. In my mind
you shouldn't even have an argument like this, it should be set with the
postback. Or it should use $_[SENDER].
IMHO, the interface to PoCo::Child should be multiplexed. That is :
POE::Component::Child-spawn(Alias='runner',
StderrEvent='[EMAIL PROTECTED]',
ErrorEvent='[EMAIL PROTECTED]');
## [EMAIL PROTECTED] is a proposed way of saying event
## command_error in session monitor
## Later, in session Zip
$poe_kernel-post(runner='run', Command='lpr -P lp1',
StderrEvent='lpr_error');
## lpr_error in session Zip would be called if there was text on
## stderr
## and elsewhere, in another session even
$poe_kernel-post(runner='run', Command= 'pgpv',
StdoutEvent=sub { }, # ignore
StdinEvent=sub { return shift @text },
StderrEvent='[EMAIL PROTECTED]');
Note these are much more complex use scenarios then PoCo::Child currently
allows. The simplified form could maybe be done with
$run=POE::Component::Child-spawn(Postback=$_[SESSION]-ID);
$run-run('ls -lr');
and now the current session will receive all the events with the default
names.
POE::Component::Base
I love it. and now that we're talking about this, could we shorten the
base name? I have components like POE::Component::Player::Mp3 - which
is entirely too long! Could we at least do POE::Co?
Agreed! However, I'd propose that only components that meet some
guildlines would be allowed in that name space.
-Philip
RE: New PoCo Guidelines
I actually do like that things live inside POE::... I just think Component is too long... so maybe POE::Co:: could be ok... or for that matter even we could just dump the Co altogether e.g. POE::Player::Mp3, POE::Server::TCP -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Thursday, August 05, 2004 8:36 PM To: [EMAIL PROTECTED] Subject: Re: New PoCo Guidelines On Thu, Aug 05, 2004 at 06:41:35PM +0100, Matthew Trout wrote: On Thu, Aug 05, 2004 at 01:19:59PM -0400, Rocco Caputo wrote: There's no requirement that they exist in POE::. For example, Term::Visual lives somewhere entirely different. One drawback, however, is you can't then use use POE qw(Component::Server::TCP Component::Client::DNS); The savings from a shorter base namespace may make that moot. Is there any reason we couldn't create a 'PoCo' base class or similar that does the same job? The shortcut was a workaround for long class names. Shortening the class names may eliminate the need for a workaround. The reasons for or against a loader class are fuzzy judgment calls, not good vs. evil issues. One negative aspect I can think of offhand is that it makes class loading more complex. You should decide whether the convenience outweighs the complexity. Consider that the margin is ten characters narrower using PoCo (or even POEx, to follow in DBIx's footsteps). So, is it worth it? Does anyone have other reasons for or against it? -- Rocco Caputo - http://poe.perl.org/
RE: New PoCo Guidelines
I propose a common nomenclature. I never like reverse Hungarian notation and variants because invariably you end up with names that don't describe the datatype well, or you end up with long names, and I hate long names. I think names should be functional: state describes the thing without describing the datatype, as does event, regardless of the implementation. on_stupid = Undecided::Cb::Chain-new( Undecided::Cb-new(\callback), Undecided::Ob-new($object, method), Undecided::Cl-new($class, method), Undecided::Ev-new(event), # probably only valid as the last item ), not that the above couldn't equally be expressed as: on_stupid = [ event, \callback, [$object = method], [$class, method] ]; which I find more concise and perlish. yes, the Undecided thing helps hide behind objects but it just seems so unwieldy. - ekkis http://www.arix.com/ec
RE: New PoCo Guidelines
Perhaps I'm too sentimental but I prefer names that are pronounceable. POEx is pretty pronounceable: POE-ex POEx I like the brevity of this. my issue however, is that the implication is that modules in that namespace are extensions... and I don't perceive components as extensions... an extension is more or less an afterthough: uh... we didn't think of this so let's extend the framework, whereas a component is an integral part of a system, which I believe is more closely aligned with the function of POE components. I also don't like PoCo, even though it's easy to say and writes nicely, because I think everything POE related should be under that namespace. perhaps a better suggestion would be to create special namespaces for internal stuff e.g. POE::Kernel and let everything else just hang off of POE e.g. POE::Player::Mp3 POE::Client::IRC POE::Server::HTTP but POE::Kernel::Child (or some such thing) - ekkis http://www.arix.com/ec
RE: New PoCo Guidelines
It allows people to publish modules autonomously. using POE:: shouldn't present any problem with this It avoids name collision between core POE and third-party components. avoided via the use of POE::Core It implies a border between POE and all these things that must be installed separately. see above Implies that all the modules have something in common. they have POE in common... beyond that POE:: simply provides a space to create namespaces e.g. POE::Server for servers POE::Client for clients, etc. -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 8:10 AM To: [EMAIL PROTECTED] Subject: Re: New PoCo Guidelines On Wed, Aug 11, 2004 at 10:17:59PM -0700, Erick Calder wrote: Perhaps I'm too sentimental but I prefer names that are pronounceable. POEx is pretty pronounceable: POE-ex POEx I like the brevity of this. my issue however, is that the implication is that modules in that namespace are extensions... and I don't perceive components as extensions... an extension is more or less an afterthough: uh... we didn't think of this so let's extend the framework, whereas a component is an integral part of a system, which I believe is more closely aligned with the function of POE components. I also don't like PoCo, even though it's easy to say and writes nicely, because I think everything POE related should be under that namespace. perhaps a better suggestion would be to create special namespaces for internal stuff e.g. POE::Kernel and let everything else just hang off of POE e.g. POE::Player::Mp3 POE::Client::IRC POE::Server::HTTP but POE::Kernel::Child (or some such thing) - ekkis http://www.arix.com/ec POE:: could be used, as long as there's a standard namespace layout for people to follow. The theory behind a second namepace: - It allows people to publish modules autonomously. - It avoids name collision between core POE and third-party components. - It implies a border between POE and all these things that must be installed separately. - Implies that all the modules have something in common. A standard namespace layout would solve the first two issues. Publishing and maintaining it would solve the third. -- Rocco Caputo - http://poe.perl.org/
RE: New PoCo Guidelines
poe://session@/event
I like poe://session/event but agree that [EMAIL PROTECTED] makes more sense
than [EMAIL PROTECTED] however I don't think session@ is necessary since
poe:://kernel/event would make no sense anyway.
-Original Message-
From: Rocco Caputo [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 7:51 AM
To: [EMAIL PROTECTED]
Subject: Re: New PoCo Guidelines
On Tue, Aug 10, 2004 at 07:17:28AM -0700, David Davis wrote:
I like POEx also.
Philip:
If you wanted to get a postback for a certain session/event you could do:
ZipEvent =
$kernel-ID_id_to_session($session_id)-postback('zip_event',@event_args),
pretty ugly and would cause an error for a session that didn't exist
I would like to suggest we use
poe://session/event
with an optional kernel param:
poe://[EMAIL PROTECTED]/event
I don't like misusing URI fields like that. If kernel is a process
address, it would be more appropriate to say
poe://session@/event
poe://[EMAIL PROTECTED]/event
Safari at least translates
http:/// into http://localhost/
http://moo@/ into http://[EMAIL PROTECTED]/
so there's precedent for this actually working.
--
Rocco Caputo - http://poe.perl.org/
RE: New PoCo Guidelines
That seems possible as long as there's some way to map sessions to network nodes well... sessions are much like ports with the exception that you could have multiple kernels per host so two sessions with the same id could exist in the host. but that could be remedied at the POE::Kernel level. if everytime a session is created, it is guaranteed to be unique within that host (regardless of kernel) then we can safely say: http://[EMAIL PROTECTED]/event or http://session/event in the case of localhost, since http://host/event would not be very meaningful. we could of course also do: http://host/session?event -Original Message- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 4:18 AM To: [EMAIL PROTECTED] Subject: Re: New PoCo Guidelines On Wed, Aug 18, 2004 at 11:09:33PM -0700, Erick Calder wrote: poe://session@/event I like poe://session/event but agree that [EMAIL PROTECTED] makes more sense than [EMAIL PROTECTED] however I don't think session@ is necessary since poe:://kernel/event would make no sense anyway. I understand there's a desire to use POE for applications distributed across several processes. Up to now, the method for determining which process a session exists within has been to specify a Kernel ID in the event name. For example: kernel/session/event - fully-qualified sample event name session/event- for events within the current kernel event- for events within the current session I objected to poe://session/event based on that assumption. It seemed that session would need to move between the URI's host and path parts. That would be a proprietary change to an established standard, which is just wrong no matter how convenient. If I understand your proposal correctly, however, you're not suggesting we break URI semantics at all. You might be suggesting the elimination of a kernel field entirely. That seems possible as long as there's some way to map sessions to network nodes. The kernel field would be implied by the session, and the URI semantics are preserved. I withdraw my objection if that's the case. -- Rocco Caputo - http://poe.perl.org/
Re: PoCo::Child
From: Mike Schroeder [EMAIL PROTECTED] Organization: DonorWare LLC Date: Tue, 14 Dec 2004 16:12:31 -0700 To: [EMAIL PROTECTED] Subject: PoCo::Child The PoCo::Child examples all use ls as the child program. Mike, for examples of how to read/write, see the PoCo::Player components e.g. Mp3, Enc, Slideshow. However, I'm not sure how to get rid of the thing! When I am done sending info to the STDIN, I send a $c-quit(), (and checking the process list the process is indeed gone), but something seems to be hanging on -- POE won't wrap up and clean up after itself -- it just hangs. I tried using PoCo::DebugShell, but PoCo::DebugShell and PoCo::Child seem to fight over STDOUT: this likely has to do with the fact that ::Child is not closing the pipe... Philip Gwyn sent me a patch months ago but only now am I getting around to applying it. I should have something ready for release soon. will post to this list then. - ekkis
Re: POE sessions, clients, confused
Also, check out POE::Component::Child. which reminds me I have some patches I need to release, and I better do it before my upcoming vacation in mid Feb too!
POE on OSX
has anyone successfully installed POE on OSX? I'm failing the test suite for the latest available with the following: Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/lib -Iblib/arch test.pl tests/10_units/01_preprocessor/01_preprocessor..ok tests/10_units/01_preprocessor/02_macro_usebytesok tests/10_units/02_pipes/01_base.skipped all skipped: not implemented yet tests/10_units/02_pipes/02_oneway...skipped all skipped: not implemented yet tests/10_units/02_pipes/03_twoway...skipped all skipped: not implemented yet tests/10_units/03_base/01_poe...ok tests/10_units/03_base/02_api_resloader.ok tests/10_units/03_base/03_component.ok tests/10_units/03_base/04_driverok tests/10_units/03_base/05_filterok tests/10_units/03_base/06_loop..ok tests/10_units/03_base/07_queue.ok tests/10_units/03_base/08_resource..ok tests/10_units/03_base/09_resources.skipped all skipped: not implemented yet tests/10_units/03_base/10_wheel.ok tests/10_units/03_base/11_assert_usage..ok tests/10_units/03_base/12_assert_retval.ok tests/10_units/03_base/13_assert_data...ok tests/10_units/03_base/14_kernelok tests/10_units/04_drivers/01_sysrw..ok tests/10_units/05_filters/01_block..ok tests/10_units/05_filters/02_grep...skipped all skipped: not implemented yet tests/10_units/05_filters/03_http...ok 7/56 skipped: PUT not supported yet. tests/10_units/05_filters/04_line...ok tests/10_units/05_filters/05_mapskipped all skipped: not implemented yet tests/10_units/05_filters/06_recordblockskipped all skipped: not implemented yet tests/10_units/05_filters/07_reference..ok tests/10_units/05_filters/08_stream.ok tests/10_units/05_filters/50_stackable..ok tests/10_units/05_filters/99_filterchange...ok tests/10_units/06_queues/01_array...ok tests/20_resources/10_perl/aliases..ok tests/20_resources/10_perl/caller_state.ok tests/20_resources/10_perl/controls.ok tests/20_resources/10_perl/events...ok tests/20_resources/10_perl/extrefs..ok tests/20_resources/10_perl/filehandles..ok tests/20_resources/10_perl/sessions.ok tests/20_resources/10_perl/sids.ok tests/20_resources/10_perl/signals..ok tests/20_resources/10_perl/statistics...skipped all skipped: not implemented yet tests/30_loops/10_select/all_errors.skipped all skipped: most of these should move into other tests tests/30_loops/10_select/comp_tcp...ok tests/30_loops/10_select/k_alarms...ok 31/37 # Failed test (tests/30_loops/00_base/k_alarms.pm at line 167) tests/30_loops/10_select/k_alarms...ok 37/37# Looks like you failed 1 test of 37. tests/30_loops/10_select/k_alarms...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 36 Failed 1/37 tests, 97.30% okay tests/30_loops/10_select/k_aliases..ok tests/30_loops/10_select/k_detach...ok tests/30_loops/10_select/k_selects..ok tests/30_loops/10_select/k_signals..ok 2/8# Waiting 2 seconds for child processes to settle. tests/30_loops/10_select/k_signals..ok tests/30_loops/10_select/ses_nfaok tests/30_loops/10_select/ses_sessionok tests/30_loops/10_select/wheel_accept...FAILED test 3 Failed 1/4 tests, 75.00% okay tests/30_loops/10_select/wheel_run..ok tests/30_loops/10_select/wheel_sf_ipv6.. *** *** This test may hang if your firewall blocks IPv6 *** packets across your localhost interface. *** tests/30_loops/10_select/wheel_sf_ipv6..ok tests/30_loops/10_select/wheel_sf_tcp...ok tests/30_loops/10_select/wheel_sf_udp...ok tests/30_loops/10_select/wheel_sf_unix..ok tests/30_loops/10_select/wheel_tail.ok tests/30_loops/20_poll/all_errors...skipped all skipped: most of these should move into other tests tests/30_loops/20_poll/comp_tcp.ok tests/30_loops/20_poll/k_alarms.NOK 36 # Failed test (tests/30_loops/00_base/k_alarms.pm at line 167) tests/30_loops/20_poll/k_alarms.ok 37/37# Looks like you failed 1 test of 37. tests/30_loops/20_poll/k_alarms.dubious Test returned status 1 (wstat 256, 0x100) DIED.
Re: POE on OSX
Summary of my perl5 (revision 5.0 version 8 subversion 1 RC3) configuration: Platform: osname=darwin, osvers=7.0, archname=darwin-thread-multi-2level uname='darwin hampsten 7.0 darwin kernel version 6.0: fri jul 25 16:58:41 pdt 2003; root:xnu-344.frankd.rootsxnu-344.frankd~objrelease_ppc power macintosh powerpc ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -g -pipe -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: RC3 Built under darwin Compiled at Sep 12 2003 19:50:49 @INC: /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl . From: Rocco Caputo [EMAIL PROTECTED] Date: Sat, 29 Jan 2005 11:39:08 -0500 To: poe@perl.org Subject: Re: POE on OSX On Fri, Jan 28, 2005 at 11:57:34PM -0800, Erick Calder wrote: has anyone successfully installed POE on OSX? I'm failing the test suite for the latest available with the following: [...] Failed Test Stat Wstat Total Fail Failed List of Failed - -- tests/30_loops/10_select/k_alarms1 256371 2.70% 36 tests/30_loops/10_select/wheel_ac41 25.00% 3 tests/30_loops/20_poll/k_alarms.t1 256371 2.70% 36 tests/30_loops/20_poll/wheel_tail91 11.11% 6 58 tests and 7 subtests skipped. Failed 4/125 test scripts, 96.80% okay. 4/3508 subtests failed, 99.89% okay. make: *** [test_dynamic] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force Time for some perl -V action, because I'm developing POE on OS X now, and I run make test before most commits. -- Rocco Caputo - http://poe.perl.org/
Re: POE on OSX
the only difference I see in this listing is the /sw directories added to @INC... I don't have such a directory, how did you get that? From: [EMAIL PROTECTED] Date: Sat, 29 Jan 2005 16:17:09 -0500 (EST) To: poe@perl.org Subject: Re: POE on OSX I just installed POE using CPAN last night on OS 10.3.7 without a problem. Here's the output of `perl -V` on my machine; feel free to compare. The only difference I see is that I have Fink installed.
Re: POE on OSX
hmm... maybe it has to do with your installing Gtk/tk/etc. did you install Event.pm? I fail 2 tests on Event 2.01 -- I've googled and found other ppl with the same issue but no solutions so far. for the record, I'm running 10.3.7 - e Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/attach_to...v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/attach_to...ok t/bored...v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/bored...ok t/callbackv-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/callbackok t/datav-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/dataok t/delete..v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/delete..ok t/evalv-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/evalok t/fifov-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/fifook t/generic.v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/generic.ok t/group...v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/group...ok t/hookv-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/hookok t/hup.v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/hup.ok t/idlev-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/idleok t/idle2...v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/idle2...ok t/io..v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/io..NOK 6# Test 6 got: '0' (t/io.t at line 87) # Expected: '1' # t/io.t line 87 is: ok $noticed_bogus_fd, 1; t/io..NOK 7# Failed test 7 in t/io.t at line 88 # t/io.t line 88 is: ok !defined $bogus-fd; t/io..FAILED tests 6-7 Failed 2/8 tests, 75.00% okay t/leakv-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/leakok t/leak2...v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/leak2...ok t/loopv-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. t/loopok t/now.v-strings are deprecated at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11. v-string in use/require non-portable at /private/var/root/.cpan/build/Event-1.02/blib/lib/Event.pm line 11.
Re: POE on OSX
I installed Fink but don't find anything resembling Event.pm - in any case, this module is optional (as is Gtk/Tk), right? so if I can't build POE there's some other reason... what should be my next step? From: Rocco Caputo [EMAIL PROTECTED] Date: Sat, 29 Jan 2005 19:04:44 -0500 To: poe@perl.org Subject: Re: POE on OSX On Sat, Jan 29, 2005 at 02:50:04PM -0800, Erick Calder wrote: hmm... maybe it has to do with your installing Gtk/tk/etc. did you install Event.pm? I fail 2 tests on Event 2.01 -- I've googled and found other ppl with the same issue but no solutions so far. for the record, I'm running 10.3.7 No, Event, Tk, and Gtk didn't install with Apple's Perl. Tk builds successfully with Perl from fink. I think Event does, too. Gtk doesn't, however. -- Rocco Caputo - http://poe.perl.org/
Re: POE 0.32 is released
is there a good reason why this release should require File::Spec = 0.87 ? I have 0.83 on my cruddy old Shrike box (which used to come as part of the perl RPM (but apparently is not sold separately)) and don't particularly care to upgrade perl just for File::Spec if I don't have to. From: Rocco Caputo [EMAIL PROTECTED] Date: Sat, 6 Aug 2005 12:28:12 -0400 To: poe@perl.org Subject: POE 0.32 is released POE 0.32 has just gone onto the PAUSE. It should reach your favorite CPAN mirror shortly. It's also available through SourceForge, with a homegrown ActiveState PPD and tarball for your convenience. As usual, http://poe.perl.org/?Where_to_Get_POE is there for guidance. Highlights of the changes since 0.31: - The POE::Session-new() deprecation continues. The new() constructor carps when used. - Signal semantics have changed slightly. Now SIGCHLD and SIGPIPE are IGNORE by default. Previously, programs that didn't handle SIGCHLD would leave zombie processes. - Ed W. patched POE::Wheel::SockteFactory to support non-blocking connect() under ActiveState Perl. Merijn Broeren patched it so the non-blocking semantics don't bleed into sockets created through other means. - All known issues with POE running under Cygwin have been addressed. - The core of the Tk event loop bridge has been rewritten, improving its robustness and portability. It supports loop_do_timeslice(), and it should be less prone to memory leaks. - POE's tests now compensate for time fluctuations (especially negative ones) on machines with variable CPU rates. - POE::Kernel's select() methods have gained pass-through parameters. Values passed to select() this way will be passed through to event handlers. It's easier to maintain continuity through file access. - Jonathan Steinert found and fixed a nasty edge case where event arguments were not destroyed within the proper context. In rare cases this would cause bizarre fatal errors. The other 90% of this iceberg can be found at http://poe.perl.org/?POE_CHANGES . Thank you for your help. A lot of POE's development comes from people on this list, whether through comments, bug reports or patches. POE wouldn't be nearly as cool without you. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: POE 0.32 is released
how I got into this pickle is that I'm getting a warning from Wheel::Run but rather than reporting it, since I figured no one would want to hear of troubles with my old 0.2802 POE, I thought I'd upgrade... in case anyone cares, or can suggest what the issue might be: Use of uninitialized value in string eq at /usr/lib/perl5/site_perl/5.8.0/POE/Wheel/Run.pm line 865. - e From: sungo [EMAIL PROTECTED] Date: Thu, 11 Aug 2005 10:42:21 -0400 To: Erick Calder [EMAIL PROTECTED] Cc: Rocco Caputo [EMAIL PROTECTED], poe@perl.org Subject: Re: POE 0.32 is released On (08/10 23:12), Erick Calder wrote: care to upgrade perl just for File::Spec if I don't have to. File::Spec lives a dual life and is available from CPAN. most core modules are this way. you do not have to upgrade perl to get a newer File::Spec. -- sungo http://eekeek.org
Re: POE 0.32 is released
I would say that the important bit here isn't that the problem exists in 0.2802 but that it exists in perl 5.8.0. that version sucks. upgrade to .1 at least already. well... according to up2date my Shrike box has the latest available perl on it (5.8.0) so I guess that to overcome this issue I'll have to wait till I'm done installing Fedora Core IV on my new MacMini... I had rather hoped to get a new release of PoCo::Child out there now... but it's waited months so i guess it can wait a bit longer... thx - e
Re: namespace request - PoCo::Server::MDP
On Aug 26, 2005, at 16:27, Jeff Lowrey wrote: use POE::Component::Server::MDP::POEQueueProvider; is a server really a component? wouldn't POE::Server::MDP make more sense?
PoCo::Child
with my apologies to everyone who has waited so long for this release, version 1.39 of this module has just been posted to CPAN. it fixes a number of issues, see the Changes file. in the coming year I hope to have more time to devote to POE (at present I'm working 60+ hrs/wk which leaves little time for anything else), specifically to release a series of modules that implement a p2p network I built a while back. until then, Happy New Year's everyone! - ekkis
Re: Bug in PoCo::Child when PID wraps round
sorry, I still own it. I've just been disconnected from the world a long
time. it will take me a while to get back to you on this but I will
From: Tony Wildish wild...@mail.cern.ch
Date: Thu, 7 May 2009 10:58:12 +0200
To: poe@perl.org
Subject: Re: Bug in PoCo::Child when PID wraps round (fwd)
Hi,
just checking one more time: is anyone looking after PoCo::Child, or is
it orphaned?
TIA,
Tony.
On Wed, 15 Apr 2009, Tony Wildish wrote:
Hi,
I sent this to the bug-poe-component-ch...@rt.cpan.org list some time ago
but it looks like that list is dead. Is there someone here managing
PoCo::Child?
Cheers,
Tony.
-- Forwarded message --
Date: Tue, 24 Mar 2009 12:56:33 +0100 (CET)
From: Tony Wildish wild...@mail.cern.ch
To: bug-poe-component-ch...@rt.cpan.org
Subject: Bug in PoCo::Child when PID wraps round
Hi,
we have been using PoCo::Child in a project for a while now and have just
uncovered a bug. The internal bookkeeping for the association of wheelIDs
and PIDs is wrong, with the result that when the OS PID wraps round, the
wrong wheelID will be given to the 'done' event.
I'm using PoCo::Child version 1.39, perl 5.8.5, kernel
2.6.9-78.0.8.EL.cernsmp.
You can see the bug by inspection of the code. At line 192 we have:
my $id = $wheel-ID;
$self-debug(qq/run(): @$cmd, wheel=$id, pid=/ . $wheel-PID);
$self-{$PKG}{pids}{$wheel-PID} = $id;
so the {pids} are inserted keyed on $wheel-PID. But at line 268, the
clean up deletes as follows:
delete $self-{$PKG}{wheels}{$id};
delete $self-{$PKG}{pids}{$id};
so it's deleting keyed on wheel-ID, not $wheel-PID.
When the PIDs wrap round, the protection in sig_child is broken by this:
sub sig_child {
my ($kernel, $self, $pid, $rc) = @_[KERNEL, OBJECT, ARG1, ARG2];
my $id = $self-{$PKG}{pids}{$pid} || ;
# child death signals are issued by the OS and sent to all
# sessions; we want to handle only our own children
return unless $id;
Because the {pids} hash had the wrong entry deleted in the cleanup, when
the PIDs wrap, an old $id will be found where none should be. So sig_child
will not return here, and will cause 'done' to be fired with the old
wheelID, which is plainly wrong.
Also, the cleanup around line 268/269 should remove {CLOSED} and
{SIGCHLD} entries for the wheel too. That's less serious because it won't
cause a problem until wheel-IDs wrap round, which will take a lot longer,
but it's still a leak.
Cheers,
Tony.
Re: run an interactive command using POE::Wheel?
On Sep 26, 2009, at 9:52 AM, chris fedde wrote: 2009/9/26 Olivier Mengué olivier.men...@gmail.com: It would be easier if the mailing list admin would reconfigure the list so we get poe@perl.org as the recipient when we choose Reply. More than once I made the mistake of replying only to the post author. I know my agreement with you on this point counts for naught but I too find it bothersome to have to constantly remove private addresses from the To: and CC: fields and to have to move the lists's address to the To: Unfortunately that would be exactly the opposite of normal mailing list behaviour. IMO what constitutes normal mailing list behaviour is debatable. there are any number of lists out there that do the more expedient thing (if not the right thing). The email client presents two choices reply to all and reply. Etiquette suggests that you normally choose reply to all. If the list were to attempt to subvert this behaviour as you suggest then special actions would be required on the part of any recipient if they wished to open a private dialogue with the sender. seems to me joining a mailing list carries the implicit intention of conversing across the list, thus replying to the list should be the default behaviour and opening private dialogue should require a special effort. Suggesting a technical solution to a simple misunderstanding of community expectations seems inappropriate to me. With best wishes cfedde incidentally, I did always mean to request that a prefix be added to the Subject header of this like, as is done with most other lists e.g. [POE] Re: ... as that makes it easy to file mail into a special box (I know, I can create a rule that defines that if _any_ of the To: Reply- to: Cc: or Bcc: contain poe@perl.org then file away, but it would be much easier to rely on the subject. aside from that it's visually easier to deal with)
Re: POE::Component::Player::Mpg123 fails make test?
it's been years since I touch that stuff too. the PoCo::Player:Mpg123 was supplanted with PoCo::Player:Mp3... I'd suggest you try that one instead On Feb 21, 2010, at 9:20 AM, Daniel Risacher wrote: I confess it has been several years since I last worked with POE, so I'm out of touch. I'm having troubles, and I'm not sure if it's something I'm doing wrong or it it's bitrot in the packages. Perhaps someone here will have insight? [Context/Versions: Ubuntu 9.10 Desktop Perl 5.10.0 POE-Component-Player-Mpg123-1.2 mpg123 1.7.3. POE 1.006 (which is in the Ubuntu repos) and POE 1.286 (latest from CPAN)] 'make test' fails like this: (note you have to provide ./test.mp3) POE-Component-Player-Mpg123-1.2$ make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/lib -Iblib/arch test.pl 1..20 ok 1 - finding player ok 2 - finding test track ok 3 - read permissions ok 4 - use PoCo::Player::Mpg123 ok 5 - session created ok 6 - component instantiated not ok 7 - play issued # Failed test 'play issued' # at test.pl line 46. Not a HASH reference at blib/lib/POE/Component/Player/Mpg123.pm line 133. # Looks like you planned 20 tests but ran 7. # Looks like you failed 1 test of 7 run. # Looks like your test exited with 255 just after 7. make: *** [test_dynamic] Error 255 Further investigation indicates that the arguments to the 'stdout' callback do not appear to be what I expect, based on the documentation for POE::Component::Child.
