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