00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:02:27  * calvinfo1joined
00:03:59  * calvinfoquit (Ping timeout: 246 seconds)
00:10:04  * AvianFluquit (Read error: Connection reset by peer)
00:12:09  * paddybyersquit (Quit: paddybyers)
00:20:35  * AvianFlujoined
00:24:17  * AvianFluquit (Read error: Connection reset by peer)
00:42:20  * jmar777joined
00:45:21  * mikealquit (Quit: Leaving.)
01:05:47  * timoxleyquit (Remote host closed the connection)
01:08:05  * timoxleyjoined
01:25:17  * piscisaureus_joined
01:27:53  * piscisaureus_quit (Client Quit)
01:28:23  * piscisaureus_joined
01:29:35  * piscisaureus_changed nick to otwo
01:29:49  * otwoquit (Client Quit)
01:30:14  * otwojoined
01:42:09  * AvianFlujoined
01:55:47  * AvianFluquit (Read error: Connection reset by peer)
01:55:57  * AvianFlujoined
02:03:08  * abraxasjoined
02:03:34  * wolfeidauquit (Read error: Connection reset by peer)
02:03:37  * wolfeida_joined
02:12:29  * kevinswiberjoined
02:24:40  * AvianFluquit (Read error: Connection reset by peer)
02:35:33  * kazuponjoined
02:38:07  * wolfeida_changed nick to wolfeidau
02:40:22  * AvianFlujoined
02:47:13  * stagasjoined
02:49:53  * st_lukequit (Remote host closed the connection)
02:58:41  * timoxleyquit (Remote host closed the connection)
03:04:19  * timoxleyjoined
03:08:44  * kevinswiberquit (Remote host closed the connection)
03:08:54  * timoxleyquit (Ping timeout: 265 seconds)
03:10:50  * aranhoidequit (Ping timeout: 245 seconds)
03:14:10  * aranhoidejoined
03:17:08  * groundwaterjoined
03:20:50  <MI6>joyent/node: Timothy J Fontaine v0.10 * 6877e64 : build: include postmortem symbols on linux - http://git.io/eqOxRg
03:31:23  <MI6>nodejs-v0.10: #1632 UNSTABLE smartos-x64 (4/604) smartos-ia32 (4/604) linux-x64 (2/604) osx-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1632/
03:34:19  * abraxasquit (Remote host closed the connection)
03:34:55  * abraxasjoined
03:36:27  <MI6>nodejs-v0.10-windows: #350 UNSTABLE windows-ia32 (10/604) windows-x64 (11/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/350/
03:42:35  * AvianFlu_joined
03:42:47  * AvianFluquit (Read error: Connection reset by peer)
03:44:01  <MI6>joyent/node: Timothy J Fontaine master * 001f9b4 : Merge remote-tracking branch 'upstream/v0.10' (+5 more commits) - http://git.io/4ch2rw
03:49:15  * Benviejoined
04:02:30  <MI6>nodejs-master: #740 UNSTABLE osx-x64 (1/680) smartos-ia32 (8/680) linux-x64 (1/680) smartos-x64 (9/680) http://jenkins.nodejs.org/job/nodejs-master/740/
04:12:44  * dshaw_joined
04:15:50  * Benviequit (Ping timeout: 264 seconds)
04:36:27  * defunctzombiechanged nick to defunctzombie_zz
04:36:48  * mikealjoined
04:39:06  * jmar777quit (Remote host closed the connection)
04:41:26  * dshaw_quit (Quit: Leaving.)
04:44:47  * mikealquit (Quit: Leaving.)
04:52:15  * brsonjoined
04:57:55  * indexzeroquit (Ping timeout: 260 seconds)
05:05:21  * indexzerojoined
05:09:51  * groundwaterquit (Quit: Textual IRC Client: www.textualapp.com)
05:12:17  * dshaw_joined
05:20:17  * calvinfo1quit (Quit: Leaving.)
05:25:26  * dshaw_quit (Ping timeout: 264 seconds)
05:25:57  * calvinfojoined
05:27:03  * groundwaterjoined
05:27:52  * groundwaterquit (Client Quit)
05:28:06  * inolenquit (Ping timeout: 265 seconds)
05:28:24  * inolenjoined
05:30:16  * dshaw_joined
05:30:41  * groundwaterjoined
05:30:48  * groundwaterquit (Remote host closed the connection)
05:31:10  * timoxleyjoined
05:34:03  * groundwaterjoined
05:34:53  * groundwaterquit (Remote host closed the connection)
05:38:19  * groundwaterjoined
05:39:07  * AvianFlu_quit (Remote host closed the connection)
05:46:39  * calvinfoquit (Quit: Leaving.)
05:55:26  * robonerdquit (Ping timeout: 240 seconds)
05:55:39  * robonerd-joined
06:05:43  * brsonquit (Ping timeout: 246 seconds)
06:07:49  * octetcloudquit (Ping timeout: 246 seconds)
06:18:39  * kazuponquit (Remote host closed the connection)
06:19:06  * brsonjoined
06:19:36  * calvinfojoined
06:19:49  * inolenquit (Read error: Connection reset by peer)
06:20:08  * inolenjoined
06:23:58  * kazuponjoined
06:25:24  * mikealjoined
06:30:04  * wwicksquit (Quit: wwicks)
06:32:58  * calvinfoquit (Quit: Leaving.)
06:34:13  * calvinfojoined
06:36:54  * calvinfopart
06:41:20  <MI6>nodejs-v0.10-windows: #351 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/351/
06:48:21  * felixgejoined
06:55:16  * loladiroquit (Quit: loladiro)
06:56:54  * brsonquit (Quit: leaving)
06:58:30  * m76joined
07:03:55  * bajtosjoined
07:06:58  * paddybyersjoined
07:18:03  * loladirojoined
07:25:36  * stagasquit (Ping timeout: 245 seconds)
07:30:46  * aranhoidequit (Read error: Operation timed out)
08:01:10  * rendarjoined
08:21:18  * dshaw_quit (Quit: Leaving.)
08:26:20  * loladiroquit (Quit: loladiro)
08:27:18  * loladirojoined
08:27:41  * loladiroquit (Client Quit)
08:28:12  <indutny>heya
08:40:49  * DarkGodWjoined
08:52:10  * dshaw_joined
09:02:43  * inolenquit (Read error: No route to host)
09:02:59  * inolenjoined
09:07:59  <mmalecki>sup Fedor
09:08:38  * dshaw_quit (Ping timeout: 264 seconds)
09:11:56  * aranhoidejoined
09:13:41  <mmalecki>indutny: so I'm confused as to isLoopback method in ip
09:13:47  <indutny>haha
09:13:48  <indutny>:)
09:13:50  <mmalecki>indutny: er, loopback.
09:14:12  <mmalecki>indutny: you specify fe80::1, every result I found on the web says that it's just ::1
09:14:34  <indutny>well
09:14:40  <indutny>perhaps, that wasn't me who contributed it
09:14:41  <mmalecki>is it related to link-local prefix?
09:14:46  <mmalecki>good point
09:14:48  <mmalecki>:Gblame
09:15:04  <mmalecki>yeah, [0]
09:16:29  <indutny>ok :)
09:18:06  <mmalecki>what a mess - fe80-feb:: seems to be link-local prefix
09:18:18  <mmalecki>but ::1 still works
09:20:03  <mmalecki>oh maan, there's more. there are also site-local and link-local addresses which aren't in ip yet
09:21:52  <indexzero>mmalecki: I really need to change my handle or something so that [0] also summons me
09:23:52  <mmalecki>indexzero: haha, it's configurable in irssi
09:24:27  <mmalecki>indexzero: so I have a question about https://github.com/indutny/node-ip/commit/5652a2c8a5312dc6a38a0d2300e6ca673b5f54c6
09:24:38  <mmalecki>indexzero: why fe80::1 as loopback instead of ::1?
09:25:54  <indexzero>mmalecki: https://gist.github.com/indexzero/7747045
09:26:13  <indexzero>I think the script I was using probably fetched the first one
09:26:17  <indexzero>which happens to be fe::80
09:26:20  <indexzero>err
09:26:22  <indexzero>fe80::1
09:26:39  <indexzero>I didn't really know anything about ipv6 so I just assumed node wasn't lying to me
09:27:35  <mmalecki>ohh... nice. so macs also have fe80::1. my Linux VM only has ::1
09:27:56  <mmalecki>https://twitter.com/dabeaz/status/406947329431052288
09:29:22  <indexzero>ok
09:29:31  <indexzero>probably better to just match /::1$/
09:30:14  <mmalecki>yeah, fe80:: is already there actually
09:30:52  <indexzero>right
09:31:06  <indexzero>but fe80::1 and ::1 both match to /::1$/
09:31:11  <indexzero>so less regexps?
09:31:49  <indexzero>mmalecki: also. unrelated: https://twitter.com/joestump/status/407425620982120448
09:32:25  <mmalecki>indexzero: whole fe80:: is a private, link-local address space
09:32:33  <mmalecki>fe80 - feb
09:32:34  <mmalecki>http://www.freebsd.org/doc/handbook/network-ipv6.html
09:33:01  <mmalecki>indexzero: oh, awesome
09:33:17  <indexzero>mmalecki: right, but private !== local
09:33:29  <mmalecki>indexzero: I don't think I know those folks
09:33:41  <indexzero>so is loopback is really just /::1$/
09:33:57  <indexzero>but link-local and site-local should be in .isPrivate()
09:34:23  <mmalecki>yeah, but os.networkInterfaces() also returns fe80::1 as a loopback interface
09:34:30  <mmalecki>with internal: true
09:35:06  <mmalecki>indexzero: ohh, wookiehangover. I met him but not sure where
09:41:21  <mmalecki>so when I listen to ::1 and connect to ::1, everything works fine. when I listen to ::1 and connect to fe80::1, I get EHOSTUNREACH
09:41:38  <mmalecki>starting to be really confused about how computers work
09:42:41  * bajtosquit (Quit: bajtos)
09:43:16  <indutny>whoa
09:43:23  <indutny>just built custom openvpn
09:43:28  <indutny>to connect to the server :)
09:43:41  <indutny>took a hour to figure out how to patch this thing
09:44:07  <mmalecki>indutny: let me guess, you tried compiling it on Solaris?
09:44:11  <indutny>no
09:44:14  <indutny>on osx
09:44:18  <indutny>using cert from keychain
09:44:26  <indutny>this option isn't present in default openvpn release
09:44:29  <mmalecki>ohhh, nice
09:44:32  <indutny>I had to use patch from 2011
09:44:37  <mmalecki>heh
09:44:43  <indutny>yeah, backporting was kind of hell
09:44:51  <indutny>though, most of the stuff was still in place
09:45:49  <mmalecki>'::' is also an alias for ::1 ._.
09:45:59  <indutny>haha
09:46:02  <indutny>yep
09:46:07  <indutny>http://[::]:8000/
09:46:09  <indutny>I love it!
09:46:20  <indutny>it don't even highlight in my irc client
09:52:09  * otwoquit (Ping timeout: 252 seconds)
09:53:28  <mmalecki>ah. it all makes a bit more sense when you realize that other interfaces also have "loopback" addresses, or link-local addresses
09:53:44  <mmalecki>and loopback is just one of those interfaces
10:03:13  * dshaw_joined
10:04:38  <mmalecki>indutny: https://github.com/indutny/node-ip/pull/10
10:04:43  <mmalecki>indutny: ^
10:07:01  <indutny>mmalecki: are you sure about ^:: ?
10:07:11  <indutny>is ::5 loopback too?
10:07:53  * dshaw_quit (Ping timeout: 272 seconds)
10:08:19  <mmalecki>indutny: no, connecting to ::5 fails
10:08:31  <mmalecki>I *think* you can only skip 1's like that
10:09:31  <indutny>ok
10:10:57  <mmalecki>indutny: I'm gonna make that ^::$
10:13:23  * dshaw_joined
10:16:40  <indutny>ok
10:20:36  * dshaw_quit (Ping timeout: 245 seconds)
10:34:46  * wolfeida_joined
10:35:43  * otwojoined
10:35:45  * wolfeidauquit (Ping timeout: 272 seconds)
10:40:50  * aranhoidequit (Ping timeout: 245 seconds)
10:49:22  <MI6>nodejs-v0.10: #1633 UNSTABLE smartos-x64 (5/604) smartos-ia32 (4/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1633/
10:50:06  * felixgequit (Quit: felixge)
10:50:28  * felixgejoined
10:50:29  * felixgequit (Changing host)
10:50:29  * felixgejoined
10:50:35  * wolfeida_changed nick to wolfeidau
10:50:40  * aranhoidejoined
10:50:57  * felixgequit (Client Quit)
10:53:31  <MI6>joyent/node: Fedor Indutny v0.10 * 9b8fcff : tls: reset NPN callbacks after SNI - http://git.io/Se5Uqw
10:57:05  * otwoquit (Ping timeout: 246 seconds)
10:58:35  <mitsuhiko>indutny: and don't forget the scope can also be in the url
10:58:45  <indutny>um?
10:59:21  <mitsuhiko>http://[::]%1/
10:59:30  <mitsuhiko>or was it [::%1]?
10:59:30  <indutny>ah
10:59:36  <indutny>gosh :)
10:59:45  <indutny>I don't even want to think about it
10:59:52  <indutny>ipv6 without domain names
11:00:11  <mitsuhiko>the clever people that thought that ":" and "%" are good signs for ip addresses because they have no prior meaning in urls
11:00:48  <indutny>:)
11:00:53  * abraxasquit (Remote host closed the connection)
11:01:37  * kazuponquit (Remote host closed the connection)
11:02:00  * felixgejoined
11:02:23  * otwojoined
11:04:56  <MI6>joyent/node: Fedor Indutny master * 4bd5f35 : Merge branch 'v0.10' (+1 more commits) - http://git.io/Jm0obQ
11:07:15  * rendarquit
11:08:03  * otwoquit (Ping timeout: 252 seconds)
11:08:34  <MI6>nodejs-v0.10-windows: #352 UNSTABLE windows-ia32 (12/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/352/
11:13:22  <MI6>nodejs-v0.10: #1634 UNSTABLE smartos-x64 (13/604) smartos-ia32 (5/604) linux-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1634/
11:17:09  * dshaw_joined
11:21:31  * dshaw_quit (Ping timeout: 260 seconds)
11:25:35  <MI6>nodejs-master: #741 UNSTABLE osx-x64 (2/680) smartos-ia32 (5/680) smartos-x64 (11/680) osx-ia32 (1/680) http://jenkins.nodejs.org/job/nodejs-master/741/
11:45:54  * bajtosjoined
11:54:58  * Raynos_joined
11:57:38  * Raynosquit (Ping timeout: 240 seconds)
11:57:41  * Raynos_changed nick to Raynos
11:57:52  * groundwaterquit (Ping timeout: 240 seconds)
11:59:37  * groundwaterjoined
12:18:01  * dshaw_joined
12:22:29  * dshaw_quit (Ping timeout: 248 seconds)
12:46:00  * indexzeroquit (Quit: indexzero)
12:58:22  * felixgequit (Quit: http://www.debuggable.com/)
13:01:26  * abraxasjoined
13:01:26  * aranhoidequit (Ping timeout: 264 seconds)
13:11:06  * abraxasquit (Remote host closed the connection)
13:16:50  * janjongboomjoined
13:28:11  * jmar777joined
13:46:04  * m76quit (Read error: Connection reset by peer)
14:17:07  * jmar777quit (Remote host closed the connection)
14:17:24  * AlexisMochajoined
14:18:35  * timoxleyquit (Remote host closed the connection)
14:30:06  * kevinswiberjoined
14:42:21  * paulfryzeljoined
14:43:53  * m76joined
14:46:50  * paulfryzelquit (Remote host closed the connection)
14:47:38  * paulfryzeljoined
14:48:18  * `3rdEdenchanged nick to `3E|BRB
14:58:52  * `3E|BRBchanged nick to `3E
15:02:00  * paddybyers_joined
15:03:20  * paddybyersquit (Ping timeout: 245 seconds)
15:03:20  * paddybyers_changed nick to paddybyers
15:04:21  * jmar777joined
15:06:12  * kazuponjoined
15:08:38  * hzjoined
15:09:13  * defunctzombie_zzchanged nick to defunctzombie
15:11:14  * hzquit (Client Quit)
15:16:24  * bajtosquit (Quit: bajtos)
15:21:31  <MI6>nodejs-master: #742 UNSTABLE osx-x64 (1/680) smartos-ia32 (7/680) smartos-x64 (8/680) osx-ia32 (1/680) http://jenkins.nodejs.org/job/nodejs-master/742/
15:24:55  * paulfryz_joined
15:28:07  * paulfryzelquit (Ping timeout: 252 seconds)
15:29:21  * timoxleyjoined
15:29:55  * paulfryz_changed nick to paulfryzel
15:31:20  * pachetjoined
15:31:20  * pachetquit (Changing host)
15:31:20  * pachetjoined
15:33:37  * timoxleyquit (Ping timeout: 252 seconds)
15:45:58  * AvianFlujoined
15:47:32  * AvianFlu_joined
15:48:04  * AvianFluquit (Disconnected by services)
15:48:07  * AvianFlu_changed nick to AvianFlu
16:02:59  * janjongboomquit (Ping timeout: 246 seconds)
16:04:15  * janjongboomjoined
16:11:01  * loladirojoined
16:15:11  * kenperkinsjoined
16:20:23  * dshaw_joined
16:22:26  * mikealquit (Quit: Leaving.)
16:26:56  * stagasjoined
16:37:41  * octetcloudjoined
16:39:29  * TooTallNatejoined
16:44:52  * dap_joined
16:50:39  * kevinswiberquit (Remote host closed the connection)
16:50:57  <creationix>does anyone know how allowHalfOpen should work
16:51:56  * dshaw_quit (Quit: Leaving.)
16:52:24  <creationix>indutny, ^
16:52:30  * mikealjoined
16:52:40  <indutny>well
16:52:44  <indutny>I do
16:53:00  <indutny>it will keep connection open
16:53:06  <indutny>even if one side has shut it down
16:53:13  <creationix>right, so support I don't allow half-open on my server
16:53:24  <creationix>in node I set allowHalfOpen: false
16:53:45  <creationix>but one of my clients never sends me a fin after I send then a fin
16:53:59  <creationix>it seems node just keeps the connection open forever waiting on fin from the client
16:54:01  <creationix>is that correct?
16:55:52  * bajtosjoined
17:00:31  <indutny>creationix: hm...
17:00:34  <indutny>let me check
17:00:37  <indutny>I think it shouldn't
17:00:55  <indutny>if everything was sent out to client
17:01:10  <indutny>yes, that's it
17:02:52  <creationix>I have code showing it the other way where the server has allowHalfOpen and the client doesn't
17:03:29  <creationix>the client connects and the server sends data to client, the client sends data to server, then the client sends end
17:04:15  <creationix>but the server never sends FIN and the client is stuck in FIN_WAIT_2
17:04:43  <creationix>it's very confusing for a socket with allowHalfOpen set to false to stay open waiting for a fin that will never come
17:14:19  * isaacs_joined
17:14:22  * hzjoined
17:15:30  <creationix>indutny, it doesn't seem to matter which side is allowHalfOpen, either way, the allowHalfOpen: false side will wait forever for a fin that never comes
17:15:48  <indutny>hm...
17:16:04  <indutny>can you please open an issue with the code that reproduces it?
17:16:17  <indutny>I hit that code path quite often, and that thing surprises me
17:16:24  <indutny>also
17:16:30  <indutny>server may not send FIN
17:16:43  <indutny>if you haven't called .destroySoon() on socket
17:16:50  <indutny>it'll just send RST
17:16:54  <indutny>on .destroy()
17:18:37  * janjongboomquit (Ping timeout: 240 seconds)
17:19:33  * st_lukejoined
17:19:46  * janjongboomjoined
17:21:48  * dshaw_joined
17:22:45  * defunctzombiechanged nick to defunctzombie_zz
17:23:07  * rendarjoined
17:25:21  * defunctzombie_zzchanged nick to defunctzombie
17:31:18  * wwicksjoined
17:33:20  * paulfryzelquit (Remote host closed the connection)
17:33:44  * c4milojoined
17:34:05  * paulfryzeljoined
17:36:38  <creationix>indutny, so in this case, it's the side with allowHalfOpen: false that is calling end
17:36:58  <creationix>the side with allowHalfOpen: true gets the fin and sends an ACK, but never a fin
17:37:07  <creationix>which is correct from that point of view
17:37:22  <creationix>but the side with halfOpen: false waits for a fin that never comes
17:38:09  <creationix>indutny, https://gist.github.com/creationix/09d886b6d7dbb5c3fdb6
17:40:05  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:43:29  * st_lukequit (Remote host closed the connection)
17:47:31  * isaacs_quit (Read error: Connection reset by peer)
17:47:52  * isaacs_joined
17:48:15  * isaacs_changed nick to Guest76069
17:49:44  * Guest76069quit (Client Quit)
17:53:43  * mcavagejoined
17:54:43  <MI6>libuv-master: #367 UNSTABLE windows (5/197) smartos (3/198) http://jenkins.nodejs.org/job/libuv-master/367/
17:57:17  * kevinswiberjoined
18:03:50  * inolenquit (Ping timeout: 240 seconds)
18:03:57  * Benviejoined
18:06:40  * st_lukejoined
18:12:08  <octetcloud>creationix: not sure what could be done about that. I think allowHalfOpen is basically a "fix my code, because I don't understand TCP" option. it defaults to not-allow, so node tcp server's auto-shutdown the out-side of TCP when the receive an in-close
18:13:36  <octetcloud>but you can't cause an in-FIN to magically appear for you, and you can't tell the other side of a TCP link that you are no longer prepared to receive data (other than a read shutdown, but that just records state, and the other side won't know you are now refusing to receive data, until they try and send, and get a RST)
18:13:52  <MI6>libuv-node-integration: #333 UNSTABLE osx-x64 (1/680) osx-ia32 (1/680) smartos-x64 (7/680) smartos-ia32 (6/680) http://jenkins.nodejs.org/job/libuv-node-integration/333/
18:14:25  * mikealquit (Quit: Leaving.)
18:14:37  <octetcloud>I'm pretty sure, that even if your server actually did a full-close/shutdown, your client will print CLIENT end, but then sit there forever, since its allowing half open, but not closing it's half
18:15:00  <octetcloud>i.e., the client is buggy.
18:15:18  * paulfryz_joined
18:18:37  * paulfryzelquit (Ping timeout: 252 seconds)
18:18:48  * AvianFluquit (Remote host closed the connection)
18:22:38  * DarkGodWquit (Ping timeout: 246 seconds)
18:23:02  * skabbesjoined
18:23:14  * paulfryz_quit (Remote host closed the connection)
18:23:52  * paulfryzeljoined
18:26:20  * trevnorrisjoined
18:27:05  <trevnorris>morning all
18:28:35  <tjfontaine>g'day
18:30:21  * AvianFlujoined
18:30:31  <octetcloud>creationix: yeah, so even if node did a full close on .end() when allowHalfOpen is false, wouldn't help a lot in this example. though still might be better https://gist.github.com/sam-github/314cdf70907998009dde/revisions
18:35:20  * otwojoined
18:36:20  * kazuponquit (Remote host closed the connection)
18:45:41  <MI6>joyent/node: Sam Roberts v0.10 * 8aac118 : process: document kill(0), disallow kill(O_RDWR) - http://git.io/JZpSMQ
18:46:26  <groundwater>trevnorris: ahoy!
18:47:54  * c4miloquit (Remote host closed the connection)
18:55:18  * st_lukequit (Read error: Connection reset by peer)
18:55:43  * st_lukejoined
18:56:29  <MI6>nodejs-v0.10: #1635 FAILURE smartos-x64 (4/604) smartos-ia32 (4/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1635/
18:57:45  <tjfontaine>hmm
19:01:24  <MI6>nodejs-v0.10-windows: #353 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/353/
19:04:15  <hueniverse>howdy!
19:04:19  <hueniverse>I'm bored
19:04:55  <trevnorris>hueniverse: upgrade all the things to v0.11 :P
19:05:24  <hueniverse>someone on my team wanted to change the mongo write concern to 1 just to increase some load and break things
19:05:46  <hueniverse>at this point every member of my team made at least one stupid suggestion to make things unstable
19:06:01  <tjfontaine>haha
19:06:31  <hueniverse>trevnorris: any luck with the domains issues I pointed out in hapi two weeks ago?
19:07:02  * kazuponjoined
19:07:14  <trevnorris>hueniverse: honestly I haven't had time. between prep for my training and node summit tomorrow. but it's on my immediate list for things to do on thurs.
19:07:45  <hueniverse>trevnorris: no worries, I've been kinda busy too...
19:08:08  <trevnorris>oh what, with bf and all? eh, child's play. ;)
19:08:30  <groundwater>hueniverse: isn't today also a big online sales day?
19:09:41  <hueniverse>groundwater: cyber monday, which is technically a bigger deal for us revenues wise, but lower volume (more people come to shop than look, and less people looking up store stuff)
19:10:08  <tjfontaine>iow where the money is spent
19:10:39  <hueniverse>groundwater: but black friday was so boring, we didn't even bother to cycle the servers. they are still up since mid day Friday when we did a release (fuck yeah!)
19:10:52  <tjfontaine>:)
19:10:53  * loladiroquit (Quit: loladiro)
19:10:55  <hueniverse>that friday release was by itself nothing, but the fact we did it was fun
19:10:55  <tjfontaine>that's fucking awesome
19:11:22  <hueniverse>my nodesummit talk is really one slide with '#nodebf'
19:11:25  * loladirojoined
19:11:31  <groundwater>i guess nodesummit can just be hueniverse talking about how boring his graphs are
19:12:28  * mikealjoined
19:12:54  <MI6>nodejs-v0.10: #1636 UNSTABLE smartos-x64 (5/604) smartos-ia32 (5/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1636/
19:12:57  * skypjackjoined
19:13:18  <skypjack>hi all
19:13:26  <tjfontaine>hi
19:13:32  <skypjack>@creationix hi I'm Michele from Cynny
19:13:54  <skypjack>I was looking fro the discussion about FIN problem
19:18:09  <hueniverse>groundwater: that would be a very short summit
19:18:36  <hueniverse>I do have one surprise dedicated to tjfontaine... :-)
19:18:43  <tjfontaine>ut oh :)
19:19:23  * dshaw_quit (Quit: Leaving.)
19:20:49  * st_lukequit (Remote host closed the connection)
19:24:02  * wwicksquit (Quit: wwicks)
19:31:02  <creationix>skypjack, look for the comments by octetcloud at http://logs.libuv.org/libuv
19:32:31  <skypjack>ok, wait
19:32:52  <skypjack>I was looking the code of node (js/cc) and libuv
19:34:02  <creationix>skypjack, https://github.com/joyent/node, https://github.com/joyent/libuv
19:34:14  <creationix>in node, js is in /lib and C++ is in /src
19:34:26  <creationix>/lib/net.js is a good place to start looking
19:36:13  <skypjack>wait, I've yet downloaded the software :-)
19:40:08  <skypjack>about octetcloud comments: he's right but we can still have the problem if the client is a mobile device that losts connection... is it correct?
19:40:18  * kazuponquit (Ping timeout: 246 seconds)
19:40:31  <skypjack>I'm not sure about that
19:42:51  <skypjack>what about to shutdown the socket if close is called and the socket has been initialized with allowHalfOpen to false?
19:44:05  * paulfryzelquit (Ping timeout: 248 seconds)
19:45:25  * st_lukejoined
19:49:08  <skypjack>the problem is that we provide api and we cannot force clients to set allowHalfOpen to false
19:51:39  * wwicksjoined
19:57:08  * otwoquit (Ping timeout: 260 seconds)
20:01:27  * indexzerojoined
20:03:55  * st_lukequit (Remote host closed the connection)
20:04:51  * jmar777quit (Read error: Connection reset by peer)
20:05:22  * jmar777joined
20:09:24  * swajjoined
20:10:49  <skypjack>on the other side we have actors in our structure that act both as server and client
20:10:51  * swajrquit (Ping timeout: 258 seconds)
20:11:08  <skypjack>it's better to abstract from the concept of client and server
20:16:07  * inolenjoined
20:16:15  <mitsuhiko>jesus christ. that pr is still being discussed.
20:16:22  <mitsuhiko>closing issues for good cannot come soon enough
20:18:18  * st_lukejoined
20:18:58  <skypjack>@mitsuhiko can you give me some reference?
20:20:25  * octetcloudquit (Ping timeout: 272 seconds)
20:24:10  * jmar777quit (Read error: Connection reset by peer)
20:24:42  * jmar777joined
20:24:44  <skabbes>skypjack: hop on over to the node.js room, and you'll see what he/she is talking about
20:25:48  * AndreasMadsenjoined
20:32:11  * st_lukequit (Remote host closed the connection)
20:34:21  * otwojoined
20:37:04  * kazuponjoined
20:39:41  * c4milojoined
20:41:08  * dshaw_joined
20:41:23  * bajtosquit (Quit: bajtos)
20:50:06  * hzquit
21:06:07  * AndreasMadsenquit (Read error: Connection reset by peer)
21:06:30  <trevnorris>indutny: ping
21:06:34  <indutny>pong
21:07:10  * AndreasMadsenjoined
21:08:16  * AndreasMadsenquit (Read error: Connection reset by peer)
21:09:18  * AndreasMadsenjoined
21:09:26  <trevnorris>indutny: why is it we can't cork() when writing out to http? or can we, and it's just not res.cork()?
21:10:27  * kazuponquit (Ping timeout: 260 seconds)
21:11:29  <tjfontaine>trevnorris: depends on if the headers have already been sent, right?
21:11:47  <trevnorris>tjfontaine: nope. res.cork == undefined
21:12:07  <tjfontaine>trevnorris: no I mean, we already do cork, but depending on if headers have been sent?
21:12:20  <trevnorris>tjfontaine: ah, I see what you're saying. sec. let me try that out.
21:12:40  <trevnorris>tjfontaine: are you saying using setHeader will or will not cork?
21:13:34  <tjfontaine>trevnorris: see _http_outgoing.js OutgoingMessage.prototype.write
21:14:11  * timoxleyjoined
21:15:18  * mikeal1joined
21:15:49  * st_lukejoined
21:17:08  * aranhoidejoined
21:17:57  <trevnorris>tjfontaine: yeah. the logic seems strange. it has no possibility of chunking if the chunk is a string? why?
21:20:22  <trevnorris>tjfontaine: also, Tranfer-Encoding defaults to chunked, but res.chunkedEncoding == false in the connection listener.
21:20:38  * mikealquit (*.net *.split)
21:21:39  * AndreasMadsenquit
21:22:14  <hueniverse>how stable is master?
21:22:56  <creationix>mitsuhiko, and this is why I sometimes don't mind having a short backlog in my chat window. It's gone already.
21:23:06  <trevnorris>hueniverse: i'd say pretty good. wouldn't give it a production ready stamp, but it's doing well.
21:23:25  <creationix>trevnorris, what is basically left before the 0.12 release?
21:23:40  <hueniverse>creationix: my seal of approval :-)
21:23:47  <trevnorris>heh
21:23:50  <mitsuhiko>creationix: considering that the original author of the pull request is from the python community, i still need to read that controversy on twitter
21:24:41  <trevnorris>tjfontaine: and even though it corks, it immediately uncorks following the write. so each individual write() is corked, but a lot of good that does if I want all the write()'s in the connection listener to be corked
21:25:15  <tjfontaine>because it's about the ticks, internally we can't really make good decisions about that without necessarily starving it
21:25:26  <tjfontaine>I think there are more places we can
21:25:35  <trevnorris>and i'm wondering why I'm not allowed to say, res.cork()
21:25:41  <tjfontaine>that may just be an oversight
21:25:52  <trevnorris>ah ok. that's what I was wondering
21:33:00  <MI6>joyent/node: Gabriel Falkenberg v0.10 * 94c4ba9 : doc: change constant to consistent - http://git.io/eCGzqQ
21:34:17  * jmar777quit (Remote host closed the connection)
21:39:05  * c4miloquit (Remote host closed the connection)
21:41:41  <creationix>isaacs, is Bryan in IRC, it seems to be my only app that is working reliably on the internet right now.
21:44:35  <MI6>nodejs-v0.10: #1637 UNSTABLE smartos-x64 (5/604) smartos-ia32 (4/604) linux-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1637/
21:46:00  <MI6>joyent/node: Yazhong Liu v0.10 * bd7fa92 : doc: list execArgv option for child_process.fork() - http://git.io/hINXrQ
21:47:56  * paddybyersquit (Quit: paddybyers)
21:48:36  <MI6>nodejs-v0.10-windows: #354 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/354/
21:48:39  * paddybyersjoined
21:48:51  * octetcloudjoined
21:54:13  * mikeal1quit (Quit: Leaving.)
21:54:17  * kevinswiberquit (Remote host closed the connection)
21:54:51  * mikealjoined
21:57:25  <tjfontaine>ircretary: tell sblom holy fucking shit -- https://github.com/chrisa/node-dtrace-provider/pull/39 that's awesome.
21:57:26  <ircretary>tjfontaine: I'll be sure to tell sblom
21:57:38  * kevinswiberjoined
21:58:04  * skypjackquit (Quit: Sto andando via)
21:58:07  * skabbesquit (Quit: skabbes)
21:59:38  <tjfontaine>trevnorris: #6623 seems like the design decision behavior for our internal buffering
22:00:02  * c4milojoined
22:00:55  <MI6>nodejs-v0.10: #1638 UNSTABLE smartos-x64 (5/604) smartos-ia32 (5/604) linux-x64 (1/604) linux-ia32 (1/604) osx-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1638/
22:04:17  <MI6>nodejs-v0.10-windows: #355 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/355/
22:05:50  * octetcloudquit (Ping timeout: 240 seconds)
22:05:59  <trevnorris>tjfontaine: yeah. i'm having serious issues w/ it right now. it's casing all types of sporadic behavior when I try to pipe as much data through as possible.
22:06:03  <trevnorris>of any buffer size.
22:06:54  <trevnorris>tjfontaine: and, i'm missing some reference on the internal buffering. what commit/when was this done?
22:07:05  * kazuponjoined
22:07:52  <tjfontaine>the normal stream work
22:09:03  <tjfontaine>trevnorris: https://github.com/joyent/node/blob/master/lib/_stream_writable.js#L227-L247
22:13:08  <trevnorris>tjfontaine: well, whatever it is, all my benchmarks are useless right now because all Node is doing is filling up my memory.
22:14:03  <tjfontaine>are these numbers you're trying to gather for node summit?
22:14:28  <trevnorris>tjfontaine: yeah. I wanted to show performance improvements for using cork/uncork when writing a bunch of small requests over tcp
22:18:23  <tjfontaine>trevnorris: not sure what to say at the moment, I would start by confirming my suspicion that it's the normal buffering mechanism
22:18:43  <tjfontaine>trevnorris: for me this would mean taking a core and looking at it with findjsobjects
22:19:04  <trevnorris>tjfontaine: well, don't have enough time for that. need to finish my slides. i'm just going to roll back to a release that works.
22:20:02  <trevnorris>tjfontaine: mind confirming that there's nothing stupidly wrong w/ my example script? https://github.com/joyent/node/issues/6623
22:21:15  <tjfontaine>trevnorris: looking at it, I would expect it to fill with 16K of memory until the otherside started to actually read it
22:21:40  <trevnorris>tjfontaine: yeah. so would I. so I start the server, then listen with `nc localhost 8000 > /dev/null`
22:22:16  <trevnorris>tjfontaine: but then the node process quickly fills up memory (I SIGTERM around 2.5BG)
22:22:42  <tjfontaine>that's not good
22:22:50  <tjfontaine>because, we should be stopping around 1.5gb
22:23:03  <tjfontaine>unless the over head is in writereq's
22:23:59  <trevnorris>yeah. I haven't output how many write's are happening, but i'm assuming it's a crap ton.
22:24:17  * skabbesjoined
22:24:50  * aranhoidequit (Ping timeout: 264 seconds)
22:25:00  <trevnorris>hm. maybe it's something w/ nc? if I `telnet localhost 8000 > /dev/null` it's freakin slow, but at least it doesn't fill up memory.
22:27:45  * rendarquit
22:29:39  <trevnorris>tjfontaine: i'm forcing the write loop to quit after 1e6 writes for a 1KB buffer, and the drain event is never firing.
22:29:55  <trevnorris>tjfontaine: i'm going to do a clean build and see if that fixes it
22:32:09  <tjfontaine>I'm seeing it as well, I'm running findjsobjects, it's taking a while so presumably this is mostly in the js heap
22:32:49  <tjfontaine>hmm, 88MB in the heap, 230MB in rss in this core
22:32:58  <tjfontaine>probably just going to be a ton of objects
22:34:51  <trevnorris>tjfontaine: ok, try the second example here: https://github.com/joyent/node/issues/6623
22:35:21  <trevnorris>tjfontaine: it shouldn't be possible that it's filling up memory. since it should only be calling the callback once the write is complete. correct?
22:38:20  <tjfontaine>8e499d9d 1 565372 Array
22:38:20  <tjfontaine>80ed7b79 565376 2 Object: callback, _asyncQueue
22:38:20  <tjfontaine>80eafa39 565374 3 Object: oncomplete, buffer, bytes
22:39:01  <trevnorris>whoa, wtf.
22:39:27  <tjfontaine>I'm guessing you're never seeing a false returned?
22:39:38  * dshaw_quit (Quit: Leaving.)
22:40:09  <tjfontaine>how does that second one fill up memory?
22:40:29  * kazuponquit (Ping timeout: 265 seconds)
22:41:04  <trevnorris>tjfontaine: heck if I know. it's calling the callback before stuff is flushed I guess?
22:41:06  * philipsquit (Quit: http://ifup.org)
22:41:18  <trevnorris>was hoping you could confirm that, because it seems impossible to me that would be happening.
22:41:39  <tjfontaine>that second one is basically all in the heap
22:41:45  <tjfontaine>090EF000 180960K rwx-- [ heap ]
22:41:53  <tjfontaine> total 271440K
22:42:05  <trevnorris>so it's filling memory for you too?
22:42:58  <tjfontaine>oh I missed the second one has a write cb
22:43:21  <trevnorris>yeah. sorry. it's not very explicit in what it does
22:43:25  <trevnorris>i'll add a comment to point that out
22:43:39  <tjfontaine>so these are basically all going to be WriteReq's
22:44:03  <tjfontaine>not sure why in your second example the cb's are being fired though
22:44:17  <trevnorris>yeah, that also has me stumped.
22:44:21  <tjfontaine>or rather why we're not going through the writeOrBuffer path
22:44:59  * philipsjoined
22:45:13  <trevnorris>ok. it's not happening on v0.10. i'm going to update the scripts to also be v0.10 compliant.
22:46:17  <tjfontaine>hmm this second one is interesting
22:46:27  <tjfontaine>8030bd19 1235639 0 Object
22:46:36  <tjfontaine>1.2m empty object
22:46:37  <tjfontaine>s
22:46:45  <trevnorris>um... ok.
22:47:40  <tjfontaine>basically all out of the 128 byte arena, so very tiny
22:47:59  <tjfontaine>really only results in 44k of usage
22:48:13  <trevnorris>strange. there's got to be something wrong w/ my first script. it's causing the same issue in v0.10 as well.
22:48:36  <tjfontaine>a wrong assumption I guess on when write returns false
22:48:58  * skabbesquit (Quit: skabbes)
22:49:04  <trevnorris>yeah. i'll go back and build, like, 10.15 or something.
22:49:21  <tjfontaine>trevnorris: you might look at https://github.com/joyent/node/issues/6506
22:49:37  * kevinswiberquit (Remote host closed the connection)
22:49:43  * skabbesjoined
22:50:48  <trevnorris>tjfontaine: thanks. yeah, these all look related.
22:52:00  <trevnorris>wtf is going on. even v0.10.15 has the same issue on that first script. I swear I've used this same script in the past to test my thoughput.
22:53:40  <trevnorris>isaacs: you around?
22:54:37  * loladiroquit (Quit: loladiro)
22:54:50  <trevnorris>tjfontaine: on the side, I think sooner rather than later we should go through ben's open PRs and decide what we want to do w/ them.
22:54:58  * loladirojoined
22:55:00  <trevnorris>just food for thought, don't mean in the next few days or anything
22:55:34  <tjfontaine>trevnorris: as we would in our normal process though?
22:55:59  * loladiroquit (Client Quit)
22:56:25  <trevnorris>tjfontaine: um, sure? I mean, at least his PR for exposing v8's profiling utils isn't a trivial change. but really useful.
22:56:28  * loladirojoined
22:56:38  <trevnorris>and since it's an API addition think it should get in sooner rather than later
22:59:44  * loladiroquit (Client Quit)
23:00:23  * loladirojoined
23:00:40  * m76quit (Read error: Connection reset by peer)
23:01:08  <trevnorris>but whatever. it's way less important than this issue.
23:01:08  * dshaw_joined
23:01:18  <trevnorris>tjfontaine: so, do you know where those 1.2m empty objects originate from?
23:06:31  <tjfontaine>trevnorris: I didn't get too in depth on it
23:06:47  <trevnorris>tjfontaine: cool. thanks for at least confirming that it's happening for you too.
23:09:18  <tjfontaine>trevnorris: it's happening, I'm not sure if it's a bug per se, so much as me not realizing the assumptions that are made
23:12:05  <trevnorris>tjfontaine: similar to that issue you linked, there's an internally incorrect check that causes drain to never be emitted.
23:12:40  <trevnorris>tjfontaine: i'm writing out 10MB all at once and node is never firing drain.
23:14:19  <trevnorris>tjfontaine: actually, wait. I think it might be that node is processing data too quickly on my local box. so drain never needs to be emitted, which causes the infinite while (write) loop. think that's possible?
23:14:50  <tjfontaine>it's possible that it's dispatching it to the OS faster than the side is reading
23:15:31  * kenperkinsquit (Quit: Computer has gone to sleep.)
23:15:36  * abraxasjoined
23:16:17  <trevnorris>hm. I have a variation of the script that's causing unusual output. one sec.
23:17:24  * st_lukequit (Remote host closed the connection)
23:19:47  * mikealquit (Quit: Leaving.)
23:20:00  <MI6>joyent/node: Fedor Indutny v0.10 * 60f777d : tls: fix pool usage race - http://git.io/50mkmA
23:20:15  <trevnorris>tjfontaine: here it is: https://github.com/joyent/node/issues/6623#issuecomment-29668694
23:20:39  * abraxasquit (Ping timeout: 252 seconds)
23:20:40  <trevnorris>tjfontaine: by forcing write() to be called in a setImmediate() it seems to allow things to be cleaned up.
23:20:50  <trevnorris>tjfontaine: but for some reason everything builds up until that point.
23:20:59  <tjfontaine>sure, some event loop iteration at least
23:21:00  * mikealjoined
23:21:29  <tjfontaine>memory will continue to grow though because you're always writing on the first iteration of the loop?
23:22:35  <trevnorris>tjfontaine: doesn't setImmediate run at the end of the eloop?
23:22:49  <trevnorris>and I don't know why memory is still growing
23:23:20  <tjfontaine>the point is setImmediate is at least yielding, it's possible your previous scripts weren't actually yielding
23:23:49  <tjfontaine>and memory can still grow because each iteration of the for loop will result a write, regardless of counter size
23:24:01  <tjfontaine>swap the two comparisons and you will perhaps get a better situation
23:24:21  <trevnorris>tjfontaine: that seems to be what's happening. but why the flush callback would be called synchronously seems strange to me.
23:24:27  <trevnorris>and yeah. just swapped them :)
23:25:24  <trevnorris>what's strange though is after running for a minute it just stops writing completely. don't know why yet.
23:25:35  <tjfontaine>probably has reached HWM
23:25:39  <tjfontaine>or whatever
23:26:28  * skabbesquit (Read error: Connection reset by peer)
23:26:41  * skabbesjoined
23:27:21  <trevnorris>well crap. whatever. really need to finish these slides.
23:27:24  <trevnorris>guess for another day.
23:29:08  <trevnorris>oy, there was an issue in the while loop. doesn't fix the problem, but is at least reporting better numbers.
23:30:57  <MI6>nodejs-v0.10: #1639 UNSTABLE smartos-x64 (4/605) smartos-ia32 (4/605) linux-ia32 (1/605) osx-x64 (1/605) http://jenkins.nodejs.org/job/nodejs-v0.10/1639/
23:32:13  * st_lukejoined
23:33:48  * pachetquit (Quit: leaving)
23:34:41  * paddybyersquit (Quit: paddybyers)
23:35:21  <MI6>nodejs-v0.10-windows: #356 UNSTABLE windows-ia32 (10/605) windows-x64 (13/605) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/356/
23:37:06  * kazuponjoined
23:39:26  <trevnorris>tjfontaine: so. conn._writableState.length is always 0 when writing small buffers. not sure why that's happening.
23:39:32  <trevnorris>so it's never > HWM
23:40:02  <tjfontaine>this is in a pure net test, right?
23:40:29  <trevnorris>yeah
23:41:55  <tjfontaine>is _writableState.buffer.length 0?
23:42:06  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:42:16  * TooTallNatejoined
23:42:17  <trevnorris>let me check
23:44:06  <trevnorris>tjfontaine: so, state.buffer.length is always == 0, even before doWrite() is fired.
23:44:29  <tjfontaine>right, ok that makes sense
23:44:40  <trevnorris>ah, ok. so it's never being pushed to .buffer. it's just being written out.
23:44:49  <tjfontaine>buffer.length *should* be 0 before doWrite, things should only go to buffer if something has already done doWrite
23:45:20  <tjfontaine>so it's the fact we're in sync mode for writes that's tripping you up
23:45:40  <trevnorris>ok. so how is it we got into sync mode?
23:45:58  <trevnorris>(didn't even realize there was a "sync" mode)
23:46:53  <tjfontaine>we're basically always in, unless someone calls write while we're already writing
23:47:09  <tjfontaine>state.writing is getting set to false
23:47:39  <tjfontaine>which means onwriteStateUpdate is firing
23:48:12  <tjfontaine>sorry have to context switch
23:48:40  <trevnorris>no worries.
23:50:17  <trevnorris>ah, so this._handle.writeQueueSize is always === 0 for small writes
23:50:25  <trevnorris>which prevents the eloop from every continuing.
23:51:32  <trevnorris>tjfontaine: so "sync" mode is that the callback will be called synchronously if the queue was flushed?
23:56:14  * dshaw_quit (Quit: Leaving.)
23:57:00  * inolenquit (Ping timeout: 260 seconds)
23:58:17  * AvianFluquit (Ping timeout: 246 seconds)