Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
MasterDuke | a -1 for one of the options means to leave it unchanged. i figured that'd be part of the rakudo implementation. i.e., `method chown(IO::Path:D: Int() $uid = -1, Int() $guid = -1) { nqp::chown(self, $uid, $guid) }` | 00:00 | |
and just as many files would have to change to add an op... | |||
japhb | Yeah, I know (about the files for adding an op) ... I'm just griping about reviewing machine generated diffs, which is a fool's game. | 00:03 | |
MasterDuke | ha | ||
japhb | We could probably do something a little more Raku-ish for the interface than using a C-style magic value, but I'm glad to hear libuv supports the semantics at least. | 00:05 | |
(And certainly that's fine for the NQP interface, because NQP is allowed to be a halfway language.) | |||
00:06
reportable6 left
00:08
reportable6 joined
00:41
evalable6 joined,
tellable6 joined
02:27
archenoth joined
02:28
archenoth left,
archenoth joined
02:30
Oshawott left
03:48
bisectable6 left,
ilogger2 left,
mst left,
MasterDuke left,
nine left,
mst joined,
nine joined,
bisectable6 joined,
ilogger2 joined
06:06
reportable6 left
06:07
reportable6 joined
08:53
sena_kun joined
09:22
sena_kun left
10:01
sena_kun joined
10:20
frost16 joined
|
|||
lizmat | nine: re Well, /dev/tty is only correct if STDIN was connected to the terminal before. If it was a pipe or a file, you'd still be off. The correct way is to dup() the file descriptor before closing it and later dup2() it back to STDIN | 11:33 | |
how would one do that in Raku or nqp ? | |||
11:36
Kaiepi joined
12:09
reportable6 left
12:10
reportable6 joined
14:13
frost16 left
14:25
epony left
|
|||
nine | I don't think MoarVM supports that directly, so it'd have to be NativeCall | 16:41 | |
lizmat | so is the PIO not some libuv construct that you can't just dup ? | 17:20 | |
17:21
sena_kun left
|
|||
lizmat | iow, shouldn't it be supported by libuv? | 17:21 | |
I guess not: github.com/libuv/libuv/issues/3448 | |||
17:30
nine left,
nine joined
17:55
sena_kun joined
18:06
reportable6 left
18:08
reportable6 joined
18:33
sena_kun left
18:35
sena_kun joined
19:59
Kaiepi left,
Kaiepi joined
20:04
Kaiepi left
20:05
Kaiepi joined
20:08
Kaiepi left,
Kaiepi joined
20:40
sena_kun left
20:41
sena_kun joined
20:44
sena_kun left
20:45
sena_kun joined
21:20
sena_kun left
|
|||
jnthn | For synchronous I/O at least, libuv isn't involved | 21:28 | |
21:59
epony joined
23:21
vrurg joined
23:28
ugexe joined
|