00:05:31  * UniOnquit (Remote host closed the connection)
00:27:19  <creationix>rphillips: does luvi with openssl build on osx?
00:27:56  <creationix>I’m missing #include <openssl/cms.h>
00:33:46  <creationix>staticbuild works :)
00:36:20  <creationix>hmm, I didn’t mean to push that partially done code to master
00:46:32  * travis-cijoined
00:46:32  <travis-ci>luvit/luvit#968 (luvi-up - b2fd52e : Tim Caswell): The build was fixed.
00:46:32  <travis-ci>Change view : https://github.com/luvit/luvit/compare/d05357145651...b2fd52eacf76
00:46:32  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39555665
00:46:32  * travis-cipart
00:56:02  <rphillips>creationix: the version on OSX is too old
00:56:07  <rphillips>static build is the way to go
00:56:25  <creationix>fair enough
00:56:47  <rphillips>you can install openssl via homebrew and override the OPENSSL_* variables
00:56:58  <rphillips>OPENSSL_ROOT_DIR is one of them
00:57:24  <rphillips>heh, i have it in my history
00:57:25  <rphillips>cmake -DWithSharedOpenSSL=OFF -DWithOpenSSL=ON -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl -DOPENSSL_INCLUDE_DIR=/usr/local/opt/openssl/include -DOPENSSL_LIBRARIES=/usr/local/opt/openssl/lib ..
00:59:49  * DarkGodquit (Ping timeout: 245 seconds)
01:01:31  <creationix>I almost have my tls wrapper working. I just need to figure out the proper way to use lua_openssl again
01:01:49  <creationix>it seems to change behavior after handshake completes
01:10:05  <rphillips>https://gist.github.com/rphillips/b20ae3ef6819f410dcf5#file-ssl-lua-L110
01:10:14  <rphillips>this ondata gets attached
01:10:20  <rphillips>after the connection succeeds
01:12:33  * kazuponjoined
01:22:22  * kazuponquit (Remote host closed the connection)
01:22:41  <creationix>rphillips: where do you read the plaintext?
01:23:13  <creationix>I see data coming out of input, but it’s certainly not plaintext
01:25:52  <creationix>ahh, that’s where I use ssl:read
01:26:32  <creationix>it works!
01:29:32  <rphillips>awesome
01:36:00  <creationix>you can merge your luvi PR now :)
01:36:46  <creationix>rphillips: usage in my new channel wrapper https://github.com/luvit/luvit/blob/luvi-up/test-tls.lua#L279-L297
01:38:09  <creationix>hmm, I should test the coroutine interface
01:40:42  * kazuponjoined
02:02:45  <creationix>I think lua_openssl has memory bugs. I get segfaults when I put it under and load
02:02:59  <creationix>just excessive logging is enough memory pressure to trigger the segfaults
02:09:28  <creationix>rphillips: blocking style too! https://github.com/luvit/luvit/blob/luvi-up/test-tls.lua#L276-L299
02:09:53  <creationix>there are still a couple bugs and it needs better proper shutdown and EOS handling, but it’s mostly there.
02:10:33  * travis-cijoined
02:10:33  <travis-ci>luvit/luvit#970 (luvi-up - c8706c3 : Tim Caswell): The build passed.
02:10:33  <travis-ci>Change view : https://github.com/luvit/luvit/compare/d78b3c08b124...c8706c38e21f
02:10:33  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39559923
02:10:33  * travis-cipart
02:15:43  * travis-cijoined
02:15:43  <travis-ci>luvit/luvit#971 (luvi-up - 19d64ae : Tim Caswell): The build passed.
02:15:43  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c8706c38e21f...19d64ae7940e
02:15:43  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39560161
02:15:43  * travis-cipart
02:25:02  * a_lequit (Remote host closed the connection)
02:25:57  <rphillips>\
02:25:59  <rphillips>https://github.com/luvit/luvit/blob/luvi-up/test-tls.lua#L112
02:26:16  <rphillips>creationix: all the local functions need local in front of them... or they get leaked to the global space
02:26:29  <creationix>there are no leaks, I declare them at top
02:26:34  <creationix>that way they can see eachother
02:26:45  <creationix>my editor has luacheck running as a live lint that is great for this
02:26:45  <rphillips>ah gotcha
02:26:46  <rphillips>cool
02:26:50  <creationix>it’s stricter than jshint
02:27:09  <rphillips>this is very nice...
02:27:15  <creationix>it will even complain if I declare a variable, set a value to it and then never use it
02:27:55  <creationix>I sent an email to the list asking what they think about adding coroutine support to everything
02:33:50  <rphillips>luv_fs_read has a 48 byte leak
02:41:04  <rphillips>looks like the uv_buf_t has the malloc pointer
02:41:09  <rphillips>for data
02:58:15  <rphillips>48-60 bytes
02:58:18  <rphillips>in different cases
03:29:58  <creationix>rphillips: which one? luvit or luv?
03:37:06  * kazuponquit (Remote host closed the connection)
03:37:14  <rch>creationix: your editor… not tedit right
03:37:32  <creationix>not lately. tedit is better for browser JS work, not C and lua
03:37:40  <creationix>I mostly use sublime 3 lately
03:38:04  <rch>ah cool
03:38:29  <creationix>if you ever do much lua stuff, I highly recommend setting up luacheck
03:40:36  * rchnotes
04:02:09  * a_lejoined
04:29:12  * a_lequit (Remote host closed the connection)
04:29:47  * a_lejoined
04:37:38  * kazuponjoined
04:42:19  * kazuponquit (Ping timeout: 245 seconds)
04:43:30  * kazuponjoined
05:09:04  * travis-cijoined
05:09:04  <travis-ci>luvit/luvit#973 (luvi-up - 5d7a012 : Tim Caswell): The build passed.
05:09:04  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c83252fcf2b0...5d7a0128fd01
05:09:04  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39563812
05:09:04  * travis-cipart
05:28:16  * a_le_joined
05:30:29  * a_lequit (Ping timeout: 264 seconds)
07:05:28  * kazuponquit (Remote host closed the connection)
07:06:26  * kazuponjoined
07:58:45  * kazuponquit (Remote host closed the connection)
11:33:49  * kazuponjoined
12:03:16  <rphillips>its in luvi with our OpenSSL changes
12:06:04  * kazuponquit (Remote host closed the connection)
12:50:42  * kazuponjoined
13:18:44  <rphillips>https://sourceforge.net/projects/axtls/
14:22:12  * dan336joined
14:25:37  <creationix>rphillips: axtls looks nice
14:34:00  <creationix>rphillips: any reason we can’t use axtls instead of openssl. I love the smaller footprint and simpler API
14:34:22  <rphillips>looking at it...
14:36:15  <rphillips>my concern is that everyone uses openssl
14:36:24  <rphillips>defacto standard almost
14:37:04  <creationix>right, more eyes
14:37:24  <creationix>for dukluv, I’ll probably use axtls. I care even more about footprint there
14:38:05  <creationix>I know static linking openssl blows up the binary size, but does it use a lot more ram too or is dynamic linking just as bad on ram?
14:42:01  <rphillips>supposedly the system shares the shared library between processes
14:42:14  <creationix>true, so openssl isn’t too bad on linux
14:42:34  <creationix>I just hate to triple the memory requirements for luvit just to have https clients
14:47:27  * a_le_quit (Remote host closed the connection)
14:48:03  * a_lejoined
14:52:44  * a_lequit (Ping timeout: 256 seconds)
14:53:14  <rphillips>nice thing about openssl is if someone has an accelerator then it will get used
14:57:02  * a_lejoined
14:58:36  <rphillips>has lua bindings
14:58:47  <rphillips>it would be slick to support both
14:59:00  <rphillips>but i think it's a nice to have
15:00:46  <rphillips>creationix: https://github.com/luvit/luv/blob/master/src/fs.c#L263
15:00:53  <rphillips>where is this data buffer freed?
15:09:23  <creationix>rphillips: looks like I forgot. It should be freed at https://github.com/luvit/luv/blob/master/src/fs.c#L166
15:09:51  <creationix>also it’s a shame I can’t use req->ptr. I tried, but libuv was writing over my pointer.
15:10:29  <creationix>fs read is the *only* thing that data field on luv_req_t is used for
15:10:49  <rphillips>oh, that makes it easier then
15:12:34  <creationix>should probably wait to malloc it till after checking arguments too
15:12:43  <creationix>it’s not needed till https://github.com/luvit/luv/blob/master/src/fs.c#L270
15:13:37  <creationix>rphillips: shall I fix it? I want to cleanup that function a little anyway.
15:13:45  <rphillips>sure
15:13:49  <creationix>and we can add fs_read to the memory leak tests too
15:14:04  <rphillips>thanks... i'm not too sure where to shoehorn it in
15:20:28  <creationix>I’m trying to convince libuv to make the API easier to use
15:20:42  <creationix>they already have the buffer inside buf.base
15:21:02  <creationix>if it was simply exposed in req->ptr in the result I wouldn’t need to store a copy of the pointer in my custom data struct
15:21:56  <creationix>rphillips: btw, for dukluv, I made a quick little type checking library that really cleaned up my code there. https://github.com/creationix/dukluv/blob/master/src/stream.c#L37-L42
15:22:17  <creationix>I declare all my variables first, then check all my arguments, then I start to allocate memory and do things that require cleanup.
15:22:59  <creationix>should I port this to luv? I think it would fix many memory leaks around invalid inputs. Not to mention cleanup the code a bit and document the argument names and types.
15:25:34  <rphillips>yeah that would be slick
15:27:21  <creationix>it should give really useful error messages combined with luaL_argcheck.
15:28:07  <creationix>rphillips: does it cost more to inline the static array in the function or is it better to declare it outside the function?
15:28:48  <creationix>I prefer the syntax of being inside, but I’ll move it out if it costs a lot more. My thinking is the C compiler will see it’s static and waste memory on every call.
15:28:48  <rphillips>that doesn't sound thread safe
15:29:06  <rphillips>if it's a static string... outside the function would be better
15:29:16  <creationix>but it’s immutable, why do threads matter?
15:29:28  <rphillips>if it's immutable, then it's fine
15:29:35  <creationix>I’m talking about the const duv_schema_entry[] btw
15:30:01  <creationix>a const and static array containing const and static char* and function pointers
15:30:12  <rphillips>outside the function is where I usually see them
15:30:31  <creationix>cool, thanks
15:51:51  <dan336>just FYI i opened an issue where received udp packets are never freed. (memory leak)
15:53:14  <creationix>dan336: awesome, thanks
15:53:30  <creationix>I think I’ll spend today cleaning up leaks in luv and adding the schema framework to cleanup code.
15:54:26  <dan336>cool.
15:54:55  <creationix>dan336: though I don’t see your issue. Your leak is again the C code in luvit master?
15:55:00  <creationix>*against
15:55:07  <dan336>yeah it is
15:55:11  <creationix>I’m working on the code in luvit/luv that’s replacing all the C code in luvit
15:55:35  <creationix>the luvi-up branch of luvit will become luvit 2.0 with luv at the core
15:55:51  <dan336>ok, should I be testing against that branch then?
15:56:03  <creationix>well, luvi-up is still quite alpha
15:56:09  <creationix>most the luvit features are still missing
15:56:13  <dan336>alright, I'll wait then.
15:56:35  <dan336>I'm using udp heavily right now for a new project and every packet leaks :)
15:56:38  <dan336>so I'll just be patient
16:02:23  * a_lequit (Remote host closed the connection)
16:03:00  * a_lejoined
16:03:29  * a_lequit (Read error: Connection reset by peer)
16:05:41  <creationix>dan336: it should be a quick fix, I’ll see if I can patch in in the old luvit while you wait for luvit 2.0
16:06:13  <creationix>rphillips: you were recently fixing memory leaks in the luvit C code, do you have time to look into it?
16:10:11  <rphillips>yeah, let me see
16:10:47  <creationix>dan336: and thanks for exercising the udp code. It never saw a lot of use
16:11:01  <creationix>I barely understood udp and C back when I wrote those bindings years ago
16:11:35  <creationix>dan336: also depending on how much code you have, you can consider porting directly to luv
16:11:38  <rphillips>dan336: which function is the leak in?
16:11:54  <creationix>luv is pretty stable at this point that contains all the primitives you’d need I think
16:12:25  <creationix>rphillips: you saw his test case right? https://github.com/luvit/luvit/issues/513
16:12:37  <rphillips>i did not. thanks
16:26:59  <rphillips>dan336: creationix : https://github.com/luvit/luvit/pull/514
16:27:11  <rphillips>instruments shows better performance
16:28:24  <creationix>I’ll bet. Wasting GB of ram destroy CPU cache
16:29:32  <dan336>oh sorry, I wasn't watching. The memory is actually allocated inside of libuv. in the uv__udp_recvmsg
16:30:09  <dan336>the stack is https://gist.github.com/DBarney/5faba2c363caaeae87dd
16:30:40  <dan336>but really if its going to be fixed with the new branch, I don't need it fixed.
16:31:01  <dan336>my project isn't currently being used in production or anything.
16:31:14  <rphillips>dan336: can you try that PR?
16:31:18  <rphillips>https://github.com/luvit/luvit/pull/514
16:31:38  <dan336>sure just give me one second
16:31:41  <creationix>the new C bindings use latest libuv (1.0.0-rc3 currently) Lots of new code upstream and on our side
16:32:29  * UniOnjoined
16:32:46  * a_lejoined
16:33:09  <dan336>well, memory did grow at all.
16:33:10  <dan336>but
16:33:11  <dan336>luvit(93487,0x7fff77b63300) malloc: *** error for object 0x7fb01841adb0: pointer being freed was not allocated
16:33:30  <creationix>hmm, too much free
16:33:44  <rphillips>dan336: is that with your test case?
16:33:53  <rphillips>gdb backtrace would be helpful
16:34:19  <dan336>yeah that was with my test case.
16:34:27  <dan336>i'll see if i can get a stack dump
16:38:08  <dan336>ok here is a stack dump: https://gist.github.com/DBarney/bc9eafa09a7397a38583
16:38:16  <dan336>it crashed on sending a packet.
16:38:28  <rphillips>k
16:41:27  <rphillips>hmm. yeah, that isn't a correct patch
16:59:36  * imzyxwvujoined
17:09:46  * a_lequit (Remote host closed the connection)
17:10:22  * a_lejoined
17:12:14  <dan336>so I'm confused, shouldn't this free the buffer after then event has been fired? https://github.com/luvit/luvit/blob/master/src/luv_udp.c#L90
17:13:41  * travis-cijoined
17:13:41  <travis-ci>luvit/luv#122 (master - 42a17b8 : Tim Caswell): The build was broken.
17:13:41  <travis-ci>Change view : https://github.com/luvit/luv/compare/3e955aac7dc4...42a17b8f54c1
17:13:41  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39619835
17:13:41  * travis-cipart
17:14:09  <rphillips>dan336: yes, it's something else
17:14:13  <rphillips>not sure what yet
17:14:15  <dan336>ah fixed it.
17:14:25  <dan336>just a sec i'll send a pull request
17:17:04  <rphillips>cool
17:18:06  <rphillips>dan336: https://github.com/luvit/luvit/compare/fixes/cache_lookup
17:18:13  <rphillips>this might be beneficial as well
17:19:02  <dan336>https://github.com/luvit/luvit/pull/515
17:19:09  <dan336>yeah that looks good.
17:19:41  <rphillips>nice!
17:22:01  <rphillips>merged
17:22:23  <dan336>sweet thanks!
17:23:15  <creationix>thanks dan336
17:23:53  <rphillips>dan336: your test case still exits for me after awhile
17:24:57  <rphillips>https://gist.github.com/rphillips/f45422c4a6b061cded1c
17:25:32  <dan336>thats weird
17:25:52  * a_lequit (Read error: Connection reset by peer)
17:26:03  <creationix>is the cached data growing the stack with sync callbacks?
17:26:11  <dan336>yeah it looks like it is
17:26:11  <creationix>another issue coroutines would solve :)
17:26:18  * a_lejoined
17:27:10  <creationix>zalgo callbacks (may or may not be called sync before returning from non-blocking function) often require trampolines externally to prevent stack overflows
17:28:58  * travis-cijoined
17:28:58  <travis-ci>luvit/luvit#979 (master - ca69dfa : Ryan Phillips): The build passed.
17:28:58  <travis-ci>Change view : https://github.com/luvit/luvit/compare/20e226a57f05...ca69dfab5638
17:28:58  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39621097
17:28:58  * travis-cipart
17:30:42  <rphillips>dan336: creationix: yeah, putting the :send into a process.nextTick clears it up
17:30:51  * travis-cijoined
17:30:51  <travis-ci>luvit/luvit#977 (fixes/cache_lookup - a50a088 : Ryan Phillips): The build passed.
17:30:51  <travis-ci>Change view : https://github.com/luvit/luvit/commit/a50a0881c2f4
17:30:51  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39620754
17:30:51  * travis-cipart
17:31:43  * kazuponquit (Remote host closed the connection)
17:39:50  <creationix>rphillips: fixed the fs_read leak. Sorry for pushing directly to master https://github.com/luvit/luv/commit/f19c3d9469d9cb9d860a91b064163508888d92d6
17:40:18  <creationix>the ->data member was added after I wrote the setup and cleanup helpers. I forgot to add it there.
17:40:21  <rphillips>sweet!
17:41:37  <creationix>I also filed https://github.com/joyent/libuv/issues/1557 so that we could remove the ->data->data member entirely
17:41:58  <creationix>Saving a pointer on all REQs would be nice
17:44:49  * a_lequit (Read error: Connection reset by peer)
17:45:08  * a_lejoined
17:46:03  * travis-cijoined
17:46:03  <travis-ci>luvit/luv#123 (master - f19c3d9 : Tim Caswell): The build was fixed.
17:46:03  <travis-ci>Change view : https://github.com/luvit/luv/compare/42a17b8f54c1...f19c3d9469d9
17:46:03  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39623006
17:46:03  * travis-cipart
17:46:34  <rphillips>creationix: nice... luvi-up branch memory usage looks good with the tls test
17:46:47  <creationix>great
17:47:08  <rphillips>1.9 MB
17:58:26  <creationix>rphillips: quick question about C
17:58:41  <rphillips>shoot
17:58:48  <creationix>If I have a function argument like (struct foo name[]), will it pass a copy of the array?
17:59:02  <creationix>I’m not clear on what [] syntax does
18:01:26  <rphillips>makes it a pointer
18:01:32  <rphillips>basically
18:03:52  <rphillips>usually there is a size passed as an argument
18:04:16  <creationix>I’m using null-terminated arrays so I don’t need size
18:04:24  <creationix>I was just worried it copied the array on every call
18:06:19  <creationix>rphillips: so what’s the difference between foo* name and foo name[]?
18:06:28  <creationix>other than how you use them internally
18:08:52  <creationix>I know that name[i] is the same as *(name + i) when using them. I guess [] is just sugar
18:09:15  <rphillips>yeah, both are looked at by the compiler as a pointer
18:11:25  <creationix>ok, I had read somewhere the [] syntax causes it to copy the array. I guess that was wrong
18:11:47  <creationix>some other places say name[] is identical to *name
18:12:24  <creationix>and if we really wanted to be consistent, it should be char name[] instead of char* name since it’s an array of chars
18:12:28  <creationix>thanks!
18:29:06  * DarkGodjoined
18:33:43  <rphillips>personally, I like *name, since it's more readable
19:04:32  <creationix>rphillips: ok, I converted one function to the new schema style, what do you think? https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/fs.c#L256-L284
19:06:01  <rphillips>https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/fs.c#L262
19:06:08  <rphillips>i think this struct should be declared outside the function
19:06:32  <rphillips>where is the free for buf.base?
19:06:56  <rphillips>we should make sure len is not < 0
19:07:33  <creationix>https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/fs.c#L282 stores buf.base in req->data->data which is cleaned up with the rest of the req
19:08:11  <creationix>so with the schema system, we can write new validators. I’ll make a new one that ensures the value is a positive integer
19:08:13  * travis-cijoined
19:08:13  <travis-ci>luvit/luv#124 (schema - 8de86bc : Tim Caswell): The build failed.
19:08:13  <travis-ci>Change view : https://github.com/luvit/luv/compare/eff35edb2f1d^...8de86bc53a49
19:08:13  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39631644
19:08:13  * travis-cipart
19:08:42  <rphillips>missing header
19:08:52  <creationix>yep, forgot to git add
19:09:08  <creationix>I ran the tests locally with a clean build so it should work
19:09:35  <creationix>and there is a leak detector test for that malloc now too
19:09:40  <creationix>I like to add regression tests whenever possible
19:10:27  <creationix>hmm, we still have a leak
19:10:40  <creationix>*potential leak
19:11:22  <creationix>though it’s very rare. The first malloc on https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/fs.c#L274 would have to succeed and then this one fail https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/lreq.c#L23
19:11:27  <creationix>the first one would never get freed
19:12:54  * travis-cijoined
19:12:54  <travis-ci>luvit/luv#125 (schema - d6929fd : Tim Caswell): The build was fixed.
19:12:54  <travis-ci>Change view : https://github.com/luvit/luv/compare/8de86bc53a49...d6929fd172e6
19:12:54  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39632044
19:12:54  * travis-cipart
19:13:10  <rphillips>https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/lreq.c#L40
19:13:15  <rphillips>shouldn't there be a free there?
19:13:39  <creationix>no, that’s just initializing the struct
19:15:34  <rphillips>https://github.com/luvit/luv/blob/8de86bc53a49dcb6f9535f7e3cf1cb4f0bc74e7e/src/lreq.c#L23
19:15:39  <rphillips>this could be a calloc instead then
19:16:52  <rphillips>data = calloc(1, sizeof(*data));
19:17:33  <creationix>true, but this is faster right?
19:17:49  <creationix>I need to set non-zero values to the other 16 bytes in the struct anyway
19:21:45  <rphillips>probably marginally faster...
19:22:07  <creationix>I’ve always seen code use malloc + memset to initialize. I wonder why calloc isn’t used more
19:22:33  <rphillips>calloc is usually optimized
19:23:42  <rphillips>http://stackoverflow.com/a/1585987
19:24:04  <rphillips>on a copy-on-write system, it's slower as well with calloc since the OS needs to find suitable memory
19:24:08  <rphillips>makes sense
19:25:58  <creationix>interesting
19:30:50  <creationix>rphillips: the confusing NULL is gone :) https://github.com/luvit/luv/commit/ca224a251f3d996cc95bc5525e54a6471b1cb209
19:31:42  * travis-cijoined
19:31:42  <travis-ci>luvit/luv#127 (schema - ca224a2 : Tim Caswell): The build passed.
19:31:42  <travis-ci>Change view : https://github.com/luvit/luv/compare/0798f561b9d0...ca224a251f3d
19:31:42  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39633642
19:31:42  * travis-cipart
19:43:11  <rphillips>this is all exciting stuff
19:47:37  <creationix>rphillips: ok, the first function is now complete I think. Care to check again https://github.com/luvit/luv/pull/82
19:51:00  * travis-cijoined
19:51:00  <travis-ci>luvit/luv#129 (schema - dbd0036 : Tim Caswell): The build passed.
19:51:01  <travis-ci>Change view : https://github.com/luvit/luv/compare/ca224a251f3d...dbd00363eeab
19:51:01  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39635265
19:51:01  * travis-cipart
20:05:02  <rphillips>commented
20:10:00  * a_lequit (Remote host closed the connection)
20:10:38  * a_lejoined
20:10:46  * a_lequit (Remote host closed the connection)
20:11:28  * a_lejoined
20:17:16  <creationix>rphillips: I read up on as much as I could about the cost of inline array literals. I couldn’t find much. So I decided to benchmark it. Moving the arrray literal out of the function body made a slight (10%) speedup.
20:17:59  * travis-cijoined
20:17:59  <travis-ci>luvit/luv#130 (schema - 641e8da : Tim Caswell): The build passed.
20:17:59  <travis-ci>Change view : https://github.com/luvit/luv/compare/dbd00363eeab...641e8dad6625
20:17:59  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39638136
20:17:59  * travis-cipart
20:19:32  <creationix>the cost of the check inline was about 59 units while calling check with an external array was about 47 units (units being whatever uv.hrtime uses)
20:19:59  <creationix>I calculated these numbers running 0x100000 loops and subtracting the baseline cost of no schema check at all
20:20:35  <creationix>so I guess that’s a 20% speedup then
20:25:42  <creationix>ok, unit is nanoseconds
20:34:20  <creationix>looks like overall the schema check (the faster version) causes a 3% slowdown in fs_read. Since that’s running in a tight loop and I’m reading a tiny (10 byte) chunk the FS interaction is highly cached.
20:34:42  * a_lequit (Remote host closed the connection)
20:35:14  <creationix>the overhead was around 23 ns per call in my tests
20:37:03  * a_lejoined
20:38:10  <rphillips>doesn't seem that bad at all
20:40:11  * not^vjoined
20:41:17  <rphillips>creationix: time to merge the openssl branch?
20:41:26  <creationix>I think so
20:44:29  <creationix>yeah, I guess that’s around 50 cpu instructions to check all my lua arguments and call several custom C callbacks right?
20:44:50  <creationix>1ns ~ 2 cycles of a 2 ghz machine?
20:48:07  * not^vquit (Read error: Connection reset by peer)
20:54:50  * travis-cijoined
20:54:50  <travis-ci>luvit/luv#132 (schema - 3a4664b : Tim Caswell): The build passed.
20:54:50  <travis-ci>Change view : https://github.com/luvit/luv/compare/641e8dad6625...3a4664b4eee6
20:54:50  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/39642616
20:54:50  * travis-cipart
21:00:59  <rphillips>https://github.com/luvit/luvi/pull/22
21:01:00  <rphillips>+1?
21:05:05  <creationix>yep, merge it
21:16:48  * a_lequit (Remote host closed the connection)
21:23:56  * dan3361joined
21:23:56  * dan336quit (Read error: Connection reset by peer)
21:38:32  * not^vjoined
21:39:28  <rphillips>tweaked luvi's readme to include the new openssl options
21:39:36  <rphillips>https://github.com/luvit/luvi#cmake-flags
21:40:40  * a_lejoined
21:40:42  <creationix>+1
21:40:55  <creationix>I’m updating the binaries in luvi-binaries so luvit’s CI servers can start testing the ssl stuff
21:41:29  <rphillips>early dinner
21:41:30  <rphillips>bbiab
21:42:33  <rch>luvi is so neat
21:43:01  * travis-cijoined
21:43:02  <travis-ci>luvit/luvi#73 (master - 0c8e8e9 : Ryan Phillips): The build passed.
21:43:02  <travis-ci>Change view : https://github.com/luvit/luvi/compare/67516c9f2f4e...0c8e8e9f7d34
21:43:02  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/39647225
21:43:02  * travis-cipart
21:43:48  * travis-cijoined
21:43:48  <travis-ci>luvit/luvi#75 (master - c423930 : Ryan Phillips): The build passed.
21:43:48  <travis-ci>Change view : https://github.com/luvit/luvi/compare/d3e0fa0a1c74...c42393054460
21:43:48  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/39647416
21:43:48  * travis-cipart
21:54:08  <creationix>cmake makes my life so much easier
21:55:46  * travis-cijoined
21:55:46  <travis-ci>luvit/luvi#76 (master - 203e419 : Tim Caswell): The build passed.
21:55:46  <travis-ci>Change view : https://github.com/luvit/luvi/compare/c42393054460...203e41969ef2
21:55:46  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/39648407
21:55:46  * travis-cipart
22:02:07  * travis-cijoined
22:02:07  <travis-ci>luvit/luvit#980 (luvi-up - 193b176 : Tim Caswell): The build passed.
22:02:07  <travis-ci>Change view : https://github.com/luvit/luvit/compare/cfc39ef6811c...193b17698d31
22:02:07  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/39649078
22:02:07  * travis-cipart
22:19:34  * not^vquit (Quit: http://i.imgur.com/Akc6r.gif)
22:45:12  * dan3361quit (Quit: Leaving.)
22:53:17  * DarkGodquit (Ping timeout: 264 seconds)
23:00:17  * a_lequit (Remote host closed the connection)
23:52:55  * a_lejoined
23:56:18  * dan336joined