00:24:32  * UniOnquit (Remote host closed the connection)
00:27:28  * Hotrootjoined
00:30:26  <Hotroot>So from what I can tell, luvit is not production ready yet, but luv is?
00:31:03  <Hotroot>And luv will do "proper" nonblocking file IO?
00:40:59  <rch>we use luvit in production
00:41:16  <rch>luv io i will let creationix_ answer when he's around
00:46:07  <Hotroot>rch: Hmm. Debating which I should use. Probably just luvit for ease of use. I'm not asking anything too specific about the IO, just that it doesn't block during reads.
00:46:21  <rch>luvit has the same async io api that nodejs has
00:46:51  <Hotroot>With the same internals?
00:47:20  <rch>the libuv glue is written in C and Lua running in luvit but they are both based on libuv (as is luv)
00:48:13  <Hotroot>Alright. And I can't seem to find an API for luvit. Is there one hiding, or does it actually support all of Node's current features?
00:50:19  <rch>the joke with luvit is that you can just read the node documentation.
00:50:54  <rphillips>Hotroot: the master branch is stable
00:51:12  <rphillips>we are in th process of porting to version 2 of luvit
00:51:15  <rphillips>the*
00:52:12  * kazuponjoined
00:52:20  <rphillips>the default display on github is the luvi-up branch, which is a WIP
00:57:45  <Hotroot>I think you guys set a world record for number of branches
01:01:01  <Hotroot>rch: It's not 1-1 yet though, right? I don't see a crypto lib.
01:01:37  <rch>not every module is there no
01:04:08  <Hotroot>I may have to start contributing. My biggest issues with Lua so far have been that everything blocks, and multithreading doesn't seem to exist.
01:05:22  <rch>that would be great!
01:16:59  * kazuponquit (Remote host closed the connection)
01:27:39  * kazuponjoined
01:48:00  <Hotroot>I see that ChildProcess's spawn() is implemented, but can parent and child send messages? In Node, the child does it with process.send(), but I don't see a process.lua
01:52:11  <rch>i bet that message protocol is not implemented
01:53:19  <Hotroot>Anything event based would work. Worst case I'll use UNIX sockets or something
01:53:40  <rch>could use streams over tcp: https://github.com/virgo-agent-toolkit/luvit-stream
01:54:50  <Hotroot>TCP for speaking to a child process seems overkill.
01:55:03  <Hotroot>I just want a pipe or something
01:55:48  <Hotroot>Guess I'll just test and see what works. Would be nice to have a list of what isn't implemented
01:56:41  <rch>yeah or alternately docs for luvit
01:56:51  <rch>i.e. a list of what is implemented (and how to use it)
01:57:08  <rch>testing what works is how i figure this out though
01:57:23  <Hotroot>Yeah
01:59:52  * ^vjoined
02:17:35  <Hotroot>Speaking of docs, the instruction say to ./configure, but there isn't one in the master branch
02:18:34  <Hotroot>Hmm, odd. Nevermind. I thought the git url reflected the branch you were in
02:43:36  <creationix_>Hotroot: luv supports pipes between parents and children and even passing handles between them (for example bind to a tcp port in parent process and listen and accept to that port in x child processes)
02:43:45  <creationix_>luv is the core to luvit 2.0
02:44:39  <creationix_>Hotroot: also, the README in the luvi-up branch of luvit is all wrong except for the notice at the top
02:44:53  <creationix_>it’s the readme for the old code in the master branch
03:06:14  <Hotroot>creationix_: So I need to utilize Luv directly?
03:14:45  * ra^^quit (Read error: Connection reset by peer)
03:20:00  * DarkGodquit (Ping timeout: 255 seconds)
03:24:36  * kazuponquit (Remote host closed the connection)
03:36:22  * ra^^joined
03:48:00  * dan336joined
03:59:33  * not^vjoined
04:01:59  * ^vquit (Ping timeout: 258 seconds)
04:13:36  * kazuponjoined
04:37:01  * kazuponquit (Remote host closed the connection)
04:38:16  * kazuponjoined
05:02:52  <rphillips>if this benchmark is the same, nodejs can create around 16,000 event emitters a second and my luajit test is creating 3 billion event emitters a second
05:07:47  * dan336quit (Quit: Leaving.)
05:13:07  * ^vjoined
05:13:17  * not^vquit (Ping timeout: 258 seconds)
05:14:27  * ^vquit (Client Quit)
06:54:43  <rch>rphillips: that can't be correct
06:54:47  <rch>wow
07:13:09  * jirwinquit (Changing host)
07:13:09  * jirwinjoined
07:15:57  * ra^^quit (Read error: Connection reset by peer)
07:18:05  * ra^^joined
08:11:30  * DarkGodjoined
11:02:34  * Hotrootpart
11:05:15  * kazuponquit (Remote host closed the connection)
11:05:42  * kazuponjoined
11:09:53  * kazuponquit (Ping timeout: 244 seconds)
12:46:33  * kazuponjoined
12:50:41  * kazuponquit (Remote host closed the connection)
13:29:23  * tjcraveyjoined
14:48:37  <rphillips>rch: https://gist.github.com/rphillips/8506bb12e825ac68f6c1
15:17:42  * UniOnjoined
15:25:40  <creationix_>Hotroot: you don’t have to. The new luvit has luv inside it
15:25:41  <creationix_>just require(“uv”)
15:27:34  <creationix_>rphillips: I guess that’s a sweet spot of luajit
15:27:41  <creationix_>16k/sec is really slow
15:38:32  * typedlambdaquit (Ping timeout: 250 seconds)
15:39:47  * typedlambdajoined
15:48:53  <creationix_>node should be able to handle an entire HTTP request parse and send a response in that time
15:55:56  <rphillips>weird
15:56:04  <rphillips>EINVAL: invalid argument on udp_bind
16:01:19  <creationix_>that’s coming from libuv
16:01:25  <creationix_>I wonder which arg it’s complaining about
16:01:39  <rphillips>i think it's complaining about the (struct sockaddr*)&addr cast
16:01:45  <rphillips>in udp_bind
16:02:28  <creationix_>that api always confuses me
16:04:19  <rphillips>i'll patch it
16:28:34  * travis-cijoined
16:28:34  <travis-ci>luvit/luv#165 (fix/udp_bind - 39cdc8f : Ryan Phillips): The build passed.
16:28:34  <travis-ci>Change view : https://github.com/luvit/luv/commit/39cdc8ff06bb
16:28:34  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/41261705
16:28:34  * travis-cipart
16:33:40  * kazuponjoined
16:57:48  <rphillips>https://github.com/luvit/luvit/pull/535
16:57:58  <rphillips>issue was with the recv_start before the bind
17:00:51  <creationix_>I see
17:11:33  * travis-cijoined
17:11:33  <travis-ci>luvit/luv#166 (fix/udp_bind - 2008b00 : Ryan Phillips): The build has errored.
17:11:33  <travis-ci>Change view : https://github.com/luvit/luv/compare/39cdc8ff06bb...2008b004aaf3
17:11:33  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/41265225
17:11:33  * travis-cipart
17:13:30  * travis-cijoined
17:13:30  <travis-ci>luvit/luvit#1178 (udp_test_case - cd5c3d0 : Ryan Phillips): The build has errored.
17:13:30  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fcd0bf728e52...cd5c3d002640
17:13:30  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41266488
17:13:30  * travis-cipart
17:19:44  <rch>rphillips: maybe the work is getting jitted out ?
17:20:11  <rphillips>i was thinking that, but the counter call is ran
17:22:24  <rphillips>tweaked it to be: https://gist.github.com/rphillips/987bfb68618974371a16
17:22:57  <rphillips>7.5 million creates
17:23:55  <rch>aha cool
17:25:03  * travis-cijoined
17:25:03  <travis-ci>luvit/luvit#1178 (udp_test_case - cd5c3d0 : Ryan Phillips): The build passed.
17:25:03  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fcd0bf728e52...cd5c3d002640
17:25:03  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41266488
17:25:03  * travis-cipart
17:31:42  * travis-cijoined
17:31:42  <travis-ci>luvit/luvit#1180 (luvi-up - 5dd0b40 : Ryan Phillips): The build passed.
17:31:42  <travis-ci>Change view : https://github.com/luvit/luvit/compare/52a51590a6ff...5dd0b40b3f0e
17:31:42  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41266738
17:31:42  * travis-cipart
17:39:24  * erlbot--quit (Remote host closed the connection)
17:54:03  * travis-cijoined
17:54:03  <travis-ci>luvit/luvit#1181 (luvi-up - 95d3873 : Ryan Phillips): The build passed.
17:54:03  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5dd0b40b3f0e...95d38730178f
17:54:03  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41269235
17:54:03  * travis-cipart
17:54:52  * travis-cijoined
17:54:52  <travis-ci>luvit/luvit#1182 (add_tcp_test - 2d1cf4d : Ryan Phillips): The build passed.
17:54:52  <travis-ci>Change view : https://github.com/luvit/luvit/commit/2d1cf4d84b23
17:54:52  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41271022
17:54:52  * travis-cipart
18:03:02  <rphillips>https://github.com/luvit/luvit/pull/536
18:06:09  <creationix_>now I remember why I didn’t use miniz’s zip code
18:06:29  <creationix_>for some reason, some of the internal file offsets assume the zip file starts at offset 0
18:06:38  <creationix_>which obviously won’t work with exe + zip combos
18:07:28  <creationix_>I could see if it’s easy to fix
18:08:36  * rjequit (Remote host closed the connection)
18:15:40  * rjejoined
18:16:47  * kazuponquit (Remote host closed the connection)
18:17:15  * travis-cijoined
18:17:15  <travis-ci>luvit/luvit#1184 (add_tcp_test - d9cad32 : Ryan Phillips): The build passed.
18:17:15  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2d1cf4d84b23...d9cad3292ed9
18:17:15  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41273086
18:17:15  * travis-cipart
18:18:12  * kazuponjoined
18:18:29  * travis-cijoined
18:18:30  <travis-ci>luvit/luvit#1186 (luvi-up - 43c18ee : Ryan Phillips): The build passed.
18:18:30  <travis-ci>Change view : https://github.com/luvit/luvit/compare/95d38730178f...43c18eeb7ee9
18:18:30  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41273189
18:18:30  * travis-cipart
18:22:57  * kazuponquit (Remote host closed the connection)
18:35:25  <creationix_>yep, wasn’t too hard to fix https://code.google.com/p/miniz/issues/detail?id=43
18:35:28  <creationix_>this works so far reading zips
18:38:52  <rphillips>nice
18:48:17  * travis-cijoined
18:48:17  <travis-ci>luvit/luvit#1187 (fixes/remove_x509_test - 6fb8d5f : Ryan Phillips): The build passed.
18:48:17  <travis-ci>Change view : https://github.com/luvit/luvit/commit/6fb8d5f2b20d
18:48:17  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41276050
18:48:17  * travis-cipart
18:49:08  <rphillips>creationix_: http://dkolf.de/src/dkjson-lua.fsl/home
18:49:22  <rphillips>sorta want to include this json parser/serializer
18:49:37  <creationix_>yeah, saw that one. I was going to try and write one faster
18:49:50  <creationix_>but we can use it for now. Writing a faster one is going to take some time
18:50:04  <rphillips>k
19:18:23  * DarkGodquit (Ping timeout: 240 seconds)
19:23:40  * kazuponjoined
19:28:24  * kazuponquit (Ping timeout: 255 seconds)
19:30:24  <rphillips>https://github.com/luvit/luvit/pull/538
19:42:11  <rphillips>tls module is next I think
19:47:48  <rphillips>i think the right answer to include libsigar is to fork luvi and include it there... thoughts?
19:49:11  * travis-cijoined
19:49:11  <travis-ci>luvit/luvit#1191 (json_fixes - 0ddb2bb : Ryan Phillips): The build passed.
19:49:11  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a6bd0d329dab...0ddb2bbea1a0
19:49:11  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41282782
19:49:11  * travis-cipart
20:05:29  <rch>it would be sweet to be able to bundle native libraries in the zip portion also
20:05:33  <rch>then no fork of luvi needed
20:06:37  <creationix_>right, for things we don’t want to put in luvi, I plan on making a way to pack dlls in the zip
20:06:42  <rch>sweet
20:07:03  <creationix_>but a fork works too, I don’t have much preference
20:07:42  <creationix_>I’m beginning to rethink my use of miniz
20:07:58  <creationix_>his crc32 code fails on zips created by linux’s zip command
20:08:12  <creationix_>(my lua code simply skipped crc checking)
20:08:17  <rch>another alternative to a fork is whatever would want to use the luvi-sigar-fork could just use luvi and apply a simple patch in its own build process to produce something equivalent to the luvi fork
20:08:25  <rch>creationix_: weird. crc is pretty well understood.
20:08:40  <creationix_>I’m thinking his zip utilities aren’t well tested
20:09:06  <rch>rphillips: i am just thinking about alternatives to a fork to simplify the build/dependency management… providing a generic way to do this for luvi means users of luvi don't have to have a fork when they want to bundle a native library
20:09:29  <rphillips>+1... if we could load the dll then that would be slick
20:09:32  <rphillips>libuv has that support
20:09:43  <creationix_>the problem is loading from memory
20:09:51  <creationix_>but if that doesn’t work, we can always write to a temp file
20:13:42  <rch>or maybe provide a way to compile it in like we do with gyp in virgo right now? there must be a reason not to do that in the new world
20:14:28  <creationix_>virgo and luvit build chain can’t include a C compiler
20:14:35  <rch>ah i see
20:14:46  <creationix_>the goal is just prebuilt luvi + prebuilt dlls
20:15:09  <creationix_>I suppose we could write some build scripts for platforms without prebuilt files
20:15:26  <creationix_>but the main case should be compiler-free
20:16:36  <rch>loading a dll/dso from a temp file to circumvent memory protection is just a little rootkitty
20:16:59  <creationix_>I don’t think it’s to circumvent memory protection
20:17:03  <creationix_>just a lack in APIs
20:17:07  <rch>huh
20:17:40  <creationix_>there are libraries that re-implement dlopen but use memory buffers
20:17:50  <creationix_>obviously they aren’t very portable
20:18:18  <creationix_>if you allow dlopen from writable filesystems, there is no security
20:22:43  <rch>too bad luajit ffi.load doesn't load from buffers
20:24:25  * kazuponjoined
20:24:47  <creationix_>yep, same with dlopen
20:25:25  <creationix_>rphillips: ok, I think I patched miniz enough to read out zips https://github.com/luvit/luvi/commit/4e218e0bbe4b7252f84c78086af76999f9273a1f
20:27:07  <rphillips>so the crc code is broken, or do the other compressors use a different algo?
20:27:18  <creationix_>not sure, they might not even use it
20:29:21  * kazuponquit (Ping timeout: 264 seconds)
20:30:27  <creationix_>hmm, yeah there are random looking 32-bit numbers in there
20:30:45  <creationix_>and it’s not related to my offset patches, still fails on normal zip files
20:33:24  * travis-cijoined
20:33:25  <travis-ci>luvit/luvi#116 (zip - 4e218e0 : Tim Caswell): The build has errored.
20:33:25  <travis-ci>Change view : https://github.com/luvit/luvi/compare/d528fffe5edd...4e218e0bbe4b
20:33:25  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41287316
20:33:25  * travis-cipart
20:38:53  * travis-cijoined
20:38:54  <travis-ci>luvit/luvi#117 (zip - 4831e7a : Tim Caswell): The build has errored.
20:38:54  <travis-ci>Change view : https://github.com/luvit/luvi/compare/4e218e0bbe4b...4831e7afd9a2
20:38:54  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41288170
20:38:54  * travis-cipart
20:42:35  * travis-cijoined
20:42:36  <travis-ci>luvit/luvi#118 (zip - 78eb506 : Tim Caswell): The build passed.
20:42:36  <travis-ci>Change view : https://github.com/luvit/luvi/compare/4831e7afd9a2...78eb50640367
20:42:36  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41288343
20:42:36  * travis-cipart
22:01:56  * travis-cijoined
22:01:56  <travis-ci>luvit/luv#167 (master - 1d72f67 : Tim Caswell): The build passed.
22:01:56  <travis-ci>Change view : https://github.com/luvit/luv/compare/42b50285dc27...1d72f67637f1
22:01:56  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/41296924
22:01:56  * travis-cipart
22:09:31  * travis-cijoined
22:09:31  <travis-ci>luvit/luvi#119 (zip - 85de981 : Tim Caswell): The build has errored.
22:09:31  <travis-ci>Change view : https://github.com/luvit/luvi/compare/78eb50640367...85de9816dd9c
22:09:31  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41297767
22:09:31  * travis-cipart
22:09:46  * DarkGodjoined
22:10:41  * travis-cijoined
22:10:41  <travis-ci>luvit/luvi#120 (zip - cdb5a9f : Tim Caswell): The build has errored.
22:10:41  <travis-ci>Change view : https://github.com/luvit/luvi/compare/85de9816dd9c...cdb5a9ff7ec0
22:10:41  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41297836
22:10:41  * travis-cipart
22:13:11  * kazuponjoined
22:18:33  * kazuponquit (Ping timeout: 264 seconds)
22:19:42  * travis-cijoined
22:19:42  <travis-ci>luvit/luvi#122 (zip - 9cd7f70 : Tim Caswell): The build passed.
22:19:42  <travis-ci>Change view : https://github.com/luvit/luvi/compare/463d75255227...9cd7f702810f
22:19:42  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41298098
22:19:42  * travis-cipart
22:22:10  * mattlgyjoined
22:29:04  <rphillips>creationix_: is there a way to take the chain and inject a read/writer that in an event emitter?
22:32:15  <rphillips>i sorta want to do something like https://gist.github.com/rphillips/2b6df405b169ad00bf19
22:33:54  <creationix_>where do you want the emit to go?
22:34:55  <creationix_>you could use a node stream1 style object if the data handler calls the external blocking write and the read loop result is written to the emitter
22:35:19  <creationix_>(assuming the object has a :write method and an :on(“data”, …)
22:36:47  <creationix_>or if you just want to monitor output, you can insert an emitter anywhere in the chain. Just make sure you also call write with the data to send it to the rest of the chain
22:39:59  <rphillips>so the connect() function for tls returns a cleartext event emitter
22:40:08  <rphillips>https://gist.github.com/rphillips/2b6df405b169ad00bf19
22:40:57  <creationix_>ok, so you want to adapt to the endpoint that’s shaped like a duplex streams1?
22:41:02  <rphillips>right
22:42:11  <creationix_>remind me of the full interface. it emits “data” for the cleartext, “end” when the stream ends, write returns true if you can write more data? “drain” emits when you can write again, and .end() ends the writable side?
22:42:55  <creationix_>oh, and there is :pause() and :resume() to control back-pressure on the emitter?
22:43:31  * creationix_changed nick to creationix
22:44:34  <rphillips>right
22:45:26  <creationix>was I right about :write() returning true when you can keep writing and false when you should stop and wait for drain?
22:45:36  <creationix>I have a hard time keeping that part straight
22:51:13  <rphillips>looks like it's here https://github.com/luvit/luvit/blob/master/lib/luvit/net.lua#L99
22:53:23  <creationix>so true when queue is empty, got it
22:54:02  * tjcraveyquit (Quit: Textual IRC Client: www.textualapp.com)
23:00:28  <creationix>rphillips: so there are two different shapes here
23:00:36  <creationix>one is a function that accepts (read, write)
23:00:42  <creationix>the other is the pair read, write
23:00:55  <creationix>it’s pretty effecient to convert an event-based stream to a read, write pair
23:01:08  <creationix>but the inside of chain is expecting a function that takes (read, write) and connects them
23:01:32  <creationix>so I would make a generic adapter that accepts a read, write pair and returns a function that takes (read, write)
23:02:56  <creationix>this wraps a uv stream https://github.com/luvit/luvit/blob/luvi-up/app/modules/codec.lua#L21
23:03:17  <creationix>we just need a new version of this that creates a synthetic emitter interface (and also returns the read, write pair
23:03:59  <creationix>read, write, emitter = codec.emitterStreamAdapter() or something
23:04:30  <creationix>writes to emitter will be forwarded to whoever calls read and calls to write will emit events on the emitter
23:05:12  <creationix>and then another helper codec.invert(read, write) will return the function(read, write) that chain expects
23:05:36  <creationix>or we could wire the two sides independently
23:05:47  <creationix>chain for encoders and chain for decoders
23:05:59  <creationix>since the server socket is also a read, write pair
23:13:30  <rphillips>wife's birthday today. going to start dinner
23:14:12  * kazuponjoined
23:14:15  <creationix>enjoy
23:17:35  <rphillips>I like the codec.streamadapter idea
23:18:53  <creationix>rphillips: not tested, but something like this https://gist.github.com/creationix/e52c2fcb3f84ec22b8ab
23:19:10  * kazuponquit (Ping timeout: 250 seconds)
23:19:10  <creationix>and if there is only one codec between the socket and the emitter, you don’t need chain
23:19:20  <creationix>since codecs have the same interface as the output of chain
23:53:22  * travis-cijoined
23:53:22  <travis-ci>luvit/luvi#123 (zip - c5196f9 : Tim Caswell): The build passed.
23:53:22  <travis-ci>Change view : https://github.com/luvit/luvi/compare/9cd7f702810f...c5196f9b97fc
23:53:22  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41307972
23:53:22  * travis-cipart