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
# 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
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.
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
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 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
* 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
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
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
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
- 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 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
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
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
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
> 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
- 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
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
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
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
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
>> 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?
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
* 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 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
# 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":
# 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
31 matches
Mail list logo
