🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth rakudo: f2959ad5c6 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Re-imagine IterateOneWithoutPhasers.pull-one

This code path is taken for things like:
   my @a = ^10 .map( ... ).grep: ...;
This makes this loop handler a little smaller bytecode wise (so better inlineable), and saves one Scalar allocation per iteration.
09:23
Geth rakudo: 7a1b729bf1 | (Elizabeth Mattijsen)++ | 4 files
Narrow down test to loop phasers

When mapping / looping, the test for phasers was too large: only the NEXT / FIRST / LAST phasers have effect on the way a loop should run.
This improves code like:
... (6 more lines)
10:27
rakudo: 52ffc12550 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make .grep(Callable) about 3% faster

Well, depending on number of iterations. Benchmark was:
   my @a = ^10 .grep: { True }
We don't need to call "sequential-map" and its overhead, we know that the IterateOneWithoutPhasers is the one that will be selected.
11:19
Geth rakudo: 0761d4b2d4 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Fix "next value" in .grep(Callable) with >1 argument

This was forgotten when support for "next value" was added. This makes:
   my @a = ^10 .grep: -> \a, \b { next True }
work correctly.
11:39
rakudo: ddc7c9ff22 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Missed one case of needing to use .has-loop-phasers
12:01
Geth rakudo: gfldex++ created pull request #4449:
add Assoc HyperWhatever support
12:03
Geth rakudo: bb09bbb858 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Improve performance of .grep(Callable) and cleanup

  - about 1% for single arg Callable
  - more than 2x as fast for 2 arg Callable
  - a few percent for 2+ arg Callables
This gets rid of the CheatArity hack, that turned out to be only in ... (7 more lines)
12:58
lizmat bisectable6: old=2021.06 my @a = ^10 .grep: { NEXT die; True }; dd @ 13:11
bisectable6 lizmat, On both starting points (old=2021.06 new=1bd0411) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Array @ = []␤»
lizmat bisectable6: old=2021.06 my @a = ^10 .grep: { NEXT die; True }; dd @a 13:12
bisectable6 lizmat, On both starting points (old=2021.06 new=1bd0411) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Array @a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]␤»
lizmat bisectable6: old=2021.01 my @a = ^10 .grep: { NEXT die; True }; dd @a
bisectable6 lizmat, Cannot find revision “2021.01” (did you mean “2021.06”?)
lizmat bisectable6: old=2020.12 my @a = ^10 .grep: { NEXT die; True }; dd @a
bisectable6 lizmat, On both starting points (old=2020.12 new=1bd0411) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «Array @a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]␤»
lizmat m: ^10 .grep: { NEXT die; True }
camelia ( no output )
lizmat shouldn't that... die ? 13:13
m: dd ^10 .grep: { next; True } 13:14
camelia ().Seq
lizmat loop semantics *are* being applied for "next"
gfldex Does Roast demand next in grep? 13:15
lizmat pretty sure
gfldex I just check, it does. So grep is a loop construct so a NEXT phaser should work. 13:16
m: ^10 .grep: { NEXT { die }; True } 13:17
camelia ( no output )
gfldex Are exceptions legal in phasers?
lizmat well... loop semantics are applied for "next" and "last" is what I think the official description is.
I don't think phasers are mentioned in this
gfldex IIRC LAST and LEAVE are special in regard of Exception. 13:18
Only LEAVE is ment to be exception safe. So `NEXT die` should just throw. 13:22
lizmat hmmm... of course, a LAST phaser would never work inside a .grep
as it could not know when the last call was made (except with an explicit "last" statement) 13:23
gfldex I'm not so sure. LAST should fire when IterationEnd is hit. 13:24
lizmat yeah, but the Callable that you specify with grep, will never get called with IterationEnd
and there has been thought about disallowing "next" and "last" inside .grep anyway 13:25
as hit hinders hypering consistently
I guess if you do need NEXT phaser functionality inside a .grep Callable, you could use LEAVE 13:26
gfldex Makes it harder to read.
lizmat anyways... going to mull over this while cycling before the rains are going to hit& 13:27
gfldex does chaning the last line in tools/templates/RAKU_SPECS change the default language version to .e? 13:32
lizmat vrurg_ might know 16:51
gfldex RAKU_SPECS does indeed control the default verion. I'm kinda calling from the future and can remore that `make spectest` doesn't look to bad for 6.e . 20:07
vrurg Spectest passing must not depend on default language revision. Moreover, it feels to me that most of unversioned tests must get `use v6.c` because they are supposed to spec it. 20:46
gfldex Test driven programming works best when you acutally run the test. :-> 21:31
lizmat
.oO( you need to have a test for that )
21:34
Geth rakudo: 38626c6860 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Lose one level of indirection with .map

We no longer need the "sequential-map" sub, so remove it. Results in about 10% less overhead for each .map. Also be smarter about handling the :item argument.
21:58
japhb lizmat++ # Iteration optimization 22:00