Re: use Test::More no_plan = $plan;
Aristotle Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2008-09-08 12:55]: In the developer release of Test::Simple, Test::Builder has been altered to die if you have any arguments after 'no_plan'. This means that some previously passing tests will fail. In fact, there are two test programs in Moose 0.57 which have this and thus fail to pass: use Test::More no_plan = 1; I've recommended that we warn instead of croak as I don't know how widespread this problem is I tried to use Google CodeSearch, but for some reason all my regexes that I feed it match all the cases I want to exclude. I tried variations on use\s+Test::More.*no_plan\s*[')/]\s*[^;] but that matches pretty much every `use Test::More` line with `no_plan` on it ever written, regardless of what follows. If anyone can see something that I can’t, please tell me. Just search for no_plan = 1. http://www.google.com/codesearch?hl=enlr=q=%22no_plan%20%3D%3E%201%22+lang%3AperlbtnG=Search I was surprised to get a few hundred results, I've only come across this once and that was in commercial code. Because there's so many uses I took Ovid's recommendation and switched it to a warning. Also the extra argument doesn't do any harm and it's quite understandable that you'd think the args follow the normal config = on_or_off pattern. -- E: Would you want to maintain a 5000 line Perl program? d: Why would you write a 5000 line program?
Re: use Test::More no_plan = $plan;
--- On Tue, 9/9/08, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: I tried to use Google CodeSearch, but for some reason all my regexes that I feed it match all the cases I want to exclude. I tried variations on use\s+Test::More.*no_plan\s*[')/]\s*[^;] but that matches pretty much every `use Test::More` line with `no_plan` on it ever written, regardless of what follows. If anyone can see something that I can’t, please tell me. lang:perl no_plan\s*=\s*\d+ This reminds me of all of the regexes people write to match proper HTML: sometimes something simple is all you need :) lang:perl no_plan\s*=\s*\d+ Schwern had the 'no_plan = 1', but I was curious about plans other than one, so I also did this: lang:perl no_plan\s*=\s*[02-9] Quite a few people are embedding the actual plan with that. I suspect that's so they can later come back and switch no_plan to tests with minimal editing. (Or with 'Test::Most die, no_plan = 7', you can die without having an extra failure from the plan, but I seriously doubt anyone cares about that :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: use Test::More no_plan = $plan;
* Eric Wilhelm [EMAIL PROTECTED] [2008-09-09 07:45]: But, uh... what are you looking for exactly? I was hoping to make a nearly-comprehensive list of modules which make this mistake, like I did back when the “`use_ok` prior to setting a plan silently succeeds” was fixed; assuming the list wasn’t too huge, we could then prod all the authors by mail to ask them to fix their crud, thus mostly averting the disruption even before it happens. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
* Ovid [EMAIL PROTECTED] [2008-09-09 08:35]: This reminds me of all of the regexes people write to match proper HTML: sometimes something simple is all you need :) As I wrote in response to Eric, I was actually trying to get as near a comprehenive list of things that need fixing as possible. The nice thing about having a central package repository with such a strong gravity as CPAN does is that it enables tandem upgrades of dependent code when APIs change incompatibly. Kinda like what getting drivers into the official Linux kernel offers if you are a hardware vendor: if the kernel changes internally, the people who just broke your driver will also fix it for you. Centralisation has many big downsides in the general case, but can be attractive because it also has some highly compelling benefits. Since we do have a case of centralisation here, it seems a waste not to exploit that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
* Michael G Schwern [EMAIL PROTECTED] [2008-09-09 08:15]: I was surprised to get a few hundred results Note that CodeSearch indexes tarballs, so there are likely to be a lot of dupes. But even so, a cautious estimate would still put that at at least several dozen unique hits, so it’s not quite an “I broke CPAN”-level problem, but it’s still significant. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
* Aristotle Pagaltzis [EMAIL PROTECTED] [2008-09-09 09:05]: “I broke CPAN” Btw, Michael, do you have a t-shirt that says that? Because if not, we really need to make you one. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
Aristotle Pagaltzis wrote: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-09-09 09:05]: “I broke CPAN” Btw, Michael, do you have a t-shirt that says that? Because if not, we really need to make you one. :-) Hehe, no, but that would be awesome! :) Maybe that should be the next Best Practical t-shirt. I can break CPAN or the lolcat version Im in yr modules, breakin yr deps -- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: use Test::More no_plan = $plan;
Aristotle Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2008-09-09 08:35]: This reminds me of all of the regexes people write to match proper HTML: sometimes something simple is all you need :) As I wrote in response to Eric, I was actually trying to get as near a comprehenive list of things that need fixing as possible. The nice thing about having a central package repository with such a strong gravity as CPAN does is that it enables tandem upgrades of dependent code when APIs change incompatibly. So jealous of OS vendors for having this ability over the entire environment. *wistful sigh* -- Being faith-based doesn't trump reality. -- Bruce Sterling
Re: use Test::More no_plan = $plan;
--- On Tue, 9/9/08, Michael G Schwern [EMAIL PROTECTED] wrote: The nice thing about having a central package repository with such a strong gravity as CPAN does is that it enables tandem upgrades of dependent code when APIs change incompatibly. So jealous of OS vendors for having this ability over the entire environment. *wistful sigh* Careful. You keep talking like that and Bob Nimby will write a scathing email telling you that since he doesn't need it, neither does anyone else. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Module::Build 0.2809 release coming, should we test it?
On Fri, 5 Sep 2008 16:48:37 -0700, Eric Wilhelm [EMAIL PROTECTED] said: http://scratchcomputing.com/tmp/generated_by.module_build.list Since yesterday I have downloaded and analysed ~56000 testreports from cpantesters and found ~135 distros that have been tested by both MB 0.2808 and 0.2808_03. There is only one result (Test-Group-0.12) that looks bad but it turns out to be due to broken Test::More 0.81_01. All others suggest that _03 is doing well. -- andreas count-for-ewilhelm.pl.out.condensed Description: Binary data
Re: Module::Build 0.2809 release coming, should we test it?
On Mon, 8 Sep 2008 16:36:00 -0700, Eric Wilhelm [EMAIL PROTECTED] said: # from Andreas J. Koenig # on Monday 08 September 2008 15:16: Since yesterday I have downloaded and analysed ~56000 testreports from cpantesters and found ~135 distros that have been tested by both MB 0.2808 and 0.2808_03. There is only one result (Test-Group-0.12) that looks bad but it turns out to be due to broken Test::More 0.81_01. All others suggest that _03 is doing well. Umm... okay. 1. I see a lot of m/0.2808_03 +FAIL/ in there. OK, I walk you through them. First off, there are ten cases in the file I sent you. B-Generate-1.130.2808 FAIL 5 B-Generate-1.130.2808 PASS 6 B-Generate-1.130.2808_03 FAIL 1 So the above is a case where it's impossible to judge without looking at the report but at the same time we cannot have any expectations about a single event when the previous outcome was diverse. Let's call it a case DUNNO. CGI-Application-Plugin-ValidateRM-2.2 0.2808 FAIL 18 CGI-Application-Plugin-ValidateRM-2.2 0.2808_03 FAIL 2 Seems like the exact right behaviour. Let's call it a case OK. Devel-LeakTrace-0.05 0.2808 FAIL 43 Devel-LeakTrace-0.05 0.2808 PASS 6 Devel-LeakTrace-0.05 0.2808_03 FAIL 1 It's a DUNNO but likelihood is high that we need not look closer on this one. HTTP-Proxy-0.230.2808 FAIL 8 HTTP-Proxy-0.230.2808 PASS 5 HTTP-Proxy-0.230.2808_03 FAIL 6 HTTP-Proxy-0.230.2808_03 PASS 1 Although it's a DUNNO, the distribution between fail and pass is quite good. Math-BaseCalc-1.0120.2808 FAIL 9 Math-BaseCalc-1.0120.2808 PASS 9 Math-BaseCalc-1.0120.2808_03 FAIL 1 A DUNNO. Metaweb-0.05 0.2808 FAIL 14 Metaweb-0.05 0.2808 PASS 10 Metaweb-0.05 0.2808_03 FAIL 1 DUNNO Parse-BACKPAN-Packages-0.330.2808 FAIL 18 Parse-BACKPAN-Packages-0.330.2808 PASS 8 Parse-BACKPAN-Packages-0.330.2808_03 FAIL 1 DUNNO Template-Plugin-Class-0.13 0.2808 FAIL 6 Template-Plugin-Class-0.13 0.2808 PASS 55 Template-Plugin-Class-0.13 0.2808_03 FAIL 1 DUNNO Test-Group-0.120.2808 PASS 47 Test-Group-0.120.2808_03 FAIL 1 A WHOAA THERE, that seems to indicate that something's wrong. But as I explained in the previous mail, this is due to Test-Simple dev release. Test-JSON-0.06 0.2808 FAIL 15 Test-JSON-0.06 0.2808 PASS 44 Test-JSON-0.06 0.2808_03 FAIL 1 A DUNNO again. So to sum up, we have found that two of the ten support the view that _03 is doing fine, one appears to be against but is proved wrong, so seven remaining are simply DUNNOs that we can ignore because they do not indicate that we have to doubt. Did you chase-down several of those? No. Are you saying that having some fail on 0.2808 implies that some fail on 0.2808_03 means no regression, or did you manage to somehow correlate the 0.2808_03 fails to the same machines sending 0.2808 fails? As explained above, I used judgement. If somebody with strong statistics fu can measure the trustworthyness of the data in fovor of a releasse, please speak up. 2. Where are these reports coming from? I have said it, I have (well, CPAN::Testers::ParseReport has) downloaded 56000 reports from http://www.nntp.perl.org/group/perl.cpan.testers/ Again, the subject of false fails: I would hate for testers to be pummelling other authors with alpha M::B errors while the M::B maintainers are left blissfully ignorant. plug Toolchain maintainers will probably want to use ctgetreports which comes with CPAN::Testers::ParseReport. /plug If dev releases pummel other authors it's a call for better tests. If your tests are good, then release early, release often and watch the results on cpantesters. The point of cpantesters for toolchain modules: they may not only watch their own but all test results where they might be involved. -- andreas
Re: use Test::More no_plan = $plan;
On Tue, 9 Sep 2008 09:00:54 +0200, Aristotle Pagaltzis [EMAIL PROTECTED] said: * Michael G Schwern [EMAIL PROTECTED] [2008-09-09 08:15]: I was surprised to get a few hundred results Note that CodeSearch indexes tarballs, so there are likely to be a lot of dupes. But even so, a cautious estimate would still put that at at least several dozen unique hits, so it’s not quite an “I broke CPAN”-level problem, but it’s still significant. It's definitely the 'I broke CPAN' level. My smoker has 260 fails more than usually. -- andreas
Re: use Test::More no_plan = $plan;
Ovid wrote: --- On Tue, 9/9/08, Michael G Schwern [EMAIL PROTECTED] wrote: The nice thing about having a central package repository with such a strong gravity as CPAN does is that it enables tandem upgrades of dependent code when APIs change incompatibly. So jealous of OS vendors for having this ability over the entire environment. *wistful sigh* Careful. You keep talking like that and Bob Nimby will write a scathing email telling you that since he doesn't need it, neither does anyone else. Well maybe I don't need Bob Nimby. Who's Bob Nimby? -- I have a date with some giant cartoon robots and booze.
Re: use Test::More no_plan = $plan;
--- On Tue, 9/9/08, Michael G Schwern [EMAIL PROTECTED] wrote: Careful. You keep talking like that and Bob Nimby will write a scathing email telling you that since he doesn't need it, neither does anyone else. Well maybe I don't need Bob Nimby. Who's Bob Nimby? No one. 'Bob' is a generic name. Nimby refers to NIMBY -- Not In My BackYard -- the selfish habit of people who shut down needed works because they're personally inconvenienced. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: use Test::More no_plan = $plan;
* Ovid [EMAIL PROTECTED] [2008-09-09 12:00]: --- On Tue, 9/9/08, Michael G Schwern [EMAIL PROTECTED] wrote: Who's Bob Nimby? No one. 'Bob' is a generic name. Nimby refers to NIMBY -- Not In My BackYard -- the selfish habit of people who shut down needed works because they're personally inconvenienced. OK, this just took a turn to the weird and now I’m lost. What did you mean by your previous reply? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
* Andreas J. Koenig [EMAIL PROTECTED] [2008-09-09 11:25]: It's definitely the 'I broke CPAN' level. My smoker has 260 fails more than usually. Due to this particular issue? Anyway, the biggest “I broke CPAN” event I remember involved failures cascading to some 15× as many distributions – literally more than half of the CPAN. This one isn’t nearly as bad, even if it’s more than bad enough. Good thing it’s a dev release, eh? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: use Test::More no_plan = $plan;
--- On Tue, 9/9/08, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: Who's Bob Nimby? No one. 'Bob' is a generic name. Nimby refers to NIMBY -- Not In My BackYard -- the selfish habit of people who shut down needed works because they're personally inconvenienced. OK, this just took a turn to the weird and now I’m lost. What did you mean by your previous reply? Sorry, I guess I should have been more explicit. I thought it was perfectly clear, but when the two replies are huh?, then obviously I've dropped the ball :) Is NIMBY just an American term? That would explain the confusion. Basically, there are quite a number of times when a particular project needs more work to support needs that some people have, but by no means all. I completely understand why people say I don't need X because I do Y. There's nothing wrong with that and it's often very helpful. However, *some* of those people following it up with something along the lines of and therefore you don't need X and I object if you add it. That really frosts my Pop-Tart (tm) because it's often blatantly not true. I remember an old argument in a pub where someone told me that anyone who wanted Test::Harness::GUI was an idiot because the command line was all anyone needs (sigh). (Anyone remember the Joel Spolsky article where he talks about 10% of MS Word features -- seemed that's all everyone needed, but everyone needed a different 10%) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: use Test::More no_plan = $plan;
Andreas J. Koenig wrote: On Tue, 9 Sep 2008 09:00:54 +0200, Aristotle Pagaltzis [EMAIL PROTECTED] said: * Michael G Schwern [EMAIL PROTECTED] [2008-09-09 08:15]: I was surprised to get a few hundred results Note that CodeSearch indexes tarballs, so there are likely to be a lot of dupes. But even so, a cautious estimate would still put that at at least several dozen unique hits, so it’s not quite an “I broke CPAN”-level problem, but it’s still significant. It's definitely the 'I broke CPAN' level. My smoker has 260 fails more than usually. I've uploaded a new alpha to deal with this. -- 31. Not allowed to let sock puppets take responsibility for any of my actions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Sub::Uplevel vs Test::More
Andreas J. Koenig wrote: On Tue, 09 Sep 2008 05:03:25 -0700, Michael G Schwern [EMAIL PROTECTED] said: I've uploaded a new alpha to deal with this. It still breaks Sub::Uplevel. Sub::Uplevel has lots of dependencies. I won't smoke a Test-Simple that breaks Sub-Uplevel. Or if the fault is on Sub-Uplevel, please let David Golden know. I'm pretty sure I have reported this recently. Have I not? Not that I'm aware of. I presume you mean this? t/05_honor_prior_override1/7 # Failed test 'use Sub::Uplevel;' # at t/05_honor_prior_override.t line 53. # Tried to use 'Sub::Uplevel'. # Error: Global symbol $VERSION requires explicit package name at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 5. # Global symbol $VERSION requires explicit package name at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 6. # Global symbol $VERSION requires explicit package name at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 6. # Global symbol @ISA requires explicit package name at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 17. # Global symbol @EXPORT requires explicit package name at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 18. # BEGIN not safe after errors--compilation aborted at /private/var/local/cpan_shell/build/Sub-Uplevel-0.19_03-JKkppY/blib/lib/Sub/Uplevel.pm line 89. # Compilation failed in require at (eval 4) line 2. # BEGIN failed--compilation aborted at (eval 4) line 2. Number found where operator expected at t/05_honor_prior_override.t line 68, near uplevel 1 (Do you need to predeclare uplevel?) Name main::uplevel used only once: possible typo at t/05_honor_prior_override.t line 68. Name DB::single used only once: possible typo at t/05_honor_prior_override.t line 16. # Failed test 'caller from uplevel subroutine calls custom routine' # at t/05_honor_prior_override.t line 84. # got: 'CODE(0x1801d08)' # expected: 'niam' # Looks like you failed 2 tests of 7. t/05_honor_prior_override Dubious, test returned 2 (wstat 512, 0x200) Failed 2/7 subtests Taking a knife to CORE::caller() and then calling someone else's functions and expecting them to work is not a good idea. After some poking around, the test fails because use vars depends on caller() and caller() is bleeding on the floor. It used to work because Test::More happened to load vars.pm before caller() got the knife. Now it doesn't, it uses our(). So this is definitely fixage, the test should never have worked. The goal of the test seems to be to detect that a customized caller() routine is not blown away by Sub::Uplevel. A much safer way to do that is to have your customized caller() just flick a file-scoped variable when it gets called and look for that change. -- The mind is a terrible thing, and it must be stopped.
Re: Sub::Uplevel vs Test::More
On Tuesday 09 September 2008 15:10:13 Michael G Schwern wrote: The goal of the test seems to be to detect that a customized caller() routine is not blown away by Sub::Uplevel. A much safer way to do that is to have your customized caller() just flick a file-scoped variable when it gets called and look for that change. That sounds relatively thread unsafe (or have I written too much C code lately?). -- c
Re: Sub::Uplevel vs Test::More
On Tue, Sep 9, 2008 at 6:20 PM, chromatic [EMAIL PROTECTED] wrote: On Tuesday 09 September 2008 15:10:13 Michael G Schwern wrote: The goal of the test seems to be to detect that a customized caller() routine is not blown away by Sub::Uplevel. A much safer way to do that is to have your customized caller() just flick a file-scoped variable when it gets called and look for that change. That sounds relatively thread unsafe (or have I written too much C code lately?). He's talking about doing it in a test -- so I think it's fine. That said, the idea of mixing Sub::Uplevel and threads puts chills up my spine. -- David
Re: Sub::Uplevel vs Test::More
On Tue, Sep 9, 2008 at 6:10 PM, Michael G Schwern [EMAIL PROTECTED] wrote: Taking a knife to CORE::caller() and then calling someone else's functions and expecting them to work is not a good idea. The problem is that we want Sub::Uplevel to do what people expect if they have already taken a knife to CORE::caller for some stupid reason, since nothing in Perl stops them from doing so. After some poking around, the test fails because use vars depends on caller() and caller() is bleeding on the floor. It used to work because Test::More happened to load vars.pm before caller() got the knife. Now it doesn't, it uses our(). Looks like this is fixable in Sub::Uplevel just by avoiding vars. Since Schwern has declared 5.005 dead and the toolchain is moving on, I'll convert to our as well and make 5.006 a requirement. New release coming soon. -- David
Re: use Test::More no_plan = $plan;
On Tue, 09 Sep 2008 05:03:25 -0700, Michael G Schwern [EMAIL PROTECTED] said: I've uploaded a new alpha to deal with this. It still breaks Sub::Uplevel. Sub::Uplevel has lots of dependencies. I won't smoke a Test-Simple that breaks Sub-Uplevel. Or if the fault is on Sub-Uplevel, please let David Golden know. I'm pretty sure I have reported this recently. Have I not? -- andreas
Re: Sub::Uplevel vs Test::More
David Golden wrote:
On Tue, Sep 9, 2008 at 6:10 PM, Michael G Schwern [EMAIL PROTECTED] wrote:
Taking a knife to CORE::caller() and then calling someone else's functions
and
expecting them to work is not a good idea.
The problem is that we want Sub::Uplevel to do what people expect if
they have already taken a knife to CORE::caller for some stupid
reason, since nothing in Perl stops them from doing so.
Indeed, but that doesn't mean you need to wave a knife around in your tests.
It can be simulated just fine with a working caller() that increments a
variable.
After some poking around, the test fails because use vars depends on
caller() and caller() is bleeding on the floor. It used to work because
Test::More happened to load vars.pm before caller() got the knife. Now it
doesn't, it uses our().
Looks like this is fixable in Sub::Uplevel just by avoiding vars.
Since Schwern has declared 5.005 dead and the toolchain is moving on,
I'll convert to our as well and make 5.006 a requirement.
[Slow motion leap towards the time bomb] N!
With caller() broken, anything that Sub::Uplevel uses which depends on it
working may fail. This includes core dependencies, like Exporter which works
here only because Test::More loads it before caller() gets scrambled. It's a
matter of time before some dependency changes what loads again and the test
fails.
You can see it all go wrong again by cutting out Test::More.
$ cat ~/tmp/bug.plx
sub _reverse_caller(;$) {
my $height = $_[0];
my @caller = CORE::caller(++$height);
$caller[0] = reverse $caller[0];
if( wantarray and [EMAIL PROTECTED] ) {
return @caller[0..2];
}
elsif (wantarray) {
return @caller;
}
else {
return $caller[0];
}
}
BEGIN {
my $old_W = $^W;
$^W = 0;
*CORE::GLOBAL::caller = \_reverse_caller;
$^W = $old_W;
}
use Sub::Uplevel;
uplevel(0, sub { print caller });
$ perl -Ilib ~/tmp/bug.plx
Undefined subroutine main::uplevel called at /Users/schwern/tmp/bug.plx line
26.
And that's after I replaced all the uses of vars.pm with our().
--
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer
Re: use Test::More no_plan = $plan;
On Tue, 9 Sep 2008 12:51:02 +0200, Aristotle Pagaltzis [EMAIL PROTECTED] said: * Andreas J. Koenig [EMAIL PROTECTED] [2008-09-09 11:25]: It's definitely the 'I broke CPAN' level. My smoker has 260 fails more than usually. Due to this particular issue? I have not checked but I have no doubt. There was nothing spectacular else afaics. Anyway, the biggest “I broke CPAN” event I remember involved failures cascading to some 15× as many distributions – literally more than half of the CPAN. This one isn’t nearly as bad, even if it’s more than bad enough. Good thing it’s a dev release, eh? Absolutely! I wish I had expressed my gratitude for getting dev releases again. Thank you, Schwern, sorry for being grumpy this morning. -- andreas
Re: Sub::Uplevel vs Test::More
On Tue, Sep 9, 2008 at 8:51 PM, Michael G Schwern [EMAIL PROTECTED] wrote: David Golden wrote: The problem is that we want Sub::Uplevel to do what people expect if they have already taken a knife to CORE::caller for some stupid reason, since nothing in Perl stops them from doing so. Indeed, but that doesn't mean you need to wave a knife around in your tests. It can be simulated just fine with a working caller() that increments a variable. That's a good point. I'll go make that change now. Since Schwern has declared 5.005 dead and the toolchain is moving on, I'll convert to our as well and make 5.006 a requirement. [Slow motion leap towards the time bomb] N! Heh. You planted that bomb, dude. Any excuse I have to bump things to 5.006 I've been taking and saying because Schwern says so. (CPAN::Reporter and deps are probably the exception and only because Slaven has sent me so many patches that I feel I owe it to him to support his Quixotic mission to smoke 5.005.) Certainly, I'd have a higher CPANTS score if I could start adding use warnings to my code. ;-) -- David
