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
---------------------------------------------------
