On 8 Apr 2007, at 22:41, Fergal Daly wrote:
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.
But for the severalth time you can have your stream multiplexer thing
but not in the TAP parser.
Does it need to be in the parser? No
Might it be useful as a standalone module? Yes
Would it complicate the parser considerably? You betcha
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.
See also: quite a lot else that's new in TAP.
> - 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...
Because my 'all the rest' is smaller than your 'all the rest'. It's
extremely simple to add begin / end to TAP::Parser - it doesn't make
the code significantly less clean.
The code to infer scope from a dotted test number is more complex
than the code to push and pop context when the parser sees begin /
end. Generating a dotted test number by walking up the scope stack
prepending test numbers is trivial.
But that's as nothing compared with the upheaval that would be
necessary to allow a single parser instance to handle interleaved TAP
from multiple, overlapping tests. 'So what' you may say. 'Implement
stream demuxing outside the parser'. Well, er, no - because then we'd
be decoding the test numbering scheme in two places and attaching two
different sets of semantics to those numbers depending on whether
we're unzipping streams or parsing nested tests.
It makes no sense to conflate the two functions of identifying tests
within a hierarchy and tagging data from multiple sources line-by-
line to mux onto a single pipe. The tag-mux-demux-untag thing can and
should be entirely separate from TAP.
> - 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.
Sheesh.
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.
Of course it can be added later. It's not even part of TAP. The fact
that it /can/ be added later demonstrates why not building that
mechanism in to TAP is a /good/ thing.
There are different ways to multiplex multiple streams. We're
proposing line by line tagging - but you could equally well employ a
binary protocol that alternated fixed size chunks from the various
input streams.
That's another reason why this mechanism should not be part of TAP.
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.
But you're undertaking that the parser should at some point in the
future be able to handle jumbled up TAP streams from multiple
sources. That complicates things considerably.
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?
But it's not even vaguely free.
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),
* ease of concatenation of TAP
* blocks are named - good for UIs
* ease of implementation
* lack of threat of being co-opted into crackpot stream jumbling scheme
* readability -> whitespace indenting V forest of numbers (debatable,
my pref)
* ease of editing - both manual and automatic - fewer numbers to keep
in sync
* law of least surprises - that TAP is structured like code easy to
understand
* easier to generate (the producer doesn't need to carry a prefix
around or walk
the stack to find it)
* can wrap TAP <= v12 without having to transform it - that's a biggy
--
Andy Armstrong, hexten.net
