POE::Component::Cron scheduling no longer works with aliases. There
also seems to be an issue with PoCo::Schedule, but I can't figure it out.
Attached file demonstrates the bug.
IRC LOG:
[17:33] <reyjrar> so, PoCo::Cron 0.19 implements scheduling internally
[17:33] <reyjrar> that's the module I'm actually using..
[17:33] <reyjrar> PoCo::Cron 0.21 now subclasses PoCo::Schedule
[17:34] <dngor> Something broke between 0.19 and 0.21?
[17:34] <reyjrar> yeah..
[17:34] <reyjrar> but PoCo::Schedule and POE both upgraded between
those timelines as well
[17:35] <dngor> Poke PoCo::Cron's author to help you track it down?
[17:35] <dngor> Are you also using Tk, or something?
[17:35] <reyjrar> nah.. I am using Loop::IO_Poll though..
[17:36] <reyjrar> that doesn't make a difference though..
[17:36] <reyjrar> just removed it..
[17:37] <reyjrar> I'll email the PoCo::Cron guy, my guess is he's got a
better understanding of PoCo::Schedule than I have..
[17:37] <dngor> Yeah. I'm looking for ways to divide and conquer the
problem... so ruling stuff out is good.
[17:37] <reyjrar> but my guess is he's going to punt to the
PoCo::Schedule author..
[17:37] <reyjrar> yeah, I'm trying to get enough information together
to isolate the problem..
[17:37] <dngor> Maybe, but if he knows better and punts, then you've
got more confidence in the problem's source.
[17:37] <reyjrar> and unfortunately, I'm lost right now..
[17:38] * dngor outs cfedde as the author of PoCo::Cron.
[17:39] <reyjrar> haha.. yeah, I was just going to email him
[17:41] <cfedde> what's broke?
[17:42] * GumbyNET5 cpan.testers: PASS POE-1.287 i386-netbsd 3.1
perl-v5.12.0 RC1 bingos@cpan.org #7043143
[17:42] <cfedde> I heard that PoCo::Schedule had been patched to fix
the most recent bug.
[17:43] <reyjrar> cfedde: well, in 0.19, you could send the session
alias.. that doesn't work in 0.21
[17:43] <reyjrar> cfedde: fixed that by passing $_[SESSION]
[17:44] <cfedde> reyjrar: do you have an example or a test case?
[17:44] <reyjrar> cfedde: working on it now..
[17:44] <cfedde> that was a behavior that I wanted to preserve
[17:44] <reyjrar> I've been trying to isolate the problem..
[17:44] <reyjrar> and make sure it wasn't something stupid I did..
[17:44] <reyjrar> :)
[17:45] <cfedde> I might have to roll back to the way it did it in
0.19. poco::schedule went all second system on us.
[17:46] <cfedde> reyjrar: just some code that tickles the bug would be
cool.
[17:46] <reyjrar> ok, I turned on assertions and got something
[17:47] <cfedde> I'd love it if you found a patch. Even better if it's
in my code.
[17:51] <cfedde> reyjrar: so you want something like
POE::Component::Cron->from_cron('* * * * *' => $s2 => 'modify'); to work
[17:51] <reyjrar> cfedde: yeah..
[17:52] <cfedde> rather than having to say $s2->ID. Which is kinda sucky.
[17:52] <reyjrar> cfedde: neither work
[17:52] <reyjrar> cfedde: well
[17:52] <reyjrar> cfedde: neither causes an error..
[17:52] <reyjrar> cfedde: but my event is never fired..
[17:53] <reyjrar> cfedde: using a session alias causes PoCo::Schedule
to error
[17:53] <reyjrar> cfedde: which used to work..
[17:53] <cfedde> an actual alias.
| Subject: | PoCoCronTest.pl |
#!/usr/bin/perl
use strict;
use warnings;
sub POE::Kernel::ASSERT_DEFAULT () { 1 }
use POE qw(
Component::Cron
);
use DateTime::Event::Cron;
my $main_sess_id = POE::Session->create(
inline_states => {
_start => \&start_processor,
_stop => \&stop_processor,
test_event => \&test_event,
},
);
POE::Kernel->run;
exit 0;
#------------------------------------------------------------------------#
# Start the Processor
sub start_processor {
my ($kernel,$heap,$session) = @_[KERNEL,HEAP,SESSION];
$kernel->alias_set('processor');
#
# Schedule Events
POE::Component::Cron->from_cron('* * * * *' => $session => 'test_event' );
$kernel->delay( _die_ => 120);
}
sub stop_processor {
}
sub test_event {
print "test_event fired\n";
}