Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Michael G Schwern
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::Builder, to

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread chromatic
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 TAP

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Smylers
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 swallowing

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread chromatic
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 uninitialized

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread David Cantrell
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. Your

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Ovid
--- 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, it's so

Re: [tapx-dev] The price of synching STDOUT and STDERR

2007-03-14 Thread Michael G Schwern
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 have two

Re: [tapx-dev] The price of synching STDOUT and STDERR

2007-03-14 Thread Andy Armstrong
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

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Geoffrey Young
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

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread David Cantrell
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.

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread chromatic
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 reducing

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Yitzchak Scott-Thoennes
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, please

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Yitzchak Scott-Thoennes
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

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Andy Armstrong
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

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread chromatic
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 convoluted

Re: The price of synching STDOUT and STDERR

2007-03-14 Thread Andy Lester
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

Re: The price of synching STDOUT and STDERR

2007-03-13 Thread chromatic
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()nostic