New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S/// within map doesn't work #5886
Comments
From @bdugganThis code: say <a1 a2 a3>.map({S/a/x/}).perl returns this: ("x3", "x3", "x3").Seq instead of x1, x2, x3. Version: 2016.11 IRC snippet below. [12:27] == bdmatatu [6c347aa0@gateway/web/freenode/ip.108.52.122.160] has joined #perl6 |
From @zoffixznetI nursed this one to know where the problem is, but unsure of the fix. Maybe someone can figure out how to push it through the finish line... First, the problem shown in the OP is weird only because there's a level of indirection with the iterator and the problem there shows up only after we attempt to fetch already reified items. Here's a simpler reproduction with both S/// and s///: <ZoffixW> m: say do for <a1 a2 a3 a4> { S/a/z/; } The problem is the `S///` and `s///` ops use the I looked through some past commits mentioning $/ for ideas, and tried the following, but that didn't fix anything... I'm out of ideas now. cpan@perlbuild2~/CPANPRC/rakudo (nom)$ gd Cheers, On Thu, 15 Dec 2016 09:47:06 -0800, bduggan@matatu.org wrote:
|
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetThank you for the report. This is now fixed. Fix: rakudo/rakudo@97359ae42e It's worth noting the fix is somewhat tangental to the original issue and the issue isn't actually a bug. What happens in the original issue is you keep returning the same container for each item mapped over (in the case of S///, it was the $/ variable). And depending on how you fetch the results, you get the *latest* value of that container. The most curious example of this effect is: [12:40] <AlexDaniel> m: say <a1 a2 a3>.map({S/huh//}) The first version is lazy, and the value inside The rest of the weirdness in this ticket is all due to the same reason, except it may appear to not be present due to laziness, or not appear on first iteration but then appear on second one, due to first version evaluated for each lazily generated value, but then those get stored in the list's $!reified attribute and keep getting updated to new values as the list is reified further. The result is only the second iteration notices those updates. Lastly, why is this ticket fixed now? We determined that S/// is actually not supposed to return $/. So for an unrelated reason it no longer returns the same container on multiple iterations, fixing this bug by a happy accident \o/ Cheers, |
@zoffixznet - Status changed from 'open' to 'resolved' |
From @bdugganGreat. I tested the original example with the change and verified ./perl6 -e 'say <a1 a2 a3>.map({S/a/x/}).perl' thanks! |
1 similar comment
From @bdugganGreat. I tested the original example with the change and verified ./perl6 -e 'say <a1 a2 a3>.map({S/a/x/}).perl' thanks! |
Migrated from rt.perl.org#130355 (status was 'resolved')
Searchable as RT130355$
The text was updated successfully, but these errors were encountered: