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
==
---
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #39838]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39838
Some compilers have flags to mark functions that don't return.
For example, GCC
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 all
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
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
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
could
* 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 the
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.
Perhaps
- 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 get the
- 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 that
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39760
compilers\imcc\imcparser.c
imcparser.c
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 API:
- Original Message
From: Jonathan Rockway [EMAIL PROTECTED]
To: Perl QA List perl-qa@perl.org
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;
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 thought.
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
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,
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39760
compilers\ast\astparser.c
astparser.c
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
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? Can't
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 Tests;
* 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
29 matches
Mail list logo
