Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 24 Apr 2006, at 15:51, Shlomi Fish wrote: [snip] Am I missing something or isn't that what Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can extract a class out of Test::Run::Straps that will provide a reusable TAP parser. [snip] In addition to Michael's and chromatic's points, the T::H::S API is oriented around getting the results of a successful parse, while I would prefer a more event-based model for some purposes (do Foo when you test failure - where Foo might involve stopping early). Adrian
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
chromatic wrote: On Sunday 23 April 2006 15:46, Michael Peters wrote: How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. That's exactly what I want and precisely why I think a well-defined TAP is more important than a plugin system for any particular harness. Hear hear. Personally, I don't even WANT the harness output, or even the harness (or at least, the result tracking functionality), I just want to run the tests, capture the TAP and then deal with it on an as-needed basis elsewhere. Adam K
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. And of course, we also need TAP::SAX :) Sort of a funny, but it probably should be written, since SAX is a nice standardised event model with plenty of existing code. (hence Perl::SAX and Pod::SAX et al). Adam K
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. I'm not attached to percentages, which I wasn't looking at anyway, but when several tests fail, the header is repeated for each test. Failed Test Stat Wstat Total Fail List of Failed ---
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 23 Apr 2006, at 20:05, Shlomi Fish wrote: [snip] This debate demonstrates why a plugin system is necessary for a test harness. If it has it, then one can write a plugin to control whether or not percentages are displayed. So for example, you can install a plugin that does that, and put this in your .bash_profile: [snip] That's not the issue for me. I can already write my own test runners without too much effort. For me the issue is why we're removing a useful (to a few people anyway), already implemented feature from the default test runner. Although I agree with Michael and chromatic that a separate TAP parser would be most pleasant. Cheers, Adrian
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Monday 24 April 2006 01:46, Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. Am I missing something or isn't that what Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can extract a class out of Test::Run::Straps that will provide a reusable TAP parser. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Shlomi Fish wrote: On Monday 24 April 2006 01:46, Michael Peters wrote: Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. Am I missing something or isn't that what Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can extract a class out of Test::Run::Straps that will provide a reusable TAP parser. It's close, but it's still a test harness first and foremost (even though it's pretty easy to subclass). If you extract out the TAP parsing portion into a separate module I think we'd be in good shape. It can be extremely useful to have the TAP parsing and test running separated out. Not only would this make it easier to have a harness look for something other than TAP (maybe some other protocol from some other language) but it also means I can parse test runs after they've been run on a completely different machine even. -- Michael Peters Developer Plus Three, LP
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Monday 24 April 2006 07:56, Michael Peters wrote: Not only would this make it easier to have a harness look for something other than TAP (maybe some other protocol from some other language) but it also means I can parse test runs after they've been run on a completely different machine even. Ian and I wrote about this in the Perl Testing book. I don't see the sample code online for some reason, but it's in chapter 3. -- c
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:34:12AM +0200, Marcus Holland-Moritz wrote:
On 2006-04-23, at 02:26:54 -0700, Yitzchak Scott-Thoennes wrote:
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
No, it wouldn't.
[EMAIL PROTECTED] $ head -n 5 Makefile.PL
use 5.004_05;
use ExtUtils::MakeMaker;
use ExtUtils::Command qw( touch rm_f );
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
syntax error at Makefile.PL line 1, near use 5.004_05
Execution of Makefile.PL aborted due to compilation errors.
Which version is this? perlfunc for perl 5.003_07 claims use VERSION
works.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 23 Apr 2006, at 07:02, Andy Lester wrote: [snip] I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. [snip] I'll just repeat what I left on Andy's blog here in case anybody agrees with me. I don't like the change myself. I'm bright enough to figure out that anything less than 100% pass is bad when developing. When using other peoples test suites seeing, for example, 99% ok tells me something very different from seeing 3% ok. For me the difference between nearly there apart form this bit of functionality that I don't care about and completely f**ked is useful. Yes I can figure it out from the test/pass numbers - but the percentage gives me a handy overview. Math is hard! :-) Not something I feel /that/ strongly about - but I don't see the utility of the change myself (beyond code simplification in T::H). (probably just me :-) Adrian
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, 23 Apr 2006 12:07:18 +0100, Adrian Howard [EMAIL PROTECTED] wrote: On 23 Apr 2006, at 07:02, Andy Lester wrote: [snip] I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. [snip] I'll just repeat what I left on Andy's blog here in case anybody agrees with me. I don't like the change myself. I'm bright enough to figure out that anything less than 100% pass is bad when developing. When using other peoples test suites seeing, for example, 99% ok tells me something very different from seeing 3% ok. For me the difference between nearly there apart form this bit of functionality that I don't care about and completely f**ked is useful. Yes I can figure it out from the test/pass numbers - but the percentage gives me a handy overview. Math is hard! :-) Not something I feel /that/ strongly about - but I don't see the utility of the change myself (beyond code simplification in T::H). (probably just me :-) I did not follow the rest of the conversation, but I strongly agree to the above statement. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, 11.23, SuSE 10.0, AIX 4.3 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 2006-04-23, at 01:02:00 -0500, Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. I've run it through a couple of my perls: Testing /tmp/perl/install/debug/perl5.004_05/bin/perl5.00405 .ok Testing /tmp/perl/install/default/perl5.004_05/bin/perl5.00405 ...ok Testing /tmp/perl/install/debug/perl5.005_01/bin/perl5.00501 .ok Testing /tmp/perl/install/debug/perl5.005_02/bin/perl5.00502 .ok Testing /tmp/perl/install/debug/perl5.005_03/bin/perl5.00503 .ok Testing /tmp/perl/install/debug/perl5.005_04/bin/perl5.00504 .ok Testing /tmp/perl/install/debug/perl5.005/bin/perl5.005 ..ok Testing /tmp/perl/install/default/perl5.005_01/bin/perl5.00501 ...ok Testing /tmp/perl/install/default/perl5.005_02/bin/perl5.00502 ...ok Testing /tmp/perl/install/default/perl5.005_03/bin/perl5.00503 ...ok Testing /tmp/perl/install/default/perl5.005_04/bin/perl5.00504 ...ok Testing /tmp/perl/install/default/perl5.005/bin/perl5.005 ok Testing /tmp/perl/install/thread/perl5.005_01/bin/perl5.00501 ok Testing /tmp/perl/install/thread/perl5.005_02/bin/perl5.00502 ok Testing /tmp/perl/install/thread/perl5.005_03/bin/perl5.00503 ok Testing /tmp/perl/install/thread/perl5.005_04/bin/perl5.00504 ok Testing /tmp/perl/install/thread/perl5.005/bin/perl5.005 .ok Testing /tmp/perl/install/debug/perl-5.6.0/bin/perl5.6.0 .ok Testing /tmp/perl/install/debug/perl-5.6.1/bin/perl5.6.1 .ok Testing /tmp/perl/install/debug/perl-5.6.2/bin/perl5.6.2 .ok Testing /tmp/perl/install/debug/perl-5.7.0/bin/perl5.7.0 .ok Testing /tmp/perl/install/debug/perl-5.7.1/bin/perl5.7.1 .ok Testing /tmp/perl/install/debug/perl-5.7.2/bin/perl5.7.2 .ok Testing /tmp/perl/install/debug/perl-5.7.3/bin/perl5.7.3 .ok Testing /tmp/perl/install/debug/perl-5.8.0/bin/perl5.8.0 .ok Testing /tmp/perl/install/debug/perl-5.8.1/bin/perl5.8.1 .ok Testing /tmp/perl/install/debug/perl-5.8.2/bin/perl5.8.2 .ok Testing /tmp/perl/install/debug/perl-5.8.3/bin/perl5.8.3 .ok Testing /tmp/perl/install/debug/perl-5.8.4/bin/perl5.8.4 .ok Testing /tmp/perl/install/debug/perl-5.8.5/bin/perl5.8.5 .ok Testing /tmp/perl/install/debug/perl-5.8.6/bin/perl5.8.6 .ok Testing /tmp/perl/install/debug/perl-5.8.7/bin/perl5.8.7 .ok Testing /tmp/perl/install/debug/perl-5.8.8/bin/perl5.8.8 .ok Testing /tmp/perl/install/debug/perl-5.9.0/bin/perl5.9.0 .ok Testing /tmp/perl/install/debug/perl-5.9.1/bin/perl5.9.1 .ok Testing /tmp/perl/install/debug/perl-5.9.2/bin/perl5.9.2 .ok Testing /tmp/perl/install/debug/perl-5.9.3/bin/perl5.9.3 .ok Testing /tmp/perl/install/default/perl-5.6.0/bin/perl5.6.0 ...ok Testing /tmp/perl/install/default/perl-5.6.1/bin/perl5.6.1 ...ok Testing /tmp/perl/install/default/perl-5.6.2/bin/perl5.6.2 ...ok Testing /tmp/perl/install/default/perl-5.7.0/bin/perl5.7.0 ...ok Testing /tmp/perl/install/default/perl-5.7.1/bin/perl5.7.1 ...ok Testing /tmp/perl/install/default/perl-5.7.2/bin/perl5.7.2 ...ok Testing /tmp/perl/install/default/perl-5.7.3/bin/perl5.7.3 ...ok Testing /tmp/perl/install/default/perl-5.8.0/bin/perl5.8.0 ...ok Testing /tmp/perl/install/default/perl-5.8.1/bin/perl5.8.1 ...ok Testing /tmp/perl/install/default/perl-5.8.2/bin/perl5.8.2 ...ok Testing /tmp/perl/install/default/perl-5.8.3/bin/perl5.8.3 ...ok Testing /tmp/perl/install/default/perl-5.8.4/bin/perl5.8.4 ...ok Testing /tmp/perl/install/default/perl-5.8.5/bin/perl5.8.5 ...ok Testing /tmp/perl/install/default/perl-5.8.6/bin/perl5.8.6 ...ok Testing /tmp/perl/install/default/perl-5.8.7/bin/perl5.8.7 ...ok Testing /tmp/perl/install/default/perl-5.8.8/bin/perl5.8.8 ...ok Testing /tmp/perl/install/default/perl-5.9.0/bin/perl5.9.0 ...ok Testing /tmp/perl/install/default/perl-5.9.1/bin/perl5.9.1 ...ok Testing /tmp/perl/install/default/perl-5.9.2/bin/perl5.9.2 ...ok Testing /tmp/perl/install/default/perl-5.9.3/bin/perl5.9.3 ...ok Testing /tmp/perl/install/thread5005/perl-5.6.0/bin/perl5.6.0 ok Testing /tmp/perl/install/thread5005/perl-5.6.1/bin/perl5.6.1 ok Testing /tmp/perl/install/thread5005/perl-5.6.2/bin/perl5.6.2 ok Testing /tmp/perl/install/thread5005/perl-5.7.0/bin/perl5.7.0 ok Testing /tmp/perl/install/thread5005/perl-5.7.1/bin/perl5.7.1 ok Testing /tmp/perl/install/thread5005/perl-5.7.2/bin/perl5.7.2 ok Testing /tmp/perl/install/thread5005/perl-5.7.3/bin/perl5.7.3 ok Testing /tmp/perl/install/thread5005/perl-5.8.0/bin/perl5.8.0 ok Testing /tmp/perl/install/thread5005/perl-5.8.1/bin/perl5.8.1 ok Testing /tmp/perl/install/thread5005/perl-5.8.2/bin/perl5.8.2 ok Testing
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 2006-04-23, at 02:49:14 -0700, Yitzchak Scott-Thoennes wrote:
On Sun, Apr 23, 2006 at 11:34:12AM +0200, Marcus Holland-Moritz wrote:
On 2006-04-23, at 02:26:54 -0700, Yitzchak Scott-Thoennes wrote:
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
No, it wouldn't.
[EMAIL PROTECTED] $ head -n 5 Makefile.PL
use 5.004_05;
use ExtUtils::MakeMaker;
use ExtUtils::Command qw( touch rm_f );
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
syntax error at Makefile.PL line 1, near use 5.004_05
Execution of Makefile.PL aborted due to compilation errors.
Which version is this?
It's 5.003.
Summary of my perl5 (5.0 patchlevel 3 subversion 0) configuration:
Platform:
osname=linux, osver=2.6.15.1, archname=i686-linux
uname='linux gandalf 2.6.15.1 #2 preempt mon feb 6 22:08:36 met 2006 i686
intel(r) pentium(r) 4 cpu 1.80ghz genuineintel gnulinux '
hint=recommended, useposix=true, d_sigaction=define
Compiler:
cc='cc', optimize='-O2', gccversion=3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0,
pie-8.7.8)
cppflags='-Dbool=char -DHAS_BOOL'
ccflags ='-Dbool=char -DHAS_BOOL'
stdchar='char', d_stdstdio=, usevfork=false
voidflags=15, castflags=0, d_casti32=define, d_castneg=define
intsize=4, alignbytes=4, usemymalloc=n, randbits=31
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt
libc=/lib/libc.so.6, so=so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
@INC: /tmp/perl/install/default/perl5.003/lib/i686-linux/5.003
/tmp/perl/install/default/perl5.003/lib
/tmp/perl/install/default/perl5.003/lib/site_perl/i686-linux
/tmp/perl/install/default/perl5.003/lib/site_perl .
perlfunc for perl 5.003_07 claims use VERSION works.
perlfunc for 5.003 doesn't mention it:
use Module LIST
use Module
Imports some semantics into the current package from the named
module, generally by aliasing certain subroutine or variable
names into your package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
The BEGIN forces the require and import to happen at compile
time. The require makes sure the module is loaded into memory
if it hasn't been yet. The import is not a builtin--it's just
an ordinary static method call into the Module package to
tell the module to import the list of features back into the
current package. The module can implement its import method
any way it likes, though most modules just choose to derive
their import method via inheritance from the Exporter class
that is defined in the Exporter module. See Exporter.
If you don't want your namespace altered, explicitly supply an
empty list:
use Module ();
That is exactly equivalent to
BEGIN { require Module; }
Because this is a wide-open interface, pragmas (compiler direc-
tives) are also implemented this way. Currently implemented
pragmas are:
use integer;
use diagnostics;
use sigtrap qw(SEGV BUS);
use strict qw(subs vars refs);
use subsqw(afunc blurfl);
These pseudomodules import semantics into the current block
scope, unlike ordinary modules, which import symbols into the
current package (which are effective through the end of the
file).
There's a corresponding no command that unimports meanings
imported by use.
no integer;
no strict 'refs';
See perlmod for a list of standard modules and pragmas.
Marcus
--
If I had only known, I would have been a locksmith.
-- Albert Einstein
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 2006-04-23, at 02:26:54 -0700, Yitzchak Scott-Thoennes wrote:
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
The only thing worth mentioning is that with perl 5.003,
the following happens:
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time require VERSION is almost always the wrong thing to do.
I'd suggest the following change:
--- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
+++ Makefile.PL 2006-04-23 10:58:50.0 +0200
@@ -1,4 +1,4 @@
-require 5.004_05;
+BEGIN { require 5.004_05 }
use 5.004_05; would be better.
No, it wouldn't.
[EMAIL PROTECTED] $ head -n 5 Makefile.PL
use 5.004_05;
use ExtUtils::MakeMaker;
use ExtUtils::Command qw( touch rm_f );
[EMAIL PROTECTED] $ perl5.003 Makefile.PL
syntax error at Makefile.PL line 1, near use 5.004_05
Execution of Makefile.PL aborted due to compilation errors.
Marcus
--
Statistics means never having to say you're certain.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On 4/23/06, H.Merijn Brand [EMAIL PROTECTED] wrote: On Sun, 23 Apr 2006 12:07:18 +0100, Adrian Howard [EMAIL PROTECTED] wrote: On 23 Apr 2006, at 07:02, Andy Lester wrote: [snip] I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. [snip] I'll just repeat what I left on Andy's blog here in case anybody agrees with me. I don't like the change myself. I'm bright enough to figure out that anything less than 100% pass is bad when developing. When using other peoples test suites seeing, for example, 99% ok tells me something very different from seeing 3% ok. For me the difference between nearly there apart form this bit of functionality that I don't care about and completely f**ked is useful. Yes I can figure it out from the test/pass numbers - but the percentage gives me a handy overview. Math is hard! :-) Not something I feel /that/ strongly about - but I don't see the utility of the change myself (beyond code simplification in T::H). (probably just me :-) I did not follow the rest of the conversation, but I strongly agree to the above statement. Fwiw, me too. -- perl -Mre=debug -e /just|another|perl|hacker/
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 15:08, H.Merijn Brand wrote: On Sun, 23 Apr 2006 12:07:18 +0100, Adrian Howard [EMAIL PROTECTED] wrote: On 23 Apr 2006, at 07:02, Andy Lester wrote: [snip] I've removed the meaningless percentages of tests that have failed. If you rely on the output at the end, it's different now. [snip] I'll just repeat what I left on Andy's blog here in case anybody agrees with me. I don't like the change myself. I'm bright enough to figure out that anything less than 100% pass is bad when developing. When using other peoples test suites seeing, for example, 99% ok tells me something very different from seeing 3% ok. For me the difference between nearly there apart form this bit of functionality that I don't care about and completely f**ked is useful. Yes I can figure it out from the test/pass numbers - but the percentage gives me a handy overview. Math is hard! :-) Not something I feel /that/ strongly about - but I don't see the utility of the change myself (beyond code simplification in T::H). (probably just me :-) I did not follow the rest of the conversation, but I strongly agree to the above statement. This debate demonstrates why a plugin system is necessary for a test harness. If it has it, then one can write a plugin to control whether or not percentages are displayed. So for example, you can install a plugin that does that, and put this in your .bash_profile: export HARNESS_PLUGINS=ControlPercentage And then run: HARNESS_PERCENT=1 runprove t/*.t to see the percents, or HARNESS_PERCENT=0 runprove t/*.t to disable them. I might get to write such a plugin for Test::Run in the upcoming days. If so, I'll upload it to CPAN and announce it here. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. -- c
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 12:46, Shlomi Fish wrote: I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) No. Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? No, why should it? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? I don't believe that plugin systems reduce complexity in general. I do strongly believe in customization, but I remain unconvinced that plugins promote reuse and customization as strongly as, for example, roles and subclasses do. -- c
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 01:02:00AM -0500, Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. Tests pass. One not numeric warning: t/00compile.ok 1/6Argument 2.57_06 isn't numeric in subroutine entry at t/lib/Test/More.pm line 670 dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ Nothing makes me appreciate Perl more than malloc. - Andy Lester
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 01:02:00AM -0500, Andy Lester wrote:
I'm approaching the end of this release cycle. I really want to get
this released.
I've removed the meaningless percentages of tests that have failed.
If you rely on the output at the end, it's different now.
xoa
file: $CPAN/authors/id/P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
size: 69114 bytes
md5: 41efc0985146e4f7d678ec7cb9b59047
I have merged this in to blead with change 27940. (Because I want the speedup)
Specifically blead is now identical (Unless I messed up) which means that
this change got removed before I committed:
--- Test-Harness-2.57_06/lib/Test/Harness.pmSun Apr 23 06:53:11 2006
+++ perl/lib/Test/Harness.pmSun Apr 23 21:23:30 2006
@@ -38,7 +38,8 @@
=cut
-$VERSION = '2.57_06';
+$VERSION = 2.57_06;
+$VERSION = eval $VERSION;
# Backwards compatibility for exportable variable names.
*verbose = *Verbose;
And this change did get committed:
//depot/perl/lib/Test/Harness/t/version.t#2 -
/home/nick/p4perl/perl/lib/Test/Harness/t/version.t
--- /tmp/tmp.27775.0Sun Apr 23 21:25:55 2006
+++ /home/nick/p4perl/perl/lib/Test/Harness/t/version.t Sun Apr 23 21:23:28 2006
@@ -19,5 +19,5 @@ BEGIN {
}
my $ver = $ENV{HARNESS_VERSION} or die HARNESS_VERSION not set;
-like( $ver, qr/^2.\d\d(_?\d\d)?$/, Version is proper format );
+ok( $ver =~ /^2.\d\d(_\d\d)?$/, Version is proper format );
is( $ver, $Test::Harness::VERSION );
Note that I removed the ? from the _ inside the regexp, which was added
in http://public.activestate.com/cgi-bin/perlbrowse?patch=27925
I felt it better to get the code perfectly in sync than to preserve minor
recent (possible) fixes and have to keep track of the fork.
Nicholas Clark
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 23:11, chromatic wrote: On Sunday 23 April 2006 12:46, Shlomi Fish wrote: I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) No. I see. Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? No, why should it? I meant that writing several test harnesses would imply that. It was a semi-rhetoric question. Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? I don't believe that plugin systems reduce complexity in general. I do strongly believe in customization, but I remain unconvinced that plugins promote reuse and customization as strongly as, for example, roles and subclasses do. I see. Well the final conclusion remains the same: we still need a good test harness that we should be able to customise using roles, subclasses, plug-ins or whatever. I still don't see where the well-definition of the test output protocol has anything to do with this issue. How would a well-defined test output protocol help with making the test harness customisable? Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Moin, On Sunday 23 April 2006 23:08, Shlomi Fish wrote: On Sunday 23 April 2006 23:11, chromatic wrote: On Sunday 23 April 2006 12:46, Shlomi Fish wrote: I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) I see. Well the final conclusion remains the same: we still need a good test harness that we should be able to customise using roles, subclasses, plug-ins or whatever. I still don't see where the well-definition of the test output protocol has anything to do with this issue. How would a well-defined test output protocol help with making the test harness customisable? Because instead of ever-changing text output (in various formatting), you might have XML (or whatever), that is transformed for output. Then you can have it display %, or not, in color or not, or in HTML or whatever. The current screenscraping really really has problems everytime the output changes. Best wishes, Tels -- Signed on Mon Apr 24 00:08:25 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Any sufficiently rigged demo is indistinguishable from an advanced technology. -- Don Quixote, slashdot guy pgpLrboNmb1M1.pgp Description: PGP signature
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
Shlomi Fish wrote: On Sunday 23 April 2006 22:35, chromatic wrote: On Sunday 23 April 2006 12:05, Shlomi Fish wrote: This debate demonstrates why a plugin system is necessary for a test harness. No, it demonstrates why a well-defined test output protocol is useful. I agree that a well-defined test output protocol is useful. However, are you implying that assuming we have that, one can write several different test harnesses to process such test outputs? (I'm just guessing.) Wouldn't that imply duplicate code, duplicate functionality and/or duplicate effort? Shouldn't we try to avoid that by making sure that we have one *good* test harness codebase that can be customised using plug-ins, and extensions? How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. -- Michael Peters Developer Plus Three, LP
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sunday 23 April 2006 15:46, Michael Peters wrote: How about a good TAP parser module that does nothing but parse TAP. Then it could be used in all kinds of test harness permutations. That's exactly what I want and precisely why I think a well-defined TAP is more important than a plugin system for any particular harness. -- c
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
David H. Adler wrote:
Tests pass. One not numeric warning:
t/00compile.ok 1/6Argument 2.57_06 isn't numeric in subroutine
entry at t/lib/Test/More.pm line 670
This is the same warning I reported in an earlier message:
http://groups.google.com/group/perl.qa/msg/fee69dde25cf42ec
Given the wise counsel of a former Phalanx strategos (every warning
your test suite throws is a bug which must be tracked down), I spent
several hours looking at this this morning. To cut to the chase, it
will go away once v2.58 is uploaded to CPAN. If my analysis is correct,
it only occurs when a module author uses a version number containing an
underscore and when that is assigned as a *string* rather than a number
to the module's $VERSION.
More detailed explanation follows.
The test which is throwing the warning is the last test in t/00compile.t:
BEGIN { use_ok 'Test::Harness', 1.1601 }
Andy's test suite, apparently for reasons of backwards compatibility, is
testing against v0.42 of Test::More, which is included beneath the
t/lib/ directory. In v0.42, when use_ok is called with a version number
as the second argument, Test::Harness::import is called. Since
Test::Harness doesn't define an import method, it's really
Exporter::import which is being called. Exporter::import, in this
particular case, calls, in turn, Exporter::export, which calls
Exporter::as_heavy, which calls Exporter::Heavy::heavy_export, which,
deep in its guts, calls its VERSION method ...
$pkg-VERSION($sym);
... which is really UNIVERSAL::VERSION which, if supplied with an
argument, assumes that the argument is a number to be compared with the
minimum version number needed. But if, way back at the top of the
chain, the module author says,
$VERSION = '2.57_06';
that 2.57_06 does not numerify, so the non-numeric argument warning
gets thrown.
Got that? (Take a deep breath.)
I experimented with several other ways of assigning to $VERSION. Each
of the three following ways ...
$VERSION = '2.5706';
$VERSION = 2.57_06;
$VERSION = 2.5706;
... avoids the non-numeric warning. The first case numerifies
correctly; the latter two already qualify as numbers in Perl. However,
each of these three cases fails the second test in Andy's t/version.t
file ...
ok( $ver =~ /^2.\d\d(_\d\d)?$/, Version is proper format );
which says that if there is anything after the hundredths place in the
version number, an underscore is mandatory. Relaxing this requirement ...
ok( $ver =~ /^2.\d\d(_?\d\d)?$/, Version is proper format );
... allows each of the three cases above to pass t/version.t and
simultaneously avoid the non-numeric warning.
Now, I believe I've read somewhere that assigning a string containing an
underscore to $VERSION is a way to tell the CPAN indexer to label this
particular version of a module as a developer's release. I suppose
someone could think of a different way of doing that that would not run
the risk of a non-numeric warning, but it's probably not important
enough to warrant many brain cycles.
But it raises the question of whether one should ever assign a string to
a module's $VERSION unless it were a string like a CVS version number.
I consulted the web versions of three relevant man pages:
http://perldoc.perl.org/perlmod.html#Perl-Modules-module
http://perldoc.perl.org/perlmodlib.html#Guidelines-for-Module-Creation
http://perldoc.perl.org/Exporter.html#Module-Version-Checking
Only the second of these pages gives an example where a non-CVS version
number is stringified before being assigned to $VERSION ...
$VERSION = 0.01
... but it doesn't provide a rationale for the stringification. The
other two pages suggest that, with the exception of CVS-type strings,
what should be assigned to $VERSION is what qualifies in Perl as a
number. (My own thinking is that I'll go back to using only numbers,
not stringified numbers, in my own modules, but this probably falls
somewhere between TMTOWTDI and YMMV.)
Jim Keenan
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
This is the same warning I reported in an earlier message: http:// groups.google.com/group/perl.qa/msg/fee69dde25cf42ec Given the wise counsel of a former Phalanx strategos (every warning your test suite throws is a bug which must be tracked down), I spent several hours looking at this this morning. To cut to the chase, it will go away once v2.58 is uploaded to CPAN. If my analysis is correct, it only occurs when a module author uses a version number containing an underscore and when that is assigned as a *string* rather than a number to the module's $VERSION. I'm sorry, I didn't mean for anyone to bother going to this trouble. I've always known what it was. It'll go away in the next version. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 04:14:01PM -0400, David H. Adler wrote: On Sun, Apr 23, 2006 at 01:02:00AM -0500, Andy Lester wrote: I'm approaching the end of this release cycle. I really want to get this released. Tests pass. One not numeric warning: Of course, I forgot to mention: Perl 5.8.8, OS X 10.4.6 . D'oha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ Perfect is the enemy of done! - Sean Burke
