On Tue, Oct 24, 2006 at 08:08:45PM -0400, Christopher H. Laco wrote:
> With most modules, I agree. But with utility modules like
> Module::Pluggable, File::Find::Recursive, etc, not working under taint
I'd be surprised if the author of Module::Pluggable wasn't open to patches
to fix this.
Nicho
Nicholas Clark wrote:
> On Tue, Oct 24, 2006 at 08:08:45PM -0400, Christopher H. Laco wrote:
>
>> With most modules, I agree. But with utility modules like
>> Module::Pluggable, File::Find::Recursive, etc, not working under taint
>
> I'd be surprised if the author of Module::Pluggable wasn't ope
I think planning and testing your modules under -T is just being a good
CPANizen; just like warnings/strict and writing pod.
Hey, that could be the next optional metrics for CPANTS:
run_under_taint. A bonus point for the ones that cared about it. It
makes me afraid because all my code complains
On Oct 24, 2006, at 9:32 AM, David Golden wrote:
I think characterizing "the basics" as being based on Module::Starter
is a little too module-specific for starters. Do you want to also
make sure that there are files other than the boilerplate created by
all the other module skeleton modules? W
Adriano Rodrigues wrote:
I think planning and testing your modules under -T is just being a good
CPANizen; just like warnings/strict and writing pod.
Hey, that could be the next optional metrics for CPANTS:
run_under_taint. A bonus point for the ones that cared about it. It
makes me afraid beca
--- Adam Kennedy <[EMAIL PROTECTED]> wrote:
> I guess the tricky bit is measuring it, do we just look for -T in the
> test scripts?
That's how Test::Harness and TAPx::Harness do it. See
&Test::Harness::Straps::_switches or
&TAPx::Parser::Source::Perl::_switches. They're virtually identical.
Ch
> I'm with Adrian. Printing out "ok" 100,000 times shouldn't be a
> big deal unless you're reading the TAP via some sort of IP over
> clay tablets protocol. But...
My test estimate is two orders of magnitude larger, so it actually is
a big deal to capture and store those results.
But I woul
Paul Beckingham wrote:
>> I'm with Adrian. Printing out "ok" 100,000 times shouldn't be a
>> big deal unless you're reading the TAP via some sort of IP over
>> clay tablets protocol. But...
>
> My test estimate is two orders of magnitude larger, so it actually is a
> big deal to capture and stor
Christopher H. Laco wrote:
> I'm in the same boat. Recently, I've started testing my environment when
> things go wrong. (I blame Andy). I have one test alone that has a test
> count of 500,000+. That's a lot of oks to be processed, when I only want
> the ones that didn't pass.
>
> Now, add in a f
Michael G Schwern wrote:
> Christopher H. Laco wrote:
>> I'm in the same boat. Recently, I've started testing my environment when
>> things go wrong. (I blame Andy). I have one test alone that has a test
>> count of 500,000+. That's a lot of oks to be processed, when I only want
>> the ones that di
Paul Beckingham wrote:
>> I'm with Adrian. Printing out "ok" 100,000 times shouldn't be a
>> big deal unless you're reading the TAP via some sort of IP over
>> clay tablets protocol. But...
>
> My test estimate is two orders of magnitude larger, so it actually is a
> big deal to capture and stor
Michael G Schwern wrote:
> It does add significant overhead. Here's the example of one of
> Regexp::Common's tests.
>
> 0 windhund /private/var/local/cpan_shell/build/Regexp-Common-2.120$ time perl
> -Ilib ~/tmp/strip_ok t/number/integer.t
> 1..23534
>
> real0m4.882s
> user0m5.469s
>
12 matches
Mail list logo
