On 2 Jan 2008, at 20:02, nadim khemir wrote:
On Saturday 29 December 2007 10.11.41 Matisse Enzer wrote:
I've spent some of this holiday season learning how to set up
BuildBot
...
Cabie seems to be as good, if not better (psst, it's written in Perl).
http://cabie.tigris.org/
There's also
# from Aristotle Pagaltzis
# on Wednesday 02 January 2008 16:47:
>> looking for (and diffusing) mines
>
>That sounds like a novel approach! Or do you mean “defusing”? :-)
Yeah :-D Diffuse is probably what they do when you find them the less
careful way!
I guess the tank+flail mechanism is stil
Eric Wilhelm wrote:
> # from Aristotle Pagaltzis
> # on Wednesday 02 January 2008 16:47:
>
>>> looking for (and diffusing) mines
>> That sounds like a novel approach! Or do you mean “defusing”? :-)
>
> Yeah :-D Diffuse is probably what they do when you find them the less
> careful way!
>
> I g
On 2 Jan 2008, at 20:02, nadim khemir wrote:
Cabie seems to be as good, if not better (psst, it's written in Perl).
Does that make it better? :)
--
Andy Armstrong, Hexten
On Wednesday 02 January 2008 16:21:24 Adrian Howard wrote:
> >> * Pointless warnings from UNIVERSAL::can needed to be stomped.
> > Is this with U::c 1.13_001?
> Nope. 1.12.
If you have a chance, would you mind trying with 1.13_001? I believe I've
stomped pointless warnings from U::c such that
On 3 Jan 2008, at 09:15, Adrian Howard wrote:
On 2 Jan 2008, at 20:02, nadim khemir wrote:
On Saturday 29 December 2007 10.11.41 Matisse Enzer wrote:
I've spent some of this holiday season learning how to set up
BuildBot
...
Cabie seems to be as good, if not better (psst, it's written in
Andy Armstrong wrote:
> On 3 Jan 2008, at 09:15, Adrian Howard wrote:
>> There's also Michael's rather swizzy Smolder project.
>>
>> http://sourceforge.net/projects/smolder
>
>
> Indeed. Smolder++. You still need something to manage a build farm
> though. I got about 80% done on Test::SmokeSt
On 3 Jan 2008, at 12:53, Michael Peters wrote:
My Python Fu is weak but I spent a productive couple of hours hacking
about with buildbot last night. My aim is to make it easy to test all
the modules in my SVN against multiple Perl's on multiple machines
and
have the config changes to add a new
My personal favorite... rats!
http://www.apopo.org/
No discussion of minesweeping may omit Minesweeper: The Movie.
http://www.collegehumor.com/video:1770138
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Jan 3, 2008 10:20 AM, Ovid <[EMAIL PROTECTED]> wrote:
> We couldn't reproduce the segfaults in the debugger or with
> Devel::Trace, but after a lot of work, a colleague and I found the
> culprit: Contextual::Return. Like Sub::Uplevel, it overrides
> CORE::GLOBAL::caller. Apparently the two do
My test aggregation took a bit longer to implement than Adrian's due to
several issues. Some were bugs in tests, some were in code, but one
issue which took a *long* time to debug was random segfaults.
We couldn't reproduce the segfaults in the debugger or with
Devel::Trace, but after a lot of wo
I mentioned that we removed UNIVERSAL::can because of bugs introduced
by global behavior changes, but to be fair to chromatic, I should
explain that this is because of code in Template::Timer:
perl -MUNIVERSAL::can -MTemplate::Timer -e 1
Died at lib/perl5/Template/Timer.pm line 63.
Compilati
On 03/01/2008, Ovid <[EMAIL PROTECTED]> wrote:
> I mentioned that we removed UNIVERSAL::can because of bugs introduced
> by global behavior changes, but to be fair to chromatic, I should
> explain that this is because of code in Template::Timer:
>
> perl -MUNIVERSAL::can -MTemplate::Timer -e 1
>
--- demerphq <[EMAIL PROTECTED]> wrote:
> > The problem is this line in Template::Timer:
> >
> > my $super = __PACKAGE__->can("SUPER::$sub") or die;
> >
> > This is OO code and that should actually read:
> >
> > my $super = __PACKAGE__->can($sub) or die;
>
> Er, i dont see how it could. Then
On 3 Jan 2008, at 16:55, Ovid wrote:
my $super = __PACKAGE__->can("SUPER::$sub") or die;
This is OO code and that should actually read:
my $super = __PACKAGE__->can($sub) or die;
Should that be __PACKAGE__->SUPER::can($sub) ?
--
Andy Armstrong, Hexten
On 3 Jan 2008, at 17:20, Andy Armstrong wrote:
my $super = __PACKAGE__->can($sub) or die;
Should that be __PACKAGE__->SUPER::can($sub) ?
Hmm. Does that do what I think it does? Maybe not.
And talking to yourself? What's all that about?
--
Andy Armstrong, Hexten
On 03/01/2008, Ovid <[EMAIL PROTECTED]> wrote:
> --- demerphq <[EMAIL PROTECTED]> wrote:
>
> > > The problem is this line in Template::Timer:
> > >
> > > my $super = __PACKAGE__->can("SUPER::$sub") or die;
> > >
> > > This is OO code and that should actually read:
> > >
> > > my $super = __PACK
On Jan 2, 2008, at 12:02 PM, nadim khemir wrote:
On Saturday 29 December 2007 10.11.41 Matisse Enzer wrote:
I've spent some of this holiday season learning how to set up
BuildBot
...
Cabie seems to be as good, if not better (psst, it's written in Perl).
http://cabie.tigris.org/
Can you
On 03/01/2008, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 3 Jan 2008, at 17:20, Andy Armstrong wrote:
> >> my $super = __PACKAGE__->can($sub) or die;
> >
> > Should that be __PACKAGE__->SUPER::can($sub) ?
>
>
> Hmm. Does that do what I think it does? Maybe not.
Without looking at the code we d
On Thursday 03 January 2008 11.50.03 Andy Armstrong wrote:
> > Cabie seems to be as good, if not better (psst, it's written in Perl).
> Does that make it better? :)
RTFM! In the feature list the authors writes "* It's really cool!". Since cool
is better than good, I assume it is ;)
The "written
On Thursday 03 January 2008 09:58:28 demerphq wrote:
> And thinking about it more i think that was the whole point of the
> weird call, Im guessing here, but probably this code isnt in a method
> which means that he doesnt have access to SUPER so, he passes it into
> can() which does.
>
> The foll
--- David Golden <[EMAIL PROTECTED]> wrote:
> Maybe it's too late, but which versions of Sub::Uplevel and
> Contextual::Return were you using?
Sub::Uplevel 0.12 (and old version. Forgot to check that).
Contextual::Return was 0.2.1 both with and without the patch listed in
http://rt.cpan.org/Publ
On 03/01/2008, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 03 January 2008 09:58:28 demerphq wrote:
>
> > And thinking about it more i think that was the whole point of the
> > weird call, Im guessing here, but probably this code isnt in a method
> > which means that he doesnt have access to
On 3 Jan 2008, at 21:02, Aristotle Pagaltzis wrote:
No. That calls `can` from the superclass, but passes
`__PACKAGE__` as the invocant. Assuming that the subclass and the
superclass use the same inherited `can` method, the result is
therefore exactly the same.
The correct incantation is
my (
* Andy Armstrong <[EMAIL PROTECTED]> [2008-01-03 18:25]:
> On 3 Jan 2008, at 16:55, Ovid wrote:
>> my $super = __PACKAGE__->can("SUPER::$sub") or die;
>>
>> This is OO code and that should actually read:
>>
>> my $super = __PACKAGE__->can($sub) or die;
>
> Should that be __PACKAGE__->SUPER::can($
On Jan 3, 2008 11:09 AM, Ovid <[EMAIL PROTECTED]> wrote:
> For smaller projects, you have fewer interactions. For large projects,
> globally altered behavior is playing russian roulette without counting
> the bullets.
At least Sub::Uplevel documentation makes a point of warning in
several places
On Tue, Jan 01, 2008 at 08:23:52PM -0500, James E Keenan wrote:
> David Cantrell wrote:
> >If anyone can give me an idiots' guide to how to grab the most recent
> >source tree, build it, and test it, then I can test it on the same boxes
> >as I do CPAN testing, plus maybe a couple of others.
> svn
On 03/01/2008, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Andy Armstrong <[EMAIL PROTECTED]> [2008-01-03 18:25]:
> > On 3 Jan 2008, at 16:55, Ovid wrote:
> >> my $super = __PACKAGE__->can("SUPER::$sub") or die;
> >>
> >> This is OO code and that should actually read:
> >>
> >> my $super =
On Thu, Jan 03, 2008 at 07:20:38AM -0800, Ovid wrote:
> We couldn't reproduce the segfaults in the debugger or with
> Devel::Trace, but after a lot of work, a colleague and I found the
> culprit: Contextual::Return. Like Sub::Uplevel, it overrides
> CORE::GLOBAL::caller.
That probably explains
* demerphq <[EMAIL PROTECTED]> [2008-01-04 00:00]:
> Consider that with 5.10 its possible to use other method
> resolution rules than the one your snippet mimics.
Does it change the MRO globally without regard for whether any
loaded classes are prepared for that?
Regards,
--
Aristotle Pagaltzis
30 matches
Mail list logo
