utApia

[Eric Wilhelm]

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 cannot be meaningful to a tap consumer.

Facts:

1.  STDERR has historically been used for (non-parsable) failure
messages.

2.  Completely synchronizing two filehandles is not possible at the
harness level (unless the harness is the kernel, then *maybe*.)

3.  Merging STDOUT and STDERR breaks starting with `warn ok;`

Wants:

1.  Identifiable (tagged) error messages as a formal part of TAP.

  ~1.5 Display errors synchronously in relation to failing tests.

2.  Backwards parser/producer compatibility (mostly with expectations
created by fact 1.)

Please correct and clarify as needed.  I've tried to cook this down into 
the essentials.  If there is a significant fact or want which is not a 
subset of the above, then I have completely misunderstood.  If I've got 
the fundamentals wrong, then I'm done -- stick a fork in me.  If I've 
got the facts wrong, correct me; otherwise, they're uh... facts.

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.

Forget for a moment about 'Undefined variable' and such warnings (except 
to remember that they exist and can ruin your day if the protocol gets 
in their way (I think that's the cannot be meaningful part of the 
fundamental.))

--Eric
-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it.
--Donald Knuth
---
http://scratchcomputing.com
---

Re: utApia

[Andy Armstrong]

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 - assuming Ovid et al agree is:

1) Disable OUT/ERR merging by default. Enabled by a --merge flag to
   runtests. Documentation says: using this flag destroys the  
important

   distinction between output and errors. Errors may be parsed as TAP.
   Bad things may happen as a result. We already have the merging
   implementation and some people are finding it valuable. So we don't
   destroy it but we make it non-default.

2) Implement TAP grammar for structured diagnostic information. This is
   patently a good idea. The only friction is that Test::Builder et al
   don't yet have support. We have to start somewhere.

Unless anyone can demonstrate that either of these actions actually move
us further away from our goals I'm going to get started on them,
probably tomorrow.

OK?

--
Andy Armstrong, hexten.net