00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:02:27  * indexzeroquit (Quit: indexzero)
00:04:45  * bnoordhuisjoined
00:05:21  * mikealquit (Quit: Leaving.)
00:06:04  * EhevuTovquit (Quit: This computer has gone to sleep)
00:08:10  <wolfeidau>Ok time to test out v0.11.8-pre :)
00:09:04  * bnoordhuisquit (Ping timeout: 248 seconds)
00:10:18  * mikealjoined
00:13:52  * st_lukequit (Remote host closed the connection)
00:14:24  * st_lukejoined
00:18:57  * st_lukequit (Ping timeout: 252 seconds)
00:38:45  * octetcloudquit (Ping timeout: 252 seconds)
00:39:07  * M28joined
00:47:33  * AvianFluquit (Remote host closed the connection)
00:48:02  * AvianFlujoined
00:48:33  * AvianFlu_joined
00:51:45  * mikealquit (Quit: Leaving.)
00:53:02  * AvianFluquit (Ping timeout: 264 seconds)
01:05:35  * kazuponjoined
01:06:18  * kazuponquit (Remote host closed the connection)
01:06:25  * kazuponjoined
01:15:38  * groundwaterquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:16:40  * amartensquit (Quit: Leaving.)
01:27:10  * kazuponquit (Remote host closed the connection)
01:27:37  * kazuponjoined
01:32:16  * kazuponquit (Ping timeout: 264 seconds)
01:33:37  * kazuponjoined
01:36:48  * dapquit (Quit: Leaving.)
01:42:40  <wolfeidau>Is NativeBuffer an 0.11 thing?
01:42:57  <tjfontaine>so many *Buffer things
01:43:05  <tjfontaine>but yes, it is
01:49:23  * amartensjoined
01:50:03  * st_lukejoined
02:00:24  <wolfeidau>tjfontaine: master looks like it is leaking those
02:00:38  <tjfontaine>heh in your test case?
02:02:07  <wolfeidau>yeah not conclusive yet but now at 200m of ram so it is leaking something
02:02:38  <tjfontaine>joy of joys :)
02:02:40  * brsonquit (Quit: leaving)
02:03:48  <wolfeidau> 5c87182aed9 17466 0 Array
02:03:53  <wolfeidau>umm wth
02:04:34  <tjfontaine>nice
02:04:51  <wolfeidau>tjfontaine: https://gist.github.com/wolfeidau/6834170#comment-924960
02:05:20  <wolfeidau>mite be my example is broken triple checking
02:05:22  <tjfontaine>a bunch of empty objects and arrays
02:06:35  <wolfeidau>Yeah that is NO hard GC atm
02:06:43  <wolfeidau>Just out of the box
02:06:46  <tjfontaine>nod
02:08:56  * abraxasjoined
02:08:58  <wolfeidau>tjfontaine: any idea how to do lsof in solaris with the open socket output?
02:10:30  <wolfeidau>OK i have cores for that test now doing the hard gc
02:14:40  <wolfeidau>pfiles $(pgrep node)
02:14:45  <wolfeidau>win!
02:16:35  * groundwaterjoined
02:16:59  * amartensquit (Quit: Leaving.)
02:34:12  * c4milojoined
02:37:18  * st_lukequit (Remote host closed the connection)
03:15:16  * c4milo_joined
03:16:40  * mikealjoined
03:22:34  * c4miloquit (*.net *.split)
03:30:16  * indexzerojoined
03:35:08  * amartensjoined
03:36:37  <othiym23>let's see where trevnorris moved my cheese to today
03:36:52  * c4milojoined
03:36:53  * c4milo_quit (Read error: Connection reset by peer)
03:47:33  * mikealquit (Quit: Leaving.)
03:49:41  * AvianFlu_quit (Remote host closed the connection)
03:49:57  * AvianFlujoined
03:50:30  * mikealjoined
03:54:10  * AvianFluquit (Remote host closed the connection)
03:54:39  * AvianFlujoined
03:55:36  * c4miloquit (Remote host closed the connection)
04:02:52  * c4milojoined
04:10:51  * AvianFluquit (Remote host closed the connection)
04:11:20  * AvianFlujoined
04:15:54  * kazuponquit (Remote host closed the connection)
04:16:11  * AvianFluquit (Ping timeout: 260 seconds)
04:16:23  * kazuponjoined
04:17:28  * amartensquit (Quit: Leaving.)
04:20:57  * kazuponquit (Ping timeout: 252 seconds)
04:23:02  * amartensjoined
04:57:02  * kazuponjoined
05:10:19  <othiym23>the short answer is that trevnorris has not yet moved my cheese in any substantial way, just changed some wording in the docs
05:20:06  * othiym23&
05:20:07  <LOUDBOT>WHY SO FEW LOUDS TODAY?
05:35:35  * bajtosjoined
05:39:23  * mcavagequit (Remote host closed the connection)
05:39:49  * mcavagejoined
05:44:00  * mcavagequit (Ping timeout: 248 seconds)
05:46:35  * c4miloquit (Remote host closed the connection)
05:47:08  * c4milojoined
05:51:42  * c4miloquit (Ping timeout: 252 seconds)
06:14:19  * indexzeroquit (Ping timeout: 248 seconds)
06:15:24  * indexzerojoined
06:19:09  * jxsquit (Ping timeout: 240 seconds)
06:19:40  * jxsjoined
06:25:24  * klutzyjoined
06:25:54  * amartensquit (Quit: Leaving.)
06:25:57  * wwicks_joined
06:26:39  * wwicksquit (Ping timeout: 240 seconds)
06:26:39  * klutzy_quit (Ping timeout: 240 seconds)
06:26:40  * wwicks_changed nick to wwicks
06:28:13  * kazuponquit (Read error: Connection reset by peer)
06:28:40  * kazuponjoined
06:32:37  * kazuponquit (Read error: Connection reset by peer)
06:34:02  * kazuponjoined
06:35:15  * paddybyersquit (Quit: paddybyers)
06:35:21  * blissdevquit (Ping timeout: 240 seconds)
06:35:52  * indexzeroquit (Ping timeout: 264 seconds)
06:40:47  <MI6>nodejs-v0.10-windows: #248 UNSTABLE windows-ia32 (9/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/248/
06:47:11  * groundwaterquit (Quit: Textual IRC Client: www.textualapp.com)
06:48:26  * groundwater_joined
06:51:33  * paddybyersjoined
07:08:44  * paddybyersquit (Quit: paddybyers)
07:09:15  * Damn3dquit (Ping timeout: 260 seconds)
07:10:35  * mcavagejoined
07:19:39  * mcavagequit (Ping timeout: 268 seconds)
07:20:44  * Damn3djoined
08:15:00  * mcavagejoined
08:15:50  * Kakera_joined
08:18:12  * Kakera_changed nick to Kakera
08:19:40  * mcavagequit (Ping timeout: 264 seconds)
08:31:09  * blissdevjoined
08:34:31  * bnoordhuisjoined
08:36:29  * rendarjoined
08:37:11  * hzjoined
09:04:50  <kaeso>bnoordhuis: thanks for landing #942 :) as a side note, do you plan to commit the ad-interim patch for #887 before cutting 0.12?
09:14:55  <bnoordhuis>kaeso: yeah, i guess i could do that
09:15:22  * mcavagejoined
09:16:35  <kaeso>bnoordhuis: I mean, if you aren't going to rewrite it before
09:16:55  <kaeso>bnoordhuis: that would synch back rust embedded copy to libuv stable
09:17:04  <bnoordhuis>i don't think i have time for that. there's like a million other things that need to happen before node v0.12
09:17:14  <bnoordhuis>so yeah, i guess i'll just land it if it still applies :)
09:19:32  * mcavagequit (Ping timeout: 241 seconds)
09:25:21  <kaeso>bnoordhuis: ah ok, then I got the wrong impression that 0.12 was imminent
09:25:27  <MI6>joyent/libuv: Ben Noordhuis master * 5c00a0e : unix: fix SIGCHLD waitpid() race in process.c - http://git.io/88QjHg
09:26:56  <bnoordhuis>kaeso: well, i was aiming for an 0.12 release in september but then real life got in the way
09:27:59  * bajtosquit (Quit: bajtos)
09:29:24  <MI6>libuv-master: #277 UNSTABLE windows (4/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/277/
09:31:00  <MI6>libuv-master-gyp: #217 FAILURE windows-x64 (3/196) linux-ia32 (1/195) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/217/
09:46:30  <MI6>libuv-node-integration: #262 UNSTABLE smartos-x64 (7/644) smartos-ia32 (5/644) http://jenkins.nodejs.org/job/libuv-node-integration/262/
09:59:00  * Chip_Zerojoined
10:00:12  * kazuponquit (Remote host closed the connection)
10:00:39  * kazuponjoined
10:05:15  * kazuponquit (Ping timeout: 248 seconds)
10:15:43  * mcavagejoined
10:17:38  * Chip_Zeroquit (Ping timeout: 245 seconds)
10:20:11  * mcavagequit (Ping timeout: 260 seconds)
10:23:44  <bnoordhuis>https://github.com/joyent/node/issues/6271#issuecomment-25960586 <- everything is broken :-(
10:24:28  * Chip_Zerojoined
10:45:35  <MI6>nodejs-v0.10: #1522 UNSTABLE smartos-x64 (1/601) linux-x64 (1/601) osx-x64 (1/601) osx-ia32 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1522/
11:00:25  * bnoordhuisquit (Ping timeout: 268 seconds)
11:08:51  * bnoordhuisjoined
11:16:04  * mcavagejoined
11:17:35  * hzquit
11:20:36  * mcavagequit (Ping timeout: 252 seconds)
11:36:07  * piscisaureus_joined
11:40:56  * piscisaureus_quit (Read error: Connection reset by peer)
11:41:40  * piscisaureus_joined
11:52:02  * roxlu_quit (Quit: leaving)
12:14:50  * abraxasquit (Remote host closed the connection)
12:15:24  * abraxasjoined
12:16:25  * mcavagejoined
12:19:27  * hzjoined
12:19:53  * abraxasquit (Read error: Operation timed out)
12:20:33  * mcavagequit (Ping timeout: 252 seconds)
12:33:30  * c4milojoined
12:33:45  * bnoordhuisquit (Ping timeout: 252 seconds)
12:35:00  <mmalecki>indutny: ping?
13:09:10  * AvianFlujoined
13:16:45  * mcavagejoined
13:21:28  * mcavagequit (Ping timeout: 264 seconds)
13:23:22  * AvianFluquit (Remote host closed the connection)
13:23:51  * AvianFlujoined
13:28:40  * AvianFluquit (Ping timeout: 264 seconds)
13:35:49  * bajtosjoined
13:49:15  * c4miloquit (Remote host closed the connection)
13:55:24  * bnoordhuisjoined
13:57:27  * kevinswiberjoined
14:17:16  * mcavagejoined
14:21:28  * mcavagequit (Ping timeout: 240 seconds)
14:23:25  * Ralt_changed nick to Ralt
14:26:48  <bnoordhuis>the ocaml repl has this very nice feature where if you enter an invalid expression, it jumps back and highlights the incorrect part of the expression
14:27:03  <bnoordhuis>i'm going to try and port that over to node's repl
14:42:27  * AvianFlujoined
14:50:43  <tjfontaine>more often than not I wish the node repl weren't a part of core
14:51:51  <tjfontaine>bnoordhuis: sorry about 6271 btw
14:52:13  * mikealquit (Quit: Leaving.)
14:55:59  * bradleymeckjoined
14:57:33  * wwicksquit (Read error: Connection reset by peer)
14:58:37  * wwicksjoined
14:59:59  * julianduquejoined
15:00:42  * bnoordhuisquit (Ping timeout: 240 seconds)
15:02:29  <tjfontaine>indutny: is anything else you'd like me to provide for the 10.9 issue for fsevents?
15:02:58  * mikealjoined
15:03:19  * M28quit (Read error: Connection reset by peer)
15:04:27  * M28joined
15:04:34  * M28quit (Client Quit)
15:10:37  * mikealquit (Quit: Leaving.)
15:10:40  * julianduquequit (Ping timeout: 264 seconds)
15:15:16  * kazuponjoined
15:17:36  * mcavagejoined
15:19:52  <MI6>nodejs-master: #603 UNSTABLE osx-x64 (1/644) smartos-ia32 (6/644) linux-x64 (1/644) smartos-x64 (8/644) linux-ia32 (1/644) http://jenkins.nodejs.org/job/nodejs-master/603/
15:21:13  * bajtosquit (Quit: bajtos)
15:22:08  * mcavagequit (Ping timeout: 248 seconds)
15:34:29  * kevinswiberquit (Remote host closed the connection)
15:35:02  * kevinswiberjoined
15:39:28  * kevinswiberquit (Ping timeout: 264 seconds)
15:53:58  <MI6>joyent/node: Dave Pacheco v0.10 * 98c57c7 : dtrace: backport two byte string fix - http://git.io/wv04Xw
15:56:27  * bajtosjoined
15:57:09  * AvianFlu_joined
15:58:01  * AvianFluquit (Disconnected by services)
15:58:04  * AvianFlu_changed nick to AvianFlu
15:58:54  * wolfeidauquit (Ping timeout: 264 seconds)
15:59:32  * mikealjoined
16:02:29  <MI6>joyent/libuv: Reini Urban master * b0bb8de : .gitignore: fix .deps/, add .dirstamp - http://git.io/Z_5Hcg
16:03:39  * bnoordhuisjoined
16:03:48  <bnoordhuis>and back again
16:03:53  <bnoordhuis>tjfontaine: sorry for what?
16:04:21  <MI6>nodejs-v0.10: #1523 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) linux-ia32 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1523/
16:05:12  <tjfontaine>your "it's all broken" comment
16:05:33  * wolfeidaujoined
16:05:51  <bnoordhuis>ah well, fixing things up is a way to make a living
16:06:00  <tjfontaine>heh
16:06:51  <MI6>libuv-master: #278 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/278/
16:07:17  * TooTallNatejoined
16:07:21  <bnoordhuis>i'll probably make libuv unregister pipe fds explicitly in the future
16:07:40  <bnoordhuis>requires a bit of work sadly but such is life
16:07:51  <tjfontaine>work is overrated
16:08:21  <tjfontaine>back to figuring out this ssl truncation I guess
16:08:27  <bnoordhuis>in v0.10?
16:08:33  <tjfontaine>no, master
16:08:35  <MI6>libuv-master-gyp: #218 FAILURE windows-x64 (8/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/218/
16:08:41  <tjfontaine>I really want to release 0.11 :<
16:08:47  <bnoordhuis>ah, there as well?
16:08:53  <bnoordhuis>i guess everything is indeed broken :-/
16:09:06  <tjfontaine>yes. the world is falling apart at the seams
16:10:19  <bnoordhuis>quite. let me tell you about wireless printer drivers...
16:10:28  <bnoordhuis>i admit i understand RMS's motivation a lot better now
16:10:45  <tjfontaine>hah
16:10:52  <tjfontaine>wireless * drivers
16:11:00  <MI6>nodejs-v0.10-windows: #249 UNSTABLE windows-ia32 (11/601) windows-x64 (11/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/249/
16:11:57  * defunctzombie_zzchanged nick to defunctzombie
16:13:17  * defunctzombiechanged nick to defunctzombie_zz
16:14:25  * defunctzombie_zzchanged nick to defunctzombie
16:18:49  * dapjoined
16:23:51  <MI6>libuv-node-integration: #263 UNSTABLE smartos-x64 (7/644) smartos-ia32 (5/644) http://jenkins.nodejs.org/job/libuv-node-integration/263/
16:26:54  * kazuponquit (Remote host closed the connection)
16:27:21  * kazuponjoined
16:32:07  <trevnorris>tjfontaine: virtual hug
16:32:16  * kazuponquit (Ping timeout: 264 seconds)
16:32:19  <trevnorris>you gave me some ideas
16:32:23  <tjfontaine>I did?
16:32:24  <tjfontaine>:)
16:32:41  <trevnorris>for everyone: should this async listener stuff be on process, or should it be it's own module?
16:40:55  * brsonjoined
16:44:35  * hzquit
16:46:25  * TooTallNatequit (Quit: Computer has gone to sleep.)
17:01:36  * mikealquit (Quit: Leaving.)
17:04:47  * TooTallNatejoined
17:07:01  * amartensjoined
17:08:10  * kevinswiberjoined
17:09:00  * st_lukejoined
17:11:30  * nrajlichjoined
17:12:50  * TooTallNatequit (Ping timeout: 264 seconds)
17:13:04  * bnoordhuisquit (Ping timeout: 248 seconds)
17:18:10  <trevnorris>wtf. since the upgrade to 3.20.14.1, allocations through smalloc are +30% slower
17:18:19  * mcavagejoined
17:21:04  <trevnorris>btw, whats we gonna do bout the ddos thing?
17:21:14  <tjfontaine>*dos
17:21:25  <tjfontaine>let's refer to it from here as 6214 :)
17:21:25  <trevnorris>dddddddddddddddddddddddddddox
17:21:26  <trevnorris>s
17:21:55  <trevnorris>well, how we going to fix 6214
17:22:28  * mcavagequit (Ping timeout: 240 seconds)
17:22:39  <tjfontaine>isaacs and I discussed it yesterday, just a matter of getting in there and implementing, it shouldn't be too bad -- I was on the right track before but just wasn't as correct as I could have been
17:23:54  * bradleymeckquit (Quit: bradleymeck)
17:24:28  <isaacs>trevnorris: i'll have a pr soon
17:24:33  <trevnorris>coolio
17:24:51  <trevnorris>i'm just peeved that v8's making my code slower.
17:24:59  <isaacs>trevnorris: any idea why?
17:25:09  <isaacs>trevnorris: also, what's the net impact on node?
17:26:05  <trevnorris>isaacs: haven't done a full analysis. probably not much at the macro level. just mad it added another 100ns to my smalloc impl.
17:26:06  <trevnorris>went from 200ns for 1 byte smalloc to 300ns!
17:27:26  * st_lukequit (Read error: Connection reset by peer)
17:27:50  <othiym23>trevnorris: if I get a vote, I want it on process
17:28:26  <trevnorris>othiym23: okidoki.
17:28:36  <othiym23>I buy piscisaureus_'s argument that there's a lot of rando stuff on process already, but there's not really a good module to put it in
17:28:56  * kevinswiberquit (Remote host closed the connection)
17:28:59  <othiym23>I guess I wouldn't barf if it ended up in async_listener either, although that complicates things for the polyfill
17:29:17  <tjfontaine>it would be _hidden I thinkk
17:29:19  <othiym23>the fact you can't have hyphens in module names that are built into the snapshot is sorta a pain
17:29:20  <trevnorris>othiym23: was just thinking, a useful thing would be to create a tracker for constructions/destructors and you could call, like, require('async-listener').count();
17:29:28  * kevinswiberjoined
17:29:34  <trevnorris>and it would give you the number of alive
17:30:06  <othiym23>yeah, but then we have to update that counter, which seems like it could be slow
17:30:20  <trevnorris>othiym23: are you kidding? this is me you're talking to :P
17:30:59  <trevnorris>it's simple. you set a counter on the env, which the AsyncWrap class already has a pointer to. then you increment/decrement accordingly.
17:31:01  <tjfontaine>othiym23: I think you slappedhim
17:31:42  <trevnorris>you pass in an object and assign a uint32_t* as external memory, then set a simple function to return async_listener_info[kCount];
17:31:45  <othiym23>whoops
17:31:50  <othiym23>sorry trevnorris, I take it back
17:31:56  <othiym23>you would never make anything slow ever
17:32:03  <trevnorris>damn right! ;)
17:32:12  <othiym23>yeah, I guess I was mostly just thinking about the polyfill there
17:32:21  <othiym23>I can do it, and I guess it won't be super expensive
17:32:25  <trevnorris>heh
17:33:46  * kevinswiberquit (Ping timeout: 245 seconds)
17:34:18  * kevinswiberjoined
17:34:40  <othiym23>so yeah, if we're going to but the asyncListener stuff in a module, we should choose a name for the module that is unclaimed so I can use it for the polyfill
17:34:53  <othiym23>but it would be simpler for me as the polyfill maintainer if we put it on process
17:35:00  <trevnorris>but, you're saying we can't use "-" in a native module?
17:35:29  <othiym23>trevnorris: yeah, it won't build, I think maybe it's a gyp or build process issue
17:35:40  <trevnorris>well we need to fix it!
17:35:43  <tjfontaine>meh
17:35:53  <tjfontaine>do we really need a module with -'s in it at the moment?
17:36:10  <trevnorris>well, it's part of my grand scheme in v0.13!!!
17:36:40  <trevnorris>*maniacal laugh*
17:36:48  <tjfontaine>no, we're nod flooding the native module list :)
17:36:51  <tjfontaine>*not
17:37:01  <trevnorris>right... you say that now.
17:37:06  * trevnorriswaits patiently
17:37:19  <tjfontaine>this is going somewhere hilarious
17:37:50  * kazuponjoined
17:37:51  <trevnorris>dude, i've been planning v0.13 for months.
17:38:20  <tjfontaine>I know, but I'm not sure how/why we would just start dumping more things in the module namespace when can just use a getter function
17:38:38  <trevnorris>it's much deeper than that.
17:38:55  * bradleymeckjoined
17:42:48  * kazuponquit (Ping timeout: 240 seconds)
17:53:03  * mikealjoined
17:53:28  <MI6>libuv-master: #279 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/279/
17:53:49  <trevnorris>tjfontaine: what do you think about this? https://github.com/trevnorris/node/compare/smalloc-augment
17:54:01  <trevnorris> /cc othiym23 ^
17:54:45  <tjfontaine>hm
17:55:03  <tjfontaine>I'm not terribly opposed in principle, I want to figure out a nicer way to genericize it
17:56:00  <tjfontaine>because it already matches how we do some of that perfcounter stuff
17:56:30  <trevnorris>yeah, but I have one more commit that I'm _sure_ you're going to love. ;P
17:57:31  <othiym23>trevnorris: what's the idea behind lines 27 and 28 of lib/smalloc.js?
17:57:55  <othiym23>i.e. why bother putting it on process if you're just going to nuke it as soon as the module gets loaded?
17:58:37  <trevnorris>othiym23: check out 2557 of src/node.cc
17:58:37  <othiym23>trevnorris: I'm with tjfontaine, I think it's a useful metric to have, but it seems like the implementation is a little ad hoc
17:58:57  <trevnorris>it's the easiest way of attaching an internal method
17:59:04  <othiym23>OK!
17:59:10  <othiym23>seems kinda rando to me, but what do I know
17:59:28  <trevnorris>well, i'll rethink it when I have more brain cells to spare.
17:59:28  * brsonquit (Ping timeout: 248 seconds)
17:59:38  <othiym23>also do we want to be deleting stuff off process?
18:00:04  * defunctzombiechanged nick to defunctzombie_zz
18:00:14  <othiym23>I mean, I guess there probably aren't a whole lot of hot paths taking process as a parameter, but my understanding is it's genearlly better to assign undefined so you don't mess with the hidden class
18:00:18  <trevnorris>i'm just adding that stuff to appease piscisaureus_
18:00:22  <othiym23>(speaking of total micro-optimizations)
18:00:24  * brsonjoined
18:00:47  <trevnorris>eh, ok.
18:01:15  <trevnorris>there is a better way to do all this, but haven't gotten around to it yet.
18:01:36  * hzjoined
18:01:39  <trevnorris>e.g. SetupSmalloc resides in src/smalloc.cc and exported through the process.binding('smalloc')
18:01:51  <trevnorris>hm. why didn't I just do that. :P
18:02:29  * dominictarrjoined
18:05:48  <trevnorris>othiym23: there, how it should have been done: https://github.com/trevnorris/node/compare/smalloc-augment
18:06:11  * st_lukejoined
18:06:45  <trevnorris>now, for my devious plan
18:07:02  <othiym23>trevnorris: thumbs up
18:07:47  <trevnorris>got one more insane commit. the sort of stuff that gives me goosebumps.
18:10:43  <MI6>libuv-node-integration: #264 UNSTABLE smartos-x64 (7/644) smartos-ia32 (5/644) http://jenkins.nodejs.org/job/libuv-node-integration/264/
18:11:39  <othiym23>such an excellent salesman for controversial ideas
18:12:13  <tjfontaine>we should totally do this better https://github.com/trevnorris/node/compare/smalloc-augment#diff-6f9c1a7b44db3038aba2a445b51edac2R37
18:12:23  <tjfontaine>we shoudl export the constants on the module instead
18:12:37  <tjfontaine>so you kCount = bidning.kCount
18:12:51  <tjfontaine>then there's less worry about shit getting out of sync
18:12:59  <trevnorris>note taken :)
18:15:03  <tjfontaine>I also wonder if really this shouldn't be information we're messaging into process.memory()
18:15:08  <tjfontaine>*memoryUsage
18:15:35  <trevnorris>whatevs
18:16:17  <trevnorris>i mean, the info _is_ available when you take a heap dump. but having it immediately available seemed useful.
18:16:35  <trevnorris>and the bits are there. so wherever you want to put it
18:16:55  <tjfontaine>you haven't heard me complain about the information, just where and how we're collecting it :)
18:17:23  <trevnorris>yeah
18:17:47  <trevnorris>i'm just in my little mad scientist lab right now. almost done and ready to commit :)
18:18:48  * mcavagejoined
18:21:56  * wwicksquit (Quit: I'm sure we'll meet again)
18:23:10  * AvianFluquit (Remote host closed the connection)
18:23:13  * bnoordhuisjoined
18:23:48  * mcavagequit (Ping timeout: 268 seconds)
18:24:32  * AvianFlujoined
18:26:44  * st_lukequit (Read error: Connection reset by peer)
18:35:52  <trevnorris>wtf. how is it possible to not have a backtrace?
18:36:14  <tjfontaine>from what?
18:36:27  <othiym23>RangeError?
18:36:27  <trevnorris>just ran a script w/ gdb --args and when I type bt, says no stack
18:36:33  <trevnorris>no, c++ abort
18:36:36  <othiym23>oh
18:36:37  <tjfontaine>you crapped on your stack :P
18:36:43  <trevnorris>heh
18:36:59  <tjfontaine>you dropped trou and laid a cleveland steamer right on it
18:37:04  <trevnorris>hah
18:37:09  <trevnorris>ok. so maybe this is a little _too_ experimental
18:37:14  <trevnorris>but been wanting to try it out for a while.
18:37:18  <tjfontaine>gist?
18:38:01  <trevnorris>tjfontaine: https://gist.github.com/trevnorris/6905980
18:38:19  <trevnorris>basically, I'm writing to external memory right before calling the function and retrieving the value from memory
18:38:29  <trevnorris>instead of needing to use ToUint32()
18:38:47  * kevinswiberquit (Remote host closed the connection)
18:39:22  * kevinswiberjoined
18:41:28  <trevnorris>eh, figured out what I did wrong
18:41:44  <trevnorris>um. nope. guess I didn't
18:43:47  * kevinswiberquit (Ping timeout: 245 seconds)
18:45:16  * kevinswiberjoined
18:45:53  <trevnorris>there we go.
18:46:02  <trevnorris>ah holy hell. that made it soooo much slower.
18:46:14  <trevnorris>oh well, wanted to try it out. now I know.
18:46:47  * st_lukejoined
18:47:36  <trevnorris>bnoordhuis: you have any moral opposition to something like this? https://github.com/joyent/node/pull/6323
18:48:43  <MI6>nodejs-master-windows: #397 UNSTABLE windows-x64 (23/644) windows-ia32 (21/644) http://jenkins.nodejs.org/job/nodejs-master-windows/397/
18:49:07  <amartens>interesting
18:51:17  * dapquit (Quit: Leaving.)
18:56:46  * indexzerojoined
18:58:33  <bnoordhuis>trevnorris: i guess my first question would be 'why?'
18:58:41  <bnoordhuis>as in, 'why keep track of that'?
18:59:05  <trevnorris>bnoordhuis: I dunno. thought of it while showering and wanted to see if I could. :)
18:59:32  <trevnorris>part of it stemmed from tjfontaine's opinion that we should track the number of beforeExit's that've been called
18:59:52  <trevnorris>and I though, hey, why not allow quick access to the number of living smalloc objects
19:00:42  * st_lukequit (Read error: Connection reset by peer)
19:01:01  * dapjoined
19:01:28  <trevnorris>bnoordhuis: I honestly don't care. think all this asyncwrap implementation for helping debugging is getting to me...
19:01:39  <trevnorris>damn you othiym23 and your cls!
19:02:05  <amartens>tracking things is interesting
19:02:38  <trevnorris>yeah, but as tjfontaine mentioned it'd be simple to place a couple dtrace macros in there or the like
19:02:55  <trevnorris>then we wouldn't need to add so much extra code
19:03:09  <amartens>dtrace isn't available on all platforms that support node, AFAIK?
19:03:56  <trevnorris>no
19:03:58  <amartens>if you're already going through the steps to put something in there, why not try to make it available to everyone who uses node?
19:04:26  <amartens>I mean, if you can do it with minimal performance implications
19:05:10  <trevnorris>everything I do has ZERO performance implications!!! ;)
19:05:35  <bnoordhuis>trevnorris: yeah, that beforeexit tracking thing... it seems kind of pointless
19:05:41  <trevnorris>bnoordhuis: i agree
19:05:53  <bnoordhuis>tjfontaine: ^
19:06:20  <trevnorris>but then I though in my sleepy stupor this morning, if we're going to track one thing, why not track all the things!
19:07:40  * wwicksjoined
19:07:44  <bnoordhuis>alternatively, we could track nothing and call it a day
19:08:00  <trevnorris>i LIKE it
19:08:48  <bnoordhuis>amartens: you can use the dtrace tracing infrastructure with systemtap on linux and etw on windows
19:09:18  <trevnorris>tracking c++ stuff manually seems silly. should be possible to analyze externally, right?
19:09:36  <trevnorris>stuff, as is method calls and such
19:12:19  <bnoordhuis>yeah, tools like systemtap and perf can do that
19:19:12  * mcavagejoined
19:21:56  * bajtosquit (Quit: bajtos)
19:23:51  * mcavagequit (Ping timeout: 260 seconds)
19:28:15  <tjfontaine>if we're going to provide a mechanism that allows ressurecting a node process at will, then I think it's absolutely critical we keep the information around about that
19:28:32  <tjfontaine>the fact that you can observe it at run time is important, but not quite the same from a post mortem standpoint
19:31:02  <tjfontaine>you can observe information about smalloc in a core dump, but we only have findjsobjects for mdb at the moment, so if you didn't happen to tkae a heap dump right before you abort()d
19:32:09  <trevnorris>tjfontaine: other than a simple counter that says "we resurrected X times before exiting", what are you wanting to track?
19:32:36  <tjfontaine>at the moment that's all I really care about for that particular feature
19:33:09  <trevnorris>and I guess what I don't understand is what good that value alone will tell you.
19:33:46  <tjfontaine>when you're sitting there with a shitpile of a coredump you never know what will help
19:34:06  <tjfontaine>so if it's within our power to keep that information around without much effort I dont' see why not
19:34:26  * dominictarrquit (Quit: dominictarr)
19:34:54  <trevnorris>for some reason I can hear your enthusiastic voice in my head as I read that.
19:35:01  <tjfontaine>heh
19:39:15  <trevnorris>guess i'm of two opinions, don't start tracking it until you know it would've been useful (more on why I feel that way in a second), and have guidelines-ish for what you will track.
19:39:15  <trevnorris>first is because of a mozilla thing called telemetry. they place probes in fx to know what it's doing. right now I think they have ~600. our statisticians proved that they could get the same info out of only 30 or so.
19:39:49  <trevnorris>and I was on the metrics team before working on node, and had to listen to the statisticians bitch about that quite often.
19:40:18  <trevnorris>second, i'm tired of seeing random debug() what not in core because at one time someone decided they needed it while doing a specific thing.
19:40:46  * EhevuTovjoined
19:40:50  <trevnorris>but if we did a proper trace of the logic then we'd be able to find the more correct places for those things.
19:43:18  * piscisaureus_quit (Ping timeout: 253 seconds)
19:44:08  * wwicks_joined
19:45:39  <trevnorris>tjfontaine: but i'd agree. _if_ we are going to track metrics internally (which I'm not saying we should) then there should be a single class in env.h that centralizes all those metrics.
19:46:15  * wwicksquit (Ping timeout: 260 seconds)
19:46:16  * wwicks_changed nick to wwicks
19:47:03  * EhevuTovquit (Quit: This computer has gone to sleep)
19:48:05  * EhevuTovjoined
19:49:34  * dominictarrjoined
20:01:05  * st_lukejoined
20:05:22  <trevnorris>bnoordhuis: ping
20:05:32  * wwicks_joined
20:06:24  * wwicksquit (Ping timeout: 248 seconds)
20:06:25  * wwicks_changed nick to wwicks
20:07:03  <bnoordhuis>trevnorris: pong
20:08:12  <trevnorris>bnoordhuis: if all the v8 handles in a method are of the form: Local<Object> = args[0].As<Object>(); (i.e. cast instead of creating a new handle) do you still need a HandleScope?
20:08:41  <bnoordhuis>trevnorris: no
20:08:48  <trevnorris>bnoordhuis: cool. thanks :)
20:13:15  * st_lukequit (Read error: Connection reset by peer)
20:14:11  * mcoffeejoined
20:15:32  <trevnorris>bnoordhuis: I still see a lot of strings created using FIXED_ONE... do you just want the ones that'll be called "often" in env.h?
20:16:54  <bnoordhuis>trevnorris: yes, only those
20:17:01  <trevnorris>coolio.
20:17:08  <bnoordhuis>where "often" is a somewhat loosely defined metric but ala
20:17:16  <trevnorris>yeah, I know what you mean
20:19:32  * mcavagejoined
20:20:09  * sblomjoined
20:21:48  <trevnorris>bnoordhuis: so what you been working on? staying awake and feeding the baby? :)
20:24:14  * mcavagequit (Ping timeout: 264 seconds)
20:25:37  <bnoordhuis>trevnorris: this week? been toying around with various approaches to profiling, thinking about how to improve event handling in libuv, triaging bug
20:25:40  <bnoordhuis>*bus
20:25:43  <bnoordhuis>damnit
20:25:48  <bnoordhuis>mac keyboards... *bugs
20:25:53  <trevnorris>heh
20:26:07  * wwicks_joined
20:26:43  <trevnorris>sounds like fun. let me know if you come up with any cool ways for profiling.
20:27:07  * wwicksquit (Ping timeout: 248 seconds)
20:27:08  * wwicks_changed nick to wwicks
20:29:01  * mralephjoined
20:30:02  <bnoordhuis>trevnorris: i have js function tracing working actually, only it's something you need to enable at startup and it's hella slow
20:30:28  <bnoordhuis>i was aiming more for something like dtrace/stap, where you can create and remove trace points at run time
20:30:47  <trevnorris>oh cool. have the code up somewhere?
20:30:58  <bnoordhuis>i must have, let me look
20:31:27  <bnoordhuis>trevnorris: https://github.com/bnoordhuis/node/tree/function-tracer <- attempt #1
20:32:56  <tjfontaine>right it uses the jit hooks
20:33:54  <trevnorris>oh interesting.
20:34:59  <bnoordhuis>somewhat. most events take place in v8 stubs and builtins :)
20:35:13  <bnoordhuis>smarter filtering is in order
20:35:59  <bnoordhuis>i'm toying with another approach where i'm putting breakpoints in the function prolog of generated code
20:36:14  <tjfontaine>*that* is how dtrace works :)
20:36:19  <tjfontaine>well more or less
20:36:33  <bnoordhuis>yeah, but dtrace has kernel assistance
20:36:52  <tjfontaine>sure, but doesn't this make sense to have generic support from v8 directly?
20:36:53  <bnoordhuis>poor old me has to work with creative uses of mmap and sigaction(SIGTRAP)
20:36:55  * nrajlichquit (Quit: Computer has gone to sleep.)
20:37:05  <trevnorris>heh
20:37:20  <bnoordhuis>tjfontaine: well, yes. but i haven't really come up with a workable scheme yet
20:37:29  <trevnorris>and here I thought my implementation of asyncwrap was all cool. this kicks its ass.
20:37:46  <bnoordhuis>also, i don't want to wait 6-9 months for it to land in a stable release
20:38:23  <trevnorris>bnoordhuis: oh, so think you could land this in a module?
20:39:41  <bnoordhuis>well, you'll probably need _some_ assistance from core
20:41:13  * TooTallNatejoined
20:45:37  * wwicks_joined
20:45:55  <MI6>joyent/node: Ben Noordhuis v0.10 * 9777890 : tls: fix premature connection termination - http://git.io/V_dHkw
20:47:23  * wwicksquit (Ping timeout: 260 seconds)
20:47:24  * wwicks_changed nick to wwicks
20:51:41  * c4milojoined
20:52:32  * indexzeroquit (Quit: indexzero)
20:53:46  <trevnorris>whoa, wtf.
20:54:06  <wolfeidau>Found something interesting in mdb today, https://gist.github.com/wolfeidau/6882870#comment-925383 note the empty entry in the list
20:54:38  <tjfontaine>wolfeidau: 362e7006a61::v8print please and thank you
20:54:59  <trevnorris>External::New(void*).As<Object>()->SetIndexedPropertiesToExternalArrayData(...);
20:54:59  <trevnorris>bnoordhuis: ^ that actually worked. but... eh, whatever.
20:56:00  <bnoordhuis>trevnorris: yeah, an External is-a kind of Object
20:56:07  <MI6>nodejs-v0.10: #1524 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1524/
20:56:33  <trevnorris>bnoordhuis: yeah, just didn't think it would since the inheritance doc shows it's from Value, not Object.
20:56:40  <wolfeidau>https://gist.github.com/wolfeidau/6882870#comment-925387
20:57:07  <trevnorris>bnoordhuis: guess what I find most interesting is that a returned External can't have any properties assigned to it.
20:57:31  <wolfeidau>tjfontaine: So your using a v8 type somewhere in native code?
20:57:40  <bnoordhuis>right, the fact it's an object is an implementation detail
20:57:41  <wolfeidau>hence this missing name?
20:57:48  <wolfeidau>aha
20:57:48  <tjfontaine>wolfeidau: we'll we're inspecting v8 types
20:58:03  <trevnorris>bnoordhuis: interesting. but you'd consider that code unsafe?
20:58:18  <wolfeidau>yeah i found those commands
20:58:25  <wolfeidau>very handy
20:58:28  <tjfontaine>indeed
20:58:46  <bnoordhuis>trevnorris: yes-ish. relies on implementation details. the reason external hides the fact that it's an object, is that it's safe to pretenure that way
20:59:05  <bnoordhuis>trevnorris: by which i mean that v8 can safely put it in the old space because there's no way it has backrefs to objects in the new space
20:59:10  * indexzerojoined
20:59:30  * sam113101joined
20:59:37  <sam113101>HELLO
20:59:56  <trevnorris>bnoordhuis: interesting. thanks for the explanation.
21:00:19  <bnoordhuis>sam113101: HELLO YOURSELF HANDSOME
21:00:43  <MI6>joyent/node: isaacs v0.10 * 9c65387 : blog: Remove wp-to-markdown script - http://git.io/vKBUyw
21:00:45  <sam113101>what's libuv?
21:01:03  <bnoordhuis>if you have to ask that question, this channel is probably not for you
21:01:24  <sam113101>is it just a wrapper around epoll/kqueue or is it more than that?
21:01:41  <trevnorris>sam113101: http://nikhilm.github.io/uvbook/introduction.html
21:02:50  <trevnorris>sam113101: also might be of interest: http://stackoverflow.com/questions/11423426/how-does-libuv-compare-to-boost-asio
21:02:54  <trevnorris>though it's a little dated.
21:03:58  <sam113101>never used boost/asio
21:05:09  <wolfeidau>tjfontaine: So this whole TLS part of node must have some crzy complicated code paths as v8 seems to be doing a lot of work to GC it
21:05:23  <tjfontaine>wolfeidau: especially in v0.10
21:05:44  <tjfontaine>it's a better story in master, when -- ya know -- it's not truncating your streams.
21:06:11  * wwicks_joined
21:06:13  <wolfeidau>tjfontaine: Well interestingly they both balloon out in the same fashion when not gc'ing the shit out of it
21:06:19  <sam113101>I want to build a game server and I was wondering if libuv would be appropriate
21:06:28  <tjfontaine>wolfeidau: that is interesting
21:06:32  <wolfeidau>Probably more so in master from what i have observed
21:07:23  <MI6>nodejs-v0.10-windows: #250 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/250/
21:07:48  * wwicksquit (Ping timeout: 240 seconds)
21:07:48  * wwicks_changed nick to wwicks
21:09:18  <sam113101>does libuv implement the reactor pattern?
21:10:06  <wolfeidau>tjfontaine: This is master without gc https://gist.github.com/wolfeidau/6882870#comment-925392
21:10:07  <bnoordhuis>sam113101: yes. we're even mentioned on the 'reactor pattern' wikipedia page :)
21:10:31  <wolfeidau>tjfontaine: note our 24 empty entries are also there
21:10:33  <sam113101>oh
21:11:24  <MI6>nodejs-v0.10: #1525 UNSTABLE smartos-x64 (5/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1525/
21:11:40  <tjfontaine>wolfeidau: I will generate a new v8.so which won't necessarily solve that, but may provide some more insight
21:12:54  <wolfeidau>tjfontaine: Looks to me like it is loading something via a stream but what struck me was "5c8718a5fe1 1261 13 Agent: domain, _events, _maxListeners, ..."
21:13:20  <wolfeidau>I am disabling the agent https://gist.github.com/wolfeidau/6882870#file-httpstest3-js-L33
21:13:26  * hzquit
21:13:44  <sam113101>does libuv use multithreading?
21:13:54  <wolfeidau>why would there be 1261 of them hanging around
21:14:03  <bnoordhuis>sam113101: for some things, yes
21:14:46  <sam113101>like eh, deferrables? if there's such a thing on libuv
21:15:23  * lukjoined
21:15:36  <tjfontaine>wolfeidau: what's ::jsprint on the object with no constructor?
21:15:40  <tjfontaine>*no named constructor
21:17:04  <bnoordhuis>sam113101: no, nothing like that. libuv uses unadorned callbacks. it's just that some things are handed off to a thread pool (file operations, getaddrinfo lookups, etc.)
21:17:09  <wolfeidau>tjfontaine: {}
21:17:14  <wolfeidau>that is it lol
21:17:25  <bnoordhuis>sam113101: the thread pool is used for things that you can't do without blocking
21:17:28  <tjfontaine>wolfeidau: thanks :)
21:17:34  <sam113101>ok
21:18:10  <sam113101>I'm not yet familiar with the reactor pattern
21:19:05  <bnoordhuis>sam113101: you register interest for events, you call the 'enter event loop' function, the library starts calling your callbacks whenever those events happen
21:19:12  <bnoordhuis>that's basically all there is to it
21:19:54  * mcavagejoined
21:20:21  <tjfontaine>wolfeidau: could you try: 12303bf04139::v8array | ::jsprint
21:22:57  <wolfeidau>tjfontaine: returns nothing
21:23:14  <tjfontaine>wolfeidau: alright, this is part of us needing to fix it for the newer version of v8
21:23:28  <wolfeidau>aha
21:23:50  * EhevuTovquit (Quit: This computer has gone to sleep)
21:24:22  * st_lukejoined
21:24:28  * sblomquit (Ping timeout: 240 seconds)
21:24:39  * rendarquit
21:24:42  * mcavagequit (Ping timeout: 264 seconds)
21:26:29  * st_lukequit (Read error: Connection reset by peer)
21:26:36  * wwicks_joined
21:27:13  * lukchanged nick to st_luke
21:27:41  <bnoordhuis>about to sign off. if anyone has questions for me, now's the time
21:27:46  <trevnorris>bnoordhuis: was running libuv's pipe_pump benchmark. couldn't believe how fast it was.
21:28:11  <bnoordhuis>ah well, most of that is courtesy of the kernel
21:28:12  <trevnorris>i'm trying to implement something directly on top of pipe_wrap to see how fast I can get node
21:28:16  <trevnorris>heh
21:28:27  * wwicksquit (Ping timeout: 248 seconds)
21:28:28  * wwicks_changed nick to wwicks
21:28:29  <MI6>nodejs-v0.10-windows: #251 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/251/
21:28:43  <trevnorris>alright man. you have a good night :)
21:28:56  * indexzeroquit (Quit: indexzero)
21:29:02  <bnoordhuis>thanks, you too :) okay, stepping away from the keyboard
21:29:04  * sblomjoined
21:32:30  * indexzerojoined
21:37:04  * dominictarrquit (Quit: dominictarr)
21:40:45  * kevinswiberquit (Remote host closed the connection)
21:41:11  <trevnorris>are uv_pipe_{open,bind,connect} all accomplish the same thing, just with different function parameters?
21:41:21  * kevinswiberjoined
21:44:15  * kevinswi_joined
21:44:49  * kevinswiberquit (Read error: Connection reset by peer)
21:48:03  * bnoordhuisquit (Ping timeout: 260 seconds)
21:50:19  * EhevuTovjoined
21:51:30  * bnoordhuisjoined
21:57:15  <indutny>hey people
21:57:24  <indutny>looks like I'm finally a bit back to core dev
21:57:31  <indutny>anything important I should take care of?
21:57:33  <indutny>bnoordhuis: ^
21:57:51  <trevnorris>he's away for the night.
21:58:22  <trevnorris>you can help me figure out wtf the order is to create a pipe directly on top of pipe_wrap. :P
22:01:56  * inolenquit (Quit: Leaving.)
22:02:06  * Kakeraquit (Ping timeout: 245 seconds)
22:04:16  * mikealquit (Quit: Leaving.)
22:04:53  <indutny>trevnorris: hrm?
22:05:13  * mikealjoined
22:06:01  <trevnorris>indutny: oh, i'm just trying to create a pipe directly using pipe_wrap, and the node semantics are strange.
22:06:47  <trevnorris>think I got it.
22:07:54  <indutny>heh
22:07:55  * wwicks_joined
22:09:00  * AvianFlu_joined
22:09:00  * AvianFlu_quit (Remote host closed the connection)
22:09:02  <indutny>trevnorris: yeah, you just create new (process.binding('pipe_wrap').Pipe)
22:09:09  <indutny>trevnorris: and connect it to path
22:09:12  <indutny>or do whatever you want
22:10:03  <indutny>write2
22:10:08  <indutny>or any other stuff
22:10:08  * wwicksquit (Ping timeout: 248 seconds)
22:10:09  * wwicks_changed nick to wwicks
22:10:12  <indutny>trevnorris: is that what you want?
22:10:15  <trevnorris>yeah
22:11:26  <trevnorris>so, uv_pipe_bind open a new fd, while uv_pipe_open connects to an existing fd?
22:12:17  * bradleymeckquit (Quit: bradleymeck)
22:13:04  * AvianFluquit (Ping timeout: 264 seconds)
22:15:26  <indutny>yes
22:15:32  <trevnorris>coolio. thanks.
22:16:02  <indutny>np
22:20:25  * mcavagejoined
22:21:06  * kevinswi_quit (Remote host closed the connection)
22:21:41  * kevinswiberjoined
22:24:32  * mcavagequit (Ping timeout: 248 seconds)
22:24:56  * mikealquit (Quit: Leaving.)
22:26:01  * kevinswiberquit (Ping timeout: 245 seconds)
22:27:05  <trevnorris>indutny: maybe enlighten me on uv_accept. at least in stream_wrap it's called in AcceptHandle and possibly passed as the third argument to onread.
22:27:22  <trevnorris>just trying to figure out when that would occur.
22:28:27  * mikealjoined
22:28:52  <indutny>trevnorris: huh?
22:28:58  <indutny>trevnorris: you call uv_accept in listen_cb
22:29:36  <indutny>aah
22:29:39  <indutny>you mean pipes
22:29:44  <trevnorris>yeah.
22:30:31  <indutny>well
22:30:38  <indutny>fourth argument to onread
22:30:42  <indutny>is a pending handle type
22:30:55  <indutny>if its not UV_UNKNOWN_HANDLE
22:31:02  <indutny>you may call uv_accept() on pipe
22:31:05  <indutny>to fetch it
22:31:22  <trevnorris>guess what I don't get is what it means to be "pending"
22:32:32  <trevnorris>because in StreamWrapCallbacks::DoRead it passes the pending handle to the onread callback if the returning !Object::IsEmpty()
22:32:36  <trevnorris>if that makes sense.
22:35:06  <trevnorris>indutny: honestly, what i'm really trying to do is compare how much data I can pump through pipe_wrap as compared to libuv's pipe_pump1_client benchmark.
22:35:15  * mcavagejoined
22:35:28  <indutny>huh
22:35:42  <indutny>DoRead is not receiving handle
22:35:49  <indutny>and its checking pending_obj
22:35:53  <indutny>which it is initializing
22:37:20  * mcavagequit (Read error: Connection reset by peer)
22:37:21  <trevnorris>DoRead is called by StreamWrap::OnReadCommon
22:37:30  <indutny>yes
22:37:31  <trevnorris>what do you mean by "not receiving handle"?
22:37:38  <indutny>well
22:37:40  <indutny>as argument
22:37:45  <indutny>its receiving it's type
22:38:19  * st_lukequit (Remote host closed the connection)
22:38:46  * st_lukejoined
22:43:25  * st_lukequit (Ping timeout: 265 seconds)
23:04:09  * st_lukejoined
23:06:28  * bnoordhuisquit (Ping timeout: 264 seconds)
23:13:48  <tjfontaine>oh is indutny looking at the ssl truncation?
23:14:19  * st_lukequit (Remote host closed the connection)
23:14:55  * st_lukejoined
23:16:50  <tjfontaine>oh no just talking to trevor
23:19:40  * st_lukequit (Ping timeout: 264 seconds)
23:20:53  <trevnorris>tjfontaine: so, i'm a little confused. i'm running libuv's pump benchmarks to see what it can do, then I wrote barebones tcp/pipe implementations.
23:20:53  <trevnorris>_if_ the two are comparable, node's 2x's slower.
23:21:11  <trevnorris>think those benchmarks are an accurate comparison of raw speed?
23:23:23  <tjfontaine>I have no idea without seeing the code, but an easy test would be to dtrace profile both and compare the stacks, there hsould be significant overlap, except for where we're jumping through stream_wrap and js
23:24:25  <tjfontaine>I'm not sure how useful a comparison is, aside from knowing that: "Yup, abstractions can add overhead -- lets continue to work at making our abstractions better"
23:25:02  <trevnorris>well, i'm modifying my benchmarks for v0.10 compatibility, but I swear I could do much better than this
23:27:20  <trevnorris>hm. guess not. poop.
23:29:12  * wwicks_joined
23:30:31  * indexzeroquit (Quit: indexzero)
23:31:40  * wwicksquit (Ping timeout: 264 seconds)
23:31:40  * wwicks_changed nick to wwicks
23:32:15  * c4miloquit (Remote host closed the connection)
23:32:48  * c4milojoined
23:33:16  * c4miloquit (Read error: Connection reset by peer)
23:33:44  * c4milojoined
23:39:12  * TooTallNatequit (Ping timeout: 248 seconds)
23:39:48  * st_lukejoined
23:43:38  * TooTallNatejoined
23:48:55  * st_lukequit (Remote host closed the connection)
23:49:38  * wwicks_joined
23:51:28  * wwicksquit (Ping timeout: 248 seconds)
23:51:29  * wwicks_changed nick to wwicks
23:55:54  * amartensquit (Quit: Leaving.)
23:58:04  * st_lukejoined
23:59:38  <MI6>libuv-master-gyp: #219 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/219/