00:10:14  * elguapo99quit (Ping timeout: 245 seconds)
00:21:02  * mmaleckiquit (Ping timeout: 265 seconds)
00:39:03  * elguapo99joined
01:01:25  * xmingquit (Read error: Connection reset by peer)
01:10:18  * elguapo99quit (Ping timeout: 244 seconds)
01:38:54  * elguapo99joined
01:48:29  * take_cheezequit (Ping timeout: 252 seconds)
02:07:24  * take_cheezejoined
02:10:38  * elguapo99quit (Ping timeout: 264 seconds)
02:40:32  <CIA-22>caoshiwei master * r93ab775 / (src/utils.c src/utils.h tests/test-fiber-bug319.lua): fixed #319 - http://git.io/WggsrA
02:40:32  <CIA-22>caoshiwei master * rf36c77e / (src/utils.c src/utils.h tests/test-fiber-bug319.lua): remove gettop() and assert, add a test case that create a socket handle in fiber. - http://git.io/hbAeLg
02:40:33  <CIA-22>andi master * rd016e25 / src/utils.h : replace tabs with spaces to maintain a cindent style. - http://git.io/jGhnWQ
02:40:33  <CIA-22>Ryan Phillips master * r1f9c272 / (src/utils.c src/utils.h tests/test-fiber-bug319.lua): Merge pull request #335 from AndrewTsao/master - http://git.io/n_YSqw
02:42:46  * travis-cijoined
02:42:47  <travis-ci>[travis-ci] luvit/luvit#434 (master - 1f9c272 : Ryan Phillips): The build passed.
02:42:47  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/f6fccfcabd18...1f9c272561ec
02:42:47  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/2279221
02:42:47  * travis-cipart
03:00:22  * xmingjoined
03:38:58  * indexzerojoined
03:48:57  <CIA-22>Tim Caswell master * r255e888 / examples/web-app/modules/cleanup.lua : Fix typo in web-app example - http://git.io/6VXmyg
03:51:45  * travis-cijoined
03:51:45  <travis-ci>[travis-ci] luvit/luvit#435 (master - 255e888 : Tim Caswell): The build passed.
03:51:45  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/1f9c272561ec...255e8885668d
03:51:45  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/2279458
03:51:45  * travis-cipart
03:52:32  <creationix>has anyone had a chance or interest to compare the web module with the http module?
03:52:57  <creationix>taking luvit.io down for a quick update...
03:53:07  <creationix>(upgrade ubuntu version)
04:19:17  <creationix>I think luvit.io is back and functional
05:01:07  * kristatejoined
05:03:07  * dvvjoined
05:04:24  * take_cheezequit (Read error: Connection reset by peer)
05:06:35  * take_cheezejoined
05:40:42  * dvvpart
06:02:44  * aliemjoined
06:22:02  * kristatequit (Ping timeout: 264 seconds)
06:23:01  * TheJHjoined
07:28:58  * `3rdEdenjoined
07:54:36  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
07:57:31  * indexzeroquit (Quit: indexzero)
08:17:01  * arek_deepinitjoined
08:32:23  * `3rdEdenquit (Quit: Leaving...)
08:32:48  * `3rdEdenjoined
08:50:09  * creationixquit (Read error: Operation timed out)
08:58:12  * mmaleckijoined
09:07:39  * aliem_joined
09:10:47  * aliemquit (Ping timeout: 240 seconds)
09:35:04  * kristatejoined
09:44:51  * creationixjoined
09:59:19  * mmaleckichanged nick to mmalecki[meeting
10:09:42  * TheJHquit (Ping timeout: 244 seconds)
10:48:28  * mmalecki[meetingchanged nick to mmalecki
11:22:43  * TheJHjoined
11:23:09  * xmingquit (Changing host)
11:23:09  * xmingjoined
11:24:48  * kristatequit (Quit: kristate)
11:24:59  * kristatejoined
11:38:26  * `3rdEdenquit (Quit: Leaving...)
11:39:37  * arek_deepinitquit (Quit: Konversation terminated!)
11:48:38  * `3rdEdenjoined
12:38:47  * mmaleckichanged nick to mmalecki[busy]
14:06:00  * elguapo99joined
14:16:34  * `3rdEdenquit (Read error: Connection reset by peer)
14:18:04  * `3rdEdenjoined
14:24:50  * `3rdEdenquit (Read error: Connection reset by peer)
14:25:21  * `3rdEdenjoined
14:46:57  * aliem_quit (Remote host closed the connection)
14:54:17  * indexzerojoined
15:18:58  <creationix>Morning Luvit friends!
15:20:14  <creationix>I want to discuss a new readable stream API
15:20:35  <creationix>The one we inherited from node is hard to use and even node wants to change it
15:21:31  <creationix>also the current api breaks middleware systems (possibly the ugliest part of connect is buffering input streams between layers)
15:26:22  * `3rdEdenchanged nick to `3E|Cooking
15:30:40  * `3rdEdenjoined
15:37:40  * CIA-22quit (*.net *.split)
15:41:25  * CIA-22joined
15:49:57  * indexzeroquit (Quit: indexzero)
15:50:20  <creationix>posted to mailing list
15:51:44  <creationix>https://groups.google.com/d/msg/luvit/wFsudgNyFH8/sO38fpU6RZUJ
15:57:26  * luastonedjoined
16:00:14  <creationix>I have some other proposals, but let's focus on these two first
16:01:27  <creationix>the others I have pending are a new module system for binary addins (make require be lua only), and some long-standing issues like a good package manager, good API docs, breaking up luvit into modules, etc..
16:19:07  * philips_quit (Excess Flood)
16:22:21  * philips_joined
16:33:06  * `3E|Cookingquit (Quit: Leaving...)
17:08:08  * etandeljoined
17:09:59  <kristate>Hi Tim, are you online at the moment?
17:15:42  <creationix>I am
17:15:52  <creationix>just documented the proposed readable stream interface https://github.com/luvit/luvit/wiki/Interfaces
17:15:55  <kristate>Hi Tim -- I read your proposal
17:16:29  <kristate>nakamura-san and I are currently implementing something similar via a fork that we call "lev"
17:16:42  <kristate>you can check it out here https://github.com/connectFree/lev
17:17:20  <kristate>the key to lev is that all streamed data is in the form of cBuffers
17:17:36  <kristate>it's backed by a fast slab allocator that I wrote yesterday
17:17:43  <creationix>neat
17:18:16  <creationix>I'm still undecided on cBuffer vs cdata for mutable buffers
17:18:22  <kristate>we should be able to get :slice working by tomorrow
17:18:46  <kristate>slice will simply slice from the slab, so it should be pretty smooth
17:18:53  <creationix>yep
17:19:10  <creationix>have you started tackling http apps yet?
17:19:26  <kristate>not yet -- cBuffers now talks slabs
17:19:40  <creationix>is that faster than lua string for immutable data?
17:20:01  <kristate>the system's read() call directly interfaces with out slab
17:20:09  <kristate>our slab*
17:20:23  <kristate>so we're not really hitting lua at all
17:20:26  <creationix>yeah, that should be fast
17:20:43  <creationix>I wish I could use libuv from luajit
17:21:04  <kristate>setting flags and the like should be doable from the lua world
17:21:12  <kristate>but not all of uv should be exposed
17:21:47  <creationix>I wonder if I could layer a select-style interface on top of libuv
17:21:53  <creationix>luajit ffi sucks for callbacks in C
17:22:09  <kristate>I think it is pretty important to drop ffi if possible
17:22:17  <creationix>why is that?
17:22:27  <kristate>ffi is great for storing structs of data -- say image processing and the like
17:22:37  <kristate>but not so great for interacting with cfunctions
17:22:52  <creationix>I thought luajit was different in that regard
17:23:01  <creationix>where ffi is actually faster than the C api
17:23:13  <creationix>because it's tightly integrated into the jit
17:23:17  <kristate>ffi works directly with luajit
17:23:23  <kristate>so it's good for structs
17:23:48  <creationix>for sure, it's a great ctype system
17:24:08  <creationix>anything where you have arrays of structs, it's going to be super fast
17:24:39  <kristate>either way, we would like to get some sort of shared API under way
17:25:01  <creationix>I'm trying to make my http layer agnostic about the streams under it
17:25:06  <kristate>I assume that luvit is going to keep its buffers implemented in ffi?
17:25:15  <creationix>I didn't specify how the streams worked or what their binary data type was
17:25:41  <creationix>kristate: not sure. The current ffi based buffer was just a hack, not something I intended to keep
17:26:13  <kristate>streams API> I think that is the most important part. if at any point the buffer gets melded into a string we lose speed
17:26:14  <creationix>personally I've only ever used strings in my luvit apps
17:26:51  <creationix>so in the stream interface I just documented, the suggested data type is string, but it's not required
17:27:00  <creationix>it can be cBuffer slices
17:27:08  <kristate>it should be cBuffer slices
17:27:09  <creationix>or ffi cdata or tables, or whatever
17:27:34  <creationix>if we adopt cBuffers then it can be that
17:27:39  <creationix>and then only use strings for text
17:28:14  <creationix>I'm not opposed to it, I just haven't had time to explore that area properly
17:28:40  <kristate>okay -- we are making leaping progress over at lev
17:28:54  <creationix>did you see how fast my new "web" module was?
17:29:04  <kristate>I think you mentioned 10x ?
17:29:13  <creationix>using strings and naive memory management, I was getting ~50K/second
17:29:14  * `3rdEdenquit (Ping timeout: 264 seconds)
17:29:15  <creationix>more like 20x
17:29:34  <creationix>50,000 reqs/second
17:29:50  <kristate>was this hello world, or another application?
17:29:57  <creationix>hello world
17:30:06  <kristate>it's not just speed -- memory management is also important.
17:30:11  <creationix>stock luvit was only getting around 3K
17:30:21  * `3rdEdenjoined
17:30:30  <creationix>true, but luvit is already world ahead of node.js in memory management
17:30:34  <kristate>as well as GC issues -- the more objects used, the more GC has to work
17:30:49  <kristate>I think so -- luajit is a huge advantage
17:31:08  <creationix>luvit apps are generally 20x less ram than nodes apps
17:31:16  <creationix>but currently they are a lot slower
17:31:30  <kristate>I think that we can get things sped up here :)
17:31:39  <creationix>so I'm working on fixing the api and improving the speed
17:31:47  <kristate>yes -- I like your thinking re: API
17:31:58  <creationix>we can do smart memory management as well, it doesn't conflict at all with my efforts
17:32:02  <kristate>let me take care of some of the core APIs regarding streams
17:32:05  <creationix>combined it should be blazing fast
17:32:44  <creationix>do you understand what changed between old node style readable streams and the proposed readable streams?
17:33:03  <creationix>libuv's api is still like the old API for sockets
17:33:11  <creationix>but it should be a natural fit for file streams
17:33:24  <creationix>since file streams are just built around reading chunks out of an fd anyway
17:34:10  <kristate>I see that you are making another call to stream.read(onRead) inside of the read?
17:34:22  <creationix>right, that's the recursive loop
17:34:32  <kristate>that might not be a good idea if you have many events waiting for IO
17:34:33  <creationix>but it won't blow the stack because the callback is on a fresh stack
17:34:47  <kristate>it could lead to starvation
17:34:49  <creationix>and using coroutines it can be a simple while loop
17:35:12  <creationix>it shouldn't lead to starvation, I expect the callback to be called later
17:35:34  <kristate>it will be called later, but later is better when you have many clients waiting to connect
17:35:40  <creationix>read just queues a listener for the next data event (and unpauses the stream if it was paused)
17:36:03  <creationix>libuv handles that level
17:36:16  <creationix>all I can do is read_start and register a data handler
17:36:18  <kristate>right, but it does that anyways?
17:36:26  <kristate>there is no need to call read again
17:36:35  <kristate>this is why buffering is important
17:36:49  <creationix>the reason you call read again is because the callback is one-shot
17:36:54  <creationix>it won't be called again
17:37:12  <creationix>each call to read triggers one onRead callback event
17:37:29  <creationix>by not calling read recursively, you implicitly pause the stream
17:39:14  <kristate>in what event is this preferred?
17:39:54  <creationix>when using coroutines it allows me to read from a file using a while loop
17:40:13  <creationix>also the implicit pausing is essential to layered middleware modules in http requests
17:40:46  <creationix>currently the consumer of the stream has to explicitly call .pause and .resume to handle back-pressure
17:40:55  <kristate>I don't know if pausing a stream is a good idea -- does the data get buffered and replayed later?
17:41:20  <kristate>or would it tell a client to stop talking?
17:41:22  <creationix>yes buffered and replayed later, but also the input source is paused
17:41:27  <kristate>or does it buffer at the system?
17:41:32  <creationix>both
17:41:35  <kristate>where is it buffered?
17:41:40  <creationix>it buffers only as much as needed
17:41:44  <creationix>depends on what stream it is
17:41:59  <creationix>anyway, I need to take my wife to the doctor, I'll be back later
17:42:02  <kristate>in your http scenario
17:42:07  <kristate>okay, be safe.
17:42:23  <creationix>respond to the email if you want
17:42:33  <kristate>thanks
17:43:41  * etandelquit (Quit: Changing server)
18:10:26  * etandeljoined
18:15:48  * joshthecoderjoined
18:28:11  * indexzerojoined
18:33:12  * luastoned1joined
18:35:50  * luastonedquit (Ping timeout: 264 seconds)
18:39:02  * dvvjoined
18:40:29  * ddd_joined
18:44:18  * indexzero_joined
18:46:21  * indexzeroquit (Ping timeout: 252 seconds)
18:46:22  * indexzero_changed nick to indexzero
18:46:59  * ddd_quit (Quit: Page closed)
19:38:03  * indexzeroquit (Quit: indexzero)
19:50:49  * `3rdEdenquit (Quit: Leaving...)
20:00:58  * mmalecki[busy]quit (Ping timeout: 245 seconds)
20:18:03  * FireFlyquit (Ping timeout: 245 seconds)
20:27:36  * FireFlyjoined
20:47:13  * etandelquit (Ping timeout: 245 seconds)
20:49:03  * etandeljoined
20:51:18  * luastoned1quit (Quit: Leaving.)
21:02:16  * FireFlyquit (Changing host)
21:02:16  * FireFlyjoined
21:03:09  * kristatequit (Ping timeout: 245 seconds)
21:07:43  * mmalecki[busy]joined
21:10:40  <creationix>back
21:13:13  * mmalecki[busy]quit (Ping timeout: 260 seconds)
21:25:14  <creationix>API design question
21:25:27  <creationix>should streams be Emitters or not require that
21:25:46  <creationix>with the new readable and writable APIs, I only use the emitter to emit "error" events
21:25:57  <creationix>I could instead just move the error reporting to the callbacks
21:27:37  <creationix>https://gist.github.com/2dbc9a7510dd21cd2c1c
21:52:44  <creationix>hmm, playing with fibers, it's still painful https://gist.github.com/2dbc9a7510dd21cd2c1c#file_test.lua
21:52:56  <creationix>more lines setting up the wrappings than using them
21:53:08  <creationix>though, if we switched to continuable style, it would be much more elegant
21:53:11  <creationix>and not require wrapping
21:53:44  <creationix>local fs = wait(fs.open("file.log", "r", "0666"))
21:53:52  <creationix>or without coroutined
21:54:10  <creationix>fs.open("file.log", "r", "0666")(function (err, fd) end )
23:11:25  * etandelquit (Ping timeout: 244 seconds)
23:24:26  * mmalecki[busy]joined
23:42:17  * jbuezaquit (Quit: jbueza)