# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39845]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39845 >
When IMCC encounters an unexpected identifier, it throws an error,
but it doesn't sa
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39844]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39844 >
I expect this to die with a "too many args" error, but it doesn't --
it prints "ok":
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?
After confirming between Synopsis 3 and the newest Pugs that the
binding operator := works as follows ...
my $x = 'foo';
my $y = 'bar';
my $z := $x;# $x and $z point to same 'foo', $y to a 'bar'
$z := $y; # $y and $z point to the same 'bar', $x to a 'foo'
print "x,y,z are '$x
On 7/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Folks,
Please always verify test results, don't use the Parrot output of the test as
the expected output.
If you are implementing a new feature, write the *test first*.
Thanks,
leo
PS from r13305:
@@ -1324,7 +1324,7 @@
set P2, 300
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
Jerry Gay (via RT) wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #39760]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39760 >
>
> compilers\ast\astparser.c
> astparser.c
> compilers\as
No problem, enjoy your vacation :)
João
Bernhard Schmalhofer via RT wrote:
On Fr. 07. Jul. 2006, 07:53:22, [EMAIL PROTECTED] wrote:
đ
Hi João,
sorry for being so late in answering your ticket. But I'm on vacation in
Istria without Internet connection and I only now got around to hitting
an INte
- 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 $
Leopold Toetsch wrote:
> Am Samstag, 15. Juli 2006 21:27 schrieb Ron Blaschke:
>
>> Attached patch brings the declarations of imcc_init in main.c and imc.h
>> in sync.
>
> Well, much simpler - I've deleted the line in main.c :-)
> Thanks for the hint.
Bummer, should have given the patch more tho
> 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
Am Samstag, 15. Juli 2006 21:27 schrieb Ron Blaschke:
> Attached patch brings the declarations of imcc_init in main.c and imc.h
> in sync.
Well, much simpler - I've deleted the line in main.c :-)
Thanks for the hint.
> Ron
leo
Jerry Gay (via RT) wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #39760]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39760 >
>
>
> compilers\imcc\imcparser.c
> imcparser.c
> compiler
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
- 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
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
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
Folks,
Please always verify test results, don't use the Parrot output of the test as
the expected output.
If you are implementing a new feature, write the *test first*.
Thanks,
leo
PS from r13305:
@@ -1324,7 +1324,7 @@
set P2, 300 # .Integer
set P3, 246.246
* 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
On Jul 15, 2006, at 2:43 AM, Chip Salzenberg (via RT) wrote:
Some compilers have flags to mark functions that don't return.
For example, GCC uses __attribute__((__noreturn__)).
All functions that don't return should be marked with this attribute.
This will happen. Humans will mark the functi
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.
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
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #39838]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39838 >
Some compilers have flags to mark functions that don't return.
For example, GCC uses
Author: larry
Date: Sat Jul 15 00:15:51 2006
New Revision: 10217
Modified:
doc/trunk/design/syn/S03.pod
Log:
More clarifications, many suggested by dduncan++.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/d
31 matches
Mail list logo
