00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:26  * c4miloquit (Remote host closed the connection)
00:02:59  * c4milojoined
00:05:25  * mcoffeequit (Remote host closed the connection)
00:07:33  * c4miloquit (Ping timeout: 248 seconds)
00:10:05  * wwicks_joined
00:11:49  * wwicksquit (Ping timeout: 248 seconds)
00:11:50  * wwicks_changed nick to wwicks
00:12:42  * EhevuTovquit (Quit: This computer has gone to sleep)
00:18:44  <wolfeidau>tjfontaine: wow what a great idea, I mite log the stacks while doing a https request
00:29:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:30:06  * st_lukequit (Remote host closed the connection)
00:30:35  * st_lukejoined
00:31:35  * wwicks_joined
00:32:30  * wwicksquit (Ping timeout: 264 seconds)
00:32:30  * wwicks_changed nick to wwicks
00:35:33  * st_lukequit (Ping timeout: 265 seconds)
00:36:44  * c4milojoined
00:36:53  * sblomquit (Ping timeout: 248 seconds)
00:41:09  * amartensjoined
00:48:39  * TooTallNatejoined
00:55:34  * c4miloquit (Remote host closed the connection)
00:56:07  * c4milojoined
01:00:42  * c4miloquit (Ping timeout: 264 seconds)
01:10:39  * dapquit (Quit: Leaving.)
01:13:09  * mikealquit (Quit: Leaving.)
01:20:03  <tjfontaine>wolfeidau: :)
01:26:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:27:19  * abraxasjoined
01:27:49  * brson_joined
01:28:14  * brsonquit (Read error: Connection reset by peer)
01:28:31  <Raynos>We're using a C++ binary extension that crashes our process by throwing a C++ exceptions in openCV
01:28:42  <Raynos>it never seems to bubble upto v8
01:28:44  <tjfontaine>ya, don't do that.
01:28:47  <Raynos>is there anyway to deal with that
01:28:48  * brsonjoined
01:28:59  <tjfontaine>you need to wrap with C++ try{}catch{}
01:29:12  <Raynos>and in the catch create & throw a v8 exception ?
01:29:14  * philipsquit (Changing host)
01:29:14  * philipsjoined
01:29:38  <tjfontaine>if that's interesting to you, yes -- if it's an async method you should make an error object and pass it along, you know the normal stuff
01:30:15  <Raynos>ok
01:30:33  * brson__joined
01:30:34  <tjfontaine>I'm fairly certain your exception will only land on the thread you are on
01:30:36  <Raynos>is there a c++ compiler flag
01:30:45  <Raynos>that makes the C++ stuff not die horribly
01:32:43  * brson_quit (Ping timeout: 248 seconds)
01:34:02  <tjfontaine>well, there's -fno-exception but don't be fooled, that just means your unwinding doesn't happen
01:34:18  <tjfontaine>I was just verifying here with others
01:34:31  * brsonquit (Ping timeout: 265 seconds)
01:35:02  <tjfontaine>about threads and exceptions, you shoudl be fine, but if you're catching a thread from a worker, you want to make an error object and then pass it to the after
01:37:25  * kazuponjoined
01:39:00  * c4milojoined
01:41:06  * kazuponquit (Remote host closed the connection)
01:41:33  * kazuponjoined
01:45:48  * kazuponquit (Ping timeout: 240 seconds)
01:49:18  * brson__quit (Ping timeout: 264 seconds)
01:49:23  * c4miloquit (Remote host closed the connection)
01:56:23  * brsonjoined
02:09:17  * c4milojoined
02:13:49  * bradleymeckjoined
02:23:47  * kazuponjoined
02:28:18  * kazuponquit (Remote host closed the connection)
02:28:45  * kazuponjoined
02:32:46  * mikealjoined
02:32:59  * kazuponquit (Ping timeout: 248 seconds)
02:48:31  * TooTallNatejoined
03:22:23  * c4miloquit (Remote host closed the connection)
03:22:56  * c4milojoined
03:25:05  * c4milo_joined
03:26:00  * c4miloquit (Read error: Connection reset by peer)
03:29:28  * brsonquit (Quit: leaving)
03:34:05  * mikealquit (Quit: Leaving.)
03:43:36  * c4milo_quit (Remote host closed the connection)
03:56:07  * wwicks_joined
03:57:45  * wwicksquit (Ping timeout: 252 seconds)
03:57:45  * wwicks_changed nick to wwicks
03:59:31  * kazuponjoined
04:04:49  * mikealjoined
04:07:11  * c4milojoined
04:09:08  * mikealquit (Ping timeout: 240 seconds)
04:19:14  * bradleymeckquit (Quit: bradleymeck)
04:24:14  <isaacs>tjfontaine: i just resized the nodejs.org zone up, because nginx is filling up the disk drive.
04:24:28  <isaacs>tjfontaine: those logs are being backed up to manta, right? can we tell logadm to delete them or something?
04:25:03  <isaacs>tjfontaine: anyway, i'm off to bed. with the resize it should be fine for another month or so, so no rush. g'nite :)
04:34:49  * mikealjoined
04:38:31  * st_lukejoined
04:44:09  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:45:28  * mikealquit (Ping timeout: 264 seconds)
05:00:30  * st_lukequit (Remote host closed the connection)
05:01:08  * st_lukejoined
05:05:31  * st_lukequit (Ping timeout: 248 seconds)
05:09:46  * st_lukejoined
05:12:59  * mikealjoined
05:15:27  * dominictarrjoined
05:17:22  * c4miloquit (Remote host closed the connection)
05:19:34  * st_lukequit (Remote host closed the connection)
05:25:48  <indutny>heya
05:31:53  * TooTallNatejoined
05:38:41  * st_lukejoined
05:42:51  * st_lukequit (Remote host closed the connection)
05:43:30  * st_lukejoined
05:47:49  * st_lukequit (Ping timeout: 248 seconds)
05:58:00  * TooTallNatequit (Quit: Computer has gone to sleep.)
05:58:06  * wwicks_joined
05:58:34  * dominictarrquit (Quit: dominictarr)
06:00:37  * wwicksquit (Ping timeout: 248 seconds)
06:00:37  * wwicks_changed nick to wwicks
06:26:26  * rendarjoined
06:40:48  <MI6>nodejs-v0.10-windows: #252 UNSTABLE windows-ia32 (9/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/252/
07:00:24  * wwicks_joined
07:01:25  * wwicksquit (Ping timeout: 248 seconds)
07:01:26  * wwicks_changed nick to wwicks
07:20:58  * wwicks_joined
07:22:04  * wwicksquit (Ping timeout: 264 seconds)
07:22:04  * wwicks_changed nick to wwicks
07:22:50  * hzjoined
07:41:07  * amartensquit (Quit: Leaving.)
07:41:34  * wwicks_joined
07:42:16  * wwicksquit (Ping timeout: 245 seconds)
07:42:16  * wwicks_changed nick to wwicks
08:01:09  * wwicks_joined
08:03:28  * wwicksquit (Ping timeout: 264 seconds)
08:03:29  * wwicks_changed nick to wwicks
08:06:11  * bajtosjoined
08:15:58  * kenperkins_joined
08:17:02  * bnoordhuisjoined
08:17:22  * kenperkinsquit (Ping timeout: 246 seconds)
08:50:36  * dominictarrjoined
09:22:38  * wwicks_joined
09:25:08  * wwicksquit (Ping timeout: 240 seconds)
09:25:08  * wwicks_changed nick to wwicks
09:34:35  * bajtosquit (Quit: bajtos)
09:39:46  * Kakerajoined
09:44:00  * wwicks_joined
09:44:32  * bnoordhuisquit (Ping timeout: 248 seconds)
09:44:46  * wwicksquit (Ping timeout: 245 seconds)
09:44:46  * wwicks_changed nick to wwicks
10:19:02  * dominictarrquit (Quit: dominictarr)
10:45:29  * wwicks_joined
10:46:54  * wwicksquit (Ping timeout: 264 seconds)
10:46:54  * wwicks_changed nick to wwicks
10:48:11  <MI6>nodejs-v0.10: #1526 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) linux-x64 (1/601) osx-x64 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1526/
10:51:48  * abraxasquit (Remote host closed the connection)
10:52:20  * abraxasjoined
10:56:59  * abraxasquit (Ping timeout: 248 seconds)
10:58:46  * bajtosjoined
11:04:07  * bnoordhuisjoined
11:08:48  * kazuponquit (Remote host closed the connection)
11:23:11  * piscisaureus_joined
11:46:02  * wwicks_joined
11:47:28  * wwicksquit (Ping timeout: 240 seconds)
11:47:28  * wwicks_changed nick to wwicks
12:07:16  * wwicks_joined
12:08:32  * wwicksquit (Ping timeout: 248 seconds)
12:08:33  * wwicks_changed nick to wwicks
12:14:11  <MI6>joyent/node: Ben Noordhuis v0.10 * 51cdce8 : doc: addon: fix object instantiation examples - http://git.io/Vuz7TA
12:19:34  <indutny>heya
12:24:10  <MI6>nodejs-v0.10: #1527 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) linux-x64 (1/601) linux-ia32 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1527/
12:24:11  <indutny>bnoordhuis: closing all pi tickets?
12:27:12  * wwicks_joined
12:28:18  * kenperkins_quit (Ping timeout: 264 seconds)
12:29:12  <MI6>nodejs-v0.10-windows: #253 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/253/
12:29:56  * wwicksquit (Ping timeout: 265 seconds)
12:29:56  * wwicks_changed nick to wwicks
12:30:32  <bnoordhuis>indutny: and everything else. there are no bugs, just bad expectations
12:34:52  <MI6>joyent/node: Ben Noordhuis v0.10 * ff1efdd : doc: net: remove bad net.Server description - http://git.io/IVO0gA
12:36:07  * kenperkinsjoined
12:38:26  <indutny>bnoordhuis: sounds like a book title
12:41:48  * dominictarrjoined
12:45:06  <bnoordhuis>indutny: i'm a poet at heart
12:45:37  <MI6>nodejs-v0.10: #1528 UNSTABLE smartos-x64 (5/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1528/
12:48:50  * CoverSlidequit (Ping timeout: 264 seconds)
12:49:55  <MI6>nodejs-v0.10-windows: #254 UNSTABLE windows-ia32 (9/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/254/
12:50:28  * CoverSlidejoined
12:53:57  * dominictarrquit (Quit: dominictarr)
12:56:18  * dominictarrjoined
13:05:02  * c4milojoined
13:10:29  <mmalecki>bnoordhuis: hi!
13:11:52  * CoverSlidequit (Ping timeout: 264 seconds)
13:13:23  * CoverSlidejoined
13:15:27  <bnoordhuis>mmalecki: ho :)
13:15:31  <bnoordhuis>indutny: seen this? https://news.ycombinator.com/item?id=6526484
13:15:53  <bnoordhuis>are you one of the lucky 110?
13:23:51  * hzquit
13:31:28  * bajtosquit (Quit: bajtos)
13:32:46  * bajtosjoined
13:32:58  * bajtosquit (Client Quit)
13:33:52  * einaros_changed nick to einaros
13:48:36  * kevinswiberjoined
13:48:56  * wwicksquit (Read error: Connection reset by peer)
13:49:17  * wwicksjoined
14:01:18  * c4miloquit (Remote host closed the connection)
14:02:41  * c4milojoined
14:02:59  * c4miloquit (Remote host closed the connection)
14:08:48  * bradleymeckjoined
14:08:50  * wwicksquit (Read error: Connection reset by peer)
14:09:09  * wwicksjoined
14:11:55  <mmalecki>bnoordhuis: how are you :) ?
14:13:06  * CoverSlidequit (Ping timeout: 245 seconds)
14:14:36  * bajtosjoined
14:14:45  <bnoordhuis>mmalecki: i have one more kid since last time but, apart from that, same old, same old :)
14:14:55  * CoverSlidejoined
14:15:12  <mmalecki>bnoordhuis: oh, congrats! :)
14:15:54  <mmalecki>bnoordhuis: how's Netherlands this time of the year?
14:16:34  <bnoordhuis>quite sunny but a tad chilly
14:16:49  <bnoordhuis>i was still walking around in a t-shirt earlier this week though
14:17:20  <bnoordhuis>how's the move to NY going?
14:17:21  <mmalecki>heh, nice. I managed to do it in Lisbon, but I'd probably freeze if I did it in Poland
14:17:30  <mmalecki>oh... not at all
14:18:34  <mmalecki>bnoordhuis: I think I'll be moving in more... European direction :-)
14:20:05  <bnoordhuis>oh? what made you change your mind?
14:20:23  <bnoordhuis>i mean, there's a 1,000 reasons not to move the USA, don't get me wrong
14:20:35  <bnoordhuis>but what in particular made you change your mind?
14:21:03  <bnoordhuis>*move to the USA
14:21:25  <bnoordhuis>though there's plenty of reasons not to move the USA either
14:21:58  <mmalecki>I mean, recent NSA news were enough to convince me on their own
14:22:24  <mmalecki>a country which actively practices terrorism and kills foreign citizens with drones for protesting drone attacks?
14:23:26  <bnoordhuis>to name one thing
14:30:30  * wwicks_joined
14:31:33  * wwicksquit (Ping timeout: 248 seconds)
14:31:33  * wwicks_changed nick to wwicks
14:31:52  * bradleymeckquit (Quit: bradleymeck)
14:31:54  * AvianFlujoined
14:32:23  * bradleymeckjoined
14:34:41  * mcavagejoined
14:39:06  * bnoordhuisquit (Ping timeout: 264 seconds)
14:53:19  * mikealquit (Quit: Leaving.)
14:55:07  * mikealjoined
15:07:11  * bnoordhuisjoined
15:10:16  * bnoordhuisquit (Client Quit)
15:15:24  * mikealquit (Quit: Leaving.)
15:16:34  * bajtosquit (Quit: bajtos)
15:19:16  * mikealjoined
15:19:40  <MI6>nodejs-master: #604 UNSTABLE smartos-ia32 (6/644) smartos-x64 (8/644) osx-ia32 (1/644) http://jenkins.nodejs.org/job/nodejs-master/604/
15:23:33  * kazuponjoined
15:27:29  <Domenic_>piscisaureus_: tell me about streams that are just .read(cb)
15:28:54  <Domenic_>I think I heard trevnorris was also interested in that?
15:31:00  * kevinswiberquit (Remote host closed the connection)
15:31:08  * wwicks_joined
15:31:37  * kevinswiberjoined
15:34:04  * wwicksquit (Ping timeout: 264 seconds)
15:34:04  * wwicks_changed nick to wwicks
15:34:16  <isaacs>Domenic_: piscisaureus_: That only makes sense if reads are *usually* called when data is not available.
15:34:45  <Domenic_>isaacs: but ... microtasks are free ... kind of ...
15:35:05  <isaacs>Domenic_: deferring isn't free
15:35:19  * mikealquit (Quit: Leaving.)
15:35:25  <Domenic_>i remember someone telling me back in the early 0.10 days it was as fast as a while loop. (That someone was you.)
15:35:37  <isaacs>no, i said it was as BLOCKING as a while loop
15:35:56  <Domenic_>haha wow i've been carrying that mis-hearing around for a long time -_-
15:35:57  <isaacs>(may have said "like a while loop")
15:36:07  <isaacs>i have a habit of being vague :)
15:36:15  * kevinswiberquit (Ping timeout: 251 seconds)
15:36:22  <isaacs>it's easy to benchmark and show that both are fast enough to usually not matter, butif they do matter, then the while loop is MUCH faster
15:38:17  <Domenic_>siiigh
15:38:23  <Domenic_>but poll + readCurrentBuffer + state so unweildy
15:38:49  <Domenic_>i was curious because piscisaureus_ said at lxjs that he wanted to do read(cb) because it was already being done internally somehow
15:39:47  * c4milojoined
15:40:19  <isaacs>well... no, that's how libuv is doing it
15:40:41  <isaacs>and it's actually more like on('data') pause/resume
15:40:49  <isaacs>except it's ondata, readStart(), readStop()
15:41:42  <Domenic_>hmm
15:41:55  <Domenic_>is that model nicer than poll/readCurrentBuffer/state?
15:41:56  <isaacs>but internal in libuv, yes.
15:42:03  <isaacs>depends :)
15:42:19  <isaacs>when you usually are reading faster than the data is flowing, then you want read(cb)
15:42:32  <isaacs>when you usually are reading slower than the data is flowing, you want read()/poll
15:43:00  <Domenic_>but you showed read(cb) built on top of read()/poll
15:43:12  <isaacs>ondata/pause/resume is klunky at any speed, imo, but useful for some cases like passive listening
15:43:22  <isaacs>yes, you can translate them all into one another because programming
15:44:04  <Domenic_>well ok
15:44:10  <isaacs>Domenic_: my zalgo blog post discusses the heuristics for choosing
15:44:25  <Domenic_>let me outline my situation
15:44:49  * mikealjoined
15:46:30  <Domenic_>designing browser streams API. nice happy flower-land = simple read(cb) nothing else. but if that limits use cases, bad. so thinking, what is the lower-level thing i should build read(cb) on? I thought it was read/poll/state, but now you are saying i could build read/poll/state on top of read(cb)? But I don't think that's true since read/poll/state can give
15:46:31  <Domenic_>sync behavior, read(cb) cannot. And this is generic API so I don't think it's a good idea to make the choice for users as to which use case is more prevalent??
15:47:00  * kevinswiberjoined
15:49:42  * dapjoined
15:52:26  * wwicks_joined
15:53:36  * wwicksquit (Ping timeout: 248 seconds)
15:53:37  * wwicks_changed nick to wwicks
15:55:12  * mikealquit (Quit: Leaving.)
15:55:59  <piscisaureus_>Domenic_: in the browser you don't want to have an eventEmitter
15:56:04  <isaacs>Domenic_: to build read/poll on top of read(cb), you just have to keep calling read(cb) and pushing into a buffer until it fills up to the specified level.
15:56:18  <isaacs>Domenic_: note that we DO effectively build read/poll on top of read(cb) in node!
15:56:27  <Domenic_>isaacs: hmm ok...
15:56:29  <piscisaureus_>Domenic_: ^ :)
15:56:36  <isaacs>well, on top of read/push
15:56:38  <isaacs>but yeah
15:56:52  <piscisaureus_>isaacs: yeah that was a design mistake. We should have done read(cb) in libuv
15:56:55  <piscisaureus_>just like write(cb)
15:57:05  <isaacs>yeah
15:57:18  <isaacs>ondata/pause/resume is kinda janky as a lowlevel thing to build on top of
15:57:27  <piscisaureus_>yeah
15:57:31  <isaacs>since libuv reads are usually going to be unbuffered, read(cb) makes more sense.
15:57:52  <piscisaureus_>well in libuv we'd still have alloc_cb
15:57:56  <isaacs>since Node's js layer is typically going to be used for pipe(), read()/poll kinda makes more sense, since you want some buffering to happen
15:57:59  <isaacs>piscisaureus_: sure
15:58:03  * kevinswiberquit (Remote host closed the connection)
15:58:17  <piscisaureus_>but the kernel zero copy problem doesn't exist for browsers
15:58:37  * kevinswiberjoined
15:58:51  * mikealjoined
15:58:58  <isaacs>i'm assuming that the "browser stream" API, whatever it settles on, will eventually be used for serverside coding.
15:59:03  <isaacs>i think this is a safe assumption
15:59:14  <isaacs>and it's shaping how i'm thinking about this problem
15:59:32  <piscisaureus_>I think it should be more low level and have no eventemitters
15:59:50  <tjfontaine>or device side in the case of boot2gecko
15:59:59  <Domenic_>yes b2g is driving this most pressingly
16:00:05  <piscisaureus_>.read([lowat, [hiwat]], cb)
16:00:07  * bajtosjoined
16:00:09  <piscisaureus_>.write(cb)
16:00:18  <Domenic_>(also stopping the chrome filesystem API guys from doing crazy things.)
16:00:23  <piscisaureus_>.shutdown/end(cb)
16:00:38  <Domenic_>interesting lowat and hiwat on the read call, not the constructor?
16:00:47  <Domenic_>wait i thought lowat was killed
16:00:55  <piscisaureus_>Ah we can kill lowat
16:01:11  <piscisaureus_>If you'd specify it it means "read at least XX bytes or until EOF/FIN"
16:01:25  <Domenic_>ah right
16:01:36  <Domenic_>isaac contended (and I think I agree) that this is not terribly useful
16:01:37  <piscisaureus_>like read(3) - disregarding signals
16:01:46  <piscisaureus_>Domenic_: I agree actually
16:01:54  <Domenic_>because what you usually want is "readUntil"
16:02:37  <piscisaureus_>Domenic_: I think that's not terribly useful either, because it requires copying/transient wrapping of part of the read buffer
16:02:41  * kevinswiberquit (Ping timeout: 245 seconds)
16:02:54  <piscisaureus_>Domenic_: or to actually call read(3) with that amount of bytes
16:03:10  <piscisaureus_>but then you end up doing way to much reads because the user typically consumes data in small chunks
16:03:25  <Domenic_>sure
16:03:34  <piscisaureus_>Domenic_: so - in fact lowat and hiwat are useful but they are "too sweet" for a low level api
16:03:53  <Domenic_>ok. but it's still useful to control the buffer at stream construction time i assume
16:04:21  <piscisaureus_>Depends - what would you want to control at construction time exactly?
16:04:57  <Domenic_>Well node currently has new ReadableStream({ highWaterMark })
16:05:25  <piscisaureus_>Yeah well that's isaacs design choice. But this requires the streams2 code to do internal bookkeeping and tricks
16:05:31  <Domenic_>oh interesting
16:05:35  <piscisaureus_>like copying/joining/slicing buffers
16:05:39  <Domenic_>so kill it?
16:06:09  <piscisaureus_>If you want very low level yeah. What you could specify is a default "max chunk size"
16:06:20  <Domenic_>isn't it important for backpressure? i.e. for when push() returns false?
16:06:30  <piscisaureus_>like fs.createReadStream({maxBuffer: 65536
16:06:47  <piscisaureus_>Domenic_: I don't think so?
16:07:10  <Domenic_>I was under the impression push() starts returning false when the buffer has highWaterMark bytes inside it
16:07:44  <piscisaureus_>Domenic_: ah that could be true. But then highWaterMark basically means "how much node buffers internally"
16:08:14  <piscisaureus_>Domenic_: which is only applicable for data that is push()ed. It doesn't matter for data that comes off the network.
16:08:50  <Domenic_>right that makes sense
16:09:06  <piscisaureus_>Domenic_: maybe you're right. Some sort of buffer size makes sense. On windows/unix you also have a "pipe size"
16:09:30  <piscisaureus_>which is how much data the write and can write until the write() call starts blocking
16:09:56  <piscisaureus_>So I guess having something like this at construction time would indeed be useful although the semantics would be a little different depending on the type of stream
16:10:56  <piscisaureus_>Domenic_: do you also have ideas about seekable streams (files) and message/frame oriented streans (like message queues)
16:11:09  <piscisaureus_>Domenic_: or is that out of scope ?
16:11:45  <Domenic_>piscisaureus_: not really, never thought about them... ideally get something out the door first, but if you think there are relevant concerns that should inform the base design, then that's worth knowing...
16:12:32  <Domenic_>i feel like the design i have now can almost work with any object (not just arraybuffers or strings), but that seems strange, so i'm not *trying* to make it work.
16:13:49  <Domenic_>New question: what is .write's callback useful for?
16:14:02  <Domenic_>It is weird that it has both a sync return (boolean) and async return (callback)
16:14:11  <Domenic_>I guess errors :-/
16:14:33  * TooTallNatejoined
16:14:34  <piscisaureus_>Domenic_: in a low level interface you may not want to return true or false
16:14:49  <piscisaureus_>Domenic_: also, errors indeed. If write fails the error callback should receive the error
16:15:05  <Domenic_>Hmm that would be convenient. But how can you get away with it? I assumed pipe() used the true/false to do backpressure stuff...
16:15:14  <piscisaureus_>Domenic_: whether the user can immediately write more should be available as a property on the stream object
16:15:21  <piscisaureus_>Domenic_: or as a method
16:15:38  <Domenic_>OK that was going to be my fallback approach; I am glad you think it is good enough to be a "should"
16:15:55  <isaacs>Domenic_: it's already a "should"
16:16:10  <piscisaureus_>isaacs: what property is that in node?
16:16:10  <isaacs>the write() return can be ignored. it's not unsafe if done in smal amounts
16:16:16  <isaacs>piscisaureus_: well, it's the return value
16:16:28  <isaacs>piscisaureus_: but also i think _writableState.needDrain or something
16:16:32  <Domenic_>needDrain yeah I think
16:16:40  <piscisaureus_>right
16:16:46  <Domenic_>What is a good name for it? "full"?
16:16:52  <isaacs>which means "you filledit up, and now someone is expecting a drain event"
16:17:00  <isaacs>Domenic_: i'd actualy like a stream.state or something
16:17:08  <isaacs>Domenic_: which is 'OK' if it's ok to do more stuff, and something else if not.
16:17:24  <isaacs>maybe stream.readState and stream.writeState
16:17:28  <Domenic_>this ties into your readable state idea, hmm, yeah
16:17:40  <piscisaureus_>Domenic_: full would be ok. Note that this only applies to the write end.
16:18:10  <piscisaureus_>Domenic_: the "real problem" is that there is some magic number
16:18:33  <piscisaureus_>Domenic_: and the user should make sure it writes until it reaches that number (or slightly goes over it)
16:18:41  <isaacs>piscisaureus_: well, so, either you buffer, or writes are not allowed when somethign is not flushed yet, etc
16:18:43  <Domenic_>readableState = { "hasData", "empty", "EOF", "error" }, writableState = { "hasRoom", "isFull", "error" } ??
16:19:11  <Domenic_>oh writableState also has "ended"
16:19:15  <piscisaureus_>Domenic_: which requires careful bookkeeping in the write callback
16:19:51  <isaacs>piscisaureus_: the "real problem" is not that there's a magic number. it's that we built the whole thing up on EE
16:19:53  <piscisaureus_>Domenic_: so the magic number is "how much the kernel can buffer" for tcp streams, which is usually unknown and may vary over time
16:20:05  <Domenic_>so much EE hate in this room ^_^
16:20:09  <isaacs>yes.
16:20:34  <isaacs>Node should not have any control-flow abstractions that aren't native to JavaScript
16:20:36  <piscisaureus_>isaacs: I don't think that a stream can be in "error" state
16:20:48  <isaacs>piscisaureus_: if a write() fails, the stream is errored
16:20:49  <piscisaureus_>isaacs: write() can fail. And so can read(). and so can end()
16:20:54  <isaacs>piscisaureus_: right
16:21:00  <isaacs>piscisaureus_: usually this is unrecoverable
16:21:05  <piscisaureus_>isaacs: yeah so for convenience we could track the error state
16:21:13  <piscisaureus_>isaacs: which is basically "the first error seen
16:21:16  <isaacs>piscisaureus_: right
16:21:54  <isaacs>piscisaureus_: i think, though, if we're going to design JS streams, from first principles, without events, we should not assume that we'll have "lowlevel streams" and "sweet streams"
16:21:57  <Domenic_>I feel like fundamentally it's canRead/shouldRead/cannotRead and the same for write
16:22:15  <isaacs>we should make lowlevel streams fundamentally different from the JS streams users are expected to consume
16:22:21  <isaacs>that was another design mistake in node
16:22:25  <isaacs>_handle vs stream
16:22:51  <Domenic_>I want to see the "design mistakes in node" talk some time
16:22:56  <isaacs>oh, man
16:22:58  <piscisaureus_>isaacs: handle was just the more low level abstraction that was convenient at the time
16:23:07  <isaacs>i bet me and piscisaureus_ could tag-team that one something fierce
16:23:10  <isaacs>:)
16:23:17  <piscisaureus_>:)
16:23:26  <piscisaureus_>we can do a shouting and insults session
16:23:29  <isaacs>you'd need to have both of us, because otherwise i'll gloss over my mistakes, and vice versa
16:23:48  <isaacs>it'd be fun to watch
16:23:57  <isaacs>maybe a little uncomfortable forthe audience
16:23:59  <isaacs>:)
16:24:03  <piscisaureus_>People would stop using node
16:24:09  <piscisaureus_>I'd be bad for our job security
16:24:37  <Domenic_>maybe at nodeconf where it isn't recorded
16:25:04  <isaacs>piscisaureus_: let's do it after we have other jobs, or our startups all take exits
16:25:54  * bradleymeckquit (Quit: bradleymeck)
16:26:01  <isaacs>it'd be good to have ryah on stage for it as well, not so much to say anything, but just to be there while we complain about a lot of the decisions that were originally his, to make the experience even more awkward.
16:26:04  <piscisaureus_>yeah
16:26:21  <piscisaureus_>isaacs: when is yours going to?
16:26:50  <Domenic_>Why is there no _end() like there is _write()?
16:26:58  <isaacs>piscisaureus_: traditionaly you have to have a company before it exits.
16:27:10  <isaacs>piscisaureus_: but, ya know, as soon as someone comes along with a big enough check, as you do.
16:27:37  <isaacs>Domenic_: what would it do?
16:27:52  <Domenic_>um, I guess manage the underlying resource?
16:27:56  <Domenic_>close the FD?
16:28:23  <isaacs>cant' you just do that on('finish')?
16:28:36  <Domenic_>I thought we hated EEs
16:28:38  <isaacs>Domenic_: are you asking, for node streams, or for the new green-field Browser streams?
16:28:48  <Domenic_>well, a combo, i guess.
16:28:48  <isaacs>Domenic_: well, sure, but at least for Node, we're kinda stuck with them
16:29:02  <isaacs>Domenic_: yeah, i dunno. we usually just add a 'finish' listener for that
16:29:06  * amartensjoined
16:29:07  <Domenic_>ok
16:30:44  <piscisaureus_>Domenic_: why do you need an event for that?
16:30:51  <piscisaureus_>Domenic_: could just be stream.close()
16:30:52  <piscisaureus_>?
16:35:53  * brsonjoined
16:37:58  <isaacs>piscisaureus_: you might want to auto-close when the end() flushes
16:38:03  <isaacs>piscisaureus_: like we do in fs
16:38:16  <piscisaureus_>isaacs: and TCP, indirectly
16:38:20  * isaacsdoing a webinar, bbiab
16:39:10  <piscisaureus_>isaacs: yes, so the normal close flow would involve calling end()
16:39:10  * julianduquejoined
16:39:34  <piscisaureus_>isaacs: but the question is what to do for read-only streams (also 'end
16:39:37  <piscisaureus_>'?)
16:39:47  <piscisaureus_>and how to do a fast abortive close
16:40:54  * bradleymeckjoined
16:41:41  * bradleymeckquit (Client Quit)
16:43:43  * bradleymeckjoined
16:44:42  * mikealquit (Quit: Leaving.)
16:48:21  * AvianFluquit (Remote host closed the connection)
16:48:37  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:54:00  * wwicks_joined
16:55:18  * wwicksquit (Ping timeout: 264 seconds)
16:55:18  * wwicks_changed nick to wwicks
16:57:15  * AvianFlujoined
17:01:36  * julianduquequit (Quit: leaving)
17:02:57  * bradleymeckquit (Quit: bradleymeck)
17:03:50  * mikealjoined
17:05:35  * st_lukejoined
17:05:41  * TooTallNatejoined
17:14:27  * wwicks_joined
17:15:28  * wwicksquit (Ping timeout: 264 seconds)
17:15:28  * wwicks_changed nick to wwicks
17:25:31  * bradleymeckjoined
17:27:28  * Benviequit (Ping timeout: 248 seconds)
17:30:23  * Benviejoined
17:32:14  * kevinswiberjoined
17:34:57  * wwicks_joined
17:35:53  * wwicksquit (Ping timeout: 265 seconds)
17:35:54  * wwicks_changed nick to wwicks
17:48:29  * EhevuTovjoined
17:53:28  <MI6>libuv-master: #280 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/280/
17:55:15  * wwicks_joined
17:56:21  * wwicksquit (Ping timeout: 248 seconds)
17:56:21  * wwicks_changed nick to wwicks
18:06:29  * mcavagequit (Remote host closed the connection)
18:06:54  * mcavagejoined
18:08:04  * EhevuTovquit (Quit: This computer has gone to sleep)
18:10:24  <MI6>libuv-node-integration: #265 UNSTABLE smartos-x64 (7/644) smartos-ia32 (5/644) http://jenkins.nodejs.org/job/libuv-node-integration/265/
18:11:12  * mcavagequit (Ping timeout: 248 seconds)
18:11:13  * indexzerojoined
18:14:02  * mcavagejoined
18:14:50  * wwicksquit (Read error: Connection reset by peer)
18:15:09  * wwicksjoined
18:15:23  * st_lukequit (Remote host closed the connection)
18:15:50  * st_lukejoined
18:20:11  * st_lukequit (Ping timeout: 248 seconds)
18:22:11  * st_lukejoined
18:24:00  * defunctzombie_zzchanged nick to defunctzombie
18:30:08  * st_lukequit (Remote host closed the connection)
18:30:35  * st_lukejoined
18:30:56  * dominictarrquit (Remote host closed the connection)
18:31:21  * dominictarrjoined
18:35:12  * st_lukequit (Ping timeout: 248 seconds)
18:35:38  * wwicks_joined
18:37:08  * wwicksquit (Ping timeout: 240 seconds)
18:37:08  * wwicks_changed nick to wwicks
18:41:13  * kazuponquit (Remote host closed the connection)
18:44:07  * c4miloquit (Remote host closed the connection)
18:44:40  * c4milojoined
18:45:23  * c4miloquit (Remote host closed the connection)
18:45:39  * c4milojoined
18:52:27  <MI6>nodejs-master-windows: #398 UNSTABLE windows-x64 (21/644) windows-ia32 (23/644) http://jenkins.nodejs.org/job/nodejs-master-windows/398/
18:53:50  * mcavagequit (Remote host closed the connection)
18:54:16  * mcavagejoined
18:55:08  * mcavage_joined
18:55:08  * mcavagequit (Read error: Connection reset by peer)
18:58:34  <isaacs>ok, got a fix for 6214, just need to write a test for it, and we're golden
19:05:04  <tjfontaine>yay
19:07:58  * amartensquit (Quit: Leaving.)
19:08:32  * bnoordhuisjoined
19:08:58  <bnoordhuis>tjfontaine: https://github.com/joyent/node/issues/5112 <- why?
19:09:20  <bnoordhuis>i've outlined the reasons why installing headers site-wide is a bad, bad idea
19:10:19  <bnoordhuis>and to the people that have special build systems and/or dependencies: boo hoo
19:10:26  <tjfontaine>on the contrary, I think it is far worse to not install headers, and it's a bug that node-gyp downloads from the internet
19:10:31  <tjfontaine>it's not a special buildsystem
19:10:34  <tjfontaine>it's make
19:11:08  <tjfontaine>people should be free to build their addons how they see fit, especially since npm supports it
19:11:27  <tjfontaine>which shouldn't arbitrarily break modules by being a misbheaving software package
19:11:36  <bnoordhuis>especially since npm supports what?
19:11:55  <tjfontaine>pre-install scripts that can perform arbitrary actions to handle their install
19:12:14  <tjfontaine>it's perfectly legitimate for people to not want to have to use gyp for their module installs
19:12:22  <bnoordhuis>so? because npm allows people to do silly things doesn't mean we have to cater to that
19:12:54  <tjfontaine>we're catering to the fact that a proper package would install the headers it needs, just like ruby, python, perl, php, so on and so forth
19:13:12  <tjfontaine>this is crucial for supporting people like debian, ubuntu, fedora
19:13:43  <bnoordhuis>packagers don't care. they just apply a patch to their fork and call it a day
19:14:16  <tjfontaine>why do we need to be contrary on this, we can actually do this with minimal effort and improve the experience for everyone
19:14:32  <tjfontaine>I'm not asking you to do the work, I'm already writing the fix
19:14:38  <bnoordhuis>because it means that now we have two build systems for add-ons
19:15:07  <tjfontaine>no, it means we can fix node-gyp from having to download files it doesn't need to, which improves the experience of people having to build addons against development releases, or in environments without internet
19:15:51  <TooTallNate>tjfontaine: i'd personally like to look into the idea of bundling header files with the node binary
19:15:54  <bnoordhuis>then fix node-gyp to work with a local cache
19:15:57  <TooTallNate>possibly gzipped
19:16:00  <bnoordhuis>^ that
19:16:07  <tjfontaine>TooTallNate: meh, resources like that are kind of insane
19:16:32  <TooTallNate>tjfontaine: can you elaborate?
19:16:40  <TooTallNate>i mean it would solve the problem you're describing i think
19:16:46  <TooTallNate>unless i'm not getting the entire pic
19:17:03  <tjfontaine>TooTallNate: because it doesn't really solve the issue of people building against the shared libraries, whcih we already support in our builds
19:17:14  <tjfontaine>TooTallNate: so if the system upgrades the library independently, the resource we've included is now wrong
19:17:18  <tjfontaine>or at least potentially
19:18:49  <TooTallNate>tjfontaine: well that's a separate issue i think
19:19:36  <tjfontaine>they are all sorts of issues, basically the story is right now, binary addons are just working by accident, I can't wait until someone has a complex project with multiple versions of level
19:19:55  <tjfontaine>anyway, for now I'm going to lunch, enjoy :)
19:20:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:22:49  <bnoordhuis>working by accident, yes. and installing headers system-wide is going to fix that?
19:23:01  <bnoordhuis>rhetorical question because no, it won't
19:23:36  <bnoordhuis>if the sharedness of our dependencies is an issue, then linking them in a way that hides them from add-ons is a much better solution
19:24:00  <bnoordhuis>if an add-on wants to link, say, openssl, it can do so explicitly and get its own copy in the address space
19:29:06  * bnoordhuisquit (Quit: leaving)
19:30:47  * amartensjoined
19:36:04  * bajtosquit (Quit: bajtos)
19:41:14  * st_lukejoined
19:42:46  * c4miloquit (Remote host closed the connection)
19:45:42  * st_lukequit (Ping timeout: 264 seconds)
19:47:28  <trevnorris>afternoon
19:47:39  * bajtosjoined
19:47:47  * bajtosquit (Client Quit)
19:49:25  <trevnorris>Domenic_: what was I interested in?
19:50:46  * st_lukejoined
19:51:39  * kazuponjoined
19:53:43  * c4milojoined
19:54:10  * EhevuTovjoined
19:56:53  * kazuponquit (Ping timeout: 248 seconds)
19:57:13  * dominictarrquit (Quit: dominictarr)
19:58:32  * wwicks_joined
19:59:55  * wwicksquit (Ping timeout: 248 seconds)
19:59:56  * wwicks_changed nick to wwicks
20:01:14  * EhevuTovquit (Quit: This computer has gone to sleep)
20:02:24  * EhevuTovjoined
20:03:15  * dominictarrjoined
20:03:49  * c4miloquit (Remote host closed the connection)
20:04:23  * c4milojoined
20:06:33  * julianduquejoined
20:08:37  * c4miloquit (Ping timeout: 248 seconds)
20:13:15  <trevnorris>indutny: ping
20:13:20  * dominictarrquit (Quit: dominictarr)
20:15:10  * ecrjoined
20:17:00  * st_lukequit (Remote host closed the connection)
20:17:28  * st_lukejoined
20:18:33  * TooTallNatejoined
20:19:07  * piscisaureus_quit (Ping timeout: 248 seconds)
20:22:04  * st_lukequit (Read error: Operation timed out)
20:31:53  <trevnorris>wow, dead.
20:36:22  * bradleymeckquit (Quit: bradleymeck)
20:37:34  * c4milojoined
20:38:30  * bradleymeckjoined
20:45:14  <othiym23>ALIVE, ALIVE-O
20:45:14  <LOUDBOT>IF THE SPIFFY WILLS IT, IT SHALL BE DONE
20:48:09  * c4miloquit (Remote host closed the connection)
21:00:13  * isaacbwpart
21:06:42  * c4milojoined
21:08:36  * bradleymeckquit (Quit: bradleymeck)
21:13:52  * rendarquit
21:23:49  * AvianFluquit (Remote host closed the connection)
21:27:48  * ecrquit (Ping timeout: 240 seconds)
21:32:49  * kevinswiberquit (Remote host closed the connection)
21:33:20  * Kakeraquit (Ping timeout: 248 seconds)
21:33:24  * kevinswiberjoined
21:37:28  * kevinswiberquit (Ping timeout: 240 seconds)
21:38:38  * ecrjoined
21:43:12  * mikealquit (Quit: Leaving.)
21:43:33  * defunctzombiechanged nick to defunctzombie_zz
21:44:44  * ecrquit (Quit: ecr)
21:44:52  * AvianFlujoined
21:45:07  * c4miloquit (Remote host closed the connection)
21:48:56  * mikealjoined
21:59:55  * AvianFluquit (Ping timeout: 248 seconds)
22:15:06  * st_lukejoined
22:19:04  * st_lukequit (Remote host closed the connection)
22:19:42  * st_lukejoined
22:24:27  * st_lukequit (Ping timeout: 265 seconds)
22:30:39  * c4milojoined
22:32:48  * c4miloquit (Remote host closed the connection)
22:33:21  * c4milojoined
22:37:52  * c4miloquit (Ping timeout: 248 seconds)
22:39:36  * st_lukejoined
22:45:41  <MI6>joyent/node: Dave Pacheco v0.10 * 720675e : test: use proper findjsobjects output format - http://git.io/T6sOLQ
22:46:30  * kazuponjoined
22:49:20  * sblomjoined
22:53:47  * st_lukequit (Ping timeout: 248 seconds)
22:55:42  <MI6>nodejs-v0.10: #1529 UNSTABLE smartos-x64 (5/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1529/
23:03:44  * kazuponquit (Remote host closed the connection)
23:06:05  <trevnorris>tjfontaine: ping
23:06:24  <MI6>nodejs-v0.10-windows: #255 UNSTABLE windows-ia32 (10/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/255/
23:25:55  * indexzeroquit (Quit: indexzero)
23:27:29  <tjfontaine>trevnorris: pong
23:29:03  <trevnorris>tjfontaine: have we created a #nodejs-sec room w/ a passphrase where we can discuss security related stuff?
23:29:34  <tjfontaine>trevnorris: what if we just used security@nodejs.org
23:30:17  <trevnorris>tjfontaine: that's useful, but want a place for active discussion, and hate using email threads for that
23:30:37  <tjfontaine>trevnorris: the threads provide useful context for people who don't necessarily use persistent connections (like bert and ben)
23:31:08  <tjfontaine>trevnorris: an alternative would be to schedule a meeting time for the conversation
23:31:18  <trevnorris>...
23:32:12  <tjfontaine>trevnorris: I mean we can create the channel and talk about it, but it's not really helpful for the people who aren't always around
23:32:31  <trevnorris>tjfontaine: will security@nodejs.org make it to everyone?
23:33:00  <tjfontaine>trevnorris: all the existing core contributors yes, but I will double check
23:34:18  <tjfontaine>trevnorris: yes, all users are on the list, we can send out a ping to make sure everyone responds
23:34:58  <tjfontaine>you know, when they're awake :)
23:38:09  <trevnorris>tjfontaine: just sent an email to security@nodejs.org. let me know if you get it.
23:41:06  <tjfontaine>trevnorris: yes, I did
23:41:25  <trevnorris>tjfontaine: either it knows that I sent it, or I'm not on the list.
23:41:44  <tjfontaine>it knows that you sent it
23:41:47  <tjfontaine>google knows all
23:41:53  <trevnorris>haha, of course
23:42:53  <tjfontaine>trevnorris: fwiw it would be helpful if you asked more direct questions :)
23:43:21  * austoquit (Quit: Leaving)
23:44:37  <trevnorris>tjfontaine: there.
23:44:51  <tjfontaine>hahah, thanks
23:48:37  * Benviequit (Remote host closed the connection)
23:48:53  * Benviejoined
23:56:56  * dapquit (Quit: Leaving.)
23:59:26  <MI6>libuv-master-gyp: #220 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/220/