On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 01:11, Fergal Daly wrote:
> To address the whatever, BEGIN/END draws you into the XMLish problems
> of waiting for a complete document before acting on the contents and
> even if you avoid this it still makes it hard to interleave streams.
You don't have to wait for END any more than you have to wait for the
end of the stream now. As you receive each line you know precisely
what its context is. The END just pops a frame off the context stack.
You may of course /elect/ to wait for an END before, say, outputting
a summary. Currently the only END you can wait for is the end of
stream - so we actually get /more/ control over when output is
displayed.
> I'm starting to think that every line should be prefixed by a test
> number, including diags (diags are not currently associated with a
> particular test but could be made so) so something like
I believe you may have mentioned this before :)
Yes but I hadn't advocated prefixing everyline with it's test number before.
I'm not sure how it helps with interleaving streams (or why that
might be desirable...). If you just mean you can multiplex lines from
mulitple streams into a single stream then you're mistaken. The test
numbering for the two streams could easily overlap.
Each test stream is a "block" and so the first number on each line
designates the stream, otherwise the numbering is _guaranteed_ to
overlap. This has been mentioned before with regard to threads and
forking, sorry I didn't make it clear it the reply.
Your numbering scheme also makes it relatively hard to wrap a stream
as a chunk: you'd have to process each line that contained a test
number to prepend the chunk number.
These two tests
# Test 1
1.2
1.2.1
1.2.2
--- cut ---
# Test 2
1
2
3
would have to be rewritten as
# Test 1
1.1.2
1.1.2.1
1.2.2
# Test 2
2.1
2.2
2.3
And in general there's a reason why programming languages favour
nested blocks over numbered paragraphs :)
Exactly. And it's clear that you can interleave these 2 streams
without ambiguity.
If you want to do chunking then you're going to have carefully buffer
your output on all streams and even then you can have trouble with
chunks that are larger than some OS buffer size. Appending to a file
or writing to a pipe is not necessarily atomic so you can end up with
one chunk's data appearing in the middle of another. To avoid this you
need to either guarantee all writes are smaller than X (might be 512
bytes, not sure) or do locking or have everything talking to a
something that multiplexes the streams.
Of course the prefix-way suffers has a similar potential problem if
there is an extremely long line. It would need to be able to handle
line continuations but that's very straight forward, like mail
hearders.
F
--
Andy Armstrong, hexten.net
