On Dec 30, 2007, at 8:32 PM, Sam Vilain wrote:
I suggested an approach
which addresses some of the self-admitted issues. Please understand
my
comment in view of the entire post, not just your initial reaction to
the first line of it.
With all due respect, the first line was kinda harsh -
# from Sam Vilain
# on Sunday 30 December 2007 18:24:
>> Essentially, it concatenates tests together and runs them
>> in one process.
>> ...
>Yuck.
>
>Why not just load Perl once and fork for the execution of each test
>script.
I think most approaches of this nature are going to fall into one for
On Dec 30, 2007, at 10:32 PM, Sam Vilain wrote:
Yuck.
I think this wins the Least Helpful Response To Someone Who Has
Provided A New Module For Everyone To Use. Bravo!
Please don't quote me out of context again.
Doesn't need any context. Responding "yuck" to someone's module is
like
Andy Lester 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.
>
>
> I think this
On Dec 30, 2007, at 8:24 PM, Sam Vilain wrote:
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.
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 exec
Andreas J. Koenig wrote:
>> On Mon, 24 Dec 2007 17:26:47 +, David Cantrell <[EMAIL PROTECTED]>
>> said:
> dc> Personally
> dc> I'd prefer to at least have the opportunity to fix my modules before
> dc> ordinary users (who never touch a dev perl) will ever see the problem.
> As autho
