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.
On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 01:11, Fergal Daly wrote:
> - it is 1-level deep grouping and so it requires another layer for
> degrouping. Separating the degrouping from the TAP parser confines it
> to a single level of grouping. If you're going to do gr
On 8 Apr 2007, at 01:11, Fergal Daly wrote:
- it is 1-level deep grouping and so it requires another layer for
degrouping. Separating the degrouping from the TAP parser confines it
to a single level of grouping. If you're going to do grouping, you
should go all the way and make it nestable and le
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 15:37, Fergal Daly wrote:
>> 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 dif
On Saturday 07 April 2007 08:43, Andy Armstrong wrote:
> I don't think a mechanism for sending multiple streams over a single
> pipe should be TAP specific or part of TAP. Making it part of the
> test numbering scheme couples it far too closely to TAP - there's
> just no need to pollute TAP
On 7 Apr 2007, at 15:37, Fergal Daly wrote:
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 wo
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 w
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 t
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 10:37, Fergal Daly wrote:
> 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
On 7 Apr 2007, at 10:37, Fergal Daly wrote:
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
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 inte
11 matches
Mail list logo
