00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:22  <trevnorris>isaacs: i was wondering that. ripped it out and all tests pass.
00:01:03  * bnoordhuisquit (Ping timeout: 252 seconds)
00:05:33  * AvianFlujoined
00:18:02  * perezdjoined
00:18:52  <Raynos>https://gist.github.com/Raynos/5000773 <- Is that behaviour a bug?
00:20:24  <TooTallNate> /cc isaacs ^
00:20:54  <isaacs>trevnorris: fwiw, it seems like the net tests go slightly faster with it as a hidden property
00:20:59  <isaacs>not sure why that is
00:23:30  <trevnorris>isaacs: really? i wouldn't have expected that.
00:24:36  <Raynos>I think changing `needReadable` boolean to `readableBytesNeeded` number would allow push() to know whether we pushed over the number of bytes needed and can return false. This also allows us to remember that a large read(n) was made and that we need more bytes then the high water mark
00:31:51  <Raynos>I guess I should make a PR against node, not readable-stream
00:32:33  <TooTallNate>Raynos: yes indeed, readable-stream is just going to be backwards-compat for v0.8.x from now on
00:32:40  <TooTallNate>and just pulling changes from node-core that is
00:32:47  <Raynos>im gonna PR this against readable-stream for now and ill backport to core later
00:32:52  <Raynos>I need to ship the bug fixes today :D
00:34:17  <TooTallNate>Raynos: you mean you don't exclusively use v0.9.x yet? :p
00:34:34  <Raynos>I mean I prefer to bugfix npm modules then node core
00:34:37  <Raynos>easier
00:34:44  <Raynos>cause I can just fork and npm i Raynos/readable-stream
00:34:57  <TooTallNate>this is true
00:36:40  * mikealjoined
00:39:36  * karupaneruraquit (Excess Flood)
00:40:07  <trevnorris>isaacs: just ran tcp-raw benchmarks in 5 sets of 25 and the difference in values don't extend past the error band.
00:40:21  <isaacs>yeah
00:40:29  <isaacs>the diff is less than the jitter
00:42:35  * karupanerurajoined
00:50:54  * perezdquit (Quit: perezd)
00:53:12  * kazuponjoined
00:57:51  <Raynos>isaacs, TooTallNate: consider https://gist.github.com/Raynos/5001063
00:58:40  <Raynos>Which I think is the situation this comment mentions ( https://github.com/joyent/node/blob/master/lib/_stream_readable.js#L117 )
01:00:01  * kazuponquit (Remote host closed the connection)
01:04:11  * trevnorrisquit (Quit: Leaving)
01:07:07  * benoitcquit (Excess Flood)
01:11:04  * bradleymeck_joined
01:14:40  * benoitcjoined
01:14:48  * bradleymeckquit (Ping timeout: 276 seconds)
01:14:48  * bradleymeck_changed nick to bradleymeck
01:19:12  <Raynos>Ok, turned those into issues ( https://github.com/joyent/node/issues/4815 , https://github.com/joyent/node/issues/4814 )
01:22:45  * rvaggjoined
01:28:40  * ericktjoined
01:38:44  * abraxasjoined
02:01:00  * perezdjoined
02:01:19  * perezdquit (Client Quit)
02:10:29  * kazuponjoined
02:15:03  * kazuponquit (Ping timeout: 244 seconds)
02:17:42  * c4miloquit (Remote host closed the connection)
02:25:03  * dapquit (Quit: Leaving.)
02:41:34  * bradleymeckquit (Quit: bradleymeck)
02:43:11  * pooyaquit (Quit: pooya)
02:43:17  * benoitcquit (Excess Flood)
02:47:35  * AvianFlu_joined
02:48:01  * AvianFluquit (Ping timeout: 248 seconds)
02:48:06  * AvianFlu_changed nick to AvianFlu
02:48:10  * benoitcjoined
03:09:38  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:15:30  * abraxas_joined
03:15:43  * abraxasquit (Read error: No route to host)
03:43:42  * benoitcquit (Excess Flood)
03:51:10  * benoitcjoined
03:52:56  * kazuponjoined
04:05:21  * Raynosquit (Ping timeout: 248 seconds)
04:06:18  * brsonquit (Quit: leaving)
04:09:20  * abraxas_quit (Read error: No route to host)
04:09:41  * abraxasjoined
04:33:04  * trevnorrisjoined
04:37:00  * Raynosjoined
04:39:11  * benoitcquit (Excess Flood)
04:46:41  * benoitcjoined
04:50:35  <trevnorris>can someone help me understand the "now" test in test-debugger-repl?
04:54:06  * pooyajoined
04:55:23  * pooyaquit (Client Quit)
04:59:02  <trevnorris>nm, figured out how it works.
05:02:43  * pooyajoined
05:23:34  * mikealquit (Quit: Leaving.)
05:27:25  * mikealjoined
06:01:56  * pooyaquit (Quit: pooya)
06:17:26  * csaohjoined
06:21:10  * trevnorrisquit (Quit: Leaving)
06:22:32  * csaohquit (Quit: csaoh)
06:32:31  * pooyajoined
06:41:03  * TooTallNatejoined
06:41:21  * TooTallNatequit (Client Quit)
06:48:17  <Raynos>how much will break if we changed streams to only treat `null` as EOF and not `undefined` ?
06:54:36  * c4milojoined
06:55:35  * trevnorrisjoined
07:05:10  * abraxasquit (Remote host closed the connection)
07:17:25  * ericktquit (Quit: erickt)
07:19:24  * pooyaquit (Quit: pooya)
07:59:21  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
08:00:50  * bnoordhuisjoined
08:01:59  * c4miloquit (Remote host closed the connection)
08:03:06  * wolfeidaujoined
08:03:29  * rendarjoined
08:05:28  * stagasjoined
08:05:40  * sgallaghjoined
08:13:49  * loladiroquit (Quit: loladiro)
08:14:24  * loladirojoined
08:15:55  * loladiroquit (Client Quit)
08:26:43  * loladirojoined
08:29:41  * csaohjoined
08:30:38  * bnoordhuisquit (Ping timeout: 255 seconds)
08:35:50  * piscisaureus_joined
08:40:22  * kazupon_joined
08:43:33  * kazuponquit (Ping timeout: 252 seconds)
09:01:41  * `3rdEdenjoined
09:07:06  <csaoh>i keep getting "Assertion failed: (loop->watchers[w->fd] == w), function uv__io_stop, file src/unix/core.c, line 648.", when I try to use uv_poll_stop after i called uv_poll_init and uv_poll_start a couple of times… what could it mean ? I don't use the right parameters in uv_poll_stop ?
09:07:59  <saghul>csaoh are you using 2 poll handles for the same fd?
09:08:25  <csaoh>not as far as i know, but i'll doublecheck
09:09:34  <saghul>that would explain
09:15:32  * bnoordhuisjoined
09:16:22  <csaoh>weird, doesn't look like it's the case…
09:17:30  * piscisaureus_quit (Ping timeout: 264 seconds)
09:18:19  <saghul>csaoh you only call uv_poll_init one, right?
09:18:29  <csaoh>once for each fd
09:20:18  <saghul>csaoh what that assert means is that the watcher being stopped for that fd is not the one that was started
09:20:31  <saghul>that's why I asked if you use multiple poll handles for a given fd
09:20:42  <saghul>I have only seen that assert in such a case
09:20:50  <csaoh>alright… will look into it, thanks !
09:22:15  <csaoh>maybe i got them messed up on a lower level
09:22:46  * kazupon_quit (Remote host closed the connection)
09:31:17  <MI61>joyent/libuv: Ben Noordhuis master * 1d64c82 : unix: use uv__set_artificial_error in uv_write2 * Use uv__set_artificial (+2 more commits) - http://git.io/_zTROQ
09:34:31  * loladiroquit (Quit: loladiro)
10:04:23  * abraxasjoined
10:37:29  * sgallaghquit (Remote host closed the connection)
11:03:20  * sgallaghjoined
11:07:43  * abraxasquit (Remote host closed the connection)
11:11:54  * bnoordhuisquit (Ping timeout: 272 seconds)
11:18:37  * hzjoined
11:22:09  * trevnorrisquit (Quit: Leaving)
11:36:49  * csaohquit (Quit: csaoh)
11:39:28  * benoitcquit (Excess Flood)
11:42:42  * csaohjoined
11:45:44  * bsnotequit (Ping timeout: 252 seconds)
11:45:58  * bsnotejoined
11:49:16  * stagasquit (Ping timeout: 272 seconds)
11:49:45  * benoitcjoined
11:51:59  * brucemquit (Quit: ZNC - http://znc.sourceforge.net)
11:53:01  * KiNgMaRquit (Ping timeout: 264 seconds)
11:53:29  * brucemjoined
11:57:09  * KiNgMaRjoined
12:05:35  <txdv>wohever they find is unlikely to survive
12:07:00  * stagasjoined
12:10:23  <indutny>?
12:10:31  <indutny>morning
12:12:02  <txdv>morning
12:12:38  <txdv>indutny: is it raining metoers today in russia?
12:12:49  <indutny>no, its quite sunny
12:12:53  <indutny>in moscow
12:13:06  <txdv>it was sunny when that meteor fell down ...
12:13:25  <txdv>actually, in what city did it go down
12:18:31  * bnoordhuisjoined
12:21:49  <indutny>Chelyabinsk
12:23:03  * bnoordhuisquit (Ping timeout: 240 seconds)
12:24:31  <txdv>an entire europe away from lithuania
12:29:30  * hzquit (Disconnected by services)
12:29:33  * hzjoined
12:35:43  * wolfeidauquit (Remote host closed the connection)
12:49:26  * indexzeroquit (Quit: indexzero)
12:55:47  * benoitcquit (Excess Flood)
13:02:36  * KiNgMaRquit (Ping timeout: 264 seconds)
13:03:45  * benoitcjoined
13:07:49  * KiNgMaRjoined
13:11:21  * indexzerojoined
13:44:30  * benoitcquit (Ping timeout: 264 seconds)
13:57:46  * benoitcjoined
14:05:59  * stagasquit (Ping timeout: 260 seconds)
14:16:57  * stagasjoined
14:20:17  * stagas_joined
14:21:14  * c4milojoined
14:21:53  * stagasquit (Ping timeout: 248 seconds)
14:21:57  * stagas_changed nick to stagas
14:22:39  * c4miloquit (Remote host closed the connection)
14:24:43  * indexzeroquit (Quit: indexzero)
14:26:35  * stagasquit (Ping timeout: 255 seconds)
14:33:56  * stagasjoined
14:42:51  * stagasquit (Ping timeout: 260 seconds)
14:43:44  * qmx|awaychanged nick to qmx
14:54:40  <csaoh>i was wondering something.. let's say i want to bind both read and write events to a stream. Can i call uv_poll_init once and then call uv_poll_start twice, with different flags (WRITEABLE and READABLE) ? or should I use uv_poll_init twice ?
14:54:48  * c4milojoined
15:03:54  * ericktjoined
15:04:34  * benoitcquit (Excess Flood)
15:07:11  <csaoh>my guess is it i need to call uv_poll_init() once, and then uv_poll_start() twice, but I fail to get both of the callbacks of uv_poll_start to be called
15:07:48  * qmxchanged nick to qmx|away
15:08:16  * benoitcjoined
15:09:49  * stagasjoined
15:14:33  * stagasquit (Ping timeout: 240 seconds)
15:17:41  * stagasjoined
15:19:35  * loladirojoined
15:22:19  * stagas_joined
15:22:45  * stagasquit (Ping timeout: 276 seconds)
15:22:47  * stagas_changed nick to stagas
15:28:29  * stagas_joined
15:29:55  * stagasquit (Ping timeout: 260 seconds)
15:30:10  * stagas_changed nick to stagas
15:34:19  * mikealquit (Quit: Leaving.)
15:43:47  * loladiroquit (Quit: loladiro)
15:46:49  * bradleymeckjoined
15:47:35  * stagasquit (Ping timeout: 255 seconds)
15:47:40  * bnoordhuisjoined
15:48:03  * pooyajoined
15:49:36  * stagasjoined
15:50:08  * mikealjoined
15:52:39  <indutny>isaacs: call?
15:52:42  <indutny>bnoordhuis: ^
15:52:48  * stagas_joined
15:52:49  <indutny>in 8 minutes
15:54:42  * stagasquit (Ping timeout: 264 seconds)
15:54:43  * stagas_changed nick to stagas
15:54:56  * pooyaquit (Quit: pooya)
15:55:11  * mikealquit (Quit: Leaving.)
15:57:20  <isaacs>yes, call
15:57:22  <isaacs>one sec
16:03:49  * stagas_joined
16:05:37  * stagas__joined
16:05:46  * mikealjoined
16:06:48  * stagas__quit (Client Quit)
16:06:50  * stagasquit (Ping timeout: 255 seconds)
16:07:16  * benoitcquit (Excess Flood)
16:09:03  * stagas_quit (Ping timeout: 252 seconds)
16:10:36  * loladirojoined
16:11:17  * benoitcjoined
16:12:46  * ericktquit (Quit: erickt)
16:21:39  * mikealquit (Quit: Leaving.)
16:26:04  * loladiroquit (Quit: loladiro)
16:26:39  * bradleymeck_joined
16:27:39  * bradleymeckquit (Read error: Connection reset by peer)
16:27:40  * bradleymeck_changed nick to bradleymeck
16:32:25  * `3rdEdenchanged nick to `3E|AFK
16:35:39  * mikealjoined
16:39:03  * AvianFluquit (Ping timeout: 260 seconds)
16:42:20  * AvianFlujoined
16:42:59  <isaacs>Raynos: I'm going to remove lowWaterMarks from streams entirely.
16:43:05  <isaacs>Raynos: i don't think you ever want that to not be zero anyway
16:43:10  <isaacs>and it will remove a lot of checking
16:45:29  * mikealquit (Quit: Leaving.)
16:47:11  <CoverSlide>if it simplifies streams2 i'm all for it
16:54:09  * `3E|AFKquit (Remote host closed the connection)
16:55:37  * `3E|AFKjoined
16:56:53  * dapjoined
16:57:49  * `3E|AFKquit (Read error: Operation timed out)
16:58:30  * AvianFlu_joined
16:58:46  * AvianFluquit (Disconnected by services)
16:58:50  * AvianFlu_changed nick to AvianFlu
16:58:57  * benoitcquit (Excess Flood)
17:02:16  * benoitcjoined
17:07:21  * bnoordhuisquit (Ping timeout: 252 seconds)
17:10:33  * AvianFlu_joined
17:10:57  * AvianFluquit (Disconnected by services)
17:11:00  * AvianFlu_changed nick to AvianFlu
17:22:43  * CoverSlide&
17:24:28  * mikealjoined
17:39:48  * bradleymeckquit (Ping timeout: 252 seconds)
17:42:48  * hzquit (Ping timeout: 264 seconds)
17:46:17  * AvianFluquit (Read error: Connection reset by peer)
17:46:44  * AvianFlujoined
17:47:39  * hzjoined
17:51:07  * trevnorrisjoined
17:56:17  * EhevuTovjoined
17:56:34  <tjfontaine>I wonder if it would be easier to make the test runner reap left children
17:58:00  * TheJHjoined
18:05:43  * sgallaghquit (Remote host closed the connection)
18:10:06  * loladirojoined
18:10:08  * pooyajoined
18:13:43  * bnoordhuisjoined
18:14:48  <tjfontaine>bnoordhuis: welcome
18:16:34  * perezdjoined
18:16:47  <indutny>wilcomen
18:17:01  <indutny>willkommen
18:18:19  * bnoordhuisquit (Ping timeout: 246 seconds)
18:18:51  * EhevuTovquit (Quit: This computer has gone to sleep)
18:21:13  * TooTallNatejoined
18:22:16  <TooTallNate>trevnorris: so i guess i'll land your patch
18:22:23  <TooTallNate>trevnorris: any chance of a test case though?
18:22:34  <trevnorris>TooTallNate: was just about to ask you for help.
18:22:48  <TooTallNate>well i'll do what i can
18:22:49  <trevnorris>TooTallNate: haven't been able to figure out what mocha is doing to cause that.
18:23:00  <TooTallNate>trevnorris: it's not just mocha though
18:23:12  <trevnorris>well. i mean your code.
18:23:21  <TooTallNate>trevnorris: that standalone gist i gave you doesn't fire the "finish" event
18:23:59  <TooTallNate>https://gist.github.com/TooTallNate/ad7ce486dc328d8f32b7
18:25:05  <trevnorris>TooTallNate: yeah. was trying to figure out how use that w/o the Decoder required.
18:25:21  <TooTallNate>well ya of course :p
18:25:32  <TooTallNate>it's strange...
18:25:45  <TooTallNate>idk what i'd be doing that would cause it to get into that state
18:25:55  <trevnorris>i'm confused how none of the existing tests caught this case.
18:26:04  <TooTallNate>as am i
18:27:04  <trevnorris>well, luckily it was easy to figure out. just noticed the program was exiting w/o continuing execution of the event queue.
18:28:01  <TooTallNate>trevnorris: it seems like that if branch you added in that patch gets executed quite a few times
18:28:07  <TooTallNate>is that expected?
18:30:38  <trevnorris>yeah. bunch of unecessary calls to the spinner. think i may have a better patch for that. one sec.
18:31:35  <MI61>joyent/node: Trevor Norris master * 7301ba3 : process: fix bug where spinner wasn't called Apperently there is a case - http://git.io/4QxrtA
18:32:02  <trevnorris>bugger... dude, there's a better one.
18:32:22  <TooTallNate>trevnorris: it was isaacs
18:32:42  <TooTallNate>trevnorris: we can revert that one
18:32:54  <TooTallNate>when we have a better one :)
18:34:27  <indutny>isaacs: https://github.com/joyent/node/pull/4826
18:34:56  * loladiroquit (Quit: loladiro)
18:37:06  * loladirojoined
18:37:26  * `3E|AFKjoined
18:37:58  <TooTallNate>ughh this is really messed
18:38:10  <trevnorris>TooTallNate: what?
18:38:15  <indutny>readStart?
18:38:24  <TooTallNate>i'm just upset i can't figure out how to test this
18:38:24  <TooTallNate>haha
18:38:36  <indutny>we've a lot of things messed
18:38:40  <indutny>so please be more specific
18:38:42  <TooTallNate>trevnorris: happy everything works though :)
18:39:04  <TooTallNate>indutny: it would have been nice to get a test case for https://github.com/joyent/node/commit/7301ba396915a54e1db9a2673a467639ff6cd0b1
18:39:19  <indutny>heh
18:39:20  <indutny>yes
18:39:22  <indutny>I guess so
18:39:23  <TooTallNate>indutny: but we can't seem to figure out how to isolate the behavior
18:43:16  * Guest____joined
18:43:21  * Guest____quit (Max SendQ exceeded)
18:44:00  <trevnorris>TooTallNate: i don't understand how it's possible. all callbacks added to the queue must have come though makeCallback, which would have detected there are more callbacks
18:44:37  <TooTallNate>trevnorris: well.. what if an addon isn't using MakeCallback()?
18:45:10  <TooTallNate>trevnorris: … this could be an error on my part is what i'm saying
18:45:14  <trevnorris>TooTallNate: the event queue is only accessible to makecallback and nextTick
18:45:56  <TooTallNate>trevnorris: i'm not using MakeCallback here https://github.com/TooTallNate/node-ogg/blob/master/src/binding.cc#L337
18:45:59  * `3rdEdenjoined
18:46:12  <TooTallNate>or anywhere for that matter, hahah
18:47:37  <isaacs>trevnorris: orly?
18:47:47  * csaohquit (Quit: csaoh)
18:48:02  <indutny>isaacs: ping pong
18:48:03  <isaacs>trevnorris: yeah, if there's a better approach, we can just clobber this one and land that.
18:48:06  <isaacs>it's cool
18:48:07  <indutny>isaacs: https://github.com/joyent/node/pull/4826/files
18:48:18  <trevnorris>somehow a callback is being left in the event queue. give me some time to figure out why.
18:49:11  <isaacs>indutny: hm. and this works?
18:49:17  <indutny>you can test it ;)
18:49:19  <isaacs>indutny: i mean, it's not the ugliest thing ever.
18:49:23  <indutny>well
18:49:26  <indutny>it works
18:51:25  * brsonjoined
18:51:51  <isaacs>running tests now
18:52:18  <isaacs>lowWaterMark is almsot all gone.
18:52:31  <isaacs>some tests failing, but they're all just tests of lowWaterMark in stream2 tests :)
18:53:54  <isaacs>i'm going to set fire to the debugger tests.
18:54:04  <isaacs>and by "set fire to" i mean "rewrite"
18:54:10  <isaacs>but ragefully
18:54:12  <isaacs>:0
18:57:36  * bradleymeckjoined
19:00:30  * TheJHquit (Ping timeout: 276 seconds)
19:03:40  <TooTallNate>trevnorris: this doesn't seem to repro it :\ https://github.com/TooTallNate/node/commit/68a8b2709e7cbb6a4c42658837f63087df2e923b
19:05:05  <trevnorris>TooTallNate: i'm leaning towards a race condition. the final callback in the queue is afterPacketout, but that thing's been called more than a dozen times already.
19:06:12  <TooTallNate>lovely :p
19:06:26  <trevnorris>TooTallNate: the only place I see afterPacketout run is when it's passed to ogg_stream_packetout.
19:06:43  <TooTallNate>sounds about right
19:06:54  <TooTallNate>and that's an async native function
19:07:45  <trevnorris>TooTallNate: but that's pretty much what you simulated in the test, right?
19:08:01  <TooTallNate>ya
19:08:08  <TooTallNate>but maybe you need to do it 10 times?
19:08:12  <TooTallNate>who knows
19:08:25  <trevnorris>can you try that? just run it a bunch.
19:14:22  <indutny>isaacs: so, lgty?
19:15:42  <TooTallNate>trevnorris: can't seem to repro still :(
19:20:53  <isaacs>indutny: yeah, sure.
19:20:55  <isaacs>tests pass
19:21:03  <isaacs>cleared for landing
19:23:29  <trevnorris>TooTallNate: is uv_queue_work supposed to call req->callback when complete?
19:24:21  * mikealquit (Quit: Leaving.)
19:24:56  <TooTallNate>trevnorris: no i don't think so, you're supposed to implement the callback manually
19:24:59  <tjfontaine>hrm no ben
19:25:28  <trevnorris>TooTallNate: then what is running the callback passed to node_ogg_stream_packetout?
19:26:33  <trevnorris>TooTallNate: nm. see it.
19:26:35  <TooTallNate>trevnorris: i invoke it manually https://github.com/TooTallNate/node-ogg/blob/master/src/binding.cc#L243
19:27:47  * mikealjoined
19:29:29  <MI61>joyent/node: Fedor Indutny master * ebc95f0 : tls: _handle.readStart/readStop for CryptoStream lib/http.js is using st - http://git.io/_muhaQ
19:30:12  <indutny>isaacs: thanks
19:31:27  * TheJHjoined
19:32:10  * EhevuTovjoined
19:32:34  * loladiroquit (Quit: loladiro)
19:33:44  * mikealquit (Quit: Leaving.)
19:37:53  <trevnorris>TooTallNate: it's a race condition for sure. the spinner is returning before the next callback has been pushed to the queue.
19:38:04  <trevnorris>but when I manually slow down nextTick then it runs fine.
19:41:44  <TooTallNate>trevnorris: but doesn't my callback *not* go through the queue at all? i'm just invoking it on the JS thread directly
19:41:49  * TheJHquit (Ping timeout: 244 seconds)
19:41:53  <trevnorris>TooTallNate: what is afterPageout?
19:41:55  <TooTallNate>trevnorris: i feel like not calling MakeCallback is causing the race
19:42:17  <TooTallNate>trevnorris: the callback function for when ogg_stream_pageout() is finished?
19:44:41  <trevnorris>TooTallNate: afterPacketout is being called by the emitter, which is pushing the callback to the tick queue.
19:45:35  <TooTallNate>trevnorris: by which emitter?
19:45:53  <TooTallNate>afterPageout is only referenced 3 times in the code
19:46:04  <TooTallNate>only interacting with the native function though
19:47:12  <trevnorris>TooTallNate: i setup a trace in nextTick to look for callbacks with the name afterPacketout. this is what it looks like: https://gist.github.com/trevnorris/5007546
19:48:25  <trevnorris>TooTallNate: i'm pretty sure these are coming in from DecoderStream.prototype._read
19:49:00  <TooTallNate>i mean that's pretty weird to me
19:49:16  <TooTallNate>afterPageout() should only be invoked directly on the JS stack
19:49:21  <TooTallNate>at the beginning that is
19:51:02  <MI61>joyent/node: Arianit Uka master * 055110d : path: join throws TypeError on non-string args lib/path.js: - throws a - http://git.io/WNBdJA
19:51:21  <TooTallNate>trevnorris: idk where you're getting that from
19:51:44  <trevnorris>TooTallNate: lib/decoder-stream.js
19:51:59  <TooTallNate>trevnorris: are you using master branch or an npm checkout?
19:52:30  <trevnorris>TooTallNate: https://github.com/TooTallNate/node-ogg/blob/master/lib/decoder-stream.js#L168
19:52:56  <TooTallNate>ya i see
19:53:03  <Raynos>isaacs: lowWaterMark is useful for pull streams
19:53:23  <Raynos>isaacs: https://github.com/Raynos/read-stream#example-pull-model
19:54:00  <Raynos>a pull stream fills up to the lowWaterMark because when `push()` && length < lowWaterMark then `_read()`
19:54:02  <TooTallNate>trevnorris: oh, you said afterPageout()
19:54:13  <TooTallNate>trevnorris: but your gist is afterPacketout()
19:54:54  <trevnorris>TooTallNate: yeah. basically it's: if (callback.name === 'afterPacketout') console.trace('afterPacketout from nextTick');
19:55:17  <TooTallNate>trevnorris: sure but what function are we actually talking about here?
19:55:19  <trevnorris>just popped that in the first line of nextTick()
19:55:27  <TooTallNate>i think you mean afterPageout()
19:56:19  <trevnorris>TooTallNate: i'm checking for when you pass afterPacketout() to nextTick.
19:56:39  <trevnorris>TooTallNate: was asking about afterPageout because it was showing up in the trace.
19:56:42  <TooTallNate>trevnorris: but who cares about that function?
19:57:11  <trevnorris>TooTallNate: because when the program exits that is the function left in the queue that hasn't been executed.
19:57:24  * TheJHjoined
19:57:57  <trevnorris>process.on('exit', function() { console.error(nextTickQueue[0]); })
19:57:59  <isaacs>Raynos: no, push() only returns false when you hit the high water mark
19:58:25  <Raynos>isaacs: I think it's nice that calling onread() and having length < lwm pre-emptively calls _read again
19:58:30  <Raynos>even if the consumer hasn't called read()
19:58:39  * `3E|AFKchanged nick to `3E
19:58:46  <TooTallNate>trevnorris: ok good to know
19:59:01  <isaacs>Raynos: right... but.. when do you actually want to call _read *instead* of emitting readable?
19:59:14  <Raynos>well if the buffer has one object in it
19:59:19  <Raynos>I want to call _read again
19:59:26  <Raynos>But I also want to emit "readable"
19:59:40  <Raynos>I think calling _read if onread() -> length < hwm is not a bad idea
19:59:49  * AvianFluquit (Ping timeout: 246 seconds)
19:59:56  <Raynos>that way the stream is always pre-emptively upto the high water mark
20:00:12  <TooTallNate>trevnorris: where is nextTickQueue?
20:00:32  <trevnorris>TooTallNate: src/node.js around line 450
20:00:35  <isaacs>Raynos: so, here's a problem:
20:00:36  * AvianFlujoined
20:00:37  <Raynos>but I guess emitting readable is the same thing if you read in a tight loop
20:00:41  <isaacs>Raynos: we emit 'readable'
20:00:46  <isaacs>Raynos: in which point, you call read() again
20:00:56  <isaacs>Raynos: and that triggers _read() again
20:00:57  <Raynos>which triggers _read because its less then hwm
20:01:05  <isaacs>Raynos: but then we call _read *yet again* after emitting?
20:01:09  <TooTallNate>trevnorris: ahh, it's gidden
20:01:11  <TooTallNate>hidden
20:01:32  <isaacs>Raynos: i guess we can do it if we check for state.reading after emitting readable
20:01:35  * wolfeidaujoined
20:01:47  <isaacs>Raynos: so, if !reading, and length < hwm, call _read() again
20:01:57  <isaacs>Raynos: after emitting readable
20:02:08  <Raynos>i guess o
20:02:09  * `3rdEdenquit (Ping timeout: 248 seconds)
20:02:11  <Raynos>im not sure though
20:03:23  <Raynos>isaacs: btw https://github.com/Raynos/readable-stream/commit/26f4b4635c099f404bad5d5cd1838b9b49ce8ec3
20:03:38  * TheJHquit (Ping timeout: 255 seconds)
20:04:08  * TheJHjoined
20:09:53  <isaacs>Raynos: hm...
20:10:05  <isaacs>Raynos: so, what happens if you need a readable event there?
20:11:28  <isaacs>oh, wait, i think i see..
20:11:39  <Raynos>I remove the rs.needReadable check. Hopefully that doesn't break anything
20:12:00  <isaacs>Raynos: so, the issue is that onread emits readable on nextTick, because sync
20:12:06  <isaacs>Raynos: valid bug. wrong fix.
20:12:07  * AvianFluquit (Read error: Connection reset by peer)
20:12:11  <isaacs>good catch, though
20:12:35  * AvianFlujoined
20:14:46  <isaacs>Raynos: does this fix your issue? https://gist.github.com/5007815
20:15:49  <Raynos>isaacs: interesting, it may do
20:16:25  <isaacs>Raynos: also, that preemptively rads.
20:16:26  <isaacs>*reads
20:16:29  <isaacs>which is rad :)
20:16:30  <Raynos>also I wanted to make `undefined` the same as `""` in buffer mode. i.e. there is no data now but this is not EOF, EOF is null. https://github.com/joyent/node/issues/4819
20:17:10  <Raynos>isaacs: I like the read(0) thing
20:17:13  <Raynos>that's a nice touch
20:17:41  <Raynos>of course this means that all streams will now fill up to the highWaterMark on read(0)
20:17:54  <Raynos>which i dont know whether that's good for memory usage.
20:18:12  <trevnorris>TooTallNate: how for the love of are you calling nextTick after the final spinner has returned? that shouldn't be possible.
20:19:00  <isaacs>Raynos: i'm ok with saying that it must === null to be EOF, i guess
20:19:47  <Raynos>im on the fence, it's useful but can go in userland if needed
20:21:03  * AvianFlu_joined
20:21:11  * AvianFluquit (Ping timeout: 260 seconds)
20:22:40  <isaacs>Raynos: i think if you want this to not fill up, use a lower hwm
20:22:57  <isaacs>Raynos: you can set hwm=0 for "no preemptive anything ever"
20:23:03  <Raynos>well hwm is for two things
20:23:06  <isaacs>but already, reading even 1 byte will make it do another read if it's < hwm
20:23:11  <Raynos>its for "how much should it preemptively fill"
20:23:22  <Raynos>and for "if you add stuff, when does it say NO I AM FULL"
20:23:30  <isaacs>i think those are really the same things
20:23:35  <Raynos>the latter is useful for push sources
20:23:41  <isaacs>"adding stuff" is how preemptive filling works
20:23:43  <Raynos>where as the latter doesnt matter for pull sources
20:23:45  <isaacs>they should be the same.
20:23:59  <isaacs>sure
20:24:13  <Raynos>i dont know whether they are the same, i'm ok with them being the same
20:24:19  <isaacs>but even "pull sources" (ie, fs reads, for example) can be thought of as a push() that we call in the future
20:24:44  <isaacs>we just call that a "callback" rather than a "push later"
20:25:16  * EhevuTovquit (Quit: This computer has gone to sleep)
20:25:31  <trevnorris>TooTallNate: ok, so there are two overlapping async events and it's a race between the spinner and the _packet being fired by afterPacketout.
20:25:42  * EhevuTovjoined
20:25:59  <trevnorris>TooTallNate: if the spinner wins then no more callbacks in the queue will be called.
20:26:01  <trevnorris>isaacs: ^
20:26:05  * AvianFlu_changed nick to AvianFlu
20:26:41  <isaacs>trevnorris: huh?
20:26:49  <isaacs>what is _packet and afterPacketout?
20:27:30  <isaacs>can someone review this pretty plz? https://github.com/isaacs/node/compare/path-resolve-nonstring-typeerror
20:27:31  <trevnorris>isaacs: so node-ogg has a cc level async event that when returns fires a callback that shoves a method to nextTick. but if the final spinner has fired then it won't be picked up.
20:27:42  <isaacs>oic
20:27:51  <isaacs>is node-ogg using node::MakeCallback to call its cb?
20:28:19  <isaacs>TooTallNate: ^?
20:28:24  <trevnorris>isaacs: nope. it's calling the callback directly which then emits an event which then calls nextTick.
20:28:31  <isaacs>ok, well, that's not going to work
20:28:33  <trevnorris>so _tickCallback won't be run.
20:28:34  <isaacs>use node::MakeCallback
20:29:05  <isaacs>i guess that's kind of a gfy answer, though, huh?
20:29:12  <isaacs>should probably make that work...
20:29:14  * AvianFluquit (Remote host closed the connection)
20:29:39  * EhevuTov_joined
20:29:52  * AvianFlujoined
20:29:55  <trevnorris>isaacs: well, calling the spinner after it's returned in every nextTick works, but it's ugly.
20:30:11  <trevnorris>isaacs: and if we're dropping the spinner in v0.11 then we'll need another solution. (you said that right?)
20:30:19  <isaacs>yeah..
20:30:26  <isaacs>but, i'm not sure the best approach
20:30:37  * EhevuTovquit (Ping timeout: 246 seconds)
20:30:43  <isaacs>since you can jump from C++ to JS without going through our prescribed hoops
20:30:59  <isaacs>and basically, nextTick only works if you go through node::MakeCallbac
20:31:07  * AvianFlu_joined
20:31:28  <trevnorris>it works if the function called from tickDepth === 0 was called by MakeCallback.
20:31:30  <Raynos>isaacs: I think of callbacks as pull streams ( https://github.com/Raynos/read-stream#example-callback ). i.e. pull once in the future and you get it. but I guess pull -> push later
20:31:31  * AvianFluquit (Disconnected by services)
20:31:33  * AvianFlu_changed nick to AvianFlu
20:38:48  * mikealjoined
20:39:25  <trevnorris>isaacs: lgtm
20:39:39  * bradleymeckquit (Quit: bradleymeck)
20:42:06  <trevnorris>isaacs: re spinner: w/o being able to enforce control of async events from cc land then we'll have to leave the spinner check in nextTick.
20:44:30  <isaacs>trevnorris: yeah, it's not so bad, i think
20:44:33  <isaacs>ugly, sure, but whatever.
20:47:25  * mikealquit (Ping timeout: 246 seconds)
20:47:49  * bradleymeckjoined
20:49:57  * wolfeidauquit (Remote host closed the connection)
20:50:15  <trevnorris>isaacs: yeah. and unless we want to enforce callbacks from cc then there'll be no way around it.
20:51:44  <TooTallNate>trevnorris: ok well so your patch is good then?
20:52:05  <TooTallNate>trevnorris: in any case, were you able to make a repro test?
20:52:09  <TooTallNate>should be possible now
20:52:34  <trevnorris>TooTallNate: yeah, it's the only way to do it. when callback can be run after an async event in cc land then nextTick needs to be checked.
20:52:47  <TooTallNate>yup
20:53:42  <trevnorris>TooTallNate: what was your branch with that test?
20:53:54  <TooTallNate>trevnorris: "add/async-hello-world"
20:53:56  <TooTallNate>on my fork
20:54:51  <trevnorris>ahh. i was trying to check out w/o the add/
20:56:02  <TooTallNate>trevnorris: so this repro's it https://github.com/TooTallNate/node/compare/add;async-hello-world
20:56:32  <trevnorris>TooTallNate: yeah, i've got you added in my remote. =)
20:56:51  <TooTallNate>isaacs: any objections to pushing that to master? ^
20:57:26  <trevnorris>TooTallNate: does that check properly? give me a set to try it out.
20:57:38  <TooTallNate>trevnorris: good work narrowing it down btw
20:57:49  <TooTallNate>trevnorris: ya the test.js should fail on v0.9.10 but works on master with your patch
20:58:09  <isaacs>TooTallNate: if it passes on master, but fails before trevor's patch, absolutely
20:58:26  <TooTallNate>isaacs: cool, that is indeed the case
20:58:33  <trevnorris>TooTallNate: wait.
20:58:48  <trevnorris>TooTallNate: i checked out bbcb8b3 built and ran the test. passes.
20:58:53  <trevnorris>am i missing something?
20:59:32  * `3Equit (Quit: becuz)
20:59:55  <TooTallNate>trevnorris: fails for me
21:00:00  <TooTallNate>trevnorris: sure you rebuilt?
21:00:17  <trevnorris>trying it again. also remember this is a race condition, so i might not be able to reproduce.
21:00:26  * `3rdEdenjoined
21:01:45  <TooTallNate>v0.9.10 tag definitely fails as well
21:02:14  <trevnorris>i'll try v0.9.10 then. mind trying at commit bbcb8b3?
21:04:46  <TooTallNate>trevnorris: https://gist.github.com/TooTallNate/898bc576135e82cdaa53
21:04:51  <TooTallNate>that's bbcb8b3
21:04:52  <TooTallNate>failing
21:10:02  <trevnorris>TooTallNate: am I doing something wrong here? https://gist.github.com/trevnorris/5008273
21:11:20  <TooTallNate>trevnorris: i think you need to pull
21:11:23  * loladirojoined
21:11:34  <trevnorris>...
21:11:40  <TooTallNate>trevnorris: you want the commit "test: modify async native test.js to test for #4820"
21:11:54  <TooTallNate>wow, "test" 3 times in one commit message
21:12:16  <trevnorris>yup... fails. sorry bout that.
21:12:16  * TooTallNateslaps writs
21:12:22  * loladiroquit (Client Quit)
21:12:32  <TooTallNate>k well i'm gonna push to master then
21:12:36  <TooTallNate>trevnorris: any objections?
21:12:43  <trevnorris>nope. good test
21:13:03  <TooTallNate>depends on async which is unfortunate but at least we're not requiring MakeCallback()
21:13:37  <TooTallNate>err, not async, but native compilation
21:14:04  <trevnorris>yeah. and the additional overhead of calling the spinner should be minimal since it's only called when the spinner isn't already out.
21:14:33  <MI61>joyent/node: Nathan Rajlich master * 50c88e0 : test: modify async native test.js to test for #4820 (+1 more commits) - http://git.io/ZrIbuA
21:14:42  <TooTallNate>trevnorris: so is there a more optimal patch like you were talking about or no?
21:15:29  <trevnorris>TooTallNate: thought there was, but not now.
21:15:36  <TooTallNate>ok cool
21:15:50  <trevnorris>unless we can somehow cheaply detect when a js callback is called from cc land, then there's nothing else to be done.
21:15:50  <TooTallNate>crisis resolved as far as i'm concerned :)
21:15:57  <TooTallNate>trevnorris: thanks a lot for looking into it
21:16:10  <trevnorris>TooTallNate: hey, I defined my work. ;-)
21:16:33  <TooTallNate>trevnorris: at this point you probably have a better handle on a lot of the low-level internals than most
21:17:14  <trevnorris>TooTallNate: heh, thanks.it's where I like to spend my time.
21:17:44  * loladirojoined
21:18:55  <trevnorris>i'm working on optimizing EvenEmitter now. the context switching drives me nuts.
21:23:07  <trevnorris>TooTallNate: though I have very little grasp on uv internals. especially the intricacies of uv_run.
21:23:31  <TooTallNate>trevnorris: well even less people know those internals
21:23:39  <TooTallNate>trevnorris: you could probably count them on one hand :P
21:25:45  <trevnorris>TooTallNate: lol. well luckily the code is so clean so it makes life easier.
21:29:02  <trevnorris>ugh. needing to use .call() and .apply() in code as hot as .emit() makes me hurt. just can't see a way around it yet.
21:29:19  * brsonquit (Ping timeout: 260 seconds)
21:29:33  <TooTallNate>trevnorris: unless the callback are set directly on the emitter object, there's not really a way around it
21:29:49  <TooTallNate>trevnorris: and even then, the variable number of args makes it hard still
21:30:25  * brsonjoined
21:30:34  <trevnorris>TooTallNate: well, at least we can optimize it for internal usage. that's part of what I did for the ticker.
21:31:25  <trevnorris>and then use .apply() for userland stuff.
21:32:23  <trevnorris>the one that really gets me is the use of double apply()'s for .once(). that is used all over core.
21:33:11  <indutny>ttyl guys
21:33:13  * indutny&
21:34:17  * CoverSlide&
21:36:06  * loladiroquit (Quit: loladiro)
21:37:01  * bnoordhuisjoined
21:39:19  * mikealjoined
21:39:24  * brsonquit (Ping timeout: 276 seconds)
21:41:04  <tjfontaine>bnoordhuis: how acceptable/unacceptable is that libuv tap change?
21:43:02  <bnoordhuis>tjfontaine: what libuv tap change? (still catching up on my email)
21:43:02  * loladirojoined
21:43:38  <tjfontaine>bnoordhuis: https://github.com/joyent/libuv/pull/717
21:43:53  * mikealquit (Ping timeout: 255 seconds)
21:44:27  * TheJHquit (Read error: Operation timed out)
21:46:44  <bnoordhuis>tjfontaine: looks reasonably acceptable
21:48:24  <tjfontaine>ok, I'm not entirely sure what the right way to trigger it on windows
21:50:50  <bnoordhuis>tjfontaine: maybe a command line switch?
21:51:16  * txdvquit (Ping timeout: 245 seconds)
21:51:54  <tjfontaine>bnoordhuis: well, I would have done a command line switch outright, except the way the runner does (or doesn't do) argument parsing, so things are fairly positional
21:57:02  * bradleymeckquit (Quit: bradleymeck)
21:59:39  <isaacs>hm.. v8 3.16 is looking pretty enticing
22:01:00  <trevnorris>isaacs: +1
22:01:24  * mikealjoined
22:06:11  <Raynos>isaacs: thanks for making streams2 nicer :)
22:17:16  * qmx|awayquit (Excess Flood)
22:18:49  * rendarquit
22:18:50  * qmxjoined
22:24:34  <isaacs>Raynos: so, that patch i gave you is not so great.
22:24:48  <isaacs>Raynos: found a bug with it
22:24:57  <isaacs>Raynos: but.... here's kind of a weird edge case..
22:25:10  <isaacs>Raynos: so, you are, let's say, in the _read function
22:25:20  <isaacs>Raynos: and you do var ret = this.push(someBigThing)
22:25:32  <isaacs>Raynos: synchronously
22:25:41  <Raynos>yes
22:25:44  <Raynos>oh
22:25:45  <isaacs>Raynos: it returns false.
22:25:47  <Raynos>infinite loop
22:25:50  <isaacs>Raynos: nono, not that
22:25:51  <Raynos>yes
22:26:03  <isaacs>however, the read() call was going to pull in as much as you give it
22:26:22  <isaacs>so you're not actually over the hwm, because it'll just return it all now anyway
22:26:31  <Raynos>oh wait
22:26:36  <isaacs>as it re-evaluates the return size on read(<noargs>)
22:26:38  <Raynos>read() calls _read synchronously
22:26:40  <isaacs>right
22:26:45  <Raynos>and then returns whats in the buffer
22:26:47  * brsonjoined
22:26:57  <isaacs>and in this case, _read calls its cb (in the form of push(bigThing) also sync)
22:27:07  <isaacs>read() is smart enough to know that _read was sync
22:27:09  * brsonquit (Client Quit)
22:27:12  <isaacs>so it re-evaluates the amount to return
22:27:22  * brsonjoined
22:27:23  <isaacs>so... in this case, the "false" return from push() is a bit misleading.
22:27:28  <isaacs>because you actually CAN take more data right now
22:27:34  <Raynos>we used to fix this with `return rs.needReable or length < hwm`
22:27:35  <isaacs>but i guess it'll just call _read anyway.
22:27:45  <isaacs>no, we used to just not fix this :0
22:27:51  <Raynos>the only downside
22:27:54  <Raynos>is for push sources
22:27:59  <Raynos>where you unnecessary pause / resume it
22:28:03  <Raynos>and pause / resume is expensive
22:28:09  <Raynos>you should just fix this with bigger watermarks :P
22:28:19  <Raynos>in fact if you push in a single chunk thats large then your hwm then thats silly
22:29:27  <MI61>joyent/libuv: Ben Noordhuis v0.8 * 86ae8b3 : unix: handle EINPROGRESS for unix sockets Before this commit, it was ass (+1 more commits) - http://git.io/Vd1OIg
22:29:30  <MI61>joyent/libuv: Ben Noordhuis master * 3348cd7 : unix: handle EINPROGRESS for unix sockets Before this commit, it was ass - http://git.io/JSj4vA
22:31:07  <trevnorris>bnoordhuis: it was ass?
22:32:01  <isaacs>trevnorris: yep.
22:32:02  <isaacs>basically
22:32:07  <trevnorris>lol
22:32:37  * loladiroquit (Quit: loladiro)
22:32:45  <isaacs>Raynos: https://github.com/isaacs/node/commit/89148d4b68c06a86945b84a1529d0d1806f4f695
22:32:50  * bradleymeckjoined
22:32:54  <isaacs>TooTallNate: can you review this? https://github.com/joyent/node/pull/4828
22:33:22  <isaacs>TooTallNate: i think you're probably the core committer with the most streams2 usage experience, after me.
22:33:41  <isaacs>though indutny is probably also up there, after crypto streams :)
22:33:59  <TooTallNate>isaacs: ya probably :) and ya lwm has always seemed a little weird to me
22:34:02  <TooTallNate>semantically
22:34:07  <isaacs>yeah
22:37:55  <bnoordhuis>trevnorris: sorry?
22:38:02  <bnoordhuis>oh
22:38:05  <isaacs>bnoordhuis: referring to the MI61 post
22:38:14  <isaacs>tjfontaine: is that a new MI61 ?
22:38:17  <isaacs>tjfontaine: it's got a 1 on it
22:38:42  <tjfontaine>heh, because tcp is hard and when it got reconnected to freenode the ghost was still there :)
22:38:59  * MI61quit (Remote host closed the connection)
22:39:09  * MI6joined
22:42:33  <isaacs>heh
22:43:56  <isaacs>Raynos: "At 2013-02-21T01:57:09.553Z, in #Node.js, Raynos said: You should probably bitch at people about Writable not being correct. I wouldnt be suprised if its full of bugs
22:43:59  <isaacs>Raynos: ?
22:44:04  <isaacs>Raynos: writable is not correct?
22:44:28  <Raynos>i was grumpy last night
22:44:35  <Raynos>I havn't abstracted, used or debugged Writable
22:45:00  <Raynos>Given the complexity of objectMode Readable I just assume there are unhandled edge cases in objectMode Writable
22:45:20  <isaacs>oh, maybe
22:45:23  <isaacs>it's WAY simpler, though, actually
22:45:27  <isaacs>and also not very new.
22:45:53  <TooTallNate>seems to be working for me
22:45:55  <isaacs>as for the object mode-ness of it, i dunno
22:45:58  <TooTallNate>even objectMode :)
22:46:00  <isaacs>maybe broken, don't really care :)
22:46:24  <TooTallNate>oh actually i'm using Transform objectMode
22:46:40  <TooTallNate>but where the writable end is normal and the readable side outputs objects
22:46:51  * TooTallNatestill needs to make a patch for that API
22:47:44  <isaacs>bnoordhuis: review? https://github.com/isaacs/node/compare/path-resolve-nonstring-typeerror
22:51:25  <TooTallNate>isaacs: this seems unnecessary to me but i'm probably missing something https://github.com/joyent/node/commit/6bd450155c36f9e3dbaa8e4d6261e5e447af0a9a#commitcomment-2669147
22:52:10  <TooTallNate>isaacs: why wouln't you just begin reading again if there's nothing to return? and not invoke the callback
22:53:03  <isaacs>TooTallNate: read through lib/tls.js, starting on line 384
22:53:08  * benoitcquit (Excess Flood)
22:53:48  <isaacs>TooTallNate: if we're resuming the session, or if there was just no bytes to read from openssl, we return '' so that we can signal that we're done reading
22:53:53  <isaacs>otherwise state.reading is still true
22:53:57  <isaacs>and it won't try to _read() again
22:55:34  <isaacs>TooTallNate: of course, you should only do this if you're reasonably sure that you'll call read() at soem point in the future regardless.
22:55:44  <isaacs>in cryptostreams, we call read(0) whenever we think there *might* be data availabe
22:58:11  <TooTallNate>isaacs: i guess my question is: if you return cb(null, ''), when does _read() get called next?
22:58:27  <isaacs>TooTallNate: when we call read(0) some time in the future
22:58:46  <isaacs>TooTallNate: ie, if the encrypted side or the readable side get written to
22:59:00  <isaacs>crypto is a very complicated double-duplex monster.
22:59:05  <TooTallNate>isaacs: shouldn't it get called immediately, as long as it's < hwm?
22:59:11  <TooTallNate>s/immediately/nextTick
23:00:26  <isaacs>TooTallNate: no, because we bail out of the onread fucntion when that happens
23:00:27  <isaacs> if (!state.objectMode &&
23:00:27  <isaacs> (chunk || typeof chunk === 'string') &&
23:00:27  <isaacs> 0 === chunk.length)
23:00:27  <isaacs> return;
23:00:59  <TooTallNate>but why?
23:01:32  <TooTallNate>it just really seems like if crypto depends on this feature, then it's not implemented correctly
23:01:48  <isaacs>because that'd just triger another call to _read() which has already told us that it doesn't have anythign for us
23:02:02  <isaacs>think about it, _read() said "No data now, come back later maybe"
23:02:19  <isaacs>if we call read(0) right away, we're just being rude
23:02:54  <isaacs>at some point in the future, we'll call read() and get something or not, and then that's great.
23:03:15  <TooTallNate>i just think the stream class is doing too much work atm
23:03:32  <TooTallNate>this state should be kept by crypto or whatever is implementing IMO
23:03:47  <TooTallNate>and then you just… don't call the cb() before you have data
23:03:50  * benoitcjoined
23:04:37  <isaacs>right, but then a) you don't know whether you have data until you check, and the answer might be no, and b) it won't call _read again while it's already got a _read pending, so you end up having to track all the same state in 2 places.
23:04:57  <isaacs>or just manually hit this._readableState.reading = false, which is even dirtier
23:05:34  <isaacs>another option is to say that "no data" is not EOF, and have an explicit way to signal EOF.
23:05:42  <isaacs>like a different method or somethign
23:05:46  <isaacs>but we end up witht eh same issues.
23:06:05  <isaacs>eofTimeNao = function() { this.push(null; }
23:06:32  <isaacs>and if you do get null from _read, you still have to know "Hey, there's nothing now, but i should come back again later when i thin there might be more"
23:07:25  <isaacs>it's easy for transform streams, because you can call cb() when you know you want more stuff.
23:07:26  <trevnorris>and this is why i enjoy fine tuning the internals.
23:07:34  <isaacs>but that's where you have a clear "my writer goes to my reader" kind of thing
23:08:05  <isaacs>in teh case of crypto, you might have many kb of data bak and forth with the client over the crypt side, before you ever get any cleartext data.
23:08:22  <isaacs>so it's not just that the enc readable goes to the clear writable and vice versa
23:08:59  <TooTallNate>isaacs: i think the 2 crypto streams should do more communicating (using i.e. events) rather then relying on the stream interface
23:09:11  <isaacs>TooTallNate: maybe.
23:09:16  <isaacs>TooTallNate: i think we should revisit that for 0.12 :)
23:09:27  <TooTallNate>well…
23:09:39  <TooTallNate>it'll be harder to remove the feature then :p
23:09:52  <TooTallNate>plus, atm it's an inconsistent feature
23:10:04  <TooTallNate>since it doesn't work in objectMode https://github.com/joyent/node/issues/4819
23:10:40  <MI6>joyent/node: Ben Noordhuis v0.8 * ef94521 : zlib: fix assert on bad input The following test case occasionally trigg - http://git.io/nZghTQ
23:11:09  <TooTallNate>isaacs: i'm just saying that with some of the crazy stream multiplexing things i've implemented so far with streams2, i would have expected to run into this feature if it was really needed...
23:11:47  <isaacs>TooTallNate: your crazy stream multiplexing things are not tls
23:11:53  <isaacs>TooTallNate: it's the craziest
23:12:02  <trevnorris>bnoordhuis, tjfontaine: thanks again for the strace and gdb tutorials. don't know how I lived w/o those before.
23:12:17  <TooTallNate>a part of me wishes Readable and friends were *even more* abstract then they are right now
23:12:25  <tjfontaine>trevnorris: my employer would also have me suggest you checkout mdb and dtrace on smartos next :)
23:12:30  <isaacs>TooTallNate: i think we can get away with removing it in 0.12 if we're going to fix tls up
23:12:51  * bradleymeckquit (Quit: bradleymeck)
23:12:51  <isaacs>TooTallNate: i'm not sure Raynos actually needs it for object streams.
23:13:06  <isaacs>TooTallNate: the thing is, if you use this, you'll potentially never know when to call _read again
23:13:07  <TooTallNate>no he doesn't… he just wants it for convenience
23:13:11  <Raynos>need what?
23:13:18  <isaacs>Raynos: https://github.com/joyent/node/issues/4819
23:13:20  <TooTallNate>Raynos: cb(null, '')
23:13:23  <Raynos>oh you want to get rid of no data
23:13:28  <Raynos>I like cb(null, undefined
23:13:29  <TooTallNate>i want to, ya
23:13:36  <isaacs>Raynos: i'd love to get rid of it for all streams, but i don't see a way to do crypto without t
23:13:38  <TooTallNate>no, it's too high-level
23:13:47  <isaacs>atm, i consider this an internal interface.
23:13:56  <isaacs>that's why 'cb(null,"")` is not documented
23:14:15  <TooTallNate>isaacs: well that's a good start - let's keep it that way :)
23:14:19  <Raynos>ok it doesnt matter anyway
23:14:22  <Raynos>I can just put it in read-stream
23:14:24  <Raynos>that will work
23:14:35  <isaacs>sure, userland ftw :)
23:14:42  <TooTallNate>Raynos: ya totally, a higher level interface is where that belongs :)
23:15:03  <isaacs>recall: I'm even somewhat against objectMode in principle anyway
23:15:04  <trevnorris>tjfontaine: keep hearing about those. i'll look into them eventually. =)
23:15:40  <tjfontaine>I'll admit I am still mostly a printf/strace/gdb guy
23:15:51  <tjfontaine>but largely because that's what I have the most experience with
23:16:31  <TooTallNate>isaacs: this is an example of using events over cb(null, ''): https://github.com/TooTallNate/node-flv/blob/master/lib/decoder-stream.js#L36-L41
23:17:20  <isaacs>TooTallNate: i'm not disagreeing with the principle here. just with hte urgency of changing the implementation.
23:17:20  <tjfontaine>trevnorris: on linux there's also systemtap which is similar to dtrace
23:17:36  <isaacs>tjfontaine: saying that in the office will get you a demerit
23:17:37  <isaacs>just sayin
23:17:38  <TooTallNate>isaacs: fair enough
23:17:39  <isaacs>;)
23:17:48  <Raynos>isaacs: good point, objectMode is out of scope but dear god the buffering nightmare ;_;
23:17:53  <tjfontaine>isaacs: I didn't say it aloud of course :)
23:17:56  <isaacs>TooTallNate: i'd like ot rewrite tls.js entirely. but indutny was kind enough to duct tape it into shape
23:18:01  <trevnorris>tjfontaine: cool i'll look into it. thanks.
23:18:04  <isaacs>TooTallNate: and made it way faster in the process :)
23:18:08  <isaacs>which is always a plus
23:18:11  <bnoordhuis>isaacs: re https://github.com/isaacs/node/compare/path-resolve-nonstring-typeerror, lgtm
23:18:11  <TooTallNate>ya that's badass
23:18:13  <TooTallNate>indutny++
23:18:56  <MI6>joyent/node: isaacs master * 089ec58 : path: Throw TypeError on non-string args to path.resolve - http://git.io/7kdbpg
23:18:57  <isaacs>bnoordhuis: thanks
23:19:29  <isaacs>TooTallNate: so, anyway... how do you feel about removing lowWaterMark, and reading up to the highWaterMark?
23:19:32  <isaacs>TooTallNate: https://github.com/joyent/node/pull/4828
23:19:44  <TooTallNate>isaacs: yup, sorry, got distracted for a second :)
23:20:40  <MI6>joyent/node: isaacs created branch pr/4828 - http://git.io/Mlobvg
23:20:45  <Raynos>isaacs: +1 on those changes btw
23:20:54  <isaacs>hmmm... that doesn't quite work, i guess...
23:21:31  * loladirojoined
23:22:05  <isaacs>hm. you can't push to the pull-req ref.
23:24:57  <TooTallNate>isaacs: wha?
23:25:07  <TooTallNate>isaacs: lwm changes seem good to me
23:25:15  <isaacs>kewl
23:25:29  <isaacs>TooTallNate: pop open your .git/config in your favorite text editor
23:25:48  <isaacs>TooTallNate: in the [remote "upstream or origin or whatever"] section, add this line:
23:25:51  <isaacs> fetch = +refs/pull/*/head:refs/remotes/ry/pr/*
23:26:04  <isaacs>TooTallNate: now git fetch -a originorwhatever will pull down a bunch of "pr/12345" type refs
23:26:32  <isaacs>TooTallNate: so i can do `git merge ry/pr/4828` to merge in my lwm pull req
23:26:44  <isaacs>TooTallNate: then `git pull --rebase ry master` to rebase onto the latest master.
23:26:58  <TooTallNate>isaacs: wow that's a badass trick
23:27:18  <isaacs>then `git push ry-push master` to push it, and this happens:
23:27:27  <MI6>joyent/node: isaacs master * a63c28e : stream: Return false from push() more properly There are cases where a p (+1 more commits) - http://git.io/gNzvbQ
23:27:37  <isaacs>(i have ry pointing at the read-only repo, so i'm less likely to push by mistake)
23:27:54  <tjfontaine>I remember being extremely happy when bert showed me the pr refs
23:28:01  <isaacs>yes, it's very nice
23:28:26  <TooTallNate>isaacs: i do the same (different names) origin=read-only, upstream=pushable
23:28:49  * c4miloquit (Remote host closed the connection)
23:28:50  <isaacs>TooTallNate: my origin is isaacs/node
23:29:21  <isaacs>i have a bunch of bash shortcuts that assume that origin will always be a git repo with "isaacs" in the url
23:29:24  * c4milojoined
23:30:46  <trevnorris>if anyone has a spare hour, here are my event emitter changes in progress: https://github.com/trevnorris/node/compare/emulsify-events
23:34:19  * c4miloquit (Ping timeout: 244 seconds)
23:41:32  * qmxchanged nick to qmx|away
23:41:38  <bnoordhuis>"emulsify" :)
23:42:32  <isaacs>trevnorris: https://github.com/trevnorris/node/compare/emulsify-events#L1R48
23:42:35  <isaacs>trevnorris: should be ||
23:43:37  <trevnorris>well, you found that fast. =P
23:43:41  <trevnorris>thanks
23:45:21  <isaacs>trevnorris: not sure if it's still going to be an issue on 3.16, but you should try to avoid early returns in these small strongly-typed functions
23:45:41  <isaacs>speaking of which, running tests now on v8 3.16
23:46:07  <trevnorris>oh really? interesting.
23:46:24  <trevnorris>and what do you mean by "running tests now"? you already have it ported to master?
23:46:29  <tjfontaine>isaacs: are you considering a jump before .10?
23:46:41  <isaacs>tjfontaine: yeah, kinda
23:46:52  <trevnorris>tjfontaine: i'd like that. bnoordhuis mentioned a gc fix in 3.16
23:46:54  <isaacs>it's a bit risky, but it also might reduce some of our speed regressions
23:47:08  <trevnorris>being that many operations use 2x's the memory.
23:47:18  <isaacs>simple/test-fs-readfile-error failed
23:47:19  <isaacs>kinda odd.
23:47:36  <trevnorris>isaacs: you have a branch for 3.16?
23:47:45  <isaacs>trevnorris: i'll push it
23:47:50  <trevnorris>=))
23:48:18  <trevnorris>isaacs: path.js 117 - punny code reporting missing space before (
23:48:31  <trevnorris> *puny
23:49:08  <tjfontaine>damn debugger repl tests
23:52:33  <Raynos>isaacs: I think multiple pushes inside _read cb whilst length < hwm may not garantuee order of the things I push in because _read gets called synchronously inside push
23:52:45  <Raynos>I would need to write a test case for this.
23:55:12  <isaacs>hmm... it looks like V8 3.16 makes the `message` property on Errors less magical
23:55:36  <trevnorris>less... magical?
23:56:53  <isaacs>yeah
23:57:03  <isaacs>like, changing the message doesn't automatically update the stack trace
23:57:11  <isaacs>kinda ruins our AssertionError class
23:58:03  * benoitcquit (Excess Flood)
23:58:19  * indexzerojoined
23:58:51  <isaacs>ohh... it's like this.message is read-only or something