[00:17] <[Coke]> kicking off another AST blin run

[00:32] <ugexe> nice

[00:37] <[Coke]> 82/2477, no failures yet.

[01:11] <[Coke]> github.com:coke/raku-ast-blin-results.git - first 7 failures there.

[01:12] <[Coke]> about 1/2 are the ones that need the moarvm fix.

[01:12] <ugexe> i dont see any

[01:13] <ugexe> just the overview file

[01:14] <[Coke]> forgot to git add

[01:14] <[Coke]> done

[01:23] <Geth> ¦ rakudo: ugexe++ created pull request #6389: RakuAST: allow a `*` slurpy on a callable parameter

[01:23] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6389

[01:23] <ugexe> i thought i had fixed ADT but nope i just forgot to push that branch

[01:27] <timo> my ADT module? I think it might actually not really work right in the first place :|

[01:27] <timo> but if it's behaving differently in rakuast and legacy that's probably a bug anyway

[01:28] <[Coke]> timo: https://github.com/coke/raku-ast-blin-results/blob/main/output_ADT_0.5

[01:30] <timo> aha

[01:31] <timo> m: sub testy($t, *&code) { say "haha what" }

[01:31] <camelia> rakudo-moar 7d3a0c0e3: ( no output )

[01:31] <timo> c: da5abc586 sub testy($t, *&code) { say "haha what" }

[01:31] <committable6> timo, ¦da5abc5: «===SORRY!===␤Parameter * quantifier not applicable to sigil '&'␤ «exit code = 1»»

[01:32] <timo> not sure what I wanted from that in the first place

[01:54] <timo> https://share.firefox.dev/3QCtqrz - there is still so, so much wrong with this, but it's a first step!

[02:07] <[Coke]> m: say 13/311 

[02:07] <camelia> rakudo-moar 7d3a0c0e3: OUTPUT: «0.041801␤»

[03:36] <[Coke]> 30 failures

[03:36] <[Coke]> 30/541 modules so far

[03:55] <Geth> ¦ setup-raku: skaji++ created pull request #58: Update npm dependencies

[03:55] <Geth> ¦ setup-raku: review: https://github.com/Raku/setup-raku/pull/58

[03:57] <Geth> ¦ setup-raku/master: 4 commits pushed by (Shoichi Kaji)++

[03:57] <Geth> ¦ setup-raku/master: 8e0d670a65 | Update npm dependencies

[03:57] <Geth> ¦ setup-raku/master: 55925473ad | Approve dependency install scripts

[03:57] <Geth> ¦ setup-raku/master: e140e3660f | Update checkout action references

[03:57] <Geth> ¦ setup-raku/master: 6c0e92a04f | Merge pull request #58 from Raku/codex/update-dependencies-20260704

[03:57] <Geth> ¦ setup-raku/master: review: https://github.com/Raku/setup-raku/compare/f788e4c0e77a...6c0e92a04f0c

[04:01] <Geth> ¦ setup-raku: 30719ceee8 | (Shoichi Kaji)++ | CHANGELOG.md

[04:01] <Geth> ¦ setup-raku: v1.13.0

[04:01] <Geth> ¦ setup-raku: 

[04:01] <Geth> ¦ setup-raku: Co-authored-by: Codex <267193182+codex@users.noreply.github.com>

[04:01] <Geth> ¦ setup-raku: review: https://github.com/Raku/setup-raku/commit/30719ceee8

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: 8 commits pushed by (Shoichi Kaji)++, dependabot[bot]++

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: b6140a4d15 | use actions/checkout@v6 in README

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: f6d278afea | Bump esbuild from 0.28.0 to 0.28.1 (#56)

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: f788e4c0e7 | Bump undici from 6.24.1 to 6.27.0 (#57)

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: 8e0d670a65 | Update npm dependencies

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: 55925473ad | Approve dependency install scripts

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: e140e3660f | Update checkout action references

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: 6c0e92a04f | Merge pull request #58 from Raku/codex/update-dependencies-20260704

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: 30719ceee8 | v1.13.0

[04:01] <Geth> ¦ setup-raku/refs/tags/v1: review: https://github.com/Raku/setup-raku/compare/a8b3750352ba...30719ceee8d5

[04:23] *** vrurg_ joined
[04:25] *** vrurg left
[05:30] *** camelia left
[05:30] *** camelia joined
[05:56] *** finanalyst joined
[09:31] *** finanalyst left
[12:02] *** MasterDuke joined
[12:03] <MasterDuke> timo: nice, i like a good profile

[12:40] <timo> this one is *not* good though :D

[12:40] <timo> the code I wrote is terrible, the variable names are too confusing, I'm not sure what I'm doing wrong exactly, but I think I'm not correctly putting multiple frames together into the same funcs that they belong to

[12:41] <MasterDuke> heh. but it *looks* cool

[12:41] <timo> the format has multiple layers: a func is like a collection of instruction pointer addresses, a frame is one instruction pointer address, a stack entry is one frame and one parent stack entry

[12:42] <timo> the stack part of that is built so that shared prefixes don't have to be stored repeatedly

[12:42] <timo> oh, and samples of course have a time and a stack entry

[12:44] <timo> and you can give every "frame" a different category (I chose Other, User, Core, NQP, Rakudo, Modules) but the code that tries to assign categories to frames went wrong so the same function can get basically every category :D

[12:46] *** [Coke] left
[13:27] *** MasterDuke left
[14:42] *** [Coke] joined
[15:10] *** finanalyst joined
[15:16] <timo> so, how are we feeling about a point release for moarvm? [Coke]?

[15:22] <[Coke]> I'm not excited about it

[15:22] <tellable6> 2026-07-04T13:17:22Z #moarvm <MasterDuke> [Coke]: i think your changelog commit also dropped mimalloc back to v2.2.7, it had been at v2.3.2

[15:23] <timo> I think The Bug™ is quite severe

[15:23] <[Coke]> feel free to revert the changelog. I didn't intentionally change anything about mimalloc, so it kind of sucks that it did that.

[15:24] <[Coke]> I actually have a set of git commands I have to run when doing the release to clear out any accidental submodule changes (which seems crazy that we need to do that.)

[15:25] <[Coke]> timo: OK. Get the other core devs to agree, point me at the commit that needs adding. (is it the only one on main?)

[15:25] <timo> oh I'm only talking about the freezing up when decoding utf8 with errors in it bug

[15:25] <[Coke]> How are we sure that doesn't make anything worse, etc.

[15:25] <[Coke]> timo: Yes. there are two conversations going on here, one about your one bug for a potential point release, and one for my bad changelog commit.

[15:26] <[Coke]> Also: please udpate the change when committing.

[15:26] <timo> the only one in main, yeah; the other option is to put a revert commit on top that makes the utf8 and utf8-c8 decoder not set the thread blocked

[15:26] <[Coke]> Also, this is the second release (in a row?) with a moarvm bug that was introduced in the month before the release.

[15:26] <[Coke]> so we need better testing.

[15:28] <[Coke]> ast blin run: 137 failures/1874 tested so far/2477 total

[15:28] <[Coke]> all pushed to the git repo

[15:28] <[Coke]> moarvm releases are pretty easy to do. If we have buyin from at least one other core dev, I'll cut that today

[15:29] <[Coke]> I'll revert my changelog commit.

[15:31] <[Coke]> fixed changelog

[15:32] <[Coke]> timo: where's the bug in github for this issue?

[15:33] <[Coke]> I don't see a link to it in the commit message, don't see a relevant bug with 'utf8' in it

[15:36] <timo> i guess we don't have a github issue for it. we can create one after-the-fact if you prefer

[15:39] <timo> i'm creating a moar one now

[15:41] <timo> utf8 decoding forgot to set thread unblocked before allocating exceptions #2022

[15:45] <[Coke]> thank you

[15:45] <timo> and also thank you for your work

[15:51] <[Coke]> folks, feel free to weigh in on the severity of this and if it requires a bugfix moarvm release on moarvm#2022

[15:51] <linkable6> MOARVM#2022 [closed]: https://github.com/MoarVM/MoarVM/issues/2022 utf8 decoding forgot to set thread unblocked before allocating exceptions

[16:49] <[Coke]> upto 149 blin fails

[16:56] <ugexe> darn i was hoping we'd be under 150 total by now :/

[16:58] <[Coke]> ... if we get very lucky...

[16:59] <[Coke]> Wonder how many are the MoarVM issue you were mentioning.

[16:59] <ugexe> it was ~50 the first time. i dont expect it to go down or up

[17:02] <ugexe> a lot of them are from NativeHelpers::Blob (the cant determien offset errors) which needs mdoule changes, many are using $*W and thus require module changes, many are slangs that probably have to be fixed at the module level

[17:07] <ugexe> as for the point release: i haven't really looked into the problem enough to understand the severity. based just on "bug that locks everything up" i'd be inclined to do it but i could also be convinced not to if 1) its not easy to encounter and 2) the behavior before the fix was better

[17:08] <ugexe> if the behavior before the buggy original fix isn't worse than the bug the fix introduced rather

[17:18] <timo> the bug before was just that if any thread initiates GC, all threads will twiddle their thumbs until the utf8 decode is finished and that thread can join in

[17:21] *** finanalyst left
[17:23] <timo> so it was mostly a question of potentially strongly degraded performance, like if you can get a service to decode large blobs as utf8 again and again, all your cores are going to waste

[17:32] <timo> to be fair, decoding 100_000 bytes 10_000 times takes 7.8s; the kind of pause you can force on a process may not be as dramatic?

[17:38] <[Coke]> 154

[17:38] <[Coke]> These last ones seem to get slower under AST, but I don't have hard data on that.

[18:47] <ugexe> so previously it made slow progress, and now it makes no progress?

[18:47] <ugexe> now being whatever is in the current release

[18:57] <Geth> ¦ rakudo: ugexe++ created pull request #6390: Handle the runtime Failure in the constant-folding warn test

[18:57] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6390

[19:13] *** finanalyst joined
[19:49] <Geth> ¦ rakudo/main: 941e1ae76e | (Nick Logan)++ (committed using GitHub Web editor) | t/08-performance/11-rakuast-constant-folding.t

[19:49] <Geth> ¦ rakudo/main: Handle the runtime Failure in the constant-folding warn test (#6390)

[19:49] <Geth> ¦ rakudo/main: 

[19:49] <Geth> ¦ rakudo/main: The test program abandons the Failure that 1 div 0 assigns, so a garbage

[19:49] <Geth> ¦ rakudo/main: collection landing mid-run may legitimately collect it and warn on stderr,

[19:49] <Geth> ¦ rakudo/main: failing the test's :err('') check depending on GC timing alone. Mark the

[19:49] <Geth> ¦ rakudo/main: runtime Failure handled explicitly, leaving compile time as the only place

[19:49] <Geth> ¦ rakudo/main: the asserted warning could come from.

[19:49] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/941e1ae76e

[19:51] *** finanalyst left
[20:30] *** librasteve_ joined
[20:33] *** librasteve_ left
[20:33] *** librasteve_ joined
[20:48] <[Coke]> weird. the blin run is between a commit on main and then a commit on a branch with rakuast enabled by default. I just got many lines of

[20:48] <[Coke]> /tmp/whateverable/rakudo-moar/941e1ae76eb79e8ecd8421a3c15689aeb47a44c4 is locked. Waiting…

[20:48] <[Coke]> which I think is the one that geth just announced on main, after the other one. Wonder if there's something manual about the bisect that's happening that does HEAD instead of the two commits in the chain

[20:56] <ugexe> yeah must be

[21:01] <lizmat> fwiw, https://raku.land/zef:lizmat/JSON::Collector, https://raku.land/zef:lizmat/JSON::Webhook, https://raku.land/zef:lizmat/JSON::RepositoryEvent and https://raku.land/zef:lizmat/RepositoryEvent contain the building blocks for a new Geth

[21:02] <lizmat> if someone wants additional events being reported by Geth (here, or somewhere private) please let me know

[21:03] <lizmat> most notable additions so far:   CheckSuite (when GitHub::Actions completes and produces a conclusion)

[21:04] <lizmat> and support for Codeberg (Forgejo) event pushing

[21:33] <[Coke]> ah, there were some modules that were running tests for 6 and 11 hours respectively

[21:33] <[Coke]> killed those, hopefully that speeds this run up

[22:30] <Geth> ¦ rakudo: ugexe++ created pull request #6392: RakuAST: allow binding to a topic call

[22:30] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6392

[22:35] <ugexe> quite a few of these failures are from YAMLish which has the fix but needs a release

[22:55] <[Coke]> I pinged leont on the closed PR

[23:04] <leont> Oh right, I just released an update

[23:05] *** Pixi` joined
[23:08] *** Pixi left
[23:16] <[Coke]> leont++

[23:17] <[Coke]> hopefully our next blin ast run will clean up a bit.

[23:17] <[Coke]> ⏳ 2280 out of 2477 modules processed (92.04%)

[23:17] <[Coke]> 177 failures

[23:54] <ugexe> CSS::Grammar failure seems to be spesh related bug on rakuast built core makes its map based ast reduce collaspe every element to the last value

[23:54] <ugexe> https://gist.github.com/ugexe/eec3506b8a62b50a7451240f5b504f0f

[23:56] <ugexe> works if i disable spesh