On 7/15/06, Ovid <[EMAIL PROTECTED]> wrote:
Just a thought:
use Tests qw/
Exception
Differences
/;
Have it import those modules and check for sub conflicts.
This doesn't really buy you anything over:
use Test::Exception;
use Test::Differences;
That already warns on import
* Jonathan Rockway <[EMAIL PROTECTED]> [2006-07-16 00:45]:
> > can_ok cannot accept a description because it accepts a list.
>
> This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]).
I do not think that prototype means what you think it means.
Regards,
--
Aristotle Pagaltzis /
On Saturday 15 July 2006 14:43, Ovid wrote:
> By default, it would also provide the Test::More tests but it should also
> normalize sub behavior:
>
> can_ok $proto, $method, $description;
> isa_ok $instance, $class, $description;
> skip $number, $description;
>
> Just doing this:
>
> use
>> Re-reading the man page, it looks like isa_ok and can_ok can't even
>> accept a test description?
>
> can_ok cannot accept a description because it accepts a list.
This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]).
What's the reasoning behind accepting an array, anyway?
Just a thought:
use Tests qw/
Exception
Differences
/;
Have it import those modules and check for sub conflicts. By default, it would
also provide the Test::More tests but it should also normalize sub behavior:
can_ok $proto, $method, $description;
isa_ok $instance, $class, $de
- Original Message
From: Jonathan Rockway <[EMAIL PROTECTED]>
To: Perl QA List
Sent: Saturday, July 15, 2006 9:33:42 PM
Subject: Re: Fw: Fixing SKIP:
> Worse, it's inconsistent with the rest of the API:
>
> ok$foo == $bar, $REASON;
> is$foo, $bar, $REASON;
> is_deeply $
> That's incorrect, even though saying "skip X tests" reads naturally
> to me. Since "skip this many for tis reason" is how I mentally think
> of SKIP: blocks, I keep writing them like that, even though it's
> wrong. As mentioned, it fails silently.
Worse, it's inconsistent with the rest of the
On Saturday 15 July 2006 11:35, Ovid wrote:
> If the docs are updated to indicate that the skip message must not consist
> solely of a positive integer, then we're OK. Will that break anything out
> there?
Perhaps if you check both arguments, and then issue a warning if the first
looks solely n
On Jul 15, 2006, at 11:35, Ovid wrote:
That was my initial thought, but there's nothing explicitly wrong
with having a numeric skip message.
No, I said make sure that the *second* argument is numeric. It must
always indicate the number of tests to be skipped.
Best,
David
- Original Message
From: David Wheeler <[EMAIL PROTECTED]>
> Perhaps skip() should be updated to ensure that the second argument
> =~ /^\d+$/;
That was my initial thought, but there's nothing explicitly wrong with having a
numeric skip message. If the docs are updated to indicate tha
On Jul 15, 2006, at 10:52, Ovid wrote:
That's incorrect, even though saying "skip X tests" reads
naturally to me. Since "skip this many for tis reason" is how I
mentally think of SKIP: blocks, I keep writing them like that, even
though it's wrong. As mentioned, it fails silently.
Perha
- Forwarded Message
From: Ovid <[EMAIL PROTECTED]>
> I have returned to working on the tap parser and stumbled across this
> irritation:
>
> #!/usr/bin/perl
>
> use Test::More tests => 1;
> SKIP: {
>skip "I'm lazy and don't wanna run no tests", 1 if 1;
Well, naturally I had to
I have returned to working on the tap parser and stumbled across this
irritation:
#!/usr/bin/perl
use Test::More tests => 1;
SKIP: {
skip "I'm lazy and don't wanna run no tests", 1 if 1;
ok 1, 'We don't get to here';
}
That produces the output:
1..1
# No tests run!
I don't
* Adam Kennedy <[EMAIL PROTECTED]> [2006-07-15 05:55]:
> Whatever "standard diagnostic" set we dictate, we can't
> localise it, so we should be aiming for language which is
> maximally clear and comprehendable by non-native speakers.
This is a very good point.
I also think it’s another one where
On Sat, Jul 08, 2006 at 03:44:55PM -0700, Scott Wang wrote:
> Thanks Paul!
>
> (1) Yes, we do send SIGKILL (9) to kill the parent
> process even the child processes are still running and
> our purpose is to have a clean kill from "root", so,
> do you think send SIGKILL (2) will be better? or, we
Why? Oh, why do people lately insist on offering up enticing tidbits of
/what is to be the next great ordained (core|6pan|etc)/ without offering
the community a chance to comment or participate? =(
Randy.
Well, in this case two reasons.
Firstly, although I have what I hope is a tentative man
In article <[EMAIL PROTECTED]>, Tels
<[EMAIL PROTECTED]> wrote:
> My real-grand-plan was always to have a CPANDB module that does exactly the
> following:
I think the latest version of my cpan(1) script does everything you
show, although it doesn't use a local database. It would be nice to
have
In article <[EMAIL PROTECTED]>, Tels
<[EMAIL PROTECTED]> wrote:
>> I am not sure what "stupid" consists, but my system wouldn't have
problems
> handling 512 MB of memory.
I'd prefer that you not decide that my system needs 512Mb to use this,
even if you can handle that on your side.
18 matches
Mail list logo
