01:14:48  * SkyRocknRollquit (Ping timeout: 240 seconds)
01:17:23  * SkyRocknRolljoined
04:22:55  * SkyRocknRollquit (Remote host closed the connection)
04:53:11  * SkyRocknRolljoined
06:36:28  * rendarjoined
07:27:57  * Soniquit (Ping timeout: 260 seconds)
07:29:49  * Sonijoined
14:15:55  * SkyRocknRollquit (Read error: Connection reset by peer)
16:00:42  <rphillips>squeek502_: responded to that github issue again
16:02:51  <squeek502_>rphillips, ive tested with spawning 3 different ways: coro-spawn, plain luv, and plain libuv, all 3 exhibit the same inconsistent reads when spawning luvit as a child process
16:04:44  <rphillips>so I had to implement a drain in the rackspace agent
16:05:24  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/master/check/base.lua#L476
16:05:36  <rphillips>it reads all of stdio/stderr, and waits for the exit
16:05:49  <rphillips>because the exit can come before everything is read
16:06:28  <creationix>I've seen exit come before EOF on the two streams all the time, but I thought the coro stuff worked around that by waiting for all three events before exiting (shild exit, stderr end, stdout end)
16:06:54  <rphillips>does the coro stuff do that?
16:08:06  <rphillips>the underlying libuv process handle shouldn't be closed until everything is read
16:08:20  <rphillips>if it is, then it'll truncate the output
16:09:18  <creationix>I'm talking about this https://github.com/luvit/lit/blob/master/libs/exec.lua#L36-L50
16:09:34  <creationix>if you only wait for the exit event, you can miss stream events
16:09:54  <creationix>is it closing the libuv handle early somewhere internally?
16:10:10  <squeek502_>im not sure
16:10:40  <creationix>wait exit doesn't do anything to the handle https://github.com/luvit/lit/blob/master/deps/coro-spawn.lua#L63-L70
16:11:32  <creationix>I don't see coro-spawn ever touch the `handle`
16:11:55  <creationix>maybe coro-channel?
16:12:38  <squeek502_>well, ive mostly been testing with the code in this comment, which just uses luv directly: https://github.com/luvit/lit/issues/222#issuecomment-327079520
16:13:36  <squeek502_>and i get the same inconsistent output from the child process
16:14:03  <squeek502_>it doesnt touch the handle, just prints in the various callbacks
16:15:07  <squeek502_>i dont have much evidence to suggest that its a bug within the lit libs
16:15:13  * creationixlooks closer at the gist
16:15:14  <rphillips>testing it out
16:16:30  <rphillips>hmm. works on linux
16:16:58  <squeek502_>ah yeah ive been meaning to check that
16:17:19  <squeek502_>'works' meaning what in this case?
16:17:47  <rphillips>https://gist.github.com/rphillips/72ac30c72339d373a0e829e4b0d83822
16:17:55  <rphillips>consistently prints the gist ^
16:18:07  <squeek502_>very strange...
16:18:54  <creationix>so, it writes to stderr, then starts the cleanup routine which closes all handles. We should probably wait will the write call finishes before closing the handles
16:19:34  <creationix>which is tricky because that's not a coroutine I believe
16:19:48  <squeek502_>yeah but its still weird because its still specific to spawning a child process
16:19:58  <squeek502_>the stderr works fine on windows when just doing luvit plain.lua
16:20:21  <creationix>sure, some race conditions only happen in certain situations
16:20:53  <creationix>also child processes have pipes while normal processes tend to have TTYs
16:20:59  <squeek502_>true
16:21:10  <creationix>I believe libuv makes stderr sync sometimes for this very reason (truncating error messages on exit)
16:21:15  <creationix>it was a big problem in the early node days
16:25:00  <creationix>Something like this maybe:
16:25:12  <creationix>https://www.irccloud.com/pastebin/RvAAItBE/
16:26:04  <creationix>we don't want to keep the event loop open longer than needed. A plain `uv.run()` may run forever. Just loop long enough to know the callback is done.
16:26:35  <squeek502_>yeah makes sense
16:26:57  <creationix>that code is untested and I havn't been writing lua in a couple months, so beware
16:27:06  <creationix>but I think it should work in theory
16:28:56  <creationix>actually, we should probably always flush stderr on exit. does that sound safe?
16:30:04  <rphillips>whichever file handles are setup should probably be flushed
16:31:24  <creationix>so try to flush everything that's a stream?
16:31:39  <creationix>only problem is, if there is an active writer, the event loop will never close
16:31:53  <creationix>unless starting the flush prevent new writes from starting
16:32:50  <creationix>I wonder if libuv prevents `uv_write` calls after `uv_shutdown` on a stream
16:33:04  <creationix>if it does, that's a great idea
16:34:12  <creationix>what does shutdown map to in luv? it's not `end` like in node I remember
16:34:49  <creationix>hmm, it's `shutdown`. I was clever with that one ;)
16:36:29  <squeek502_>made some minor fixes to your code and it seems to work: https://hastebin.com/zejiwulofe.lua
16:38:07  <creationix>try this one too, it replaces the existing walk loop:
16:38:14  <creationix>https://www.irccloud.com/pastebin/8WsiKKa3/
16:40:03  <creationix>passes all tests locally
16:40:33  <squeek502_>yeah that works too, commented out the previous flush
16:40:51  <creationix>sweet, I think the second one is better since it flushes any streams
16:50:36  <creationix>rphillips: rfr https://github.com/luvit/luvit/pull/1007
16:56:27  * SkyRocknRolljoined
17:08:19  <squeek502_>creationix, here's a PR to fix the appveyor.yml: https://github.com/luvit/luvit/pull/1008
17:08:53  <creationix>thanks
17:09:02  <creationix>I guess they got stricter about what's allowed
18:06:11  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
18:37:57  * SkyRocknRollquit (Remote host closed the connection)
18:39:09  * SkyRocknRolljoined
19:59:21  * Andolsjoined
20:46:10  * SkyRocknRollquit (Remote host closed the connection)
21:45:59  * DarkGodjoined
22:26:53  * Andolsquit
22:30:32  * Fuslquit (Excess Flood)
22:33:52  * Fusljoined
23:17:42  * DarkGodquit (Quit: Leaving)
23:27:38  * travis-cijoined
23:27:39  <travis-ci>luvit/luvit#2992 (flush-streams-on-exit - c7d2a32 : Tim Caswell): The build has errored.
23:27:39  <travis-ci>Change view : https://github.com/luvit/luvit/commit/c7d2a32f3514
23:27:39  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/272568431
23:27:39  * travis-cipart
23:38:15  * travis-cijoined
23:38:16  <travis-ci>luvit/luvit#2995 (flush-streams-on-exit - 84218f2 : Tim Caswell): The build has errored.
23:38:16  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c7d2a32f3514...84218f2c4142
23:38:16  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/272568859
23:38:16  * travis-cipart