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