00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:02:03  * sblomquit (Ping timeout: 248 seconds)
00:16:08  * Benviequit (Remote host closed the connection)
00:16:35  * Benviejoined
00:21:07  * st_lukejoined
00:34:47  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:51:42  * st_lukequit (Remote host closed the connection)
00:52:22  * st_lukejoined
00:55:19  * julianduquequit (Quit: leaving)
00:55:24  * TooTallNatejoined
00:56:42  * st_lukequit (Ping timeout: 265 seconds)
01:00:25  * EhevuTovquit (Quit: This computer has gone to sleep)
01:05:41  * wwicksquit (Quit: wwicks)
01:09:04  * kazuponjoined
01:12:27  * TooTallNatequit (Ping timeout: 248 seconds)
01:15:42  * kazuponquit (Ping timeout: 264 seconds)
01:20:40  * kazuponjoined
01:49:19  * wwicksjoined
01:52:28  * wwicksquit (Client Quit)
01:53:40  * defunctzombie_zzchanged nick to defunctzombie
02:07:03  * wwicksjoined
02:21:38  * st_lukejoined
02:34:26  * TooTallNatejoined
02:44:17  * Raynosquit (*.net *.split)
02:44:17  * LeftWingquit (*.net *.split)
02:44:17  * philipsquit (*.net *.split)
02:44:18  * toothrotquit (*.net *.split)
02:44:18  * defunctzombiequit (*.net *.split)
02:44:28  * defunctzombiejoined
02:44:47  * philipsjoined
02:46:51  * toothrjoined
02:46:55  * Raynosjoined
02:49:24  * LeftWingjoined
03:03:26  * Raynosquit (Changing host)
03:03:26  * Raynosjoined
03:08:59  * st_luke_joined
03:09:52  * st_lukequit (Ping timeout: 248 seconds)
03:34:22  * toothrquit (*.net *.split)
03:34:22  * kazuponquit (*.net *.split)
03:34:23  * Benviequit (*.net *.split)
03:34:23  * ircretaryquit (*.net *.split)
03:34:23  * klutzyquit (*.net *.split)
03:34:32  * ircretaryjoined
03:34:37  * klutzyjoined
03:34:41  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:34:43  * Benviejoined
03:34:55  * kazuponjoined
03:37:51  * toothrjoined
03:44:15  * TooTallNatejoined
04:01:20  * kazuponquit (Ping timeout: 265 seconds)
04:05:00  * mikealquit (Quit: Leaving.)
04:10:04  * brsonquit (Ping timeout: 264 seconds)
04:10:06  * mikealjoined
04:12:15  * brsonjoined
04:12:47  * defunctzombiechanged nick to defunctzombie_zz
04:23:21  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:24:26  * wwicksquit (Quit: wwicks)
04:44:11  * brsonquit (Ping timeout: 248 seconds)
04:52:00  * kazuponjoined
05:05:47  <indutny>trevnorris: pong
05:23:03  * wwicksjoined
05:30:37  * wwicks_joined
05:30:59  * bajtosjoined
05:32:15  * wwicksquit (Ping timeout: 252 seconds)
05:32:15  * wwicks_changed nick to wwicks
05:44:59  * Kakerajoined
05:55:22  * piscisaureus_joined
06:32:50  * wwicks_joined
06:33:03  * st_luke_quit (Remote host closed the connection)
06:34:13  * wwicksquit (Ping timeout: 248 seconds)
06:34:14  * wwicks_changed nick to wwicks
06:39:08  * amartensquit (Quit: Leaving.)
06:40:52  <MI6>nodejs-v0.10-windows: #256 UNSTABLE windows-ia32 (9/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/256/
06:42:22  * rendarjoined
06:44:55  * amartensjoined
06:53:06  * Kakeraquit (Ping timeout: 252 seconds)
07:24:10  * amartensquit (Quit: Leaving.)
07:32:11  * bnoordhuisjoined
07:56:23  * hzjoined
08:14:12  * wwicks_joined
08:15:55  * wwicksquit (Ping timeout: 248 seconds)
08:15:56  * wwicks_changed nick to wwicks
08:23:15  * bajtosquit (Quit: bajtos)
08:23:15  * mcavage_quit (Read error: Connection reset by peer)
08:23:37  * mcavagejoined
08:23:40  * bajtosjoined
08:26:54  * abraxasjoined
08:52:05  * dominictarrjoined
09:11:01  * bnoordhuisquit (Ping timeout: 248 seconds)
09:12:14  * dominictarrquit (Quit: dominictarr)
09:15:04  * dominictarrjoined
09:15:26  <rvagg>there don't seem to be any benchmarks for event.js, is this right?
09:22:45  * dlmanningquit (Ping timeout: 248 seconds)
09:26:57  * dlmanningjoined
09:45:15  * bajtosquit (Quit: bajtos)
09:59:26  * kazupon_joined
09:59:27  * kazuponquit (Read error: Connection reset by peer)
10:00:05  * kazuponjoined
10:03:49  * kazupon_quit (Ping timeout: 248 seconds)
10:10:42  * kazuponquit (Read error: Connection reset by peer)
10:12:05  * kazuponjoined
10:42:26  * kazuponquit (Remote host closed the connection)
10:42:57  * kazuponjoined
10:45:15  * kazupon_joined
10:47:28  * kazuponquit (Ping timeout: 240 seconds)
10:48:10  <MI6>nodejs-v0.10: #1530 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1530/
11:00:33  * kazupon_quit (Remote host closed the connection)
11:01:01  * kazuponjoined
11:05:41  * kazuponquit (Ping timeout: 248 seconds)
11:06:19  <`3rdEden>rvagg: that's true
11:07:29  <rvagg>`3rdEden: given that event.js is often quoted as being written for performance ("like a crazy person wrote it") because it's used so much, it's quite strange that there are no direct benchmarks for it... so the data on perf is second hand
11:07:41  <`3rdEden>rvagg: you're free to re-use the benchmarks from my EE3 project https://github.com/3rd-Eden/EventEmitter3/tree/master/benchmarks
11:08:26  <`3rdEden>rvagg: the only thing i've heard is that they used http_simple as a benchmark to see how it affected the req/se
11:08:29  <`3rdEden>req/sec*
11:14:53  * Kakerajoined
11:27:29  * dominictarrquit (Quit: dominictarr)
11:59:01  * bnoordhuisjoined
12:33:35  * mcavage_joined
12:33:36  * mcavagequit (Read error: Connection reset by peer)
13:12:52  * hzquit (Read error: Connection reset by peer)
13:29:18  * bajtosjoined
14:21:30  * julianduquejoined
14:32:06  * mikealquit (Quit: Leaving.)
14:34:28  * mikealjoined
14:35:07  * dapjoined
14:46:17  * mikealquit (Quit: Leaving.)
14:48:45  <bnoordhuis>https://groups.google.com/forum/#!topic/nodejs/EciK3LEBtOc <- calling bajtos
14:50:33  <piscisaureus_>bnoordhuis: I think proot fails because you make an accept4 syscall directly
14:51:17  <piscisaureus_>oh hmm maybe not, ptrace should be able to detect these accept4 calls as well
14:51:23  <piscisaureus_>but I remember there was a ptrace bug related to that
14:54:10  <bnoordhuis>piscisaureus_: the guy posted on the mailing list that the proot author said it was a proot bug
14:54:17  <bnoordhuis>case closed, it seems
14:54:38  <piscisaureus_>bnoordhuis: you send your patch to proot yet?
14:57:05  <bnoordhuis>no. i'm done with writing software
14:57:34  <piscisaureus_>bnoordhuis: what are you going to do now?
14:58:07  <piscisaureus_>bnoordhuis: are you resigning?
14:58:34  * mikealjoined
14:58:55  * mikealquit (Client Quit)
14:59:01  <bnoordhuis>maybe move to france, start a chateau
15:00:05  <bnoordhuis>or belgium and a brewery
15:00:10  <bnoordhuis>both options have their appeal
15:01:22  <piscisaureus_>bnoordhuis: move to russia and start a distillery?
15:02:13  <bnoordhuis>mwah. i think the pyrenees climate agrees better with me
15:02:32  <bnoordhuis>also, i'm not really into vodka
15:02:53  <bnoordhuis>or women with jaws that are squarer than mine
15:04:08  <piscisaureus_>bnoordhuis: so you don't mind eating fries all day or speaking french>
15:04:15  * indexzerojoined
15:04:48  <bnoordhuis>i'll have to brush up on my french a little but that's okay
15:04:54  <bnoordhuis>pour l'amour right?
15:05:10  <bnoordhuis>also, the belgians eating fries all day is such a stereotype
15:05:12  <piscisaureus_>Just got an email from SANParks that there is a fire in Karoo National Park but that I need not fear
15:05:17  <bnoordhuis>they also eat waterkonijn
15:05:20  <piscisaureus_>haha
15:05:23  <piscisaureus_>yummies
15:05:48  <piscisaureus_>andouillette, on the other hand...
15:06:21  <bnoordhuis>mmm
15:08:51  <piscisaureus_>bnoordhuis: on a serious note
15:09:08  <piscisaureus_>bnoordhuis: how much work do you think it is to put node-heapdump and some start/stop profiler bindings in core?
15:09:15  <piscisaureus_>bnoordhuis: could we spearhead that to get into 0.12?
15:12:26  <bnoordhuis>piscisaureus_: close to trivial
15:12:39  <bnoordhuis>esp. if you just want the 'dump to file' behavior
15:13:33  <piscisaureus_>bnoordhuis: Ideally it should be able to locate the log later without user intervention
15:13:38  * mikealjoined
15:13:48  <piscisaureus_>bnoordhuis: the parser etc does not have to be in core, it can live in npm
15:14:50  <bnoordhuis>piscisaureus_: 'it should be able' - who or what is 'it'?
15:15:29  <piscisaureus_>bnoordhuis: anything
15:16:06  <piscisaureus_>bnoordhuis: if you could specify the target file location I presume that is okay
15:16:17  <bnoordhuis>yeah, that's no big deal
15:16:17  <piscisaureus_>bnoordhuis: so people can dump into $TEMP or something
15:20:30  <MI6>nodejs-master: #605 UNSTABLE smartos-ia32 (8/644) smartos-x64 (8/644) http://jenkins.nodejs.org/job/nodejs-master/605/
15:27:17  * mikealquit (Quit: Leaving.)
15:29:34  * mikealjoined
15:33:52  * c4milojoined
15:37:38  * bajtosquit (Quit: bajtos)
15:44:58  * `3rdEdenchanged nick to `3E|GONE
15:53:21  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:59:35  * AvianFlujoined
16:01:09  * kazuponjoined
16:04:22  * bajtosjoined
16:28:54  * defunctzombie_zzchanged nick to defunctzombie
16:29:42  * st_lukejoined
16:30:31  * bnoordhuisquit (Ping timeout: 272 seconds)
16:31:15  * toothrchanged nick to toothrot
16:33:57  * mikealquit (Quit: Leaving.)
16:47:17  * austojoined
16:51:25  * TooTallNatejoined
16:57:34  * kevinswiberjoined
17:00:25  * kellabytequit (Read error: Connection reset by peer)
17:04:56  * brsonjoined
17:05:39  * julianduquequit (Quit: leaving)
17:10:31  * kazuponquit (Remote host closed the connection)
17:10:57  * kazuponjoined
17:15:08  * kazuponquit (Ping timeout: 240 seconds)
17:17:47  <MI6>joyent/node: Glen Mailer master * 66b8c3c : assert: indicate if exception message is generated - http://git.io/3ThtDg
17:22:02  * defunctzombiechanged nick to defunctzombie_zz
17:26:19  * AvianFluquit (Remote host closed the connection)
17:30:13  * dapquit (Quit: Leaving.)
17:30:15  * mikealjoined
17:30:19  <MI6>nodejs-master: #606 UNSTABLE smartos-ia32 (6/644) smartos-x64 (8/644) http://jenkins.nodejs.org/job/nodejs-master/606/
17:31:37  * indexzeroquit (Quit: indexzero)
17:34:20  * AvianFlujoined
17:44:00  <MI6>nodejs-master-windows: #399 UNSTABLE windows-x64 (20/644) windows-ia32 (24/644) http://jenkins.nodejs.org/job/nodejs-master-windows/399/
17:44:28  * c4miloquit (Remote host closed the connection)
17:45:04  * c4milojoined
17:48:24  * kevinswiberquit (Remote host closed the connection)
17:48:58  * kevinswiberjoined
17:49:02  <trevnorris>morning
17:49:07  <trevnorris>indutny: nm, thanks :)
17:49:21  * c4miloquit (Ping timeout: 245 seconds)
17:49:21  * bajtosquit (Quit: bajtos)
17:52:51  * bajtosjoined
17:53:00  * bajtosquit (Client Quit)
17:53:02  * kevinswiberquit (Ping timeout: 240 seconds)
17:53:29  <MI6>libuv-master: #281 UNSTABLE linux (1/195) windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/281/
17:55:02  <trevnorris>rvagg: we should say, it's been written for performance, *with the stipulation of backwards compatibility*
17:55:13  <trevnorris>rvagg: it's by no means "performant" in my book.
17:55:26  * amartensjoined
17:56:57  <indutny>trevnorris: heya
17:57:04  * julianduquejoined
17:57:09  <trevnorris>how's it going?
17:59:33  <indutny>good
17:59:38  <indutny>how are you?
18:00:10  <trevnorris>doing well.
18:00:43  <trevnorris>been looking at 6011 for so long, don't think I'll be able to find any other issues with it.
18:00:43  <trevnorris>just waiting for review.
18:01:07  * kevinswiberjoined
18:02:24  * st_lukequit (Read error: Connection reset by peer)
18:02:41  * st_lukejoined
18:03:10  * st_lukequit (Remote host closed the connection)
18:03:37  * st_lukejoined
18:03:52  * dapjoined
18:05:53  * st_luke_joined
18:06:26  * st_lukequit (Read error: Connection reset by peer)
18:10:01  <trevnorris>indutny: how's moscow this time of year?
18:10:22  <MI6>libuv-node-integration: #266 UNSTABLE smartos-x64 (7/644) smartos-ia32 (6/644) http://jenkins.nodejs.org/job/libuv-node-integration/266/
18:13:04  <indutny>trevnorris: a bit like london
18:21:36  * kazuponjoined
18:26:38  * kazuponquit (Ping timeout: 240 seconds)
18:27:06  * st_luke_quit (Remote host closed the connection)
18:28:38  * indexzerojoined
18:31:46  * bnoordhuisjoined
18:34:45  * st_lukejoined
18:46:33  <trevnorris>anyone mind a quick review? https://github.com/joyent/node/pull/6337
18:48:07  <tjfontaine>looking
18:53:13  * julianduquequit (Quit: leaving)
18:57:22  <MI6>nodejs-master-windows: #400 UNSTABLE windows-x64 (21/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/400/
18:58:31  * bnoordhuisquit (Ping timeout: 245 seconds)
19:00:28  * bnoordhuisjoined
19:02:52  <tjfontaine>trevnorris: is HasIndexedPropertiesInExternalArrayData true on ArrayBuffer?
19:03:04  * julianduquejoined
19:03:13  <trevnorris>tjfontaine: let me check. why?
19:03:39  * kellabytejoined
19:03:46  <tjfontaine>trevnorris: just curious, mostly interested to know if node::Buffer::Copy does the right thing in that case
19:04:38  <trevnorris>oh, if say you pass an ArrayBuffer to the receiving end of a Buffer#copy()?
19:05:46  <tjfontaine>just thinking about a possible permutation of "ArrayBuffer -> Buffer"
19:05:51  <trevnorris>tjfontaine: nope. doesn't return true.
19:06:02  <tjfontaine>k
19:06:16  <tjfontaine>seems like that's a potential api improvement at some point
19:06:40  <tjfontaine>I'm not sold on it, just somethign that came across to me
19:07:29  <trevnorris>you'd need to use the ArrayBuffer::Contents::Data() to get that out
19:08:04  <trevnorris>tjfontaine: already took care of those two things.
19:08:57  <trevnorris>tjfontaine: holy shit. you can do a smalloc.alloc(N, new ArrayBuffer(M));
19:08:58  * julianduquequit (Ping timeout: 246 seconds)
19:09:09  <trevnorris>and the two data sets live separate.
19:09:40  * EhevuTovjoined
19:09:49  <tjfontaine>bbiab lunch
19:14:04  <MI6>joyent/node: Trevor Norris master * ad83620 : buffer: add buf.toArrayBuffer() API (+1 more commits) - http://git.io/Gp6iEQ
19:14:13  <bnoordhuis>wow, that was quick
19:15:07  <trevnorris>bnoordhuis: sorry, go too quickly there?
19:15:31  <bnoordhuis>well, i don't know - i didn't look at it but i have faith in all of you
19:15:36  <bnoordhuis>*hug*
19:15:41  <trevnorris>:)
19:16:25  <trevnorris>bnoordhuis: in that case can I merge 6011 ;P
19:16:35  <bnoordhuis>ai, indent error
19:17:18  <trevnorris>bnoordhuis: strange. cpplint didn't catch that.
19:17:33  <MI6>joyent/node: Trevor Norris master * 8a295cd : buffer: add buf.toArrayBuffer() API - http://git.io/PBU5kw
19:17:45  <bnoordhuis>yeah
19:17:57  <bnoordhuis>also, i introduced a style error in node.cc, it seems :$
19:18:34  <bnoordhuis>next time i touch that code i'll fix it up, promise
19:18:47  <trevnorris>:)
19:19:04  <bnoordhuis>bit of a stupid warning though: src/node.cc:3161: { should almost always be at the end of the previous line [whitespace/braces] [4]
19:19:08  <trevnorris>othiym23: ping
19:19:11  <bnoordhuis>it's because i start a new scope...
19:19:25  <othiym23>but I was just going to go get luuuuuuunch
19:19:30  <othiym23>aaaaagh
19:19:34  <othiym23>trevnorris: whattaya want?
19:19:51  <trevnorris>othiym23: just quick question. did we agree on a name to replace "domain" with async listener other than "storage"
19:19:57  <trevnorris>can't remember what it was
19:19:58  <othiym23>"value"
19:20:03  <trevnorris>ah yeah. thanks.
19:20:11  <trevnorris>ok, off to lunch with you :)
19:20:12  * kevinswiberquit (Remote host closed the connection)
19:20:17  <othiym23>tyvm!
19:20:44  <trevnorris>bnoordhuis: heh, totally forgot I thew in a commit into 6011 just to get rid of that warning: https://github.com/trevnorris/node/commit/29d1884f144abee196457655ac89b1ef76840d2a
19:20:46  * kevinswiberjoined
19:21:02  <trevnorris>so I'd totally forgotten about it
19:21:29  <bnoordhuis>yeah... actually, i have half a mind to fix cpplint.py
19:21:47  <bnoordhuis>but not tonight
19:22:30  <bnoordhuis>but lgtm i guess, this is a lot less work
19:22:42  * julianduquejoined
19:22:47  <bnoordhuis>i'm allowed to be lazy on fridays
19:22:57  <trevnorris>lgtm on which? that one commit?
19:22:58  <bnoordhuis>(right? right?)
19:23:02  <trevnorris>yeah.
19:23:12  <bnoordhuis>yeah, i didn't look at any other commits
19:23:33  <trevnorris>cool. and since it has nothing to do with the PR, I'll just pop it off.
19:23:57  <trevnorris>and seriously. between a new kid and all the issues you've responded to. be lazy. ;)
19:24:32  <bnoordhuis>:)
19:25:29  * kevinswiberquit (Ping timeout: 265 seconds)
19:27:41  * EhevuTovquit (Quit: This computer has gone to sleep)
19:28:15  <MI6>joyent/node: Trevor Norris master * 7503e4c : lint: fix a cpplint error - http://git.io/87_GYw
19:28:54  * EhevuTovjoined
19:35:25  <indutny>bnoordhuis: I've some fixes for it as well
19:35:36  <indutny>bnoordhuis: disallowing comma-first style
19:35:42  <indutny>and other bits
19:36:21  <MI6>nodejs-master: #607 UNSTABLE smartos-ia32 (8/644) smartos-x64 (11/644) http://jenkins.nodejs.org/job/nodejs-master/607/
19:37:14  <bnoordhuis>indutny: feeling snarky?
19:38:16  <indutny>haha
19:38:21  <indutny>sorry, it sounded rude
19:38:31  <indutny>but it wasn't intended to be so
19:38:44  <indutny>I think we should be more consistent in style
19:38:59  <indutny>and that's my main direction, if I'll ever decide to touch cpplint
19:39:21  <indutny>anything that doesn't look like the rest of the code should be fixed
19:39:35  <bnoordhuis>or... we could mandate comma first style for constructors. idea!
19:40:48  * st_lukequit (Read error: Connection reset by peer)
19:41:03  * st_lukejoined
19:43:48  <trevnorris>I was actually wondering about that. you guys like the comma first style in constructors, but there only?
19:44:06  <bnoordhuis>it's mostly to minimize diff noise when you add fields
19:44:24  <bnoordhuis>effectiveness thereof is up for debate but there it is
19:45:16  <trevnorris>ah, ok.
19:45:40  <isaacs>i like comma-first everywhere.
19:45:46  <trevnorris>....
19:45:48  <isaacs>but i like consistency more
19:46:10  <isaacs>and linting isn't about subjective preferences, it's about picking a style we can all live with, even if no one loves it, and then fucking living with it.
19:46:15  <isaacs>;)
19:46:43  <bnoordhuis>yeah, but cpplint is like honey badger on this subject
19:46:46  <bnoordhuis>it don't care!
19:46:55  <isaacs>bnoordhuis: yeah, tha'ts a problem, for sure.
19:47:01  <bnoordhuis>me neither, actually
19:47:08  <isaacs>bnoordhuis: also, i'm in favor of any style rules being enforced by the linter, or dropped.
19:47:25  <bnoordhuis>or at least, there's a rationale for it but not a super duper strong one
19:47:48  <bnoordhuis>yeah, i've landed some cpplint patches already
19:48:00  <bnoordhuis>but it's not always easy to get it to do what you want
19:48:25  <MI6>nodejs-master: #608 UNSTABLE smartos-ia32 (6/644) smartos-x64 (8/644) http://jenkins.nodejs.org/job/nodejs-master/608/
19:49:21  <trevnorris>tjfontaine: ping
19:54:14  * kevinswiberjoined
19:57:35  * `3E|GONEchanged nick to `3E
19:58:08  <MI6>nodejs-master-windows: #401 UNSTABLE windows-x64 (21/644) windows-ia32 (28/644) http://jenkins.nodejs.org/job/nodejs-master-windows/401/
20:00:39  <tjfontaine>trevnorris: pong
20:01:12  <isaacs>trevnorris: (re 6214) when i run the test with a zero-byte repsonse on master with my patch, i'm not seeing the assertion error you had.
20:02:04  <trevnorris>isaacs: let me run with your patch again and see i I can reproduce. then I'll give a bt.
20:02:11  <isaacs>kk
20:08:01  <isaacs>trevnorris: yes, this is linux failure.
20:08:11  <isaacs>doesn't fail with a big response, but does when it's a zero-byte response
20:08:31  <isaacs>blows an assertion in uv_read_stop. wonder why it doesn't in os x
20:09:12  <isaacs>also, sweet zombie jesus, that assert is monkeyballs
20:09:46  <trevnorris>I know right?
20:09:57  <trevnorris>bnoordhuis: wtf were you thinking?
20:10:07  <trevnorris>;)
20:13:06  <isaacs>it's not so bad in the source
20:13:13  <isaacs>just looks gnarly with the \n removed
20:13:53  <tjfontaine>is it clear which part is blowing?
20:13:59  <tjfontaine>I haven't actually looked into it
20:14:20  <isaacs>they're || so, all of them are :) so, it's in UV_POLLOUT, and it's write_completed_queue is empty, and its write_queue is empty, and it doesn't have a shutdown_req or connect_req
20:15:07  * isaacspours one out for demorgan
20:15:18  <tjfontaine>heh
20:15:49  <tjfontaine>sounds like we could blow that assert for 0 byte responses separate from this?
20:16:48  <isaacs>tjfontaine: well, it's not actually a zero-byte response
20:16:51  <isaacs>it's an http response
20:16:57  <isaacs>so there's like, status, etc.
20:17:01  <isaacs>but it's a small response
20:17:57  <tjfontaine>but spread over two write requests?
20:18:10  <tjfontaine>anyway, back to my other stuff
20:19:14  <isaacs>tjfontaine: not sure how many writereqs there are
20:21:24  <trevnorris>isaacs: um... there's something strange going on.
20:21:34  <isaacs>removing that assertion makes it work fine
20:21:40  <isaacs>but that's usually not a good solution :)
20:21:59  <trevnorris>isaacs: so your patch is a race condition. if I run a debug build then I never receive a request
20:22:05  <trevnorris>but the assert doesn't blow
20:22:36  <trevnorris>ok, wait.
20:22:48  <trevnorris>I do receive some requests. but then quickly nothing.
20:23:41  <trevnorris>isaacs: running in debug build, I get a bunch of requests, then cpu on both server and client goes to 0%
20:23:53  <trevnorris>it's like it just stops processing the data.
20:25:18  <isaacs>interesting
20:25:34  <isaacs>basically, what my patch does is says, "if you're not going to read my responses, i'm going to stop reading your requests"
20:26:14  <isaacs>eventually, this leads to a completely unresponsive client getting timed out
20:26:37  <trevnorris>I haven't run it long enough to see if the client will time out
20:26:41  <trevnorris>how long should that take?
20:27:17  <isaacs>trevnorris: on master? that test should time out after 200ms of inactivity
20:27:23  <isaacs>ie, pretty fast
20:27:43  <trevnorris>isaacs: well, your test does, but it doesn't. something is starving I/O on my box.
20:27:44  <isaacs>bnoordhuis: yes, that is a stupid cpplint failure. can you either fix cpplint or use a do{}while(false) there?
20:27:50  <trevnorris>it took almost two minutes to complete.
20:27:54  <isaacs>bnoordhuis: it is a cpplint failure, still.
20:28:29  <isaacs>bnoordhuis: oh, it's already fixed
20:28:32  <isaacs>bnoordhuis: disregard :)
20:28:45  <trevnorris>isaacs: what was worded poorly.you test is told to time out after 200ms, but thta doesn't happen on my box. your test takes 2 mins to complete.
20:28:52  <trevnorris>*that was
20:28:57  <trevnorris>man, my typing really sucks.
20:29:06  <isaacs>trevnorris: i see
20:29:13  <isaacs>trevnorris: that's a lot of mins
20:29:34  <tjfontaine>gcore and find out where it is :)
20:29:40  <trevnorris>tjfontaine: in the process :)
20:29:46  <trevnorris>have a meeting in 30, but i'll get it.
20:30:52  <MI6>nodejs-master-windows: #402 UNSTABLE windows-x64 (22/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/402/
20:35:02  * AvianFlu_joined
20:35:53  * AvianFluquit (Ping timeout: 272 seconds)
20:40:17  <trevnorris>tjfontaine: sorry, think my quick force push made jenkins hurt. will it/he recover ok?
20:40:25  <trevnorris>i'd hate to see it/him suffer.
20:40:52  <tjfontaine>please, stop force pushing. more commits are not a problem.
20:41:09  <tjfontaine>but what makes you think it's angry?
20:41:30  <trevnorris>he was red in the face. :P
20:41:43  <isaacs>lol
20:41:46  <tjfontaine>which build?
20:42:20  <tjfontaine>oh pull requests
20:42:27  <trevnorris>yeah
20:42:40  <trevnorris>http://jenkins.nodejs.org/job/node-pullrequest/1363/
20:42:42  <tjfontaine>ya, we can just rebuild it
20:42:50  <trevnorris>eh, doesn't matter.
20:42:59  <tjfontaine>I just told it to do it again
20:43:04  <trevnorris>thanks :)
20:43:06  <tjfontaine>yw
20:43:25  <tjfontaine>I thought we were talking about the master force push
20:43:32  <trevnorris>oh, no
20:44:01  <tjfontaine>which, really -- stop that. there's no grace window where it's acceptable
20:44:10  <trevnorris>tjfontaine: for a dump, is it better to use a debug build or does it matter.
20:44:21  <tjfontaine>trevnorris: for mdb in this case it doesn't matter
20:44:29  <trevnorris>coolio
20:44:37  <tjfontaine>trevnorris: unless you're trying to track down a difference between release and debug
20:44:42  <trevnorris>nope
20:44:50  <tjfontaine>ya then just use a release build
20:44:56  <trevnorris>wait. is it just gcore <pid> ?
20:45:01  <tjfontaine>yes
20:45:19  <tjfontaine>gcore $(pgrep node)
20:45:26  <tjfontaine>or something if you want to get all fancy
20:45:36  <tjfontaine>[and only have one node proc running]
20:45:49  <isaacs>tjfontaine: the ubuntu.nodejs.org zone is out of disk space, it looks like
20:46:04  <tjfontaine>sigh.
20:46:15  <tjfontaine>oh that's not mine
20:46:19  <isaacs>tjfontaine: ok
20:46:27  <isaacs>tjfontaine: so you're ok with me trashing some old stuff on there?
20:46:47  <tjfontaine>isaacs: yup, also it's helpful to do your scratch work in /data as that's where the real disk space is in a kvm instance :)
20:46:52  <trevnorris>tjfontaine: took a dump. it's a big one. how do I start sifting through it?
20:47:20  <trevnorris>sorry, couldn't resist.
20:47:20  * trevnorrishangs his head in childish shame
20:47:20  <isaacs>trevnorris: first, you're going to want a stick, or some other disposable tool that's relatively firm
20:47:30  <trevnorris>haha
20:47:35  <isaacs>trevnorris: and some noseplugs
20:47:46  <tjfontaine>firm is only necessary if the dump itself is relatively solid
20:48:12  <trevnorris>damn you guys. almost sprayed coconut water on my keyboard.
20:48:20  <isaacs>well, sure but you don't wanna go sifting through with a silicone spatula, or something that's liable to get caught and slip out flinging the stuff everywhere
20:48:35  <isaacs>trevnorris: i find that mdb is suitable for sifting through most dumps
20:49:08  <bnoordhuis>i step away for five minutes...
20:49:21  <tjfontaine>trevnorris: so you really wanna know what to do? I would start with: `mdb core` then `::findjsobjects -v ! sort -k 2`
20:49:25  <isaacs>tjfontaine: oh, wow, yeah
20:49:33  <isaacs>./data is 2% used
20:49:37  <tjfontaine>isaacs: ya, been doing it wrong on kvm instances? :)
20:50:16  <trevnorris>tjfontaine: how do you link to v8.so again?
20:50:30  <isaacs>tjfontaine: guess so
20:50:31  <tjfontaine>did you pass --dest-cpu to your build?
20:50:41  <trevnorris>nope
20:50:46  <tjfontaine>http://us-east.manta.joyent.com/tjfontaine/public/ia32_v8.so
20:50:47  <tjfontaine>use that one
20:50:48  <trevnorris>it's just telling me that findjsobjects isn't a command
20:51:01  <tjfontaine>that's the latest that's in master
20:51:43  * wwicks_joined
20:52:18  <trevnorris>haha, i remembered ::load :P
20:53:08  * wwicksquit (Ping timeout: 240 seconds)
20:53:08  * wwicks_changed nick to wwicks
20:55:52  * julianduquequit (Ping timeout: 265 seconds)
20:56:14  <trevnorris>well, that's going to take a while.
20:56:33  <tjfontaine>ya, patience is a virtue :)
20:56:41  <tjfontaine>also was this while it was stuck?
20:56:49  <tjfontaine>you could do: ::jsstack
20:56:49  <trevnorris>yeah
20:56:59  <tjfontaine>at least you can know where it was when you core'd it
20:57:06  <trevnorris>can I run mdb twice on the same core?
20:57:19  <tjfontaine>yes
20:58:21  <trevnorris>yup, GC. not surprising.
20:58:40  <trevnorris>ah, from http parser
20:59:01  <tjfontaine>not necessarily helpful, you should probably also get a flamegraph while it's going on
20:59:14  <trevnorris>um... ok. never done that before.
20:59:16  <tjfontaine>that will let you know hwo often it's doing something
20:59:40  <tjfontaine>trevnorris: start the process then use http://blog.nodejs.org/2012/04/25/profiling-node-js/
20:59:56  <trevnorris>coolio. thanks.
21:00:02  <trevnorris>*meeting
21:00:03  * trevnorris&
21:00:04  <LOUDBOT>WHY CAN'T THEY MAKE A NICOTINE PATCH THAT BURNS MORE LIKE A CIGARETTE DOES?
21:01:33  * julianduquejoined
21:09:34  * AvianFlu_quit (Remote host closed the connection)
21:11:49  * julianduquequit (Ping timeout: 265 seconds)
21:14:07  <trevnorris>tjfontaine: does smartos have stackvis somewhere?
21:14:13  <trevnorris>(smartos.nodejs.org)
21:14:16  <tjfontaine>trevnorris: npm install -g stackvis
21:14:22  <trevnorris>ah, ok
21:14:24  <trevnorris>duh
21:25:57  * dominictarrjoined
21:43:44  <trevnorris>tjfontaine: wow, check this: https://cloudup.com/cV5vvluAiye
21:44:22  <trevnorris>isaacs: ^
21:44:38  <trevnorris>that parser is kicking out butts
21:44:54  <tjfontaine>can I get the svg? :)
21:45:05  <trevnorris>yeah. hit the download button top right
21:45:12  <tjfontaine>oh it's that kind of thing
21:45:30  <tjfontaine>https://i.cloudup.com/QtHu1ZJYEo.svg is the url I was looking for :)
21:46:15  <tjfontaine>right so no gc time going on here, at least not appreciable
21:46:25  <tjfontaine>just pure parsing time
21:47:57  <trevnorris>yeah. but what's strange is that --prof shows +40% in GC
21:48:49  <trevnorris>wow, it's all parserOnHeadersComplete
21:48:54  <tjfontaine>you only have the one node process running when you did that dtrace script?
21:48:58  <trevnorris>all, meaning a lot
21:49:25  <trevnorris>no. the tcp pumping the data was a separate process, but I traced by pid
21:49:31  <trevnorris>so it only got the servers data
21:50:03  <tjfontaine>you did dtrace -p you mean, or added /pid == 12345/ to your predicate?
21:50:15  <othiym23>isaacs: ping
21:50:39  <trevnorris>pid ==
21:51:03  <trevnorris>swapped out execname ==
21:51:11  <tjfontaine>if you used dtrace -p in your predicate just to be extra safe it's helpful to do dtrace -p -n '.../pid == $target/...' a quick little way so you don't have to keep updating it
21:51:39  * defunctzombie_zzchanged nick to defunctzombie
21:51:43  <tjfontaine>or you can use `dtrace -c "./node <somescript>" -n '.../pid == $target/...'
21:51:49  <isaacs>othiym23: pong
21:51:52  * dominictarrquit (Quit: dominictarr)
21:51:55  * wolfeidauquit (Remote host closed the connection)
21:52:01  <trevnorris>tjfontaine: ah, nice trick. thanks.
21:52:03  <tjfontaine>not the use of single quotes, you don't want $target to be evaluated before the dtrace command gets a chance to look at it
21:52:24  <trevnorris>yeah cool
21:52:30  <tjfontaine>*note
21:53:06  <othiym23>isaacs: I have a bunch of tests with their own node_modules directories that are getting pressganged into my module's tgz file
21:53:09  * wwicks_joined
21:53:09  <othiym23>this is surprising to me!
21:53:24  <othiym23>I thought npm respected .gitignore for pack / publish
21:53:41  <othiym23>is this an errorneous assumption? and how do I mark things to not be included in the tarball?
21:53:42  <isaacs>it does, except for node_modules
21:54:07  <othiym23>well, it's also including a few directories with bigassed log files in them that are marked to be ignored by .gitignores in their parent directories
21:54:13  <isaacs>right
21:54:18  <isaacs>link?
21:54:48  * wwicksquit (Ping timeout: 240 seconds)
21:54:48  <othiym23>"npm install newrelic@0.11.7" and then take a look at the tarball in ~/.npm/newrelic
21:54:49  * wwicks_changed nick to wwicks
21:54:58  <othiym23>or maybe it's 0.11.6
21:55:18  <othiym23>my little bitty module doesn't need to be 14-28MB :(
21:55:38  <tjfontaine>are you *suuuure*?
21:55:50  <othiym23>it's like 4,000 lines of code!
21:55:53  <tjfontaine>it was a great way to test the tls bug in 0.10.19
21:56:06  * rendarquit
21:56:15  <othiym23>5,000 if you include its bundledDependencies
21:57:05  <othiym23>a customer was all "your module takes 30 minutes to install" and I was all "lol yr dumb" and then I looked at how big the tarball was and I was all :'(
22:01:23  <othiym23>isaacs: since npm filters out the .gitignore files, you can also look at https://github.com/newrelic/node-newrelic, which has all of them
22:09:01  * indexzeroquit (Quit: indexzero)
22:09:19  <isaacs>othiym23: interesting. yeah, this is a bug
22:09:29  <isaacs>~/.npm/newrelic/0.11.7/package/test/versioned/node-mysql-2/package.json shows that those are deps, but not bundledDeps
22:09:33  <isaacs>so it should not be including them
22:09:58  * Kakeraquit (Read error: Connection reset by peer)
22:10:38  * bnoordhuisquit (Ping timeout: 272 seconds)
22:10:41  <othiym23>isaacs: if I do a clean checkout and `npm publish` without `npm install` first, the bundledDeps don't end up in the tarball -- is this the behavior you expect?
22:11:50  <isaacs>othiym23: well, then the bundledDeps aren't there, so yes
22:12:20  <othiym23>isaacs: also, the logfiles in ~/.npm/newrelic/0.11.7/package/test/multiverse/build-errors should be ignored by the .gitignore in test/multiverse (in the source checkout), but they're getting pulled in
22:12:25  <othiym23>this is also counter to my expectations
22:13:08  <othiym23>isaacs: OK, just checking, it could have worked by fetching the bundledDeps before packing (which is sorta what I thought was happening)
22:16:22  <isaacs>othiym23: so, yes, it is indeed including things it should not be. verified with a simpler test.
22:16:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:17:40  * kevinswiberquit (Remote host closed the connection)
22:18:15  * kevinswiberjoined
22:21:51  * kevinswi_joined
22:23:15  * kevinswiberquit (Read error: Connection reset by peer)
22:23:50  <othiym23>isaacs: glad to know I'm not bonkers, and in the meantime I'll just change my build process to work around it
22:23:53  <othiym23>isaacs: thanks!
22:24:38  <isaacs>np
22:24:40  <isaacs>thanks for finding it
22:24:42  * kevinswi_quit (Remote host closed the connection)
22:25:15  * kevinswiberjoined
22:25:46  <isaacs>othiym23: oh, shit, this is interesting
22:25:51  <isaacs>othiym23: so... here's why that's happening...
22:26:04  <isaacs>othiym23: not that you care, but indulge me for a second and be my rubber duck :)
22:26:10  <othiym23>sure!
22:26:14  <othiym23>glad to be of service sir
22:26:14  <tjfontaine>you're the one
22:26:18  <tjfontaine>you ake bathtime soo much fun
22:26:35  <isaacs>so, this is a bit of code that's trying to figure out if it should bundle a package it finds in a node_modules folder, or exclude it
22:27:00  <isaacs>let's say you have a package x, with a bundledDependency on y, and y has a regular dependency on z
22:27:09  <isaacs>bundling y means that you ought to bundle z also, right?
22:27:10  <isaacs>otherwise it won't work
22:27:11  <othiym23>with you so far
22:27:15  <othiym23>yes
22:27:43  <isaacs>so, the logic says, if the parent folder is a package, and that package is getting included, then clearly we're already in a bundle, and need to bundle this dep, no matter what
22:27:54  <isaacs>however, that gets confused if you have x/test/y/node_modules/z
22:28:09  <isaacs>because y has a parent, and is being included, but ISN'T being included as a bundledDependency, per se
22:28:50  <othiym23>right
22:29:21  * kevinswiberquit (Ping timeout: 245 seconds)
22:29:38  <isaacs>so, i think the fix is to make sure that the parent folder name is node_modules, and not, eg "test"
22:30:26  <othiym23>does pack do a depth-first or breadth-first traversal of the directory tree?
22:30:30  <othiym23>I guess that's cache, not pack
22:31:19  <isaacs>othiym23: i'm talking about the packing phase of `npm cache add`
22:31:22  <othiym23>it seems to me that a more reliable way would be to do a depth-first traversal, and then you could just say "this and all its children are packed" on a per-dependency basis
22:31:26  <isaacs>othiym23: https://gist.github.com/isaacs/6943027 <-- can you apply that on your local npms?
22:31:29  <othiym23>OK
22:31:30  <isaacs>and make sure it works for you
22:31:46  <isaacs>othiym23: yes, it does depth-first
22:31:58  <othiym23>let me trigger a full build so all the goop is in there
22:32:04  <isaacs>othiym23: but it's a bit naive and slower than it needs to be
22:33:15  <othiym23>OK, that was just what seemed simplest to me on first thought
22:40:57  <othiym23>isaacs: that fixed it in npm 1.3.11, as far as I can tell
22:41:02  <isaacs>sweet
22:41:14  <isaacs>othiym23: i'm gonna merge a few other things in, and then release a new npm, probably monday
22:41:17  <isaacs>this fix'll be in it
22:41:28  <othiym23>xlnt, thanks
22:42:02  <othiym23>I think it's probably best to do a git clone https://github.com/newrelic/node-newrelic && cd node-newrelic && npm install && npm publish anyway, though
22:42:15  <othiym23>I've been trying to clean up my build process some in preparation for CD anyway
22:43:48  * TooTallNatejoined
22:53:25  * brsonquit (Quit: leaving)
22:53:43  * brsonjoined
22:57:49  * julianduquejoined
23:06:35  * st_lukequit (Remote host closed the connection)
23:07:03  * st_lukejoined
23:12:03  * st_lukequit (Ping timeout: 272 seconds)
23:23:48  * c4milojoined
23:28:37  * defunctzombiechanged nick to defunctzombie_zz
23:38:33  * mikealquit (Quit: Leaving.)
23:40:57  * kevinswiberjoined
23:58:46  <MI6>libuv-master-gyp: #221 FAILURE windows-x64 (5/196) linux-ia32 (1/195) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/221/