On Mon, 01 Feb 2016 21:59:33 -0800, alex.jakime...@gmail.com wrote: > Let's try running the same code twice: > > <AlexDaniel> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: { > sleep rand / 100000; $_ + 1 }; say @y > <camelia> rakudo-moar a5fe34: OUTPUT«[]» > <AlexDaniel> m: my @x = ^10; my @y = @x.hyper(:3batch, :5degree).map: { > sleep rand / 100000; $_ + 1 }; say @y > <camelia> rakudo-moar a5fe34: OUTPUT«[1 2 3 4 5 6 7 8 9 10]» > > The thing is that sometimes 「hyper」 decides to return an empty list. This > is a real problem because it basically renders it useless (too unreliable). > > If you have problems reproducing it, try changing 「/ 100000」 to something > else. This delay is not really relevant but it seems like it affects the > chances to get one result or another. > > Here's also a golfed down version: > > Code: > dd @(^10 .hyper(:1batch).map: { sleep rand; $_ }) > > Result: > () > OR > (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) > > According to the execution time 「hyper」 does not even bother to compute the > result in these problematic cases (it just returns an empty list without > trying to process the data). That being said, there is a chance that it > fails half way through, see next example. > > > Another interesting issue (probably the same one): > > Code: > .say for (^10).hyper(:1batch).map: { sleep rand; $_ } > > Result: > 1 > OR > 2 > OR > 3 > OR > 0 > 3 > 2 > 1 > 5 > 8 > 7 > 4 > 6 > 9 > OR etc. > > So not only it is out of order (#127099), but it is also extremely broken. > > It looks like there is no such problem with 「race」. > > IRC log (nothing useful there though): > http://irclog.perlgeek.de/perl6/2016-02-02#i_11975794
Fixed in new hyper/race implementation; tests in S07-hyperrace/hyper.t and S07-hyperrace/race.t (for original post and other examples that I found in the discussion of this ticket).