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
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
On Wednesday 14 March 2007 17:02, Michael G Schwern wrote:
> I forgot, I'm on a mailing list. Thou shalt not let any inaccuracy, no
> matter how minor or totally inconsequential to the point being made, go
> uncorrected.
I generally consider it good debating technique to characterize the opposin
On Wednesday 14 March 2007 15:05, Michael G Schwern wrote:
> chromatic wrote:
> > I think my point eluded everyone. Let me be very clear.
> >
> > MAKE diag() PRINT TO STDOUT NOT STDERR.
>
> Deja vu all over again. We had this discussion months ago when TAP::Parser
> tried EXACTLY this, at the t
Let me make something clear, I don't have a solution to this problem. I'm
just finally getting a grip on what the problem actually is. The last week
has shaken lose use cases and conditions I hadn't thought about before and the
TAP diagnostic syntax proposal does not cover.
What I do know is tha
chromatic wrote:
> 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
