00:32 kjp left 00:33 kjp joined 00:35 kjp left, kjp joined 07:58 sp1983 joined
sp1983 timo: please take a look when you have a chance - github.com/melezhik/Sparrow6/pull/10/changes , started my regression tests 08:00
tellable6 2026-04-06T18:30:59Z #raku <El_Che> sp1983 thx!
08:02 finanalyst joined 08:38 finanalyst left
timo sp1983: on a first quick glance it looks like it should work 09:00
sp1983 good)
hopefully it will fix this "resource temporary unavailable" 09:01
and btw - the way it works now - lines are clear, no gibberish
timo can you find out what terminal emulator the user who gets that error is using? and whether there's a "screen" or "tmux" or similar tool in the middle? how about an ssh connection? 09:04
sp1983 I guess it's tmux 09:06
so he runs sparky in tmux and then sparky would run raku program that runs qemu program in background and reads it's stdout back to raku 09:07
via ProcAsync 09:08
and this output is printed out with timestamps back to file
pretty much that
timo just in the interest of simplifying the whole situation, trying to see if removing tmux lets us still see the error would be interesting
sp1983 yeah, I also thought about that ... it'd funny if in the end of the day this is tmux fault ) 09:09
timo well, it's not necessarily tmux's "fault", it's just possible that it contributes some necessary little piece to cause the actual problem 09:10
sp1983 yeah 09:12
timo if we can golf down the issue to make it easily reproducible with just a tiny piece of raku code in a specific situation, we need to decide if the "temporarily not available" error is something that "say" and friends should throw towards the user, or if it should internally be handled by retrying 09:15
at the very least it'd be nice to find out why it's doing that 09:17
09:19 sp1983 left 09:23 sp1983 joined
sp1983 btw, if this exception is "catchable" ? 09:24
I've never tried that
"or if it should internally be handled by retrying" - I'd probable love that 09:25
timo it is catchable, yeah 09:27
sp1983 then catch and retry could be a last resort 09:39
I will ask the user to check my patch tonight , we are in different time zones 09:40
timo i can think of reasons why retrying may not be the desired default, or at the very least to make it possible to not get retries 09:41
09:42 sp1983 left 09:51 sp1983 joined 10:22 sp1983 left 14:02 apogee_ntv joined 14:50 sp1983 joined
sp1983 .tell timo: still erroring after the patch - gist.github.com/melezhik/dee19e565...155de9ecea 14:53
tellable6 sp1983, I'll pass your message to timo
sp1983 the same error
asked them to run sparkyd not in tmux 14:54
dies here - github.com/melezhik/Sparrow6/blob/...akumod#L58 14:56
timo huh, that's odd. I would have expected it to give that error when it reaches .flush 14:58
could it be somewhere else is also removing output buffering?
sp1983 🤷 15:00
I am going to add try / catch
I know this is not the best option , however ... 15:03
btw running not in tmux did not help
github.com/melezhik/Sparrow6/commi...2107b7e878
timo do be advised that right after being told that you can't write to stdout at this moment, it may not work to print the error message either 15:06
might be a good choice to try to print it on $*ERR instead? 15:07
sp1983 yeah, agree ) 15:08
just use warn, right ?
we have an interesting bug here )) 15:09
Geth setup-raku: 434772cb0b | (Shoichi Kaji)++ | 4 files
Remove unused lib test sources
15:11
timo warn is a bit more "special" than just "print to stderr", as it uses the exception mechanism - you can catch warnings 15:18
sp1983 I see 15:20
15:30 sp1983 left
disbot2 <melezhik.> Ok. Try/Catch helped 15:40
[Coke] I believe "note" is "just print to stderr" 16:09
16:13 sp1983 joined 16:14 sp1983 left 16:18 sp1983 joined
sp1983 rpm build for raku openssl fails with - resources/libraries.json: No such file or directory, I assume this should be generated during Build.rakumod execution ? 16:20
rpa.st/LWDXE
here is RPM spec - rpa.st/DF6ZI 16:21
16:24 finanalyst joined
lizmat say is on $*OUT, note === say on $*ERR 16:29
16:38 sp1983 left
disbot2 <melezhik.> timo: what’s your thoughts on further debugging ? From my pragmatical point of view the issue is “fixed” )) 17:00
timo I would still be interested in finding out why it happens so we can figure out if a change in rakudo or moarvm is necessary to prevent issues for users in the future 17:05
we still only have the one user who can reproduce the "temporarily unavailable" issue, and it's still not a reliable reproduction? 17:06
can that user install strace and run it like so `strace -ff -o trace_of_everything.txt -e trace=%file -e trace=%desc the-command-that runs-rakudo with-the-thing` 17:14
this will give a bunch of files - one per PID - only a few of which will actually be interesting, primarily the one where the attempt to write to stdout fails, and its parent (if there is a parent) 17:15
AFKBBL
18:04 finanalyst left 18:41 finanalyst joined 21:06 finanalyst left