Re: The spewing problem.

2008-01-15 Thread Sam Vilain
Aristotle Pagaltzis wrote: * Geoffrey Young [EMAIL PROTECTED] [2008-01-14 17:05]: it's useful to me because I say it is. personally I don't feel the need to defend something many people would like to see this like we're being forced to here. Yeah, agreed. Why is everyone so dogmatic and

Re: The spewing problem.

2008-01-14 Thread Sam Vilain
Matisse Enzer wrote: Ok, why do you want to stop it as fast as possible when a failure occurs? So I can more quickly focus on fixing that first test failure. I use make test 21 | less Works for individual tests too make perl -Mblib t/testname.t 21 | less I don't see how this stops

Re: The spewing problem.

2008-01-14 Thread Sam Vilain
Geoffrey Young wrote: schwern has a valid point in not wanting to lose diagnostics upon implementing this feature, but outside of that it wastes too many cycles going back and forth like this over what is a pretty minimal feature. Stop wasting cycles arguing, and start posting patches

Re: The spewing problem.

2008-01-13 Thread Sam Vilain
Matisse Enzer wrote: Ok, why do you want to stop it as fast as possible when a failure occurs? So I can more quickly focus on fixing that first test failure. I use make test 21 | less Works for individual tests too make perl -Mblib t/testname.t 21 | less Sam.

Re: The spewing problem.

2008-01-12 Thread Sam Vilain
Michael G Schwern wrote: Paul Johnson wrote: This is something that I too have asked for in the past. I've even hacked up my own stuff to do it, though obviously not as elegantly as you or Geoff. Here's my use case. I have a bunch of tests that generally pass. I hack something

Re: Test::Aggregate - Speed up your test suites

2008-01-01 Thread Sam Vilain
Ovid wrote: Why not just load Perl once and fork for the execution of each test script. You can pre-load modules before you fork. Forking is also more likely to be used for parallelization. Often code requires sweeping changes before it can be run in parallel. So this means we're reduced

Re: Test::Aggregate - Speed up your test suites

2007-12-30 Thread Sam Vilain
Ovid wrote: If you have slow test suites, you might want to give it a spin and see if it helps. Essentially, it concatenates tests together and runs them in one process. Thus, you load Perl only once and load all modules only once. Yuck. Why not just load Perl once and fork for the

Re: TAP historical versions

2007-03-13 Thread Sam Vilain
Sam Vilain wrote: I just gave the cg- commands initially because I didn't want to write this git-core equivalent in public: mkdir perl cd perl git-init git-remote add catalyst git://git.catalyst.net.nz/perl.git git-config remote.catalyst.fetch \ '+refs/heads/restorical:refs

Re: TAP historical versions

2007-03-12 Thread Sam Vilain
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

Re: TAP historical versions

2007-03-12 Thread Sam Vilain
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