Geth nqp: ugexe++ created pull request #864:
Let a block reference resolve to a frame written back into the unit
00:30
rakudo/main: 16eb0b5aa5 | (Nick Logan)++ | src/core.c/RakuAST/Raku.rakumod
Include may-have-signature in RakuAST::Block.raku

Previously the .raku dump of a block omitted the may-have-signature flag, so evaluating the dump of a block that used a placeholder variable rebuilt a block that rejects placeholders. This emits the flag when it is set, matching how the topic flags are handled.
01:03
rakudo/main: f4f05f29d6 | (Nick Logan)++ | 2 files
RakuAST: Compile the block without modifier via the without op

Previously the without statement modifier special-cased a block with parameters, cloning its code object and calling the clone with the tested value, guarded by an arity check with a misplaced parenthesis. The parenthesis closed after the arity check, making the whole && expression the second argument to nqp::istype. A type object boolifies ... (7 more lines)
rakudo/main: 5252b452b8 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Merge pull request #6622 from ugexe/ugexe/rakuast-without-modifier-block

RakuAST: Compile the block without modifier via the without op
rakudo: ugexe++ created pull request #6624:
RakuAST: link an EVAL's code objects inside the compiler
02:00
nqp/main: 5e9603a88d | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Let a block reference resolve to a frame written back into the unit (#864)

Previously a block reference took a frame from the shared frame table only when this compilation made it. A compilation run while a unit is being compiled writes its frames back into that unit's frame list, and the unit's deserialization code references such blocks by value, so a module compiled under the legacy frontend that compiles Raku code at ... (9 more lines)
02:05
rakudo: ugexe++ created pull request #6625:
Bump NQP to let a block reference resolve to its own compilation frame
02:09
03:01 nine left, nine joined
Geth rakudo/main: b63c7dd93b | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP to let a block reference resolve to its own compilation frame (#6625)
03:09
03:29 Pixi` is now known as Pixi
Geth rakudo/main: 572529e486 | (Nick Logan)++ | 3 files
RakuAST: let the scope wire an ENTER phaser's result name

Previously the scope taking an ENTER phaser handed the name of the lexical it declares for the phaser's result back to the caller, and the phaser stored it through an IMPL- method. A phaser node built outside a parse never runs the begin-time step that stores it, so code adding such a node had to keep the name itself and reach for the ... (7 more lines)
03:41
rakudo/main: ce63098b56 | (Nick Logan)++ | 4 files
Link an EVAL's code objects inside the compiler

Previously a compile nested in an enclosing compilation had to stop at the AST and finish by hand: lower the unit to QAST, compile from the qast stage, and call IMPL-FIXUP-COMPILED-CODEREFS on the result so the enclosing precompilation could serialize the code objects. String EVAL did this, and so did every module embedding Raku code the same way. ... (12 more lines)
rakudo/main: 4bce2f4b38 | (Nick Logan)++ (committed using GitHub Web editor) | 7 files
Merge pull request #6624 from ugexe/ugexe/rakuast-eval-compile-fixup

RakuAST: link an EVAL's code objects inside the compiler
rakudo: ugexe++ created pull request #6626:
RakuAST: give a nested EVAL its enclosing compilation's package
03:57
08:08 kjp left 08:45 kjp joined
Geth rakudo/main: 8f427a4c73 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
RakuAST: give a nested EVAL its enclosing compilation's package (#6626)

Previously the resolver found the current package of an EVAL by walking from the EVAL's outer context until it met a context declaring
  $?PACKAGE or the setting object it holds. A context reached by walking
is a fresh object, so the setting check only matches when the outer context is the setting itself, and a setting frame declares no ... (11 more lines)
13:40
[Coke] c: 8f427a4c73 2.say 13:49
committable6 [Coke], ¦8f427a4: «Cannot find this revision (did you mean “3cfa77a”?)»
[Coke] c: 4bce2f4b38 6.say 13:50
committable6 [Coke], ¦4bce2f4: «Cannot find this revision (did you mean “1720fbe”?)»
[Coke] c: ce63098b56 e*pi.say
committable6 [Coke], ¦ce63098: «Cannot find this revision (did you mean “506855b”?)»
[Coke] ok, that's concerning.
.ask AlexDaniel - last several commits are not showing up as builds - out of disk again? 13:51
tellable6 [Coke], I'll pass your message to AlexDaniel
[Coke] .ask alexdaniel 0cb1dd6c4 is the last commit I see a build for 13:54
tellable6 [Coke], I'll pass your message to AlexDaniel
linkable6 (2026-08-25) github.com/rakudo/rakudo/commit/0cb1dd6c49 RakuAST: fix issue with m:p/foo/ and s:p/foo/bar/ codegenning
Geth ¦ whateverable: coke assigned to AlexDaniel Issue commitable builds missing github.com/Raku/whateverable/issues/414 13:55
[Coke] opens github.com/Raku/whateverable/issues/414 - blin runs blocked until this is resolved. 13:56
Geth rakudo/lizmat-36: a22cab8f9d | (Elizabeth Mattijsen)++ | 17 files
Streamline setting core dynamic vars, part 1

The ideas behind this work are:
  - remove setting up code for lazy setting of core dynamic vars
   using REGISTER-DYNAMIC, but instead do all of this at once by
   initializing the lookup hash once, and thus removing some
   overhead of code that is run at every startup
... (13 more lines)
15:17
rakudo: lizmat++ created pull request #6627:
Streamline setting core dynamic vars, part 1
rakudo/lizmat-36: e5afe1fd6c | (Elizabeth Mattijsen)++ | src/core.c/Process.rakumod
Deactivate language level logic for now

The REGISTER-DYNAMIC logic has support for creating different lazy initialization code for different language levels. However, nothing was using this logic, so we don't need to take care of that logic at in the INITIALIZE-DYNAMIClookup either.
15:31
15:49 AlexDaniel joined
AlexDaniel c: HEAD say 42 15:49
tellable6 2026-09-02T13:51:07Z #raku-dev <[Coke]> AlexDaniel - last several commits are not showing up as builds - out of disk again?
committable6 AlexDaniel, ¦HEAD(67c81bd): «42␤»
tellable6 2026-09-02T13:54:52Z #raku-dev <[Coke]> alexdaniel 0cb1dd6c4 is the last commit I see a build for
linkable6 (2026-08-25) github.com/rakudo/rakudo/commit/0cb1dd6c49 RakuAST: fix issue with m:p/foo/ and s:p/foo/bar/ codegenning
AlexDaniel 67c81bd
linkable6: 67c81bd
hmmmmmmmmmmmmmmmmmmmm
and why is that
is buildable just stuck again somehow 15:50
16:05 nativecallable6 left, benchable6 left
AlexDaniel [Coke]: space is no longer an issue for some time, right now buildable is crashing on startup without any useful output, I'm confused 16:05
[Coke]: if you see that buildable is not joining #whateverable then that's a sign by itself… 16:06
16:06 benchable6 joined 16:07 nativecallable6 joined
AlexDaniel huggable6: hug 16:07
huggable6 hugs AlexDaniel
AlexDaniel gist.github.com/AlexDaniel/177c271...6ab047b865 16:11
does this mean anything?
submodule.3rdparty/zmij.url github.com/vitaut/zmij 16:16
submodule.3rdparty/mimalloc.url github.com/microsoft/mimalloc.git
submodule.3rdparty/rapidhash.url github.com/Nicoshev/rapidhash
find 1 difference :)
hmm but other submodules have .git, so it can't be it 16:18
ugexe i dunno if it would be related but github has been flakey as hell recently fwiw. like 50% of all github CI actions in the raku repo randomly fail due to cloning repos failing 16:33
"fatal: could not read Username for 'github.com': No such device or address" - ah yeah i think its the same thing
you can keep retrying and it'll eventually work :/ 16:34
[Coke] bah 17:02
was github one of the things that responded better on ipv4? 17:03
Geth rakudo/lizmat-36: 270fec1d99 | (Elizabeth Mattijsen)++ | src/core.c/Process.rakumod
Lazy init code doesn't need to be installed

The name is really only so it can be show in any execution error, rather than a nameless block
17:06
AlexDaniel I'm not switching for ipv4 for github :D 17:36
we can wait, but I'm still confused as to why buildable crashes entirely
c: HEAD say 42 17:37
committable6 AlexDaniel, ¦HEAD(8f427a4): «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel that looks like a different commit?
4 hours ago 17:38
c: HEAD~10 say 42
committable6 AlexDaniel, ¦HEAD~10: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel c: HEAD~15 say 42
committable6 AlexDaniel, ¦HEAD~15: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel and why not 17:39
shareable6: HEAD~15
shareable6 AlexDaniel, whateverable.6lang.org/HEAD~15
AlexDaniel “fatal: could not read Username for 'github.com': No such device or address”
okay, so buildable happily archived the builds with those failures… well 17:40
ok, 41 builds wiped, it'll try to rebuild them again. Then I'll do the same thing one more time 17:43
17:58 AlexDaniel left
Geth rakudo/ugexe-patch-2: 4b26ce0513 | (Nick Logan)++ (committed using GitHub Web editor) | lib/CompUnit/Repository/Staging.rakumod
Use more precise return type
18:49
rakudo: ugexe++ created pull request #6628:
Use more precise return type
19:51 finanalyst joined
Geth rakudo/main: 7d5540e504 | (Nick Logan)++ (committed using GitHub Web editor) | lib/CompUnit/Repository/Staging.rakumod
Use more precise return type (#6628)
22:09
rakudo/lizmat-36: 03aea8d43b | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/RepositoryRegistry.rakumod
Micro opt setting up repos

This code is run in $*REPO initialization, so every time at least one module is used.
22:55
rakudo/main: 988b229e02 | (Nick Logan)++ | 4 files
RakuAST: bind a BEGIN-called routine to the running compilation

Previously a routine called at BEGIN time kept the do of its dynamic compilation when the unit later ran as a script. That do closes over a snapshot of the compile-time scope, so a sub declared in a block read the snapshot instead of the block's runtime frame: a lexical assigned at runtime read as undefined, a state variable carried the BEGIN-time ... (33 more lines)
22:58
rakudo/main: 714d6f2e1b | (Nick Logan)++ | 3 files
RakuAST: bind a BEGIN-called routine's captured phasers and thunk bodies

Previously a loop phaser and a start or whenever body of a routine called at BEGIN time kept running the frames of the compilation that ran at BEGIN time. A NEXT or LAST phaser wrote to the compile-time snapshot of its lexicals, and so did a start block, while the routine around them read the runtime frames. ... (11 more lines)
rakudo/main: 7f091c0fcf | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
Merge pull request #6620 from ugexe/ugexe/rakuast-begin-called-routine-bind

RakuAST: bind a BEGIN-called routine to the running compilation
rakudo: ugexe++ created pull request #6629:
RakuAST: Show the source around a compile time problem
23:06
23:39 finanalyst left