OK, first of all, a bot-friendly (whateverable-friendly specifically) version
of the first snippet is here:
say run(:out, <perl6 -e>, ‘await ^100 .map: -> $i { start { "".match(/ { print
$i } /) } }’).out.slurp-rest eq (^100).join
And that points to the better-sched merge as noted by dogbert++
The second snippet is faulty in a completely different way, but it is also
fixed.
So the second snippet is living its own life which is probably more interesting
than mine:
On 2015.12 and onwards it was giving False. Then it was fixed (?) in:
(2017-12-19)
https://github.com/rakudo/rakudo/commit/c51f1796e627e93b34e1b06b46c6dccb82549e04
and therefore started to give True. However, after this commit it got broken
(?) again:
(2018-02-07)
https://github.com/rakudo/rakudo/commit/c0c7756f4b5c1d5c79eea56a30a6e43b17b7d408
and therefore started to give False. But it didn't take long to fix that again
in:
(2018-03-04)
https://github.com/rakudo/rakudo/commit/fb882d498edec985a1bd645208862681a64c8743
and so now it gives True again.
Please write tests for this so that it does not get worse than that :)
***⚠ if you write tests, please test both snippets ⚠***
On 2017-08-09 13:06:46, sml...@gmail.com wrote:
> This bug was found as a side-effect of RT #131870, but might be a
> separate issue:
>
> ➜ await ^10 .map: -> $i { start { "".match(/ { say $i } /) } }
> 7
> 7
> 6
> 6
> 7
> 8
> 9
> 9
> 9
> 9
>
> Somehow, multiple iterations see the same value for the closed-over
> variable `$i`.
>
> Without the `await` and `start`, it prints each number from 0 to 9
> exactly once, like it should.
>
> ---
>
> Note that the problem is only with *code blocks* inside regexes. When a
> lexical variable is interpolated into the top-level of a regex directly,
> things seem to work fine:
>
> ➜ say await ^10 .map: -> $i { start { "0123456789".match(/ $i /) } }
> (｢0｣ ｢1｣ ｢2｣ ｢3｣ ｢4｣ ｢5｣ ｢6｣ ｢7｣ ｢8｣ ｢9
>
> ---
>
> Bot-friendly version that reliably prints `False`, even though it should
> print `True`:
>
> my $c = Channel.new; (await ^100 .map: -> $i { start "".match(/ {
> $c.send: $i } /) }); $c.close; say $c.sort.list eqv (^100).list;
>
> According to bisectable6 and committable6 this prints `False` for all
> past Perl 6 releases, so it's not a regression but rather an old bug.
