00:04:49  * kazuponjoined
00:11:44  * kazuponquit (Remote host closed the connection)
01:20:07  * kazuponjoined
01:41:33  * kazuponquit (Remote host closed the connection)
01:51:54  * kazuponjoined
03:12:31  * a_lequit (Remote host closed the connection)
03:50:00  * a_lejoined
03:50:19  * kazuponquit (Remote host closed the connection)
04:20:53  * kazuponjoined
04:25:37  * kazuponquit (Ping timeout: 245 seconds)
04:37:14  * kazuponjoined
04:58:41  * a_lequit (Remote host closed the connection)
06:51:35  * kazupon_joined
06:54:42  * kazuponquit (Ping timeout: 250 seconds)
07:14:39  * DarkGodjoined
07:17:25  * kazupon_quit (Remote host closed the connection)
07:26:53  * kazuponjoined
07:46:58  * kazuponquit (Remote host closed the connection)
07:47:24  * kazuponjoined
10:29:11  * kazuponquit (Remote host closed the connection)
10:31:30  * kazuponjoined
10:54:36  * kazuponquit (Remote host closed the connection)
11:06:47  * ra^quit (Remote host closed the connection)
11:08:10  * ra^joined
11:42:23  <ra^>Hello
11:42:28  <ra^>i was wondering, why isn't ECONNRESET don't also trigger a self:destroy() there https://github.com/luvit/luvit/blob/master/lib/luvit/net.lua#L174
11:43:29  <ra^>Just by using browser and pressing control + r, i can trigger this
11:43:32  <ra^> "Assertion failed: (!uv__io_active(&stream->io_watcher, UV__POLLIN) && "stream->read_cb(status=-1) did not call uv_c\
11:43:32  <ra^> lose()"), function uv__read, file src/unix/stream.c, line 1009.
11:55:58  <ra^>s/don't also trigger/also triggering/
12:05:25  * kazuponjoined
12:09:33  * kazuponquit (Ping timeout: 246 seconds)
12:32:00  * a_lejoined
12:55:14  * typedlambdaquit (Ping timeout: 250 seconds)
12:56:51  * typedlambdajoined
13:32:47  * kazuponjoined
14:17:32  * dan336joined
14:57:38  <rch>ra^: interesting question
15:19:23  * kazuponquit (Remote host closed the connection)
15:19:51  * kazuponjoined
15:24:45  <rphillips>ra^: looks like we could use a PR for that
15:28:39  <rphillips>we should probably destroy the handle on any error
15:33:05  <rphillips>https://github.com/luvit/luvit/pull/508
15:38:49  <rphillips>creationix: updated that pr to emit the error on the nexttick
15:39:09  <creationix>to force it to be async?
15:39:24  <rphillips>right
15:39:38  <creationix>yeah, most people don’t expect zalgo behavior
15:46:35  * travis-cijoined
15:46:35  <travis-ci>[travis-ci] luvit/luvit#934 (fixes/socket_error - bf5ac96 : Ryan Phillips): The build failed.
15:46:35  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/dd52b6b054c4...bf5ac96e64e4
15:46:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/36166000
15:46:35  * travis-cipart
15:47:11  <rphillips>hmm
15:47:20  <rphillips>one of the tls tests failed
15:52:51  <rphillips>fixed it...
15:52:55  <rphillips>travis building
15:53:34  <creationix>this is why I’m writing tests for luv
15:53:47  <creationix>I’m working out GC issues currently. Stress testing is from as many angles as I can think of
15:53:53  <ra^>what does PR stand for ?
15:54:01  <creationix>ra^: Pull Request on github
15:54:27  <creationix>ra^: rphillips did one already, he working out the kinks currently
15:55:05  <rphillips>ra^: should be fixed shortly
15:56:29  <creationix>rphillips: using coroutines in the core of luv is interesting
15:56:48  <creationix>I *think* it’s a better approach.
15:57:01  <creationix>I haven’t needed luv_handles yet
15:57:12  <creationix>just straight libuv structs as lua userdata
15:57:40  <creationix>also I’m just going to ref all uv structs upon creation and not release them till uv_close finishes
15:58:09  <creationix>that means they will leak memory if you never close them, but otherwise there are too many edge cases where they are alive and I didn’t think they were
15:58:30  <creationix>also libuv would leak anyway if you never close them, so what’s wrong with lua-side leaking too?
15:58:55  <ra^>there is one thingh strange about this bug, is EPIPE, don't trigger, an assert, only ECONNRESET did for me
15:59:09  <creationix>ra^: this is with luvit right?
15:59:17  <ra^>yes
15:59:20  <creationix>I wonder if we’re listening to one of those and not the other
15:59:33  <creationix>some signals are ignored in luvit if I remember correctly
16:00:17  <rphillips>we ignore sigpipe
16:00:31  <rphillips>https://github.com/luvit/luvit/blob/fixes/socket_error/src/luvit_init.c#L178
16:00:40  <creationix>that would explain the difference
16:04:25  * travis-cijoined
16:04:26  <travis-ci>[travis-ci] luvit/luvit#935 (fixes/socket_error - 1916537 : Ryan Phillips): The build was fixed.
16:04:26  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/bf5ac96e64e4...1916537caef2
16:04:26  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/36167581
16:04:26  * travis-cipart
16:05:06  <rphillips>merged
16:05:19  <rphillips>creationix: does the playground get automatically updated?
16:05:30  <creationix>rphillips: playground?
16:05:47  <rphillips>ah, I thought we had a web interface for luvit repl
16:05:59  <creationix>try.luvit.io?
16:06:05  <creationix>no, it’s manual, I can update it if you want
16:06:37  <rphillips>oh, not needed... misinterpreted ra^
16:06:40  <rphillips>ra^: fixed
16:07:04  <ra^>well the program was not aborted, because of an unhandled signal but cause of a failled assertion, so i was not sure if i had bad luck with my libuv
16:07:13  <creationix>:) arch linux has an up-to-date version of cmake
16:07:25  <rphillips>arch linux is usually up-to-date on everything :)
16:07:41  <ra^>of if you were compiling it with NDBUG
16:08:24  * creationixgot confused, luvit doesn’t use cmake yet
16:09:13  <creationix>I can’t wait will we have luvi binaries being build for all platforms and flavors
16:16:31  * kazuponquit (Remote host closed the connection)
16:16:31  * travis-cijoined
16:16:31  <travis-ci>[travis-ci] luvit/luvit#937 (master - c7c3d2d : Ryan Phillips): The build passed.
16:16:31  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/73461e436481...c7c3d2df70c4
16:16:31  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/36168883
16:16:31  * travis-cipart
16:23:04  <creationix>rphillips: try.luvit.io is now running 0.10.0-34-gc7c3d2d
16:33:42  * DarkGodquit (Remote host closed the connection)
17:54:33  * DarkGodjoined
18:52:16  * jirwinjoined
18:54:48  * a_lequit (Remote host closed the connection)
18:55:22  * a_lejoined
19:04:15  * not^vjoined
19:31:16  * not^vquit (Read error: Connection reset by peer)
19:31:45  * not^vjoined
20:01:45  * not^vquit (Ping timeout: 272 seconds)
20:09:42  * not^vjoined
21:01:26  <creationix>luv now has bindings for loop, prepare, check, idle, async, poll, timer, poll, and signal uv types
21:01:28  <creationix>http://showterm.io/f502b9ab3b16e655cd9f9
21:01:34  <creationix>rphillips: rch: ^
21:02:00  <rphillips>nice!
21:02:05  <creationix>if you scroll up you can see I’m logging all the active libuv handles in a given event loop along with their registered event handlers and ref state
21:02:20  <creationix>so much visibility will help debugging I think
21:02:37  <creationix>and also using walk I can auto-close all active handles in a loop
21:03:07  <creationix>If I can figure out a way to use multiple loops at once, we could partition apps
21:03:21  <creationix>but since each loop blocks the entire thread, that’s tricky
21:04:41  <creationix>the test file can be seen at https://github.com/luvit/luv/blob/uv-update-1.0.0/test-loop.lua
21:05:42  <rch>cool
21:06:40  <creationix>I’m just going through the new manual page by page implementing all the functions http://docs.libuv.org/en/latest/signal.html
21:06:55  <creationix>next is process spawning, that will be a bit harder than the last few
21:35:42  * not^vquit (Ping timeout: 245 seconds)
22:04:10  * not^vjoined
22:13:20  * DarkGodquit (Remote host closed the connection)
23:00:53  * not^vquit (Ping timeout: 240 seconds)
23:01:52  * dan336quit (Quit: Leaving.)