[perl #60490] Rakudo doesn't report an error on log(0)
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #60490] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=60490 > Rakudo r32568: $ ./perl6 -e 'my $result = log(0); say "Still alive after getting $result"' Still alive after getting -inf S29: =item log our Num multi method log ( Num $x: Num :$base = Num::e ) is export Logarithm of base C<$base>, default Natural. Calling with C<$x == 0> is an error. (Since log is periodic along the imaginary axis, an error should perhaps be thrown for other complex values as well, provided that enough precision can be achieved to make this a problem.)
[perl #60482] Rakudo dies strangely on .trans call in for loop on .split result
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #60482]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60482 >
...but now I've found something. seriously!
rakudo: say "foo\nbar\nbaz".trans([ /\s+/ => " " ])
rakudo 32543: OUTPUT[foo bar baz]
all good, yes?
now look:
rakudo: for "foo\nbar\nbaz".split( /\n ** 2..*/ ) { say
.trans([ /\s+/ => " " ]) }
rakudo 32543: OUTPUT[too few arguments passed (2) - 3 params
expectedcurrent instr.: '_block25' pc -342568903 ((unknown
file):-1)]
HAH!
* masak files ticket
Re: [perl #60490] Rakudo doesn't report an error on log(0)
On Tue, Nov 11, 2008 at 11:57:02PM -0800, Carl Mäsak wrote: > Rakudo r32568: > > $ ./perl6 -e 'my $result = log(0); say "Still alive after getting $result"' > Still alive after getting -inf Now fixed in r32574: $ ./parrot perl6.pbc -e 'my $result = log(0); say $result;' Can't take log of 0 $ Note that instead of throwing an exception immediately, log(0) returns a Failure that then throws an exception if it is used. Pm
Re: flagging compiler-generated code
On Tue, Nov 11, 2008 at 11:03:09PM -0600, Chris Dolan wrote:
> I'm thinking ahead to the Parrot equivalent of Perl::Critic, which I
> hope will someday be able to analyze arbitrary .pbc files. One problem I
> foresee is that there seems to be no way to distinguish anonymous subs
> ("my $f = sub { 1 };") from inner blocks. Both compile down to something
> like this:
> .sub "_block16" :anon :lexid("23") :outer("21")
>
> Would it be feasible to add a new PIR adverb to mark anonymous methods
> invented by the compiler so we can easily tell them apart from anonymous
> methods invented by the programmer?
I'm having trouble understanding "anonymous methods invented by
the compiler" in this context, probably because in a Perl 6
sense I don't think of inner blocks as being "invented" by the
compiler. They're right there in the code where the programmer
wrote them.
Perhaps you could clarify what you mean by "inner block" here?
Pm
Re: [perl #60482] Rakudo dies strangely on .trans call in for loop on .split result
On Tue, Nov 11, 2008 at 08:43:09AM -0800, Carl Mäsak wrote:
> rakudo: for "foo\nbar\nbaz".split( /\n ** 2..*/ ) { say
> .trans([ /\s+/ => " " ]) }
> rakudo 32543: OUTPUT[too few arguments passed (2) - 3 params
> expectedcurrent instr.: '_block25' pc -342568903 ((unknown
> file):-1)]
> HAH!
> * masak files ticket
The problem is that the strings returned in PGE's Match objects
are Parrot String PMCs, and so the .trans method for String PMCs
(src/pmc/string.pmc:867) ends up being used instead of the .trans
method defined by Rakudo.
This will all likely be fixed when we have HLL mapping in place,
and when PGE is updated to understand HLL mapping. Until then, I
think we're a little stuck on this one.
Pm
Re: flagging compiler-generated code
> On Tue, Nov 11, 2008 at 11:03:09PM -0600, Chris Dolan wrote:
>> I'm thinking ahead to the Parrot equivalent of Perl::Critic, which I
>> hope will someday be able to analyze arbitrary .pbc files. One problem
>> I
>> foresee is that there seems to be no way to distinguish anonymous subs
>> ("my $f = sub { 1 };") from inner blocks. Both compile down to
>> something
>> like this:
>> .sub "_block16" :anon :lexid("23") :outer("21")
>>
>> Would it be feasible to add a new PIR adverb to mark anonymous methods
>> invented by the compiler so we can easily tell them apart from anonymous
>> methods invented by the programmer?
>
> I'm having trouble understanding "anonymous methods invented by
> the compiler" in this context, probably because in a Perl 6
> sense I don't think of inner blocks as being "invented" by the
> compiler. They're right there in the code where the programmer
> wrote them.
>
> Perhaps you could clarify what you mean by "inner block" here?
>
> Pm
Sorry, I'm having trouble finding the right vocabulary. The following
should make more sense:
Both of the following code snippets result in a PIR .sub that is annotated
as :anon
if True {
say 'Hello';
}
vs.
my $f = {
say 'Hello';
}
The former results in a trivial entry in the call graph (exactly one
caller) while the latter can cause arbitrarily complexity in the call
graph. So, a static analysis tool has to work much harder on the latter.
I thought it would be a useful shortcut if the compiler would add a flag
to help distinguish the two cases, so I wouldn't have to include the first
example above in the call graph at all.
Chris
Re: flagging compiler-generated code
On Wed, Nov 12, 2008 at 12:53:24PM -0600, Chris Dolan wrote:
> > On Tue, Nov 11, 2008 at 11:03:09PM -0600, Chris Dolan wrote:
> >> One problem I foresee is that there seems to be no way to
> >> distinguish anonymous subs ("my $f = sub { 1 };") from inner
> >> blocks. Both compile down to something like this:
> >>
> >> .sub "_block16" :anon :lexid("23") :outer("21")
> >>
> >> Would it be feasible to add a new PIR adverb to mark anonymous methods
> >> invented by the compiler so we can easily tell them apart from anonymous
> >> methods invented by the programmer?
> >
> > Perhaps you could clarify what you mean by "inner block" here?
>
> Sorry, I'm having trouble finding the right vocabulary. The following
> should make more sense:
>
> Both of the following code snippets result in a PIR .sub that is annotated
> as :anon
>
>if True { say 'Hello'; }
> vs.
>my $f = { say 'Hello'; }
Ah. In Perl 6 the first is called a "bare block"; in PCT we call
it an "immediate block". So, it sounds like you're wanting a way
to distinguish immediate blocks from other types of blocks.
It would be no problem to have PCT add a flag to subs generated
from immediate blocks, but we'd have to modify PIR (IMCC) to be
able to recognize the new flag and attach it to the Sub somehow.
A slightly different approach would be to have PCT generate :load/:init
code to attach a property to the Sub PMC at runtime... but I suspect
that might not help as much with static analysis of a .pbc file,
since the property wouldn't be present until after the .pbc itself
is loaded. And with the current design of Parrot there are other
properties (e.g., signature) that don't get attached to blocks until
after the module is loaded.
So, perhaps what we need is a way in PIR to attach compile-time
properties to blocks. But that's really a Parrot design question
more than a Rakudo/PCT question, so perhaps we should re-post this
question and thread to the parrot-dev list.
Thanks!
Pm
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Mon, Nov 10, 2008 at 01:03:47PM -0500, Andy Dougherty wrote:
> On Sat, 8 Nov 2008, chromatic wrote:
> > +if (fabsl(ld) == 0.0 && Parrot_signbit(ld))
> > +info.flags |= FLAG_MINUS;
> > +
> (I'm not sure how portable fabsl() is either, though it may not matter.
> I don't see any harm to just omitting it here.)
Me neither. Surely
if (0.0 != -0.0) {
fputs("Your compiler is broken!", stderr);
}
(not tested. Particularly, not tested on icc with the "optimiser" enabled)
Nicholas Clark
[svn:parrot-pdd] r32579 - trunk/docs/pdds
Author: coke
Date: Wed Nov 12 14:01:31 2008
New Revision: 32579
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
remove [DEPRECATED] warning - this is gone now.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Wed Nov 12 14:01:31 2008
@@ -839,18 +839,6 @@
want the parentheses?
}}
-=item .return (args)
-
-{{ Deprecated. Use .tailcall instead. See RT#58236. }}
-
-=item .return .'somemethod'(args)
-
-{{ Deprecated. Use .tailcall instead. See RT#58236. }}
-
-=item .return .(args)
-
-{{ Deprecated. Use .tailcall instead. See RT#58236. }}
-
=item .tailcall (args)
=item .tailcall .'somemethod'(args)
