Geth rakudo/main: 20 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/0...3badfb0df4
00:16
rakudo: ugexe++ created pull request #6667:
RakuAST: fix a fifth batch of deparse holes found by round tripping raku code
00:18
01:06 kurahaupo joined
[Coke] setting it to -1000 didn't help 02:23
github.com/coke/raku-blin-release-...9/suspects 02:46
grabbed several screens worth up to the end
ugexe eventually blin should probably pipe the test output directly to a file instead of storing it all in memory, which is going to add up with that many modules 03:02
it'd also presumably let someone look at the tests full output for anything that got run at all even when getting oomd 03:03
Geth rakudo/main: 16 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/b...b6ce74e13d
04:31
rakudo: ugexe++ created pull request #6668:
RakuAST: fix a sixth batch of deparse holes found by round tripping raku code
04:32
05:29 kurahaupo left 06:08 finanalyst joined 06:44 kurahaupo joined 06:56 kurahaupo left 07:06 sivoais left 07:12 sivoais joined 08:48 finanalyst left 09:13 finanalyst joined 09:15 finanalyst left 09:17 finanalyst joined
Geth rakudo/main: 8d0908b0e3 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.rakumod
RakuAST: simplify .raku on RakuAST::Regex::InternalModifier::xxx

If the modifier matches the key, there's no need to create a .raku argument representation for it
09:39
rakudo/main: afe3689207 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals.rakumod
R:I.IS-ISOLATED-MATCH does not need boolification

It's an internal method, returning 0 or 1 is enough
11:11
lizmat ugexe: re not setting $/ in 6.e: this basically only applies to Str.match and Str.subst, right? 12:01
or am I missing some cases ?
12:47 finanalyst left
lizmat ah, .trans and Grammar.parse 12:58
13:16 finanalyst joined 13:39 finanalyst left
ab5tract āž¤ raku -M6.e.PREVIEW 14:28
===SORRY!=== Error while compiling:
Could not find 6.e.PREVIEW in:
do we provide a mechanism for declaring the compiler version for an interactive run? 14:29
I guess I just do it inside the session
(it also fails to compile without my silly typo :) ) 14:30
ugexe its actually different now 14:45
actually im wrong
anyways i think -M happens too late
v6.whatever wouldnt be the first statement 14:46
already looked into that as part of github.com/rakudo/rakudo/pull/6631
basically the version is decided before -M runs 14:48
ab5tract that makes sense actually. taking a loog at your PR now 14:49
so if we did want users to be able to select a version, it would need it's own flag that gets resolved first 14:50
timo do we want to build anything that warns the user if their -I (be it implicit or explicit, flag or env var) points at a place that is enormous, for example having the equivalent of `-I .` in one of the corresponding env vars and then starting rakudo in ~/ and wondering why it takes a million hours to start up? 14:51
ugexe yeah a flag or env var to set the language make sense in the context of -e but what about anything else? li 14:53
should we have a warning if dir() produces a billion results and takes awhile? 14:54
14:57 ShimmerFairy left
timo don't think so, you can consume that lazily and it's not recursive by default either 14:58
ugexe right but dihwidt cuts both ways. are most people using dir() lazily? i doubt it 15:00
i concede it is less likely to happen without the recursion though
timo one other important difference is that you're not necessarily expecting `-I .` to recursively go through your entire ., especially since (AIUI) it doesn't do it unless you also use a `use` statement (or equivalent) in your code 15:03
15:03 ShimmerFairy joined
Geth rakudo/main: 14 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/a...9b177711b2
15:05
timo also, we should check if CompUnit::Repository::FileSystem should be following symlinks - always, never, or never if they lead outside of the original starting path 15:06
Geth rakudo: ugexe++ created pull request #6669:
RakuAST: fix a seventh batch of deparse holes found by round tripping raku code
15:07
ab5tract timo: when you say "not recursive by default", do you mean that there is a non-handrolled recursive way to call dir()? 15:11
ugexe it was brought up at least once before github.com/rakudo/rakudo/pull/1045 15:13
timo ab5tract: i'm not aware of one off-hand
but we do have one internally in rakudo
ab5tract ugexe: yeah we also talked about it recently, and also [Coke] suggested File::Find 15:14
ugexe the combitorial explosion of parameters is definitely a problem we've seen elsewhere 15:15
ab5tract timo: interesting. it's something that trips me up every time. I don't _really_ mind implementing my own BFS each time, it does keep me fresh, but it also feels really strange to be missing
timo but I was thinking only of how CU::R::FS specifically is recursing through the path it is given
ab5tract zoffix says that File::Find is provided in the Rakudo distribution, but I do not find it in mine 15:19
ugexe i think they meant raku star
timo could mean Rakudo::Star, or perhaps on some linux distribution's default
ab5tract ack. I've gotten into this argument about zef only to find that it is actually present in the pre-compiled rakudo builds (or was last time I checked, I always do rakubrew build, not rakubrew download) 15:20
ugexe heh yeah for zef it has to start its CI actions with `raku -e 'my $site = CompUnit::RepositoryRegistry.repository-for-name(q|site|); $site.uninstall($_) for $site.installed'` 15:22
ab5tract another discussion for some point: `raku` was never meant to be wholly owned by Rakudo. Now that we have two non-Rakudo based thingies, we might want to consider how configuring what `raku` "means" should look like
ugexe well creating a raku compiler doesn't get you a free seat on the RSC 15:23
timo in any case, in a system that has podman and you use it with its defaults from your user, if you have -I include your home, you will see it recurse into all your container's storage folders, which can have symlinks that are meant to be absolute but relative to the container's own filesystem, not your host's, and then you can get into /run/user/$UID/xyz/ which is a folder that has files in it that
may give "no such file or directory" when you try to stat them, and then you get a very weird compile time error of "Failed to stat file: no such file or directory" without a path, without a line number to point at the "use" statement, and without any hint that it's about your wrong -I
ugexe but yeah we do need to keep other implementations in mind
ab5tract ugexe: if all this Truffle/JVM stuff actually produces a usably fast implementation, it will also come back up for us too. IIRC, `raku` would just point to whichever backend was compiled last 15:24
timo I'm going to write a PR that makes the error less LTA
ab5tract timo++ 15:25
theoretically, would making -I. fail without a META6.json in immediate scope be justifiable?
timo it's quite possible that "`-I $HOME` behaves badly" is just a DIHWIDT, or maybe we can decide that we shouldn't follow symlinks inside the given path to anywhere outside of the intended path if that's not prohibitive in terms of performance 15:26
ugexe that would be great, but most people when developing aren't keeping their meta6.json up to date (or may not even have one)
plus sometimes you just want a one-off module
ab5tract ugexe: then in those cases they could be directed to -Ilib, no?
ugexe the problem is the distinction between distribution and module
timo pretty sure -I with a folder is often used for non-modules that just have some helpers
ugexe the argument to -I is arbitrary
timo for example, rakudo's t/04-nativecall/CompileTestLib.rakumod isn't in any kind of module 15:27
ugexe -I. and -Ilib are just basic examples of what the distinction usually (but doesnt have to) entail
timo the tests in there set up `use lib <lib t/packages/Test-Helpers t/04-nativecall>;`
ugexe really its -I $path-with-no-meta6 and -I $path-with-meta6 15:28
timo sorry, I claimed that the error gives no pointer at the line with `use` but it does. it just doesn't put a `<HERE>` and the code in the output 15:30
ugexe CompileTestLib is a module, it isnt part of a distribution.
ab5tract hmm.. so maybe a compromise point: with -Iwhateva will not follow symlinks (and a worry stating so could possibly be emitted) unless -Iwhateva has a META6.json. To restate less obliquely, bank the decision for following symlinks as to whether a META6.json exists in that location.
having written that out, it feels a bit arbitrary though
I do think a bit of sanity protection like you are proposing is reasonable tho, timo 15:32
timo the "wow your -I has a shitton of files in it, is that really okay?" one? 15:33
ab5tract yeah :) 15:34
15:38 lizmat left, Geth left 15:39 Geth joined
Geth nqp/make_Cursor_cursor_fail_method_more_inlinable: c2a34c6e2f | (Timo Paulssen)++ | src/QRegex/Cursor.nqp
Make !cursor_fail return self like nearby methods instead of the $!pos

This makes it inlinable into callers that have a different HLL, since return_i is an instruction that uses_hll in moarvm.
15:43
nqp: timo++ created pull request #874:
Make !cursor_fail return self like nearby methods instead of the $!pos
15:47
timo greppable6: !cursor_fail 15:49
greppable6 timo, Found nothing!
timo greppable6: eco !cursor_fail
greppable6 timo, Found nothing!
timo greppable6: help
greppable6 timo, Like this: greppable6: password # See wiki for more examples: github.com/Raku/whateverable/wiki/Greppable
timo do i need rakkable for that? 15:50
lizmat_ hmmm 15:57
15:58 rakkable joined
lizmat_ rakkable: eco-provides !cursor_fail 15:58
rakkable lizmat_, Running: eco-provides !cursor_fail, please be patient!
lizmat_, Found 9936 lines in 65 files (12 distributions):
lizmat_ meh
timo wow. can you give me the results? 15:59
15:59 rakkable left, rakkable joined
lizmat_ rakkable: eco-provides !cursor_fail 15:59
rakkable lizmat_, Running: eco-provides !cursor_fail, please be patient!
lizmat_, Found 9936 lines in 65 files (12 distributions):
lizmat_, gist.github.com/bff16e7e952eb768f9...e07a299dbf 16:00
timo oh
that's "any line that doesn't have cursor_fail in it"?
lizmat_ hmmm.. that feels.. incorrect
could be
rakkable: eco-provides cursor_fail
rakkable lizmat_, Running: eco-provides cursor_fail, please be patient!
lizmat_, No occurrences found for: eco-provides cursor_fail
timo that makes a lot more sense
I wonder why it only reported 12 distributions though 16:01
limited to 10k lines?
lizmat_ yeah, probably
16:02 lizmat_ left, lizmat joined
timo is 10000 files a good threshold for "this is probably not what you meant to do" for -I or RAKULIB? 16:17
lizmat bisectable6: old=2026.01 for ^10 { say %_ } 16:19
bisectable6 lizmat, On both starting points (old=2026.01 new=afe3689) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «Too many positionals passed; expected 0 arguments but got 1␤ in block <unit> at /tmp/X7oDTDBLgQ line 1␤␤»
lizmat hmmm
error is a bit LTA though
Geth rakudo/warn_probably_wrong_use_lib_or_RAKULIB_pointed_at_huge_file_tree: a2c4abadb1 | (Timo Paulssen)++ | src/core.c/CompUnit/Repository/FileSystem.rakumod
Warn if "use lib" or RAKULIB or whatever points at a huge dir tree

For now, I just chose 10k files crawled as a reasonable "did you really mean to do this?" threshold.
Using "warn" is not my favourite way to do this, but I'm not sure if I can add a WORRY from this piece of code, since it may run at run-time as well.
16:21
rakudo/main: 15 commits pushed by (Nick Logan)++
review: github.com/rakudo/rakudo/compare/c...37d796e270
16:27
rakudo/warn_probably_wrong_use_lib_or_RAKULIB_pointed_at_huge_file_tree: bc2c84a7df | (Timo Paulssen)++ | src/core.c/CompUnit/Repository/FileSystem.rakumod
Warn if "use lib" or RAKULIB or whatever points at a huge dir tree

For now, I just chose 10k files crawled as a reasonable "did you really mean to do this?" threshold.
Using "warn" is not my favourite way to do this, but I'm not sure if I can add a WORRY from this piece of code, since it may run at run-time as well.
Also give a better error message on exceptions when crawling directory trees.
rakudo: timo++ created pull request #6670:
Better error when crawling files for "use lib" or RAKULIB fails, and warn about too big dir trees
16:29
ugexe seems unfortunate to wrap all that logic in a try
timo another thing we could do is put a try/catch in the DirRecurse iterator 16:30
I haven't checked yet if that's where the error originates, actually
ugexe ideally we only try/catch the thing that would actually fail and not catch stuff like syntax errors for unrelated logic 16:31
timo hm? how would a syntax error give an exception there?
ugexe m: try { my $x = "abc".substr(1,2,3) }; say 42 16:33
camelia 42
ugexe this is what i mean
timo oh you mean if someone later changes the code and introduces an error, it would be caught there? 16:34
ugexe yeah... although i glossed over the CATCH with it being in the middle of the block instead of start/end 16:36
still, it seems like a code smell to have `my int $total-files = 0;` in a try block for instance 16:37
timo oh, curious, the default DIR-RECURSE uses "doesn't start with a dot" as the criteria to consider putting something new on the $!todo
not sure why. the value is not needed outside of the try block, it seems like a sensible life-time boundary 16:38
ugexe but then again having try foo() with where foo() calls that seems fine
so probably just my own personal preferences at play
timo ahahahaha, I wanted to repro the issue with "could not stat" and instead of hitting the folder where that happens, rakudo ran off into /run/user/1000/kio-fuse-xyz/fish/bla@foo.local/ and is now exploring "/sys/devices/pci0000:00/.../.../.../..." on another system over ssh 16:48
repro it inside gdb, that is
[Coke] hee. tried setting blin at -1000 for OOM policy, and each test run at 1000 - every test failed instantly. :) 17:18
like, the whole run of 2500 modules finished in 3min 17:19
(hopefully this is a misconfig invoking the command) 17:29
timo did you still have max memory at 10 megabytes? 17:47
[Coke] ah, good. now getting a normalish run, we'll see if the OOM killer ruins the party
I don't have max memory set for anything 17:48
systemd-run -E RAKULIB=. --user --tty --wait --working-directory=$RUNDIR --unit=blin --slice=user.slice --property="CPUW
eight=101" --property="OOMPolicy=continue" --property="OOMScoreAdjust=-1000" raku bin/blin.p6 --old=$OLD --new=$NEW --he
artbeat=$HEARTBEAT
^^ blin
22:my @systemd-cmd = 'systemd-run', "--working-dir=$cwd", '--user', '--tty', '--wait', '--slice=user.slice', '--property=OOMScoreAdjust=1000';
^^ individual test run
timo `blin.service` might have something in it; you can try `systemctl cat blin.service` to find out, though `systemctl status blin.service` should also show that with a lot less noise around it 17:49
that CPUWeight of 101 seems like an incredibly small amount of adjustment :D 17:52
[Coke] no files found for blin.service
Unit blin.service could not be found.
timo oh, you have --user in systemd-run, so you probably have to also pass --user to systemctl so it communicates with the correct instance of systemd (each user gets a user instance of systemd) 17:53
Geth rakudo: ugexe++ created pull request #6671:
RakuAST: fix a eighth batch of deparse holes found by round tripping raku code
18:14