00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:30  <isaacs>trevnorris: if you wanna leave that for me, you'd be totally justified in doing so
00:01:50  <trevnorris>isaacs: probably will. just wanted to see how difficult it would be. now I know.
00:01:54  <isaacs>trevnorris: it's my patch, i should take responsibility for the cleanup
00:02:04  <isaacs>and i reviewed the bio stuff, so i've got some idea of what's going on there.
00:02:12  <trevnorris>heh, well good luck dude. :)
00:02:28  <isaacs>could always just do a commit-by-commit manual rewrite of it
00:03:26  <trevnorris>because of the class syntax conversion, git has no idea what's going on. so yeah, I was just doing it method by method.
00:05:41  * groundwaterquit (Quit: groundwater)
00:05:47  <trevnorris>isaacs: eh, the buffer merge is a snap. it's the crypto stuff that's a bitch. i can use that to preemptively merge my stuff. :)
00:05:59  * paddybyersquit (Ping timeout: 252 seconds)
00:19:56  * qardquit (Quit: Leaving.)
00:21:26  * wavdedjoined
00:23:10  * inolenquit (Remote host closed the connection)
00:23:32  * inolenjoined
00:23:57  * dannycoatesquit (Remote host closed the connection)
00:27:17  * dominictarrchanged nick to dominictarr_zzz
00:32:25  * mikealquit (Quit: Leaving.)
00:33:01  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:44:30  * dapquit (Quit: Leaving.)
00:46:00  * timoxleyquit (Quit: Computer has gone to sleep.)
00:48:02  * pachetjoined
00:49:47  * TooTallNatejoined
00:49:47  * inolenquit (Quit: Leaving.)
00:52:11  * dominictarr_zzzquit (Quit: dominictarr_zzz)
01:11:59  * TooTallNatequit (Ping timeout: 252 seconds)
01:15:31  * TooTallNatejoined
01:19:23  * amartensquit (Quit: Leaving.)
01:21:57  * qardjoined
01:28:25  * abraxasjoined
01:29:09  * defunctzombie_zzchanged nick to defunctzombie
01:29:13  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:32:37  * mikealjoined
01:33:28  * hzquit
01:34:08  * timoxleyjoined
01:38:24  * defunctzombiechanged nick to defunctzombie_zz
01:43:19  * stagasjoined
01:50:45  * inolenjoined
01:54:26  * qardquit (Quit: Leaving.)
01:59:45  * defunctzombie_zzchanged nick to defunctzombie
02:02:49  * defunctzombiechanged nick to defunctzombie_zz
02:04:56  * hij1nxquit (Ping timeout: 256 seconds)
02:05:07  * `3rdEdenjoined
02:09:28  * `3rdEdenquit (Ping timeout: 256 seconds)
02:11:06  * hij1nxjoined
02:19:47  * timoxleyquit (Quit: Computer has gone to sleep.)
02:24:14  * pachetquit (Quit: leaving)
02:32:10  * st_lukejoined
02:39:45  * st_lukequit (Remote host closed the connection)
02:50:15  * amartensjoined
02:50:41  * amartensquit (Client Quit)
02:55:11  * wolfeidauquit (Remote host closed the connection)
03:09:07  * niska`joined
03:09:35  * pquerna_joined
03:09:36  * pquerna_quit (Changing host)
03:09:36  * pquerna_joined
03:09:45  * Ralt_joined
03:11:14  * brsonquit (Quit: leaving)
03:12:44  * defunctzombie_zzchanged nick to defunctzombie
03:13:44  * ingmar5joined
03:13:50  * Raltquit (Ping timeout: 245 seconds)
03:13:50  * LOUDBOTquit (Ping timeout: 245 seconds)
03:13:51  * pquernaquit (Ping timeout: 245 seconds)
03:13:51  * niskaquit (Ping timeout: 245 seconds)
03:13:52  * CAPSLOCKBOTquit (Ping timeout: 245 seconds)
03:13:53  * Ralt_changed nick to Ralt
03:13:53  * KiNgMaRquit (Ping timeout: 245 seconds)
03:13:54  * rjequit (Excess Flood)
03:17:00  * rje_joined
03:22:17  * defunctzombiechanged nick to defunctzombie_zz
03:22:40  * rje_quit (Quit: Leaving...)
03:26:05  * mikealquit (Quit: Leaving.)
03:29:02  * rjejoined
03:36:49  * kazuponjoined
03:41:44  * LOUDBOTjoined
03:41:44  * CAPSLOCKBOTjoined
03:50:03  * wavdedquit (Quit: Hasta la pasta)
04:05:43  * `3rdEdenjoined
04:10:18  * `3rdEdenquit (Ping timeout: 264 seconds)
04:14:55  * normanmjoined
04:34:07  * AvianFluquit (Remote host closed the connection)
04:41:56  * timoxleyjoined
04:53:53  <tjfontaine>ircretary: tell bnoordhuis aside from the missing test, what are your thoughts on something like https://github.com/tjfontaine/node/compare/hasref
04:53:53  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
05:10:51  * timoxleyquit (Ping timeout: 260 seconds)
05:15:11  * timoxleyjoined
05:40:38  * paddybyersjoined
05:58:52  * pquerna_changed nick to pquerna
06:08:28  * loladirojoined
06:22:39  * rendarjoined
06:25:36  * ingmar5quit (Quit: ZNC - http://znc.sourceforge.net)
06:26:01  * KiNgMaRjoined
06:29:57  * `3rdEdenjoined
06:30:39  * timoxleyquit (Ping timeout: 260 seconds)
06:35:26  * amartensjoined
06:38:43  * amartensquit (Client Quit)
06:46:22  * indexzerojoined
06:59:35  * Kjerskiquit (Ping timeout: 252 seconds)
07:13:06  * bajtosjoined
07:17:04  * timoxleyjoined
07:18:10  * csaohjoined
07:22:50  * indexzeroquit (Ping timeout: 256 seconds)
07:26:19  * csaohquit (Quit: csaoh)
07:31:45  * stolsmajoined
07:35:29  * indexzerojoined
07:36:59  * loladiroquit (Ping timeout: 252 seconds)
07:40:29  * csaohjoined
08:00:48  * wolfeidaujoined
08:05:31  * benoitcquit (Excess Flood)
08:12:19  * kazupon_joined
08:12:21  * kazuponquit (Read error: Connection reset by peer)
08:16:42  * benoitcjoined
08:32:33  * csaohquit (Quit: csaoh)
08:33:13  * csaohjoined
09:20:57  * stagasquit (Read error: Connection reset by peer)
09:46:14  * bajtosquit (Ping timeout: 252 seconds)
09:52:57  * bajtosjoined
10:02:08  * csaohquit (Quit: csaoh)
10:05:52  * csaohjoined
10:15:06  * indexzeroquit (Quit: indexzero)
10:22:52  * abraxasquit (Remote host closed the connection)
10:30:13  * csaohquit (Quit: csaoh)
10:39:02  * bajtosquit (Ping timeout: 252 seconds)
10:43:49  * timoxleyquit (Quit: Computer has gone to sleep.)
10:49:21  * bajtosjoined
10:50:42  * hzjoined
10:55:45  * csaohjoined
11:14:20  * kazupon_quit (Remote host closed the connection)
11:27:04  * dominictarrjoined
11:36:11  * bnoordhuisjoined
11:51:51  * pachetjoined
12:02:07  * Chip_Zerojoined
12:03:22  * bajtosquit (Quit: bajtos)
12:08:40  * pachetquit (Changing host)
12:08:40  * pachetjoined
12:19:37  * niska`quit (Remote host closed the connection)
12:27:41  * niskajoined
12:34:47  * bnoordhuisquit (Ping timeout: 256 seconds)
12:35:20  * pachetquit (Ping timeout: 240 seconds)
12:47:41  * mralephquit (Read error: Operation timed out)
12:50:38  * kazuponjoined
13:00:02  * indexzerojoined
13:17:35  * kazuponquit (Remote host closed the connection)
13:27:03  * kevinswiberjoined
13:36:06  * hzquit (Ping timeout: 264 seconds)
13:37:15  * dostoyevskyjoined
13:38:46  <dostoyevsky>Is there a way to dump the events that have been registered with libuv? We have a problem that libuv sometimes seems to hang which is probably because we have erroneously registered events that we never pay attention to...
13:39:21  <dostoyevsky>just seeing what events let libuv currently hang would be great
13:41:18  * pachetjoined
13:41:18  * pachetquit (Changing host)
13:41:18  * pachetjoined
13:41:23  * timoxleyjoined
13:47:58  * c4milojoined
14:00:19  * normanmquit (Quit: Computer has gone to sleep.)
14:02:44  * kazuponjoined
14:04:57  <saghul>dostoyevsky you can check all handles in a given loop using uv_walk
14:09:51  <dostoyevsky>saghul: Interesting
14:16:27  * hzjoined
14:23:28  * abraxasjoined
14:23:54  * stagasjoined
14:26:15  * kazuponquit (Remote host closed the connection)
14:27:02  * bajtosjoined
14:27:49  * abraxasquit (Ping timeout: 248 seconds)
14:28:47  * kazuponjoined
14:36:54  * dominictarrquit (Quit: dominictarr)
14:50:28  * groundwaterjoined
14:56:06  * bnoordhuisjoined
14:57:55  <MI6>joyent/node: Ryuichi Okumura v0.10 * 4cd643e : doc: fix missing Class in header (+1 more commits) - http://git.io/r_1wXQ
15:07:49  <isaacs>good morning, heroes
15:08:23  <isaacs>bnoordhuis: hey, i have a crazy idea for http servers...
15:08:41  <isaacs>bnoordhuis: when you do server.close(), if the client is doing some keepalive stuff, then the connections might not die for a very long time.
15:08:58  <isaacs>bnoordhuis: so, even though you're not accepting new connections, you won't gracefully close.
15:09:36  <isaacs>bnoordhuis: idea: if (server.closed) res.addHeader('connection', 'close')
15:09:37  <MI6>nodejs-v0.10: #193 UNSTABLE linux-ia32 (1/584) smartos-x64 (1/584) http://jenkins.nodejs.org/job/nodejs-v0.10/193/
15:09:53  <isaacs>bnoordhuis: and then res.on('finish', socket.destroy)
15:10:15  <bnoordhuis>isaacs: um. guess that sounds reasonable
15:10:33  <isaacs>kewl
15:10:42  <bnoordhuis>are people complaining about that or ?
15:10:43  <isaacs>i found this while adding the unref/keepalive behavior to our client.
15:10:53  <bnoordhuis>oh okay
15:11:00  <isaacs>well, i've kinda wondered why in the npm website, when i close a worker, the process stays alive for many minutes after.
15:11:05  <isaacs>it's weird behavior.
15:12:01  <isaacs>but also, if our client keeps connections open, then the server.close doesn't close the process.
15:12:14  <isaacs>also, a bug: if you do socket.unref(), it doesn't unref the timer aspect.
15:12:21  <isaacs>so it still keeps the process open for 2 minutes
15:15:58  * kazuponquit (Remote host closed the connection)
15:20:58  <MI6>nodejs-v0.10-windows: #23 UNSTABLE windows-ia32 (8/584) windows-x64 (10/584) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/23/
15:22:49  * `3rdEdenquit (Remote host closed the connection)
15:30:26  <MI6>joyent/node: Ben Noordhuis v0.10 * f59ab10 : buffer, crypto: fix default encoding regression - http://git.io/KRbiyQ
15:32:19  <bnoordhuis>god, it's been raining ever since dawn
15:32:43  <bnoordhuis>probably from before dawn but i wasn't around to notice it
15:32:58  <bnoordhuis>summer in holland...
15:39:17  <isaacs>yeesh
15:39:26  <isaacs>i'ts sunny and wonderful in Oakland
15:39:26  <dostoyevsky>bnoordhuis: Summer in Germany wasn't much different so far...
15:42:16  <MI6>nodejs-v0.10: #194 UNSTABLE smartos-x64 (3/584) http://jenkins.nodejs.org/job/nodejs-v0.10/194/
15:49:24  * dapjoined
15:50:13  * inolenquit (Quit: Leaving.)
15:50:31  <MI6>nodejs-v0.10-windows: #24 UNSTABLE windows-ia32 (9/584) windows-x64 (9/584) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/24/
15:51:06  * defunctzombie_zzchanged nick to defunctzombie
15:52:13  <bnoordhuis>tjfontaine: 'refd' is such an ugly name
15:54:56  * defunctzombiechanged nick to defunctzombie_zz
15:55:34  <tjfontaine>bnoordhuis: sure, I'm not tied to that
15:56:42  <tjfontaine>isaacs: oakland is a mystery it was overcast and rainy in alameda and now sf :)
15:56:57  <bnoordhuis>i guess it's not the worst thing in the world
15:57:02  <bnoordhuis>generally looks okay to me
15:57:06  <tjfontaine>bnoordhuis: it could just as easily be hasref
15:57:10  <isaacs>it was actually pretty overcast
15:57:15  <isaacs>but it's clearing up now
15:57:27  <bnoordhuis>tjfontaine: well... refd is less typing
15:57:40  <tjfontaine>quite, which is kinda why I picked it :)
15:57:42  <isaacs>though, there are clouds on the hills behind me, and clouds over alameda in front of me, so i think they may join forces and come get me
15:57:47  <isaacs>refd is kinda weird.
15:57:58  * isaacstaking weather personally
15:58:05  <tjfontaine>paranoia.
15:58:16  <tjfontaine>it's not paranoia if it's true
15:58:23  <bnoordhuis>hasReferenceThatKeepsTheEventLoopAlive
15:58:30  <tjfontaine>hah
15:59:08  <bnoordhuis>i can live with refd. it's internal anyway, right?
15:59:15  <tjfontaine>ya
15:59:55  <tjfontaine>I was just going to feel bad for isaacs trying to debug what is and isn't ref'd without having to compare against ._getActiveHandles :)
16:02:07  <isaacs>hahah
16:02:14  <isaacs>tjfontaine: i'm a pro at getActiveHandles now.
16:02:35  <isaacs>but it would be really nice if we started a convention of doing this.handle.type = 'net.Socket' or something
16:03:04  <tjfontaine>yesterday I really confused myself by unref'ing and o0'ing at why they weren't in ActiveHandles ...
16:03:07  <bnoordhuis>isaacs: doesn't this.handle.constructor.name work?
16:03:20  <isaacs>bnoordhuis: sort of
16:03:25  <isaacs>you have the .owner reference
16:03:27  <bnoordhuis>oh wait, you want the owning object
16:03:28  <isaacs>usualy that's enough
16:03:31  <isaacs>yeah
16:03:49  <bnoordhuis>right. owner works for most everything except timers
16:03:52  <isaacs>in a sizeable app, oyu may have something hanging around, and not really know what it is
16:04:03  <isaacs>bnoordhuis: speaking of which, unrefing a socket doesn't unref the timeout timer.
16:04:10  <isaacs>(maybe i mentioned that before? i'm still pre-coffee...)
16:04:12  <bnoordhuis>you mentioned that :)
16:04:18  <tjfontaine>and it's definitely a bug :)
16:05:29  <bnoordhuis>a regular timer isn't backed by a Timer bindings object
16:05:39  <bnoordhuis>and you probably don't want to create one for each tcp connection
16:06:33  <isaacs>bnoordhuis: right, but on http/s servers, we do socket.setTimeout(120000) or whatever
16:06:38  <isaacs>and that puts it in a list, right?
16:06:58  <isaacs>when we unref() that socket, it still keeps the event loop open
16:07:58  <tjfontaine>well regular timeouts promote to a full Timer on an .unref could do similar logic for the socket stuff
16:08:19  * TooTallNatejoined
16:08:29  <isaacs>tjfontaine: if presumably unref is rare, i guess.
16:08:32  <isaacs>on the server, at least.
16:08:39  <isaacs>and socket.setTimeout() is probably rare on the client?
16:08:49  <isaacs>i'm guessing hardly anyone ever does something other than the default.
16:09:17  <tjfontaine>unref is certainly a rare case today, and that's why the setTimeout.unref works like that
16:11:43  <bnoordhuis>we can split up lib/timers.js in user facing code and something internal that never refs
16:12:07  <bnoordhuis>i guess core never wants a timer that's attached to some other object to ref the event loop
16:12:15  <isaacs>bnoordhuis: that's a good idea.
16:12:32  <isaacs>bnoordhuis: what else do we use timers for?
16:12:40  <isaacs>i mean, for real Timer timers
16:12:58  <isaacs>we just have one for each setTimeout/Interval list, right?
16:13:07  <bnoordhuis>yeah
16:13:29  <tjfontaine>afaik net.js is the only one using the timers.active() stuff
16:13:43  <tjfontaine>actually we have 1:1 for Inteval
16:13:46  <tjfontaine>*interval
16:13:51  <isaacs>and timers.active() is pretty expensive.
16:13:59  <bnoordhuis>tjfontaine: well, until yesterday
16:14:02  * kevinswiberquit (Remote host closed the connection)
16:14:08  <isaacs>bnoordhuis: what happened yesterday?
16:14:19  <bnoordhuis>yesterday i fixed all the bugs
16:14:29  <tjfontaine>right
16:14:30  <bnoordhuis>okay okay, just one actually
16:14:35  * kevinswiberjoined
16:15:27  <bnoordhuis>isaacs: in case you're wondering: 22533c0 timers: fix setInterval() assert
16:16:14  <tjfontaine>hm did that land on v0.10?
16:16:26  <tjfontaine>I guess I didn't realize that
16:18:04  * tjfontainemakes note to keep track of target branch when reviewing
16:18:21  <bnoordhuis>hah
16:18:30  <bnoordhuis>it was a bug fix for a c++ assert
16:18:40  <bnoordhuis>hence targeted at v0.10
16:19:18  * kevinswiberquit (Ping timeout: 264 seconds)
16:19:33  <tjfontaine>right, it's just a change in what setInterval returns in the stable side, I wonder if that will freak anyone out
16:19:53  <tjfontaine>they should be interfacing with clearInterval anyway
16:21:46  <isaacs>oh, right, i did see this
16:22:59  <tjfontaine>isaacs: don't forget to update your scrum
16:23:13  <bnoordhuis>dinner, biab
16:23:42  * dannycoatesjoined
16:26:12  * indexzeroquit (Quit: indexzero)
16:26:26  * kazuponjoined
16:26:54  * kazuponquit (Read error: Connection reset by peer)
16:27:14  * kazuponjoined
16:29:03  * defunctzombie_zzchanged nick to defunctzombie
16:31:19  <isaacs>so, the sock/timer unref() thing is a simple enough bug. i'll just post it. and it's not relevant to this http stuff.
16:31:38  * nsmjoined
16:32:12  <tjfontaine>yup
16:46:32  * qardjoined
16:46:46  * csaohquit (Quit: csaoh)
16:47:55  * `3rdEdenjoined
16:50:04  * TooTallNatequit (Read error: Connection reset by peer)
16:50:59  * brsonjoined
16:55:32  * defunctzombiechanged nick to defunctzombie_zz
16:59:13  * amartensjoined
17:05:38  * TooTallNatejoined
17:11:23  * defunctzombie_zzchanged nick to defunctzombie
17:14:02  * defunctzombiechanged nick to defunctzombie_zz
17:26:12  * kevinswiberjoined
17:28:22  * kazuponquit (Remote host closed the connection)
17:50:39  <trevnorris>afternoon
17:51:01  <tjfontaine>heya
17:53:25  * AvianFlujoined
17:55:30  <trevnorris>bnoordhuis: 5489 is a strange one. that problem on master or v0.10? (or both)
18:05:15  * `3rdEdenquit (Remote host closed the connection)
18:14:58  * `3rdEdenjoined
18:23:55  * defunctzombie_zzchanged nick to defunctzombie
18:24:05  <bnoordhuis>trevnorris: tested with v0.10 but probably in master too
18:24:06  * abraxasjoined
18:28:44  * abraxasquit (Ping timeout: 252 seconds)
18:33:03  * bnoordhuisquit (Ping timeout: 260 seconds)
18:33:35  * defunctzombiechanged nick to defunctzombie_zz
18:37:32  * hueniversequit (Quit: Leaving.)
18:37:43  * hueniversejoined
18:39:27  <trevnorris>so i'm giving my first node talk next month. now that I'm the "node dude" anyone that emails mozilla about getting a node speaker are forwarded to me.
18:39:56  <amartens>could be a worse problem to have
18:40:21  <MI6>joyent/libuv: Bert Belder v0.10 * d182e45 : windows: make uv_spawn not fail under job control - http://git.io/M8O1Rg
18:41:51  <trevnorris>don't get me wrong, i'm not complaining. just new to the idea that i'd be teaching other devs about node.
18:42:34  <MI6>libuv-v0.10: #63 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/63/
18:42:36  * piscisaureus_joined
18:42:43  <tjfontaine>so we introduced a bug I see
18:42:59  <trevnorris>tjfontaine: how?
18:43:07  <tjfontaine>berts last commit
18:43:10  * kevinswiberquit (Remote host closed the connection)
18:43:34  <trevnorris>oh, to libuv
18:43:43  * kevinswiberjoined
18:45:08  <piscisaureus_>tjfontaine: very edge casey
18:45:16  <piscisaureus_>tjfontaine: but sblom mentioned it
18:45:31  <tjfontaine>piscisaureus_: sblom brought this up yesterday, I thought my test with 2k8r2 was ok
18:45:46  <piscisaureus_>isaacs: you might want to upgrade libuv again before releasing 0.10.7
18:45:59  <isaacs>piscisaureus_: kk
18:46:11  <piscisaureus_>tjfontaine: sblim should read the comments I added :)
18:46:21  <tjfontaine>hehe
18:47:15  <MI6>libuv-v0.10-gyp: #27 UNSTABLE smartos-x64 (2/186) windows-ia32 (3/187) linux-x64 (1/186) smartos-ia32 (2/186) windows-x64 (4/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/27/
18:47:57  * kevinswiberquit (Ping timeout: 256 seconds)
18:55:50  <MI6>libuv-node-integration: #58 UNSTABLE smartos-x64 (2/584) osx-x64 (1/584) osx-ia32 (1/584) http://jenkins.nodejs.org/job/libuv-node-integration/58/
18:57:23  * kevinswiberjoined
18:57:58  * `3rdEdenquit (Remote host closed the connection)
18:58:20  <trevnorris>isaacs: would you consider it a good enough change to accept if I manage to remove the slaballocator w/o any performance regression, or would you require an improvement?
18:58:47  <isaacs>trevnorris: if there's no perf regression, that's what's important.
18:58:55  <trevnorris>coolio. almost there.
18:58:58  * `3rdEdenjoined
18:58:58  <isaacs>trevnorris: improvement is great, too.
18:59:00  <isaacs>of course.
18:59:10  * c4miloquit (Remote host closed the connection)
18:59:13  * stagas_joined
18:59:55  * inolenjoined
19:00:14  <trevnorris>isaacs: so w/ the new buffer.dispose() if a dev uses that on a net stream perf increases between 15-35%. problem right now are all those tiny http headers.
19:00:22  <trevnorris>so that's creating a small regression in the http simple tests.
19:00:38  <trevnorris>working on that now
19:01:11  * stagasquit (Ping timeout: 252 seconds)
19:01:22  * stagas_changed nick to stagas
19:02:05  * trevnorris&
19:02:06  <LOUDBOT>ENGINEERS ARE NOT GOOD AT DEALING WITH CUSTOMERS
19:02:23  <tjfontaine>amen.
19:06:24  <tjfontaine>man, test-pipe-unref was just broken, I have a feeling that when I look at blame I will have to punish myself
19:06:46  <tjfontaine>but of course
19:30:02  <MI6>joyent/libuv: Bert Belder v0.10 * 4f61ab2 : windows: make uv_spawn not fail under job control - http://git.io/30_NdA
19:32:27  <MI6>libuv-v0.10: #64 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/64/
19:33:33  * benoitcquit (Excess Flood)
19:34:45  * st_lukejoined
19:37:08  <MI6>libuv-v0.10-gyp: #28 FAILURE smartos-x64 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/28/
19:37:33  * normanmjoined
19:42:43  * benoitcjoined
19:45:39  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:45:47  <MI6>libuv-node-integration: #59 UNSTABLE smartos-x64 (1/584) linux-x64 (1/584) osx-x64 (1/584) linux-ia32 (1/584) osx-ia32 (1/584) http://jenkins.nodejs.org/job/libuv-node-integration/59/
19:48:21  * bajtosquit (Quit: bajtos)
19:51:18  * TooTallNatejoined
19:54:45  * `3rdEdenquit (Remote host closed the connection)
20:00:54  * normanmquit (Quit: Computer has gone to sleep.)
20:12:43  * c4milojoined
20:15:46  * juliangruberjoined
20:17:22  * kevinswiberquit (Remote host closed the connection)
20:17:58  * kevinswiberjoined
20:22:34  * kevinswiberquit (Ping timeout: 256 seconds)
20:28:41  * trevnorrisfg
20:31:54  * stolsmaquit (Ping timeout: 264 seconds)
20:35:02  * `3rdEdenjoined
20:37:08  * trevnorrisfg
20:37:29  <tjfontaine>no really process to the foreground
20:37:37  * rendar_joined
20:37:45  <trevnorris>eh?
20:38:25  <tjfontaine>heh, poor joke, seeing you `fg` twice made me feel like you saying: "no really, damnit, why isn't my process in the foreground"
20:39:03  <trevnorris>oh, that last one went though? after I made it xchat told me I lost connection and logged in again.
20:41:02  <tjfontaine>nod
20:42:31  * rendarquit (Read error: Connection reset by peer)
20:47:50  * Ralt_joined
20:48:12  <trevnorris>right now stream_wrap converts all incoming data into a Buffer then sends it through MakeCallback. What if we gave the ability to add a cc callback to which the data is passed?
20:48:48  <trevnorris>just seems there are cases where data comes in just to be pushed right back out to cc for processing, and by shorting that loop time could be saved.
20:49:29  <tjfontaine>how does that fit in for wanting to .pipe it to multiple places?
20:50:24  <trevnorris>the cc callback would just overwrite the default functionality. so if you use it then better know what you're doing.
20:50:37  <trevnorris>also doesn't mean that makecallback can't be called, but for example
20:50:41  * KiNgMaRquit (*.net *.split)
20:50:41  * Raltquit (*.net *.split)
20:50:42  * dsantiag_quit (*.net *.split)
20:50:42  * Ralt_changed nick to Ralt
20:51:03  <trevnorris>the http headers, they are placed in a Buffer just to be sent to js, to be sent right back to cc to be parsed.
20:51:08  <trevnorris>then the Buffer is no longer used
20:51:33  <trevnorris>so if instead the data could be sent directly to the parser the Buffer would never need to be created.
20:51:58  * dsantiagojoined
20:52:57  * KiNgMaRjoined
20:53:06  <tjfontaine>I get why you want to do it, it's pretty much the same thing needed for tls
20:53:19  <trevnorris>oh, heh
20:53:29  <trevnorris>well i need it for other stuff :)
20:57:03  <tjfontaine>trevnorris: so what if instead you worked on one of the js http parsers?
20:57:56  <tjfontaine>trevnorris: I mean it's a balance, exposing a generic interface for everyone and then consuming it to show it's good, only to turn around say "ya well, we're core we'll just skip that step" :P
20:59:06  <trevnorris>lol. i understand your point. guess I figured that stream_wrap is inheritable by developers, and allowing that functionality at the cc level is ridiculously more powerful.
20:59:31  <trevnorris>being able to bypass the Buffer creation and MakeCallback call would increase potential throughput dramatically.
20:59:58  <tjfontaine>fewer boundary jumps are a net win
21:00:46  <trevnorris>yeah. also figured a generic implementation could be useful elsewhere in core.
21:01:02  <trevnorris>and to be honest it'd be useful for some of the use cases here at mozilla
21:01:54  <trevnorris>e.g. a "straight pipe" where the data is written directly out instead of first being turned into a Buffer then written back out from js again.
21:03:23  <tjfontaine>ya, those cases though are generally few, at least where you're willing to implement the work in js instead of c
21:03:41  <trevnorris>yeah
21:04:08  <tjfontaine>the tls work suffers because of excessive boundary hops into ssl, which we could "solve" with ssl in js, but that's not nearly as likely as an http parser in js
21:04:25  <trevnorris>this is more of the enterprise level (tm) usage with ridiculously high throughput.
21:04:52  <trevnorris>didn't isaacs say he was going to move all the tls stuff into cc?
21:05:09  * Benviejoined
21:05:14  <trevnorris>and I doubt a js http parser would perform as well as what's in place now
21:05:16  <tjfontaine>because you still have to interface with the ssl stuff, so fewer hops there does make sense
21:05:40  <tjfontaine>trevnorris: that's an unproven statement, it seems quite possible to make it as fast in js
21:05:48  * `3rdEdenquit (Quit: gnite sexies)
21:06:01  <tjfontaine>plus you have the jit there doing some heavy lifting for you
21:08:23  <trevnorris>accessing raw memory isn't the same as accessing an Array of Smi's, give me an hour and I'll see what I can do.
21:08:36  <tjfontaine>haha
21:09:55  <tjfontaine>there quite a few protocol parsers that perform quite admirably in js, and certainly hand tuned C can really crank out some work, but ya know we work on node
21:11:00  <trevnorris>heh, for me all that means is we create a stable user facing api. if it was more performant to do everything in cc after that i'd be ok. ;-)
21:11:55  <tjfontaine>when I was benchmarking c-ares vs my dns parsing, packets were arriving into js land at the same speed as reaching the ares code, and my interpretation of the entire packet was only a few percent slower than c-ares
21:13:13  <tjfontaine>and making buffers and streams fast[er] makes everyone happy, but I'd really hate to see us have to short circuit so hard on http
21:16:12  <trevnorris>oh this makes me hurt inside.
21:16:31  <trevnorris>ok, w/ the number of object properties that are being set in cc, a one legged cat could run faster.
21:20:14  <TooTallNate>trevnorris: hahaha
21:21:03  <TooTallNate>isaacs: is 24561 your user id?
21:21:06  <TooTallNate>on your mac?
21:21:34  <TooTallNate>i got some weird permissions changes in /usr/local/lib/node_modules/npm/test/packages/npm-test-files/.npmignore after using the .pkg installer the other day
21:21:37  <TooTallNate>isaacs: ^
21:22:02  <tjfontaine>o0
21:22:09  <trevnorris>TooTallNate: seriously dude.
21:22:36  <TooTallNate>on top of that
21:22:45  <trevnorris>tjfontaine: ok, parsing out the raw strings would be faster in cc. but setting all those properties in cc in no freaking possible way could be faster than js.
21:22:50  <TooTallNate>i was trying to `npm install -g npm` and got the permissions error
21:23:00  <TooTallNate>but by then /usr/local/bin/npm was already removed :(
21:23:07  <tjfontaine>trevnorris: accessing object properties in cc vs js isn't really a fair comparison
21:23:48  <trevnorris>tjfontaine: what? the current implementation sets all the return object properties in cc. that is so freakishly slow. there's no way a js implementation couldn't be faster.
21:24:32  <trevnorris>tjfontaine: basically, you're right. I was wrong. a js implementation here would noticably faster.
21:24:44  <TooTallNate>time for npm curl installer
21:25:52  <tjfontaine>trevnorris: heh, I have no problems agreeing that a short circuit would be make it all fast, I just worry about the precedent it sets
21:26:47  <trevnorris>tjfontaine: well, we already allow a similar thing to be done w/ Buffers. were the user can pass their own make weak callback instead of using the default.
21:27:22  <trevnorris>imo adding hooks like that adds a small amount of complexity but a large amount of customizability (is that a word?)
21:27:44  <TooTallNate>isaacs: when did you change the default log level for npm?
21:28:04  <tjfontaine>trevnorris: but those hooks are set in cc though?
21:28:19  <tjfontaine>unless we're passing around fptrs
21:28:42  <trevnorris>yeah. the buffer callback is in cc.
21:29:59  <tjfontaine>I just worry about the precedent it sets when we codify: "oh well, you should really be doing this in a module and setting this callback"
21:31:03  <trevnorris>i see it this way. basically for the 98% of users the js implementation is awesome, and still fast. but for the 2%, like what we're doing at mozilla, the ability to write cc modules w/ those types of hooks is ridiculously powerful.
21:31:17  <trevnorris>TooTallNate: you've written a massive number of modules. what's you take?
21:31:40  <TooTallNate>trevnorris: can you catch me up?
21:31:49  <tjfontaine>I guess I don't really have enough context to know what other problem you're trying to solve at mozilla that gets solved by this
21:31:50  <TooTallNate>i haven't really been paying attention atm :p
21:32:20  <trevnorris>TooTallNate: basically, stream_wrap automatically converts incoming data to a Buffer and passes it to MakeCallback.
21:32:44  <trevnorris>TooTallNate: I would like if in a cc module we could pass an override callback that is passed the raw data, then we can do what we want w/ it.
21:33:38  <TooTallNate>trevnorris: so you're using stream_wrap directly in these cc modules?
21:33:43  <trevnorris>TooTallNate: the idea is to skip pas the "create a buffer, then pass to js callback, to pass buffer to cc function, to extract data and operate on it" when we're already writing a cc module.
21:34:01  <trevnorris>TooTallNate: or TCPWrap/etc.
21:34:08  <trevnorris>they all inherit from StreamWrap
21:34:10  <TooTallNate>i see
21:34:14  <tjfontaine>why not just use uv_ directly
21:34:19  <TooTallNate>i can't say i've ever used those directly in addons
21:34:24  <TooTallNate>i pretty much just use Buffer
21:34:56  <trevnorris>tjfontaine: it's powerful to be able to create js hooks to control the flow of operations while not needing to expose the data directly to js until it's ready.
21:35:10  <tjfontaine>man trying to have your cake and eat it too :)
21:35:15  <TooTallNate>trevnorris: i'm not totally opposed, but i don't have a very strong opinion either :)
21:35:40  <trevnorris>heh
21:35:52  <trevnorris>it's my birthday this weekend. damn right i'll eat all my cake!
21:36:20  <tjfontaine>there's no reason you can't use js to control things, just that if you really care about passing from a socket directly to some other parser the libuv route seems ideal, you could even do net.connect
21:37:27  <trevnorris>tjfontaine: sorry. you have me lost. how does the libuv route help me? you mean write my own mini stream implementation?
21:38:21  <tjfontaine>trevnorris: libuv is the mini stream implementation, if the goal is to push the bytes as fast and with as little overhead as possible just use libuv in your module
21:39:26  <tjfontaine>you can either make the tcp connection entirely in your module with libuv, or you can pass the streamwrap down to the module, unwrap it and start performing the uv_read_start operations
21:39:53  <trevnorris>can you expound on the later?
21:40:01  <tjfontaine>certainly
21:40:55  <tjfontaine>so, in your js land you net.connect which returns a net.Socket that has a ._handle, which is just a TCPWrap
21:41:34  <tjfontaine>you pass that to your module, and do the ::Unwrap, and then obj->handle__ is your uv_handle_t
21:41:35  <trevnorris>following
21:41:59  <trevnorris>ok
21:42:07  <tjfontaine>or rather uv_tcp_t or whatever it's called
21:42:41  <tjfontaine>anyway, you can then call uv_read_start which will start your reading procedure, and you can do whatever you want and use what ever allocation you want
21:43:29  <trevnorris>tjfontaine: so you're saying to reimplement StreamWrap::ReadStart
21:43:58  <trevnorris>reason I like StreamWrap is it handles some of the difficult guts. like the optimizations i'm doing on memory allocations.
21:43:59  <tjfontaine>it's not reimplement so much as doing the same thing it does for uv
21:44:27  <trevnorris>basically I want everything StreamWrap is doing, except for the last step of turning the data into a Buffer automatically.
21:44:42  <tjfontaine>basically mostly the point of streamwrap :)
21:44:49  <trevnorris>lol
21:44:59  <tjfontaine>which is what I'm saying
21:45:01  <tjfontaine>go ahead
21:45:05  <tjfontaine>make the streamwrap in js
21:45:13  <tjfontaine>but just don't let js call readstart
21:46:42  <trevnorris>tjfontaine: one thing I think would be useful is allow developers to extend, say, net and do stuff like:
21:47:12  <trevnorris>var server = net.createServer(function(c) { ...
21:47:24  <trevnorris>c.transform1(); c.transform2();
21:47:52  <trevnorris>then when you receive the data it's already gone through both transformations.
21:48:11  <trevnorris>if we had a hook into streamwrap it'd be totally do-able.
21:48:42  <tjfontaine>everything you described can be done, except you wouldn't get that unless you monkeypatch'd net
21:48:51  <trevnorris>and remember that while not a lot of developer may write cc-level modules. a lot of users use modules w/ cc code.
21:49:33  <trevnorris>so the few that write cc modules can write them ridiculously well, then the masses can use them w/o worrying about all this
21:49:54  <tjfontaine>mylib.createServer = function (cb) { return net.createServer(function (s) { cb(binding.setUpTheBomb(s)); }) };
21:51:20  <trevnorris>ok, first i'm going to throw up a patch. then i'm going to work on this http_parser issue.
21:51:44  <trevnorris>since the latter would solve the http regression i'm having from removing the slaballocator
21:54:59  * AvianFluquit (Remote host closed the connection)
21:56:04  * rendar_quit
22:00:21  * c4miloquit (Remote host closed the connection)
22:06:48  * dominictarrjoined
22:14:11  * pachetquit (Quit: leaving)
22:15:55  <trevnorris>tjfontaine: imho this is a simple add that adds a lot of functionality: http://git.io/h9_33w (though excuse any c++ errors =)
22:16:11  <trevnorris>tjfontaine: also, that's only possible from my no-slaballocator branch. that sucker made life a bitch
22:17:38  * dominictarrquit (Ping timeout: 252 seconds)
22:18:27  <tjfontaine>trevnorris: ya I have no problem understanding why you want to do it, I'm just not fond of the precedent
22:18:45  <trevnorris>ok. i can respect that.
22:19:02  <tjfontaine>especially since it can be done for modules now without a change to core
22:19:53  <trevnorris>referring back to the two methods mentioned earlier?
22:19:59  <tjfontaine>ya
22:20:14  <tjfontaine>which I presume there are people already doing it that way, especially the db modules
22:20:30  <trevnorris>you'd be surprised what crazy stuff I've seen.
22:20:46  <tjfontaine>ya well, there's no accounting for taste :)
22:20:52  <trevnorris>heh
22:21:42  <trevnorris>my Buffer changes are going to break a lot of cc modules. but unfortunately there's no way around that on.
22:26:23  * bnoordhuisjoined
22:36:52  <trevnorris>bnoordhuis: mind if I get your thoughts on http://git.io/h9_33w
22:49:59  <trevnorris>anyone care to lgtm this: https://github.com/trevnorris/node/compare/fs-create-string-sym
22:55:43  <tjfontaine>trevnorris: basically it looks good to me, though I thought in general we did lazy initialization of the symbols?
22:56:37  <tjfontaine>hmm i guess we do both
22:56:54  <trevnorris>tjfontaine: don't know how the rest feel, but imho it's not worth the hassle anymore. they're a lot cheaper then they used to be
22:57:00  * c4milojoined
22:57:35  <tjfontaine>I hate it when you see a test that's germane to what you're working with fails, but then you can't recreate it
22:58:28  <trevnorris>tjfontaine: so you mean the test doesn't fail when you run it alone?
22:59:31  <tjfontaine>or with python tools/test individual multiple times, or full suite multiple times
22:59:45  <trevnorris>wtf. that's awesome.
22:59:48  <tjfontaine>then you run it in make test and it hates me
22:59:59  <trevnorris>another lgtm anyone? https://github.com/trevnorris/node/compare/add-isolate-to-prims
23:01:52  <trevnorris>isaacs: you forget some debug code in b3cf3f35?
23:02:03  <tjfontaine>heh, cute that one has False with the isolate but True without
23:02:19  <tjfontaine>seems fine to me
23:02:23  <trevnorris>coolio thanks
23:02:38  <trevnorris>merging from v0.10 to master is getting more and more complicated.
23:02:50  <trevnorris>so many little v8 syntax changes make it a pain to keep track of them all
23:03:39  <tjfontaine>nod, isaacs said he was going to work on the big merge today, hopefully we'll be able to keep up with it a bit more
23:04:12  <trevnorris>yeah! then I can get to finishing up my buffer changes. i'll be happy to have that off my plate.
23:07:31  <MI6>joyent/node: Trevor Norris master * 7998843 : fs_event: use cached Persistent syms instead (+1 more commits) - http://git.io/pQNjbg
23:17:47  <MI6>nodejs-master: #222 UNSTABLE osx-x64 (1/598) smartos-x64 (5/598) http://jenkins.nodejs.org/job/nodejs-master/222/
23:20:52  <trevnorris>tjfontaine: ^ i'll assume that's normal? (debug* tests failing)
23:21:26  <tjfontaine>without looking I'm guessing osx is test-debugger-client?
23:21:33  <trevnorris>yeah
23:21:50  <tjfontaine>ok, then unfortunately yes this is not unusual :/
23:22:11  <tjfontaine>I need to spend more time and figure out wtf is causing smartos x64 debug tests fail
23:22:13  <trevnorris>smartos it's test-debug* and test-http-client-timeout-event
23:22:32  <tjfontaine>the test-debug* scare me on x64, especially since it's only ever failing on x64
23:22:45  <tjfontaine>I'm hoping it's a v8 bug that will be fixed in the next upgrade
23:23:31  <tjfontaine>and anything *timeout* of cours is ripe for randomly failure
23:27:53  <trevnorris>tjfontaine: um. this message isn't helpful: http://jenkins.nodejs.org//job/node-pullrequest/380/DESTCPU=x64,label=linux//tapTestReport/test.tap-572/
23:28:18  <tjfontaine>heh ya I don't disagree
23:28:54  <tjfontaine>I didn't write that test, and there's not a good reason for it to fail
23:30:59  <trevnorris>tjfontaine: you know why the failed tests/tap results page take so long to come up?
23:31:47  <tjfontaine>trevnorris: basically because every time you load a tap page jenkins has to reinterpret the tap file because it doesn't cache anything
23:31:58  <trevnorris>ah, ok
23:32:23  <tjfontaine>hm I wonder
23:34:12  <MI6>nodejs-master-windows: #31 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/31/
23:34:18  <tjfontaine>oooh what did you do
23:34:36  <tjfontaine>goddamn windows
23:34:56  <trevnorris>man. give me a heart attack.
23:38:18  <trevnorris>wow. the stack trace on this is awesome: http://jenkins.nodejs.org/job/nodejs-master-windows/31/DESTCPU=x64,label=windows/consoleText
23:41:31  <tjfontaine>ya lovely java
23:41:43  <tjfontaine>so clearly you must have bsod'd windows with your build :P
23:41:59  <tjfontaine>lets kick another off and see if it happens again, what say you?
23:42:07  * stagasquit (Read error: Connection reset by peer)
23:44:59  <trevnorris>sounds good to me. that'll be great if I cause windows to explode. /s
23:45:09  <tjfontaine>heh
23:53:40  * amartensquit (Quit: Leaving.)