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
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 whic
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 wi
Dave Mitchell wrote:
> 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
Sam Vilain wrote:
> If you grab the "p4-perl" branch, that's pretty much (sans importing
> bugs) blead;
>
> 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
Sam Vilain wrote:
> Ah right, I assumed you'd just be interested in the pre-perforce stuff -
I could get it from Perforce but that would require access to the repo.
And, of course, using Perforce. *yuck* The repo browser unfortunately
only goes back 50 revisions.
> that above download is ab
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 tem
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 other thing it does well is shatter backwards
compat
Another option is to use IPC::System::Simple.
The driver script is a neat idea, I used this variation for testing my
harness wrapped around my Utils C library
Say I had C code in a Utils library, one source file which might have
this code
/**
* internal function
*/
static int hexChar2Int (
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 groked Unicode)).
CPANTS now lives on a new server provided by hexten.net . Thanks!!
You ca
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
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
>
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
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. N
On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> http://perl-qa.yi.org/index.php/Test_Groups
Rationale?
Why does this need a TAP mod? Why not let the producer handle it?
plan "as_you_go";
plan add => 2;
pass;
pass;
plan add => 3;
pass;
pass;
pas
* 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?
And if the tests and plan disagree, how do you localise the group
in w
Fergal Daly wrote:
> http://perl-qa.yi.org/index.php/Test_Groups
Rationale?
Why does this need a TAP mod? Why not let the producer handle it?
plan "as_you_go";
plan add => 2;
pass;
pass;
plan add => 3;
pass;
pass;
pass;
Would output:
ok 1
ok 2
ok 3
ok 4
ok 5
1..5
http://perl-qa.yi.org/index.php/Test_Groups
F
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?
Michael G Schwern wrote:
> We're in the process of adding a version number to TAP (ya know, ok 1, not
> ok 2) and I'm trying to figure out what version number we're actually at.
> I've been tracing back through the features added since Perl 1 but things
> are a bit jumbled.
>
> I'd like to pick bra
20 matches
Mail list logo
