On 09/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
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 impor
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 severa
On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 12:46, Fergal Daly wrote:
> Prepending something to every line is necessary if you want perfect
> multiplexing.
But we don't want that to be part of TAP do we? What's with the
insistence that TAP has to be responsible for m
On 8 Apr 2007, at 12:46, Fergal Daly wrote:
Prepending something to every line is necessary if you want perfect
multiplexing.
But we don't want that to be part of TAP do we? What's with the
insistence that TAP has to be responsible for multiplexing?
Or we could just go with a proposal that
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
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
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 tha
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 6 Apr 2007, at 23:17, A. Pagaltzis wrote:
> * Michael Peters <[EMAIL PROTECTED]> [2007-04-06 23:15]:
>> Maybe I'm missing something (and if so, please point out the
>> obvious to me) but I can't find a way for a single TAP file to
>> cont
On 6 Apr 2007, at 23:17, A. Pagaltzis wrote:
* Michael Peters <[EMAIL PROTECTED]> [2007-04-06 23:15]:
Maybe I'm missing something (and if so, please point out the
obvious to me) but I can't find a way for a single TAP file to
contain results from multiple test files.
There isn’t one. There wa
* Michael Peters <[EMAIL PROTECTED]> [2007-04-06 23:15]:
> Maybe I'm missing something (and if so, please point out the
> obvious to me) but I can't find a way for a single TAP file to
> contain results from multiple test files.
There isn’t one. There was recently discussion about this, with
mixed
20 matches
Mail list logo
