00:00:05  * daviddiasquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:00:43  * daviddiasjoined
00:04:20  * dsantiagoquit (Quit: Computer has gone to sleep.)
00:04:58  * daviddiasquit (Ping timeout: 240 seconds)
00:18:25  * c4milojoined
00:18:29  * daviddiasjoined
00:19:33  * brsonquit (Ping timeout: 240 seconds)
00:22:42  * c4miloquit (Ping timeout: 245 seconds)
00:30:11  * a_lequit (Remote host closed the connection)
00:33:16  * daviddiasquit (Remote host closed the connection)
00:36:14  * zz_karupachanged nick to karupa
00:46:56  * a_lejoined
00:46:59  * dap_quit (Quit: Leaving.)
00:56:59  * a_lequit (Remote host closed the connection)
00:58:32  * a_lejoined
01:01:00  * thlorenzjoined
01:05:18  * thlorenzquit (Ping timeout: 240 seconds)
01:15:09  * kazuponjoined
01:20:54  * thlorenzjoined
01:21:43  * dsantiagojoined
01:28:56  * Ralithquit (Ping timeout: 250 seconds)
01:30:18  * thlorenzquit (Remote host closed the connection)
01:30:55  * thlorenzjoined
01:34:11  * kazuponquit (Remote host closed the connection)
01:34:20  * AvianFlujoined
01:35:19  * thlorenzquit (Ping timeout: 250 seconds)
01:49:05  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:51:24  * seldojoined
01:53:35  * kazuponjoined
02:01:54  * Ralithjoined
02:04:18  * thlorenzjoined
02:06:30  * c4milojoined
02:08:32  * thlorenzquit (Ping timeout: 245 seconds)
02:08:44  * seldoquit (Remote host closed the connection)
02:11:03  * c4miloquit (Ping timeout: 256 seconds)
02:13:01  * a_lequit (Ping timeout: 250 seconds)
02:16:03  * euoiajoined
02:30:54  * saghulquit (Ping timeout: 250 seconds)
02:31:09  * rosskquit
02:31:18  * euoiaquit (Ping timeout: 240 seconds)
02:38:27  * avalanch_quit (Remote host closed the connection)
02:39:01  * avalanche123joined
02:42:00  * avalanch_joined
02:43:18  * avalanche123quit (Ping timeout: 240 seconds)
02:46:49  * Left_Turnquit (Remote host closed the connection)
02:56:50  * avalanch_quit (Remote host closed the connection)
02:57:22  * avalanche123joined
02:58:53  * euoiajoined
03:02:23  * avalanche123quit (Ping timeout: 264 seconds)
03:04:01  * yunongjoined
03:06:19  * avalanche123joined
03:11:10  * avalanche123quit (Remote host closed the connection)
03:11:42  * avalanche123joined
03:16:13  * avalanche123quit (Ping timeout: 256 seconds)
03:33:00  * seldojoined
03:38:48  * c4milojoined
03:43:03  * c4miloquit (Ping timeout: 240 seconds)
03:44:05  * c4milojoined
03:44:24  * a_lejoined
03:47:59  * daviddiasjoined
04:03:26  * kazuponquit (Remote host closed the connection)
04:10:56  * thlorenzjoined
04:11:17  * seldoquit (Remote host closed the connection)
04:11:22  * daviddiasquit (Ping timeout: 264 seconds)
04:12:14  * daviddiasjoined
04:12:18  * euoiaquit (Ping timeout: 240 seconds)
04:16:28  * yunongquit
04:17:41  * avalanche123joined
04:29:49  <bradleymeck>is there any reason we can't use GetMessage/PostMessage in WIN32 to do something like SIGUSR1 activates the debugger? Unsure the cost of keeping a thread just sitting there waiting for the message to come in
04:37:10  * avalanche123quit (Remote host closed the connection)
04:37:38  * avalanche123joined
04:42:34  * avalanche123quit (Ping timeout: 264 seconds)
04:49:19  * avalanche123joined
04:57:04  * c4miloquit (Remote host closed the connection)
05:02:18  * kazuponjoined
05:06:33  * kazuponquit (Ping timeout: 240 seconds)
05:11:42  * kazuponjoined
05:27:42  * daviddiasquit (Ping timeout: 245 seconds)
05:34:55  * seishunjoined
05:55:58  * rmgquit (Remote host closed the connection)
05:57:15  * seldojoined
05:57:15  * seldoquit (Remote host closed the connection)
05:57:21  * seldojoined
05:57:46  * dshaw_joined
05:59:50  * rmgjoined
06:08:33  * a_lequit (Ping timeout: 240 seconds)
06:34:06  * thlorenzquit (Remote host closed the connection)
06:34:43  * thlorenzjoined
06:39:34  * thlorenzquit (Ping timeout: 264 seconds)
06:42:06  * rendarjoined
06:46:47  * seishunquit (Ping timeout: 264 seconds)
06:52:41  * Soarez|afkchanged nick to Soarez
07:02:19  * Soarezchanged nick to Soarez|afk
07:46:27  * Soarez|afkchanged nick to Soarez
07:54:06  * dshaw_quit (Quit: Leaving.)
08:04:54  * avalanche123quit (Remote host closed the connection)
08:05:21  * avalanche123joined
08:06:52  * rendarquit (Ping timeout: 245 seconds)
08:10:02  * avalanche123quit (Ping timeout: 255 seconds)
08:16:44  * avalanche123joined
08:19:04  * avalanche123quit (Remote host closed the connection)
08:22:00  * c4milojoined
08:26:45  * c4miloquit (Ping timeout: 256 seconds)
08:38:41  <txdv_>is it possible that libuv will call a shutdown callback with the req == null?
08:38:49  <txdv_>UV_EXTERN int uv_shutdown(uv_shutdown_t* req,
08:44:01  * rmgquit (Remote host closed the connection)
09:15:13  * Left_Turnjoined
09:43:26  * saghuljoined
09:44:36  * rmgjoined
09:49:02  * rmgquit (Ping timeout: 255 seconds)
10:10:09  * c4milojoined
10:14:30  * piscisaureusjoined
10:14:51  * karupachanged nick to zz_karupa
10:14:58  * c4miloquit (Ping timeout: 264 seconds)
10:19:41  * janjongboomjoined
10:51:08  * mrvisserjoined
10:53:38  * mrvisserquit (Client Quit)
10:53:59  * mrvisserjoined
10:59:57  * Soarezchanged nick to Soarez|afk
11:03:18  * Soarez|afkchanged nick to Soarez
11:06:20  * Soarezchanged nick to Soarez|afk
11:10:34  * MI6joined
11:19:23  <MI6>joyent/libuv: Andrius Bentkus master * 960eefb : unix: guarantee write queue cb execution order in streams - http://git.io/kBJnpw
11:21:02  <saghul>txdv_: ^
11:36:39  <indutny>yay!
11:36:46  <indutny>saghul: so only one PR is left before v0.12 libuv?
11:36:49  <indutny>ohai, btw
11:52:47  * piscisaureusquit (Ping timeout: 255 seconds)
11:58:29  * c4milojoined
12:01:31  * mrvisserquit (Remote host closed the connection)
12:02:58  * c4miloquit (Ping timeout: 240 seconds)
12:13:22  * mrvisserjoined
12:14:47  * kazuponquit (Remote host closed the connection)
12:21:52  * euoiajoined
12:25:46  <saghul>indutny: ohai!
12:25:48  <saghul>a few
12:26:02  <saghul>I'll try to make a milestone thin on GH over the weekend
12:26:29  <saghul>there are a couple of others we should check/land, for the Julia and Rust folks
12:29:02  <indutny>ok,thanks
12:38:59  * bradleymeckquit (Quit: bradleymeck)
12:52:38  * euoiaquit (Ping timeout: 240 seconds)
12:55:39  * bradleymeckjoined
12:57:07  * c4milojoined
13:03:59  * avalanche123joined
13:06:21  * c4miloquit (Remote host closed the connection)
13:08:18  * avalanche123quit (Ping timeout: 240 seconds)
13:08:38  * Soarez|afkchanged nick to Soarez
13:09:33  * Damn3dquit (Ping timeout: 240 seconds)
13:11:28  * euoiajoined
13:12:16  * Damn3djoined
13:25:12  * a_lejoined
13:29:59  * a_lequit (Ping timeout: 264 seconds)
13:36:43  * bradleymeckquit (Ping timeout: 256 seconds)
13:38:45  * c4milojoined
13:43:07  * c4miloquit (Ping timeout: 245 seconds)
13:47:27  * bradleymeckjoined
14:03:01  * bradleymeckquit (Read error: Connection reset by peer)
14:05:00  * bradleymeckjoined
14:12:38  * euoiaquit (Ping timeout: 240 seconds)
14:14:16  * seishunjoined
14:17:12  * kenperkinsquit (Remote host closed the connection)
14:22:58  * a_lejoined
14:24:00  * kenperkinsjoined
14:24:13  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:25:12  * euoiajoined
14:28:11  * c4milojoined
14:32:17  * mrvisserquit (Remote host closed the connection)
14:36:03  <kellabyte_>morning all!
14:38:25  <kellabyte_>forgive me since I don't know node.js well, how does node.js work with libuv and multiple requests if a handler (maybe wrong term?) is taking too long? do they all wait or do you parallelize still processing other requests but synchronize later to ensure you respond in order?
14:50:00  * c4miloquit (Remote host closed the connection)
14:59:59  * c4milojoined
15:10:26  * kazuponjoined
15:19:23  * kenperkinsquit (Remote host closed the connection)
15:25:18  * euoiaquit (Ping timeout: 240 seconds)
15:29:13  <othiym23>kellabyte_: depends on whether it's network requests (which can all be handled asynchronously, so it's basically just memory cost having multiple requests being handled concurrently) or file I/O (which gets tangled up in the absence of reliable async APIs, and so which uses a thread pool to handle requests)
15:29:51  * euoiajoined
15:30:02  <othiym23>kellabyte_: if anything is blocking inside V8, though, it's game over, and the whole process will be blocked
15:30:13  <othiym23>kellabyte_: so you gotta define which kind of "taking too long" you're talking about
15:36:58  * kenperkinsjoined
15:39:28  * daviddiasjoined
15:39:46  * daviddiasquit (Client Quit)
15:40:07  * daviddiasjoined
15:40:38  * mrvisserjoined
15:43:36  * kazuponquit (Remote host closed the connection)
15:46:18  * euoiaquit (Ping timeout: 240 seconds)
15:46:57  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
15:47:56  * daviddiasjoined
15:56:45  * AlexisMochajoined
16:00:11  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
16:00:48  * TooTallNatejoined
16:00:49  * euoiajoined
16:04:58  * avalanche123joined
16:05:47  * kazuponjoined
16:07:23  * rmgjoined
16:07:40  * rendarjoined
16:09:17  * avalanche123quit (Ping timeout: 255 seconds)
16:10:19  * daviddiasjoined
16:14:45  * dap_1joined
16:22:17  * kazuponquit (Remote host closed the connection)
16:38:12  * rosskjoined
16:41:24  * bradleymeckquit (Quit: bradleymeck)
16:49:39  <kellabyte_>othiym23: I guess I'm more thinking of proper libuv usage, I'm using node.js as an example since it's using it but maybe the V8 integration adds another aspect that I don't need to worry about
16:50:00  <nathan7>kellabyte_: one event loop, one thread
16:50:09  <nathan7>kellabyte_: a thread processes one event at a time
16:50:29  <kellabyte_>nathan7: right, but you can spawn new threads with libuv to process things
16:50:44  <nathan7>kellabyte_: like, node only ever has one event loop
16:50:49  <nathan7>kellabyte_: because JS only ever has one thread
16:51:09  <kellabyte_>ok, but you can still use threads in libuv with a single event loop
16:51:26  <nathan7>Well, yeah, you can send things into the loop from other threads
16:51:36  <nathan7>but they'll be processed by that one thread still, sequentially
16:52:03  <kellabyte_>even this? http://nikhilm.github.io/uvbook/threads.html
16:52:12  <kellabyte_>I'm talking worker threads
16:52:16  <tjfontaine>I'm confused about the question in general -- what are you thinking about more
16:53:20  <kellabyte_>tjfontaine: so there are things that can be done in parallel even if the first request is still waiting for some resource, so you can start processing the 2nd request after it (say http parsing the request headers, etc)
16:53:52  <kellabyte_>but you'll have to block until the first is complete before you respond from the 2nd
16:53:54  <tjfontaine>but we're talking about application layer as opposed to something more lower level like a network resource
16:54:17  * qard-homejoined
16:54:38  * euoiaquit (Ping timeout: 240 seconds)
16:54:38  <kellabyte_>well I'm asking if this is what people do with libuv and how, I was using node.js as an example of a libuv consumer
16:54:45  <kellabyte_>maybe I shouldn't have mentioned it lol
16:55:04  <tjfontaine>heh ok
16:55:56  * euoiajoined
16:56:02  <tjfontaine>I think it depends on the application you're trying to do -- http headers aren't the best example -- but if you do have some cpu intensive work that can be done off loop while waiting on other data -- then sure you can use a thread to do so, but then you will want something to serialize the results once the other portions have finished
16:56:17  <kellabyte_>right
16:56:35  <kellabyte_>my question was if node.js did anything like that, and how it's usage of libuv was to do it, that's the reason I brought it up
16:56:51  <kellabyte_>just as a starting discussion so I could learn how I should do it
16:57:16  * dshaw_joined
16:57:18  <tjfontaine>well libuv does do something like that for FS operations, but node.js does not necessarily do anythign like that -- aside from kinda something like spawnSync
16:57:42  <tjfontaine>there may be binary addons leveraging libuv that do this though
16:58:01  <kellabyte_>binary addons?
16:58:10  <kellabyte_>what does that mean?
16:58:12  <tjfontaine>people writing modules for node.js in C/C++
16:58:52  <kellabyte_>ahh ok
16:59:01  <tjfontaine>summer in the bay is weird -- I need the clouds to burn off.
16:59:14  <kellabyte_>thanks for the info tjfontaine :)
16:59:24  <tjfontaine>kellabyte_: no problem
16:59:41  <kellabyte_>has there been any further discussions about handing off handles to other event loops?
16:59:45  <nathan7>hmm
16:59:52  * nathan7should go back to figuring out uv_poll
17:00:26  <kellabyte_>the IPC bug on windows is still broken and there's no way to hand off handles, so I haven't found a way to do multiple event loops on windows now
17:00:31  <kellabyte_>or maybe I should revert back to 0.7 I think it was
17:00:47  <tjfontaine>kellabyte_: maybe AlexisMocha can help with your ipc bug? he's our man from MSFT
17:00:58  * euoiaquit (Ping timeout: 240 seconds)
17:01:11  <kellabyte_>tjfontaine: oh cool! thanks :) I'll talk to AlexisMocha
17:01:37  <kellabyte_>looks like the IPC stuff got refactored and when it did the benchmarks broke
17:02:18  <kellabyte_>tjfontaine: thanks so much, you rock :)
17:02:28  <tjfontaine>heh, glad to be of service
17:04:49  * daviddiasquit (Ping timeout: 250 seconds)
17:05:17  * daviddiasjoined
17:12:07  * avalanche123joined
17:18:07  * daviddiasquit (Ping timeout: 245 seconds)
17:21:09  <indutny>tjfontaine: ping pong
17:21:10  <indutny>heya
17:21:18  <indutny>any v0.12 blockers to share with me? :)
17:21:34  <indutny>is it still the same thing that only you and trevor know what to do about?
17:23:48  <tjfontaine>I am writing them up and will have an email this weekend
17:24:15  <tjfontaine>there's at least the nextTick in streams that we added that breaks some things we need to figure out
17:24:25  <tjfontaine>we can have chrisdickinson look into that
17:25:07  <chrisdickinson>ah interesting
17:25:56  <chrisdickinson>is there an issue # for that?
17:26:34  <tjfontaine>off the top of my head I don't know, but it manifests on smartos and I haven't had a chance to root cause it, http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=ia32,label=smartos/lastCompletedBuild/tapTestReport/simple.tap-564/
17:26:35  * euoiajoined
17:26:55  <tjfontaine>chrisdickinson: do you have access to a smartos box through walmart or would you need access to one?
17:27:39  <chrisdickinson>i've got a (slightly janky) vm on my computer, I can see if I can get access to a WM one
17:28:13  <tjfontaine>chrisdickinson: I can just give you access to core teams infra, what's your ssh pubkey? what's on github?
17:28:28  <chrisdickinson>https://github.com/chrisdickinson.keys
17:28:38  <tjfontaine>k
17:28:58  <chrisdickinson>thanks!
17:30:58  <tjfontaine>chrisdickinson: ok, you should be able to `ssh root@smartos.nodejs.org`
17:31:13  <tjfontaine>chrisdickinson: there's a lot of junk stored in there, just make yourself a workspace in there
17:31:34  <chrisdickinson>ah, rad, thanks!
17:41:06  <indutny>tjfontaine: yeah
17:41:13  <indutny>tjfontaine: ok, nice!
17:49:08  * c4miloquit (Remote host closed the connection)
17:49:52  * kenperkinsquit (Remote host closed the connection)
17:50:25  <chrisdickinson>weird, it's not failing off of a fresh build for me
17:52:38  <tjfontaine>sometimes you have ot do interesting things to test to match how jenkins runs the test
17:52:54  <tjfontaine>python tools/test.py simple < configure
17:53:19  <tjfontaine>because stdio is redirected through so many ridiculous levels of indirection
17:53:31  <chrisdickinson>ah!
17:53:55  <tjfontaine>python is doing one thing, java/jenkins is doing another
17:54:09  * mrvisserquit (Remote host closed the connection)
17:55:38  * kenperkinsjoined
18:01:11  <chrisdickinson>how is java configured to run the test suite?
18:01:23  <chrisdickinson>(I don't think I have access to see tht)
18:01:26  <chrisdickinson>s/tht/that/g
18:02:27  <tjfontaine>well, that's basically how it works ... hang on
18:03:03  * mrvisserjoined
18:04:05  <tjfontaine>chrisdickinson: https://gist.github.com/tjfontaine/87f5734aa171aac6f8dd
18:04:30  * bradleymeckjoined
18:04:56  <tjfontaine>chrisdickinson: but as far as what jenkins does it's not easy for me to see, but basically when testing for these types of changes I `cat somefile | python tools/test` or `python tools/test.py < somefile`
18:05:37  <chrisdickinson>cool, yeah, i've tested with the various forms of redirect -- only remaining one i haven't tried to get a TCP socket instead of a pipe socket
18:14:36  * avalanche123quit (Remote host closed the connection)
18:15:16  * avalanche123joined
18:15:17  * avalanche123quit (Remote host closed the connection)
18:15:33  * avalanche123joined
18:19:02  * brsonjoined
18:21:07  * c4milojoined
18:21:40  * Soarezchanged nick to Soarez|afk
18:25:32  * c4miloquit (Ping timeout: 250 seconds)
18:28:34  * brsonquit (Ping timeout: 250 seconds)
18:35:54  * KiNgMaRquit (*.net *.split)
18:35:54  * tjfontainequit (*.net *.split)
18:36:02  * tjfontainejoined
18:36:26  * tjfontainechanged nick to Guest43087
18:44:02  <chrisdickinson>hm, thus far i've only been able to reproduce by piping a command that never exits in, or redirecting input from a tcp server that similarly never stops writing
18:45:17  <Guest43087>hm
18:45:21  * dshaw_quit (Quit: Leaving.)
18:45:38  * Guest43087quit (Changing host)
18:45:39  * Guest43087joined
18:46:07  * Guest43087changed nick to tjfontaine
18:48:14  <chrisdickinson>it looks like (according to jenkins) it's failing on both x64 and ia32, but without an endless net.socket, i can't get it to hang as expected. the python stuff *should* be fine -- it should inherit stdin from its parent.
18:49:32  <tjfontaine>well, that is actually not correct because the job was only ever building the native arch, instead of both
18:50:31  <chrisdickinson>ah -- i was comparing http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=x64,label=smartos/1298/tapTestReport/simple.tap-564/ to http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=ia32,label=smartos/1298/tapTestReport/simple.tap-564/
18:50:56  <chrisdickinson>but they both build the native arch?
18:50:58  <tjfontaine>ya, I'm removing wrk from the build, so we can get a clean
18:51:42  <tjfontaine>ya unfortunately --dest-cpu wasn't being passed, I fixed that and then `wrk` isn't respecting the defined arch
18:52:22  <chrisdickinson>aah
18:54:17  <tjfontaine>we should have a better run this time aside from ubuntu 14.04
18:55:32  * c4milojoined
19:04:41  * avalanche123quit (Remote host closed the connection)
19:05:15  * avalanche123joined
19:09:55  * avalanche123quit (Ping timeout: 256 seconds)
19:10:40  <tjfontaine>chrisdickinson: ok so good news is it's failing int he same way on both archs, http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=ia32,label=smartos/lastCompletedBuild/tapTestReport/ and http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=x64,label=smartos/1301/tapTestReport/
19:11:41  <chrisdickinson>interesting that the async version of the test is breaking too
19:16:21  * avalanche123joined
19:31:04  <chrisdickinson>i *think* i might have tracked it down
19:33:04  <chrisdickinson>`node -e 'setInterval(process.stdout.write.bind(process.stdout, "beep"), 100)' | node test/simple/test-stdin-pause-resume-sync.js` would eventually close, and EPIPE the writing process as of 0.10
19:33:31  <chrisdickinson>but, on a build of master, it doesn't close, and doesn't EPIPE
19:33:57  <chrisdickinson>it just stays open -- continually doing the maybeReadMore dance.
19:52:22  * KiNgMaRjoined
19:55:08  * ircretaryquit (*.net *.split)
19:55:17  * ircretaryjoined
19:55:18  * rmgquit (*.net *.split)
19:55:18  * a_lequit (*.net *.split)
19:55:19  * Left_Turnquit (*.net *.split)
19:55:19  * qard-appnetaquit (*.net *.split)
19:55:37  * qard-appnetajoined
19:55:47  * Left_Turnjoined
19:55:54  * rmgjoined
19:56:52  * a_lejoined
20:08:30  * bradleymeckquit (Quit: bradleymeck)
20:33:00  <mmalecki>chrisdickinson: that's smartos?
20:33:43  <chrisdickinson>i was running this on smartos, yes -- but it appears to happen on osx too with that setup
20:34:20  <chrisdickinson>my *guess* is that either jenkins is handing python tools/test.py a weird stdin
20:35:19  <tjfontaine>right it's all sorts of indirection happening -- it is indeed frustrating but in this case it probably does represent a bug of some sort
20:36:11  <mmalecki>chrisdickinson: would be happy to help with debugging that when I get home -- that seems concerningly similar to a case I've seen in production
20:36:24  <mmalecki>chrisdickinson: I never got to repro that one tho
20:36:40  <chrisdickinson>it definitely is a change from v0.10's behavior
20:40:18  <chrisdickinson>https://gist.github.com/chrisdickinson/c29ba12b7f1a4fcc3539#file-gistfile1-txt-L19
20:40:41  <tjfontaine>we added a nextTick that I think is causing this
20:40:47  <tjfontaine>it came in through a merge commit
20:40:54  <chrisdickinson>so resume_ is getting called after the pause, triggering a read, which triggers a maybeReadMore
20:41:42  <chrisdickinson>tjfontaine: the resume_ nextTick?
20:42:03  <tjfontaine>I bet it's https://github.com/joyent/node/commit/4128d4d2ba8f346cab2b062f57ae4cb4831e7bb5
20:42:48  <tjfontaine>probably needing a merge of 0.10 into master
20:43:23  <chrisdickinson>hm, oldMode is entirely unused now
20:43:53  <tjfontaine>well I think that was the case during the merge as well
20:44:14  * bradleymeckjoined
20:44:26  * bradleymeckquit (Client Quit)
20:45:03  <chrisdickinson>hm
20:46:26  <chrisdickinson>i'm seeing this as: resume is scheduled, then pause is called. resume is called on next tick, ignoring the fact that it's paused. this calls read(0), which calls _read, which in net restarts the handle with a readStart, ondata starts pushing data back into the stream
20:46:52  <tjfontaine>right
20:47:18  <chrisdickinson>(at which point we've constructed a sort of maybeReadMore glider gun)
20:50:39  <chrisdickinson>(interestingly, if you make it so that `needMoreData` returns false, it actually *still* doesn't close the stream, since maybeReadMore causes the net.Socket to readStop/readStart it over and over instead.)
20:53:21  * avalanche123quit (Remote host closed the connection)
20:53:56  * avalanche123joined
20:55:20  * avalanche123quit (Remote host closed the connection)
20:55:36  * avalanche123joined
20:55:54  * c4miloquit (Remote host closed the connection)
21:03:47  * c4milojoined
21:28:32  <chrisdickinson>hm, I'm hesitant to add more state tracking to ReadableState, but https://gist.github.com/chrisdickinson/397767a085f8b1227340 appears to restore 0.10 behavior
21:31:43  * brsonjoined
21:41:18  * euoiaquit (Ping timeout: 240 seconds)
21:43:58  * euoiajoined
21:57:18  * euoiaquit (Ping timeout: 240 seconds)
22:00:29  * Damn3dquit (Ping timeout: 256 seconds)
22:00:47  * seishunquit (Ping timeout: 250 seconds)
22:03:29  * Damn3djoined
22:03:29  * Damn3dquit (Changing host)
22:03:29  * Damn3djoined
22:07:56  * Damn3dquit (Ping timeout: 240 seconds)
22:10:49  <chrisdickinson>https://github.com/joyent/node/pull/7970 i'm at least 70% saddened by this solution, since it adds yet more state to readablestate.
22:13:04  <tjfontaine>we always hate that
22:13:12  <tjfontaine>I'll review it tonight
22:15:21  * bengljoined
22:15:30  * Damn3djoined
22:15:30  * Damn3dquit (Changing host)
22:15:30  * Damn3djoined
22:16:20  * petka_quit (Quit: Connection closed for inactivity)
22:16:43  <chrisdickinson>it's mostly there to see if it fixes the issues with the linked jenkins issues.
22:16:51  <tjfontaine>yup
22:17:27  <tjfontaine>oh man I hate jenkins
22:21:04  <tjfontaine>chrisdickinson: http://jenkins.nodejs.org/job/node-pullrequest/2206/ is running currently
22:22:34  * sh1mmerjoined
22:25:39  <tjfontaine>hm
22:25:53  <tjfontaine>oh same thing wrk
22:28:39  * rendarquit
22:34:51  <tjfontaine>chrisdickinson: http://jenkins.nodejs.org/job/node-pullrequest/DESTCPU=ia32,label=smartos/2206/tapTestReport/
22:35:30  <chrisdickinson>hm! looks like it fixed the -sync issue
22:43:22  <chrisdickinson>looks like the dns failure is present on master as well.
22:43:55  * a_lequit (Remote host closed the connection)
22:48:41  <tjfontaine>chrisdickinson: ya
23:19:20  * wolfeidauquit (Remote host closed the connection)
23:24:40  * AvianFluquit (Quit: Leaving)
23:25:47  * AvianFlujoined
23:44:15  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)