00:11:07  * qardquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:18:41  * qardjoined
01:00:04  * joocain2quit (*.net *.split)
01:14:15  * qardquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:23:33  * AtumTquit (Remote host closed the connection)
01:55:15  * dagobert__quit (*.net *.split)
01:55:15  * Matthew[m]quit (*.net *.split)
01:55:17  * williamkapkequit (*.net *.split)
01:55:17  * terinjokesquit (*.net *.split)
01:55:59  * williamkapkejoined
01:56:19  * dagobert__joined
01:56:47  * Matthew[m]joined
01:56:58  * terinjokesjoined
02:01:59  * listenmorequit (Remote host closed the connection)
02:02:25  * listenmorejoined
02:11:31  * joocain2joined
02:30:36  * joocain2quit (Ping timeout: 276 seconds)
02:31:04  * joocain2joined
02:35:48  * joocain2quit (Remote host closed the connection)
02:46:09  * joocain2joined
02:46:33  * joocain2quit (*.net *.split)
02:47:02  * joocain2joined
03:04:51  * rjequit (Ping timeout: 240 seconds)
03:30:04  * joocain2quit (*.net *.split)
03:30:05  * ohnxquit (*.net *.split)
03:30:05  * ugexequit (*.net *.split)
03:30:05  * Jacob843quit (*.net *.split)
03:30:06  * williamkapkequit (*.net *.split)
03:30:07  * listenmorequit (*.net *.split)
03:30:07  * terinjokesquit (*.net *.split)
03:30:07  * dagobert__quit (*.net *.split)
03:30:07  * steshawquit (*.net *.split)
03:30:07  * txdvquit (*.net *.split)
03:30:08  * erikjquit (*.net *.split)
03:30:09  * iarnaquit (*.net *.split)
03:30:10  * zkatquit (*.net *.split)
03:30:10  * trevnorrisquit (*.net *.split)
03:30:12  * refackquit (*.net *.split)
03:30:12  * dbeveniusquit (*.net *.split)
03:30:12  * lennartclquit (*.net *.split)
03:30:12  * niskaquit (*.net *.split)
03:31:01  * brett19joined
03:31:05  * orangemochajoined
03:31:13  * othiym23joined
03:31:22  * joaocgreisjoined
03:31:34  * MLM_joined
05:05:18  * rjejoined
05:05:46  * joocain2quit (Remote host closed the connection)
05:06:05  * joocain2joined
06:06:37  * stephenbelangerjoined
06:08:01  * stephenbelangerquit (Client Quit)
06:08:18  * qardjoined
06:30:16  * joocain2quit (Ping timeout: 255 seconds)
06:31:04  * joocain2joined
06:47:20  * qardquit (Quit: qard)
06:53:33  * qardjoined
07:38:11  * qardquit (Quit: qard)
09:04:38  * joocain2quit (Remote host closed the connection)
09:05:11  * joocain2joined
09:27:44  * joocain2quit (Remote host closed the connection)
09:27:58  * joocain2joined
09:44:42  * AtumTjoined
10:40:28  * AtumTquit (Read error: Connection reset by peer)
10:54:40  * AtumTjoined
11:25:28  * mylesborinsquit (Quit: farewell for now)
11:25:59  * mylesborinsjoined
12:56:16  * joocain2_joined
12:56:25  * joocain2quit (Remote host closed the connection)
13:22:34  <sgimeno>anyone knows why UV_READABLE_PIPE and UV_WRITABLE_PIPE uv_stdio_flags aren't really handled on unix?
13:53:34  * joocain2_quit (Remote host closed the connection)
13:54:01  * joocain2joined
14:40:08  * benjamingr_joined
16:23:51  * vtjnashjoined
16:28:41  <sgimeno>vtjnash, hi
16:28:51  <sgimeno>thanks for the comment
16:29:00  <vtjnash>Hi. Figured I should try to hop on here too :)
16:29:06  <vtjnash>You're welcome
16:29:12  <sgimeno>I had already tried something similar to your patch but broke the tests badly
16:29:23  <sgimeno>it seems the writable argument is important
16:29:37  <sgimeno>stdio[0] must always be writable
16:29:48  <sgimeno>and the others readable
16:30:02  <sgimeno>(at least that's what some tests expect)
16:30:13  <vtjnash>That's true, but shouldn't the client be responsible for that?
16:31:20  <sgimeno>I *think* so, but we should probably ask Ben :)
16:31:25  <vtjnash>Seems like it might be tricky though to change, since libuv has always been ignoring this flag on unix
16:31:53  <sgimeno>what about keeping the ipc check
16:32:34  <vtjnash>(And partially ignoring it on Windows – have a different PR against libuv-master that changes that)
16:33:01  <vtjnash>Sure, the ipc check makes sense. It could even update the flags for stdin/stdout/stderr to "make sense"
16:33:30  <sgimeno>let me see what node does...
16:33:58  <vtjnash>The failing test looked like it cared about stdio[4], so I wasn't sure what libuv was expecting it to do (seems to expect it has opened a bidir pipe)
16:34:36  <vtjnash>So I was simply extrapolating from there to assume it might be setting CREATE|READ|WRITE|IPC already
16:34:47  <sgimeno>not really
16:35:03  <sgimeno>if it's 'pipe' is: CREATE|READ|WRITE
16:35:16  <sgimeno>if it's 'ipc' is CREATE|READ|WRITE|IPC
16:35:47  <vtjnash>So checking `IPC` and checking `READ|WRITE` should give the same result?
16:36:20  <sgimeno>wrt READABLE and WRITABLE I think so
16:36:29  <vtjnash>k
16:36:58  <vtjnash>Alternatively, libuv could also just unconditionally set the flags to `READ|WRITE`
16:38:08  <sgimeno>yes, after making the socketpair we already have a duplex channel
16:38:47  <sgimeno>still windows and unix have different semantics wrt the PIPE flags
16:38:48  <vtjnash>Right. In the Julia project, we avoid using CREATE and just create and pass the pipe handle explicitly in order to control this
16:39:05  <vtjnash>Would be easy to make Windows always open a duplex pipe too
16:39:12  <vtjnash>(although also would be a breaking change)
16:39:25  <sgimeno>whatever, we should be consistent
16:40:38  <vtjnash>Yeah, that should help make testing easier too
16:40:52  <sgimeno>To avoid a breaking change I think the way forward should be unix to be more like windows
16:41:00  <sgimeno>so, handling the flags
16:41:05  <vtjnash>To be self-serving, that's part of my goal for https://github.com/libuv/libuv/pull/1498 :)
16:41:44  <sgimeno>yes, I was looking into that earlier as I remembered it was touching some of this code
16:42:33  <sgimeno>this https://pastebin.com/Xb4vQzy2
16:42:52  <sgimeno>vtjnash, that patch works for me
16:43:42  <vtjnash>It doesn't specifically address this (e.g. I'm still always using uv_socketpair), but it does provide `uv_pipe` as a separately tested API. I think that would make it easier to just add a conditional in the CREATE logic
16:43:57  <sgimeno>passes the tests both in libuv and nodejs (with the nodejs patch for the read stream fix)
16:44:21  <vtjnash>Seems like the `if (writable) branch should have similar logic?
16:45:39  <vtjnash>maybe like https://pastebin.com/KWukTAy5?
16:46:34  <sgimeno>probably, tbh I'd like to understand why it is like it is now
16:46:41  <sgimeno>I'm going to check your version
16:47:14  <sgimeno>still, removing the ipc if is ok?
16:47:16  <vtjnash>It's the same, just adding the `readable` flag to the `writable` branch
16:47:37  <vtjnash>Ah, right, I forgot to put that back
16:47:39  <sgimeno>could someone use CREATE|PIPE?
16:48:12  <vtjnash>Not sure what it would be supposed to do, but probably
16:50:01  <sgimeno>libuv tests pass
16:51:36  <sgimeno>with this patch: https://pastebin.com/AgAvyunA (I've added the ipc check to your patch)
16:55:15  <sgimeno>and nodejs tests also pass (except for one I don't really understand)
16:59:37  <sgimeno>vtjnash, would you open a PR and see what others think?
17:01:06  <sgimeno>or I can do it myself what you prefer
17:08:08  <vtjnash>Sorry, I think I got this backwards in my head
17:08:20  <vtjnash>A READ pipe should have the `write` flag set
17:08:40  <vtjnash>and vice versa
17:09:09  <sgimeno>oh yeat, it's from the child process POV
17:09:18  <vtjnash>right
17:09:46  <sgimeno>I'll update the patch
17:10:00  <vtjnash>Maybe the simple version will work now?
17:10:34  <sgimeno>good idea
17:11:25  <sgimeno>keeping the ipc check, right?
17:11:49  <vtjnash>I think drop that too – That should make it most nearly identical to the Windows code
17:14:53  <sgimeno>still fails
17:15:00  <sgimeno>to be sure we're in the same page
17:15:28  <sgimeno>https://pastebin.com/H37rU5UE
17:16:47  <sgimeno>oh my bad
17:16:48  <sgimeno>typo
17:17:00  <vtjnash>ah, yep, I see it now
17:17:47  <vtjnash>It's too bad that we have some many similarly named constants, but doesn't seem like there's anything that could have been done about it :/
17:18:19  <sgimeno>haha yeah
17:19:15  <sgimeno>tests pass
17:19:25  <sgimeno>with the simpler patch
17:19:27  <sgimeno>:D
17:19:48  <sgimeno>what if somene just CREATE and IPC?
17:21:41  <sgimeno>checking how it goes with nodejs, I guess fine because they CREATE READ WRITE IPC
17:31:16  <vtjnash>yeah, if they ask to create a pipe without read or write permissions, too bad, you get what you asked for
17:31:30  <vtjnash>That's what you get on windows anyways
17:32:42  <sgimeno>makes sense to me
17:32:45  <vtjnash>Also, while I have you, do you know what's the status of the branch merge for updating `master`?
17:32:50  <sgimeno>please open a PR :D
17:33:25  <sgimeno>I'm waiting on Ben to weight in. I added a couple of commits to fix the windows issues
17:33:47  <sgimeno>I think with those commits should be ready to go
17:34:05  <vtjnash>There's the one that's open now, so I was assuming that would merge first, then a new one would be needed to update again?
17:34:53  <sgimeno>I'm referring to the one opened yes. Sure, unless someone opens a new one with latest libuv I guess
17:35:15  <sgimeno>latest v1.x
17:35:41  <vtjnash>yes
17:38:45  <vtjnash>Can I ask you about updates on my others PRs too? I see you approved "thread: support for affinity and detach", is there anything else I need to do?
17:39:37  <sgimeno>I don't think so. But I was waiting for Ben's approval as he had already reviewed it
17:39:49  <vtjnash>OK
17:42:33  <sgimeno>I know you have the uv_pipe one, but I'll need time for that. It wasn't easy for me the first pass :/
17:43:17  <vtjnash>That one is now at least easier for me to carry as a patch
17:43:49  <vtjnash>The other difficult one was "handle writes larger than 2GB"
17:44:32  <vtjnash>It seemed like some of the buildbots don't support the conditions required to test that one
17:45:51  <sgimeno>mmm, I remember that, let me see
17:49:19  <sgimeno>It seems there are some comments to be addressed?
17:50:13  <vtjnash>some style concerns – the more pressing issue was that it can't be tested
17:52:13  <sgimeno>are all of the because of timeouts?
17:52:35  <vtjnash>The timeout is long enough it passes even on old, slow, virtualized machines
17:53:00  <vtjnash>The failures are due to being unable to create a 2GB allocation
17:53:28  <vtjnash>So I wasn't sure if I should just give up and instead just document that libuv can't do this
17:54:00  <vtjnash>Or only test on 64-bit machines + with writev amplification
17:54:59  <sgimeno>If it's a buildbot issue we could skip the tests on those
17:55:14  <sgimeno>I'm going to run the branch again to see the errors
17:55:55  <vtjnash>Are the logs really completely gone? Seems like a short window to see them vs. the effort of rerunning them
17:56:35  <sgimeno>yes, it's a node build group policy issue, they run the jobs more frequently so they need to cleanup fast I think
17:56:54  <sgimeno>https://ci.nodejs.org/view/libuv/job/libuv-test-commit/677/
17:56:57  <vtjnash>Are log files really that big?
17:57:16  <sgimeno>I don't know /
17:57:46  <sgimeno>but there are LOTS of bots
18:01:58  <sgimeno>vtjnash, is this the problem? https://ci.nodejs.org/job/libuv-test-commit-linux/713/nodes=debian8-64/console
18:03:30  <vtjnash>Actually, that one I haven't been able to quite figure out
18:04:14  <vtjnash>The ones that fail to allocate the memory just segfault
18:07:53  <sgimeno>do you remember on which build bots?
18:08:09  <vtjnash>no idea
18:08:34  <sgimeno>3 I've looked , all fail with the ping pong test
18:10:05  <vtjnash>Yeah, without the old logs, it's hard to work on this
18:10:20  <sgimeno>freebsd seems to just timeout
18:12:00  <sgimeno>the results don't seem that bad
18:12:21  <sgimeno>it seems it's either the timeout or the nread == UV_EOF assertions
18:13:20  <vtjnash>hm, interesting, it seems unusual to see all 3 timeout
18:14:44  <vtjnash>Perhaps it would be better to not run this test at all on 32-bit? I'm doing some crazy shenanigans to try to make that work
18:16:34  <sgimeno>I *think* that could work
18:17:22  <vtjnash>Allocating 2 GB is UB in the C standard / compilers anyways
19:09:31  * benjamingr_quit (Quit: Connection closed for inactivity)
19:16:26  * qardjoined
19:21:12  * qardquit (Ping timeout: 276 seconds)
19:43:59  * qardjoined
19:44:48  * qard_joined
21:55:16  * qard_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:36:15  * qard_joined
23:11:02  * vtjnashquit (Remote host closed the connection)
23:15:07  * qardquit (Quit: qard)
23:31:40  * AtumT_joined
23:34:57  * AtumTquit (Ping timeout: 248 seconds)
23:58:18  * listenmorequit (Ping timeout: 256 seconds)