Specification based testing

2004-09-17 Thread Ovid
I'm at work, so I've not had a chance to think too deeply about this, but here's an interesting node about specification-based testing using Test::LectroTest (http://search.cpan.org/~tmoertel/Test-LectroTest-0.2006/) http://www.perlmonks.org/index.pl?node_id=390737 It looks like food for though

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Geoffrey Young
> You could use the values from Config.pm paul and I were talking about this on irc, wondering if there was some Config.pm value that would give the @INC that perl was compiled with. neither of us could find one, and when I started poking around as to create a patch, I fould that the logic the co

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Graham Barr
On 17 Sep 2004, at 15:48, Ricardo SIGNES wrote: * David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] So, what's to be lost by having the inc directories default to the contents of @INC when you load Devel::Cover rather than at install time? Presumably the problem is that by runtime, lib and bl

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread David Wheeler
On Sep 17, 2004, at 7:48 AM, Ricardo SIGNES wrote: Presumably the problem is that by runtime, lib and blib directories are already in @INC, so the things in your ./distro/lib/ won't be covered, defeating the point. Ah, good point. As to whether there is a simple way to resolve this, I haven't thoug

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Ricardo SIGNES
* David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] > So, what's to be lost by having the inc directories default to the > contents of @INC when you load Devel::Cover rather than at install > time? Presumably the problem is that by runtime, lib and blib directories are already in @INC, so

Re: [Devel::Cover] return conditions

2004-09-17 Thread Tels
-BEGIN PGP SIGNED MESSAGE- Moin, On Friday 17 September 2004 12:41, [EMAIL PROTECTED] wrote: > Incidentally, the original obfuscated code is pretty damn fast > if you expect to return False most of the time. I bet by removing the return statement it gets even faster: ala: ($one == $tw

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
Incidentally, the original obfuscated code is pretty damn fast if you expect to return False most of the time. Rate if_else - (F) space_ship - (F) space_ship (T) ternary - (F) if_else - (T) ret_1_or_ret_0 (T) ternary - (T) ret_1_or_ret_0 (F) (control) (F) (control) (T) i

Re: [Devel::Cover] return conditions

2004-09-17 Thread Dave Cross
On Fri, Sep 17, 2004 at 09:33:39AM +0100, [EMAIL PROTECTED] wrote: > > it's basically a confusing if else > > if ($one == $two) { return 1 } else { return 0 } Or return $one == $two; Dave... -- We are far too young and clever

[Devel::Cover] @INC at Runtime?

2004-09-17 Thread David Wheeler
Hi Paul (and everyone else), The Devel::Cover documentation says: The inc directories are initially populated with the contects of the @INC array at the time Devel::Cover was built. You may reset these directories using -inc, or add to them using +inc. However, now that new

Re: [Devel::Cover] return conditions

2004-09-17 Thread Tels
-BEGIN PGP SIGNED MESSAGE- Moin, On Friday 17 September 2004 10:56, [EMAIL PROTECTED] wrote: > But that would return '' or 1and presumably the author > wanted zero instead of an empty string. > > Cheers, Brent > On Fri, Sep 17, 2004 at 09:33:39AM +0100, [EMAIL PROTECTED] wrote: > > it's

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
But that would return '' or 1and presumably the author wanted zero instead of an empty string. Cheers, Brent - The entrepreneur is essentially a visualizer and an actualizer... He can visualize something and w

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
it's basically a confusing if else if ($one == $two) { return 1 } else { return 0 } - Love is everything. It is the key to [human] life, and its influences are those that move the world. -- Ralph Waldo Trine