# New Ticket Created by Christian Bartolomaeus
# Please include the string: [perl #123048]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=123048 >
Today I got a failure while spectesting for rakudo.jvm:
Failure summary:
S02-names-vars/perl.rakudo.jvm 84 - .perl on user-defined type roundtrips okay
I investigated and the test in question runs fine most of the time but fails
only once in a while. The test in question is on the last line of following
code:
# RT #61918
#?niecza skip ">>>Stub code executed"
{
class RT61918 {
has $.inst is rw;
has $!priv;
has $.string = 'krach';
method init {
$.inst = [ rand, rand ];
$!priv = [ rand, rand ].perl;
}
}
my $t1 = RT61918.new();
my $t1_new = $t1.perl;
$t1.init;
my $t1_init = $t1.perl;
ok $t1_new ne $t1_init, 'changing object changes .perl output';
# TODO: more tests that show EVAL($t1_init) has the same guts as $t1.
ok $t1_new ~~ /<< krach >>/, 'attribute value appears in .perl output';
# RT #62002 -- validity of default .perl
my $t2_init = EVAL($t1_init).perl;
is $t1_init, $t2_init, '.perl on user-defined type roundtrips okay';
}
To me it looks as if "rand" (in method "init") sporadically generates values
that don't survive the roundtrip on JVM. I tried to reproduce the failure and
eventually came up with an example:
$ perl6-j -e 'my $a = 0.219947518065601987e0; say $a.perl; say
EVAL($a.perl).perl'
0.21994751806560198e0
0.219947518065602e0
Moar and Parrot return less decimal places for $a.perl already:
$ perl6-m -e 'my $a = 0.219947518065601987e0; say $a.perl; say
EVAL($a.perl).perl'
0.219947518065602e0
0.219947518065602e0
So .perl behaves differently in this case on JVM and Moar/Parrot.
Maybe I'm looking in the wrong direction, but the test failure should not
occur. I'm going to fudge the test ('skip') for rakudo.jvm.
