Michael G Schwern wrote:
>> How about
>> "diag Failure\n". Or even levels of keywords debug/info/notice/warning/
>> err/crit/alert/emerg (stolen from syslog.h).
>
> That's an interesting idea. My worry is making it human readable.
>
> not ok 2
> err Test failed in foo.t line 2
> err got:
Yitzchak Scott-Thoennes wrote:
> Michael G Schwern wrote:
>> print "TAP version 15\n";
>> print "1..1\n";
>> print "# Information\n";
>> print "not ok 1\n";
>> print "! Failure\n";
>
> I'd really not like to see meaningful punctuation.
>> I'm going to say its if a line starts
Michael G Schwern wrote:
> print "TAP version 15\n";
> print "1..1\n";
> print "# Information\n";
> print "not ok 1\n";
> print "! Failure\n";
I'd really not like to see meaningful punctuation. How about
"diag Failure\n". Or even levels of keywords debug/info/notice/warning/
Andy Armstrong wrote:
> On 16 Mar 2007, at 02:52, Michael G Schwern wrote:
>> The reason being that the parser should know if there's diagnostics
>> forthcoming for the current test. This allows a TAP displayer to
>> display the
>> complete information for a test without having to wait, possibly
I believe I now know how to move towards no longer using STDERR for failure
information display AND keep compatibility with existing test scripts, even
those not written using Test::Builder or Test.pm AND not require
Test::Builder, Test.pm and TH not be upgraded in lock step AND not introduce
ambig
chromatic wrote:
> Yeah, much more than a sentence and people start to take me seriously.
>
> I think diagnostics have to go into the TAP stream at some point.
>
> I think expecting a harness to merge STDOUT and STDERR when it runs a test
> file is prone to errors.
>
> I think there are plenty
On 16 Mar 2007, at 02:52, Michael G Schwern wrote:
The reason being that the parser should know if there's diagnostics
forthcoming for the current test. This allows a TAP displayer to
display the
complete information for a test without having to wait, possibly a
long time,
for the next test
Andy Armstrong wrote:
> I've added to TAP::Parser an experimental YAML syntax for embedding
> machine readable diagnostic information in TAP streams. The syntax looks
> like this:
>
> 1..5
> ok 1
> ok 2
> ---
> -
>fnurk: skib
>ponk: gleeb
> -
>
On 15 Mar 2007, at 23:49, Andy Armstrong wrote:
The YAML parser we're currently using needs to be fed an entire YAML
document in a string so the parser has to recognise the boundaries of
^ TAP
the YAML and only then pass it to the parser. This means that if the
The last two releases of Test-Simple (0.68 and 0.69) break on perls before
5.8. The reason is the, seemingly innocent, change to Test::Builder->is_fh()
to use ->isa() instead of UNIVERSAL::isa(). This means things like
UNIVERSAL::isa($non_object, "GLOB") don't work any more.
Its not as bad as it
I've added to TAP::Parser an experimental YAML syntax for embedding
machine readable diagnostic information in TAP streams. The syntax looks
like this:
1..5
ok 1
ok 2
---
-
fnurk: skib
ponk: gleeb
-
bar: krup
foo: plink
...
ok 3
ok 4
This is a bit of a long shot. We have a test failure for TAP::Parser
0.51 on Windows:
http://www.nntp.perl.org/group/perl.cpan.testers/2007/03/msg437065.html
It's Perl 5.8.5 and to this (untutored) eye it looks as if it's not
ActiveState's build. I've tried to build 5.8.5 here but can't get
chromatic wrote:
> One issue that hasn't come up much is that you can't always rely on STDERR
> being available when a human looks at the test results.
>
> Think of testing long-running programs in process, testing in the browser
> (whether via JavaScript Test.Builder or Apache::Test), and automate
On Thursday 15 March 2007 09:49, brian d foy wrote:
> I'm not advocating any change here because I'm perfectly happy with
> what we have now, but isn't the problem there that # means too many
> things?
>
> If a comment started with a # (because this is perl), and other things
> had some other sigi
David Cantrell wrote:
> Yitzchak Scott-Thoennes wrote:
>> David Cantrell wrote:
>>> Any test suite that blithely ignores warnings is BROKEN.
>>> The second type of warning is the one that tells you when you the
>>> author
>>> have fucked up, like, when you say "my $variable" twice, or saying
>>> "$
In article <[EMAIL PROTECTED]>, Michael G Schwern
<[EMAIL PROTECTED]> wrote:
> Piping all diagnostics to STDOUT solves nothing except maybe allowing runtests
> to display warnings again. You still can't tell the difference between a
> comment (what currently is "# foo" printed to STDOUT) and a f
This version of T::H makes prove automatically run under -w, and also
adds a -X flag for turning off warnings.
Begin forwarded message:
From: PAUSE <[EMAIL PROTECTED]>
Date: March 15, 2007 11:46:59 AM CDT
To: "Andy Lester" <[EMAIL PROTECTED]>
Subject: CPAN Upload: P/PE/PETDANCE/Test-Harness-2
Yitzchak Scott-Thoennes wrote:
David Cantrell wrote:
Any test suite that blithely ignores warnings is BROKEN.
The second type of warning is the one that tells you when you the author
have fucked up, like, when you say "my $variable" twice, or saying
"$variable = 'one thing'" and "$varable = 'som
On 15 Mar 2007, at 09:20, Eric Wilhelm wrote:
At the moment, what I'm seeing is differences in priorities placed on
wants #1 and #2 and/or how much of "which want" you're willing to give
up for the other.
Right. Agreed. So let's nail this down to specific actions. My plan for
TAP::Parser - assu
The diag() debate raged on in pdx tonight. Of course, the sides are
roughly in agreement about most things, but with differing priorities
and ideas about particulars of the implementation.
Perhaps it's time to collect the issues and do some thinking.
Fundamentals:
1. Anything on STDERR canno
20 matches
Mail list logo
