00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:00:12  * mikealquit (Ping timeout: 264 seconds)
00:01:34  <trevnorris>isaacs: in stream.js, it was using events.EventEmitter already. and ironically that would have put the line over the char limit. so I just swapped that out for EE. cool?
00:02:31  <isaacs>sblom: sorry, forgot to tell you: if https://github.com/joyent/node/pull/4887 actually works, then LGTM
00:02:47  <isaacs>sblom: i don't think there's anyone around qualified to review cmd script code.
00:03:06  <isaacs>sblom: so, just go ahead and push. it'll be good for you, toughen up those nerves :)
00:03:12  * nodejs-ciquit
00:03:29  <isaacs>sblom: if it's broken, i'll just give you some guff about it next week when we do another build :)
00:03:39  <tjfontaine>I thought he did push it
00:03:43  * bradleymeckquit (Quit: bradleymeck)
00:03:43  <tjfontaine>just hasn't closed the pr
00:03:43  <isaacs>orly??
00:03:49  <isaacs>oh, yeah!
00:03:51  <isaacs>ok, nvm :)
00:03:58  * nodejs-cijoined
00:04:24  * bradleymeckjoined
00:05:16  <sblom>d'oh.
00:05:21  <sblom>Thanks for closing.
00:09:03  <TooTallNate>https://github.com/LearnBoost/cloudup-local/pull/128
00:09:14  <TooTallNate>whoops :
00:09:15  <TooTallNate>:p
00:09:16  <TooTallNate>https://github.com/joyent/node/issues/4884#issuecomment-14318316
00:09:19  <trevnorris>isaacs: honestly the one idea i threw around a lot was a way to speed up the hottest path. single listener, 3 <= arguments, and no use of "this" in the listener.
00:09:20  <TooTallNate>well that turned sour quick
00:09:33  <trevnorris>isaacs: would be over 10x's faster, but couldn't figure out how to implement it.
00:09:42  * EhevuTovquit (Quit: This computer has gone to sleep)
00:10:52  <isaacs>trevnorris: we still always have apply() in there
00:11:02  <isaacs>trevnorris: unless you do bind in on() but that's even slower.
00:11:16  <isaacs>trevnorris: or call(), i suppose
00:11:44  <isaacs>TooTallNate: yeah, i'm looking into thise.
00:12:19  <trevnorris>isaacs: yeah. it was more like an "emitter.reallyFreakinFastEmit(event)" type of thing. but.... yeah.
00:14:31  * MI6quit (Remote host closed the connection)
00:14:41  * MI6joined
00:14:57  <trevnorris>when I did some testing using that, a single emit() couldn't be measured by hrtime(). but, eh. i'll do it myself in userland. ;-)
00:16:54  <MI6>libuv-master build #20 UNSTABLE osx (2/183) smartos (4/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/20/
00:17:12  <tjfontaine>isaacs: ^^ thoughts?
00:26:42  <bnoordhuis>god, ab is so moronic
00:26:51  <bnoordhuis>ab -k turns on keep-alive
00:27:16  <bnoordhuis>but if the server doesn't reply with a Connection: keep-alive, ab just hangs there, doesn't matter that it's a http/1.1 response
00:27:55  <tjfontaine>bnoordhuis: ab loves you
00:28:02  <tjfontaine>why don't you love it in return?
00:28:14  <bnoordhuis>it's one of those love-hate relationships
00:28:20  <bnoordhuis>the love comes from ab, the hate from me
00:28:29  * bradleymeckquit (Quit: bradleymeck)
00:28:39  <trevnorris>really? i always felt that ab hated me
00:28:57  <bnoordhuis>anyway, the good news is that the bug is not in my code. the bad news is that it took me way too long to figure that out
00:33:57  <MI6>joyent/node: Lars-Magnus Skog master * 4b20f34 : doc change for Readable._read() - http://git.io/BNiriw
00:34:18  <isaacs>tjfontaine: that's cute :)
00:34:31  <tjfontaine>ugh this throttle plugin is not working the way I thought
00:34:44  <trevnorris>isaacs: updated and responded to the comments.
00:34:48  <isaacs>trevnorris: the trick is to emit a bazillion times, then just do the division
00:35:32  <tjfontaine>isaacs: we at least get some visibility into how many tests are failing and where
00:35:46  <isaacs>tjfontaine: yeah, that's what i mean.
00:35:51  <isaacs>tjfontaine: and it's a lot slimmer.
00:36:07  <isaacs>tjfontaine: and less "Yippee!"
00:36:09  <isaacs>:)
00:36:18  <isaacs>which is fun like the first 7 times you see it
00:36:18  <tjfontaine>ya, and it will only be at the end of a full job, not for every configuration
00:36:39  <isaacs>trevnorris: ok, reading commits again
00:37:30  <isaacs>trevnorris: so, you'd have to know to call fastEmit(event)?
00:37:37  <isaacs>trevnorris: could it fall back somehow?
00:39:13  <isaacs>bnoordhuis: which bug?
00:40:18  <trevnorris>isaacs: in all but one case, where the listener uses "this".
00:40:39  <isaacs>trevnorris: we should assume that listeners will use this
00:40:48  <trevnorris>isaacs: the perf difference is 1009923 ops/ms vs 86555 ops/ms
00:40:48  <isaacs>trevnorris: that's almost guaranteed.
00:40:53  <isaacs>ouch
00:41:04  * MI6quit (Remote host closed the connection)
00:41:05  <isaacs>though... still we're hunting rats.
00:41:09  <trevnorris>but notice, that is ms, not seconds.
00:41:14  * MI6joined
00:41:16  <isaacs>you gotta catch a lot of rats to make it worth hunting them.
00:41:18  <trevnorris>yeah, that's why i dropped it.
00:41:20  <isaacs>k.
00:41:33  <isaacs>we can investigate later if we get bored or stoned and there's nothing on tv or whatever.
00:41:36  <isaacs>:)
00:41:43  <trevnorris>lol, sounds good to me.
00:43:07  <trevnorris>isaacs: oh, and if you can figure out why test-event-emitter-remove-all-listeners is failing in that one case, i'd love to get rid of it.
00:44:00  <isaacs>trevnorris: in which case?
00:44:16  <trevnorris>isaacs: http://git.io/SJlXSw
00:44:43  <isaacs>oh, ok.
00:44:46  * isaacsshrug
00:44:57  <isaacs>ohhhh... probably it's in the middle of walking the array or something?
00:45:08  <isaacs>i guess it's a good safety measure.
00:45:19  <trevnorris>oh yeah. remoteAllListeners has a "while (Array.length)"
00:45:27  <isaacs>right
00:45:40  <isaacs>trevnorris: also, not an issue here, but in the future, we're ok in node with var hoisting
00:45:46  <isaacs>trevnorris: no need to manually declare all vars at the top
00:45:54  <isaacs>crockford is not a node committer :)
00:46:16  <trevnorris>isaacs: lol, yeah. it's for my own sanity. it's bitten me in the ass more than a couple times in the past.
00:46:32  <isaacs>we do check for leaked globals after every test.
00:46:44  <isaacs>so it's not such a huge concern.
00:46:50  <trevnorris>ah, ok.
00:46:51  <trevnorris>cool
00:46:59  <isaacs> get bitten more often by hand-hoisting
00:47:10  <isaacs>artisanally hoisted vars
00:47:26  <tjfontaine>oh man
00:47:30  <isaacs>none of this mechanical function scoping for us, no sir.
00:47:40  <isaacs>only the finest locally sourced organic variables.
00:49:25  <tjfontaine>oh multiple jobs != multiple runs
00:49:38  <MI6>nodejs-master: #37 UNSTABLE osx (3/543) windows (10/543) windows (11/543) http://jenkins.nodejs.org/job/nodejs-master/37/
00:49:54  <tjfontaine>hmm that didn't regex the arch properly
00:49:59  <MI6>joyent/libuv: Ben Noordhuis master * 7e59f9b : linux: make uv_cpu_info() handle absent procfs Return an error when read - http://git.io/RK6qLQ
00:50:01  <MI6>joyent/node: Ben Noordhuis master * 7707acd : deps: upgrade libuv to 7e59f9b - http://git.io/BIv41g
00:50:55  * MI6quit (Remote host closed the connection)
00:51:06  * MI6joined
00:51:06  <tjfontaine>it helps if you don't typo your regex, _ != +
00:51:13  * mikealjoined
00:53:17  <MI6>libuv-master: #21 UNSTABLE osx (1/183) smartos (4/183) linux (4/183) http://jenkins.nodejs.org/job/libuv-master/21/
00:53:43  <trevnorris>bnoordhuis: what do you think about abstracting a more light weight storage mechanism that could be used by buffers, array buffers and slabs?
00:54:05  <trevnorris>basically it's only purpose would be to store/retrieve data. no mutators, etc. would be in it.
01:02:24  <isaacs>trevnorris: just benchmarking now
01:02:32  <isaacs>trevnorris: everything lgtm otherwise
01:02:39  <trevnorris>coolio
01:02:50  <isaacs>i don't suspect any problems, of course, just due dilligence
01:03:21  <trevnorris>wouldn't expect any less. ;-)
01:05:51  <trevnorris>well, have to pick up dinner. be on later.
01:05:54  * trevnorrisquit (Quit: Leaving)
01:13:49  <isaacs>ircretary: tell trevnorris Ugh. As I'd feared. It's about 5% better, +- 8000%
01:13:49  <ircretary>isaacs: I'll be sure to tell trevnorris
01:14:03  <isaacs>ircretary: tell trevnorris Re-running tests on a machine that is not also my laptop
01:14:03  <ircretary>isaacs: I'll be sure to tell trevnorris
01:14:08  <MI6>joyent/node: Ben Noordhuis v0.8 * 7189b3e : crypto: don't assert when calling Cipher#final() twice Remove the assert - http://git.io/saAf3Q
01:18:20  * nodejs-ciquit
01:20:02  * sblomquit (Ping timeout: 252 seconds)
01:25:54  <bnoordhuis>curious, i remove some debug code and the program gets slower...
01:26:54  <MI6>nodejs-master: #38 UNSTABLE linux-ia32 (1/543) windows-x64 (13/543) smartos-ia32 (3/543) windows-ia32 (11/543) linux-x64 (1/543) smartos-x64 (3/543) http://jenkins.nodejs.org/job/nodejs-master/38/
01:31:41  <tjfontaine>bnoordhuis: would you be so kind to cherry pick https://github.com/joyent/node/commit/1762ba37ca810d44933ae850fd4fd00fd16be732
01:31:48  * sblomjoined
01:31:51  <tjfontaine>(back into v0.8)
01:32:45  <sblom>bnoordhuis and tjfontaine (and probably others): You need Gravatars for your github users. You're driving the color out of our commit log. :p
01:33:27  <tjfontaine>haha
01:33:34  <tjfontaine>sblom: I'll get right on that :P
01:33:45  <sblom>Nooo! Jenkins is higher prio.
01:33:57  <sblom>:)
01:34:02  <tjfontaine>hehe
01:35:47  <isaacs>bnoordhuis: you should set a gravatar that is the github avatar, but with a different color, or upside down or something
01:36:14  <isaacs>ircretary: tell trevnorris http://static.izs.me/benchmark-emulsify-vs-master.html
01:36:15  <ircretary>isaacs: I'll be sure to tell trevnorris
01:36:21  <isaacs>ok, i'm landing this thing
01:36:22  <isaacs>i dig it
01:36:38  <tjfontaine>narrowing in on it
01:36:58  <MI6>joyent/node: Trevor Norris master * d1b4dcd : events: add type checks to once Also cleanup unnecessary use of "self" s (+9 more commits) - http://git.io/7os0Zw
01:37:01  <bnoordhuis>tjfontaine: don't you rather want to unlink at test start?
01:37:17  <bnoordhuis>tjfontaine: if the test somehow fails and the exit event isn't emitted, it won't get unlinked
01:38:13  <tjfontaine>bnoordhuis: well, if the test fails I'm farked either way
01:38:24  <tjfontaine>bnoordhuis: the issue I'm having is that `git clean` on windows can't remove that file
01:39:15  <sblom>tjfontaine: I hear rumors that Cygwin git on Windows can handle long paths. We could switch, but Aaaaaa-cygwin!
01:39:28  <tjfontaine>no fuck cygwin :P
01:39:58  <tjfontaine>sblom: aren't you guys working on a first class git since you have first class support in TF?
01:39:58  <isaacs>sblom: no cygwin.
01:40:00  <isaacs>not ever.
01:40:15  <isaacs>i'll consider cygwin when it can run child processes without being a psychopath about it
01:40:36  * isaacs.oO(is psychopathic in how it refuses to kill its children... that analogy needs work)
01:40:54  <tjfontaine>heh
01:40:59  <bnoordhuis>tjfontaine: that patch won't apply
01:41:10  <sblom>isaacs: Yes. That is one of cygwin's deepest pathologies. But it's not its only one. It uses some 1990s hack for symlinks, too.
01:41:14  <tjfontaine>bnoordhuis: sigh, ok
01:41:19  <bnoordhuis>well, it does with -C0 but...
01:41:46  <bnoordhuis>doesn't look like it patches in the right place
01:43:34  * indexzeroquit (Quit: indexzero)
01:43:58  <MI6>joyent/node: bnoordhuis created branch test-unlink-path - http://git.io/b0MR7Q
01:44:08  <bnoordhuis>^ tjfontaine does that work for you?
01:44:27  <tjfontaine>yup
01:44:41  <tjfontaine>well
01:44:50  <tjfontaine>yes
01:44:55  <MI6>joyent/node: Ben Noordhuis master * 93156a6 : test: unlink temp file at test start The file has a long name that's app - http://git.io/F6_eFQ
01:45:11  <MI6>nodejs-v0.8: #8 FAILURE osx-ia32 (106/467) windows-x64 (1/467) linux-x64 (20/467) linux-ia32 (20/467) smartos-x64 (25/467) windows-ia32 (5/467) osx-x64 (2/467) smartos-ia32 (11/467) http://jenkins.nodejs.org/job/nodejs-v0.8/8/
01:45:29  <bnoordhuis>only 20 more commits to go
01:49:11  * wolfeidauquit (Remote host closed the connection)
01:49:46  * loladiroquit (Quit: loladiro)
01:49:52  <bnoordhuis>Requests/sec: 197596.14 <- hell yeah
01:50:07  <bnoordhuis>epoll in edge-triggered mode and EPOLLRDHUP is pretty awesome
01:51:20  * dapquit (Quit: Leaving.)
01:52:40  * perezdjoined
01:54:25  * arlolrajoined
01:59:19  <isaacs>bnoordhuis: nice
02:00:41  <isaacs>so, i'm very close to calling this v0.10
02:00:42  <isaacs>http://static.izs.me/benchmark-emulsify-vs-0.8.html
02:01:11  <isaacs>splitting up read() and the writable class will almost certainly get us there, i think
02:01:20  <isaacs>"almost", "i think", etc., lol
02:01:32  <MI6>nodejs-master: #39 UNSTABLE osx-x64 (2/543) windows-x64 (13/543) windows-ia32 (11/543) http://jenkins.nodejs.org/job/nodejs-master/39/
02:01:48  <isaacs>it's really intersting that we're consistently WAY faster with TLS for small chunks, but a bit slower as the chunk size gets bigger.
02:02:50  <isaacs>ircretary: tell trevnorris http://static.izs.me/benchmark-emulsify-vs-0.8.html <-- that is looking really good. we're almost there
02:02:51  <ircretary>isaacs: I'll be sure to tell trevnorris
02:08:01  * bradleymeckjoined
02:09:31  * mikealquit (Quit: Leaving.)
02:09:35  * bradleymeckquit (Client Quit)
02:15:21  * bnoordhuisquit (Remote host closed the connection)
02:21:38  * sblomquit (Ping timeout: 252 seconds)
02:21:55  <MI6>nodejs-master: #40 UNSTABLE osx-x64 (1/543) windows-x64 (12/543) osx-ia32 (2/543) windows-ia32 (10/543) linux-x64 (1/543) http://jenkins.nodejs.org/job/nodejs-master/40/
02:22:04  * perezdquit (Quit: perezd)
02:22:33  * arlolraquit (Quit: Leaving...)
02:37:47  * c4miloquit (Remote host closed the connection)
02:43:12  * arlolrajoined
03:12:27  <isaacs>hm... this is not so great: https://gist.github.com/isaacs/5069520
03:16:55  <isaacs>hm... this is not so great: https://gist.github.com/isaacs/5069520
03:18:01  <TooTallNate>isaacs: what happens?
03:18:10  <isaacs>TooTallNate: you get no response from the server.
03:21:48  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:25:15  * benoitcquit (Excess Flood)
03:27:14  <isaacs>OHHHH!!!! i ar dum
03:27:20  <isaacs>blerp baderp
03:27:28  <isaacs>client.on('response', res.on(data), etc.)
03:27:49  * benoitcjoined
03:52:10  * brsonquit (Quit: leaving)
03:54:03  * c4milojoined
04:03:56  <isaacs>OK, but THIS is definitely not behaving as i'm expecting: https://gist.github.com/5069656
04:11:27  <isaacs>hm. seems like destroySoon is too aggressive in some cases
04:11:47  * isaacschatting with the bots..
04:16:01  * TooTallNatejoined
04:20:38  <isaacs>TooTallNate: wb
04:20:43  <isaacs>TooTallNate: found the *actual* bug
04:20:48  <isaacs>https://gist.github.com/5069656
04:20:57  <TooTallNate>what's wb?
04:21:40  <TooTallNate>isaacs: i take it that does the same as the http one?
04:21:51  <isaacs>TooTallNate: wb = welcome back
04:21:57  <TooTallNate>ahhh :)
04:21:59  <isaacs>TooTallNate: well, the http one was just me being dumb.
04:22:00  <TooTallNate>thanks
04:22:05  <isaacs>TooTallNate: but this one actually is wrong.
04:22:23  <isaacs>you should be able to write a message on a socket, even after EOF.
04:22:35  * arlolraquit (Quit: Linkinus - http://linkinus.com)
04:22:38  <isaacs>but we call destroySoon on socket end, which calls socket.end()
04:22:41  <TooTallNate>i get Error: write after end
04:22:45  <isaacs>yep.
04:22:48  <isaacs>because ^
04:22:53  <TooTallNate>right...
04:23:10  <isaacs>so, what we should do, is not do that
04:23:23  <isaacs>destroySoon should only call end() if that's what you want it to do.
04:23:31  <isaacs>or maybe not at all, and we just call end() if you want to call end()
04:30:03  <TooTallNate>is this a regression with the _read cb removing patch?
04:30:10  * benoitcquit (Excess Flood)
04:38:18  * benoitcjoined
04:38:34  <isaacs>TooTallNate: no, it looks like it's pretty much always been busted like this.
04:38:38  <isaacs>ever since GH-1697
04:38:47  <isaacs>(at least)
04:39:04  <isaacs>since that test depends on this behavior, or else would not have passed in the first place.
04:39:16  <isaacs>and it's not an issue for http, because we explicitly frame everything
04:41:54  <isaacs>TooTallNate: I think it's more likely that people will call end(), which triggers finish, which calls onSocketFinish, which triggers a shutdown, which calls destroy once that finishes
04:42:02  <isaacs>so, it'll get destroyed anyway
04:42:22  <isaacs>rather than that they'll call destroySoon(), and expect it to call end() for them
04:56:29  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:11:57  * CoverSlidequit (Read error: Operation timed out)
05:15:59  * CoverSlidejoined
05:25:07  * trevnorrisjoined
05:30:30  * benoitcquit (Excess Flood)
05:33:09  * c4miloquit (Remote host closed the connection)
05:34:19  * benoitcjoined
05:41:50  * wolfeidaujoined
06:00:48  * trevnorrisquit (Ping timeout: 264 seconds)
06:09:33  * loladirojoined
06:21:06  * bradleymeckjoined
06:21:11  * bradleymeckquit (Client Quit)
06:29:35  * mikealjoined
06:30:54  * benoitcquit (Excess Flood)
06:35:19  * benoitcjoined
07:09:30  * loladiroquit (Quit: loladiro)
07:17:29  * loladirojoined
07:31:14  * benoitcquit (Excess Flood)
07:31:52  * benoitcjoined
07:41:54  * rendarjoined
07:55:16  * AvianFluquit (Remote host closed the connection)
08:27:16  * benoitcquit (Excess Flood)
08:28:25  * benoitcjoined
09:09:59  * einarosjoined
09:29:29  * stagasquit (Ping timeout: 255 seconds)
09:44:38  * loladiroquit (Quit: loladiro)
10:06:31  * `3rdEdenjoined
10:08:06  * slaskisjoined
10:17:08  * c4milojoined
10:28:27  * kevireillyjoined
10:29:40  * Kakerajoined
10:29:52  <Kakera>is libuv's common.gypi based on something?
10:30:01  <Kakera>I want the Debug/Release build configurations, but not libuv-specific stuff in it
11:22:26  * `3rdEdenquit (Remote host closed the connection)
11:26:42  * gedhibcdcjoined
11:26:43  * gedhibcdcpart
11:48:27  * hfhalgbdhjoined
11:48:27  * hfhalgbdhpart
11:52:57  * `3rdEdenjoined
12:01:50  * `3rdEdenquit (Ping timeout: 272 seconds)
12:21:55  * slaskisquit (Quit: slaskis)
12:26:08  * slaskisjoined
12:29:40  * slaskisquit (Client Quit)
12:34:17  * `3rdEdenjoined
12:40:56  * bnoordhuisjoined
12:44:02  * abraxasjoined
12:45:24  * piscisaureus_joined
12:47:19  * benoitcquit (Excess Flood)
12:48:48  * abraxasquit (Ping timeout: 264 seconds)
12:52:56  * benoitcjoined
13:03:59  * hzjoined
13:23:33  * hffchhihbjoined
13:23:33  * hffchhihbpart
13:26:10  * bnoordhuisquit (Ping timeout: 260 seconds)
13:38:24  * `3rdEdenquit (Remote host closed the connection)
14:08:54  * `3rdEdenjoined
14:17:30  * `3rdEdenquit (Ping timeout: 260 seconds)
14:18:57  * piscisaureus_quit (Ping timeout: 244 seconds)
14:23:25  * piscisaureus_joined
14:24:56  * stagasjoined
14:31:52  * benoitcquit (Excess Flood)
14:32:00  * bnoordhuisjoined
14:34:59  * bnoordhuisquit (Read error: Operation timed out)
14:37:56  * benoitcjoined
14:39:54  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner])
14:49:34  * stagasjoined
15:07:27  * c4miloquit (Remote host closed the connection)
15:34:19  * slaskisjoined
15:37:07  * AvianFlujoined
15:37:16  * bradleymeckjoined
16:00:36  * bnoordhuisjoined
16:01:00  * slaskisquit (Quit: slaskis)
16:01:33  * slaskisjoined
16:09:28  * mikealquit (Quit: Leaving.)
16:21:35  * mikealjoined
16:35:44  * mikealquit (Quit: Leaving.)
16:44:41  * abraxasjoined
16:46:14  <rendar>piscisaureus_: i have tried on windows 7 that command you gave me, but i got the same strange behavior, i'll do more test btw
16:49:08  * abraxasquit (Ping timeout: 255 seconds)
17:02:23  * mikealjoined
17:10:23  * slaskisquit (Quit: slaskis)
17:28:37  * slaskisjoined
17:32:31  * mikealquit (Quit: Leaving.)
17:35:25  <piscisaureus_>isaacs: why did you decide to add the api to EventEmitter and not EventEmitter.prototype ?
17:35:52  <piscisaureus_>I am totally not fond of this ES5 style
17:39:17  * txdvjoined
17:39:50  <tjfontaine>piscisaureus_: how's tricks?
17:40:33  <piscisaureus_>tjfontaine: good and not good.
17:40:38  <piscisaureus_>tjfontaine: but hey, I'm here :-p
17:40:52  * loladirojoined
17:40:59  <tjfontaine>hehe, well I'm glad for the good things, and am sure the not good will pass :)
17:41:23  <piscisaureus_>yeah. mostly the fact that I am pretty sick atm but it'll pass
17:42:43  <tjfontaine>ah, that's not fun at all, just a cold or worse?
17:45:24  <isaacs>piscisaureus_: because adding stuff to EE.proto makes people upset.
17:45:28  <isaacs>piscisaureus_: it's a locked API, man.
17:45:39  <piscisaureus_>damnit
17:45:43  <isaacs>piscisaureus_: i know.
17:45:57  <isaacs>piscisaureus_: hey, you know a thing or two about TCP..
17:46:05  <isaacs>piscisaureus_: without running the code, what would you expect this to do? https://gist.github.com/isaacs/5069656
17:46:05  <piscisaureus_>so who is seriously going to care?
17:46:14  <piscisaureus_>isaacs: looking
17:46:40  <isaacs>piscisaureus_: at least, the mongoose project will be busted, so we'd have to give them a heads up, and play another round of "Justify the API" like we did with domains.
17:46:48  <isaacs>piscisaureus_: not super into that.
17:47:03  <isaacs>piscisaureus_: also, i like, don't want to break them.
17:47:08  <piscisaureus_>does mongoose set their own lisenerlength?
17:47:27  <isaacs>piscisaureus_: well, they have this silly thing where you inherit from event emitters, but then also set random stuff on the object.
17:47:30  <piscisaureus_>isaacs: I think that that gist should fail because it'll write to a closed socket
17:47:35  <isaacs>so documents with a field called "domain" were getting broken
17:47:44  <piscisaureus_>isaacs: actually there's two failure modes because allowHalfOpen is not set
17:48:05  <isaacs>piscisaureus_: so, the 'end' event should close the socket, if allowHalfOpen is not set?
17:48:07  <piscisaureus_>so -- documents with "on" are not broken?
17:48:16  <isaacs>piscisaureus_: they have a list of fields that are not ok to set.
17:48:26  <isaacs>piscisaureus_: not justifying their api.
17:48:29  <isaacs>i told them it was dumb
17:48:35  <piscisaureus_>isaacs: no - a socket auto-shutdowns when it receives a FIN (aka end event)
17:49:22  <isaacs>right
17:49:23  <piscisaureus_>it's dumb
17:49:33  <isaacs>(socket fin or mongoose?)
17:49:38  <isaacs>(either way, i agree)
17:49:39  <piscisaureus_>mongoose
17:50:05  <piscisaureus_>isaacs: the client (second) connection should also err because you call .end() and then you write on the "end" event.
17:50:13  <piscisaureus_>isaacs: that is not fixed with allowHalfOpen
17:50:38  <isaacs>piscisaureus_: why should the client error?
17:51:07  <isaacs>piscisaureus_: i'm not writing to the client socket in the end event
17:51:22  <piscisaureus_>isaacs: oh - you're right
17:51:24  * piscisaureus_facepalms
17:51:27  <isaacs>k
17:51:35  <isaacs>so, if th eserver is allowHalfOpen, then what do you expect?
17:52:15  <piscisaureus_>isaacs: sec
17:52:32  <piscisaureus_>isaacs: I would expect it to work
17:52:44  <piscisaureus_>isaacs: although the order in which messages are printed should be undefined
17:52:55  <isaacs>yes
17:52:59  <piscisaureus_>since they both run in the same process and libuv and/or the networking stack can reorder events
17:53:00  <isaacs>well... no
17:53:02  <isaacs>actually
17:53:27  <isaacs>because the server doesn't write anything until the client eof's
17:53:50  <piscisaureus_>ok - let me write it down (sigh)
17:53:59  <isaacs>so the server should get all the messages, then the client gets all of them
17:54:05  <isaacs>or are you saying that the second hello can come before hte first?
17:54:33  <piscisaureus_>haha
17:55:06  <piscisaureus_>well you are right
17:55:11  <isaacs>updated gist: https://gist.github.com/isaacs/5069656
17:55:12  <piscisaureus_>in this case order should be defined
17:55:57  <piscisaureus_>isaacs: actually I was lazy because I know that sometimes ppl get bitten by this when node establishes a loopback connection to the same process.
17:55:58  <piscisaureus_>but yea
17:56:31  <isaacs>yeah, if you do client writing and server writing at the same time, then who writes first (in the same process) might be undefined
17:56:46  <MI6>nodejs-v0.8: #9 ABORTED http://jenkins.nodejs.org/job/nodejs-v0.8/9/
17:56:53  <piscisaureus_>SERVER data hello[123]
17:56:53  <piscisaureus_>SERVER data THUNDERMUSCL!
17:56:53  <piscisaureus_>SERVER message received, responding
17:57:02  <bnoordhuis>MI6: aborted?
17:57:23  <tjfontaine>bnoordhuis: I stopped a build because it was still failing
17:57:27  <bnoordhuis>ah okay
17:57:28  <piscisaureus_>CLIENT data hello[123]
17:57:28  <piscisaureus_>CLIENT data THUNDERMUSCLE!
17:57:28  <piscisaureus_>CLIENT end
17:57:31  <piscisaureus_>isaacs" ^-- that
17:57:34  <piscisaureus_>is what I expect
17:58:03  <isaacs>piscisaureus_: ok, great.
17:58:04  <isaacs>thanks
17:58:09  <isaacs>my sanity is verified.
17:58:18  <piscisaureus_>isaacs: so --- curious, what is the background of this?
17:58:38  <isaacs>well... i wrote a little simple json-headers-plus-body protocol as an example in the node api docs.
17:58:48  <isaacs>adn someone said, "Hey, that shoudl be an npm module. I actually want to use that for a thing"
17:59:01  <isaacs>so i started writing it up, and write an example for it using a tcp server.
17:59:14  <isaacs>and then was getting throws about write after end, etc.
17:59:31  <isaacs>and realized, ok, yeah, half open etc, but this api is really not intuitive.
17:59:59  <isaacs>i mean, it's kind of odd that the other side can trigger my code to call socket.end(), even while i'm in the middle of doing stuff.
18:00:09  <bnoordhuis>that's tcp for you
18:00:28  <isaacs>which means that, for a tcp server, you must constantly be checking if the socket is destroyed. or just add an error listener, I suppose, but the error is very confusing.
18:00:54  <isaacs>the error should be something like "the other side ended this connection, so get fucked", rather than "you called write() after you called end(), so get fucked"
18:01:10  <isaacs>because you see that, and you look at your code, and go "NO I DID NOT CALL END YOU LYING LIAR!"
18:01:13  <isaacs>and rage happens.
18:01:14  <bnoordhuis>that's what the OS tells you (node) though
18:01:18  <isaacs>right
18:01:32  <isaacs>i'm not arguing for changing the semantics and doing halfOpen always.
18:01:51  <isaacs>i'm arguing for detecting "closed by the other guy's FIN" and providing a better error message.
18:02:02  <isaacs>"write after end" is confusing when the write is clearly not after you called end()
18:02:16  <bnoordhuis>oh, like that - sure, no objections
18:02:41  <isaacs>also: there is kind of an odd state you can get into if the socket IS halfOpen, where it won't ever get destroyed, it looks like
18:02:56  <isaacs>oh, no, i was misreading it.
18:02:57  <isaacs>nvm
18:02:57  <bnoordhuis>how's that? you mean FIN_WAIT2?
18:03:03  <bnoordhuis>oh okay
18:03:24  <isaacs>if 'finish' happens on the writable side, and its readable side is ended, then we call destroy()
18:03:36  <isaacs>otherwise we do shutdown
18:04:26  * loladiroquit (Quit: loladiro)
18:06:22  <tjfontaine>oh
18:07:28  * bradleymeckquit (Quit: bradleymeck)
18:07:42  * c4milojoined
18:08:22  <tjfontaine>bnoordhuis: hey can we cherry pick that NODE_COMMON_PORT into v0.8 :) https://github.com/joyent/node/commit/17a812618d6135c77c060e0f6ec396fb48eec6f0
18:10:02  <MI6>joyent/node: Timothy J Fontaine v0.8 * 0b70a14 : test: optionally set common.PORT via env variable This is a back-port of - http://git.io/CN5hUw
18:10:07  <bnoordhuis>tjfontaine: no
18:10:14  <tjfontaine>:)
18:10:18  <bnoordhuis>;)
18:14:46  <isaacs>so, this is entirely a simulated error, but do you think that we should give the error a code like ECONNRESET or something?
18:14:57  <isaacs>what would you get if you DID call write() on that socket?
18:16:56  <isaacs>bnoordhuis, piscisaureus_ ^?
18:17:41  <tjfontaine>I think epipe
18:18:19  <tjfontaine>hm or rst
18:18:19  * loladirojoined
18:18:41  <bnoordhuis>isaacs: EPIPE
18:18:50  <isaacs>oh, right
18:22:54  <isaacs>https://github.com/joyent/node/pull/4894
18:26:49  * loladiroquit (Quit: loladiro)
18:29:54  <bnoordhuis>isaacs: left a comment
18:30:25  <isaacs>bnoordhuis: we call that cb right away for backward compatibility, i believe.
18:32:00  <isaacs>but it looks like that's probably just a mistake in the older code.
18:32:23  <isaacs>it's weird. we call the cb right now, but then emit error on nextTick
18:32:31  <isaacs>pre-streams2 code is so bonkers!
18:32:32  <isaacs>:)
18:32:42  <bnoordhuis>sounds like a bug, yes
18:33:40  * loladirojoined
18:34:02  <isaacs>no reason we can't fix both now :)
18:34:47  <isaacs>hrm. we have tests verifying that the throw happens right now.
18:34:53  <isaacs>the error event, that is
18:35:08  <isaacs>i guess we can nextTick just the cb, though
18:37:04  <isaacs>wild. so, fs write streams used to call the cb on nexttick, but emit now. net streams called the cb now, but emitted on next tick
18:37:10  <isaacs>consistency! we has a little!
18:38:02  <isaacs>bnoordhuis: you should watch this show: http://www.imdb.com/title/tt1695989/
18:38:16  <tjfontaine>heh
18:41:56  <bnoordhuis>just wikipediad it (is that a word)
18:41:58  <bnoordhuis>sounds fun
18:43:07  <isaacs>bnoordhuis: if you involve disturbingly uncomfortable humor and schadenfreude about lying american douchebags in europe, then it's right up your alley
18:43:14  <isaacs>s/involve/enjoy/
18:43:51  <bnoordhuis>sounds like my kind of thing :)
18:44:02  * loladiroquit (Quit: loladiro)
18:47:02  <isaacs>bnoordhuis: updated commit
18:48:29  <bnoordhuis>isaacs: it's strange and confusing that the error is emitted immediately
18:48:35  <bnoordhuis>is there a reason why it's like that?
18:53:41  * loladirojoined
18:54:19  * slaskisquit (Quit: slaskis)
18:54:27  <MI6>nodejs-v0.8: #15 UNSTABLE osx-ia32 (2/467) windows-x64 (2/467) linux-x64 (1/467) linux-ia32 (2/467) smartos-x64 (1/467) osx-x64 (1/467) smartos-ia32 (1/467) http://jenkins.nodejs.org/job/nodejs-v0.8/15/
18:54:51  <isaacs>bnoordhuis: well... so, i kinda get it.
18:54:58  <isaacs>the cb calling immediately is wrong, clearly
18:55:11  <isaacs>but emitting the error event now is an example of "report errors asap"
18:55:14  <isaacs>you already have the object, clearly
18:55:24  <isaacs>you are calling write() on it
18:55:31  <isaacs>so, you've had a fair chance to add an error listener by now.
18:55:39  <bnoordhuis>well, maybe...
18:55:58  <bnoordhuis>still, we defer error events everywhere in node
18:56:09  <isaacs>calling the cb immediately is an example of violation fo async-consistency
18:56:22  <isaacs>where do we defer error events?
18:56:45  <bnoordhuis>everywhere we get them immediately
18:56:55  <bnoordhuis>say net.connect
18:57:27  <bnoordhuis>bad example maybe because libuv always defers the error now
18:58:21  <isaacs>looks like net.js is the *only* place we defer error emission
18:58:41  <isaacs>we even have a long-standing test to verify that fs write streams throw synchronously if you call write() after end
18:58:56  <bnoordhuis>really? how... quaint
19:00:00  <isaacs>also, child process send() emits the error right now if the channel is closed
19:00:46  <bnoordhuis>looks like we have some cleanup to do
19:01:18  <isaacs>same with http, errors get emitted right away. of course, that's dependent on how sockets work, so ends up being deferred in practice.
19:02:25  <isaacs>in TLS, we emit errors sychronously, except for one that's deferred with a setImmediate() so that we guarantee not to call it in this tick.
19:03:02  <isaacs>we error immediately if you destroy() on stdout/err
19:03:11  <bnoordhuis>i stick to what i said :)
19:03:29  <bnoordhuis>if only because it makes reasoning about node's error paths easier
19:03:56  <bnoordhuis>i don't think performance is an issue here because you're on an uncommon code path anyway
19:04:37  <bnoordhuis>i would turn it around and ask when it's essential for an error to be emitted immediately
19:05:00  <bnoordhuis>i'm reasonably sure the answer is 'never'
19:07:43  <indutny>nice patches
19:08:21  <MI6>joyent/node: Raymond Feng master * 47e1150 : windows/msi: fix msi build issue with WiX 3.7/3.8 The `heat` tool that g - http://git.io/d6d9AQ
19:09:02  <isaacs>bnoordhuis: sure
19:09:22  <isaacs>bnoordhuis: that's reasonable. but we should get consistency now, and then defer all errors in another patch, i think.
19:09:44  <bnoordhuis>okay
19:09:57  <isaacs>ie, out of scope for this PR
19:17:16  <isaacs>bnoordhuis: any other comments?
19:25:04  <bnoordhuis>isaacs: no, none
19:25:10  <isaacs>k, thanks
19:26:49  <isaacs>bnoordhuis: I added a TODO comment for you.
19:26:50  <MI6>joyent/node: isaacs master * 2106ef0 : net: Provide better error when writing after FIN The stock writable stre - http://git.io/JLEs0w
19:27:05  <isaacs>bnoordhuis: not necessarily for you to do, but for someone to do to address your nexttick error concerns
19:35:59  <indutny>isaacs: better create issue
19:36:07  <isaacs>indutny: ?
19:36:11  <indutny>then TODO
19:36:12  <indutny>in code
19:36:14  <isaacs>oh, haha
19:36:19  <indutny>well, that's not funny
19:36:23  <isaacs>sure.
19:36:51  <isaacs>indutny: i'm laughing because i was already in the process of writing it up
19:36:55  <indutny>ah
19:36:56  <indutny>:)
19:41:45  <isaacs>indutny: https://github.com/joyent/node/issues/4897
19:42:16  * bnoordhuisquit (Ping timeout: 272 seconds)
19:44:35  <piscisaureus_>isaacs: "This socket has been closed by the other party" <-- not quite correct.
19:45:16  <piscisaureus_>isaacs: "This socket has been auto-closed by us because the other party sent FIN and allowHalfOpen is not enabled"
19:48:10  <isaacs>piscisaureus_: so.. yeah. i tried to make it a bit more understandable as to what's going on, without explaining how TCP works in an error message.
19:48:27  <isaacs>"this socket has been *ended* by the other party" perhaps?
19:48:31  <piscisaureus_>yes
19:48:37  <piscisaureus_>yeah that'd be better
19:48:40  <isaacs>k
19:48:42  <isaacs>i'll change it.
19:49:18  <isaacs>fwiw, the 0.8 and before error message in this case was "This socket is closed."
19:49:19  <piscisaureus_>Technically the other party can also close a socket but that's a different condition :)
19:49:23  <isaacs>even in cases where it's not actually closed.
19:49:36  <piscisaureus_>yes - bad
19:49:46  <isaacs>but, i mean, whatever, it was in teh process of closing.
19:49:52  <piscisaureus_>well actually heh :)
19:50:00  <isaacs>it was ABOUT to be closed, that's for sure :)
19:50:04  <isaacs>on nextTick
19:50:12  <piscisaureus_>:)
19:50:24  <piscisaureus_>which doesn't need to be btw
19:50:38  <piscisaureus_>I can't think of a good reason for deferring that to the next tick
19:50:45  <piscisaureus_>but maybe that's because I can't think good
19:50:46  <isaacs>yep
19:50:52  <isaacs>that's a problem. not thinking good.
19:51:01  <isaacs>that's why we have tests. so that we only have to think a little good, a little bit at a time.
19:51:17  <MI6>joyent/node: isaacs master * 4ac73d2 : net: s/closed/ended/ in write-after-fin message - http://git.io/V0VvUA
19:59:35  <isaacs>anyone wanna review this? https://github.com/isaacs/node/compare/emit-before-ctor
19:59:38  * benoitcquit (Excess Flood)
19:59:51  <isaacs>slight regression from the recent event emitter emulsify business.
20:00:13  <isaacs>calling emit() before the EventEmitter ctor raises "property of undefined" error
20:08:15  * bnoordhuisjoined
20:08:30  * benoitcjoined
20:16:29  * bnoordhuisquit (Ping timeout: 244 seconds)
20:19:12  <tjfontaine>hmm dear windows build, I don't get you
20:21:23  <MI6>nodejs-master: #41 FAILURE windows-x64 (13/500) osx-ia32 (2/543) windows-ia32 (10/543) http://jenkins.nodejs.org/job/nodejs-master/41/
20:36:03  <MI6>nodejs-master: #42 FAILURE osx-x64 (1/545) linux-ia32 (1/545) windows-x64 (13/500) osx-ia32 (2/545) smartos-ia32 (2/545) windows-ia32 (10/545) linux-x64 (2/545) smartos-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/42/
20:37:25  <tjfontaine>git clean on windows is just freaking hilarious
20:37:53  <isaacs>tjfontaine: what does it even do?
20:39:05  <tjfontaine>isaacs: mostly just fails because the rm it ships is fairly dumb (so is the python implementation of unlink for windows)
20:39:14  <isaacs>i see
20:39:19  <isaacs>can we replace it with a node version?
20:39:28  <isaacs>tjfontaine: or just replace our git clean with something that uses rimraf?
20:39:29  <tjfontaine>possibly
20:39:41  <isaacs>i mean, node is pretty good at handling long patsh
20:40:10  <tjfontaine>there's also an ms-ified git because of the tf integration, Im' going to see if that papers over the problem
20:40:34  <tjfontaine>isaacs: I just worry about mixing of node as build utility, and node as testing
20:41:20  * c4miloquit (Remote host closed the connection)
20:41:20  <isaacs>well... we could have a node build that just is there for the benefit of a rimraf script
20:41:26  <isaacs>and never gets touched
20:41:29  <tjfontaine>nod
20:41:31  <isaacs>just another thing on the os
20:42:06  <tjfontaine>winders is my nemesis
20:43:24  * brsonjoined
20:53:38  * nodejs-cijoined
20:54:08  * nodejs-ciquit (Client Quit)
20:54:56  * nodejs-cijoined
20:56:04  * nodejs-ciquit (Client Quit)
20:59:47  * piscisaureus_quit (Ping timeout: 248 seconds)
21:27:26  * mmaleckichanged nick to mmalecki[zzz]
21:37:51  * mikealjoined
21:50:31  * indexzerojoined
21:52:49  * bnoordhuisjoined
22:01:40  <bnoordhuis>tjfontaine: i think simple/test-dgram-pingpong is failing because it uses hardcoded port numbers
22:01:51  <bnoordhuis>or rather, sometimes failing
22:02:21  <bnoordhuis>easy to fix though
22:06:12  <MI6>joyent/node: Ben Noordhuis v0.8 * 426cbed : test: make simple/test-dgram-pingpong respect PORT Don't use hard-coded - http://git.io/LMQBmA
22:07:39  <tjfontaine>bnoordhuis: oh excellent
22:09:02  <tjfontaine>bnoordhuis: I guess that needs to go to master as well?
22:09:43  * MI6quit (Remote host closed the connection)
22:10:08  <tjfontaine>oh for fucks sake jenkins
22:12:21  * MI6joined
22:14:02  <MI6>joyent/node: Ben Noordhuis master * 2d51036 : Merge remote-tracking branch 'origin/v0.8' Conflicts: doc/api/http.mark (+6 more commits) - http://git.io/k9AvFQ
22:14:08  <bnoordhuis>tjfontaine: ^ :)
22:14:17  <tjfontaine>thanks :)
22:16:40  <tjfontaine>jenkins is angry with me at the moment of course
22:25:45  * piscisaureus_joined
22:34:35  <MI6>nodejs-v0.8: #19 UNSTABLE linux-x64 (2/467) osx-ia32 (1/467) smartos-ia32 (1/467) windows-x64 (2/467) windows-ia32 (4/467) osx-x64 (2/467) smartos-x64 (1/467) linux-ia32 (2/467) http://jenkins.nodejs.org/job/nodejs-v0.8/19/
22:38:18  <bnoordhuis>tjfontaine: http://jenkins.nodejs.org/job/nodejs-v0.8/19/testReport/ <- are the failing tests supposed to be listed?
22:39:03  <tjfontaine>they are supposed to be on the overview page, but for whatever reason the tap plugin hates my life
22:39:12  <bnoordhuis>ah okay
22:39:46  <tjfontaine>I haven't wanted to look at the java yet to figure out why
22:40:54  <tjfontaine>I mean they're clearly there on the actual configuration page http://jenkins.nodejs.org/job/nodejs-v0.8/19/DESTCPU=x64,label=linux/tapTestReport/
22:41:32  <tjfontaine>knowing everything else I've seen about jenkins and plugins this is more than likely a deficiency in the fact that I'm using a matrix build (one job, multiple configurations)
22:42:01  * mikealquit (Quit: Leaving.)
22:42:22  <isaacs>bnoordhuis: did you fix https://github.com/joyent/node/issues/4885 or am i thinking of something else? re: simple/test-child-process-fork-getconnections
22:42:26  <isaacs>Edit
22:42:34  <isaacs>whoa, aggressive copy from github page :_)
22:42:45  <bnoordhuis>isaacs: no, i couldn't reproduce it last night
22:43:00  <isaacs>ok
22:43:00  <bnoordhuis>i only tried it for 30s or so
22:43:13  <isaacs>oh, rihgt, now i remember
22:43:20  <isaacs>yeah, it only seems to happen when the machine is busy with somethign
22:43:31  <isaacs>try running `make bench` in a separate tab
22:44:20  <bnoordhuis>`make -j4` in the v8 dir also does it, it seems :)
22:44:27  <MI6>nodejs-master: #43 FAILURE windows-x64 (13/500) linux-ia32 (1/545) linux-x64 (1/545) windows-ia32 (10/545) osx-x64 (2/545) http://jenkins.nodejs.org/job/nodejs-master/43/
22:51:51  * loladiroquit (Quit: loladiro)
22:54:48  * Kakeraquit (Ping timeout: 264 seconds)
23:01:51  <MI6>joyent/node: isaacs master * d345c11 : events: Handle emit before constructor call - http://git.io/xM-_Rg
23:03:06  * loladirojoined
23:04:17  * loladiroquit (Client Quit)
23:05:37  * rendarquit
23:06:54  * loladirojoined
23:09:10  * indexzeroquit (Quit: indexzero)
23:10:06  * loladiroquit (Client Quit)
23:12:14  * mikealjoined
23:13:04  <MI6>nodejs-master: #44 FAILURE windows-x64 (13/500) windows-ia32 (10/545) osx-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/44/
23:13:23  * benoitcquit (Excess Flood)
23:13:36  <isaacs>oh, whoops.
23:13:48  <isaacs>bnoordhuis: review? https://github.com/isaacs/node/commit/63edde0e01e577691002c2f2e39fb30abccec1bc
23:19:01  * benoitcjoined
23:25:40  * indexzerojoined
23:47:54  * loladirojoined