00:44 gfldex left 00:50 vrurg joined, gfldex joined 00:56 greppable6 left, unicodable6 left, vrurg_ left, [Coke] left, committable6 left, unicodable6 joined, greppable6 joined, [Coke] joined, committable6 joined 01:19 melezhik left 03:08 ntv left 03:10 apogee_ntv joined
[Tux] Rakudo v2025.10-27-g89dff65d3 (v6.d) on MoarVM 2025.10-11-g06c0bcbb7
csv-ip5xs0.263 - 0.266
csv-ip5xs-201.102 - 1.103
csv-parser1.139 - 1.140
csv-test-xs-200.116 - 0.117
test1.851 - 1.930
test-t0.462 - 0.473
test-t --race0.283 - 0.291
test-t-205.883 - 6.001
test-t-20 --race1.473 - 1.532
 08:59
csv-test-xs 0.014 - 0.014
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
09:16 melezhik joined 10:00 librasteve_ joined 13:21 ds7832 joined
timo ok, i'm back on the parallel module loading topic. i think i understand how the part i was unsure about works 13:33
13:35 melezhik_ joined
melezhik_ timo: ++ 13:35
timo i think i'm going to procedurally generate a ridiculous module with lots of modules that have a bunch of different dependency paths through all the bits and random sleeps in the module mainlines and such
melezhik_ if you want to experiment with brownie in that sense, just give me a shout
timo brownie may be a few levels too high up for my needs right now 13:36
melezhik_ yeah, I see 13:38
13:46 melezhik_ left 14:06 melezhik_ joined 14:09 melezhik_ left 14:34 melezhik_ joined 14:35 melezhik_ left 14:36 melezhik left 14:46 melezhik_ joined 14:48 melezhik joined 14:57 librasteve_ left 15:01 melezhik_ left, melezhik_ joined
melezhik_ . 15:04
15:20 melezhik_ left, melezhik_ joined
timo whatever i did made compilation errors during dependency precomp make the main process hang (probably only if other threads are waiting for precomp to finish) 15:23
15:32 melezhik_ left 15:42 melezhik_ joined 15:44 melezhik_ left
timo actually that may have already been there before 15:52
15:58 melezhik_ joined 16:02 melezhik_ left 16:13 melezhik_ joined 16:19 melezhik_ left, melezhik_ joined
timo huh. "say" or "note" inside a BEGIN block in a file that gets precomped can break because looking up &say and &note result in VMNull somehow, and trying to invoke that breaks ... but the issue doesn't seem to appear without --stagestats or RAKUDO_MODULE_DEBUG=1 16:21
oh, huh, just running the file itself manually also causes this problem? without any flags or env vars?
ugexe ah 16:23
there is some ipc via stderr/stderr
timo is this a known issue? or did i somehow break it with my changes? i'll rebuild rakudo on main i guess 16:25
i thought it was only stdout 16:26
for the dependencies, right?
ugexe github.com/rakudo/rakudo/blob/89df...kumod#L428
around here and after
timo .o( if we had proper filehandle inheritance control for &run and Proc::, we could keep stdout and stderr free for the user to use )
ugexe but yeah i think it passes the depenencies through
and rakudo_module_debug being on/off changes something about stderr and/or stdout that gets used (sorry for being vague, i forget the details) 16:27
github.com/rakudo/rakudo/blob/89df...#L447-L451
probably related to that bit
i don't think there is a proper issue for it though 16:28
timo that would explain why setting RAKUDO_MODULE_DEBUG causes something to happen, but --stagestats also causes the issue 16:29
ugexe yeah and here is another RMD change of behavior right around there github.com/rakudo/rakudo/blob/89df...#L469-L471
timo i think that's too far away from the thing i'm seeing 16:30
i literally saw getlex_no '&say' return a VMNull 16:31
inside of my BEGIN block
oh no, the error goes away when i build from rakudo main ;_; 16:32
was it a fluke? i can't get it reproduced any more it looks like 16:37
16:53 melezhik_ left, melezhik_ joined
Geth rakudo/precomp_repo_no_parallel_load_of_same_precompiled_file: 002dac33e2 | (Timo Paulssen)++ | src/core.c/CompUnit/Repository/FileSystem.rakumod
When precomp fails, notify waiting threads of failure

Otherwise, multiple threads requiring the same compunit, that then first has to be precompiled, and fails to compile for some reason, will keep waiting forever for the Promise to be broken or kept.		 16:55
16:56 melezhik left
timo i should have made the branch name shorter 16:59
Geth rakudo/precomp_repo_no_parallel_load_of_same_precompiled_file: 040d145a44 | (Timo Paulssen)++ | src/core.c/CompUnit/PrecompilationRepository.rakumod
in !load-dependencies, handle loaded hash right

need to not just check that there is something in a slot, but now we can also have Promise objects in there that we need to await.		 17:03
17:16 melezhik_ left
timo hm, i cannot recommend running the stresstest thing with 500 modules and four rakudos in parallel trying to precomp everything 17:38
the ram usage is rather a lot
gist.github.com/timo/c206a75790f55...133d788c99 18:22
i reduced the max number of dependencies a module can have on something in the next sphere to 6 instead of "as much as there are modules in there" which makes the growth from the recursiveness a lot less ridiculous
lizmat: responded to your comment on my PR, does it clear up the question? 18:28
hmm. that isn't actually crashy with rakudo on main branch 18:32
lizmat it answers my question: but perhaps explain that in a comment there 18:34
18:37 melezhik_ joined 18:50 melezhik_ left, melezhik_ joined 18:55 melezhik_ left, melezhik_ joined
timo i feel like "otherwise the dependency precomp has already been loaded and we can just go on" is like what i explained 18:59
19:04 melezhik_ left 19:05 melezhik_ joined
melezhik_ finally solved the problem with output buffering and now o10r main page gets realtime data over web socket (every 2 minutes) 19:08
brw.sparrowhub.io/report/brw-orch/2058
^^ ab5tract:
19:17 melezhik_ left
lizmat timo: yeah, you're right. Didn't make the link between "we've promised" and "returned a Promise" in my head :-( 19:59
weekly: time to think about the Raku Advent Calendar! 20:14
notable6 lizmat, Noted! (weekly)
20:16 ds7832 left 20:37 melezhik_ joined 20:41 melezhik_ left 20:44 ds7832 joined 22:02 vrurg left 22:14 melezhik_ joined 22:16 melezhik_ left 22:17 melezhik_ joined 22:20 vrurg joined 22:21 melezhik_ left 23:18 melezhik_ joined 23:22 melezhik_ left 23:50 melezhik_ joined 23:54 melezhik_ left 23:55 melezhik_ joined 23:57 melezhik_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!