--- Michael G Schwern [EMAIL PROTECTED] wrote:
How does it do this? I understand that an old harness will not be
able
to parse it - it will be upset by the sub-plans and the dotted test
numbers)
Yep. By backwards compatible I mean you can feed the new TAP to an
old
harness and it
On 12 Mar 2007, at 00:00, Michael G Schwern wrote:
That's a good idea.
Whether or not you can set a list of specific versions (considering
them as
extensions rather than increasing versions) or just a single
highest version
is up for debate.
Highest version I'd say. I hope we're not
On 12/03/07, Andy Armstrong [EMAIL PROTECTED] wrote:
On 12 Mar 2007, at 00:00, Michael G Schwern wrote:
That's a good idea.
Whether or not you can set a list of specific versions (considering
them as
extensions rather than increasing versions) or just a single
highest version
is up for
On 12/03/07, Ovid [EMAIL PROTECTED] wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
How does it do this? I understand that an old harness will not be
able
to parse it - it will be upset by the sub-plans and the dotted test
numbers)
Yep. By backwards compatible I mean you can
On 12 Mar 2007, at 12:15, Fergal Daly wrote:
Highest version I'd say. I hope we're not expecting such a complex
melange of versions that we need to enumerate the ones we support. If
say we're supporting version 10 it's implicit that we also support
1-9.
Are we not anticipate any bad
On 12 Mar 2007, at 12:27, Andy Armstrong wrote:
I don't want every producer written from here forward to have to be
able to negotiate its way through a minefield of supported
versions. From the producer's point of view the logic should be as
simple as checking that the harness supports our
On 12/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Michael G Schwern wrote:
Subroutines? I don't know if I follow. Do you mean...
sub foo {
extend(2);
pass();
bar();
pass();
}
sub bar {
extend(3);
pass();
pass();
pass();
}
I believe that can be made to
On 12/03/07, Andy Armstrong [EMAIL PROTECTED] wrote:
On 12 Mar 2007, at 12:15, Fergal Daly wrote:
Highest version I'd say. I hope we're not expecting such a complex
melange of versions that we need to enumerate the ones we support. If
say we're supporting version 10 it's implicit that we also
--- Fergal Daly [EMAIL PROTECTED] wrote:
What you're saying is we can _never_ break backwards comatibility.
That is not the impression I got from previous discussions.
Sorry if I gave that impression. I don't mean 'never'. I mean we have
to have a huge amount of bang for our buck to justify
On 12 Mar 2007, at 13:12, Fergal Daly wrote:
I don't want every producer written from here forward to have to be
able to negotiate its way through a minefield of supported versions.
But you do want every consumer written from here forward to support
every previous version.
On the assumption
On 11 Mar 2007, at 22:01, Michael G Schwern wrote:
Fergal Daly wrote:
You're suggesting that each call to extend the plan verifies that the
previous plan has been executed fully? That does not allow nesting.
Yes, nesting is what this proposal does which cannot be done now.
Unfortuantely
Hi Fergal,
* Fergal Daly [EMAIL PROTECTED] [2007-03-12 18:00]:
On 12/03/07, A. Pagaltzis [EMAIL PROTECTED] wrote:
How do you set environment variables when the producer lives
at the other end of an HTTP connection? How do you set
environment variables when you've pipe the producer's output
On Monday 12 March 2007 10:53, A. Pagaltzis wrote:
Making “either the consumer talks to the producer and the
producer has to implement some complex logic, or the producer
sticks to the plainest TAP possible” a requirement would just
lead to most ad-hoc implementations of producers being
Fergal Daly writes:
On 12/03/07, chromatic [EMAIL PROTECTED] wrote:
On Monday 12 March 2007 10:53, A. Pagaltzis wrote:
Making either the consumer talks to the producer and the
producer has to implement some complex logic, or the producer
sticks to the plainest TAP possible a
On 12/03/07, Smylers [EMAIL PROTECTED] wrote:
Fergal Daly writes:
On 12/03/07, chromatic [EMAIL PROTECTED] wrote:
On Monday 12 March 2007 10:53, A. Pagaltzis wrote:
Making either the consumer talks to the producer and the
producer has to implement some complex logic, or the producer
Fergal Daly wrote:
Remember, the TAP producer is not the instigator of the conversation.
The consumer is - it runs the scripts, it requests something to
produce TAP. The consumer is the the client.
Oh but that's not necessarily true. As pointed out there are plenty of
situations where A) the
On 12/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
Remember, the TAP producer is not the instigator of the conversation.
The consumer is - it runs the scripts, it requests something to
produce TAP. The consumer is the the client.
Oh but that's not necessarily true.
http://perl-qa.yi.org/index.php/Test_Groups
F
Fergal Daly wrote:
Did group 1 produce 2 tests and group 2 produce 3 or was it the other
way around?
Why is that important to know?
Worse,
ok 1
ok 2
ok 3
...
ok 1001
1..1000
where did my extra test come from?
That's something the TAP producer can tell us, right now. No TAP
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-03-11 12:55]:
Why does this need a TAP mod? Why not let the producer handle
it?
Because then all you can do is a global trailing plan which is
only half a step up from no plan?
Yep. And why is that a problem?
And if the
On 11/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
Did group 1 produce 2 tests and group 2 produce 3 or was it the other
way around?
Why is that important to know?
Because the first case conforms to the plan, the second doesn't.
Worse,
ok 1
ok 2
ok 3
...
ok
On 11/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-03-11 12:55]:
Why does this need a TAP mod? Why not let the producer handle
it?
Because then all you can do is a global trailing plan which is
only half a step up from no
Michael G Schwern wrote:
The attached proof-of-concept implements it. I had to poke at the guts of
TB to do it, there's no way to extend the plan without printing the plan, so
it would need a minor TB patch. But its very straight forward.
Figured out a way to not have to do that. Just
On 11/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
You're suggesting that each call to extend the plan verifies that the
previous plan has been executed fully? That does not allow nesting.
Yes, nesting is what this proposal does which cannot be done now.
Groups
Fergal Daly wrote:
On 11/03/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
You're suggesting that each call to extend the plan verifies that the
previous plan has been executed fully? That does not allow nesting.
Yes, nesting is what this proposal does which cannot be
Michael G Schwern wrote:
Subroutines? I don't know if I follow. Do you mean...
sub foo {
extend(2);
pass();
bar();
pass();
}
sub bar {
extend(3);
pass();
pass();
pass();
}
I believe that can be made to work without a TAP extension. Its the
producer which
26 matches
Mail list logo
