--- Log opened Tue Apr 30 00:00:14 2013
00:01 < trevnorris> isaacs: also, why the "char* storage = new char[]; char* data = storage;"?
00:02 <@isaacs> trevnorris: copy pasta :)
00:02 < trevnorris> heh, ok.
00:04 < trevnorris> isaacs: i'm not familiar with HashUpdate, but does it retain the memory? I don't see where "data" is being free'd.
00:07 <@isaacs> trevnorris: doesn't matter.  storage is on the stack
00:08 <@isaacs> oh, right, i'm not freeing storage, though :)9
00:08 <@isaacs> and that's new'ed
00:10 <@isaacs> trevnorris: fixed the leak
00:10 < trevnorris> coolio
00:12 < trevnorris> isaacs: the concept looks clean. I like it.
00:12 < trevnorris> just for testing I'll throw in the string buffering in js and run the benchmarks. but not tonight.
00:13 <@isaacs> kk
00:13 < trevnorris> also, based on the values in #5015 I'd have expected a larger discrepency between v0.8 and v0.10
00:14 <@isaacs> trevnorris: well, also, this is testing throughput, not creation time
00:14 < trevnorris> (just an observation)
00:14 < trevnorris> ah, ok.
00:14 < trevnorris> duh
00:14 <@isaacs> in each bench, i'm only creating a single hash object.
00:14 <@isaacs> it coudl be that digest() got slower, or something
00:15 <@isaacs> now i guess i should do the non-throughput bench
00:18 <@isaacs> trevnorris: yeah, this is weird... i'm seeing it going faster (on my mac, anyway) with v0.10 than v0.8
00:18 < trevnorris> that is strange. i'm out, but next time I'll grab that patch and test it here.
00:19  * trevnorris &
00:19 < LOUDBOT> FUCKING DECIDE WHETHER FUCKING NEEDLE OR FUCKING HAYSTACK IS THE FIRST FUCKING PARAMETER
00:19 < trevnorris> lol. LOUDBOT you're the best way to end the day
00:26 < kellabyte> lol
00:36  * isaacs &
00:36 < LOUDBOT> HELLO IS MICHAEL JACKSONS HAIR ON FIRE WORTHY OF AN FPP
04:06 -!- mode/#libuv [+o TooTallNate] by ChanServ
07:31 <@indutny> morning
08:52 <@indutny> bnoordhuis: good morning
08:52 <@indutny> how are you?
09:34 < bnoordhuis> indutny: sup fedor
09:34 <@indutny> ho man
09:34 <@indutny> I'm good
09:34 <@indutny> https://github.com/joyent/libuv/pull/794
09:35 < bnoordhuis> i may or may not look at that today
09:36 < bnoordhuis> it's a holiday today here :)
09:36 <@indutny> wow
09:36 <@indutny> really?
09:36 < bnoordhuis> yep. also the coronation of the new king
09:36 <@indutny> ah
09:36 <@indutny> queen's day
09:36 <@indutny> kewl
09:36 < bnoordhuis> yep
09:37 <@indutny> very nice
09:37 <@indutny> actually, this patch is pretty simple
09:37 <@indutny> I've just removed mutex and added semaphore instead
09:37 < bnoordhuis> next year it'll be called king's day
09:37 <@indutny> hahaha
09:37 < bnoordhuis> feels... strange
09:37 <@indutny> is it like for the first time in dutch history?
09:37 < bnoordhuis> not the first time. but the first time in 80 years or thereabouts
09:38 <@indutny> still surprising
09:38 < bnoordhuis> hm, more like 120 years
09:38 < bnoordhuis> the first queen was coronated in 1890
09:38 < bnoordhuis> and it's been queens ever since
09:39 <@indutny> well, its good
09:42 < bnoordhuis> indutny: so how do you ensure that s->events is accessed atomically
09:42 <@indutny> bnoordhuis: well, it can't be the other way
09:42 <@indutny> semaphores
09:42 <@indutny> its pretty hard synchronization
09:42 < bnoordhuis> well...
09:43 < bnoordhuis> you call uv_async_send() before uv_sem_wait()
09:43 <@indutny> yes
09:43 < bnoordhuis> the other way around won't work, of course
09:43 <@indutny> so what can possibly happen
09:43 < bnoordhuis> but it means the other thread may have processed things before the call to uv_sem_wait()
09:43 <@indutny> yes
09:43 <@indutny> but that's ok
09:43 <@indutny> and we can safely loop
09:44 <@indutny> because events = 0 now
09:44 <@indutny> I can even add assertion if you want
09:44 <@indutny> and surely there's no need to |= events now
09:46 <@indutny> oook
09:46 <@indutny> assertion happens
09:46 <@indutny> gosh
09:47 <@indutny> ah
09:47 <@indutny> it happens when closing
09:48 <@indutny> yes
09:48 <@indutny> seems to be working good now
09:48 < bnoordhuis> oh? what did you change?
09:49 <@indutny> well, I just simplified it
09:49 <@indutny> s->events = events
09:49 <@indutny> and added
09:49 <@indutny>       assert((s->events == 0) || (stream->flags & UV_CLOSING));
09:49 <@indutny> after sem_wait()
09:49 <@indutny> so, this way, I'm always sure that events was processed
09:49 <@indutny> (force pushed, btw)
10:04 < bnoordhuis> indutny: see my comments. otherwise LGTM, i guess
10:04 <@indutny> kewl
10:04 <@indutny> thank you
10:04 < bnoordhuis> i think i'll move that code into darwin.c sometime in the near future
10:04 < bnoordhuis> as a fyi
10:07 <@indutny> heh
10:07 <@indutny> good decision
10:08 < MI6> joyent/libuv: Fedor Indutny v0.10 * 67f9b91 : stream: use harder sync restrictions for osx-hack - http://git.io/F3rbtg
10:08 <@indutny> thank you
10:10 < MI6> libuv-v0.10: #47 UNSTABLE windows (6/187) osx (1/187) smartos (3/186) linux (1/186) http://jenkins.nodejs.org/job/libuv-v0.10/47/
10:15 < MI6> libuv-v0.10-gyp: #10 UNSTABLE windows-x64 (5/187) smartos-ia32 (3/186) osx-x64 (1/187) smartos-x64 (4/186) windows-ia32 (6/187) osx-ia32 (1/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/10/
10:23 < MI6> libuv-node-integration: #37 FAILURE linux-ia32 (1/581) http://jenkins.nodejs.org/job/libuv-node-integration/37/
10:59 -!- mode/#libuv [+o piscisaureus_] by ChanServ
11:07 < bnoordhuis> piscisaureus_: how was the coronation?
11:29 <@piscisaureus_> bnoordhuis: I don't know. I'm just moving between parties.
11:29 <@piscisaureus_> Not interested in the actual coronation
13:50 < kellabyte> whats the difference between libevent and libuv?
13:59 <@indutny> kellabyte: freshness, better support
13:59 <@indutny> and many other stuff
13:59 <@indutny> also it doesn't support windows
14:00 <@indutny> well
14:00 <@indutny> it supports it
14:00 <@indutny> but not completion ports
14:00 <@indutny> so its probably slow
14:01 < kellabyte> indutny: everything I'm reading says libevent supports IOCP since 2010?
14:01 < kellabyte> in libevent 2.0
14:04 < kellabyte> indutny: I got a question "why haywire and not libevent's evhttp" I'm like, I dunno why libuv vs libevent :P
14:40 < MI6> joyent/node: isaacs v0.10 * dda7b40 : doc: Fix require.extensions documentation - http://git.io/7p_6Kw
14:45 -!- mode/#libuv [+o piscisaureus_] by ChanServ
14:57 < MI6> nodejs-v0.10: #167 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/167/
15:15 <@piscisaureus_> bnoordhuis: hey, I'm not happy with the openssl downgrade.
15:15 <@piscisaureus_> bnoordhuis: because it broke the build
15:15 <@piscisaureus_> bnoordhuis: also it's one big commit so now it's impossible to track the patches we float again
15:20 <@isaacs> omw into the office.  call in 0:40
15:20 <@isaacs> piscisaureus_, bnoordhuis: Please continue the fight over openssl, we can reach some kind of decision on the call.
15:20  * isaacs &
15:20 < LOUDBOT> DO YOU REALLY LIKE THAT BUU OR ARE YOU JUST SAYING
15:20 <@piscisaureus_> isaacs: I won't be at the call
15:48 < bnoordhuis> piscisaureus_: it's just `git checkout origin/v0.8 -- deps/openssl` - what's in v0.8 is in v0.10 now
15:48 < bnoordhuis> i'd be okay with reverting the downgrade if there is a reliable way to fix the regressions
15:48 < bnoordhuis> but so far i'm not having much luck
15:49 < bnoordhuis> connecting with e.g. s_client -tls1 works but doing the same thing with node fails
15:49 < bnoordhuis> sometimes hardm as in asserts at runtime
15:50 < bnoordhuis> if you want to look at it, be my guest. i'm slogging my way through 500 pages of legalese right now
15:51 < bnoordhuis> (which you should do too, really)
16:01  * isaacs fg
16:02 -!- mode/#libuv [+o sblom] by ChanServ
16:03 <@isaacs> bnoordhuis: skype?
16:04 <@isaacs> trevnorris: skype?
16:05 -!- mode/#libuv [+o TooTallNate] by ChanServ
16:44 < bnoordhuis> tjfontaine: re user-service.condenastdigital.com, i can only get it to work when i disable tls altogether
16:45 < bnoordhuis> that is, tell openssl to only use sslv2 and 3
16:45 < bnoordhuis> it even barfs on tls 1.0 - but not with v0.8 :-/
16:47 < tjfontaine> bnoordhuis: I presume we're talking in node, right?
16:47 < bnoordhuis> yes
16:47 < tjfontaine> ok, and how do you disable tls altogether, by compiling it out you mean?
16:48 < bnoordhuis> no, passing SSL_OP_NO_TLSv1 in secureOptions
16:48 < tjfontaine> oh ok
16:48 < bnoordhuis> SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv2 does not work, however
16:48 < tjfontaine> 1_2
16:49 < bnoordhuis> err, right
16:49 < bnoordhuis> v0.8 however is perfectly happy talking tls 1.0 to that server
16:50 < tjfontaine> maybe we're just missing an initialization of something
16:50 < bnoordhuis> it doesn't look like openssl 1.0.1 is advertising any new ssl/tls extensions
16:52 < bnoordhuis> let's see what compiling with OPENSSL_NO_TLS1_2_CLIENT does
16:54 <@indutny> bnoordhuis: believe me - its most like a cipher
16:55 < bnoordhuis> yeah. i never was into puzzles
16:56 <@indutny> s/like/likely/
16:56 <@indutny> there're not that much stuff
16:56 <@indutny> also it might be a signature_algorithms
16:56 <@indutny> extensions
16:56 <@indutny> anyway, something related to cryptography
16:58 < bnoordhuis> okay, it's not OPENSSL_NO_TLS1_2_CLIENT
16:59 <@indutny> hahaha
17:00 < bnoordhuis> curiously enough, even OPENSSL_NO_TLS1 doesn't fix it
17:01 < bnoordhuis> i guess that means it's something in node
17:02  * bnoordhuis is off to dinner
17:49 < trevnorris> indutny: posted a v8 issue about adding a flag so the object would free linked mem on gc. responded saying "v8 gc generally does not necessarily visit dead objects"
17:49 < trevnorris> and basically it'd be necessary to do the same thing (persist/makeweak) internally to accomplish this.
17:50 < trevnorris> so, from how that sounds, seems like that approach isn't worth investigating. thoughts?
17:50 <@indutny> what? :)
17:50 <@indutny> aaah
17:50 <@indutny> got it
17:50 <@indutny> here is the deal
17:50 <@indutny> that won't help you that much
17:51 <@indutny> you need a separate space for such objects
17:51 <@indutny> which could be really cheaply scavenged
17:52 < trevnorris> interesting. and v8 isn't doing something similar now I assume.
17:55 < trevnorris> ircretary: tell bnoordhuis 3.18.5 has the fromCharCode fix. upgrade?
17:55 < ircretary> trevnorris: I'll be sure to tell bnoordhuis
18:50 < trevnorris> oooh. --expose_natives_as has some fun stuff.
18:55 -!- mode/#libuv [+o piscisaureus_] by ChanServ
18:56 -!- mode/#libuv [+o sblom] by ChanServ
18:57 < trevnorris> indutny: crazy ass and horribly uninformed idea. possible to enable allow_natives_syntax by default, for use in crypto w/ openssl?
19:01 <@TooTallNate> huh?
19:25 < trevnorris> TooTallNate: not sure of the deep technical details, but allows for much quicker interface between js and cc.
19:29 < trevnorris> TooTallNate: for example. say I set "--expose_natives_as=nav", running nav.ToUint32(n) is ~4x's faster than when I do the same from a module.
19:30 <@TooTallNate> woah
19:31 < trevnorris> basically, it injects the assembly of your code into the js assembly generated.
19:38 < trevnorris> TooTallNate: it would probably be a ridiculous undertaking, but I like the idea of having a build config that tells node to use this, then we could start building out optimizations that will replace the usual if it's set.
19:41 <@TooTallNate> trevnorris: ya that could be interesting
19:41 < trevnorris> TooTallNate: where I think it would come in handy is, say, short string hashes.
19:42 < trevnorris> right now it has a large instantiation cost, but if it could call the openssl code directly, think there could be significant improvements.
19:59 < trevnorris> have there been discussions about wanting to move away from openssl?
20:01 < trevnorris> isaacs: had idea for hashing. how about not instantiating a full class until the second "update()". I'd assume people are using the algorithm for passwords and such.
20:02 < trevnorris> so we could streamline that case.
20:20 <@isaacs> trevnorris: so, that's not even 10% of the regression.
20:21 <@isaacs> trevnorris: basically, it's close to 100% due to the fact that we provide the result as a buffer instead of a string.
20:22 <@isaacs> trevnorris: if i have it return as a string, then we get all the performance back.
20:22 <@isaacs> trevnorris: converting the writes to buffers is about 10% or so of the regression (a 5% improvement overall)
20:22 <@isaacs> trevnorris: but just turning a char* into a buffer is fully HALF of the time spent doing createHash('sha256').digest()
20:23 < trevnorris> isaacs: check out these perf using the new buffers: http://git.io/koMS7A
20:24 < trevnorris> isaacs: line item "#4964" in the first batch are using the new buffers.
20:24 < trevnorris> test 2 is generating a MD5 hash from a single string.
20:25 < trevnorris> the new buffers can generate a new instance from an existing char* in ~250ns.
20:25 < trevnorris> that only accounts for 10% of the time it takes to run.
20:26 <@isaacs> nice
20:26 <@isaacs> it kinda sucks to wait for 0.12 before we can make crypto fast again
20:27 < trevnorris> yeah
20:28 < trevnorris> not sure what could be done about that. the changes necessary are too extensive for a stable branch, imho.
20:29 < trevnorris> TooTallNate: anything special I need to feed node-gyp to link in <openssl/md5.h>?
20:29 < trevnorris> it compiles, but keeps giving me a linkage error when I run
20:30 <@isaacs> trevnorris: interestingly, the *throughput* is somewhat *faster*
20:30 <@isaacs> trevnorris: but calling hash.digest() is crazy slow
20:31 < trevnorris> that's really strange.
20:34 <@isaacs> in the throughput test, i'm throwing TONS of buffers at it
20:34 <@isaacs> so, it could just be that V8 got faster.
20:34 <@isaacs> btw,
20:35 <@isaacs> bnoordhuis piscisaureus indutny trevnorris tjfontaine sblom TooTallNate http://simp.ly/publish/7mYRTH
20:35 < tjfontaine> hopefully not too many typos in it
20:35 < tjfontaine> :)
20:39 < trevnorris> nice. like it.
20:39 < trevnorris> attention span is crap, so write ups are great.
20:44 <@isaacs> i'll just keep prepending to that file in NValt, so feel free to bookmark or whatever.
20:52 < trevnorris> isaacs: you already in palo alto, or heading down later?
20:54 < tjfontaine> he's in SF atm
20:56 <@indutny> what's that?
20:56 <@indutny> oh, call notes
20:56 <@indutny> nice
20:56 <@indutny> I think we can template it
20:57 <@indutny> "trevor: buffers sucks, persistent and makeweak sucks, working on that"
20:57 <@indutny> "ben: bug fixes and openssl crap"
20:57 <@indutny> "bert: windows sucks, I was on queen's party"
20:57 <@indutny> "isaacs: oh, streams2"
20:57 <@indutny> "TooTallNate: oh my pi!"
20:58 <@indutny> "fedor: did nothing on node"
20:58 <@indutny> super-productive two weeks :)
20:59 < tjfontaine> heh
21:00 <@indutny> oh
21:00 <@indutny> tj: "jenkins sucks"
21:00 <@indutny> :D
21:00 <@indutny> sorry if anything
21:00 <@indutny> didn't mean to be rude
21:00 < trevnorris> lol
21:00 <@indutny> just stupid jokes
21:00 < tjfontaine> you captured me appropriately
21:04 < trevnorris> heh. egrep "fuck.*(windows|jenkins)"
21:05 < tjfontaine> yes.
21:11 < bnoordhuis> indutny: you forgot "reviewed patches"!
21:11 <@indutny> ah yes
21:11 <@indutny> definitely
21:12 < bnoordhuis> trevnorris: does spidermonkey have anything similar to v8's SetExternalArrayData?
21:12 < bnoordhuis> looking at the way typed arrays are implemented, i'm guessing the answer is 'no'
21:13 < bnoordhuis> SetIndexedPropertiesToExternalArrayData, rather
21:16 < tjfontaine> bnoordhuis: fwiw I built node against the shared version of 1.0.1 and it exhibits the same error, I'm now going to trace the ssl calls between s_client and node to see if there's anything obvious
21:17 < trevnorris> bnoordhuis: don't know. let me go ask one of the devs.
21:33 < tjfontaine> so one of the interesting differences between node and s_client, node is triggering more ssl_add_clienthello_tlsext interactions
21:34 < tjfontaine> https://gist.github.com/tjfontaine/5492127
21:36 < bnoordhuis> ah. no doubt that's it
21:37 < bnoordhuis> hm. i wonder what extensions those are
21:38 < MI6> joyent/node: Ben Noordhuis master * ab518e8 : https: implement https.Server#setTimeout() - http://git.io/oIU_jw
21:38 < tjfontaine> the only other difference is we set the next proto cb
21:38 < tjfontaine> well at least what seems to mean the only other difference
21:39 < bnoordhuis> i tried disabling that but it didn't make a difference
21:39 < bnoordhuis> hm, i wonder if i wasn't rigorous enough
21:40 < bnoordhuis> let's see what happens when we disable everything except bare tls 1.0
21:40 < trevnorris> TooTallNate: how the fuck do I link against openssl? swear I've basically copied out everything from node.bcrypt and I still get a linkage error.
21:40 <@TooTallNate> trevnorris: in an addon?
21:40 < tjfontaine> bnoordhuis: fwiw I haven't done the -no_tls1_2 comparison yet
21:40 < trevnorris> TooTallNate: yeah.
21:41 <@TooTallNate> trevnorris: did you do everything in: https://github.com/TooTallNate/node-gyp/wiki/Linking-to-OpenSSL?
21:41 < bnoordhuis> of course now the ssh connection to my linux machine craps out...
21:43 < trevnorris> TooTallNate: yeah. simplified since I don't care about win support or pre v0.6. but yeah.
21:44 <@TooTallNate> trevnorris: well what's the error you get?
21:44 <@TooTallNate> trevnorris: and also, is how is openssl linked to your copy of node?
21:44 < trevnorris> TooTallNate: symbol lookup error: [...] undefined symbol: MD5
21:44 <@TooTallNate> maybe that gyp code doesn't work when openssl is dynamically linked or something
21:45 <@isaacs> anyone interested in  crypto hash perf stuff: https://github.com/joyent/node/issues/5015#issuecomment-17254341
21:45 <@isaacs> bnoordhuis: i'm espcially interested in your opinions on the proposed (internal) API addition there
21:45 < trevnorris> TooTallNate: well, wouldn't it be the same case for node.bcrypt.js? that builds/runs fine.
21:46 <@TooTallNate> trevnorris: well ya it should be the same thing really
21:46 <@TooTallNate> check the output of `ldd path/to/binding.node`
21:46 <@TooTallNate> trevnorris: but also, how is openssl linked to your node?
21:46 <@TooTallNate> static or shared?
21:48 < trevnorris> TooTallNate: https://github.com/trevnorris/v8-basics
21:51 <@TooTallNate> [14:46:29] <@TooTallNate>	 trevnorris: but also, how is openssl linked to your node?
21:51 <@TooTallNate> [14:46:32] <@TooTallNate>	 static or shared?
21:52 < trevnorris> TooTallNate: think static. if that means I'm using the openssl that is packages w/ node.
21:52 <@TooTallNate> trevnorris: ya static is just the default
21:53 < tjfontaine> bnoordhuis: and with the -no_tls1_2 comparison (and the proto commented out) https://gist.github.com/tjfontaine/5492127#file-ssl_nottls-diff
21:53 <@TooTallNate> trevnorris: so you're probably trying to access a symbol that node doesn't access, and therefore node doesn't re-export the symbol from openssl
21:53 < trevnorris> TooTallNate: ah, that's probably it. MD5 isn't used by node.
21:53 <@TooTallNate> trevnorris: see https://github.com/joyent/node/issues/4051#issuecomment-8800621
21:54 <@TooTallNate> trevnorris: it's a bug that would be nice if it was fixed
21:54 <@TooTallNate> trevnorris: ideally what you're trying to do would work
21:54 <@TooTallNate> trevnorris: i don't really know what the status of that thread is though
21:58 < bnoordhuis> fuck, lost my ssh connection again
21:58 < bnoordhuis> i think it's a sign i should go to bed
21:58 < trevnorris> TooTallNate: so is there a quick hack to include openssl/md5.h so node exports it? tried by "#include <openssl/md5.h>" in crypto, but didn't work.
21:59 < tjfontaine> bnoordhuis: I wonder if our implicit read()==0 reset logic is getting in the way here
21:59 <@TooTallNate> trevnorris: that's a question for the C guys /cc bnoordhuis 
21:59 <@TooTallNate> trevnorris: but i think an empty function that references the function pointers would work
21:59 < trevnorris> ok
22:00 < tjfontaine> you need to reference the symbol you want to re-export
22:00 < tjfontaine> or tell your linker to stop doing the optimization on the library where it strips unused symbols
22:02 < trevnorris> tjfontaine: so, I tried by including md5.h in crypto. then adding "extern [...] MD5([...])" at the top.
22:02 < trevnorris> something like that?
22:03 < tjfontaine> the extern may work, but it may be that you need to static void foo() { MD5(...); }
22:03 < trevnorris> ah, ok.
22:03 < tjfontaine> there are also something like def files you can pass to the linker like we do on windows
22:04 < bnoordhuis> damn, it works
22:04 < tjfontaine> bnoordhuis: with which change?
22:04 < bnoordhuis> i blunt force disabled npn, servername, etc.
22:05 < bnoordhuis> and now i can connect when i specify SSL_OP_NO_TLSv1_[12]
22:05 < tjfontaine> so when we use npn/sni stuff we are implicitly declaring our interest in 1_2?
22:06 < bnoordhuis> i don't think so but i'm not sure
22:06 < bnoordhuis> npn, servername and so on are all extensions
22:07 < bnoordhuis> conde nast's service is choking on the servername extension...
22:08 < bnoordhuis> it also doesn't like tls 1.2 but 1.1 is fine
22:09 < tjfontaine> I had a friend forward the information to some condenast folk, hopefully I'll hear from them today or tomorrow, and I'll be able to update them with the info
22:09 < MI6> nodejs-master: #189 UNSTABLE smartos-x64 (1/587) linux-x64 (1/587) windows-ia32 (147/587) windows-x64 (146/587) http://jenkins.nodejs.org/job/nodejs-master/189/
22:09 < bnoordhuis> okay, cool
22:10 < bnoordhuis> i guess that means we can revert the downgrade
22:10 < tjfontaine> so why is that we couldn't set the NO_TLSv1_2 stuff?
22:11 < bnoordhuis> it's probably a bit of both
22:11 < bnoordhuis> that server doesn't like a) sni, and b) tls 1.2
22:12 < bnoordhuis> the odd thing is, of course, that openssl 1.0.0 advertised sni without trouble
22:12 < trevnorris> tjfontaine: screw it. just hacked the code I wanted to test into node. that's working
22:12 < bnoordhuis> ffs, lost ssh again
22:13 < bnoordhuis> okay, switching machines. fucking macs
22:14 <@isaacs> bnoordhuis: well, there's your problem.  you're just supposed to type on them, not fuck them.
22:18 < trevnorris> fuck yeah. only took me 3 hours, but finally made a single string in, md5 out addition to crypto.
22:18 < trevnorris> now time to benchmark.
22:19 < bnoordhuis> back
22:19 < tjfontaine> welcome home
22:19 < bnoordhuis> merci
22:20 < bnoordhuis> so i guess it doesn't really make sense that SSL_OP_NO_TLSv1_2 doesn't do anything unless you disable sni
22:20 < bnoordhuis> iow, further investigation required
22:20 < tjfontaine> what were you doing to disable sni?
22:21 <@TooTallNate> trevnorris: so it worked?
22:21 < bnoordhuis> tjfontaine: #ifdef'ing it out
22:21 < tjfontaine> bnoordhuis: ok
22:21 < trevnorris> TooTallNate: nope. just hacked the code I want to test directly into node.
22:21 <@TooTallNate> hahaha
22:22 < bnoordhuis> trevnorris: how does mozilla's patch review process work? just upload to bugzilla or ?
22:23 < trevnorris> isaacs: ok, so. "crypto.createHash('md5').update('hi').digest()" takes ~3000ns. my test of single string in, md5 out - "testmd5('hi').toString('hex')" runs in ~1000ns.
22:23 < trevnorris> 3x's faster.
22:23 < trevnorris> isaacs: and it returns a buffer, then I run toString('hex') on it.
22:24 < trevnorris> bnoordhuis: yeah. that's pretty much it.
22:25 < trevnorris> bnoordhuis: I hate hq, so can't help you there. but here's a how-to whatnot: https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch
22:26 < bnoordhuis> trevnorris: okay clear, thanks
22:26 < trevnorris>  /hq/mq
22:26 < trevnorris> mother effing.
22:26 < trevnorris>  /mq/hg
22:26 < trevnorris> bnoordhuis: send me the link and I'll forward it to the dev team.
22:27 < bnoordhuis> trevnorris: will do (though i haven't written any code yet)
22:27 < trevnorris> heh, ok.
22:28 < bnoordhuis> btw, re: --expose-natives-as, i've considered that in the past
22:28 < bnoordhuis> but the natives stuff is not stable in any way
22:28 < bnoordhuis> so it could be something of a risky proposition to introduce that in core
22:30 < trevnorris> bnoordhuis: real quick. chatting w/ the spidermonkey engineers.
22:30 < trevnorris> they're interested in seeing what you're doing. and are happy to help.
22:30 < trevnorris> if you have anything public, let me know.
22:31 < bnoordhuis> trevnorris: right. so what i want to do is add something similar to v8's SetIndexedPropertiesToExternalArrayData
22:31 < bnoordhuis> only with a less cumbersome name :/
22:31 < trevnorris> bnoordhuis: the reponse: "you can play games to get something like that for a typed array, but currently the engine still has to manage allocation (because there's a header in front of the data)"
22:31 < bnoordhuis> you mean the shape of the object?
22:31 < bnoordhuis> if yes, then yeah, i already got that far :)
22:32 < trevnorris> bnoordhuis: if you want, hop onto irc.mozilla.org #jsapi
22:32 < trevnorris> they'll help you out.
22:33 < bnoordhuis> okay, cool. but tomorrow, not today :0
22:33 < bnoordhuis> first this openssl thing, then i'm off to bed
22:33 < bnoordhuis> but thanks so far :)
22:33 < trevnorris> oh yeah. late there. np
22:35 < trevnorris> bnoordhuis: one last question from the team: "do you happen to know whether he's dealing with the new stack rooting stuff?"
22:35 < bnoordhuis> trevnorris: i don't know what that means so i guess the answer is no
22:35 <@TooTallNate> lol
22:35 < trevnorris> lol. neither do i. :)
22:36 -!- mode/#libuv [+oo tjfontaine MI6] by ChanServ
22:36 < trevnorris> bnoordhuis: last thing. was thinking the natives extension could originally be built under the node_unsafe_optimizations flag, or some such.
22:36 < trevnorris> just food for thought.
22:37 < bnoordhuis> well, perhaps. that flag is more for unsafe / known-bad compiler flags
22:37 <@tjfontaine> ooh now I get to play +o games lik ry
22:37 <@tjfontaine> *like
22:37 < bnoordhuis> but changes its semantics is no biggy, no one knows it exists in the first place
22:37 < bnoordhuis> *changing
22:37 < trevnorris> lol yeah.
22:38 < trevnorris> and maybe just add another node_use_natives or some such.
22:38 < bnoordhuis> hrm, yeah. let me think about it
22:38 < bnoordhuis> it's something bert and i have discussed in the past and it seemed like a good idea at the time
22:39 < bnoordhuis> but the thing is, of course, that any method on the natives object can go away at any time
22:39 < trevnorris> sfink from mozilla says "tell him they're fun, he'll love it!"
22:39 < bnoordhuis> hah
22:40 < trevnorris> well, that would be for the --expose-natives-as, right? i was thinking more of writing our own for ssl optimizations and such. isn't that possible?
22:40 < bnoordhuis> writing our own what? builtins?
22:41 < trevnorris> yeah...
22:41  * trevnorris timidly says
22:41 < bnoordhuis> how would that work? you mean patching runtime.js or?
22:43 < trevnorris> hm. thought the flag --allow-natives-syntax would allow for a user to write their own.
22:43 < trevnorris> guess not.
22:44 < bnoordhuis> ah, we're discussing --allow-natives-syntax now?
22:44 < trevnorris> oh, sorry yeah.
22:44 < bnoordhuis> well, yes, you could - but you'd have to add them to runtime.js :)
22:44 < trevnorris> really? well, that's a pain.
22:46 < trevnorris> maybe we can work something like that in by node v3.0 =)
22:48 < bnoordhuis> so what in particular would you implement?
22:52 < trevnorris> was thinking mainly for crypto.
22:53 < bnoordhuis> but what in particular?
22:54 < bnoordhuis> tjfontaine: i give up for tonight. it's definitely the servername extension but v0.8 sends it too and it works there
22:54 < bnoordhuis> s/tonight/the night/
22:55 < trevnorris> randomBytes
22:55 < trevnorris> also possibly for a few of the buffer methods like writeFloat*
22:56 < bnoordhuis> okay, i can see that
22:56 < bnoordhuis> but what about randomBytes?
22:57 <@tjfontaine> bnoordhuis: ok, I'll continue on it tonight, we can catch up tomorrow
22:59 < trevnorris> bnoordhuis: well, it takes ~3300ns for both randomBytes and pseudoRandomBytes. (2000 w/ the new buffer changes)
23:00 < trevnorris> oh, for a 16 byte random string.
23:00 < trevnorris> erm. buffer
23:00 < trevnorris> so I know that the new buffers only take 230ns to instantiate, and calling to/from cc ~40ns.
23:01 < trevnorris> so just wondering what's taking so long, and thought maybe a builtin could help there.
23:01 <@isaacs> trevnorris: see you in a bit, i'm heading down that way now-ish
23:01  * isaacs &
23:01 < LOUDBOT> KICKIN' IT OLDSKOOL AND THINGS LIKE THAT
23:01 < trevnorris> coolio.
23:03 < trevnorris> bnoordhuis: where Math.random() only takes around 5ns. realize that's not an apples to apples comparison, but that's still a huge margin.
23:03 < bnoordhuis> trevnorris: it's because randomBytes and pseudoRandomBytes go into the threadpool
23:03 < bnoordhuis> unless you were benchmarking the sync versions, of course
23:04 < trevnorris> yeah. that was the sync version.
23:05 < bnoordhuis> could also be because it mallocs a reasonable amount of memory
23:06 < bnoordhuis> and it always creates a new buffer, of course
23:06 < bnoordhuis> okay, signing off. have a good night, guys
23:06 < trevnorris> night, and thanks.
23:16 < trevnorris> isaacs: here's the md5 implementation: https://gist.github.com/trevnorris/5492650 (oh, and it depends on new buffers)
23:16 <@tjfontaine> better you tell him in person :)
23:16 < trevnorris> lol, good idea.
23:32 < trevnorris> just realized I haven't had a meal today. off to grab some food.
23:32  * trevnorris &
23:32 < LOUDBOT> I HAVE VASELINE ON MY TOES SO THAT I CAN TOE RAPE YOU FASTER.
23:33 <@tjfontaine> priceless
--- Log closed Wed May 01 00:00:20 2013