On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 02:07, Fergal Daly wrote:
>> begin
>> begin
>> ok
>> end
>> begin
>> not ok
>> end
>> end
>
> Yes, I said it was nestable but my point is that it once you start
> nesting you can no longer have the demuxer separate from the TAP
> parser. So now it's tightly coupled with TAP which was supposedly a
> bad thing.
We're talking at cross purposes. I'm proposing that begin/end be part
of TAP, handled by TAP parser.
I was also saying that if you want to multiplex multiple streams onto
a single pipe it should be implemented outside of TAP. That has
nothing to do with begin / end.
>> I added that to the example only for readability.
>
> TAP's readability is a deliberate feature, any modifications should
> retain that readability. You must have some kind of indentation.
We can certainly allow leading spaces. There's no need to /require/
correct indentation though.
There's a requirement to accept it otherwise human-readability is
lost. There should be a strong recommendation to produce it.
> Indenting by extending the number is somewhat backwards compatible.
And you're prepending a number to plan lines? To the TAP version
line? To each line of a YAML block?
Prepending something to every line is necessary if you want perfect
multiplexing. I see a proposal on the wiki for disambiguating
diagnostics involving "# #" meaning this diagnostic belongs to the
test result above (no way of indicating that it belongs to the test
result below). If instead you prefix diagnostics with something
including the test number then you get everything.
How does the Test::More instance of each test script discover what
number it's supposed to prepend to each line? What happens if you
happen to want to merge two TAP transcripts that use the same prefix
number? Are we going to have to have a tool to renumber TAP?
Joining tests after running would require renumbering, which is pretty simple
perl -lpe 'if ($f ne $ARGV){$f=$ARGV;$c++} s/^((?:not )?ok|\d+\.\.\d+)
(\d)/$1 $c.$2/'
But although that's how the thread started, I don't see how that use
case is the overriding concern when it comes to adding grouping to
TAP.
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
- is valid TAP right now except for plans
- will handle a forking/threaded script fine apart from assigning
diagnostics to the right test (which doesn't actually happen yet
anyway)
Your suggestion
- requires 2 new keywords
- is not valid TAP right now, current TAP parsers ignore most of your
sample output
- makes test-numbering non-unique (current TAP parser emits
warnings/errors referring to test numbers)
- makes it impossible to fork/thread
F
--
Andy Armstrong, hexten.net
