timo github.com/rakudo/rakudo/issues/5358 might be able to be closed now. should we ping the original reporter to hear if the solution is satisfactory? 01:09
Geth nqp/main: 19bf6eccc0 | (Daniel Green)++ | src/QAST/Block.nqp
Use a local for a somewhat hot class member access
 01:18
nqp/main: 01a4822ea8 | MasterDuke17++ (committed using GitHub Web editor) | src/QAST/Block.nqp
Merge pull request #839 from MasterDuke17/make_a_local_for_yet_another_somewhat_hot_class_member_access

Use a local for a somewhat hot class member access
Geth rakudo/more_locals_instead_of_class_members: c4f67baa77 | (Daniel Green)++ | src/Perl6/Optimizer.nqp
More locals instead of class members
 04:25
rakudo/more_locals_instead_of_class_members: 4e9bf1b66a | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP for more using-locals nano-optimizations
rakudo/main: 81d59d64ed | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP for more using-locals nano-optimizations
 04:26
rakudo: MasterDuke17++ created pull request #5787:
More locals instead of class members		 04:30
[Tux] Rakudo v2025.01-98-g81d59d64e (v6.d) on MoarVM 2025.01-24-g21d96b374
csv-ip5xs0.265 - 0.265
csv-ip5xs-201.106 - 1.118
csv-parser1.092 - 1.102
csv-test-xs-200.137 - 0.137
test1.897 - 1.898
test-t0.416 - 0.419
test-t --race0.290 - 0.296
test-t-205.120 - 5.233
test-t-20 --race1.296 - 1.311
 07:49
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log 07:50
Geth rakudo/main: 99500a5db2 | MasterDuke17++ (committed using GitHub Web editor) | src/Perl6/Optimizer.nqp
More locals instead of class members
 08:34
lizmat looks like that last one shaved about 20% off of stage optimize in core.c setting 08:39
ab5tract Wow! 08:45
lizmat meh... it was a fluk... more like 2% on the next run... 09:18
I still wonder how these differences come about 09:19
Geth rakudo/main: abb92d96c5 | (Elizabeth Mattijsen)++ | 2 files
Make Blob ~ Blobx take lefthand type in 6.e

Reported in #5071: having it produce a Buf if the types on either side are differently parameterized, felt weird as in other such cases the type on the left-hand side of the infix will be produced.
This is now the case in 6.e. Sadly, the revision-gated mechanism could not be used. Adding it to the proto broke setting compilation, and applying it in the core epilogue made the core setting compiliation infiniloop (probably because it is using infix ~ somewhere inside).		 09:25
ab5tract lizmat: any reason you don’t feel like fixing/updating revision gating when you encounter issues like this? 10:32
lizmat I fear it would take me a lot of time to get into the revision-gated logic right now 10:33
and I'm seriously considering taking a stab at the binder at some point 10:34
ab5tract Well the alternative is to keep pushing things that “should” be revision gated but aren’t
lizmat true, but at least these are localized to src/core.e/Fixups 10:35
ab5tract How does the binder come into play here? It’s not used in dispatch unless things are very odd
lizmat I plan to look at the binder because I'd like to be able to indicate exact match of types: eqaddr logic vs istype logic 10:36
also, doesn't it still do a trial bind in dispatch ? 10:37
ab5tract Not unless it doesn’t know what else to do 10:39
At least as far as my experience goes 10:40
lizmat hmmmm
ok, I'll spend some time on it :-) 10:43
ab5tract Between the commit adding is item and the commit that adds revision gating, there should be plenty to chew on. It will be worth your time to reference them 10:44
Geth rakudo/main: 6e98232339 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Handle Associative.deepmap better wrt Empty

Issue #4435 describes how .deepmap messes up on Associatives the moment that some elements are skipped by returning Empty.
This commit fixes that by special casing the direct Associative.deepmap to actually check for empty returns, and then not producing those ... (14 more lines)		 11:44
rakudo/main: 8 commits pushed by (Stefan Seifert)++ 12:06
jdv sena_kun: thanks
tellable6 2025-02-17T21:27:08Z #raku-dev <sena_kun> jdv this was 3.5 years ago, but my best guess is "something on Blin got broken and we reverted it"
nine That's 1171 12:07
lizmat nice! a lot of work for a single test file!
nine indeed 12:08
Geth rakudo/main: ab09c6d1db | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod
Additional fix on Associative.deepmap

Turns out 6e98232339 only fixed 1-key hashes. Found while writing the actual test for #4435		 12:13
roast: c5b9baef9a | (Elizabeth Mattijsen)++ | S32-list/deepmap.t
Add test for #4435
rakudo/main: 4d37905df1 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
Revert "RakuAST: Avoid re-declaration of $_ in sub-sigs"

This reverts commit f1de73e9edf4891b8490df713257f2cf74384672.
Turns out that this fix broke cases like -> $_ { }(3) which did not declare it's own $_ and thus bound to the outer scope's $_. Looks like we need a better fix for the double delcaration of $_ in sub-signatures: for [1,2],[3,4] -> ($_,$b) { }		 12:40
nine A surprising fix that gets us to 1172
ab5tract: ^^^
lizmat Q: what do you think: * = 1 | 2 does ? 12:42
m: say Q|sub a(:$a where * = (1,2).any) { }|.AST.DEPARSE 12:46
camelia sub a (:$a = (1, 2).any) { }
lizmat it feels that this is codegenned incorrectly, or should be disallowed 12:47
looks like the legacy grammar *is* creating a block for this 12:48
if I interpret the QAST correctly 12:49
in any case, it feels to me that any assignment to the topic, should be a no-no
m: sub a(:$a where * = 42) { dd $a }() # this feels wrong 12:50
camelia 42
lizmat instead of dying because it couldn't dispatch, it uses the value to assign to the missing named argument 12:51
see #4381 for reason of this investigation
R#4381 12:52
linkable6 R#4381 [open]: github.com/rakudo/rakudo/issues/4381 [junctions][dispatching] sub foo($a where * = 'a'|'b') { } infiniloops if called without arguments
lizmat m: sub a(:$a where * := 42) { dd $a }() # that should be the error, I think 12:54
camelia ===SORRY!=== Error while compiling <tmp>
Malformed parameter
at <tmp>:1
------> sub a(:$a where * :<HERE>= 42) { dd $a }() # that should be th
nine bartolin: I still think that loop label test enshrines wrong behavior. Most notably behavior caused by a simple bug in the legacy compiler. 13:42
To be precise github.com/rakudo/rakudo/blob/main...s.nqp#L199 checks whether the ast contains more than 2 elements. This is clearly meant to find C-style loops: loop (;;). However a label is also an element in that array: github.com/rakudo/rakudo/blob/main...s.nqp#L173 13:43
Thus it takes the label, thunks it and uses that as a condition. It just happens that a label boolifies to true. 13:45
Without label we generate a Rakudo::Iterator::Loop:
m: (while True { }).iterator.^name.say
camelia Rakudo::Iterator::Loop
nine While with the label, we call the 2 arg form of Seq.from-loop and end up creating a Rakudo::Iterator::WhileLoop: 13:46
m: (L1: while True { }).iterator.^name.say
camelia Rakudo::Iterator::WhileLoop
nine It just so happens that these have different lazyiness. Loop has method is-lazy(--> True) { } while While doesn't. 13:48
lizmat is that not an error ?
nine lizmat: What exactly? 13:50
lizmat that ...WhileLoop isn't lazy ?
nine That's exactly my point. We accidentally compile to a WhileLoop and that again is accidentally not lazy. The spectest however requires the loop to be eager. 13:51
Hence I claim that the spectest is still wrong.
lizmat understood, and agree 13:53
nine m: (loop { }).iterator.^name.say 14:00
camelia Rakudo::Iterator::WhileLoop
nine Then, there's of course this ^^^ oddity. While we do optimize a `while True` to an Iterator::Loop, we don't use that for a plain loop { }. Any guess why? 14:01
ab5tract nine: nice catch earlier! Doesn’t that intersect with tracking blocks separately from scopes? 14:04
lizmat actually, no idea nine
nine The answer is: because on Sat Nov 28th 2009 Stephen Weeks did the first implementation of loop { } which compiled it to a PAST op while(1) because that's what was available. This became OP.new(:op<while>, QAST::Var.new(:name<True>, :lexical)) which became OP.new(:op<while>, QAST::IVal.new(:value(1)) which became from-loop(&body, -> { 1 })
ab5tract Ah, cool! I like that kind of historical review 14:05
lizmat m: multi sub a(@a) { dd }; multi sub a(Seq:D $a) { dd }; a (1,2,3).map(*+1) # this feels, meh 14:06
camelia Ambiguous call to 'a(Seq)'; these signatures all match:
(@a) from <tmp> line 1
(Seq:D $a) from <tmp> line 1
in block <unit> at <tmp> line 1
lizmat feels to me a specific Seq:D candidate should be more tight than a Positional sig
nine Well actually, I'd rather not have to do this kind of digging. That's why one should be extra careful when writing spec tests, so they don't become "do whatever Excel 95 does" 14:07
ab5tract I’ve wondered about whether an LLM could be a useful tool as an oracle into the accretion of design decisions by building it on the broad corpus of Perl 6 / Raku communications channels, bug trackers, and repositories. 14:10
lizmat afk for a few hours& 14:11
ab5tract That’s maybe not something that I can just take on unilaterally, as timo has pointed out. But I think it would be really cool to have a window onto earlier historical moments, the back and forth between implementation constraints and high level design, etc 14:12
I think there are probably some interesting organizational lessons that are in there too. 14:13
nine I still think that we did ourselves a great disservice by abandoning the design documents and calling them speculations.
ab5tract I agree. It would be a massive but cool project to revisit those and rewrite / expand as necessary 14:15
nine "lazy loops can be indicated by putting the loop in parens or brackets" is super clear, especially compared to the "do whatever this combination of 3 different implementation bugs results in" we have in the spec tests
ab5tract And release it as the Butterfly book
Geth rakudo/fix-lazy-loop-bugs: a56f1b5770 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: fix label getting lost on while/until True/False loops

Accidentally attached the named arg to the QAST::Stmt instead of the op.		 14:44
rakudo/fix-lazy-loop-bugs: c0c4e7addb | (Stefan Seifert)++ | 2 files
Fix a bunch of non-sunk lazy loop bugs

Whether a loop used as expression turns out to become lazy or not has so far been determined by the complex interplay between several bugs. We treated loop labels as conditions, did not recognize 1 as a compile time value and failed to make iterators lazy. This fixes all of those.
nine This commit ^^^ (ignore the one before) restores sanity and breaks 29 individual spec tests.
Geth rakudo/main: a56f1b5770 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: fix label getting lost on while/until True/False loops

Accidentally attached the named arg to the QAST::Stmt instead of the op.		 14:48
releasable6 Next release in ≈4 days and ≈3 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
[Coke] just pinged Snyk about adding Raku as one of the languages they scan for. 15:11
(one of the things they scan for is OSS licensing on projects inside git repos, so that seems an easy add) 15:13
lizmat rakkable: eco-pr ' sort ' 17:31
rakkable lizmat, Running: eco-provides ' sort ', please be patient!
lizmat, No occurrences found for: eco-provides ' sort '
lizmat rakkable: eco-pr --pattern=' sort '
rakkable lizmat, '--pattern' argument not allowed / unknown: ignored
lizmat, Running: eco-provides sort ', please be patient!
lizmat, No occurrences found for: eco-provides sort '
lizmat meh
Geth rakudo/main: ef60266a92 | (Elizabeth Mattijsen)++ | src/core.c/Cool.rakumod
Mark '.samespace' method as an implementation-detail

As suggested by #4318		 18:09
rakudo/main: 45b36fa0c7 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.rakumod
Word wrap class implementation detail message

As originally reported in #3723.
[Coke] m: say Attribute.^methods[0] 18:15
camelia ForeignCode
[Coke] m: dd Attribute.^methods[0]
camelia The 'ForeignCode' class is a Rakudo-specific implementation detail and has no serviceable parts inside
lizmat hopes camelia isn't stuck at a56f1b577 18:18
[Coke] m: Nil 18:19
camelia ( no output )
Geth rakudo/main: 90312db3d7 | (Elizabeth Mattijsen)++ | src/core.c/Range.rakumod
Make Range.Numeric a bit smarter wrt infinity

Issue #3637 reported that prefix + is wrong on some edge cases of possible Ranges. Since prefix + is just short for calling .Numeric it looked like that method needed some TLC.
This commit does that: if numeric values are in the range, then:
  - return 0 if min value exceeds max value
  - return Inf if min == -Inf or max == Inf
  - otherwise calculate the diff as before		 19:06
roast: 00906c4517 | (Elizabeth Mattijsen)++ | S02-types/range.t
Add tests for #3637
 19:14
lizmat m: Nil 19:23
camelia ( no output )
lizmat m: dd ForeignCode
camelia The 'ForeignCode' class is a Rakudo-specific implementation detail and
has no serviceable parts inside.
Geth rakudo/main: 8835a4384e | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: parse $foo=<bar> in regexes

This feature doesn't seem to have been implemented in the old frontend. Spec tests are todo'ed. But parsing this syntax lets us get over those todos and run the other tests.		 21:25
nine 1173
bartolin nine: Oh my, thanks for digging into that "lazy loops" topic. Your explanations make total sense to me. In case I didn't make that clear before, I fully agree that github.com/raku/roast/commit/53d332addf was wrong. Just a question to avoid a misunderstanding: When you say "that loop label test enshrines wrong behavior", do you refer to the attempt to fix the tests with 21:33
github.com/Raku/roast/pull/870 or to the original test?
bartolin will try how it looks with github.com/rakudo/rakudo/tree/fix-...-loop-bugs 21:34
nine At least the original test. Haven't looked too closely at the current version. 21:43
bartolin I see, thanks. For the record, the test didn't change yet. That was just a PR for now. 21:45
Ha, on that branch the version from the PR passes with RAKUDO_RAKUAST=1. But without there are again crashes with "labeled last without loop construct". E.g. for this this one: 22:24
m: my $ignore; my @res; sub while-loop-in-parens() { (L: while True { @res.push: 3; last L }) }; $ignore = while-loop-in-parens()[2]; dd @res
camelia [3]
timo hey nine, i was wondering if you might have input for what you would like from the moarvm remote debugger, if you have used it at all 22:42
bartolin Oh, I think the crash happens because of a missing sigil in github.com/rakudo/rakudo/commit/c0c4e7addb. I've commented on that commit (from the branch "fix-lazy-loop-bugs"). 23:17
Geth setup-raku/dependabot/npm_and_yarn/octokit/plugin-paginate-rest-9.2.2: 4e0927a1a4 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump @octokit/plugin-paginate-rest from 9.2.1 to 9.2.2

Bumps [@octokit/plugin-paginate-rest](github.com/octokit/plugin-paginate-rest.js) from 9.2.1 to 9.2.2.
  - [Release notes](github.com/octokit/plugin-paginate.../releases)
  - [Commits](github.com/octokit/plugin-paginate......v9.2.2)
  ---
... (6 more lines)		 23:26

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!