Re: Failing test on Windows

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.

Re: Failing test on Windows

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 open to

Re: Failing test on Windows

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

Re: New Kwalitee Metric?

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?

Re: Failing test on Windows

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

Re: Failing test on Windows

--- 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. Cheers,

Re: Sparse Test Output

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 would

Re: Sparse Test Output

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 store those

Re: Sparse Test Output

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 few

Re: Sparse Test Output

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 didn't

Re: Sparse Test Output

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 store those

Re: Sparse Test Output

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 sys