David Golden wrote:
I'll be getting into Oslo Friday mid-morning. Assuming no mishaps
finding the hotel, I'll be up for touring around Oslo on Friday
afternoon. If anyone from the hackathon has similar plans and is
interested in meeting up, please email and let me know. (And if any
locals
Eric brining up TAP meta information made me think of some more hackathon
topics.
Finish and implement the TAP meta information proposals. Everybody wants them.
http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Topics#TAP_Meta_Information
Revise the TAP specification, it's
[For folks who aren't aware, we just had an intense three day hackathon in
Oslo during which about a dozen of us tried to hash out new TAP extensions and
write some sort of well formed spec. We got a lot done, but didn't have quite
the clean resolution I was hoping for. Afterwards I had a
Ovid wrote:
--- Steffen Schwigon [EMAIL PROTECTED] wrote:
And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we want:
1. Make it as human-readable as possible.
2. Maximize flexibility.
As for human-readable,
David E. Wheeler wrote:
On Apr 13, 2008, at 10:41, Michael G Schwern wrote:
Two possible solutions:
A) Just reserve ASCII [a-z]. This is very easy to check for but I'm
worried it's carving out too small a space.
Why would it be too small? I mean, that's a *lot* of words you can use.
I
chromatic wrote:
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
Remember, the producer and the displayer of the non-reserved keys are both
under local user control. They choose the custom keys and they choose what
they need and can handle.
That sort of eliminates the upgrading
chromatic wrote:
On Wednesday 16 April 2008 22:57:21 David E. Wheeler wrote:
In principal I completely agree with you, chromatic (that is, I agree
with the principal you espouse here; my agreement is not purely
theoretical ;-)). But how does that work in practice? Specifically
with regard to
chromatic wrote:
We'd like folks to be able to add their own keys as they need without first
wondering whether it might be useful for others or worrying if we might add
a key of the same name, but different functionality, later. Thus the
separation of local from official keys.
This part I
chromatic wrote:
On Thursday 17 April 2008 16:17:48 Michael G Schwern wrote:
chromatic wrote:
We'd like folks to be able to add their own keys as they need without
first wondering whether it might be useful for others or worrying if we
might add a key of the same name, but different
Executive summary: User key collision is not a show stopper.
chromatic wrote:
On Thursday 17 April 2008 17:56:25 Michael G Schwern wrote:
We're working around the same issue Perl 5 is having adding new keywords.
In Perl 5, since keywords and user-defined subroutines share the same
space
chromatic wrote:
On Thursday 17 April 2008 19:10:21 Michael G Schwern wrote:
As for why it'll work with TAP, with a few exceptions (exit_status, or
whatever we decide to call it, is currently the only one), diagnostic keys
do not effect test parsing. It's not a show stopper. At worst
chromatic wrote:
If TAP v15 adds a
new reserved key, anyone who deliberately upgrades may need to modify
both the producer and consumer to deal with the collision, if that person
even cares.
I don't understand. There can be no collision. Official TAP keys all
start with a lower case letter.
David E. Wheeler wrote:
On Apr 18, 2008, at 10:50, chromatic wrote:
My argument was complex: solve the real problem or don't solve it.
The in
between position is silly and won't make anyone happy. (However, the
first
person to suggest RDF triples gets a lecture from *all* parties.)
Yes.
Chris Dolan wrote:
I'm not on the tap-l list (why is this cross-posted to perl-qa???)
We're trying to move discussion of TAP to a broader, non-perl audience, thus
the non-perl TAP mailing list. Since most TAP discussion has been on perl-qa,
and since many of the people interested in TAP are
Ovid wrote:
I'd like advice on how best to implement this.
Currently, because so many module authors thoughtfully break
$SIG{__DIE__}, I routinely find that things like this break:
ok $foo or die; # sometimes still exits with zero
# or simply doesn't exit
Is it
nadim khemir wrote:
I have had a problems with output when running tests, this happends, IE, when
perl output a warning.
warning_like
{
something() ;
} qr'Use of uninitialized value in substitution iterator' ;
I get the warning on the terminal which is boring when
These appear to all being due to the fact that Test::Harness does some very
specific tests of @INC and the environment which Devel::Cover changes. It's
not Devel::Cover's fault.
The below appear to be because Devel::Cover inserts its own blib into @INC and
the tests aren't wired to deal with
Smylers wrote:
Bram writes:
At the moment foo() returns 3.
Time passes and code changes.
Now there are 3 options:
foo() returns 1, this will result in 'unexpected todo test passed'
being outputted;
foo() returns 3, no special output is produced;
foo() returns 4, no special output is
Aristotle Pagaltzis wrote:
As a technique, paying attention to how broken code changes,
why does it matter that broken code breaks differently? What
does this information tell you that might fix code?
It means there is a known internal dependency on some other part
of the code that is not
As you may know, TPF funded my grant to rewrite Test::Builder to support the
new test library features people have been asking for over the last six or
seven years of it's life that it doesn't currently support well.
One of the first things I'd like to address is how I've handled the dev
Michael G Schwern wrote:
I've chosen Google Code because it does basically everything I want,
uses Subversion which we're used to, everything talks to and makes
importing the repo easy. Also I can just bother Andy Lester if I can't
figure anything out. :) The repository import is in progress
I don't remember if this escaped the Oslo Hackathon.
For a long time people have been complaining about Got as in Got vs
Expected (for, imho, fussy grammar reasons). Also expected is long and has
to be carefully lined up with got.
During the Oslo Hackathon we knocked this around some and
Heiko Eißfeldt wrote:
I had problems installing Test::Kwalitee 0.30 with the
latest Module::CPANTS::Analyse 0.82 under win xp/cygwin.
'perl ./Build test' gave
t/01-kwaliteeskipped: Test::Kwalitee not installed:
need a dist at
.../.cpan/build/Test-Kwalitee-0.30/blib/lib/
Gabor Szabo wrote:
Looking at this report I am not sure why does it fail and how to fix it
http://www.nntp.perl.org/group/perl.cpan.testers/2008/08/msg2041140.html
Besides, AFAIK PAR::Packer is not one of the prereqs of Padre so what are
these
messages regarding PAR::Packer?
Known
Ovid wrote:
One issue Salve raised is that the IETF apparently requires *physical*
meetings three times
a year. Short of people individually ponying up the money, this suggests
some form of
sponsorship. Anyone have any thoughts on this?
I roll to disbelieve.
It seems not like the IETF to
Ovid wrote:
One issue which arose at YAPC::EU was the problem with machine-readable TAP
diagnostics.
Since they're not yet implemented, we can change them. The problem we wound
up with was
that we have two things to specify: core TAP and extended TAP. Core TAP is
simple
(well, uh,
Ovid wrote:
--- On Mon, 18/8/08, Michael G Schwern [EMAIL PROTECTED] wrote:
YAML has several important things that JSON is lacking.
Without going into detail, I'll just say that you raise some valid points. I
agree with some and not with others, but we should defer this discussion
Ovid wrote:
--- On Tue, 19/8/08, Michael G Schwern [EMAIL PROTECTED] wrote:
I think we should start the process by specifying TAP
version 12 aka core TAP.
The stuff we all agree on and is in wide use. Extension
discussion should be
orthogonal so as not to stall the standardization
Jeffrey Thalhammer wrote:
At my current $job, the Perl code is organized into a handful of
cpan-style distros. We use Module::Build to build each distro, and then
use CPAN.pm to orchestrate the deployment of the application from a
local CPAN repository. This all works like a charm.
But
Ovid wrote:
Folks, this really, really needs to go to the IETF list.
What IETF list?
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
http://test-more.googlecode.com/files/Test-Simple-0.81_01.tar.gz
Before I start tearing up the guts of Test::Builder in earnest, I figure I
should get a last release out. Here's an alpha of Test::More with a bunch of
new little features and bug fixes, including...
* note() which is like diag()
Eric Wilhelm wrote:
# from H.Merijn Brand
# on Sunday 31 August 2008 03:35:
If I follow
http://module-build.sourceforge.net/META-spec-v1.3.html#recommends
optional_features:
- opt_csv:
...
...
And if I follow
http://module-build.sourceforge.net/META-spec-v1.3.html#recommends
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
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
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
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
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
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
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
Nicholas Clark wrote:
On Tue, Sep 09, 2008 at 10:12:24PM -0400, David Golden wrote:
(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
Eric Wilhelm wrote:
# from David Golden
# on Wednesday 10 September 2008 11:00:
If CPANTS can find the -w in the tests or whatever and the META.yml
says 5.6... (Because enabling warnings in *everyone else's* code is
a good way to placate a static kwalitee scanner?) I give up.
I don't
Barbie wrote:
The notification system will run once a day and collate a list of the
links to the reports via the web interface on the NNTP server. As such,
you will no longer receive huge reports in your inbox, but at most just
one email a day containing a list of links to your reports. You
Aristotle Pagaltzis wrote:
* David Golden [EMAIL PROTECTED] [2008-09-05 21:10]:
* After a period of time to allow people to opt-in, the default
policy for authors without a stated preference will be
changed to no mail.
From that point on, CPAN Testers will be a purely opt-in
David E. Wheeler wrote:
On Sep 11, 2008, at 14:17, Michael G Schwern wrote:
Because they all come in at one lump, I have to deal with them in one
lump.
There's no easy system to tell which ones I've dealt with (previously
I'd just
delete the mail) and which ones I haven't.
The way
Barbie wrote:
On Thu, Sep 11, 2008 at 02:17:41PM -0700, Michael G Schwern wrote:
Ick. I hope I'm missing something obvious maybe?
The bit where I get flamed. Again. Thanks.
You're welcome. :)
Oh, you're in a hellish spot, I realize. And it sucks. Thank you very much
for putting so much
Ovid wrote:
PerlUnit is dead. Lots of people are recommending PerlUnit. What have I
missed?
http://use.perl.org/~Ovid/journal/37463
My stock thinking is that because it follows the xUnit pattern that's most
familiar to most non-Perl programmers. It's the first thing they stumble on
Eric Wilhelm wrote:
My stock thinking is that because it follows the xUnit pattern that's
most familiar to most non-Perl programmers. It's the first thing
they stumble on that looks like what they're used to. So that's what
they go with.
Even if they had no prior language experience, if
David E. Wheeler wrote:
On Sep 17, 2008, at 13:24, Michael G Schwern wrote:
FWIW I added a TAP column to the Perl section on Wikipedia's list of unit
testing frameworks. If every testing framework has to sound off on
xUnit, why
not TAP?
http://en.wikipedia.org/wiki
Fergal Daly wrote:
#!perl
use Test::More tests=1;
use Test::Builder::Tester;
test_out('not ok 1 - use Fcntl;');
test_fail(+1);
use_ok 'Fcntl', 'Pie';
test_test( Fails for bad export);
__END__
alternatively
use Test::Tester;
use Test::More tests = 1;
Michael G Schwern wrote:
Shlomi Fish wrote:
* What is the problem with world writeable files in a distro?
Let's suppose Makefile.PL is world-writable. While the distro is being
unpacked, a malicious user writes something like:
{{{
system('rm -fr $HOME');
}}}
to it, and after you come
Michael Peters wrote:
You're right. If they are a malicious user then they will find a way to
screw you. I'm just saying that since we know about this path, let's
eliminate it, or at least make it public and known.
I agree with that. The part I object to in the OP is the part where CPAN
Ovid wrote:
Today I've received two failure reports from vpit (via the excellent new
CPAN testers email). The error for both Test::Aggregate and aliased is:
[ERROR] [Wed Sep 24 20:13:40 2008] Could not run 'Build':
Can't use an undefined value as a HASH reference at
Aristotle Pagaltzis wrote:
* Cosimo Streppone [EMAIL PROTECTED] [2008-09-29 02:10]:
but it seems that gnu tar doesn't like the following:
$ tar --mode=0755 cvf blah.tar somedir
$ tar c --mode=0755 vf blah.tar somedir
and will only accept:
$ tar cvf blah.tar --mode=0755 somedir
Aristotle Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2008-09-29 14:50]:
MakeMaker can set a minimum umask if it wants to play security
nanny
On Windows?
Windows, as always, is a special case. If a work around is necessary for
Windows that's fine.
--
Hating the web since
Aristotle Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2008-09-29 16:35]:
Aristotle Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2008-09-29 14:50]:
MakeMaker can set a minimum umask if it wants to play
security nanny
On Windows?
Windows, as always, is a special case
I just found this out, and I assume others here occasionally make use of
testdrive and don't know.
HP is shutting down it's testdrive program which gives logins to its many
operating systems (see also VMS) for developer evaluation and testing. It's
replacing it with something called HP Partner
Greg Sabino Mullane wrote:
It should be fairly easy for willing CPAN testers to setup any database
they like, and provide some connection information for throwaway tables
and data (assuming the test script WILL probably drop all tables in
there and dump its own crap there).
This seems of
http://schwern.org/src/Test-Simple-0.82.tar.gz
or coming soon on CPAN.
Please report bugs via
http://code.google.com/p/test-more/issues/list
There are some user visible changes which might cause fixage for those who
depend too closely on the output of Test::Builder. Here's the new features
and
Randy J. Ray wrote:
Seeing as one of the
CPANTS metrics gauges whether a distro's META.yml conforms to the
most-recent spec, I was wondering if there is an existing approach to
comparing a YAML doc to a given spec. Or what constitutes a YAML spec, for
that matter.
The YAML specifications can
http://schwern.org/src/Test-Fork-0.02.tar.gz
On its way to CPAN now.
I just cleaned up and released a stable version of Test::Fork which is a
helper module for code that forks. It does all the Test::Builder voodoo
necessary to have tests happening in parallel on a single TAP stream.
NAME
Ovid wrote:
It's interesting that every time I run this, the 'note' shows up before the
'diag':
use Test::More 'no_plan';
ok 1, 'first test';
diag 'this is a diag';
note 'this is a note';
ok 1, 'second test';
__END__
note.t ..
ok 1 - first test
# this is a note
0.82 accidentally shipped with a dependency on Mouse. We're only using that
for experiments.
No other change.
http://schwern.org/src/Test-Simple-0.84.tar.gz
--
Hating the web since 1994.
Steve Peters wrote:
[EMAIL PROTECTED] t]$ ./perl harness ../lib/constant.t
../lib/constant1/97
# Failed test at ../lib/constant.t line 115.
# got: '1'
# expected: '0'
# unexpected warning
# Argument 12 cats isn't numeric in addition (+) at
../lib/Test/Builder.pm line
Randy J. Ray wrote:
After much longer than it *should* have taken me, I've finally gotten my
Test::* module onto CPAN (in fact, this is the second release, as the first
time around I bundled it on a machine that had an out-of-date EU::MM, so the
META.yml wasn't quite up to par... plus I'd
http://test-more.googlecode.com/files/Test-Simple-0.85_01.tar.gz
This latest release resolves a number of long outstanding issues in cmp_ok().
The biggest being this:
cmp_ok $object, '==', $number;
cmp_ok() would always stringify or numify its arguments, removing the
overloading. This
Ovid wrote:
1. How can I find out why a CPAN testers report is N/A?
Dig through the details.
[MSG] [Sat Oct 18 02:06:52 2008] Prerequisite 'perl' for 'Test::Most' could
not be obtained from CPAN -- sending N/A grade
In this case, CPANPLUS::Dist::YACSmoke is confused. Lately it seems to be
http://schwern.org/src/Test-Simple-0.86.tar.gz
or a CPAN near you!
This release mostly deals with fixing a long standing problem with cmp_ok()
and overloaded objects. I expect this to cause some fixage.
Previously, overloaded objects would have their overloading stripped, turning
them into
Jonathan Rockway wrote:
* On Wed, Nov 12 2008, David Golden wrote:
On Wed, Nov 12, 2008 at 3:17 PM, demerphq [EMAIL PROTECTED] wrote:
IMO if the toolchain is to work this should happen at PAUSE (if it can
detect this problem IMO it should just damn well fix it itself) or at
extraction.
It
David Golden wrote:
On Wed, Nov 12, 2008 at 3:17 PM, demerphq [EMAIL PROTECTED] wrote:
I rather strongly object to this change.
I totally understand -- but keep in mind that this was in response to
someone flagging this as a potential (if highly unlikely) security
hole, forwarding it to
Andreas J. Koenig wrote:
On Wed, 12 Nov 2008 19:13:40 -0800, Michael G Schwern [EMAIL
PROTECTED] said:
Now that the CPAN shells and archiving modules are handling it at their
end, I
think the PAUSE filter should be removed. It's not PAUSE's job to be the
code
police
Smylers wrote:
[1] common carrier is a legal idea from common US/UK law. I don't
want to get into the legal mumbo jumbo because we're not lawyers, but
invoking the idea is useful and powerful.
OK, so you're talking about Cpan being something morally equivalent to a
common carrier, rather
Jan Dubois wrote:
On Thu, 13 Nov 2008, Michael G Schwern wrote:
This is why I want CPAN to return to its common carrier policy. Don't
inspect
them, don't open them, don't reject them and especially don't try to fix
them,
just leave the packages sealed.
CPAN (at least the indexing part
Smylers wrote:
I have lying around a prototype for the CPAN shell to warn the user
when they run it as root and offer to reconfigure itself to only su
for the install. That would help plug the hole.
Yeah, that sounds good.
But only for users running CPAN, not anybody who is manually
Eric Wilhelm wrote:
The only impossible spot is when tests are inside e.g. a
runtime dispatched method, no? (And, given the procedural paradigm,
that seems to be an odd case.)
No, that's not odd at all. Any data driven testing system will be that
way. Tests are run based on some config file
Justin DeVuyst wrote:
Hello,
I was told this might be a place to get information about
upcoming Test::Builder changes.
I'd like to know if and when Test::Builder will officially
support true plan at end. The current version of
Test::Builder reports 1..$seen_tests instead of
David E. Wheeler wrote:
On Jan 23, 2009, at 10:23 AM, Eric Wilhelm wrote:
I don't recall claiming that it was *simpler*. The single static
numeric plan is simplistic. Given any cross-platform skip issue or
optional-dependency condition, you have a situation where the plan
becomes harder for
rf...@drivebuytech.com wrote:
Late to this discussion. But can somebody explain to me why in java or .net
or groovy or
ruby a programmer doesn't have to induicate the number of tests that will
run before hand
but in perl he must?
Let's make something clear, Perl says nothing about this.
After wrestling some alligators, Test::More's repository now on github.
Please feel free to clone, push, pull, fork or whatever it is you kids do
these days.
http://github.com/schwern/test-more/tree/master
In all seriousness, github is as close to my Grand Scheme For Version Control
as I've yet
Well it's about damn time.
use Test::More;
pass;
done_testing;
This now works and effectively replaces no_plan.
This works, too:
use Test::More;
pass;
done_testing(1);
I was expecting it to be hard and require a lot of reworking the tests. It
turns out it was really easy, so I
Gabor Szabo wrote:
BTW what about
use Test::More;
pass;
pass;
# done_testing() # not being called at all.
Is this a failure now as there was no plan, not even a no_plan ?
It's a failure by virtue of there being no TAP plan. I didn't feel it was
necessary to output an explicit failing
David Cantrell wrote:
On Thu, Feb 05, 2009 at 10:00:38AM +0200, Gabor Szabo wrote:
You might want to report error if both plan(2) and add_plan(2) was
called in the same file.
Or you might not.
plan(2);
# generic tests
ok(...);
ok(...);
if($ENV{RUN_REALLY_SLOW_TESTS}) {
David E. Wheeler wrote:
On Feb 5, 2009, at 12:34 PM, Michael G Schwern wrote:
Though we don't have incremental TAP plans, Test::Builder can check that
you've run all the tests you said you'd run before you add more. Thus...
use Test::More;
plan add = 2;
pass;
plan add = 1;
pass
Gabor Szabo wrote:
With prove I can say
prove --exec $ENV{PARROT_DIR}/parrot
$ENV{PARROT_DIR}/languages/rakudo/perl6.pbc t/01.t
and it will run
$ENV{PARROT_DIR}/parrot $ENV{PARROT_DIR}/languages/rakudo/perl6.pbc t/01.t
how can I achieve the same thing with make test or Build test ?
Now that Test::More is on github, and I'm deliriously happy with their process
of managing forks/branches, I'm going to go ahead and delete the Google Code
SVN repo to avoid any confusion by leaving a dead repo around. I'll hold off
a few days so that anyone who has some outstanding patches maybe
Nicholas Clark wrote:
On Sat, Feb 14, 2009 at 12:57:45PM +0200, Gabor Szabo wrote:
On Thu, Feb 12, 2009 at 3:18 PM, Nicholas Clark n...@ccl4.org wrote:
I find
isnt($foo, undef);
useful as it gives better failure diagnostics than
ok(defined $foo);
Wouldn't it be better to write
Ovid wrote:
At this point, explain() has been in Test::Most long enough and is one
of the features I pitched it on that I'm not keen on changing it
(Dumper was added later. This was a way of having non-verbose
diagnostics). That being said, I'm happy to try and figure out some
way of
Pedro Figueiredo wrote:
I've had a report from a user regarding some tests under Darwin (10.5.6,
Leopard, I have no idea if it happens on earlier versions too). I've
since noticed the behaviour under 5.10 on Linux is not what I expected
either.
My orbital mind reading laser got hit by an
Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2009-02-18 21:55]:
One of the issues with that approach is Test::Builder's history
can't store test #2 twice. So history is lost.
Shouldn’t this be fixed?
Sure, but how?
Internally, fine, it can be stored using a list
David E. Wheeler wrote:
On Feb 18, 2009, at 2:04 PM, David E. Wheeler wrote:
Of course if I use -v, it passes `verbosity = 1` to TAP::Harness, but
I'd love to be able to see the failure diagnostics without having to
see all of the passing test TAP output, too. Is there some way to get
Aristotle Pagaltzis wrote:
If you're referring to having two tests with the same number,
that's perfectly valid TAP which will cause the suite to fail.
Test::Builder should support it whether we use it for sub-plans
or not.
I agree with that. Let me try again:
I’m saying that outputting
chromatic wrote:
On Thursday 19 February 2009 04:05:37 Ovid wrote:
Properly, if we want to report SKIPs for each test (presumably with
numbers), then we want to report failing TODOs with each test for
consistency's sake.
I don't like that. You can already get this behavior with the
Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2009-02-19 08:40]:
it doesn't require any extra TAP reader logic to determine pass
or fail.
I’m not talking about pass/fail, I’m talking about finding out
about subplans, from the consumer end.
As TAP has no formal means
Andy Lester wrote:
Second point: Should tests 3 and 6 pass? Being unnumbered?
Yes, that's by design (or at least happy historical accident).
It allows you to run a bunch of tests where you can't guarantee the order or
coordinate the counter. For example, testing anything that forks (threads
David E. Wheeler wrote:
Hrm. Reading the documentation:
=item * Cverbosity
Set the verbosity level:
1 verbosePrint individual test results to STDOUT.
0 normal
-1 quiet Suppress some test output (mostly failures
while tests
David E. Wheeler wrote:
On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote:
I’m not talking about pass/fail, I’m talking about finding out
about subplans, from the consumer end.
As TAP has no formal means to express that, and I'm not waiting for a TAP
extension, any TAP reader will need
Andy Lester wrote:
On Feb 19, 2009, at 2:24 PM, Michael G Schwern wrote:
Andy Lester wrote:
Second point: Should tests 3 and 6 pass? Being unnumbered?
Yes, that's by design (or at least happy historical accident).
But ok 0 should certainly fail, right?
Yeah, that's just a bug
Andy Armstrong wrote:
On 20 Feb 2009, at 16:52, David E. Wheeler wrote:
On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:
RENUMBER
Won't that fuck up existing users of the library?
Yeah, I was making a BASIC joke :)
A very basic joke.
--
44. I am not the atheist chaplain.
-- The
Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2009-02-19 21:15]:
As TAP has no formal means to express that, and I'm not waiting
for a TAP extension, any TAP reader will need extra logic to
figure that out. So worrying about that seems moot.
If it takes a lot longer
Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2009-02-20 23:35]:
And we come back to the beginning: it's all going to be ad hoc
anyway until TAP formalizes it. Fine for eyeballing. If someone
wants to scrape the information out they can do it from the
description
David E. Wheeler wrote:
Dot notation?
ok 1.1
ok 1.2
ok 2.1
1..2
If you don't want any existing TAP parser to be able to read it and delay
release until they do, sure!
I am totally not waiting for TAP to work out sub-plan syntax.
--
185. My name is not a killing word.
-- The 213
1201 - 1300 of 1466 matches
Mail list logo
