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
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
>>> "$
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 Mar 15, 2007, at 12:38 AM, chromatic wrote:
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 agree with both of these, and I do think it'll cause problems, but
if we
On Wednesday 14 March 2007 18:27, A. Pagaltzis wrote:
> * chromatic <[EMAIL PROTECTED]> [2007-03-14 18:50]:
> > I think my point eluded everyone. Let me be very clear.
> Not me, but I’m not surprised that so many people missed it.
> After all, you did try to make it in as condescendingly
> conv
* chromatic <[EMAIL PROTECTED]> [2007-03-14 18:50]:
> I think my point eluded everyone. Let me be very clear.
Not me, but I’m not surprised that so many people missed it.
After all, you did try to make it in as condescendingly
convoluted a way as possible. I don’t think your sarcasm was
called fo
On 14 Mar 2007, at 19:24, Yitzchak Scott-Thoennes wrote:
A way to request verbose output without the merging.
I'm wondering whether merging should be a separate option. I feel
slightly uneasy about having the harness behave so differently as a
result of setting the verbose flag. Normally -v
> On 14 Mar 2007, at 07:29, chromatic wrote:
>> The problem is that there's no way to tell that that information
>> sent to
>> Test::Builder->diag() is diagnostic information for the tests
>> because once it
>> goes out on STDERR, it could be anything.
>
> So we seem to have two reasonably sensible
David Cantrell wrote:
> Michael G Schwern wrote:
>
>> First thing is breaks, and probably most important: No warnings.
>
> Any test suite that blithely ignores warnings is BROKEN.
>
> There are two types of warning. First, those which you deliberately
> spit out, like "use of foo() is deprecated,
On Wednesday 14 March 2007 09:41, Geoffrey Young wrote:
> > There ought to be a way to capture diagnostic information in the TAP
> > stream because it's useful for diagnosing problems.
> so, to chromatic's point, I can't help but feel like solving the quoted
> issue would go a long way toward red
Ovid wrote:
David Cantrell <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
Same here, but Test::NoWarnings is hardly annoying.
Sure, on its own. But then there's lots of other modules which, on
their own, aren't annoying. B
> There ought to be a way to capture diagnostic information in the TAP stream
> because it's useful for diagnosing problems.
I feel like I'm talking to myself when I say this (since I've said this
before) but I'll say it again just, well, because :)
the implicit idea that STDERR generally goes
On 14 Mar 2007, at 15:45, Michael G Schwern wrote:
But we can go ahead with TH 3 now using Ovid's plan without
worrying about that.
OK. Unless anyone jumps in first I'll implement it when I get some
time from Friday onwards.
--
Andy Armstrong, hexten.net
Andy Armstrong wrote:
> On 14 Mar 2007, at 07:29, chromatic wrote:
>> The problem is that there's no way to tell that that information
>> sent to
>> Test::Builder->diag() is diagnostic information for the tests
>> because once it
>> goes out on STDERR, it could be anything.
>
> So we seem to h
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
I like fewer bugs. I guess we'll just have to agree to differ,
F
--- David Cantrell <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
>
> > use Test::NoWarnings;
>
> I like to use Fewer::Annoying::Dependencies.
Same here, but Test::NoWarnings is hardly annoying. More than once
that module has revealed bugs that we've managed to miss in
development. In fact,
Fergal Daly wrote:
use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
--
David Cantrell
On 14 Mar 2007, at 07:29, chromatic wrote:
The problem is that there's no way to tell that that information
sent to
Test::Builder->diag() is diagnostic information for the tests
because once it
goes out on STDERR, it could be anything.
So we seem to have two reasonably sensible options on t
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Michael G Schwern wrote:
> First thing is breaks, and probably most important: No warnings.
Any test suite that blithely ignores warnings is BROKEN.
There are two types of warning. First, those which you deliberately
spit out, like "use
Michael G Schwern wrote:
First thing is breaks, and probably most important: No warnings.
Any test suite that blithely ignores warnings is BROKEN.
There are two types of warning. First, those which you deliberately
spit out, like "use of foo() is deprecated, please use bar() instead".
You
# from chromatic
# on Wednesday 14 March 2007 01:47 am:
>They don't have to interfere with the TAP stream unless they call
>Test::Builder->diag(),
Yep. We need to flow everything from stderr through asap. However, I
don't think we should be trying to do *anything* with it (except maybe
archi
chromatic wrote:
> On Wednesday 14 March 2007 01:37, Smylers wrote:
>
>> chromatic writes:
>
>> > There ought to be a way to capture diagnostic information in the TAP
>> > stream because it's useful for diagnosing problems.
>
>> Does that help with the case where it's an 'ordinary' Perl-generated
>
On Wednesday 14 March 2007 01:37, Smylers wrote:
> chromatic writes:
> > There ought to be a way to capture diagnostic information in the TAP
> > stream because it's useful for diagnosing problems.
> Does that help with the case where it's an 'ordinary' Perl-generated
> warning ("Use of uninitia
chromatic writes:
> There ought to be a way to capture diagnostic information in the TAP
> stream because it's useful for diagnosing problems.
Does that help with the case where it's an 'ordinary' Perl-generated
warning ("Use of uninitialized value" and the like), which runtests is
also swallowin
Michael G Schwern writes:
> ... TAP::Parser guarantees that STDOUT and STDERR will be in sync,
> something Test::Harness does not guarantee.
>
> First thing is breaks, and probably most important: No warnings.
That caught me by surprise this week. runtests was showing a failure I
didn't unders
On Wednesday 14 March 2007 00:00, Michael G Schwern wrote:
> chromatic wrote:
> > If only there were a way, perhaps in Test::Builder, to supply
> > diag()nostic information to the TAP output stream.
> Diagnostics (comments) in the TAP stream should not be displayed. diag()
> does not go to the
chromatic wrote:
> On Tuesday 13 March 2007 23:15, Michael G Schwern wrote:
>
>> The simplest solution, and one which unblocks Test::Harness 3.0 because
>> TAP::Parser breaks compatibility in its current state, is to remove the
>> syncing feature.
>
> If only there were a way, perhaps in Test::Bu
On Tuesday 13 March 2007 23:15, Michael G Schwern wrote:
> The simplest solution, and one which unblocks Test::Harness 3.0 because
> TAP::Parser breaks compatibility in its current state, is to remove the
> syncing feature.
If only there were a way, perhaps in Test::Builder, to supply diag()nosti
Those who don't follow TAP::Parser closely might now know about the issue
that's currently being struggled with. It has to do with how TAP::Parser
guarantees that STDOUT and STDERR will be in sync, something Test::Harness
does not guarantee.
Test::Harness only captures STDOUT from a test script.
29 matches
Mail list logo
