00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:51  <tjfontaine>(unix) green build http://jenkins.nodejs.org/job/nodejs-v0.10/188/
00:03:39  <MI6>joyent/libuv: Bert Belder master * 961202d : Merge branch 'v0.10' (+8 more commits) - http://git.io/TiKqMA
00:05:12  <MI6>libuv-v0.10-gyp: #26 UNSTABLE smartos-x64 (4/186) windows-ia32 (3/187) windows-x64 (4/187) smartos-ia32 (4/186) osx-ia32 (1/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/26/
00:07:55  <MI6>joyent/libuv: isaacs created tag v0.11.2 - http://git.io/gdbVog
00:10:16  * bnoordhuisquit (Ping timeout: 246 seconds)
00:11:23  <MI6>joyent/libuv: piscisaureus created tag v0.11.3 - http://git.io/DaOdkg
00:11:26  <MI6>joyent/libuv: Bert Belder master * adc79ba : Now working on v0.11.4 (+1 more commits) - http://git.io/UQ2k0g
00:12:01  <MI6>libuv-node-integration: #54 UNSTABLE osx-x64 (1/584) osx-ia32 (2/584) smartos-x64 (2/584) linux-ia32 (1/584) http://jenkins.nodejs.org/job/libuv-node-integration/54/
00:14:11  <MI6>joyent/node: Bert Belder master * 7934825 : uv: upgrade to v0.11.3 - http://git.io/ZP99Rw
00:14:25  <MI6>nodejs-v0.10: #189 UNSTABLE smartos-x64 (2/584) linux-ia32 (1/584) linux-x64 (1/584) http://jenkins.nodejs.org/job/nodejs-v0.10/189/
00:16:36  <MI6>libuv-master-gyp: #32 FAILURE smartos-x64 (2/188) windows-ia32 (3/189) osx-ia32 (1/189) smartos-ia32 (4/188) http://jenkins.nodejs.org/job/libuv-master-gyp/32/
00:18:29  <MI6>libuv-master: #93 UNSTABLE windows (4/189) osx (1/189) smartos (2/188) http://jenkins.nodejs.org/job/libuv-master/93/
00:20:46  * qardquit (Quit: Leaving.)
00:21:40  * mikealquit (Quit: Leaving.)
00:23:56  * groundwaterquit (Quit: groundwater)
00:26:06  <MI6>libuv-master-gyp: #33 UNSTABLE smartos-x64 (2/188) windows-ia32 (3/189) smartos-ia32 (4/188) windows-x64 (3/189) http://jenkins.nodejs.org/job/libuv-master-gyp/33/
00:27:37  <MI6>libuv-master: #94 UNSTABLE windows (3/189) smartos (2/188) linux (1/188) http://jenkins.nodejs.org/job/libuv-master/94/
00:28:10  * abraxasjoined
00:32:34  * abraxasquit (Ping timeout: 245 seconds)
00:33:18  <MI6>libuv-node-integration: #55 UNSTABLE osx-x64 (1/584) smartos-ia32 (5/584) osx-ia32 (1/584) smartos-x64 (4/584) http://jenkins.nodejs.org/job/libuv-node-integration/55/
00:33:35  * loladirojoined
00:33:39  * kazuponjoined
00:35:46  * mikealjoined
00:37:38  * bnoordhuisjoined
00:38:16  * kazuponquit (Ping timeout: 246 seconds)
00:44:55  * bnoordhuisquit (Ping timeout: 246 seconds)
00:45:13  <MI6>nodejs-master: #216 UNSTABLE smartos-x64 (12/596) osx-x64 (1/596) linux-ia32 (3/596) linux-x64 (4/596) smartos-ia32 (4/596) http://jenkins.nodejs.org/job/nodejs-master/216/
00:45:46  * inolenquit (Quit: Leaving.)
00:53:10  <MI6>libuv-node-integration: #56 UNSTABLE osx-x64 (1/596) smartos-ia32 (13/596) osx-ia32 (1/596) smartos-x64 (2/596) linux-ia32 (1/596) linux-x64 (1/596) http://jenkins.nodejs.org/job/libuv-node-integration/56/
00:56:45  * luxigojoined
00:58:34  * hzquit
01:03:11  * icarotjoined
01:03:28  <MI6>nodejs-master-windows: #26 UNSTABLE windows-x64 (8/596) windows-ia32 (9/596) http://jenkins.nodejs.org/job/nodejs-master-windows/26/
01:04:01  * kazuponjoined
01:04:51  * kazuponquit (Remote host closed the connection)
01:12:01  * kevinswiberjoined
01:19:15  <MI6>libuv-node-integration: #57 UNSTABLE osx-x64 (3/596) smartos-ia32 (100/596) osx-ia32 (91/596) smartos-x64 (5/596) linux-ia32 (2/596) http://jenkins.nodejs.org/job/libuv-node-integration/57/
01:20:59  * timoxleyjoined
01:34:10  * mikealquit (Quit: Leaving.)
01:35:00  * dannycoatesquit (Remote host closed the connection)
01:39:26  * AvianFluquit (Remote host closed the connection)
01:40:51  * abraxasjoined
01:45:40  * perezdjoined
01:46:24  * piscisaureus_quit (Ping timeout: 252 seconds)
02:10:19  * luxigoquit (Remote host closed the connection)
02:13:55  * AvianFlujoined
02:15:35  * kazuponjoined
02:20:20  * kazuponquit (Ping timeout: 256 seconds)
02:25:25  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:38:06  * st_lukejoined
02:53:04  * kevinswiberquit (Remote host closed the connection)
02:53:37  * kevinswiberjoined
02:56:22  * icarotquit (Ping timeout: 276 seconds)
02:58:18  * kevinswiberquit (Ping timeout: 264 seconds)
03:00:26  * timoxleyquit (Quit: Computer has gone to sleep.)
03:13:58  * Raynos_changed nick to Raynos
03:20:15  * mikealjoined
03:24:02  * st_lukequit (Remote host closed the connection)
03:26:44  * inolenjoined
03:41:30  * kazuponjoined
03:48:49  * timoxleyjoined
03:54:10  * brsonquit (Quit: leaving)
04:11:14  * mikealquit (Quit: Leaving.)
04:29:28  * normanmjoined
04:32:39  * defunctzombie_zzchanged nick to defunctzombie
04:55:55  * defunctzombiechanged nick to defunctzombie_zz
04:59:58  * benoitcquit (Excess Flood)
05:00:25  * mikealjoined
05:00:38  * txdvquit (*.net *.split)
05:00:39  * indutnyquit (*.net *.split)
05:00:46  * mikealquit (Client Quit)
05:01:42  * mikealjoined
05:03:09  * mikealquit (Client Quit)
05:03:29  * txdvjoined
05:03:29  * indutnyjoined
05:07:02  * benoitcjoined
05:14:55  * benoitcquit (Excess Flood)
05:17:33  * benoitcjoined
05:39:21  * stagasjoined
05:44:20  * stagasquit (Ping timeout: 252 seconds)
05:51:30  * stagasjoined
05:57:14  * AvianFluquit (Remote host closed the connection)
05:59:14  * stolsmajoined
06:08:26  * bajtosjoined
06:13:35  * rendarjoined
07:01:12  * timoxleyquit (Quit: Computer has gone to sleep.)
07:10:39  * kuebkjoined
07:11:14  * wolfeidauquit (Remote host closed the connection)
07:14:26  * kazuponquit (Remote host closed the connection)
07:15:09  * `3rdEdenjoined
07:21:00  * qardjoined
07:25:43  * timoxleyjoined
07:25:51  * wolfeidaujoined
07:25:52  * kazuponjoined
07:28:14  * wolfeidauquit (Remote host closed the connection)
07:28:38  * luxigojoined
07:34:32  * csaohjoined
07:37:13  * qardquit (Quit: Leaving.)
07:47:18  * kuebkpart
07:57:19  * kuebkjoined
07:57:24  * kuebkpart
08:00:20  * `3rdEdenquit (Ping timeout: 256 seconds)
08:04:09  * `3rdEdenjoined
08:09:06  * `3rdEdenchanged nick to `3E|BRB
08:22:21  * stolsmaquit (Ping timeout: 252 seconds)
08:26:50  * piscisaureus_joined
08:47:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
08:51:18  * wolfeidaujoined
09:02:15  * loladiroquit (Quit: loladiro)
09:16:37  * csaohquit (Ping timeout: 252 seconds)
09:36:22  * csaohjoined
09:41:59  * bajtosquit (Quit: bajtos)
09:51:02  * `3E|BRBchanged nick to `3E
10:18:04  * hzjoined
10:28:46  * luxigoquit (Ping timeout: 276 seconds)
10:35:05  * luxigojoined
10:43:00  * abraxasquit (Remote host closed the connection)
10:44:37  * bajtosjoined
10:45:16  * stagas_joined
10:47:44  * kazuponquit (Remote host closed the connection)
10:49:21  * csaohquit (Quit: csaoh)
10:53:31  * stolsmajoined
10:58:15  * bajtosquit (Quit: bajtos)
11:05:20  * csaohjoined
11:06:50  * dominictarrjoined
11:17:57  * timoxleyquit (Quit: Computer has gone to sleep.)
11:28:52  * wolfeidauquit (Ping timeout: 256 seconds)
11:36:47  * stagas_quit (Ping timeout: 256 seconds)
11:37:56  * c4milojoined
11:56:38  * `3Equit (Ping timeout: 256 seconds)
11:58:20  * kazuponjoined
12:03:43  * kazuponquit (Ping timeout: 260 seconds)
12:04:10  * `3Ejoined
12:10:03  * kazuponjoined
12:17:39  * kuebkjoined
12:17:52  <kuebk>hi
12:18:00  <kuebk>how can i read v8.log?
12:20:27  * benoitcquit (Changing host)
12:20:27  * benoitcjoined
12:47:45  * c4miloquit (Remote host closed the connection)
12:49:00  * c4milojoined
13:03:28  * c4miloquit (Remote host closed the connection)
13:16:10  * kevinswiberjoined
13:24:34  * pachetjoined
13:25:09  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
13:40:37  <indutny>kuebk: using tick-processor npm module
13:40:40  <indutny>hi
13:41:35  * kazuponquit (Remote host closed the connection)
13:43:35  * stolsmaquit (Ping timeout: 260 seconds)
13:43:51  * bnoordhuisjoined
13:45:58  * c4milojoined
13:46:48  * kenperkinsjoined
13:49:59  * bajtosjoined
14:12:37  * bnoordhuisquit (Ping timeout: 256 seconds)
14:16:00  <kuebk>indutny: thx
14:32:09  * c4miloquit (Remote host closed the connection)
14:33:01  * kazuponjoined
14:35:12  * groundwaterjoined
14:39:27  * c4milojoined
14:41:21  * hzquit
14:42:45  * normanmquit (Quit: Computer has gone to sleep.)
14:48:11  * saghul_joined
14:51:03  * saghul_quit (Client Quit)
14:53:38  * saghul_joined
14:55:28  * kazuponquit (Remote host closed the connection)
14:56:16  * saghul_quit (Client Quit)
14:56:27  * c4miloquit (Remote host closed the connection)
14:56:56  * c4milojoined
15:01:23  * c4miloquit (Ping timeout: 245 seconds)
15:11:25  * kenperkinsquit (Quit: Computer has gone to sleep.)
15:11:29  * c4milojoined
15:14:47  * bajtosquit (Quit: bajtos)
15:15:30  * timoxleyjoined
15:16:03  * `3Equit (Remote host closed the connection)
15:19:17  * bnoordhuisjoined
15:22:00  * saghul_joined
15:22:25  * saghul_quit (Client Quit)
15:23:45  * bnoordhuisquit (Ping timeout: 256 seconds)
15:24:12  * timoxleyquit (Quit: Computer has gone to sleep.)
15:27:57  * kuebkpart
15:35:09  * bajtosjoined
15:36:29  * paddybyersjoined
15:41:46  * bnoordhuisjoined
15:49:31  * AvianFlujoined
16:00:32  <tjfontaine>good morning folks
16:00:47  <tjfontaine>or General UTC Greeting as it were
16:03:19  * bnoordhuisquit (Ping timeout: 246 seconds)
16:04:25  * TooTallNatejoined
16:05:56  * kazuponjoined
16:11:31  * kazuponquit (Ping timeout: 260 seconds)
16:12:18  <isaacs>whoa, lots of MI6 in the backlog
16:12:31  <tjfontaine>all berts fault
16:12:34  <isaacs>ahah
16:12:53  <isaacs>i guess usually the conversation is happening in the channel as well, and this time it was in meatspace
16:13:02  <tjfontaine>yup
16:13:16  <isaacs>off to have my eyeballs poked at
16:13:27  <isaacs>?me &
16:13:30  * isaacs&
16:13:30  <LOUDBOT>BACK TO THE BASICS. THE STREETS REQUIRE IT JERRY
16:14:49  * wavdedjoined
16:14:53  * kenperkinsjoined
16:15:01  * kenperkinsquit (Client Quit)
16:19:37  * dominictarrquit (Quit: dominictarr)
16:19:53  <trevnorris>morning
16:21:49  * qardjoined
16:23:28  * dannycoatesjoined
16:26:29  <trevnorris>mmalecki: ping
16:27:30  <mmalecki>trevnorris: pong :)
16:27:44  <mmalecki>trevnorris: oh damn, yeah, I forgot. I'm a terrible human being
16:27:55  <trevnorris>mmalecki: so i've done some interesting work on the no slab allocator thing
16:27:59  <mmalecki>but if you link me again, I'll make sure this ends up on one of our load balancers
16:28:02  <trevnorris>mmalecki: was thinking it might be of use to you
16:28:11  <mmalecki>link please :)
16:28:52  <mmalecki>AvianFlu: fyi, I'll be deploying a change involving slab allocators from trevnorris to one of LBs
16:29:03  <trevnorris>mmalecki: http://git.io/k_kCxw
16:29:28  <trevnorris>mmalecki: so that removes the SlabAllocator completely, but there is one more change that may be of use.
16:29:53  <trevnorris>mmalecki: I've added a "buffer.dispose()' method that will allow you to zero out a buffer immediately.
16:30:18  <mmalecki>ohhhh, damn, that'd be really useful
16:30:22  <trevnorris>mmalecki: benchmarks show +35% increase in throughput in some cases when the incoming buffer is immediately disposed.
16:30:37  <mmalecki>since we buffer stuff and then count on GC to dispose the buffer
16:30:47  <mmalecki>yeah, that's wonderful
16:31:17  <trevnorris>cool. it's documented w/ examples. still experimental though, but stable as of last night. ;-)
16:43:41  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:50:42  * bnoordhuisjoined
16:51:56  * `3rdEdenjoined
16:54:38  * inolenquit (Quit: Leaving.)
16:54:40  <tjfontaine>bnoordhuis: I'm glad you responded to that gentoo issue, I'm not sure I could have resisted the troll
16:54:47  <trevnorris>bnoordhuis: will 5482 be a hot patch for 10.6? (i.e. is the problem sever enough that it would need to be)
16:55:14  <bnoordhuis>tjfontaine: he probably just doesn't know any better
16:55:18  <bnoordhuis>trevnorris: yes
16:55:26  <bnoordhuis>kind of a shame that slipped through
16:55:44  <tjfontaine>there was already a plan for 10.7 on thusrday anyway
16:56:28  <trevnorris>bnoordhuis: i might add that there should be a test in test-buffer.js. since "Buffer('', 'buffer')" causes an assertion fail.
16:56:47  <bnoordhuis>trevnorris: yeah. my patch fixes that but Buffer('', 'buffer') is not valid in itself
16:56:57  <bnoordhuis>i guess i can add a test that checks that it throws an exception
16:57:11  <bnoordhuis>i'll just do that
16:57:30  <trevnorris>yeah. i think throwing is better than allowing the user to do something that triggers an assert error from js
16:59:13  <bnoordhuis>added and pushed
16:59:51  * TooTallNatejoined
17:00:45  <trevnorris>bnoordhuis: help clear something up. you're placing the "case BUFFER" along side BINARY, but "Buffer('', 'binary')" just returns a zero length buffer. so how's that throw going to happen? (i'm going to grab and build now)
17:01:11  * mikealjoined
17:01:58  <trevnorris>wtf. why is there a "V0.10" branch?
17:03:09  <tjfontaine>heh, typo by bert it seems
17:03:26  <bnoordhuis>ah, that explains the weird mismatch i was seeing
17:03:54  <tjfontaine>I guess you can blame me for not seeing it as I was sitting beside him
17:03:57  <bnoordhuis>trevnorris: it throws because buf.write() doesn't know about buffer encoding
17:04:19  <trevnorris>bnoordhuis: ah, thrown before reaching cc. duh. thanks.
17:06:22  * mikealquit (Quit: Leaving.)
17:08:08  <tjfontaine>so who's going to fix the branch issue?
17:10:24  <bnoordhuis>tjfontaine: i guess i'll do it
17:10:40  * amartensjoined
17:11:24  <bnoordhuis>they're identical, it seems
17:12:06  <tjfontaine>hm? v0.10 on github says isaacs upgraded to uv 10.6, but V0.10 says bert upgraded to 10.7
17:13:00  <bnoordhuis>in that case i hope i just didn't break something :-/
17:13:10  <bnoordhuis>Your branch is ahead of 'origin/v0.10' by 214 commits.
17:13:41  <bnoordhuis>origin/v0.10 is v0.10.0...
17:13:58  <bnoordhuis>shall i just push it?
17:14:23  <tjfontaine>that seems suspect, but I'm not sure why
17:14:48  <bnoordhuis>i bet someone typoed when pushing
17:14:52  <bnoordhuis>anyway, here goes
17:15:07  <MI6>joyent/node: Bert Belder v0.10 * 6bcf51e : uv: upgrade to v0.10.7 - http://git.io/jDql0A
17:15:18  <tjfontaine>looks clean
17:15:27  <bnoordhuis>yep, it was a fast forward
17:21:16  <trevnorris>anyone have an issue w/ me deleting the V0.10 branch?
17:21:45  <tjfontaine>I say go for it, we don't need that sort of confusion
17:23:59  <bnoordhuis>trevnorris: too late!
17:24:13  <trevnorris>bnoordhuis: heh, noticed that. :)
17:24:24  <TooTallNate>tjfontaine: it would maybe be cool if we exposed these bleeding edge builds for people who want them
17:24:40  <tjfontaine>TooTallNate: specifically for pi or all?
17:24:58  * csaohquit (Quit: csaoh)
17:25:38  <TooTallNate>tjfontaine: all
17:25:57  <tjfontaine>ya, right now they're only in ~tj/archive/node on www.nodejs.org
17:26:05  <TooTallNate>idk, there's random times when i wanna try master but am too lazy to pull+build :p
17:26:17  <MI6>nodejs-v0.10: #190 UNSTABLE linux-ia32 (1/584) smartos-x64 (1/584) http://jenkins.nodejs.org/job/nodejs-v0.10/190/
17:26:21  <TooTallNate>oh, nice little home dir :P
17:26:41  <tjfontaine>ya, it also generates a debian repo, but I need to split it up into a few
17:26:41  <TooTallNate>404s anyways :(
17:26:51  <TooTallNate>http://www.nodejs.org/~tj/archive/node ?
17:27:08  <tjfontaine>don't think the nginx has userdir's enabled
17:27:29  * c4miloquit (Remote host closed the connection)
17:28:33  <tjfontaine>I guess we have enough generated that we could replace the nightlies url and move that into place
17:28:59  <TooTallNate>what's the nightlies url?
17:29:39  <tjfontaine>jenkins.nodejs.org/nightlies but the upload to www is going to supersede that
17:30:48  <tjfontaine>it takes a while to load because it asks jenkins to generate the list
17:34:01  <tjfontaine>TooTallNate: http://nodejs.org/dist/nightlies/
17:35:14  * loladirojoined
17:36:23  <TooTallNate>tjfontaine: nice dude!
17:36:31  <TooTallNate>tjfontaine: well that was easy/quick :)
17:36:47  <tjfontaine>just symlink'd it, hopefully that doesn't fuck any of the version managers
17:37:20  <TooTallNate>i'd think not
17:37:26  <TooTallNate>but ya, hopefully :)
17:37:42  <TooTallNate>tjfontaine: so jenkins does `make pkg` for osx ?
17:37:47  <tjfontaine>yup
17:37:59  <TooTallNate>that's probably a good idea
17:38:05  <tjfontaine>these are all unsigned of course
17:38:08  <TooTallNate>since that's what most users will be getting
17:38:10  <TooTallNate>right right
17:38:14  * inolenjoined
17:38:30  * AvianFluquit (Remote host closed the connection)
17:38:30  <TooTallNate>tjfontaine: so for osx 32-bit tests does it do `arch -x86 node test` or whatever?
17:38:36  <TooTallNate>or how does it run the 32-bit version
17:38:37  <TooTallNate>?
17:38:50  * mikealjoined
17:39:06  <tjfontaine>well, `make pkg` is a separate job from the normal CI work
17:39:39  <tjfontaine>normal CI operation we have a subjob for ia32 and x64, so it builds each and then uses that binary for the tests
17:41:25  * brsonjoined
17:51:28  * isaacsfg
17:51:53  <tjfontaine>wb
17:52:16  <tjfontaine>isaacs: so you're up to date, I symlink'd my nightlies dump into the /dist/ dir
17:52:23  <isaacs>tjfontaine: so, i think, asap, we should move at least the nightlies into manta
17:52:32  <isaacs>eventually the entire dist/
17:52:43  <tjfontaine>isaacs: yes, that's kinda why I didn't do it before
17:52:52  <isaacs>but for now, i mean, whatever.
17:52:54  <isaacs>that's fine
17:53:03  <tjfontaine>k
17:56:42  <MI6>nodejs-v0.10-windows: #20 UNSTABLE windows-ia32 (9/584) windows-x64 (10/584) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/20/
18:13:04  <trevnorris>isaacs: have a few questions regarding the slaballocator changes when you have a min
18:16:15  <trevnorris>bnoordhuis: since i'm there, cool if I close 5482?
18:19:19  <tjfontaine>once he lands the fix?
18:20:20  <trevnorris>tjfontaine: oh, missed that the commit is from his remote and not from core :P
18:20:29  <tjfontaine>hehe
18:33:23  * hueniverse1quit (Quit: Leaving.)
18:33:44  * hueniversejoined
18:41:11  <tjfontaine>bnoordhuis: btw there was a group of 7 ticket closings that came from you right when you were investigating the duplicate branch issue
18:43:01  <bnoordhuis>yeah, somehow github thinks i've closed them
18:45:40  <bnoordhuis>i can't reopen my own pull request :-/
18:45:54  <tjfontaine>which one?
18:46:02  <bnoordhuis>https://github.com/joyent/node/pull/5483
18:46:19  <tjfontaine>uh, I can't open it either
18:46:47  <bnoordhuis>i'll resubmit it
18:47:37  <bnoordhuis>weird, i can reopen my other PR
18:48:01  <tjfontaine>you've confused github somehow
18:48:01  <trevnorris>bnoordhuis: it's because you selected to merge to "joyent:V0.10" instead of "joyent/v0.10"
18:48:10  <tjfontaine>ah
18:49:06  <bnoordhuis>right
18:49:32  <bnoordhuis>still weird though, the other pull requests are against v0.10
18:50:03  <tjfontaine>this is another point that we should be able to change the target branch for a PR
18:59:39  * mikealquit (Quit: Leaving.)
19:06:55  <MI6>joyent/node: Ryan Graham v0.10 * 1deeab2 : doc: improve exports/module.exports consistency (+1 more commits) - http://git.io/lcywcQ
19:08:39  * hzjoined
19:12:18  * stagasquit (Read error: Connection reset by peer)
19:14:09  <tjfontaine>bnoordhuis: you ok with https://github.com/joyent/node/pull/5325 getting merged now?
19:14:31  * sblomjoined
19:14:57  * c4milojoined
19:16:40  <tjfontaine>sblom: btw, bert made a change for child process creation, if you could make sure it doesn't raise any flags for you https://github.com/joyent/libuv/commit/415f4d3e4c7ac25abf723eed3f5b40e63e045785
19:22:11  <bnoordhuis>tjfontaine: provided it works, yes
19:25:47  <MI6>joyent/node: Ben Noordhuis master * 3afa5e6 : deps: reapply c-ares floating patch - http://git.io/q4BC_A
19:26:09  <brson>would it be 'bad' (in any sense) if for all tcp handles created in rust we also create an async handle?
19:30:00  * mikealjoined
19:31:40  <trevnorris>mmalecki: just a heads up. i'm keeping that branch current-as-possible so expect plenty of force pushes
19:33:32  <bnoordhuis>brson: no. but why would you want to do that?
19:35:09  * indexzerojoined
19:38:18  <brson>bnoordhuis: it has to do with our scheduler design and task migration. our scheduler is driven by the uv event loop and tasks can migrate between schedulers (threads) and i/o handles may be sent between tasks. if a task goes to use a uv handle and sees that it is running on a different scheduler (and event loop) than the one the handle was created on then it needs to arrange to be rescheduled on a different thread
19:38:27  <brson>bnoordhuis: and the way schedulers communicate is through async handles
19:38:38  <brson>so every i/o object needs a handle to it's 'home' scheduler
19:38:41  * mikealquit (Ping timeout: 252 seconds)
19:38:48  <brson>bnoordhuis: does that sound sane so far?
19:39:06  <bnoordhuis>brson: i think so :)
19:39:24  <brson>i could also share an async handle under a mutex. i don't know which approach is better
19:39:45  <MI6>nodejs-master: #217 UNSTABLE smartos-ia32 (3/596) osx-x64 (1/596) smartos-x64 (4/596) http://jenkins.nodejs.org/job/nodejs-master/217/
19:42:57  <bnoordhuis>brson: async handles are relatively cheap so it wouldn't bother with mutexes
19:43:25  <brson>bnoordhuis: ok, i'm glad to hear that
19:43:36  <brson>bnoordhuis: thanks for your help again
19:44:28  <MI6>nodejs-v0.10-windows: #21 UNSTABLE windows-ia32 (10/584) windows-x64 (10/584) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/21/
19:46:02  <bnoordhuis>brson: quick question, how many async handles do you expect there will be per loop?
19:46:23  <bnoordhuis>i ask because libuv needs to do a linear scan for pending handle
19:46:25  <bnoordhuis>*handles
19:48:39  * c4miloquit (Remote host closed the connection)
19:48:48  <brson>bnoordhuis: as many as there are other handles. if we can do 10,000 tcp sockets then 10,000 async handles
19:49:15  <brson>+ a few others for various purposes, but these are the bulk
19:50:17  <bnoordhuis>brson: okay. it should not really be a problem
19:50:30  <bnoordhuis>even on a slow os x machine, we can process over 1M async handles/second
19:50:48  <bnoordhuis>my main linux dev machine does about 15M/second, i think
19:50:58  <bnoordhuis>still, it's something we should optimize some day
19:51:17  <brson>bnoordhuis: i assume that is a lot larger than the number of tcp sockets i should expect?
19:51:54  <bnoordhuis>brson: yes, unless you're aiming for the C10M problem :)
19:53:32  * bajtospart
19:58:53  * indexzeroquit (Quit: indexzero)
20:02:01  * perezdquit (Quit: perezd)
20:03:03  * c4milojoined
20:06:25  * mikealjoined
20:06:42  <trevnorris>bnoordhuis: so currently when a connection is piped, does the data come into node as a Buffer, then the Buffer is written out to the destination?
20:07:11  <trevnorris>just at face value, that's how the source looks. just want to verify.
20:10:31  * mikealquit (Ping timeout: 240 seconds)
20:14:48  <sblom>tjfontaine: took a look at the process creation change. I like it. I left a question for piscisaureus_ on the PR. I can't think of a good way to answer it, so I think it's mostly academic.
20:16:35  <tjfontaine>sblom: hm so you mean what happens to process C is spawned from B after being spawned from A?
20:17:54  <bnoordhuis>trevnorris: correct
20:18:45  <trevnorris>bnoordhuis: would it be possible to do a "pass through pipe" which skips the step of writing data to a Buffer and instead writing it out directly to the destination from cc-land?
20:22:28  <sblom>tjfontaine: Yep--that's the scenario.
20:24:13  <MI6>nodejs-master-windows: #27 UNSTABLE windows-x64 (8/596) windows-ia32 (9/596) http://jenkins.nodejs.org/job/nodejs-master-windows/27/
20:24:54  <bnoordhuis>trevnorris: yes, that's the splice concept. we haven't gotten around to that yet
20:25:59  <trevnorris>bnoordhuis: cool. just wanted to see if it was plausible. looking for something else to do after this buffer patch lands. :)
20:27:18  <tjfontaine>oh we need to update the cares.gyp
20:27:47  * `3rdEdenquit (Remote host closed the connection)
20:33:19  * wolfeidaujoined
20:33:19  * dannycoatesquit (Read error: Connection reset by peer)
20:34:09  * mikealjoined
20:35:35  <bnoordhuis>tjfontaine: how so?
20:36:20  <tjfontaine>src/inet_net_pton.h and inet_ntop.h have been replaced by a single exported header
20:36:32  <tjfontaine>so gyp whines that the files are missing
20:37:58  <bnoordhuis>tjfontaine, trevnorris: you're officially reviewers now, like it or not
20:38:15  <tjfontaine>ok, I will lgtm the lookup event one :)
20:38:27  <bnoordhuis>tjfontaine: curious, it's not complaining for me
20:38:32  <bnoordhuis>but i'll fix it
20:38:34  <tjfontaine>it's complaining on windows
20:38:47  <trevnorris>bnoordhuis: closed my first bug today. =)
20:38:48  <tjfontaine>could be msbuild though
20:40:02  <bnoordhuis>trevnorris: very good. that many more may follow
20:40:14  <bnoordhuis>preferably with lots of snarky comments
20:40:21  <trevnorris>lol
20:40:38  <tjfontaine>I'm sure this throwing will make people happy :)
20:41:55  <bnoordhuis>probably not but the alternative is worse
20:42:02  <tjfontaine>I agree
20:42:21  <tjfontaine>we could defer it to the cb though
20:42:33  <tjfontaine>this is certainly one of those places where I prefer a throw
20:42:43  <isaacs>`var someName = function() {...` == awful
20:42:48  <isaacs>just a PSA, don't ever do that.
20:42:55  <isaacs>it's all over http
20:43:19  <isaacs>tjfontaine: git blame says that you wrote all this code, so i assume you can answer for it ;P
20:43:24  <tjfontaine>:<<
20:45:30  <bnoordhuis>tjfontaine: https://github.com/piscisaureus/cares/commit/4204667 <- lgty?
20:45:42  <tjfontaine>yup
20:47:16  * hzquit (Disconnected by services)
20:47:20  * hzjoined
20:47:59  <trevnorris>indutny: when you have a moment, mind reviewing the error from http://git.io/ZQe4zA
20:48:11  <MI6>joyent/node: Ben Noordhuis master * 6902f65 : deps: fix up header files in cares.gyp - http://git.io/kFFrfA
20:48:43  <tjfontaine>hmm you know, I should really add note to the documentation about `dns.setServers` that it will not have an effect on `.lookup`
20:49:23  <trevnorris>tjfontaine: crazy thought. v8 allows you to transverse all Persistents. so add a debug whatnot that would allow the user to print out how many Buffers exist at any given time.
20:50:11  <tjfontaine>trevnorris: that is interesting, can you also traverse the owners of the refs?
20:51:09  <trevnorris>tjfontaine: owners?
20:51:23  <tjfontaine>trevnorris: all the people with references to the buffers
20:51:57  * dannycoa_joined
20:52:26  <trevnorris>tjfontaine: you access the Persistent itself. so whatever information is tied to that object you have access to.
20:52:28  <tjfontaine>trevnorris: it's interesting to see what buffers are still alive, and even more interesting still to know who is keeping the buffer alive
20:53:18  <trevnorris>so I guess technically you could write out all buffer contents to a dump of some kind for analysis.
20:53:31  <trevnorris>hm. this could get in-depth. also something that could be done in user-land
20:53:35  <tjfontaine>trevnorris: joyent's mdb stuff can do this, but it deals with it slightly different than interacting directly with v8
20:53:48  <roxlu>when I want to create a thread and copy some data (pixel data, rgb24) from the main thread to my worker thread which encodes this using libvpx/x264, is it better to use a plain uv_mutex_t or a uv_rwlock_t ?
20:53:48  <trevnorris>tjfontaine: fyi the method is "V8::PersistentHandleVisitor"
20:53:49  <tjfontaine>ya certainly could be a useful module
20:53:57  <tjfontaine>trevnorris: nod
20:54:04  <MI6>joyent/node: Ben Noordhuis master * 7124387 : http: don't escape request path, reject bad chars (+1 more commits) - http://git.io/kUzbIw
20:56:46  * kenperkinsjoined
20:58:19  * `3rdEdenjoined
20:59:22  <MI6>nodejs-master: #218 UNSTABLE osx-ia32 (1/596) smartos-ia32 (1/596) linux-x64 (2/596) linux-ia32 (1/596) smartos-x64 (3/596) http://jenkins.nodejs.org/job/nodejs-master/218/
21:00:38  * loladiroquit (Ping timeout: 252 seconds)
21:06:25  * `3rdEdenquit (Ping timeout: 246 seconds)
21:09:11  * defunctzombie_zzchanged nick to defunctzombie
21:15:37  <MI6>nodejs-master: #219 UNSTABLE osx-x64 (1/597) smartos-x64 (3/597) http://jenkins.nodejs.org/job/nodejs-master/219/
21:15:49  <tjfontaine>sblom: A -> B -> C, if B exits C is reaped on 2k8r2, though I'm not sure if process.on('exit') fires in C, it would seem like not we talked about the lack of singals yesterday being the issue there I believe
21:17:21  <tjfontaine>sblom: https://gist.github.com/tjfontaine/5587476 is what i used to test
21:17:47  <sblom>tjfontaine: sounds like bad things don't happen.
21:17:49  <sblom>:)
21:18:06  <sblom>Cool.
21:18:08  <tjfontaine>indeed, at least a better world than zombies
21:18:12  <sblom>For sure.
21:18:45  * defunctzombiechanged nick to defunctzombie_zz
21:24:44  <trevnorris>tjfontaine: feeling lazy. can you direct me to where in http the incoming data is transformed into the request object?
21:25:06  <trevnorris>well, i'm still looking at the code. but don't want to spend the rest of the day analyzing it.
21:26:05  <tjfontaine>I'm not entirely sure what you're looking for, _http_incoming.js?
21:26:34  * dannycoa_quit (Read error: Connection reset by peer)
21:27:08  * dannycoatesjoined
21:31:10  <trevnorris>tjfontaine: http used net, which uses the StreamWrap, which wraps all incoming data in a Buffer. correct?
21:31:45  <trevnorris>tjfontaine: so what I'm wondering is where the conversion of those incoming Buffers to the actual request object passed to the requestListener takes place.
21:31:48  * indexzerojoined
21:32:14  <MI6>nodejs-master-windows: #28 UNSTABLE windows-x64 (10/596) windows-ia32 (9/596) http://jenkins.nodejs.org/job/nodejs-master-windows/28/
21:33:06  * wavdedquit (Ping timeout: 264 seconds)
21:33:51  <tjfontaine>trevnorris: well in _http_common parserOnHeadersComplete creates the IncomingMessage
21:34:35  <trevnorris>tjfontaine: thanks. what i want to do is manually .dispose() those buffers once the request object has been created. that should improve performance.
21:34:35  * dominictarrjoined
21:35:24  <tjfontaine>trevnorris: the buffers actually go through the parser
21:35:25  * sblomquit
21:35:53  <trevnorris>tjfontaine: exactly. but then it's left up to v8 to clean them up. once they've gone through the parser they're no longer needed.
21:36:01  <trevnorris>i'm assuming
21:36:23  * c4miloquit (Remote host closed the connection)
21:37:36  <trevnorris>tjfontaine: so it looks like the headers have already been parsed by the time they reach parserOnHeadersComplete. but that should trace me back to where I need to go. thanks
21:37:50  * c4milojoined
21:38:10  * rendarquit
21:40:37  <tjfontaine>trevnorris: lib/_http_server sets a new ondata that calls parser.execute
21:40:46  <tjfontaine>that seems to be what you're looking for
21:40:54  <trevnorris>tjfontaine: ah, perfect. thanks!
21:45:11  * qardquit (Quit: Leaving.)
21:46:15  <tjfontaine>bnoordhuis: oh, so the problem is unref is being called on an already fired timeout handle?
21:50:33  * wolfeidauquit (Ping timeout: 245 seconds)
21:51:29  <bnoordhuis>tjfontaine: yep
21:52:09  <bnoordhuis>oh, and the other one is that you can call HandleWrap::Unref() essentially directly but with a different holder object
21:52:43  <bnoordhuis>another reason never to expose bindings objects directly to user land code
21:52:45  <tjfontaine>right, I was pretty sure I had tested unref on intervals before, just hadn't thought of this happening
21:53:06  <tjfontaine>ya in hindsight when I added unref I probably should have gone ahead and wrapped interval
21:53:31  <bnoordhuis>better late than never, right? :)
21:53:58  <tjfontaine>heh ya, [un]fortunately not many people use unref
21:55:22  <bnoordhuis>do i hear a lgtm?
21:55:32  <tjfontaine>so the other thing you're doing here is no longer relying on uv handling the repeat logic, which if I remember from previous conversation you wish you hadn't implemented
21:55:59  <tjfontaine>bnoordhuis: as further proof it had a green build :)
21:56:12  <bnoordhuis>the gods are smiling on me
21:56:15  <tjfontaine>indeed
21:58:24  * qardjoined
21:59:24  <trevnorris>is there a minimum size for misc fix up PR's?
21:59:50  <MI6>joyent/node: Robert Kowalski master * 04ce807 : module: use path.sep instead of custom solution - http://git.io/DAQJIw
22:00:09  <bnoordhuis>trevnorris: minimum what?
22:00:52  <trevnorris>bnoordhuis: little stuff like this: https://github.com/trevnorris/node/compare/misc-fixups
22:01:23  <tjfontaine>ok, my uv-dtrace works on osx and smartos, shall I land it? :)
22:02:16  <bnoordhuis>trevnorris: lgtm
22:03:31  <MI6>joyent/node: Ben Noordhuis v0.10 * 22533c0 : timers: fix setInterval() assert - http://git.io/mvY64Q
22:04:39  <bnoordhuis>signing off. have a good night everyone
22:04:44  <trevnorris>night
22:04:46  <tjfontaine>night
22:06:44  <tjfontaine>bnoordhuis: I don't think you meant to reopen #4261
22:06:47  * AvianFlujoined
22:08:10  <trevnorris>heh, yeah. hate how they have a "comment & reopen" right next to "comment"
22:08:18  <tjfontaine>ya
22:08:28  <tjfontaine>especially since it's normally comment and close :)
22:08:55  <MI6>joyent/node: Timothy J Fontaine master * f0d80d7 : dtrace: enable uv's probes if enabled - http://git.io/qcaBnw
22:09:04  <trevnorris>.... about to push my first commit. feel a little queasy.
22:09:11  <tjfontaine>heh now you have to rebase :)
22:09:23  <trevnorris>damn you. just saw that. :)
22:09:27  * bnoordhuisquit (Ping timeout: 260 seconds)
22:09:45  <tjfontaine>trevnorris: so I have 3 remotes, origin me, upstream which is git://, and then upstream-rw which is git+ssh://
22:10:05  <MI6>nodejs-master: #220 UNSTABLE linux-ia32 (2/598) smartos-x64 (3/598) http://jenkins.nodejs.org/job/nodejs-master/220/
22:10:12  <tjfontaine>and then: git push upstream-rw HEAD:master
22:10:17  <tjfontaine>from the feature branch
22:10:43  <trevnorris>tjfontaine: i actually have three repos. the one that allows me to push is away from my usual dev path. I have fat fingers, hence why i'm constantly rebasing.
22:10:45  * wolfeidaujoined
22:10:51  <tjfontaine>heh
22:12:18  <MI6>joyent/node: Trevor Norris master * 88333f7 : http: don't slice unless necessary - http://git.io/CyQoJw
22:12:28  <tjfontaine>omig what did you do
22:12:28  <tjfontaine>:P
22:12:42  <trevnorris>aaahhhh!!!!
22:13:10  <MI6>nodejs-master-windows: #29 UNSTABLE windows-x64 (9/597) windows-ia32 (9/597) http://jenkins.nodejs.org/job/nodejs-master-windows/29/
22:14:12  <tjfontaine>btw trevnorris your change made me think about https://github.com/joyent/node/pull/5259/files
22:15:36  <trevnorris>tjfontaine: oh, interesting.
22:16:05  <tjfontaine>I don't think it eliminates the need to slice, but it eliminates passing it around since it goes back on the stream
22:16:59  <isaacs>oh, shit, that "sockets hanging in CONN_WAIT" thing, I think i reproduced it
22:17:09  <tjfontaine>how?
22:17:20  <isaacs>because i gave up and though, "Whatever, I'm sick of digging into this, i'm gonna implement that unref keepAlive client thing"
22:17:29  <isaacs>and now all the http tests hang
22:17:32  <isaacs>this is awesome!
22:17:46  <tjfontaine>heh
22:17:51  <trevnorris>lol. not usually the response i'd expect from a bug
22:18:06  <isaacs>trevnorris: well, it's a bug i've been looking for for a long time now :)
22:18:40  <trevnorris>ah. makes sense. have to love finding those little evasive bitches
22:20:52  <trevnorris>isaacs: just pushed my first commit!
22:20:58  * trevnorrisfeels like such a grown up now
22:21:10  <isaacs>trevnorris: i saw!
22:21:23  <amartens>don't grow up
22:21:36  <isaacs>congratulations, you've consummated your node-core commit bit :)
22:22:07  <trevnorris>lol
22:22:20  <trevnorris>great use of the word consummate
22:22:38  <trevnorris>amartens: no worries. I have a 2 year old and feel like he's more responsible than I am sometimes :P
22:23:26  <amartens>trevnorris: hey, you've had a kid - that's pretty responsible
22:23:34  <amartens>well, possibly irresponsible
22:23:44  <amartens>but you're responsible for him now, so at least there's that :P
22:23:54  * mikealquit (Quit: Leaving.)
22:27:09  <tjfontaine>oho, https://github.com/joyent/libuv/pull/264#issuecomment-6330380 I was looking for this information yesterday
22:30:10  <MI6>nodejs-v0.10: #192 UNSTABLE linux-x64 (4/584) linux-ia32 (2/584) osx-x64 (1/584) smartos-x64 (1/584) smartos-ia32 (1/584) http://jenkins.nodejs.org/job/nodejs-v0.10/192/
22:30:38  <tjfontaine>hmm well that can't have been what was failing, lame
22:30:39  <MI6>nodejs-master: #221 UNSTABLE osx-ia32 (1/598) smartos-ia32 (2/598) smartos-x64 (6/598) http://jenkins.nodejs.org/job/nodejs-master/221/
22:32:43  <isaacs>actually, i'm not sure if it's the same bug.
22:33:37  * wolfeidauquit (Remote host closed the connection)
22:34:51  <trevnorris>isaacs: side note. I have the no slab allocator within 0-5% performance of master. thing is that removing the slab allocator is necessary for manually disposable buffers.
22:35:14  <trevnorris>and if the user manually disposes incoming buffers then performance blows past master
22:35:44  <trevnorris>for net. i'm experimenting w/ http right now to see if we can do the same thing internally.
22:35:58  <amartens>hey isaacs, just watching your "Road to 1.0" talk. What's the upcoming V8 API change that's going to break C++ addons? I seem to remember hearing something about a big V8 change last week that had some people concerned...
22:36:16  <trevnorris>amartens: it's going to be harsh, yes.
22:36:43  <trevnorris>amartens: the major change is coming in https://codereview.chromium.org/12494012/
22:38:09  <trevnorris>amartens: the big changes are: no more Local, everything is Persistent or Handle; Persistent no longer inherets from Handle; and instead of returning the value, you have to pass the return value as a function argument.
22:39:00  <tjfontaine>trevnorris: is that true of everything? Integer::New for instance?
22:39:22  <trevnorris>tjfontaine: hm. not sure. i'm reviewing the source now.
22:39:46  <amartens>… no more Local?
22:39:47  <amartens>dang
22:40:00  <trevnorris>tjfontaine: here are the changes we're worried about: https://codereview.chromium.org/12494012/patch/50001/51001
22:40:03  <amartens>that seems annoying and messy
22:40:56  <tjfontaine>trevnorris: ya I was already looking
22:41:34  <trevnorris>tjfontaine: i think the return value thing is more for "typedef void (*FunctionCallback)"
22:42:40  <trevnorris>isaacs: oh, good news. so it looks like the methods that require the return value to be passed have a different name. then the others are being deprecated. so should provide good backwards compatibility.
22:43:37  <trevnorris>oy, those bastards aren't even following their own style guide.
22:43:58  <tjfontaine>ya there's going to be some pain from this, but I don't think it will be terribly invasive
22:44:14  * wankdankerjoined
22:44:42  <trevnorris>hm. and this isn't the change set that removes Local. have to go find that one again.
22:47:41  <wankdanker>just watched "the road to node.js v1.0". Anyone have a link to the crazy v8 changes that will eventually be taking place? I'd like to wrap my head around it.
22:47:55  <isaacs>tjfontaine: so, here's the thing that's breaking...
22:48:02  <trevnorris>wankdanker: https://codereview.chromium.org/12494012/patch/50001/51001
22:48:07  <isaacs>tjfontaine: let's say, instead of destroying sockets, the client unref()s them, and puts them in a list.
22:48:12  <isaacs>tjfontaine: so far so good.
22:48:13  <wankdanker>trevnorris: thanks.
22:48:14  <tjfontaine>right
22:48:23  <isaacs>tjfontaine: now, pretend that the server is localhost, in the same process.
22:48:38  <isaacs>and it's not responding with connection:close
22:48:45  <isaacs>it's responding with connection:keep-alive
22:48:54  * dscape_changed nick to dscape
22:48:56  <isaacs>and you make 2 reqs, and then you want the process to exit.
22:49:07  <isaacs>well, ok, except, you have a server with 2 connections to it!
22:49:28  <tjfontaine>oh a contained process, ya
22:49:47  <tjfontaine>shouldn't the server also unref a keep-alive'd connection?
22:49:57  <tjfontaine>well
22:49:59  <tjfontaine>no
22:50:06  <isaacs>right
22:50:10  <isaacs>from the server's pov, it's just "a connection"
22:50:14  <isaacs>we've called server.close()
22:50:20  <isaacs>so it's no longer listening
22:50:26  <isaacs>however, the connection is still alive
22:50:39  * mikealjoined
22:51:31  <tjfontaine>ya, in a self-contained test .close just won't satisfy this test case
22:51:40  * pachetquit (Quit: leaving)
22:52:18  <tjfontaine>isaacs: it is a bug, just not in node :)
22:52:38  <isaacs>maybe... here's an idea.
22:52:51  <isaacs>maybe in an outgoing message, from a server, on the 'finish' event, if the server is closed, kill the connection.
22:53:10  <tjfontaine>hm
22:53:19  <isaacs>except, then we have to send connection:close or we're lying liars.
22:53:57  <tjfontaine>right, if the point of .close is to let connections wrap up what they're doing there's not much you're going to do
22:54:26  <tjfontaine>aside from being impolite
22:56:29  <trevnorris>isaacs: just fyi, for shits and giggles i'm merging v0.10 to master so I can get a jump start on merging my stuff.
22:57:38  <tjfontaine>doesn't look like this merge will be that painful
22:58:20  * c4miloquit (Remote host closed the connection)
22:58:49  <trevnorris>tjfontaine: except for a bunch of Buffer stuff, which is what my patch deals with
22:58:53  * indexzeroquit (Quit: indexzero)
22:59:41  <tjfontaine>trevnorris: oh the cryptostream stuff wasn't already merged?
23:00:04  <trevnorris>tjfontaine: the crypto stream stuff was merged into v0.10. and the v0.10 merge to master was going to take care of the rest.
23:00:32  <tjfontaine>right I was thinking that bert merged 10 into master yesterday as well, but that was just libuv 10 into master
23:00:40  <trevnorris>yeah
23:05:31  <trevnorris>tjfontaine: oh, and add to that the crypto bio stuff that indutny dropped on master. it's a mess.
23:06:04  <tjfontaine>best of luck! :)
23:08:14  <tjfontaine>isaacs: hmm you sure you couldn't .unref on .finish?
23:08:41  <isaacs>tjfontaine: tried that
23:08:53  <tjfontaine>hrm
23:08:54  <isaacs>looks like the process stays open even if both sides unref.
23:08:57  <isaacs>might be a bug there.
23:10:04  <tjfontaine>hmm does _getActiveHandles list if they've been unref'd?
23:10:28  <MI6>nodejs-v0.10-windows: #22 UNSTABLE windows-ia32 (10/584) windows-x64 (9/584) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/22/
23:10:30  <isaacs>hm... not with a tcp server, though, that works fine
23:13:11  <tjfontaine>ya, before you get too far on this we should expose uv_has_ref on the handle
23:13:33  <tjfontaine>otherwise trying to debug this will be a pain in the ass
23:16:14  <isaacs>ohhhhhh
23:16:24  <isaacs>it's the timeout timer
23:17:45  <isaacs>server.setTimeout(0) fixes it
23:17:56  <tjfontaine>interesting
23:18:13  <tjfontaine>so does unref on finish after close make sense?
23:18:19  <isaacs>yeah, i think so
23:18:21  <isaacs>maybe
23:18:25  <isaacs>more than destroy on finish after close
23:18:31  <tjfontaine>absolutely
23:18:34  <isaacs>though it's effectively the same thing
23:18:46  <isaacs>if the server closes, i mean, those sockets are destroyed
23:18:53  <isaacs>and ref just keesp the process up
23:19:00  <isaacs>so it's more graceful than destroy, but not by much
23:19:12  <tjfontaine>right, except that if they send another request before the process exists it will be filled
23:19:21  <isaacs>right
23:19:23  <tjfontaine>you have to make sure to ref in that case
23:19:32  <isaacs>hmm...
23:19:34  <isaacs>that's not so great.
23:19:48  <isaacs>can see a situation where we close the process mid-response
23:20:08  <tjfontaine>if it's ref'd how can it close?
23:20:23  <isaacs>i mean, if we get that not-quite-right
23:20:27  <tjfontaine>right yes
23:20:33  <isaacs>which i'd say is impossible, if i hadn't fought to often with this code.
23:20:38  <tjfontaine>but ref/unref is idempotent
23:20:49  <isaacs>tht's true, at least.
23:21:03  <tjfontaine>so as long as you're always ref'ing on a new request it's relatively sane
23:22:18  * wolfeidaujoined
23:22:47  <isaacs>yeah
23:22:49  <isaacs>i guess so
23:23:18  * timoxleyjoined
23:28:37  <isaacs>really, unref'ing a socket should unref the timeout timer, also
23:29:29  <tjfontaine>ya, instead of just the handle, I agree that's a bug
23:30:14  <MI6>nodejs-master-windows: #30 UNSTABLE windows-x64 (8/598) windows-ia32 (8/598) http://jenkins.nodejs.org/job/nodejs-master-windows/30/
23:32:12  <tjfontaine>> process._getActiveHandles()
23:32:12  <tjfontaine>[ { _connecting: false,
23:32:12  <tjfontaine> _handle:
23:32:12  <tjfontaine> { refd: true,
23:32:26  <tjfontaine>that should be helpful
23:32:31  * bnoordhuisjoined
23:32:55  <tjfontaine>bnoordhuis is sleep-irc'ing again
23:36:48  * bnoordhuisquit (Ping timeout: 245 seconds)
23:41:22  <isaacs>yeah, that'd be nice.
23:41:34  * kevinswiberquit (Remote host closed the connection)
23:42:00  * AvianFluquit (Read error: Connection reset by peer)
23:42:06  * kevinswiberjoined
23:42:34  * AvianFlujoined
23:43:46  * luxigoquit (Remote host closed the connection)
23:46:54  * kevinswiberquit (Ping timeout: 264 seconds)
23:56:11  <isaacs>tjfontaine: i think the better solution is that when oyu call server.close(), we start sending Connection:close
23:56:29  <isaacs>tjfontaine: and doing socket.destroySoon() in response.on('finish')
23:56:44  <isaacs>tjfontaine: server.close = "I'd like to shut down, whenever you guys are done with me, k?"
23:58:06  <isaacs>also, fixes the unit test case.
23:58:24  <isaacs>sadface, though: this is definitely not the elusive CLOSE_WAIT bug.
23:58:34  * isaacsoff to practice
23:58:36  * isaacs&*
23:58:37  <LOUDBOT>WHEN I SAY HILLSHIRE YOU SAY FARMS
23:59:18  <trevnorris>damn you!
23:59:50  <trevnorris>merging the StringBytes changes along side the crypto BIO changes is ridiculous