Re: [perl #123048] [JVM] test in S02-names-vars/perl.t fails sporadically

[Moritz Lenz]

Hi,

On 10/24/2014 06:16 PM, Christian Bartolomaeus (via RT) wrote:
# 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.

The better approach is to isolate the user-defined type roundtrips test 
from roundtripping floats with many digits.

So rather remove the rand's, replace them by fixed values, and have 
separate tests for round-tripping 0.21994751806560198e0. Then fudge that 
test for JVM as needed.

Cheers,
Moritz