--- 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
12!
I went back through all the changes to t/TEST and lib/Test/Harness.pm in
Perl using Sam's git repository and dug out all the extensions to TAP over
the years.
See http://perl-qa.yi.org/index.php/TAP_version for details.
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
TAPx::Parser is now known as TAP::Parser. You can find the latest
CPAN release here:
http://search.cpan.org/dist/TAP-Parser/
and the latest work-in-progress here:
http://svn.hexten.net/tapx/
Changes in this release:
0.51 12 March 2007
- 'execrc' file now allows 'regex' matches for
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
On Sun, Mar 11, 2007 at 03:46:37PM -0700, Michael G Schwern wrote:
The repo browser unfortunately only goes back 50 revisions.
It can display *any* 50 revisions; for example,
http://public.activestate.com/cgi-bin/perlbrowse/c/1
shows you changes 9951 - 1. Admittedly it could do
Sam Vilain wrote:
You can add them all as branches with that cg-branch-add command then
suck them all down with a big cg-fetch command. Another option is to
just grab the lot with git-clone.
Forgot to say, that's almost a 200MB download at the moment.
Actually if you've got the lot, then
Michael G Schwern wrote:
cg-branch-add p4-perl git://git.catalyst.net.nz/perl.git#p4-perl
cg-fetch p4-perl
cg-switch p4-perl
cg-switch: refusing to switch to a remote branch - see README for lengthy
explanation; use cg-seek to just quickly inspect it
Oops, yeah, my
On Sun, 11 Mar 2007 19:17:11 +0100, Thomas Klausner [EMAIL PROTECTED]
said:
Hi!
CPANTS is now up and running again, with fresh data, which will be available
daily. (There might be a problem with UTF8 and the database, but that
should be solvable soon (especially as I know finally
Andy Armstrong wrote in perl.qa :
TAPx::Parser is now known as TAP::Parser. You can find the latest
CPAN release here:
http://search.cpan.org/dist/TAP-Parser/
and the latest work-in-progress here:
http://svn.hexten.net/tapx/
Changes in this release:
I might have missed that, but looks
On 12 Mar 2007, at 16:22, Rafael Garcia-Suarez wrote:
I would recommend to avoid that (at least until TAP::Parser becomes
core
in a stable perl.)
Oops, that's my fault. We should probably rename it for now. It
doesn't actually get installed - it's just sitting there in the bin
dir so
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.
So, we seem to have drifted from the topic of test groups over to this topic
of future proofing against broken versions and TAP producer / parser version
negotiation. I have a simple solution for this.
If all we do is argue about TAP extensions and never actually produce one we
will never have
On 12 Mar 2007, at 23:49, Michael G Schwern wrote:
And nothing done to work on the TAP diagnostic
syntax, easily the most pressing new TAP feature.
I've been thinking about that today. I've got other stuff today
tomorrow and Wednesday but my plan was to get some code out by the
end of the
# from Michael G Schwern
# on Monday 12 March 2007 04:49 pm:
If all we do is argue about TAP extensions and never actually produce
one we will never have to worry about new versions!
That's a good plan. To implement it, we really need a committee.
Perhaps perl-qa is a little overwhelmed with
--- Eric Wilhelm [EMAIL PROTECTED] wrote:
# from Michael G Schwern
# on Monday 12 March 2007 04:49 pm:
If all we do is argue about TAP extensions and never actually
produce
one we will never have to worry about new versions!
That's a good plan. To implement it, we really need a
29 matches
Mail list logo
