Skip Menu |

This queue is for tickets about the POE-Component-Schedule CPAN distribution.

Maintainer(s)' notes

The new source repo is now at https://github.com/dolmen/p5-POE-Component-Schedule

Report information
The Basics
Id: 53925
Status: open
Priority: 0/
Queue: POE-Component-Schedule
People
Owner: dolmen [...] cpan.org
Requestors: chris [...] fedde.us
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 0.92
Fixed in: 0.94

History Show all quoted text
  Fri Jan 22 16:47:39 2010 chris [...] fedde.us - Ticket created
Subject: POE::Component::Cron tickles a bug in 0.92
See http://rt.cpan.org/Public/Bug/Display.html?id=53491 POE is 1.284, POE::Component::Cron is 0.021 problem reported in both perl 5.10.0 and 5.10.1 I can duplicate this and will look into it further soon. $ 14:37:48 cfedde@floss:~/src/POE-Component-Cron-0.021 make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/POE-Component-Cron.t .. 1/? # This is going to take about two minutes Attempt to bless into a reference at /usr/local/share/perl/5.10.0/POE/Component/Schedule.pm line 165. # Looks like your test exited with 255 just after 2. 10075: Sessions were started, but POE::Kernel's run() method was never 10075: called to execute them. This usually happens because an error 10075: occurred before POE::Kernel->run() could be called. Please fix 10075: any errors above this notice, and be sure that POE::Kernel->run() 10075: is called. See documentation for POE::Kernel's run() method for 10075: another way to disable this warning. t/POE-Component-Cron.t .. Dubious, test returned 255 (wstat 65280, 0xff00) All 2 subtests passed Test Summary Report ------------------- t/POE-Component-Cron.t (Wstat: 65280 Tests: 2 Failed: 0) Non-zero exit status: 255 Files=1, Tests=2, 1 wallclock secs ( 0.05 usr 0.01 sys + 0.59 cusr 0.08 csys = 0.73 CPU) Result: FAIL Failed 1/1 test programs. 0/2 subtests failed. make: *** [test_dynamic] Error 255
  Fri Jan 22 17:30:21 2010 chris [...] fedde.us - Correspondence added
15:10:20 <+zephg> cfedde: poco::schedule 0.03 results in all tests passing
  Fri Jan 22 17:30:22 2010 chris [...] fedde.us - Status changed from 'new' to 'open'
  Fri Jan 22 18:14:25 2010 zeph.gillen [...] gmail.com - Correspondence added
From: zeph.gillen [...] gmail.com
On Fri Jan 22 17:30:21 2010, CFEDDE wrote: Show quoted text
> 15:10:20 <+zephg> cfedde: poco::schedule 0.03 results in all tests > passing >
This results in all tests passing for POE::Component::Schedule and POE::Component::Cron. Is a new test needed in PoCo::Schedule to catch this?
Subject: bless.patch
diff -Naur POE-Component-Schedule-0.92/lib/POE/Component/Schedule.pm POE-Component-Schedule-0.92-zephg/lib/POE/Component/Schedule.pm --- POE-Component-Schedule-0.92/lib/POE/Component/Schedule.pm 2009-11-20 11:03:55.000000000 -0700 +++ POE-Component-Schedule-0.92-zephg/lib/POE/Component/Schedule.pm 2010-01-22 16:08:00.000000000 -0700 @@ -162,7 +162,7 @@ # We return a kind of smart pointer, so the schedule # can be simply destroyed by releasing its object reference - return bless \$id, $class; + return bless \$id, ref($class) || $class; } sub delete {
  Tue Feb 09 06:56:46 2010 dolmen [...] cpan.org - Taken
  Tue Feb 09 17:23:58 2010 dolmen [...] cpan.org - Correspondence added
RT-Send-CC: zeph.gillen [...] gmail.com
Le Ven 22 Jan 2010 18:14:25, zephg a écrit : Show quoted text
> Is a new test needed in PoCo::Schedule to catch this?
Yes I would appreciate it, because I tried to write one, but failed. Could you explain me why the following program does not show the same problem? use strict; use warnings; { package A; sub new { my $class = shift; bless {}, $class; } sub ok { print "OK\n"; } 1; } { package B; use base 'A'; 1; } my $b = B->new(); $b->ok; -- Olivier Mengué - http://o.mengue.free.fr/
  Fri Feb 12 20:01:13 2010 dolmen [...] cpan.org - Status changed from 'open' to 'patched'
  Sat Mar 13 19:09:41 2010 dolmen [...] cpan.org - Correspondence added
RT-Send-CC: zeph.gillen [...] gmail.com
0.94 has been released and it includes the patch. -- Olivier Mengué - http://o.mengue.free.fr/
  Sat Mar 13 19:09:45 2010 The RT System itself - Status changed from 'patched' to 'open'
  Sat Mar 13 19:09:47 2010 dolmen [...] cpan.org - Status changed from 'open' to 'resolved'
  Mon Oct 25 05:27:35 2010 dolmen [...] cpan.org - Fixed in 0.94 added
  Wed May 04 12:45:58 2011 dolmen [...] cpan.org - Correspondence added
RT-Send-CC: zeph.gillen [...] gmail.com
Le 2010-02-09 17:23:58, DOLMEN a écrit : Show quoted text
> Could you explain me why the following program does not show the same > problem?
There is an explanation about the "ref($class) || $class" construct here: http://www.perlmonks.org/?node_id=147708 However, I still don't see why it is needed in POE::Component::Schedule. No copy behaviour is implemented. -- Olivier Mengué - http://search.cpan.org/~dolmen/ http://github.com/dolmen/
  Wed May 04 12:45:59 2011 The RT System itself - Status changed from 'resolved' to 'open'
  Wed May 04 12:46:36 2011 dolmen [...] cpan.org - Status changed from 'open' to 'resolved'
  Fri Mar 09 08:14:05 2012 dolmen [...] cpan.org - Correspondence added
RT-Send-CC: zeph.gillen [...] gmail.com
Le 2011-05-04 18:45:58, DOLMEN a écrit : Show quoted text
> Le 2010-02-09 17:23:58, DOLMEN a écrit : >
> > Could you explain me why the following program does not show the same > > problem?
> > There is an explanation about the "ref($class) || $class" construct here: > > http://www.perlmonks.org/?node_id=147708 > > However, I still don't see why it is needed in POE::Component::Schedule. > No copy behaviour is implemented.
I still don't understand why it is needed in poco:Schedule. And I'm not the only one to no want this in my code and shown by this Perl::Critic policy: https://metacpan.org/module/Perl::Critic::Policy::Bangs::ProhibitRefProtoOrProto -- Olivier Mengué - http://perlresume.org/DOLMEN
  Fri Mar 09 08:14:06 2012 The RT System itself - Status changed from 'resolved' to 'open'