On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 14:41, Fergal Daly wrote:
> If you're testing web applications, you can fire off forks or threads.
> So instead of serially waiting for each network operation to complete,
> let them run in parallel. This could help to get wallclock-time closer
> to cpu-time. You could put each set of tests in it's own script (might
> be easy, might not), fire off each script outputting to it's own file
> and then run the tap consumer over each file in turn and join all the
> results up. Or you could just give each thread/process it's own test
> prefix and let them off to do their own thing.
I'd rather just give each thread its own stream and TAP::Parser and
mix everything together further upstream in that case. If you want to
capture all the TAP have each parser spool to a different file and
then concatenate them all.
How? For this to work, either each producer starts its own parser (so
now the test is running the harness) OR a producer has a way to signal
to the harness that a new stream is starting and it needs to attach a
new parser to it OR each producer writes to its own file and the
harness comes around and finds all the output files and parses them OR
something else that I haven't thought of.
> This doesn't seem to be motivation of the original poster was asking
> about, however joining multiple streams becomes easy, you just prefix
> each line with "$n." where $n is the number of the file.
I think you just don't join TAP streams in that way. How do you
handle YAMLish diag blocks that follow a numbered test? How do you
handle plan lines?
You'd have to prepend a source identifier to each line - and doing
that is really just a standard trick (see logfiles) that doesn't
really feel like it should be part of TAP.
Yes, this is exactly what I said except the source identifier is just
a test number. Each source has a dedicated block and everything it
outputs is associated with that block. You don't need a weird textual
source identifier (although each block is a test and tests have names
so it does have a textual identifier, just not on every line).
Currently we have a situation where we cannot even assign diagnostics
to the relevant test
ok 1
# wibble
ok 2
# foobar
does "wibble" belong to the first or second test?
ok 1
diag 2 # wibble
ok 2
diag 2 # foobar
now it's clear.
replace 1 or 2 there by nest numbers like 1.2.3.
> Using BEGIN/END works for the non-real time however it seems like it
> would be better to use a solution that works equally well in either
> situation,
Trying to solve the realtime problem by turning each line of TAP into
a packet with a source idntifier and then streaming them over a
single pipe is bonkers. We don't need to mux/demux streams for
network transmission. TCP/IP does that pretty well.
I'm not particularly trying to solve it, I'm just pointing out that
you get it for free once you allow nested blocks and make each line
declare it's test number which are useful for other things anyway.
From your "numbered paragraphs" comment I guess you think that nested
blocks are quite a natural feature.
I'm not sure what you mean by your TCP/IP comment. Are you saying we
should not reimplement the wheel and somehow leverage TCP/IP's muxing
abilities to solve a problem?
F
