00:46 [Coke] left 02:42 [Coke] joined
[Coke] doing the redo run now. most have a few dozen modules to test, this one up to 420 02:45
so many locked copies of rakudo 02:46
Geth rakudo: ugexe++ created pull request #6687:
RakuAST: fix thunks stacked over a WhateverCode		 03:13
rakudo/main: ee62d82647 | (Nick Logan)++ | 3 files
RakuAST: declare code in a WhateverCode only in the WhateverCode

Previously a thunk declared the code and variables of its expression in its own block even when an inner thunk evaluated the expression. A WhateverCode is such an inner thunk, and a constant's value, a parameter default and a loop statement modifier all wrap one more thunk around it. A block, pointy block, regex, signature literal or ... (9 more lines)		 05:03
rakudo/main: 11177343c6 | (Nick Logan)++ | 2 files
RakuAST: allow a condition modifier over a WhateverCode in a loop

Previously a statement with both a condition and a loop modifier died with "Condition modifier thunk cannot wrap an inner thunk" at compile time when its expression was a WhateverCode, as in
  `(*.succ if 1 for 1)`. The condition modifier thunk expected to be the
innermost thunk, but the WhateverCode's thunk was already there.
This has the condition modifier thunk declare the inner thunk and wrap its value.
rakudo/main: 98a6ae6b7b | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Merge pull request #6687 from ugexe/ugexe/rakuast-stacked-thunk-decls

RakuAST: fix thunks stacked over a WhateverCode
06:52 gfldex left 07:19 gfldex joined
lizmat re startup timing: I think I found the reason why I'm seeing 0.06 and 0.08 startup times 08:22
it appears that the processor in my MBP (M4 Max) has slow (efficient) and fast cores
I noticed that if I'm running a single core process in one window, the bare startup is .06, if there are no other (long) running processes, the startup is .08 08:25
so if it's busy, it's using a fast core, otherwise it's using an efficient core
Geth rakudo/main: ff41340331 | (Elizabeth Mattijsen)++ | src/Raku/ast/base.rakumod
RakuAST: make sure Node.apply-sink accepts :$okifnil

Expression.apply-sink has this named argument, that is apparently being used in some situation. But in some situations, Node.apply-sink is being called with it and then fails.
This unbreaks the RakuAST::Utils module.		 09:14
10:29 lizmat left, lizmat joined
lizmat . 10:31
[Coke] lizmat: github.com/coke/raku-ast-blin-resu...ailures.md has the pre-2026.09 AST run, which goes from (slightly old) HEAD on main, to AST default, to 6.e default. 12:13
This does not include the potential moarvm fix from ugex. 12:14
this was the second run with just the failures from the first run - however, there were still so many, there are at least two failures in here that not real, but show the zef failure of not finding the module 12:15
failures.md was so big I made a failures-short.md with just the bisects and not the output
of 189 failures, 181 are bisected to the commit switching to AST. at least one is known from previous runs and is broken on main 12:17
releasable6: next 12:20
releasable6 [Coke], Next release in ≈11 days and ≈6 hours. There are no known blockers. 191 out of 424 commits logged
[Coke], Details: gist.github.com/c7d552234144f8a3c8...8cec97c885
[Coke] I don't think we're ready to make AST the default with 2 weeks to go.
(less than that) 12:21
I am tempted to automate what I'm doing with the changelog setup, but by the time I do it, I feel, the huge flux of commits will dry up 12:28
definitely happy to take any plain text writeups for the release announcement, as well. (can probably turn 200 commits for AST into a paragraph or two) 12:29
let me know if we want another AST run, but for now I'll switch back to testing HEAD (since it's already 10s of commits beyond where it was last I checked) 12:44
I also wonder if we want to try doing a pre-release of rakudo so we can get the AST version out there and get feedback on it before pushing something in the regular pipeline. 12:45
Maybe we replace the October release with a pre-release, e.g.
(though I suspect many things would not be happy about a release that wasn't called YYYY.MM 12:47
I wonder how many unclosed parens I've left out there over the years. 12:57
13:01 Pixi` joined 13:04 Pixi left
ugexe fwiw the first 5 i randomly spot checked are the ye old ++$pos json::Fast failures 13:57
that being said i'm not sure everyone will be ready for a release in two weeks or not 14:03
[Coke] release in general, or AST-enabled release? 14:33
ugexe oh, i meant an AST enabled release but it wouldnt bother me if we didn't do one more legacy release either 14:39
[Coke] In general, I don't think we need to be doing monthly releases at this point, but this month *does* have a LOT in it. 14:46
15:39 [Coke] left 15:40 [Coke] joined 19:37 finanalyst joined 21:31 finanalyst left
Geth nqp/main: e31676e5b0 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to remove thread blocking while reading

See github.com/MoarVM/MoarVM/issues/2041		 21:49
rakudo/main: af3df50dba | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to remove thread blocking while reading

See github.com/MoarVM/MoarVM/issues/2041		 22:02
23:49 kjp left

Powered by Cro and the Raku® Programming Language.

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

Thank you!