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 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! -- Rocco Caputo rcap...@pobox.com
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: Task: Write a TAP v12 formatter for Test::Builder1.5
On 11/16/11 2:15 AM, Michael G Schwern wrote: That's the task. Write a TAP version 12 formatter. Should we proceed on the assumption that this specifies v12? http://testanything.org/wiki/index.php/TAP_specification ... and that this specifies v13? http://testanything.org/wiki/index.php/TAP_version_13_specification Thank you very much. Jim Keenan
Re: Task: Write a TAP v12 formatter for Test::Builder1.5
On 2011.11.16 4:19 PM, James E Keenan wrote: Should we proceed on the assumption that this specifies v12? http://testanything.org/wiki/index.php/TAP_specification ... and that this specifies v13? http://testanything.org/wiki/index.php/TAP_version_13_specification No, not for our purposes. YAML diagnostics are not implemented. I thought about it some more, and the v12/v13 split isn't what we're really going for here. Rather than calling it the v12 formatter, it should more properly be called the legacy or TB1 formatter. It's not so much about producing TAP v12 as it is replicating what Test::Builder currently outputs. I can break the issue into two parts. Write a v12 TAP formatter (really v12 this time). This will serve as an easy way to split the formatter into extensible pieces, as all the code currently lies in TAP::v13. This is really straightforward. https://github.com/schwern/test-more/issues/219 Write the legacy formatter as a subclass of TAP::v12. This mostly involves putting the strings TAP uses into attributes and making a subclass of TAP::v12 which changes those defaults. https://github.com/schwern/test-more/issues/215 -- 184. When operating a military vehicle I may *not* attempt something I saw in a cartoon. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Subtests work! New alpha imminent.
Subtests are now 100% operational in Test::Builder1.5. It slipped in place very nicely with the new event system, which makes me very happy, and it's much simpler than it used to be. The only vestige of the old system I had to retain was tracking TODO tests since that's still done in the Test::Builder object. Thank you Ovid and others for writing such excellent and comprehensive tests. Before the next alpha can go out, I just have to finish merging from master and do a handful of major class/method name changes so early adoptors don't get screwed again next alpha. https://github.com/schwern/test-more/issues?milestone=5 It looks like Jason Galea stepped up and did the refactorings. There's just one small one left. I'd appreciate a taker. https://github.com/schwern/test-more/issues/210 Then I can collapse with the flu while you all knock around the alpha. -- 170. Not allowed to defect to OPFOR during training missions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
