On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 12:46, Fergal Daly wrote:
> Prepending something to every line is necessary if you want perfect
> multiplexing.
But we don't want that to be part of TAP do we? What's with the
insistence that TAP has to be responsible for multiplexing?
I should have said "only necessary".
>> Or we could just go with a proposal that adds two easily understood
>> keywords to TAP without altering any of the existing syntax.
>
> I should point out that I have updated the wiki, I just noticed that I
> had transposed the "ok" and the test number in the groups proposal.
> That may have caused a lot of confusion.
>
> My suggestion on the wiki
>
> - adds no new keywords
New keywords aren't in short supply.
Really? Every new keyword is something that was previously ignored by
the parser and now takes a meaning.
> - is valid TAP right now except for plans
What about the multi-part test numbers?
Multi-part test number do not upset current parsers. They don't
understand them as multipart numbers, as far as I can tell, they
interpret them as names.
What about YAMLish blocks?
How do you propose to tag them with test numbers in a backwards
compatible way?
Backwards compatible with an unimplemented (unreleased anyway) proposal?
I'd be quite happy to see all diagnostics tagged with a test number
but there's nothing in my basic (non-forking) suggestion that prevents
things carrying on as today where you assume the diagnostic was for
the last emitted test.
> - will handle a forking/threaded script fine apart from assigning
> diagnostics to the right test (which doesn't actually happen yet
> anyway)
Which with structured diagnostics is /much/ more of a big deal. You
don't seem to address that at all.
Yes I did. If you want your structured (or any) diagnostics to be
associated correctly and you want to allow forking you have to tag
each line with test numbers. If forking is deemed not important then
tagging them is not necessary.
> Your suggestion
>
> - requires 2 new keywords
New keywords aren't in short supply.
> - is not valid TAP right now, current TAP parsers ignore most of your
> sample output
A TAP stream that doesn't use blocks is unchanged by my proposal -
100% backwards compatible because it's identical.
But a TAP stream that outputs blocks cannot be parsed at all by an
older parser, it will completely ignore any "not ok"s in the output.
> - makes test-numbering non-unique (current TAP parser emits
> warnings/errors referring to test numbers)
We can construct a hierarchical test number that looks just like yours.
Exactly! So why not just do that to start with and leave out all the rest...
> - makes it impossible to fork/thread
Until you expand on your proposal to explain how you're going to
associate structured diagnostics with a particular test so does yours.
As above, if you care about forking and diagnostics (structured or
otherwise) you have to tag each diag line with a test number. If you
don't care about diagnostics and just want to track results then
forking is supported in the basic suggestion.
So the essential difference is that with my way you can forget about
forking for now but you still the option to support it later on. With
your way, support for forking can not be added later because a test's
position in the output stream now has a meaning.
The idea that a TAP stream may in fact be multiple streams that have
been mixed together complicates the TAP parser hugely to provide hard-
to-test functionality that may not be of interest to the majority of
users.
Adding blocks at all complicates the parser. I don't see how
unambiguously identifying the test that produced every line adds more
complication than having the parser maintain a stack of blocks.
At the risk of repeating myself (again) any mux / demux can take
place at a lower level in a notional TAP protocol stack - it doesn't
have to be part of TAP.
You're right, it doesn't have to be, however if you can get it for
free along with another useful feature, why not take it?
What benefits do you get from implementing blocks your way vs my way?
The only one I've seen is that it is easier to concatenate 2 saved TAP
streams (but not so easy that it's just a matter of cat 1.tap 2.tap >
combined.tap so you'll want a tool to do it anyway),
F
