[svn:perl6-synopsis] r10217 - doc/trunk/design/syn

[larry]

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/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jul 15 00:15:51 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 8 Mar 2004
-  Last Modified: 14 Jul 2006
+  Last Modified: 15 Jul 2006
   Number: 3
-  Version: 47
+  Version: 48
 
 =head1 Changes to existing operators
 
@@ -29,7 +29,8 @@
 =item * C<< -> >> becomes C<.>, like the rest of the world uses.
 
 =item * The string concatenation C<.> becomes C<~>.  Think of it as
-"stitching" the two ends of its arguments together.
+"stitching" the two ends of its arguments together.  String append
+is likewise C<~=>.
 
 =item * All postfix operators that do not start with a dot also have
 an alternate form that does.  (The converse does not hold--just because
@@ -50,17 +51,31 @@
 so you need C<$($foo[bar])> to mean the other way.
 
 =item * Bitwise operators get a data type prefix: C<+>, C<~>, or C.
-For example, C<|> becomes either C<+|> or C<~|> or C, depending on
-whether the operands are to be treated as numbers, strings, or boolean
-values.  Left shift C< << > becomes C< +< >, and correspondingly with
-right shift. Unary C<~> becomes either C<+^> or C<~^> or C, since a
-bitwise NOT is like an exclusive-or against solid ones.  Note that C
-is functionally identical to C.  C differs from C<||> in that
-C always returns a standard boolean value (either 1 or 0), whereas
-C<||> return the actual value of the first of its arguments that is
-true.  Bitwise string operators may only be applied to C types or
-similar compact integer arrays, and treat the entire chunk of memory
-as a single huge integer.
+For example, Perl 5's C<|> becomes either C<+|> or C<~|> or C,
+depending on whether the operands are to be treated as numbers,
+strings, or boolean values.  Perl 5's left shift C< << > becomes
+C< +< >, and correspondingly with right shift. Perl 5's unary C<~>
+(one's complement) becomes either C<+^> or C<~^> or C, since a
+bitwise NOT is like an exclusive-or against solid ones.  Note that
+C is functionally identical to C, but conceptually coerces to
+boolean first and then flips the bit.  Please use C instead.
+
+C is a logical OR but differs from C<||> in that C always
+evaluates both sides and returns a standard boolean value.  That is,
+it's equivalent to C<< ?$a + ?$b != 0 >>.  Another difference is that
+it has the precedence of an additive operator.
+
+C is a logical AND but differs from C<&&> in that C always
+evaluates both sides and returns a standard boolean value.  That is,
+it's equivalent to C<< ?$a * ?$b != 0 >>.  Another difference is that
+it has the precedence of a multiplicative operator.
+
+Bitwise string operators (those starting with C<~>) may only be
+applied to C types or similar compact integer arrays, and treat
+the entire chunk of memory as a single huge integer.  They differ from
+the C<+> operators in that the C<+> operators would try to convert
+the string to a number first on the assumption that the string was an
+ASCII representation of a number.
 
 =item * C splits into two operators: C (which concatenates repetitions 
 of a string to produce a single string), and C (which creates a list of 
@@ -108,7 +123,7 @@
 
 ($a,$b,$c) = 1,2,3;
 
-since list assignment operators are of assignment precedence to their left.
+since assignment operators are tighter than comma to their left.
 
 =item * The scalar assignment operator still parses as it did before, so
 
@@ -379,7 +394,8 @@
 in terms of C, so C<$a leg $b> is now defined as C<~$a cmp ~$b>.
 The sort operator still defaults to C rather than C.  The
 C<< <=> >> operator's semantics are unchanged except that it returns
-an C value as described above.
+an C value as described above.  In other words, C<< $a <=> $b >>
+is now equivalent to C<+$a cmp +$b>.
 
 =item * Binary C<< => >> is no longer just a "fancy comma".  It now
 constructs a C object that can, among other things, be used to
@@ -393,8 +409,9 @@
 is much more general now.  See "Smart matching" below for details.  (To catch
 "brainos", the Perl 6 parser defines an C<< infix:<=~> >> macro which always
 fails at compile time with a message directing the user either to use C<~~>
-or C<~=> instead, or to put a space between if they really wanted to assign
-a stringified value.)
+or C<~=> (string append) instead, or to put a space between if they
+really wanted to assign a stringified value.)  A negated smart match is
+spelled C.
 
 =item * "Unary" C<.> calls its single argument (which must a postfix operator)
 on C<$_>.  (It's not really a unary operator, so we put it in quotes.)
@@ -582,11 +599,22 @@
 =head1 Meta operators
 
 Perl 6's operators have been greatly regularized, f

[perl #39838] [PCC] mark non-returning functions with __attribute__((__noreturn__))

[via RT]

# 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 __attribute__((__noreturn__)).
All functions that don't return should be marked with this attribute.

("Parrot Cage Cleaners, assemble!")
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: CPANDB - was: Module::Dependency 1.84

[brian d foy]

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 of that locally so any program could use it.

Re: CPANDB - was: Module::Dependency 1.84

[brian d foy]

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.

Re: [perl #39838] [PCC] mark non-returning functions with __attribute__((__noreturn__))

[Andy Lester]

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 functions with a special flag  
comment, and then the headerizer will do the GCC magic.


xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Time for a Revolution

[Adam Kennedy]

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 mandate from Larry, 
I'd like to be sure I'm not obviously and completely wrong first.


And secondly, because even if I was ready to consult with the community 
about it (and don't worry, I most certainly will) I _right_now_ don't 
have the time to actually hold a detailed technical conversation over 
the length of a whole thread... or at all really.


And in a month, I should.

If I were to go into detail now, it would be vapour or the conversation 
would be noisy. If I just did a simple overview, I'd be pressed for details.


So for me at least, the only feasible methodology I've found to get a 
decent result is.


1. Think to myself
2. Proof of concept for myself
3. Consult with experts (here etc)
4. Realise my ideas sucked and revise them
5. Proof of concept for experts
6. Implement
7. Release to public

So yes, you'll be consulted.

That is all :)

Adam K

Re: Any Clue about Devel::Cover Error Message "Corrupted storable file (binary v2.7) at ../../lib/Storable.pm"

[Paul Johnson]

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 consider to send SIGKILL (2) to kill all the
> child processes before send SIGKILL (2) to kill parent
> process, do you think this may help?
> 
> (2) "Maybe you could send it something a little nicer
> which might allow to process to clean up.", any more
> detail suggestion and example will be appreciated!

I'm not quite sure what your environment looks like, so I can only give
some general suggestions at best.

If you can avoid signals completely, I would try to do that.  Maybe you
have some other method of IPC going on that you could use to use to send
a "kill yourself" command.

Singals in perl used not to be safe, that is they could lead to
corruption or crashes.  Since 5.8 they have been safe (providing you
haven't explicitly made them unsafe).  (Hopefully you are not using
5.6.)  So if you can send a signal which can be caught, and then set up
a signal handler which cleans up (if necessary) and then exists the
program, that should allow things to work better.  You might like to
consider USR1 or USR2 for this, if you are not already using them.  Or
you might prefer TERM.  In any case, you should ensure that it is a
signal which can be caught, which is not the case with KILL.

> (3) We might also consider to give some sleep time
> before destroy the test object, which causes process
> killing and cleaning up, but, is there a way we can
> know Devel::Cover has doen its work to write data?
> 
> (4) "Devel::Cover does its work in the very last END
> block.", does this mean that Devel::Cover will not
> write data until the main test process run to its end?

Sleeping, then killing won't work.  Although Devel::Cover collects data
the entire time a program is running (unless you turn it off at some
point), the data will not be saved until its END block is run.  This
will normally be the very last END block.  This means that unless you
let the program run to completion the coverage data will not be fully
saved.  You might hinder this process by calling _exit, calling exec,
sending SIGKILL or doing anything else that stops normal completion of
the program.

> For example, a perl test script loads the perl module
> that is under testing and excise the functions in that
> module, sometime the test script needs use "system" to
> call some other perl scripts (that also is under
> testing), Devel::Cover will not write data until the
> main test script reach its end point or exit? 

Correct.  But the scripts you are calling with system will not have any
coverage data collected unless you have arranged for that in some way.
And if you do that, the coverage data for those scripts will be written
as soon as the scripts exit.

> (5) Is there a way we can tell which data files (under
> structure folder?) have been corrupted?

Just try reading them with the retrieve method from Storable.  Better
yet, send me patches for Devel::Cover::DB::validate_db and
Devel::Cover::DB::is_valid to do something more than just check that one
file exists there ;-)  (Those methods should probably be merged too.)
(And sorry they are not already written.  I suspect something a little
more robust there might have saved you a bit of pain.)

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: TAP diagnostic syntax proposal

[A. Pagaltzis]

* 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 “actual/expected” pair
wins out over “have/want”, once again due to the fact that both
parts of the latter pair have so many different meanings.

F.ex. when translating to German, outside of idioms you’ll find
six translations of “actual” and just two of “expected”, but more
than a dozen for “have” and some 20-odd for “want”.

Regards,
-- 
Aristotle Pagaltzis // 

A note for test writers

[Leopold Toetsch]

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 # .Float
div P2, P2, P3
-   eq P2, 1, EQ4
+   .fp_eq( P2, 1.218293, EQ4)

300 / 246.246 just isn't 1 exactly

Fixing SKIP:

[Ovid]

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 particularly like that this is a silent failure, but I'm not sure of a 
robust way to fix that.  In any event, I reread the docs a couple of times 
before I realized I was being stupid.  That suggests to me that this little nit 
could be improved.

Cheers,
Ovid
 
-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Fixing SKIP:

[David Wheeler]

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 skip() should be updated to ensure that the second argument  
=~ /^\d+$/;


Best,

David

Fw: Fixing SKIP:

[Ovid]

- 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 example wrong because it it *reads* wrong even 
if it's right.  It should have read:
 
 skip 1, "I'm lazy and don't wanna run no tests" if 1;
 
 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.
 
 Cheers,
 Ovid
 
-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Fixing SKIP:

[Ovid]

- 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 the skip 
message must not consist solely of a positive integer, then we're OK.  Will 
that break anything out there?

Cheers,
Ovid
 
-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Fixing SKIP:

[David Wheeler]

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

Re: Fixing SKIP:

[chromatic]

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 numeric and the second doesn't.

-- c

Re: [perl #39760] make warnings (r13197 - x86-msvc-7.1)

[Ron Blaschke]

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
> compilers\imcc\imcparser.c(878) : warning C4273: 'malloc' :
> inconsistent dll linkage
> compilers\imcc\imcparser.c(885) : warning C4273: 'free' : inconsistent
> dll linkage
> 
> compilers\ast\astparser.c
> astparser.c
> compilers\ast\astparser.c(1298) : warning C4102: 'yyerrlab1' :
> unreferenced label
> 
> compilers\imcc\main.c
> main.c
> compilers\imcc\main.c(480) : warning C4273: 'imcc_init' : inconsistent
> dll linkage

In the current head (r13307) imcparser.c seems to be mostly fine.

compilers\imcc\imcparser.c
imcparser.c
compilers/imcc/imcparser.c(4098) : warning C4102: 'yyerrlab1' :
unreferenced label

But compilers/imcc/main.c still suffers.

compilers\imcc\main.c
main.c
compilers\imcc\main.c(480) : warning C4273: 'imcc_init' :
inconsistent dll linkage

Attached patch brings the declarations of imcc_init in main.c and imc.h
in sync.

compilers\imcc\main.c
main.c

Ron
Index: compilers/imcc/main.c
===
--- compilers/imcc/main.c   (revision 13307)
+++ compilers/imcc/main.c   (working copy)
@@ -477,7 +477,7 @@
 }
 }
 
-extern void imcc_init(Parrot_Interp interp);
+PARROT_API extern void imcc_init(Parrot_Interp interp);
 
 int
 main(int argc, char * argv[])

Re: [perl #39760] make warnings (r13197 - x86-msvc-7.1)

[Leopold Toetsch]

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

Re: Fw: Fixing SKIP:

[Jonathan Rockway]

> 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:

ok$foo == $bar, $REASON;
is$foo,   $bar, $REASON;
is_deeply $foo,   $bar, $REASON;

And then this:

skip $REASON, $num;

Sadly, it would be hard to change that since so many people use the
"wrong" syntax.

Re-reading the man page, it looks like isa_ok and can_ok can't even
accept a test description?

Regards,
Jonathan Rockway



signature.asc
Description: OpenPGP digital signature

Re: Fw: Fixing SKIP:

[Ovid]

- 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 $foo,   $bar, $REASON;
>
> And then this:
>
> skip $REASON, $num;
>
> Sadly, it would be hard to change that since so many people use the
> "wrong" syntax.
>
> 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.

isa_ok can *sort* of accept a description which is why I often do this:

  isa_ok $object, 'Foo::Bar', '... and the object';

And the output reads:

  ok 7 - ... and the object isa Foo::Bar

It's a kludge, but I like my test output to read sensibly.
 
Cheers,
Ovid


-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Regards,
Jonathan Rockway

Re: [perl #39760] make warnings (r13197 - x86-msvc-7.1)

[Ron Blaschke]

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.  The clue was only a
few lines up: C<#include "imc.h">.  Sorry about that, and thanks for
fixing it.

> leo

Ron

Re: [perl #39759] [NEW] Util tool - search for opcodes

[João Cruz Morais]

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 INternet Cafe.
I'll apply your patch after July 25th, when I'm back in Germany.

Best regards,
  Bernhard


  

use Tests; # ?

[Ovid]

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, $description;
  skip $number, $description;
 
Just doing this:

  use Tests;

Would import the Test::More equivalents.

Thoughts?

Cheers,
Ovid

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: [perl #39760] make warnings (r13197 - x86-msvc-7.1)

[Ron Blaschke]

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\ast\astparser.c(1298) : warning C4102: 'yyerrlab1' :
> unreferenced label

compilers/ast/astparser.c is generated by GNU Bison 1.875.  I have GNU
Bison 2.1 installed, which generates code that doesn't yield any warning.

bison -v -y compilers\ast\ast.y -d -o compilers\ast\astparser.c
-p AST
C:\Perl\bin\perl.exe -MExtUtils::Command -e touch
compilers\ast\ast.y.flag compilers\ast\astparser.c
compilers\ast\astparser.h
bison -v -y compilers\ast\ast.y -d -o compilers\ast\astparser.c
-p AST
C:\Perl\bin\perl.exe -MExtUtils::Command -e touch
compilers\ast\ast.y.flag compilers\ast\astparser.c
compilers\ast\astparser.h
compilers\ast\astparser.c
astparser.c


Is that sufficient to close this issue, or should I provide a patch to
disable the C4102 warning?

Ron

Re: A note for test writers

[jerry gay]

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 # .Integer
set P3, 246.246 # .Float
div P2, P2, P3
-   eq P2, 1, EQ4
+   .fp_eq( P2, 1.218293, EQ4)

300 / 246.246 just isn't 1 exactly


i'm pretty sure this was intended for p6i, not p6l, so i'm forwarding it there.
~jerry

binding operators and related introspection

[Darren Duncan]

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','$y','$z'\n"; # output: x,y,z are 'foo','bar','bar'

That makes sense of course, and is what people would want most of the time.

But I would also like to have an easy way to change all bindings to 
the same variable at once to point to the same new variable. 
Essentially an easy way for us to implement ourselves the run-time 
folding that I raised in the "optimizing with === immutable 
comparitor" thread.  I would like for this to work:


  my $x = 'foo';
  my $y = 'bar';
  my $z := $x;# $x and $z point to same 'foo', $y to a 'bar'
  $z.rebind_all_aliases_to( $y ); # $x and $y and $z all point to 'bar'

Alternately or in addition to the last line, if something like this could work:

  for $z.aliases -> $z_alias {
$z_alias := $y;
  }
  # now $x and $y and $z all point to 'bar'

Unless something like this could be available for use, it would be 
impractical to implement run time folding just using := since we 
could end up in a tug of war situation if folding comparisons between 
pairs drawn from a pool of all equal elements were not done in 
exactly the right sequence.


-- Darren Duncan

Re: Fw: Fixing SKIP:

[Jonathan Rockway]

>> 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 you just do:

can_ok($object, $_, "can object $_?") for @methods;

This would then run (scalar @methods) tests, but I'd think you'd want
that anyway.  It doesn't make sense for a test for ->can("foo") to fail
when ->can("bar") fails.

Regards,
Jonathan Rockway




signature.asc
Description: OpenPGP digital signature

Re: use Tests; # ?

[chromatic]

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;
>
> Would import the Test::More equivalents.
>
> Thoughts?

I like everything except overriding the names.  I think that would add to the 
confusion, especially more than a screen length away from the use line.

How about different names?

-- c

Re: Fw: Fixing SKIP:

[A. Pagaltzis]

* 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 // 

Re: use Tests; # ?

[Michael G Schwern]

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 conflicts.

In fact you lose the ability to pass in any import routines.

And where do you set the plan?



By default, it would also provide the Test::More tests but it should also 
normalize sub behavior:


Write Test::More::Normalized or something.


  can_ok $proto, $method, $description;
  isa_ok $instance, $class, $description;


What problem are you trying to solve here?

Is the slightly different interface from the rest of Test::More really
a problem?  They still don't line up with everything else as they're
not of the form foo_ok $got, $expected, $description.

Is their interface being slightly different a bigger problem than the
one you're introducing by changing the interface from how it works
everywhere else?  The user will now have to remember "can_ok works
like *that* except when I'm using Tests in which case it works like
*that*".  I would suggest instead providing new functions with
different names than changing the way the old ones work.

It introduces a porting problem.  One cannot simply slap "use Tests"
at the top of an existing script.

Presumably isa_ok()'s $description now becomes free form.  What sort
of free form $descriptions do you want to put in there?  Does isa_ok
$obj, $class or diag($description) solve the same problem?  Ditto
can_ok's lack of a description.

Finally, the interfaces are different for a reason.  You often want to
test a big list of methods with can_ok().  isa_ok() has a pretty
narrow range of possible descriptions.



  skip $number, $description;


$number is optional when 'no_plan' is on which would lead to things like:

   skip undef, "foo";

or magic such as:

   skip $description;
   skip $number, $description;

where skip() guesses what you meant by the contents of the first argument.

Yuck.

[perl #39844] [BUG] Parrot doesn't do args checking for a sub without params

[via RT]

# 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":

   .sub main :main
 test("foo", "bar")
 end
   .end

   .sub test
 print "ok\n"
 .return()
   .end

--
Matt Diephouse

[perl #39845] [TODO] Better IMCC Errors: unexpected IDENTIFIER

[via RT]

# 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 say what the unexpected identifier was. This is  
painful for debugging compilers and should be fixed.

   mini:~/Projects/parrot mdiep$ cat test.pir
   .sub main :main
 $I0 = $I1 - foo
 end
   .end

   mini:~/Projects/parrot mdiep$ parrot test.pir
   error:imcc:syntax error, unexpected IDENTIFIER
   in file 'test.pir' line 2
   mini:~/Projects/parrot mdiep$

--
Matt Diephouse