🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
Geth | nqp/main: 68eb3a1909 | (Timo Paulssen)++ | tools/templates/MOAR_REVISION Bump MoarVM to get GC bugfix related to special unwinds |
01:31 | |
rakudo/main: 8d8f7316ae | (Timo Paulssen)++ | tools/templates/NQP_REVISION Bump NQP to get MoarVM GC bugfix for special unwinds |
01:33 | ||
rakudo/main: 293fa5bcd9 | (Timo Paulssen)++ | tools/templates/NQP_REVISION Remove merge-related oopsie from NQP_REVISION |
01:38 | ||
nqp/zhuomingliang/cleanup: 23da905873 | (Jimmy Zhuo)++ | 2 files Some code cleanup and re-order Reduces blib\Raku\Grammar.moarvm about 65KB size |
02:50 | ||
08:20
vrurg left,
vrurg joined
|
|||
Geth | nqp/zhuomingliang/cleanup: 71118c38d5 | (Jimmy Zhuo)++ | 2 files Cleanup and re-order some code Reduces blib\Raku\Grammar.moarvm about 65KB size |
11:18 | |
nqp/zhuomingliang/cleanup: 1339dab40d | (Jimmy Zhuo)++ | 2 files Cleanup and re-order some code Reduces blib\Raku\Grammar.moarvm about 95KB size |
11:49 | ||
rakudo/main: dc8db4f0c5 | (Will Coleda)++ | docs/release_guide.pod Track next release |
11:51 | ||
14:36
japhb left
14:48
japhb joined
|
|||
leont | Seems I'm suffering from a regression in a piece of code of mine doing «$*IN.Supply(:1size).lines», it now blocks when it previously didn't. It's probably MoarVM#1832 related @timo | 19:48 | |
linkable6 | MOARVM#1832 [open]: github.com/MoarVM/MoarVM/pull/1832 Add MVM_string_decodestream_get_up_to_chars | ||
leont | No wait I misreadt that it hasn't been merged, then I guess I should reopen #5189, though I don't know what did change to break it. | 19:49 | |
patrickb | Since which release do you see it not working anymore? | 19:51 | |
leont | I'm currently on v2025.04, but I hadn't looked at that code in at least a year so I don't really know when it broke. | 19:52 | |
ugexe | rakubrew download moar 2025.03 && rakubrew download moar 2025.02 && ... | 19:58 | |
rakubrew exec --with 2025.03 raku -e '...' | |||
leont | No, my analysis is totally wrong, it does actually work in my minimal case. Sorry for the confusion, though I haven't figured the rest of the story yet. Moment. | 19:59 | |
The program I'm working with is this one: github.com/Leont/protocol-postgres...les/simple | 20:03 | ||
I thought the supply was the problem because if the problem disappears if I revert github.com/Leont/protocol-postgres...edc1c66856 | 20:04 | ||
But the issue also disappears if I remove the «whenever $client.disconnected» below. | |||
I'm very confused now | 20:05 | ||
timo | is there something that shuts the react block down when the supply closes but the disconnected signal doesn't fire? | 20:28 | |
i assume the terminate makes sure that happens? | 20:29 | ||
leont | Terminate would cause the server to disconnect, which should trigger disconnect promise | 20:33 | |
But the problem is that I'm not even getting my input right now, and that is weird. | 20:34 | ||
ugexe | i think in your original code you spawned a new thread to do the reading of the supply. in the new code that doesn't happen so that thread tries to read from stdin and thus doesn't reach the next whenever blocks | 20:39 | |
timo | ah, IO::Handle.Supply doesn't work asynchronously, and doesn't make a thread either, but the socket used for the postgres protocol is an async socket so i'm not sure where the entire thing would block? | 20:44 | |
ah | |||
ok, i think the supply block that the IO::Handle (and CatHandle) use don't do anything like "whenever", they just loop while the handle has something and yield results, but the react block from the code can't "start up" until the supply block finished its "setup" | 20:46 | ||
Geth | whateverable/main: b8d353f6c3 | (Will Coleda)++ | config-default.json Releasable commit links to ....git are broken We can clone with or without the trailing .git but this should fix the links in relesable updates |
20:47 | |
[Coke] | ^^ Please keep an eye on the bots - this should be OK (and will fix a releasable issue) but I have no easy way to test. | ||
leont | This used to work, so that does beg the question how it broke? | 20:51 | |
But a Supply that doesn't whenever sounds pretty broken to me | 20:52 | ||
20:52
bisectable6 left,
bloatable6 left,
linkable6 left,
benchable6 left,
greppable6 left,
committable6 left,
releasable6 left,
nativecallable6 left,
unicodable6 left,
quotable6 left,
evalable6 left,
notable6 left,
shareable6 left,
tellable6 left,
coverable6 left,
sourceable6 left
|
|||
timo | not necessarily | 20:53 | |
what is (1,2,3,4).Supply supposed to "whenever", for example? | |||
leont | I mean, I'm fine with that immediately emitting and then ending, I don't see the problem there. | 20:54 | |
timo | the issue with $*IN.Supply is that we don't have asynchronous IO for file handles, only for sockets | ||
20:55
greppable6 joined,
shareable6 joined
|
|||
timo | libuv doesn't have it either, it looks like | 20:55 | |
leont | I'm pretty sure it does | ||
20:55
nativecallable6 joined,
bloatable6 joined,
linkable6 joined
|
|||
ugexe | libuv async IO is regular IO on a thread pool | 20:55 | |
20:55
committable6 joined
|
|||
ugexe | file IO rather | 20:55 | |
timo | correct | 20:56 | |
20:56
releasable6 joined,
evalable6 joined
|
|||
timo | it does have the possibility to put a file handle in as a "poll handle" which is kind of like using select() | 20:56 | |
20:56
benchable6 joined,
bisectable6 joined
|
|||
ugexe | you emulated that behavior in the code from your revert because it spawns a new thread to read from $*IN | 20:56 | |
20:56
tellable6 joined,
quotable6 joined,
unicodable6 joined
20:57
notable6 joined
|
|||
leont | AFAIK libuv doesn't use threads by default, though it has a number of backends and some might do such a thing | 20:57 | |
20:57
coverable6 joined,
sourceable6 joined
|
|||
timo | "All file operations are run on the threadpool. See Thread pool work scheduling for information on the threadpool size." | 20:57 | |
ant.readthedocs.io/en/latest/fs.html but that's not for reading/writing, that's for filesystem stuff | 20:58 | ||
leont | Yeah, asynchronous file system stuff is extremely non-portable | ||
timo | libuv has stream handles for TCP, TTY, and Pipes, but nothing for regular files | 21:00 | |
async IO for $*IN really only makes sense for TTYs though, right? | |||
leont | uv_tty_init would let you open stdin exactly like I want. It's just not implemented on the MoarVM side. | ||
timo | which is why i thought i could re-use the async pieces of sock stream handles and just check that the in handle is a tty one, but it didn't work | 21:01 | |
leont | Well it would also make sense if it's a pipe. And it's fine to emulate something if it's a file probably. | ||
[Coke] | reminder, changelog for 2025.05 started; github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 21:06 |