Re: The end of 5.6 is nigh!
On Wed, Nov 16, 2011 at 12:06 PM, Rocco Caputo rcap...@pobox.com wrote: On Nov 13, 2011, at 11:43, Zefram wrote: Reini Urban wrote: 5.6.2 still is the fastest perl around. Evidently it's important to you to get the wrong answer as quickly as possible. (Advice from Klortho #11912.) 4.036 would get you a wronger answer even faster! perl 4 still has the big global switch-based interpreter without the optree and optimizations on it. Ditch that. 5.6 is fast and almost never wrong compared to 5.14. With higher perls it is even much easier to get wrong results, because of more unexpected magic happening behind, more dependency bloat and less experienced hackers working on it. Module::Build is e.g. a prime example, where a native make replacement never got to the level of a make replacement, though it should have been possible with ~200 lines to get dependency handling in perl. This module still forces maintainers to drop 5.6. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: The end of 5.6 is nigh!
On Wed, Nov 16, 2011 at 12:06 PM, Rocco Caputo rcap...@pobox.com wrote: On Nov 13, 2011, at 11:43, Zefram wrote: Reini Urban wrote: 5.6.2 still is the fastest perl around. Evidently it's important to you to get the wrong answer as quickly as possible. (Advice from Klortho #11912.) 4.036 would get you a wronger answer even faster! perl 4 still has the big global switch-based interpreter without the optree and optimizations on it. Ditch that. 5.6 is fast and almost never wrong compared to 5.14. With higher perls it is even much easier to get wrong results, because of more unexpected magic happening behind, more dependency bloat and less experienced hackers working on it. Module::Build is e.g. a prime example, where a native make replacement never got to the level of a make replacement, though it should have been possible with ~200 lines to get dependency handling in perl. This module still forces maintainers to drop 5.6 and still is a major performance and feature hog. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: The end of 5.6 is nigh!
On Sat, Nov 12, 2011 at 5:50 PM, Michael G Schwern schw...@pobox.com wrote: It's that time again! Time when I hammer the last few nails in the coffin of a version of Perl. By which I mean, the next major release of Test::More (aka Test::Builder1.5) will support 5.8.1 and up. ExtUtils::MakeMaker will probably go that way, too. This effectively cuts off most of CPAN from 5.8.0 and down. This will happen in the next few months. Test::More might nudge its requirement a little higher depending on just how difficult it is to work around early threading bugs in the earlier 5.8 releases. At this point I don't imagine this will cause too much disruption. There aren't many serious 5.6 users left and whomever is left has to have already come up with some sort of 5.6PAN solution. Dropping 5.6 will ease maintenance and testing of these modules and make a greater baseline of core modules available. However, if a company or organization would like to see 5.6 compatibility retained, they can contact me about sponsoring the extra work for continued maintenance. Thanks to Sarathy and rgs for some great and long lived releases! It's been a good eight years. I've come around your hammering lately and had this idea: Cannot CPAN add logic to avoid downloading your new versions on older releases? This is for EUMM and now Test::Builder. 5.6.2 still is the fastest perl around. As long as you keep making it slower and fatter you have to come up with some kind of practical solution. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [RFC] Dual-lifing test.pl
Nicholas Clark schrieb: On Mon, Jun 30, 2008 at 12:54:29PM -0400, Jerry D. Hedden wrote: Jerry D. Hedden wrote: From what I can tell, there are well over a dozen dual-lived modules that incorporate test.pl into their distributions. Rather than continuing this trend, I would like to propose turning it into a module and dual-lifing it to CPAN. Nicholas Clark wrote: Why are they using it, rather than something built from Test::Builder? What does it offer that Test::Builder derived modules don't? Jerry D. Hedden wrote: In my case of dual-lifing threads, threads::shared, Thread::Queue and Thread::Semaphore, it was because the tests were already written to use test.pl. Thus, adding it to the distribution was easier than rewriting all the tests. But, logically, those tests in the modules in core can be re-written to not use it [if, see below] I would imagine that is also the case for the other dual-lived modules that use test.pl, but their maintainers could have other reasons. Anybody? Additionally, test.pl has certain functionality (e.g., fresh_perl() and watchdog()) not found in the Test::* modules. hence I think that a better solution would be to add just that code to a Test::Builder based module, either a new one, or an existing one if its maintainer is keen. +1 The core's test.pl is meant to be a subset of the Test::More functionality for core regression tests in t/* (distinct from tests in lib/* for modules shipped with core). To me it feels like scope creep if it also ends up dual- lived. It also means that we would have *two* core-supported test frameworks, which can't be used in the same test. I rather keep my own t/test.pl (with added run_cc_test() in B::C) than requiring another external module. If I want another external dependency I could just use Test::More. watchdog() is fine, but I better use alarm there. $ head -n2 t/test.pl # # t/test.pl - most of Test::More functionality without the fuss -- Reini Urban http://phpwiki.org/ http://murbreak.at/
