[perl #55304] [PATCH] eval_(dies|lives)_ok methods for rakudo's Test.pm, and more tests
# New Ticket Created by Moritz Lenz # Please include the string: [perl #55304] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55304 Attached patch, mostly courtesy Vasily bacek Chekalkin, adds the eval_lives_ok and eval_dies_ok methods to Test.pm, and adds three more passing tests to 'make spectest_regression'. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #55338] sub form of WHAT() missing
# New Ticket Created by Moritz Lenz # Please include the string: [perl #55338] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55338 rakudo as of r28087 doesn't implement the sub form fo WHAT() (S12:1862). (This is the first of a series of tickets that pmichaud wants for missing features in rakudo that are used in the test suite). -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Clarification on S12
This message is looking for a clarification/confirmation.
S12:207 says:
To call an ordinary method with ordinary method-dispatch semantics,
use either the dot notation or indirect object notation:
$obj.doit(1,2,3)
doit $obj: 1,2,3
If the method was not found, it will fall back to a subroutine call
instead, with the invocant becoming the first positional argument.
Does fall back to a subroutine occur anytime we don't have
a method with a matching signature? For example, if we have
class Foo {
multi method bar(Num $x) { say Foo::bar; }
}
sub bar(Int $x) { say sub bar; }
my $foo = Foo.new;
$foo.bar(3);
In this case do we still fall back to the subroutine call? How
about if the method isn't a multimethod (or if the sub is a multisub)?
Thanks,
Pm
Re: Clarification on S12
Qui, 2008-06-05 às 11:04 -0500, Patrick R. Michaud escreveu:
Does fall back to a subroutine occur anytime we don't have
a method with a matching signature? For example, if we have
as far as I understand it, it only falls back to sub-dispach if the
method dispatch would otherwise fail, which basically means...
class Foo {
multi method bar(Num $x) { say Foo::bar; }
}
sub bar(Int $x) { say sub bar; }
my $foo = Foo.new;
$foo.bar(3);
since Num.ACCEPTS(3) should return true (rakudo is failing that), the
method dispatching should be successfull, therefore no fallback occurs.
daniel
[perl #55350] exp() suffers from low precision
# New Ticket Created by Moritz Lenz # Please include the string: [perl #55350] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55350 Rakudo as of r28105 suffers from low precision in its exp() function. rakudo: say exp(5) - 148.4131591025766 0.000159103 perl -wle 'print exp(5) - 148.4131591025766' 0 Mathematica agrees with perl 5: In[1] := N[Exp[5], 20] Out[1] = 148.41315910257660342 This makes one test fail in t/spec/S29-num/exp.t I don't know if that's a parrot or a rakudo bug, so please forward if necessary. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #55346] [PATCH] tool for checking if '# pure' files still contain fudging
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #55346]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55346
Attached patch adds a script to tools/ that walks through a test
specification file (t/spectest_regression.data by default) and prints a
list of files that are marked as pure, but still contain '#?rakudo'
fudge directives.
particle++ for suggesting it.
It's only tested under linux so far, so please also test on MacOS and
Windows before applying.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Index: MANIFEST
===
--- MANIFEST (revision 28098)
+++ MANIFEST (working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Wed Jun 4 20:37:00 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Thu Jun 5 15:13:47 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -1961,6 +1961,7 @@
languages/perl6/t/harness [perl6]
languages/perl6/t/pmc/mutable.t [perl6]
languages/perl6/t/spectest_regression.data [perl6]
+languages/perl6/tools/fudge_purity_inspector.pl [perl6]
languages/perl6/tools/update_passing_test_data.pl [perl6]
languages/pheme/MAINTAINER [pheme]
languages/pheme/MANIFEST[pheme]
Index: languages/perl6/tools/fudge_purity_inspector.pl
===
--- languages/perl6/tools/fudge_purity_inspector.pl (revision 0)
+++ languages/perl6/tools/fudge_purity_inspector.pl (revision 0)
@@ -0,0 +1,39 @@
+#! perl -w
+# Copyright (C) 2008, The Perl Foundation.
+# $Id$
+use strict;
+use warnings;
+
+my $input_file = shift @ARGV || 't/spectest_regression.data';
+my $impl = 'rakudo';
+
+open my $fh, '', $input_file
+or die Can't open '$input_file' for reading: $!;
+
+print The following files, if any, contain fudge directives,\n;
+print although they are marked as pure:\n;
+
+while ($fh){
+chomp;
+next if m/^#/ || m/^\s*$/;
+my ($file, $comment) = split m/\s*#\s*/;
+if ($comment $comment eq 'pure'){
+check_file_and_warn($file);
+}
+}
+
+sub check_file_and_warn {
+my $filename = shift;
+$filename = t/spec/$filename;
+#warn checking file $filename\n;
+open my $fh, '', $filename
+or die Can't opne file '$filename' for reading: $!;
+my $re = qr{^\s*#\?$impl};
+while ($fh) {
+if (m/$re/){
+print $filename, \n;
+last;
+}
+}
+close $fh;
+}
Property changes on: languages/perl6/tools/fudge_purity_inspector.pl
___
Name: svn:mime-type
+ text/plain; charset=UTF-8
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Re: Clarification on S12
Patrick R. Michaud wrote:
On Thu, Jun 05, 2008 at 05:29:25PM +0100, Daniel Ruoso wrote:
Qui, 2008-06-05 às 11:04 -0500, Patrick R. Michaud escreveu:
Does fall back to a subroutine occur anytime we don't have
a method with a matching signature? For example, if we have
as far as I understand it, it only falls back to sub-dispach if the
method dispatch would otherwise fail, which basically means...
class Foo {
multi method bar(Num $x) { say Foo::bar; }
}
sub bar(Int $x) { say sub bar; }
my $foo = Foo.new;
$foo.bar(3);
since Num.ACCEPTS(3) should return true (rakudo is failing that), the
method dispatching should be successfull, therefore no fallback occurs.
Okay, so my bad example didn't provide an answer to my
original question. Let's try it this way:
class Foo {
multi method bar(Dog $x) { say Foo::bar; }
}
sub bar(Int $x) { say sub bar; }
my $foo = Foo.new;
$foo.bar(3);
In this case, since Foo has a bar method (but not one matching Int),
do we still fall back to the subroutine call?
We can't, because the subroutine call takes the invocant as the first
positional argument. If it should fall back (and I don't know if it
does), you have to declare sub bar(Foo $w, Int $x){ say sub bar }
How about if the method
isn't a multimethod (or if the sub is a multisub)?
Pm
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Clarification on S12
On Thu, Jun 05, 2008 at 10:45:08PM +0200, Moritz Lenz wrote:
Okay, so my bad example didn't provide an answer to my
original question. Let's try it this way:
class Foo {
multi method bar(Dog $x) { say Foo::bar; }
}
sub bar(Int $x) { say sub bar; }
my $foo = Foo.new;
$foo.bar(3);
In this case, since Foo has a bar method (but not one matching Int),
do we still fall back to the subroutine call?
We can't, because the subroutine call takes the invocant as the first
positional argument. If it should fall back (and I don't know if it
does), you have to declare sub bar(Foo $w, Int $x){ say sub bar }
You're correct, my examples suck today. Sorry about that.
The I don't know if it does part of your answer is the crux of my
question. Essentially, does having _any_ 'bar' multimethod in a
class automatically suppress a fall back to a subroutine call,
even if none of the multimethods' signatures match?
Pm
Re: [perl #55304] [PATCH] eval_(dies|lives)_ok methods for rakudo's Test.pm, and more tests
Moritz Lenz wrote:
Oops, forgot to attach patch. Now it's really there.
Your implementations of eval_lives_ok and eval_dies_ok seem
inconsistent. eval_lives_ok uses try and eval_dies_ok does not. The
two implementations may catch different types of exceptions. I am
proposing the patch below:
$ svn diff Test.pm
Index: Test.pm
===
--- Test.pm (revision 28117)
+++ Test.pm (working copy)
@@ -122,17 +122,20 @@
lives_ok($closure, '');
}
+sub eval_exception ($code) {
+my $eval_exception;
+try { eval ( $code ); $eval_exception = $! }
+$eval_exception // $!;
+}
multi sub eval_dies_ok($code, $reason) {
-eval ( $code );
-proclaim((defined $!), $reason);
+proclaim((defined eval_exception($code)), $reason);
}
multi sub eval_dies_ok($code) {
eval_dies_ok($code, '');
}
multi sub eval_lives_ok($code, $reason) {
-try { eval ($code) }
-proclaim((not defined $!), $reason);
+proclaim((not defined eval_exception($code)), $reason);
}
multi sub eval_lives_ok($code) {
eval_lives_ok($code, '');
Re: [perl #55304] [PATCH] eval_(dies|lives)_ok methods for rakudo's Test.pm, and more tests
Ronald Schmidt wrote:
Moritz Lenz wrote:
Oops, forgot to attach patch. Now it's really there.
Your implementations of eval_lives_ok and eval_dies_ok seem
inconsistent. eval_lives_ok uses try and eval_dies_ok does not. The
two implementations may catch different types of exceptions. I am
proposing the patch below:
Good catch. Actually I already encountered I problem with these two
subs, but haven't got around to fix it so far.
Are there any exceptions that are not caught by eval?
Currently rakudo seems to catch every run time exception, but parse
failures still throw an exception. I'm pretty sure that's wrong, because
it's contrary to Perl 6's exception philosophy.
So eval() needs more work, but in the mean time your patch works just
fine (and it will continue to work when eval is fixed), so I vote +1 here.
Cheers,
Moritz
$ svn diff Test.pm
Index: Test.pm
===
--- Test.pm (revision 28117)
+++ Test.pm (working copy)
@@ -122,17 +122,20 @@
lives_ok($closure, '');
}
+sub eval_exception ($code) {
+my $eval_exception;
+try { eval ( $code ); $eval_exception = $! }
+$eval_exception // $!;
+}
multi sub eval_dies_ok($code, $reason) {
-eval ( $code );
-proclaim((defined $!), $reason);
+proclaim((defined eval_exception($code)), $reason);
}
multi sub eval_dies_ok($code) {
eval_dies_ok($code, '');
}
multi sub eval_lives_ok($code, $reason) {
-try { eval ($code) }
-proclaim((not defined $!), $reason);
+proclaim((not defined eval_exception($code)), $reason);
}
multi sub eval_lives_ok($code) {
eval_lives_ok($code, '');
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Clarification on S12
On Thu, Jun 05, 2008 at 11:04:52AM -0500, Patrick R. Michaud wrote: : This message is looking for a clarification/confirmation. : S12:207 says: : : To call an ordinary method with ordinary method-dispatch semantics, : use either the dot notation or indirect object notation: : : $obj.doit(1,2,3) : doit $obj: 1,2,3 : : If the method was not found, it will fall back to a subroutine call : instead, with the invocant becoming the first positional argument. : : Does fall back to a subroutine occur anytime we don't have : a method with a matching signature? For example, if we have Maybe it's just a temporary lack of imagination, but I'm having trouble these days coming up with any kind of a use case for confusing single dispatch with multiple dispatch. Yeah, I know I wrote that, but I was either smarter or stupider back then... Larry
Re: Clarification on S12
On 2008 Jun 5, at 18:43, Larry Wall wrote: Maybe it's just a temporary lack of imagination, but I'm having trouble these days coming up with any kind of a use case for confusing single dispatch with multiple dispatch. Yeah, I know I wrote that, but I was either smarter or stupider back then... p5 backward compatibility? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
