This is twitter.com/rcaputo's Typepad Profile.
Join Typepad and start following twitter.com/rcaputo's activity
Join Now!
Already a member? Sign In
twitter.com/rcaputo
Recent Activity
While it "looks like a hack", a small example is much more reasonable for a blog comment than a larger, more complete program. I'm glad that it concisely proved my point. As for POE's documentation, it does explain how to call run() so that it returns right away without taking control of the event loop. I admit it could be clearer. The original included: POE::Kernel will print a strong message if a program creates sessions but fails to call run(). If the lack of a run() call is deliberate, you can avoid the message by calling it before creating a session. run() at that point will return immediately, and POE::Kernel will be satisfied. (example) ... Based on your feedback, I am changing it to read: POE::Kernel will print a strong message if a program creates sessions but fails to call run(). Prior to this warning, we received tons of bug reports along the lines of "my POE program isn't doing anything". It turned out that people forgot to start an event dispatcher, so events were never dispatched. If the lack of a run() call is deliberate, perhaps because some other event loop already has control, you can avoid the message by calling it before creating a session. run() at that point will initialize POE and return immediately. POE::Kernel will be satisfied that run() was called, although POE will not have actually taken control of the event loop. (example) Note, however, that this varies from one event loop to another. If a particular POE::Loop implementation doesn't support it, that's probably a bug. Please file a bug report with the owner of the relevant POE::Loop module. ... If this change is unsatisfactory or you encounter any other problems, please send bug reports and/or patches to POE's bug queue at rt.cpan.org. Constructive dialoge with CPAN authors will increase the rate of CPAN improvement. You will want to do this if you're interested in helping Perl be a friendlier, more welcoming platform for open source development.
1 reply
By the way, your style for pre-formatted text in comments seems a bit vertically sparse and not very monospaced. The preview style looked a lot better, although the textarea was kind of small.
1 reply
I respectfully disagree, and I have code to back me up. POE runs with other main loops. In fact, POE::Kernel->run() is often implemented in terms of native event dispatchers. POE::Loop classes implement event watchers using native watchers, and native callbacks are used to generate POE events. Depending on the POE::Loop implementation, POE::Kernel->run() need not be called upon to dispatch events. This is CPAN, so your mileage may vary. If you're interested in improving CPAN, submit bug reports to the appropriate queues. I mentioned I had code. Here's a working example of POE code and native Glib code running together in the same program, using Glib's MainLoop: use Glib; use POE; POE::Session->create( inline_states => { _start => sub { $_[KERNEL]->delay(tick => 1) }, tick => sub { print "poe tick at ", time(), "...\n"; $_[KERNEL]->delay(tick => 1); }, }, ); my $glib_timer = Glib::Timeout->add( 500, sub { print "glib tick at ", time(), "...\n"; return 1; } ); # Dispatches Glib and POE events. Glib::MainLoop->new->run(); Of course you can call POE::Kernel->run() instead of Glib's main loop. This is a good thing. A single, portable run() method covers every supported event loop.
1 reply