On Tuesday 13 March 2007, Michael G Schwern wrote:
> 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 ext
--- 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 ne
# 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 wit
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 w
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 to
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
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) th
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,
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 TA
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 requirement would just
> lead
On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
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
>
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 fo
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
On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 00:45]:
> This brings up something else. Future harnesses should probably
> set
>
> I_UNDERSTAND_TAP_VERSIONS="1,5,8,10-22"
>
> so we know what we can output. If that's not set then we need
> to sti
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 hope
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,
* Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 00:45]:
> This brings up something else. Future harnesses should probably
> set
>
> I_UNDERSTAND_TAP_VERSIONS="1,5,8,10-22"
>
> so we know what we can output. If that's not set then we need
> to stick to plainest TAP.
No, I don’t think so.
How do yo
> 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
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, yea
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, the
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 wit
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 the
Michael G Schwern wrote:
> Sam Vilain wrote:
>
>> Try this (after installing cogito):
>>
>> cg-clone git://git.catalyst.net.nz/perl.git#restorical
>> git-log -p t/TEST
>>
>
> Thanks, but that only gets me up to August of 1996. Where's the rest?
>
Ah right, I assumed you'd just be i
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 t
--- 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 justi
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
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 tha
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 tests
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 v
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 decisions
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 me
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 u
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 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 expec
--- 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
> harn
35 matches
Mail list logo
