MasterDuke timo: i just copied the code from the existing switch. the _u cases cast to `MVMint64` since they were introduced by jnthn in github.com/MoarVM/MoarVM/commit/6c...169bd5d0f1 and modified by nine in github.com/MoarVM/MoarVM/commit/44...bba837bbdd 02:06
but maybe now they should cast to `MVMuint64`
patrickb That issue has been a looong time coming. I don't see it happening any time soon. 11:41
The only two options I see:Just do it all by myself. I guess I can live with dealing with a lot less edge-cases than libuv can. 11:42
Or: Create a libuv patch and PR. The patch we'll apply to our libuv copy and guard in moar against that patch not being there. Then a moar built with system libuv just won't have PTY support. 11:43
Given how long libuv PTY support has not been happening (and node js working round it, just like I'm doing it now) I don't think that PR will be merged quickly. So we'd have to live with the patched version for a while. Also I don't know if I can manage to lift such a PR to a level where it'd be suitable for upstream libuv. 11:46
But from all I see it'd be a lot less work to do it from inside libuv compared to hacking around it from the outside. (On posix I have it already working, but the code is a hack on the uglier end of the spectrum.) 11:48
lizmat are you saying libuv dev has stalled, or just in this particular case ? 12:14
patrickb The libuv devs don't have active plans to implement PTY support. not a prio. 13:56
The real question is, are we willing to maintain a patch set for a while and accept that a moar with external libuv will not provide PTY support? 13:58
"a while" is possibly a long time.
lizmat would that affect PTY support on Windows only, or in general ?
afk& 14:12
patrickb If I go for the libuv patch solution it'd affect everyone. 14:24
ugexe i don't like the idea of acting different based on if we're using a fork of libuv or not 15:46
it is probably easier for users to reason about PTY support not working because they are on windows than based on what variant of moarvm they happen to be using for their rakudo 15:50
i do wonder if the lack of support in libuv is because it isnt a priority or if it is because the overall dev velocity has gone down in general as people move on with their lives, get different jobs, etc (this is just a gut feeling though) 15:52
however i do recognize there is a higher than usual chance for it to get stalled based on their feedback / expectations 15:53
patrickb I can try get a PR up and pushing it through, but I'd hate to be blocked on it with my moar PTY work. 16:06
That's why I'm considering maintaining a patch.
My personal minimum acceptable level of support for PTY in moar is, Linux, MacOS, OpenBSD and Windows. 16:08
I wouldn't want to go live without Windows support.
Another reason, why PTY is low prio in libuv: The primary user, node, has an independent solution and this doesn't depend on a libuv impl. 16:13
timo: Do you happen to know off hand if the Debian moar package uses an external libuv? 16:14
ugexe why can't we copy what node does? 16:17
fwiw i interpret github.com/nodejs/node/issues/46105 as no one had the know-how or tuits to do it, and not that they wouldnt actually want to use it 16:20
patrickb That's my current approach, copying the node-pty lib. 16:28
It's just that doing so is such a huge yak shaving, that I get scared. 16:29
E.g. tracking if a process on Windows finished requires a separate thread constantly monitoring the process. That thread would, once it needs to signal, need to synchronize with the libuv loop thread. 16:31
The "simple" job of starting a process on Windows is also multiple hundred lines of code in libuv only to get the format of the enc card and process args into the right format. Then there is loads of code to get permissions and process groups right. 16:32
The node-js code is a bit slimmer, but still has loads of corner case code and also needs to have that separate process watcher thread. 16:33
I'd say I'm 2/3 done with having a first working version with doing it manually in moarvm on Windows (posix is already working). But that's without arg and env setup and without the watcher thread. 16:35
timo patrickb: salsa.debian.org/perl6-team/moarvm...=heads#L46 20:17
tellable6 2025-02-21T14:46:26Z #raku <tbrowder> timo i updated doc PR
patrickb Ok. So the Debian build would lose PTY support until it'd go upstream... 20:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!