From @masak

Parrot r36318 (before the merge that broke Rakudo), and Rakudo 21f374.

$ perl6 -e 'my $a = 5; say $a.PARROT; say $a .. 5'
Int
5
$ perl6 -e 'my $a = 5; sub foo($a) { say $a.PARROT; say $a .. 5 }; foo($a)'
ObjectRef->Int
Undefined value shifted from empty range

$

Note that not only is a warning emitted, but the second 'say' outputs
a blank line.

From @jnthn

On Tue Feb 03 07​:25​:43 2009, masak wrote​:

Parrot r36318 (before the merge that broke Rakudo), and Rakudo 21f374.

$ perl6 -e 'my $a = 5; say $a.PARROT; say $a .. 5'
Int
5
$ perl6 -e 'my $a = 5; sub foo($a) { say $a.PARROT; say $a .. 5 };
foo($a)'
ObjectRef->Int
Undefined value shifted from empty range

$

Note that not only is a warning emitted, but the second 'say' outputs
a blank line.

Was more clone-related fun. I suspect when we've been calling Parrot's
clone directly, we'll usually want to really be calling .clone() on the
object, since it can handle ObjectRef chains. That fixes this issue. (Of
course, in a Perl 6 prelude we'd call the .clone() method too...)

So, resolved in git 1beabec and added a test for this into
S02-builtin-datatypes/range.t. This also made one of the 99-problems
tests that had been failing pass, so un-todo'd that. :-)

Thanks,

Jonathan

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'

From @pmichaud

On Wed, Feb 11, 2009 at 05​:02​:52AM -0800, jnthn@​jnthn.net via RT wrote​:

Was more clone-related fun. I suspect when we've been calling Parrot's
clone directly, we'll usually want to really be calling .clone() on the
object, since it can handle ObjectRef chains. That fixes this issue. (Of
course, in a Perl 6 prelude we'd call the .clone() method too...)

Just to echo a couple of comments from #parrot​: For language
interop reasons I suspect that we really want to bias towards
the Parrot opcodes and not towards Rakudo methods. Rakudo will
then need to map the Parrot vtable functions into the appropriate
(overridable) method calls in Perl 6.

However, I haven't totally convinced myself that this is the
correct approach, so I'm not looking to immediately convert
everything in the Rakudo source to use one approach or
the other. Just keep in mind that at the moment my general
bias for PIR builtins is to use the opcode-based invocations
instead of the method-based ones.

Pm