[Coke] kicking off another AST blin run 00:17
ugexe nice 00:32
[Coke] 82/2477, no failures yet. 00:37
github.com:coke/raku-ast-blin-results.git - first 7 failures there. 01:11
about 1/2 are the ones that need the moarvm fix. 01:12
ugexe i dont see any
just the overview file 01:13
[Coke] forgot to git add 01:14
done
Geth rakudo: ugexe++ created pull request #6389:
RakuAST: allow a `*` slurpy on a callable parameter		 01:23
ugexe i thought i had fixed ADT but nope i just forgot to push that branch
timo my ADT module? I think it might actually not really work right in the first place :| 01:27
but if it's behaving differently in rakuast and legacy that's probably a bug anyway
[Coke] timo: github.com/coke/raku-ast-blin-resu...ut_ADT_0.5 01:28
timo aha 01:30
m: sub testy($t, *&code) { say "haha what" } 01:31
camelia ( no output )
timo c: da5abc586 sub testy($t, *&code) { say "haha what" }
committable6 timo, ¦da5abc5: «===SORRY!===␤Parameter * quantifier not applicable to sigil '&'␤ «exit code = 1»»
timo not sure what I wanted from that in the first place 01:32
share.firefox.dev/3QCtqrz - there is still so, so much wrong with this, but it's a first step! 01:54
[Coke] m: say 13/311 02:07
camelia 0.041801
[Coke] 30 failures 03:36
30/541 modules so far
Geth setup-raku: skaji++ created pull request #58:
Update npm dependencies		 03:55
setup-raku/master: 4 commits pushed by (Shoichi Kaji)++ 03:57
setup-raku: 30719ceee8 | (Shoichi Kaji)++ | CHANGELOG.md
v1.13.0

Co-authored-by: Codex <267193182+codex@users.noreply.github.com>		 04:01
setup-raku/refs/tags/v1: 8 commits pushed by (Shoichi Kaji)++, dependabot[bot]++
04:23 vrurg_ joined 04:25 vrurg left 05:30 camelia left, camelia joined 05:56 finanalyst joined 09:31 finanalyst left 12:02 MasterDuke joined
MasterDuke timo: nice, i like a good profile 12:03
timo this one is *not* good though :D 12:40
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
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
the stack part of that is built so that shared prefixes don't have to be stored repeatedly 12:42
oh, and samples of course have a time and a stack entry
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:44
12:46 [Coke] left 13:27 MasterDuke left 14:42 [Coke] joined 15:10 finanalyst joined
timo so, how are we feeling about a point release for moarvm? [Coke]? 15:16
[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
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.
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:24
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
[Coke] How are we sure that doesn't make anything worse, etc.
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.
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
[Coke] Also, this is the second release (in a row?) with a moarvm bug that was introduced in the month before the release.
so we need better testing.
ast blin run: 137 failures/1874 tested so far/2477 total 15:28
all pushed to the git repo
moarvm releases are pretty easy to do. If we have buyin from at least one other core dev, I'll cut that today
I'll revert my changelog commit. 15:29
fixed changelog 15:31
timo: where's the bug in github for this issue? 15:32
I don't see a link to it in the commit message, don't see a relevant bug with 'utf8' in it 15:33
timo i guess we don't have a github issue for it. we can create one after-the-fact if you prefer 15:36
i'm creating a moar one now 15:39
utf8 decoding forgot to set thread unblocked before allocating exceptions #2022 15:41
[Coke] thank you 15:45
timo and also thank you for your work
[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]: github.com/MoarVM/MoarVM/issues/2022 utf8 decoding forgot to set thread unblocked before allocating exceptions
[Coke] upto 149 blin fails 16:49
ugexe darn i was hoping we'd be under 150 total by now :/ 16:56
[Coke] ... if we get very lucky... 16:58
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
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:02
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:07
if the behavior before the buggy original fix isn't worse than the bug the fix introduced rather 17:08
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:18
17:21 finanalyst left
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:23
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:32
[Coke] 154 17:38
These last ones seem to get slower under AST, but I don't have hard data on that.
ugexe so previously it made slow progress, and now it makes no progress? 18:47
now being whatever is in the current release
Geth rakudo: ugexe++ created pull request #6390:
Handle the runtime Failure in the constant-folding warn test		 18:57
19:13 finanalyst joined
Geth rakudo/main: 941e1ae76e | (Nick Logan)++ (committed using GitHub Web editor) | t/08-performance/11-rakuast-constant-folding.t
Handle the runtime Failure in the constant-folding warn test (#6390)

The test program abandons the Failure that 1 div 0 assigns, so a garbage collection landing mid-run may legitimately collect it and warn on stderr, failing the test's :err('') check depending on GC timing alone. Mark the runtime Failure handled explicitly, leaving compile time as the only place the asserted warning could come from.		 19:49
19:51 finanalyst left 20:30 librasteve_ joined 20:33 librasteve_ left, librasteve_ joined
[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
/tmp/whateverable/rakudo-moar/941e1ae76eb79e8ecd8421a3c15689aeb47a44c4 is locked. Waiting…
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
ugexe yeah must be 20:56
lizmat fwiw, raku.land/zef:lizmat/JSON::Collector, raku.land/zef:lizmat/JSON::Webhook, raku.land/zef:lizmat/JSON::RepositoryEvent and raku.land/zef:lizmat/RepositoryEvent contain the building blocks for a new Geth 21:01
if someone wants additional events being reported by Geth (here, or somewhere private) please let me know 21:02
most notable additions so far: CheckSuite (when GitHub::Actions completes and produces a conclusion) 21:03
and support for Codeberg (Forgejo) event pushing 21:04
[Coke] ah, there were some modules that were running tests for 6 and 11 hours respectively 21:33
killed those, hopefully that speeds this run up
Geth rakudo: ugexe++ created pull request #6392:
RakuAST: allow binding to a topic call		 22:30
ugexe quite a few of these failures are from YAMLish which has the fix but needs a release 22:35
[Coke] I pinged leont on the closed PR 22:55
leont Oh right, I just released an update 23:04
23:05 Pixi` joined 23:08 Pixi left
[Coke] leont++ 23:16
hopefully our next blin ast run will clean up a bit. 23:17
⏳ 2280 out of 2477 modules processed (92.04%)
177 failures
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
gist.github.com/ugexe/eec3506b8a62...0f5b504f0f
works if i disable spesh 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!