[Coke] I think you can add moarvm as another remote and push your ugexe branch to that upstream. 01:46
I managed to do it on rakudo once then failed when I tried it the next time. 01:47
ugexe i dont have permissions 01:50
git push origin ugexe/upstream-luajit-dynasm 01:51
ERROR: Permission to MoarVM/MoarVM.git denied to ugexe.
fatal: Could not read from remote repository.
[Coke] try again 02:00
ugexe hmm, still seeing the same message 02:18
Geth Blin: japhb++ created pull request #57:
Add an overview-watcher util script		 02:19
02:23 rnddim joined, rnddim left 02:24 rnddim joined, ShimmerFairy left
[Coke] hurm. gave you write privs... 02:31
ugexe oh i had to accept an invite on github.com 02:37
Geth nqp/ugexe/upstream-luajit-dynasm: 33906453c9 | (Nick Logan)++ | tools/templates/MOAR_REVISION
Bump MoarVM to switch DynASM to upstream LuaJIT
 02:42
rakudo/ugexe/upstream-luajit-dynasm: 168a2eb0e1 | (Nick Logan)++ | tools/templates/NQP_REVISION
Bump NQP to switch DynASM to upstream LuaJIT
 02:43
02:47 rnddim is now known as ShimmerFairy
[Coke] want a blin run on 168a2eb0e1 ? 02:53
c: 168a2eb0e1 e
committable6 [Coke], ¦168a2eb: «Cannot find this revision (did you mean “b121e53”?)»
ugexe yeah 02:57
[Coke] c: 168a2eb0e1 e 03:03
committable6 [Coke], ¦168a2eb: «»
Geth Blin/main: 0493413c69 | (Geoffrey Broadwell)++ | util/overview-watcher.raku
Add an overview-watcher util script
 03:04
Blin/main: 6fcc9ec5e2 | (Will Coleda)++ (committed using GitHub Web editor) | util/overview-watcher.raku
Merge pull request #57 from japhb/japhb/overview-watcher

Add an overview-watcher util script
03:33 ShimmerFairy left, ShimmerFairy joined 03:37 ShimmerFairy left 03:38 ShimmerFairy joined
ShimmerFairy [Coke]: I have pull requests open on all the projects (MoarVM/NQP/Rakudo/roast) for my changes. Alternatively, the branches all have the same name "unicode-18.0", and have all been pushed upstream except rakudo, where I don't have push perms (that branch is on my fork of rakudo instead). 03:44
japhb ShimmerFairy: I approved the MoarVM one (lizmat had requested I review it) 04:02
ShimmerFairy Oh that's good! For the record, I think merging all the PRs at the same time (or as close together as possible) would be preferable, to avoid any noise coming from expectation mismatches (e.g. running Unicode 17 spectests on Unicode 18 moarvm). 04:06
japhb Agreed
In fact, I'd recommend saying "Everyone please hold off merges until I finish these" first. :-) 04:07
ShimmerFairy At least for my part all the upgrade work is up and in PRs already. Whatever other improvements to Unicode support I want to make aren't upgrade related, and can happen later whenever. 04:11
I will say though that I wish github had some kind of notion of "cross-repo PRs" for neatly organizing these kinds of changes. (though maybe the fact that you'd want such a thing is a clue that Unicode support isn't abstracted all that well currently...) 04:13
04:38 vrurg_ joined 04:39 vrurg left 06:36 camelia joined 08:43 bazzrrr0 joined
bazzrrr0 Does anyone know whether El_Che intends to add a sister service providing pre-built rakupp binaries, to go alongside the current very useful rakudo-pkg service? 08:45
Will repost on #raku channel as it might be the better place for this topic 09:09
Geth nqp/main: 961f3cc315 | Faye++ (committed using GitHub Web editor) | t/nqp/106-unicodenames.t
Add tests for Jurchen and Small Seal scripts. (#879)

These tests ensure their Unicode names are properly generated by the backend.
nqp/main: 68075a0ccd | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for Unicode 18.0, Shimmerfairy++
 09:12
rakudo/main: 21607b372f | Faye++ | 7 files
Update for Unicode 18.0

All the usual steps for updating to a new version of Unicode, though with the added step of handling some new algorithmic Unicode character names. Also needed to bump up the number of expected failures in the General Category tests, the current failures only affect unassigned codepoints.		 09:26
rakudo/main: e1058f0baa | Faye++ | t/09-moar/UnipropCheck.rakumod
Update general category test for zero expected failures.

Changes in MoarVM have made it so that every codepoint's general category is now correctly returned when queried, so the number of expected failures in now zero.
rakudo/main: 11ce8045c0 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 7 files
Merge pull request #6792 from ShimmerFairy/unicode-18.0

Update for Unicode 18.0
10:04 hurufu joined
Geth rakudo/lizmat-58: 2c4a28c02b | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for Unicode 18.0, Shimmerfairy++

Alas, two Rakudo test-files are now failing, and three roast test-files, all related to grapheme breaks, so assume the tests will need to be fixed		 10:20
lizmat argh 10:22
in the wrong branch :-(
ShimmerFairy lizmat: I've got a roast PR as well, if you missed it. github.com/Raku/roast/pull/923 10:28
lizmat make test clean now, *phew* 10:37
Geth rakudo/main: 9f2f8a37d1 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for Unicode 18.0, Shimmerfairy++
 10:38
roast/master: 4 commits pushed by Faye++, (Elizabeth Mattijsen)++
lizmat spectest clean also, ShimmerFairy++ 10:41
ShimmerFairy Glad to hear it wasn't a fluke of my machine :) And lizmat++ for doing the merging-in of everything. 10:42
lizmat c: HEAD dd Unicode.version 10:46
committable6 lizmat, ¦HEAD(11ce804): «v17.0␤»
lizmat meh..not up to date yet :-)
Geth rakudo/main: d898bc6d3c | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Raku/ast/resolver.rakumod
RakuAST: streamline ::Resolver.(EVAL|Compile).resolve-lexical (#6805)

  - rewrite so no return statements are needed anymore
  - tighten up scope walkers		 11:00
rakudo/main: 5ffa907559 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 17 files
RakuAST: make .resolution.compile-time-value DRYer (#6804)

This particular chained method call occurred a *lot*, so it feels like a good idea to make this DRYer.
This adds a ::Lookup.resolved-value method, and uses that method instead of any .resolution.compile-time-value call. Should improve readability and overall bytecode size.
11:11 bazzrrr0 left 11:52 hurufu left, hurufu joined
Geth roast: bd58f3a54c | (Elizabeth Mattijsen)++ | 27 files
Untodo test passing in 2026.09

Because RakuAST has been made the default, which fixes a lot of issues. Also closed any associated issues that were still open.
This makes the result of a spectest a *lot* cleaner!		 12:14
roast: fbedc39103 | (Elizabeth Mattijsen)++ | spectest.data
Mark S29-os/system.t as slow

So it gets started earlier and doesn't affect wallclock time as much at the end
roast: 9143ef83ad | (Elizabeth Mattijsen)++ | S32-io/out-buffering.t
Untodo test that now appears to be ok on MacOS

Not sure if this was RakuAST related, or MacOS update related. So put it in a separate commit.
rakudo/main: 11 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/5...613ee61882		 12:16
[Coke] ARGH 12:18
lizmat ARGH?
[Coke] Yes, all the unicode 18 stuff got merged when I was asleep?
through all 4 repos?
lizmat eh, yeah.... and all clean
did I miss something yesterday ? 12:19
[Coke] For future reference, we can have branches all the way through and then test the rakudo branch that includes the changes, which I had asked about before went offline in here (which is why I was surprised to see it all merged this morning) 12:20
lizmat ah, I took japhb's approval as an ok to merge away 12:21
[Coke] crap, I just accidentally overrwrote my blin runner that was distinct from the checked in version. shit. 12:22
(I think it was only a cosmetic change, thankfully) 12:24
Geth rakudo/main: 04a96091f8 | (Elizabeth Mattijsen)++ | 2 files
Untodo now passing tests
[Coke] I think japhb's approval was based directly on your ask for a review, not my comment at all. 12:25
lizmat ah, yes :-( 12:26
[Coke] ugexe: finishing the redo-run on your branch - only 3 potential failures.
(not counting Injector. :)
ugexe: clean on redo. You're all good 12:30
c: 04a96091f8 e 12:31
committable6 [Coke], ¦04a9609: «Cannot find this revision (did you mean “e1a86f1”?)»
[Coke] c: e2613ee618 e
committable6 [Coke], ¦e2613ee: «Cannot find this revision (did you mean “78ffee6”?)»
[Coke] (will kick off the next blin run when HEAD is built) 12:32
Geth nqp/main: 0fa43704ca | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for line number annotation fix

Marco Ladermann++		 12:34
lizmat [Coke]: want me to hold off the NQP bump ? 12:35
[Coke] for what? 12:45
oh, of that in rakudo. No, doesn't matter.
lizmat ok 12:46
Geth rakudo/main: 7893514afd | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Todo a test again, apparently it flaps?
 12:47
rakudo/main: 11ac8beafc | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for line number annotation fix

Marco Ladermann++
roast: f8eeb40157 | (Elizabeth Mattijsen)++ | spectest.data
Mark sprintf tests as slow

So that they're started early so that spectest takes less wallclock		 12:49
[Coke] want the buildable bot to let me know, when a build finishes, if that means HEAD in rakudo is now built 13:12
13:17 hurufu left
Geth Blin/main: 1fab2c33a1 | (Will Coleda)++ | util/overview-watcher.raku
Replace LTA failure if file doesn't exist
 13:18
13:32 hurufu joined 13:47 hurufu left 13:50 hurufu joined
Geth rakudo: ugexe++ created pull request #6807:
Implement shaped array views and jagged array shapes		 14:01
ugexe maybe we should just disable pushing to main? 14:06
like the nqp bumps and stuff should have been done, and then the PR for the unicode stuff rebase and ran through CI to pass it 14:08
and similarly the todo test commit which was apparently wrong
its ok for those things to take an extra hour or two really 14:09
and now i have conflicts on 3 of my local branches because we added a helper method. and what im seeing im not a fan of either... there is code that does e.g. return Nil unless nqp::can($prefix.resolution, 'compile-time-value'); to guard the call to that method, but now we just call a different method instead witht he same guard. that is not easier to understand 14:25
we really really really need to think about these types of changes. if some change is easy assume you overlooked something 14:26
Geth rakudo: ugexe++ created pull request #6808:
RakuAST: declare a package's body where it is evaluated and its header with its body		 14:32
[Coke] starting another blin through 11ac8beafc 14:33
linkable6 (2026-10-07) github.com/rakudo/rakudo/commit/11ac8beafc Bump NQP for line number annotation fix
[Coke] From a release management standpoint, I'd be very happy with a protected main 14:35
We had floated it probably years back but didn't get traction. 14:36
for CI/CD makes a lot of sense, for coordination it makes sense. We won't do a blin run on every PR, but being able to do a blin run on *some* PRs is also very handy. 14:37
(more so when we get blin testing all of the ecosystem, not just most - then we can do an "essential module" run for a branch, which is relatively quick. 14:38
lizmat fwiw, I waited almost 24 hours for the merge of my PRs 14:39
ugexe you can review your own PRs too 14:40
seeing the PR on github vs locally often helps you to see things you might have missed
lizmat with regards to the helper method: the "nqp::can($prefix.resolution" was untouched
it only changed .resolution.compile-time-value 14:41
so, all the cases where there was *no* guard
ugexe my point wasnt that that method was touched. its that there was a guard that was connected to the original method. now the original method has been renamed and now the guard has no visual connection to that call
lizmat the original method was *not* renamed 14:42
ugexe well its not called under that guard, whatever
previously it was obvious why that guard was there
now its not
and that was just from me quickly glancing at the pr
a search and replace is rarely sufficient for sufficiently complicated code 14:43
because it has no way to make use of the surrounding lines context 14:44
lizmat fwiw, I vetted each and every change in that PR
and this is the method that was added: 14:45
+ method resolved-value() { self.resolution.compile-time-value }
ugexe return Nil unless nqp::can($prefix.resolution, 'compile-time-value');
my $routine := $prefix.resolved-value;
this is what i mean
you cant read those two lines and know they are connected at all unless you've also memorized the implementation of resolved-value()
before it was obvious 14:46
my $module := self.resolved-value; 14:48
my $CompUnitHandle := self.IMPL-UNWRAP-LIST(self.get-implicit-lookups())[0].compile-time-value;
similar for that. originally they were both .compile-time-value calls which made their connection clearer 14:49
lizmat OOC, is it common that it doesn't have a 'compile-time-value' method? or is that rare ? 14:51
ugexe not sure, i'd have to spend some time looking. i don't think it matters if its rare though 14:53
the name resolved-value also suggests it works for anything that resolved. but it doesn't. it dies on an unresolved lookup, and on one that resolved to something without a compile-time value (such as an operator bound to a my &infix:<…> variable) 14:57
lizmat re "seeing the PR on github vs locally often helps you to see things you might have missed" 15:02
I always look at the git diff before committing
ugexe so you don't see anything confusing about the examples i posted, or you just overlooked those? 15:05
lizmat I didn't look at the context with that in the back of my mind 15:10
ugexe the context of the surrounding code is always important 15:11
lizmat as an alternative I have a branch for simplification of ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE
but sadly it looks like Github is 500ing on me 15:12
looks like creating a gist is also 500 15:13
Geth rakudo/lizmat-59: 81ae3f8048 | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod
RakuAST: simplify ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE

Since it didn't matter why the $routine value could not produce a concrete value, wrap all of the checks in a single try.
Also use a proper if structure for: 1. readability 2. no need for return statements		 15:18
lizmat ugexe: is that better readable ? 15:19
ugexe are you sure about "Since it didn't matter why the $routine value could not produce"? 15:20
without actually looking i would assume slapping a try in front of such a statement is going to cover up errors we'd want to expose themselves
lizmat there was no diagnostic given, just return Nil, which it also returns when all is ok
yes, It does hide any other possible reasons why it would fail 15:21
ugexe so it does matter then
lizmat it matters as much as with any other try in the code
ugexe i would have to check to confirm that. i wouldn't use that as a basis for using more try 15:22
lizmat understood, but all of the reasons for possible failure where just silently ignored, just as a try would
understood, but all of the reasons for possible failure where just silently ignored, just as a try would 15:23
and there are about 30 of them in the RakuAST bootstrap
also in the case of: my $module := self.resolved-value; 15:24
my $CompUnitHandle := self.IMPL-UNWRAP-LIST(self.get-implicit-lookups())[0].compile-time-value;
the two statements only interact with each other later: my $handle := $CompUnitHandle.from-unit($module.WHO); 15:25
so why would it matter how they got their values ?
ugexe because humans text? 15:28
read text
lizmat the way I look at these statements is that they obtain a value from somewhere, and use that to create another value 15:29
at that stage, It shouldn't matter to the reader how these values were created
that's why we have subs and methods 15:31
ugexe it matters that the reader can intuit things via context 15:32
im telling you that for me personally those changes make it *harder* for me to understand
Geth rakudo/main: 5136581fd1 | (Elizabeth Mattijsen)++ | 17 files
Revert "RakuAST: make .resolution.compile-time-value DRYer (#6804)"

This reverts commit 5ffa907559987787efd2de97883296270189a9bc.		 15:34
rakudo: lizmat++ created pull request #6809:
RakuAST: simplify ::ApplyPrefix.IMPL-RECORD-NATIVE-RETURN-TYPE		 15:35
rakudo/lizmat-59: 5136581fd1 | (Elizabeth Mattijsen)++ | 17 files
Revert "RakuAST: make .resolution.compile-time-value DRYer (#6804)"

This reverts commit 5ffa907559987787efd2de97883296270189a9bc.		 15:36
rakudo/lizmat-59: ecdde5fc3d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 17 files
Merge branch 'main' into lizmat-59
16:11 hurufu left
ugexe so main CI looks like its broke 16:21
github.com/rakudo/rakudo/commits/main/ 16:22
yeah we can't just untodo tests that legacy fails until we remove the legacy frontend 16:28
so roast needs to revert whatever commit did that 16:29
then all the current PRs need to rerun so they can pass their roast test again
if the roast commit was instead made as a PR we could revert it from the web ui 16:30
ab5tract m: say (1000 + 1) =:= (1002 - 1) 16:32
camelia False
ab5tract is this spec'd behavior or a quirk of whats-currently-implemented 16:33
ugexe they each box to a different Int object 16:35
oh lord 16:37
m: say (1+1) =:= (3-1)
camelia True
ab5tract oof 16:38
ugexe because moarvm caches 1 - 14
-1 - 14 rather 16:39
i'm gonna benchmark to see what kind of regression removing that cache would actually result in. if we're lucky maybe it isn't as relevant anymore 16:41
ab5tract nice idea. consistency is great if the cost is not too high 16:42
Geth Blin/main: 0771cb5705 | (Will Coleda)++ | util/overview-watcher.raku
Also show percentage complete in watcher
 16:51
Blin/main: b305cd5a37 | (Will Coleda)++ | util/overview-watcher.raku
Avoid warnings about math on Anys.

Note that these warnings only showed up in a singular terminal config.
  japhb++ for the fix.
roast/ugexe/retodo-legacy-failures: 8288e9dd7c | (Nick Logan)++ | 19 files
Restore todos for tests that still fail on the legacy frontend

Previously bd58f3a54 removed the todo markers of tests that pass now that RakuAST is the default. However many of those tests still fail with RAKUDO_RAKUAST=0, which broke the legacy spectest job in rakudo's CI. This restores the todo markers in the files where the legacy frontend still fails. The files where the tests pass on both frontends stay untodo'd.		 17:01
roast: ugexe++ created pull request #924:
Restore todos for tests that still fail on the legacy frontend
roast: 07e501eb25 | (Nick Logan)++ (committed using GitHub Web editor) | 19 files
Restore todos for tests that still fail on the legacy frontend (#924)

Previously bd58f3a54 removed the todo markers of tests that pass now that RakuAST is the default. However many of those tests still fail with RAKUDO_RAKUAST=0, which broke the legacy spectest job in rakudo's CI. This restores the todo markers in the files where the legacy frontend still fails. The files where the tests pass on both frontends stay untodo'd.		 17:03
linkable6 ROAST#924 [closed]: github.com/Raku/roast/pull/924 Restore todos for tests that still fail on the legacy frontend 17:04
roast: da425eb928 | (Elizabeth Mattijsen)++ | 8 files
Revert "Untodo test passing in 2026.09"

This reverts commit bd58f3a54c71c843254cc2817b0bc4f4744a35a4.		 17:39
ugexe ab5tract: irclogs.raku.org/perl6/2015-02-13....18:23-0004 timtoady says "TimToady for non-containers =:= is equivalent to ===" 18:33
maybe we should do that? 18:34
ab5tract That sounds pretty clean to me
[Coke] just got two "hey can I work on that" pings on 2 different repos from 2 different people. 18:37
(both raku related) 18:38
new people, I should stress. 18:39
this feels like a scam or something. :| 18:42
ugexe github.com/rakudo/rakudo/pull/6808 is worthy of a pre-merge Blin run if your cores are currently going to waste :) 18:52
19:03 bazzrrr0 joined 19:30 bazzrrr0 left
[Coke] 178 modules left to go on the current run 19:33
ugexe: if you can make it a rakudo branch also, that will make it much easier to blin run
20:14 jdv_ is now known as jdv
[Coke] who maintains the m: builds? 20:19
looks like it is stuck before 2026.09
Geth rakudo: ugexe++ created pull request #6811:
RakuAST: report a value a native return cannot take as a return type check failure		 21:24
[Coke] yah, this person is probably a bot. :| 21:25
github.com/Raku/Blin/issues/58#iss...6044383103
If they don't have more to say than "if you are not working can i work on this? @coke", I may end up blocking them from the raku repo. :(
Geth rakudo/ugexe/rakuast-package-trait-args: 2cad885b1b | (Nick Logan)++ | 8 files
RakuAST: declare a package's body with the block it sits in

Previously a package other than a role emitted its body as an immediate block in the code evaluating the package. Code that only takes the type of a package never compiles that expression, so the body never reached the program and serializing the methods of the type died with
  "QAST::Block with cuid N 'POPULATE' ... has not appeared". This happened
... (18 more lines)
[Coke] ~~ s/repo/org
Geth rakudo/ugexe/rakuast-package-trait-args: 73a88727aa | (Nick Logan)++ | 14 files
RakuAST: declare what a package's header declares with its body

Previously the declarations in the traits of a package, e.g. `my class C is foo(my constant K = 5) { method m { K } }`, belonged to the package's scope, which produced no code. Nothing declared them at runtime, so the body saw `(Mu)` for a variable or constant, and a sub or an enum value was `VMNull`. ... (23 more lines)
ugexe [Coke]: ^ i pushed it into the repo org repo (all the noise is why i normally use my own remote instead of the official rakudo one)
21:51 lizmat left
[Coke] makes sense. 21:51
doing the redo through 11ac8beafc, only 3 to check. 21:53
c: 73a88727aa e
committable6 [Coke], ¦73a8872: «»
[Coke] cool, already built, will kick it off before I leave, probably.
11ac8beafc clear on retest, even for Injector? (wonder if it got pushed) 21:59
linkable6 (2026-10-07) github.com/rakudo/rakudo/commit/11ac8beafc Bump NQP for line number annotation fix
[Coke] kicking off a run for 73a8872 now 22:00
Geth rakudo: ugexe++ created pull request #6812:
Handle a Slip from a loop body the same in every loop iterator		 22:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!