[Coke] WOOT 00:26
Geth Blin/coke/systemd: 5056b47a79 | (Will Coleda)++ | lib/Blin/Processing.rakumod
Run testing through systemd
 00:35
[Coke] now to do a ful l run and see if that helps. 00:36
Geth rakudo/ed6913c55-but-with-rakuast: c6b06c7aab | (Will Coleda)++ | src/main.nqp
Make AST the default, support RAKUDO_LEGACY
 00:49
[Coke] ok, kicked off another ast blin run using per-test systemd 01:05
bah, this is going waaaay too fast 01:08
... if I add debug output it works. wtf 01:16
... if I add debug output it *partially* works. wtf
Geth rakudo: ugexe++ created pull request #6547:
Make loop controls work in hyper and race iteration		 01:23
Blin/coke/systemd: 47de4b8e1c | (Will Coleda)++ | lib/Blin/Processing.rakumod
respect $timeout
 01:25
[Coke] I lost the timeout before - defaulted to 10s for a run, so my simple stuff often worked but timed out under load, and a full run everything timed out. think a real run is going now 01:27
Geth Blin/coke/systemd: 04dc20f4b5 | (Will Coleda)++ | util/summarize-overview.raku
Simple tool to summarize output/overview counts
 01:40
[Coke] not sure how trustworthy, but 6 ast failures so far out of 451 tested 02:05
Geth rakudo: ugexe++ created pull request #6548:
RakuAST: compile resolved operator calls as static lookups		 04:20
rakudo: ugexe++ created pull request #6549:
RakuAST: elide unused implicits from methods and generated accessors		 04:21
rakudo: ugexe++ created pull request #6550:
RakuAST: optimize the compiled regex QAST at code generation		 04:22
japhb ugexe: You were saying earlier that you thought you might be out of ecosystem-driven targets for RakuAST work ... what's driving the PR train currently? 05:36
08:12 finanalyst joined
finanalyst .tell [Coke] would you please take a look at the doc-website PR 08:27
tellable6 finanalyst, I'll pass your message to [Coke]
09:21 [Coke] left 09:26 [Coke] joined
lizmat m: dd Mu.are(Mu) 12:29
camelia No such method 'are' for invocant of type 'Mu'
in block <unit> at <tmp> line 1
lizmat meh
m: dd Any.are(Mu) 12:32
camelia Bool::True
lizmat m: dd Any.are(Any)
camelia Bool::True
lizmat m: dd Any.are(Cool)
camelia Failure.new(exception => X::AdHoc.new(payload => "Expected 'Cool' but got 'Any'"))
[Coke] bah. that run also died with oom-kill at 89.54% completion. 12:52
tellable6 2026-08-12T08:27:41Z #raku-dev <finanalyst> [Coke] would you please take a look at the doc-website PR
[Coke] ugexe: only 80 failures, with 262 untested because of the OOM 12:57
timo: what is "CPUWeight=100" doing? 12:59
timo prioritization for CPU time 13:00
it sounds like 100 is the default value, so it might not be doing anything?
[Coke] right.
ok. if I have --unit=blin on the main process, and then invoke systemd-run inside that... are those still "under" the blin run? 13:01
wondering if with the current setup a runaway test could still kill the top level unit 13:02
(feel free to throw me at some docs, also - something less dry than the man page would be helpful. :)
ugexe japhb: addressing some old open issues and optimizations 13:18
[Coke] trying a run with no systemd at the top level 13:23
timo ah, you mean systemd-run inside it with no other --unit or anything? 13:26
I honestly would inspect the unit it created with `systemctl cat`, or check with `systemctl status` what the tree structure looks like? 13:27
[Coke] oddly, all the blin stuff is under: ā”‚ ā”œā”€tmux-spawn-cd975b78-529d-4640-9564-13c4dd86b84b.scope 13:29
let me copy this into a gist
(this is without a top level --unit=blin, though. 13:31
(too big to gist), but here's one of the individual ones as well:
ā”‚ ā”œā”€run-p1571356-i1619476.service
ā”‚ ā”‚ ā”œā”€1571357 /tmp/whateverable/rakudo-moar/c6b06c7aab095ed79fe6ff584b256ca2c20d9c35/bin/perl6 -- /hom> ā”‚ ā”‚ ā””ā”€1575472 /tmp/whateverable/rakudo-moar/c6b06c7aab095ed79fe6ff584b256ca2c20d9c35/bin/perl6 -I /hom> ā”‚ ā”œā”€run-p1572471-i1530737.service
... oh, that's horrible.
timo the entire output would be too big to gist for sure, since it's your entire system 13:46
I find it rather difficult to make any sense of only these little bits
but yeah, tmux uses a systemd api to run each pane in its own little scope
you can also use --scope instead of --unit for the whateverabled things. that might be more sensible perhaps 13:48
and no, unfortunately I usually go through the man pages for the systemd directives and such
"systemd-cgls" can be helpful for figuring out the nesting of cgroups 13:51
[Coke] (scope) ok
man page tells me there's a scope, but no real info on what it's doing. 13:52
timo units are helpful when you want the systemd itself to manage the thing getting started when it's needed, or stopped, or what have you
ah, maybe this is not the right thing after all? > Scopes units manage a set of system processes. Unlike service units, scope units manage externally created processes, and do not fork off processes on its own. 13:53
[Coke] ok, I'm always doing this manually, so..
timo that pertains to the question of whether or not new processes started in some way or another will become a part of the thing you're configuring or not
oh! there's the switch I've been looking for: OOMPolicy=continue 13:54
> If set to continue and a process in the unit is killed by the OOM killer, this is logged but the unit continues running.
[Coke] ok, so that sounds like I want to : 1) put back systemd on the main runner, 2) remove it from the children, 3) add that policy to the top level runner. 13:56
though my current run with no systemd at the top, and system on the individual runs might also work 13:57
will let tthis finish
[Tux] Rakudo v2026.07-94-ged6913c55 (v6.d) on MoarVM 2026.07-13-gf6dab41c7
csv-ip5xs0.281 - 0.295
csv-ip5xs-201.132 - 1.176
csv-parser1.144 - 1.148
csv-test-xs-200.116 - 0.116
test1.856 - 1.862
test-t0.487 - 0.508
test-t --race0.315 - 0.337
test-t-206.417 - 6.495
test-t-20 --race1.496 - 1.507
 13:58
csv-test-xs 0.016 - 0.017
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
ugexe rakuast wise the bigger optimization left is buildplan / populate i think 14:03
500k Foo.new (2 attrs + defaults)0.1030.693
legacy vs rakuast
i still have some smaller optimizations to go through but i dont think anything would come close to that 14:04
timo it would be good to also give either the individual test processes a high OOMScoreAdjust or the main blin process a low (negative) OOMScoreAdjust value 14:12
otherwise it's still possible the main blin process gets chosen over the individual test processes
[Coke] timo - look slike this run just exploded. the top level process just died with 128 left to go. 17:42
so I'll add it back to the top level, add continue to that, and try the OOM Score Adjust.
thanks for the pointers, we'll get there eventually.
ugexe: only 90 failures in this partial run
Geth rakudo: ugexe++ created pull request #6551:
RakuAST: report static types for attribute reads and self		 18:12
rakudo: ugexe++ created pull request #6552:
RakuAST: form a setting operator's meta-op at compile time		 18:13
[Coke] ah. my geth complaint a few days ago is likely because the url was dragging in the timestamp from the next row somehow. 18:14
I assume this is because of my particular setup (mac ssh inside iterm2 to another mac, running irssi in a tmux session) 18:15
if I cut and paste the links, no issue
ugexe nice, presumably under 100 finally. hopefully these new prs don't push it back up too much 18:17
[Coke] 2459 out of 2507 modules processed (98.08%) 20:39
promising
<100 failures, 1597 OK on this last ast blin run 21:40
main process did not die from OOM - not sure if any of the outputs show an issue.
the outputs DO now include the runtime/memory usage of the given test as well
they all seem to say "Finished with result: success" 21:41
Geth Blin/coke/systemd: 298f3967b7 | (Will Coleda)++ | lib/Blin/Debug.rakumod
remove extraneous space
 21:42
ugexe github.com/coke/raku-ast-blin-resu...lo_0.0.8_0 21:50
kind of odd output at the start of that (and others) 21:51
the auth-matcher() that its complaining about isn't something a user would be calling directly 21:52
22:22 rakkable left, rakkable joined
japhb ugexe: Ah, makes sense (old open issues and optimizations). Very glad to hear about both, especially the optimizations part! :-D 22:59
[Coke]: I'm curious -- is there something in iterm2 that keeps you using it? My experience testing various terminals led me to believe it's less than awesome (especially since Ghostty has very nice native Mac behavior), but nevertheless people seem to really like iTerm2. So I'm curious what the "pro" is that overrides the cons. 23:04
*Ghostty exists and has ...

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!