00:05:24  <mike-d>Raynos: sure, i'm a forty+ c hacker so i'm still trying to get my head around all this, it actually freaks me out a little when I look at code and don't see any logic, it's like i'm mostly looking at code that's just wrapping other code, still getting used to it
00:06:14  <Raynos>mike-d: you'll like airport
00:06:17  <Raynos>its nicely layerd
00:07:56  <Raynos>isaacs: I want to optimize npm search. Is there anything I can do in npm itself to make it faster or will this be user land
00:08:01  <mike-d>I really enjoy low level code, one thing that sold me on node was the lack of an AST, plus for web we have no real options and I hate big things
00:09:36  <mike-d>Raynos: thanks for your time, gonna take a break
00:09:45  <Raynos>mike-d: btw are you in the bay area?
00:10:13  <mike-d>Raynos: i'm in Florida
00:10:14  <Raynos>ah ok
00:10:31  <mike-d>very close to the ocean
00:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 21]
00:29:29  * st_lukejoined
00:42:03  * ITprojoined
01:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 13]
01:41:01  * st_lukequit (Remote host closed the connection)
01:51:49  <mike-d>Raynos, Isaacs: any linked info I can read up on for the new 0.9.x stream API?
01:58:42  <Raynos>mike-d: https://gist.github.com/3791742
01:59:07  <Raynos>mike-d: https://github.com/Raynos/read-stream https://github.com/Raynos/write-stream https://github.com/Raynos/read-write-stream
02:02:07  <Raynos>mike-d: most importantly https://github.com/isaacs/readable-stream
02:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 15]
03:04:01  <rowbit>SubStack, pkrumins: Someone's waiting in the queue for undefined/undefined
03:14:30  * tomshredsjoined
03:20:01  <rowbit>Hourly usage stats: [developer: 27, free: 13]
03:38:55  * tomshredsquit (Quit: Leaving...)
03:56:59  * ITproquit (Ping timeout: 245 seconds)
03:57:13  <Raynos>isaacs: npm is a pain to use programmatically. I must be missing the "use it exactly this way or deal with all the edge cases yourself" document
04:20:01  <rowbit>Hourly usage stats: [developer: 19, free: 10]
04:26:29  * mike-dquit (Quit: mike-d)
04:32:59  * tomshredsjoined
04:39:09  * simcop2387quit (Excess Flood)
04:41:42  * simcop2387joined
04:47:31  * tomshredsquit (Quit: Leaving...)
05:20:01  <rowbit>Hourly usage stats: [developer: 17, free: 38]
05:58:59  <Raynos>https://gist.github.com/3809709
06:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 17]
06:34:55  * ITprojoined
07:01:29  * ITproquit
07:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 49]
07:38:18  * substackawake
07:38:44  <substack>dominic_ZZZZ: so I met somebody studying informatics who is very into music also and did a baudio-party demo
07:39:04  * dominic_ZZZZchanged nick to dominictarr
07:39:13  <dominictarr>substack, awesome!
07:40:03  <dominictarr>mbergman gave me a crazy idea to make a distributed realtime frame work aimed at kids.
07:40:04  <substack>also a group of brazilians was doing some music and dancing it was great
07:40:19  <substack>and a guy was playing a guitar that was missing some strings with a violin bow
07:40:19  <dominictarr>dancing to baudio?
07:40:32  <dominictarr>oh cool, where was this?
07:40:39  <substack>no to some brazilian songs
07:40:50  <dominictarr>aha,
07:40:56  <substack>they had some drums and a ukelele
07:41:02  <substack>at the oasis hostel last night
07:41:04  <substack>crazy place
07:41:41  <substack>had it recommended to me by somebody at the conf
07:41:55  <Raynos>dominictarr: https://github.com/Raynos/npm-used
07:42:21  <substack>Raynos: I love the idea of a hackedy for distributed computing
07:42:40  <Raynos>substack, dominictarr: I like the idea of "distributed made simple"
07:42:44  <mbalho>wat is hackedy
07:43:03  <substack>_why's book
07:43:19  <substack>slash interactive guide
07:43:19  <substack>http://hackety.com/
07:43:49  <mbalho>i thought hackety hack was a programming environment only, didnt know it was a book
07:44:17  <mbalho>but yea a distributed computing made simple text would rule
07:44:21  <mbalho>distributedcomputingforcats.com
07:44:53  <mbalho>(i am offering keys to the *forcats.com empire if anyone would like to contribute to the kingdoms livelihood)
07:44:54  * AvianFluquit (Remote host closed the connection)
07:45:48  <substack>I had a dream where I got stopped by a busybody at immigration between countries
07:45:51  <dominictarr>mbalho, haha, great.
07:45:52  <Raynos>mbalho: oh your max ogden
07:45:56  <Raynos>why you do tis.
07:46:31  <substack>he stopped me because he "looked me up" and "found a bunch of hacking materials"
07:46:50  <mbalho>lol
07:46:52  <substack>my dream self is really good at making smarmy idiot characters
07:48:05  <dominictarr>there is some other thing too, shoes
07:48:09  <dominictarr>http://shoesrb.com/
07:48:24  <dominictarr>which is like a really simple ui thing
07:49:53  <dominictarr>but like, with some simple stuff + crdt, etc,
07:50:00  <dominictarr>you can make a little toy app
07:50:09  <Raynos>distributed programming isn't that hard
07:50:14  <Raynos>I mean
07:50:22  <Raynos>you cant really do anything
07:50:24  <Raynos>other then use crdt
07:50:26  <dominictarr>and then be like get you friends to visit a link, and then you are both using it
07:50:28  <Raynos>and run multiple nodes
07:50:29  <substack>distributed computing is very hard
07:50:35  <dominictarr>substack, NO
07:50:38  <dominictarr>it's easy
07:50:38  <substack>but it's the kind of hard where you can solve it once and for all
07:50:43  <substack>with libraries
07:50:51  <Raynos>The point is.
07:50:57  <Raynos>All they can do is share state using crdt
07:50:59  <Raynos>and do GUI stuff
07:50:59  <dominictarr>it's easy when you start with the right assumptions.
07:51:03  <Raynos>so its just real time GUI stuff
07:51:22  <Raynos>there isnt any option to try different distributed strategies or libraries
07:51:45  <Raynos>"Can I share data in a distributed fashion? Yes. Ok distributed part of my app is done now"
07:53:33  <dominictarr>you could use a few other things, that make more sense for what it is.
07:55:27  <Raynos>maybe what you want
07:55:34  <Raynos>is to visualize data travelling through nodes
07:55:41  <Raynos>turn it into a game
07:55:52  <Raynos>"You joined a network. Now try and build a distributed path to your friend"
07:56:07  <Raynos>"here are some distributed network connecting options"
07:56:29  <dominictarr>but don't use big words like "distributed"
08:02:05  <mbalho>npm install (the programmatic api) returns this:
08:02:08  <mbalho>[ [ '[email protected]','node_modules/android-statusbarnotification','','','android-statusbarnotification' ] ]
08:02:29  <mbalho>i wonder what 2 and 3 are?
08:02:32  <mbalho>isaacs: o/
08:02:42  <mbalho>(tried looking in the npm code but it is too abstract)
08:02:53  <mbalho>also Y U NO USE OBJECTS?!?
08:05:30  <mbalho>AHHAH var parentDir = r[3], parent = r[2], where = r[1], what = r[0], from = r[4]
08:20:01  <rowbit>Hourly usage stats: [developer: 1, free: 48]
08:28:06  * dominictarrquit (Ping timeout: 252 seconds)
08:32:00  <Raynos>mbalho: arrays are more efficient!
08:32:16  <Raynos>mbalho: Especially when using an array pool
09:05:48  * jibayjoined
09:11:20  <substack>I'm at the gat rossio but nobody is here
09:11:30  <substack>fuck this happened yesterday too at browns cafe
09:20:01  <rowbit>Hourly usage stats: [developer: 1, free: 38]
10:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 32]
11:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 38]
12:20:01  <rowbit>Hourly usage stats: [developer: 0, free: 26]
12:51:26  * shuaibjoined
13:14:58  * shuaibquit (Quit: Textual IRC Client: http://www.textualapp.com/)
13:20:01  <rowbit>Hourly usage stats: [developer: 1, free: 46]
13:34:43  * tomshredsjoined
13:36:12  * tommybergeronjoined
13:37:19  * tommybergeronquit (Client Quit)
13:39:04  * tomshredsquit (Ping timeout: 245 seconds)
13:42:18  * tomshredsjoined
13:48:10  * shuaibjoined
13:53:09  * AvianFlujoined
14:19:04  * wiwilliajoined
14:20:06  <rowbit>Hourly usage stats: [developer: 5, free: 30]
14:52:29  * shuaibquit (Quit: Textual IRC Client: http://www.textualapp.com/)
15:00:07  * mikealjoined
15:16:08  * _sorensenjoined
15:20:01  <rowbit>Hourly usage stats: [developer: 3, free: 43]
15:29:58  * mikealquit (Quit: Leaving.)
15:38:26  <isaacs>mbalho: <shrug>. objects would be fine.
15:38:37  <isaacs>mbalho: feel free to refactor. i'm not super happy with basically any of the code in npm.
15:38:57  <isaacs>it's all garbage and bullshit and kludges that have grown organically like so much mold over a bread that wasnt' very good to begin with.
15:40:38  <isaacs>Raynos: using it programmatically isn't all that bad.
15:40:50  <isaacs>Raynos: how are you planning on implementing search? i'm curious about what kind of optimizations you'd like to do.
15:41:16  <isaacs>Raynos: if you make it much better, then it belongs in npm. if you can build your thing in such a way that npm can use it, then that'd be the optimum path, i think
15:47:29  <pkrumins>oh a bug in monitor
15:47:44  <pkrumins>< rowbit> SubStack, pkrumins: Someone's waiting in the queue for undefined/undefined
15:47:47  <pkrumins>undef/undef
16:00:34  * mikealjoined
16:03:29  * mikeal1joined
16:05:15  * mikealquit (Ping timeout: 255 seconds)
16:05:55  <isaacs>Raynos: ping me when you're around and have a sec. i'd like to bounce some transform-stream ideas off of your head.
16:07:10  * mikeal1quit (Client Quit)
16:11:31  * AvianFluquit (Read error: Connection reset by peer)
16:11:54  * AvianFlujoined
16:20:01  <rowbit>Hourly usage stats: [developer: 13, free: 32]
16:20:24  * tphummeljoined
16:22:14  * mike-djoined
16:25:16  <isaacs>substack: i hear your cries re: duplexes.
16:25:25  <isaacs>substack: we're fixing this at its root.
16:25:43  <isaacs>writables will never emit 'end'. end will only ever be a readable feature.
16:30:47  <Raynos>isaacs: The only thing I can think about to make npm search better is what TJ did. Index every single possible word into redis and have an O(1) lookup
16:31:10  <isaacs>Raynos: that's kind of expensive.
16:31:17  <isaacs>Raynos: but not unreasonable
16:31:34  <Raynos>well you do it once
16:31:41  <Raynos>and then run an hourly cron job to hit the all route
16:31:46  <Raynos>and update redis
16:31:52  <isaacs>no, you listen on the _changes feed
16:32:00  <isaacs>the expensive bit is that now we have to have this redis thing
16:32:08  <isaacs>npm search needs to be clever enough to know where to go for search info's.
16:32:17  <isaacs>ie, the registry, or to the redis thing
16:32:22  <isaacs>or maintain a local redis install? ugh.
16:32:32  <isaacs>i've considered sqlite, but that's also painful
16:32:36  <Raynos>I thought the expensive bit was the sheer amount of data in redis
16:32:47  <isaacs>nah, that's just a matter of having a lot of ram
16:32:53  <isaacs>the db is only 16gb
16:32:56  <Raynos>I can actually just tell TJ
16:33:01  <Raynos>to take his npm-search thing
16:33:03  <isaacs>and the word indexes is way less than that
16:33:04  <Raynos>and keep it upto date
16:33:33  <isaacs>the problem though -- and maybe this isn't too much of a problem really -- is that there's no way to do that for private registries
16:34:10  <Raynos>sure there is
16:34:13  <isaacs>but there could be some way to maybe forward responses from the /-/all route to a redis thing, and if you don't have that set up, then i'll just dump what it does now
16:34:20  <isaacs>and the client will just make do
16:34:37  <Raynos>well im thinking of just having an opt in redis cache flag
16:34:52  <isaacs>so, the npm client does /-/all/?since=12345678090&terms=yabba+dabba+doo
16:34:52  <Raynos>where it hits redis
16:35:06  <isaacs>and the couch proxies or something?
16:35:08  <isaacs>i duno
16:35:16  <Raynos>because I wont trust my clever search to be correct :P
16:35:53  <Raynos>isaacs: did you see https://github.com/Raynos/npm-used ?
16:35:56  <isaacs>oic, so you'd have something like npm search yabba dabba doo --redisregistry=http://blahblah:1234
16:35:59  <isaacs>or something?
16:36:03  <Raynos>I'm going to update that to allow you to search among those.
16:36:21  <Raynos>I think being able to search in "all the modules that these authors own AND all the modules they have ever used"
16:36:29  <Raynos>is a way to remove noise from heavy searches
16:37:20  * mikealjoined
16:38:43  <isaacs>Raynos: so, what do you think about this.transform = function (chunk, emit, done)
16:38:57  <Raynos>its good
16:39:00  <isaacs>Raynos: call emit() with output, call done() when you've fully consumed that chunk.
16:39:08  <isaacs>the problem is, of course, that emit() already has a meaning
16:39:17  <isaacs>function (chunk, output, done)?
16:39:18  <isaacs>maybe?
16:39:20  <Raynos>https://github.com/Raynos/chain-stream/blob/master/index.js#L24
16:39:30  <Raynos>I've added it to my crazy stream chaining
16:39:36  <Raynos>I like (chunk, write, end)
16:39:57  <isaacs>right
16:39:59  <Raynos>because it makes you think that actually your being a writable stream for every chunk
16:40:19  <Raynos>you could even do back pressure
16:40:19  <isaacs>wait, so write, that's a method or an object?
16:40:24  <Raynos>and have write return false :P
16:40:42  <isaacs>i think that's too clever
16:40:56  <Raynos>to say "the buffer is above the high watermark of this transform stream stop transforming"
16:41:00  <isaacs>txstream.write() will return false if there's stuff waiting to be processed in the write buffer
16:41:14  <isaacs>or if there's anything waiting to be consumed in the read buffer
16:41:29  <isaacs>calling the output(newChunk) function will just put it in the read buffer, and maybe emit 'readable'
16:41:33  <Raynos>write and end are the same as emit and done
16:41:45  <isaacs>ight
16:41:47  <isaacs>right
16:41:55  <isaacs>but, the names need to be less confusing.
16:41:58  <Raynos>I was actually thinking of writing this myself
16:42:07  <isaacs>i need this in node-core.
16:42:14  <isaacs>i need this for crypto and zlib
16:42:41  <Raynos>then you should write it :P
16:43:06  <Raynos>i think the harder problem
16:43:18  <Raynos>is having a clean way to move data from one transform callback to another
16:43:31  * mikealquit (Ping timeout: 260 seconds)
16:43:34  <isaacs>what do you mean?
16:43:40  <Raynos>"this is the rest of the buffer that I cant process. The next callback should append it to whatever his chunk is an process it"
16:43:54  <Raynos>https://github.com/dominictarr/split/blob/master/index.js#L16
16:44:01  <Raynos>Like split has a running "soFar" counter
16:44:01  <isaacs>oh, that is all implementation-specific, though
16:44:25  <Raynos>I guess you can use reductions for that
16:44:43  <isaacs>the reason why the writable watermark and buffer and bs is all on the _writableState obj, and similar for readable stuff on _readableState, is so that "this.buffer" can be whatever the hell you want it to be.
16:44:47  <Raynos>oh and returning false in the transformation callback
16:44:51  <Raynos>should make write return false
16:44:55  <isaacs>the core readable/writable API surface is thus pretty minor.
16:45:08  <isaacs>no, the transformation callback's return cannot be relevant.
16:45:11  <isaacs>it doesn't happen right away.
16:45:17  <isaacs>it happens some day in the distant future
16:45:24  <isaacs>many millions of clock cycles from now
16:45:38  <isaacs>seconds. SECONDS!!
16:45:41  <Raynos>then a transformation stream has no way to do back pressure
16:45:53  <isaacs>the back pressure is based on how much of its input buffer has been consumed.
16:46:03  <isaacs>same as any writable stream
16:46:10  <Raynos>what if the transformation stream's implementation is "push it into the job queue unless there are 100 items in the job queue. If there are a 100 then backpressure"
16:46:15  <isaacs>a tx stream is just a writable stream who's _write() method does thte transform stuff
16:46:28  <isaacs>Raynos: then it just doesn't call done() until it's ready
16:46:38  <Raynos>oh
16:46:43  <isaacs>and it won't get another transform(chunk,output,done) call until it calls done()
16:46:47  <Raynos>done() is used to say "do the next chunk"
16:46:56  <isaacs>it's a way to say "i'm done with this chunks now"
16:46:56  <Raynos>in my case done() is just to buffer the end event
16:47:02  <isaacs>yeah, no
16:47:04  <Raynos>and all the transforms come as fast as possible
16:47:12  <isaacs>nono, that will definitely not work for me.
16:47:17  <isaacs>that assumes that transforms are immediate.
16:47:23  <Raynos>no
16:47:26  <isaacs>you can safely assume that they're never immediate in any interesting case.
16:47:29  <Raynos>it assumes that transforms are parallel
16:47:31  <Raynos>and commutative
16:47:35  <isaacs>oh, god, even worse
16:47:44  <isaacs>zlib doesn't work that way.
16:47:51  <isaacs>you have to go end to end in an orderly fashion
16:48:00  <isaacs>same with crypto
16:48:01  <Raynos>but any transform stream that tkaes line buffered JSON
16:48:17  <Raynos>would work fine like that. For example es.parse()
16:48:20  <isaacs>JSON is an immediate in-memory operation
16:48:29  <Raynos>true/
16:48:29  <isaacs>it's the exception.
16:48:39  <isaacs>but even an interruptible parser needs to get its data in order.
16:48:47  <Raynos>there are other async examples where they can be done parallel and commutatively
16:48:57  <isaacs>right, but they're not really relevant here.
16:49:25  <Raynos>nope.
16:49:30  <isaacs>the vast majority of "foo.pipe(bar).pipe(baz)" calls in production nodejs code will break in subtle yet intense ways if order is not preserved.
16:49:31  <Raynos>your doing much lower level stuff
16:50:06  <isaacs>yeah, so: stream.transform(chunk, callToPassOutputToReadableSide, callWhenDoneWithThisChunkOrAnErrorOccurs)
16:50:24  <isaacs>i'm thinking of making it _transform just to make it clear that this is an internal function that should not be called directly.
16:50:29  <isaacs>a la _write/_read
16:50:36  <Raynos>seems sensible
16:50:43  <Raynos>will it be on Readable or Writable
16:50:46  <Raynos>or a seperate base class?
16:50:51  <Raynos>I guess it has to be seperate
16:51:00  <isaacs>it'll be a separate base class that inherits from Readable, and parasites from Writable
16:51:13  <isaacs>and calls both ctors
16:51:25  <Raynos>the alternative to that api
16:51:31  <Raynos>is the transform(chunk, next) API
16:51:35  <Raynos>where you do next(null)
16:51:38  <Raynos>to signify end
16:51:48  <isaacs>then what, next(outputChunk) to pass output?
16:52:03  <isaacs>what about if i don't have output yet, but i'm done with this chunk, and don't want to end?
16:52:12  <isaacs>next(new Buffer(0))?
16:52:21  <isaacs>seems kinda unsatisfactory
16:54:09  <isaacs>we explored that a few years ago, but it kind of didnt' ever really work out in real situations.
16:54:41  <isaacs>new Transform(function(chunk, output) { ... call output(null) when done, or output(outChunk) for output ... })
16:54:56  <isaacs>but it is a huge pita to get zlib into that shape nicely
16:54:59  * mikealjoined
16:55:46  * shuaibjoined
17:02:36  * tphummelquit (Ping timeout: 240 seconds)
17:07:53  <Raynos>isaacs: dont call next at all
17:08:15  <Raynos>why call it with an empty buffer
17:08:17  <isaacs>Raynos: but then how do you get another chunk?
17:08:25  <Raynos>oh wait
17:08:32  <Raynos>next gives you a next chunk?
17:08:33  <isaacs>Raynos: the way zlib works, when compressing, is that you frequently dont' get any output
17:08:35  <Raynos>and end ends the entire thing?
17:09:02  <isaacs>Raynos: i'm trying to figure out how transform(chunk,next) works in that case.
17:09:10  <isaacs>Raynos: with async asymmetric io
17:09:28  <isaacs>ie, write 1 chunk, and get 10 chunks of output, or write 10 chunks and get 1 chunk of output
17:09:32  <Raynos>in my transform. it's a one to many transformation. you get one chunk. you call next 0 to n times for that chunk. you call end to say "there are no more transformations for THIS chunk"
17:09:34  <isaacs>that means that you have 9 writes that don't call next?
17:09:49  <isaacs>Raynos: but... you're only passing one function in...
17:09:56  <Raynos>well
17:10:04  <Raynos>next(null) 9 times
17:10:05  <isaacs>Raynos: transform(chunk,next) /* where's 'end'? */
17:10:08  <Raynos>and then next(output)
17:10:13  <Raynos>end is next(null)
17:10:14  <isaacs>but next(null) means emit('end')?
17:10:21  <Raynos>no
17:10:30  <Raynos>End is a poorly phrased word
17:10:34  <isaacs>ok, so, it just emits'end' when there's no more output (because there's no more input coming)
17:10:48  <isaacs>i got 99 problems and the ability to count problems is probably most of them.
17:11:11  <Raynos>it's transformation(chunk, transformed, done)
17:11:11  <Raynos>for the 1 -> 10 case
17:11:11  <isaacs>you have to be very precise about semantics around streams :)
17:11:11  <Raynos>call transformed 10 times
17:11:18  <isaacs>then call done()
17:11:23  <Raynos>then call done to say "give me the next chunk or end cleanly if there are no more chunks"
17:11:35  <Raynos>for the 10 -> 1 case you call done 9 times then transformed once then done
17:11:53  <isaacs>right
17:11:57  <isaacs>so, i think we're on the same page here
17:12:07  <Raynos>and of course you can overload transformed
17:12:09  <isaacs>it's just a matter of naming it so that it's clear when reading the code.
17:12:15  <isaacs>i'd rather just have two functions
17:12:19  <isaacs>one is a callback, one is a emit
17:12:28  <Raynos>to be function transformed(x) { if (x === null) { return done() } else { ... } }
17:12:37  <isaacs>because i also want to be able to do done(error)
17:12:44  <Raynos>ah
17:12:45  <isaacs>if there's an error in the underlying system
17:12:53  <isaacs>so it's literally a cb style function
17:12:55  <Raynos>why do done(error)
17:13:01  <Raynos>instead of this.emit("error", err)
17:13:23  <isaacs>because that means that you can pass done to some other function that takes a cb
17:13:39  <isaacs>thats how _write(chunk, cb) and _read(n, cb) work
17:13:44  <Raynos>clever
17:13:49  <isaacs>so, there's a symmetry there
17:13:56  <isaacs>_transform(chunk, output, cb)
17:14:02  <Raynos>you could also just have _transform(chunk, cb)
17:14:07  <Raynos>where its cb(err, array)
17:14:13  <isaacs>right, and call cb(er, [chunks,...])
17:14:16  <Raynos>but then you have to build an array
17:14:19  <isaacs>yeah
17:14:22  <isaacs>but that's not actually so bad.
17:14:34  <isaacs>it's just inefficient
17:14:53  <isaacs>in the 1->10 case, you'd like the reader to be able to consume them right awa
17:14:55  <isaacs>y
17:15:03  <isaacs>otherwise you're buffering twice, which is kinda sily
17:15:31  <isaacs>those chunks could be going out the tcp socket while you're waiting for zlib to compute some more lzw
17:20:01  <rowbit>Daily usage stats: [developer: 106, free: 859]
17:20:02  <rowbit>Hourly usage stats: [developer: 13, free: 39]
17:23:09  * shuaibquit (Ping timeout: 240 seconds)
17:25:17  * shuaibjoined
17:26:36  * mikealquit (Quit: Leaving.)
17:40:59  <pkrumins>Announcing Monthly Catonmat Geek T-Shirts!
17:41:03  <pkrumins>http://www.catonmat.net/blog/announcing-monthly-catonmat-geek-tshirts/
17:48:21  * tphummeljoined
18:00:18  * mikealjoined
18:06:56  * mikealquit (Ping timeout: 260 seconds)
18:20:03  <rowbit>Hourly usage stats: [developer: 2, free: 36]
19:14:57  * tphummelquit (Quit: tphummel)
19:20:01  <rowbit>Hourly usage stats: [developer: 1, free: 34]
19:40:53  <substack>isaacs: great news @ duplex streams
20:01:11  * ryan_stevensjoined
20:07:02  * tphummeljoined
20:10:44  * tomshredsquit (Ping timeout: 245 seconds)
20:11:36  * tphummelquit (Ping timeout: 256 seconds)
20:12:35  <Raynos>substack: duplex streams?
20:13:53  * mikealjoined
20:14:21  * zz_shykeschanged nick to shykes
20:15:46  * tphummeljoined
20:20:01  <rowbit>Hourly usage stats: [developer: 2, free: 46]
20:26:56  * shuaibquit (Ping timeout: 240 seconds)
20:28:21  * shuaibjoined
20:30:48  * st_lukejoined
20:37:05  * st_lukequit (Remote host closed the connection)
20:37:16  * st_lukejoined
20:40:59  * mike-dquit (Quit: mike-d)
21:05:33  <isaacs>Raynos: the fact that pipe unhooks on dest.on('end')
21:05:53  <isaacs>Raynos: so, if dest is a duplex, it might not be time to do that yet
21:06:04  <isaacs>since you're confusing the writable end with the readable end
21:06:14  <isaacs>same reason why i needed _writableState and _readableState instead of a bunch of things
21:07:30  <Raynos>isaacs: Agreed. That's sensible.
21:07:45  <Raynos>isaacs: do you know what else is cool. You can write your own pipe implementation.
21:08:02  <isaacs>yeah, but it's dumb to have to
21:08:05  <Raynos>readable and writable are better primitives for writing your own pipe
21:08:09  <Raynos>isaacs: no it's not.
21:08:25  <Raynos>remember dominictarr's distrinction between squirt and straw streams
21:08:25  <isaacs>i mean, if your streams are emitting and receiving chunks of strings/buffers, then it's dumb
21:08:40  <Raynos>pipe determines how chunks flow and how back pressure is handled
21:08:46  <isaacs>i think it was something like suck, swallow, and squirt.
21:08:47  <Raynos>there are other ways for things to flow
21:08:58  <isaacs>kind of verging on some nsfw implications..
21:15:04  <Raynos>isaacs: ಠ_ಠ
21:15:25  <isaacs>speaking of which, check out this passthrough hotnes: https://gist.github.com/3814458
21:15:42  <isaacs>mute-stream is about to become 5 lines
21:15:45  <isaacs><3 this
21:20:01  <rowbit>Hourly usage stats: [developer: 3, free: 33]
21:33:04  * tilgovijoined
21:34:46  * tilgoviquit (Excess Flood)
21:35:01  * tilgovijoined
21:43:17  <isaacs>Raynos: hmm... found another edge case for transform streams.. this is a good one.
21:44:11  <isaacs>Raynos: how does the logic in my _transform method know when the writable side ends?
21:44:43  <isaacs>Raynos: like, if i'm compressing, at some point, you're gonna say "end()", and i might have some state that needs to flush
21:44:50  <isaacs>but withoput you writing another chunks
21:45:26  <isaacs>maybe call _transform(null, output, cb)_?
21:47:43  <isaacs>it needs some way to know when to flush
22:03:14  * tilgoviquit (Ping timeout: 256 seconds)
22:20:02  <rowbit>Hourly usage stats: [developer: 7, free: 25]
22:40:48  * st_lukequit (Remote host closed the connection)
22:52:42  <rowbit>SubStack, pkrumins: These encoders are STILL down:
22:59:48  <rowbit>/!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\
22:59:48  <rowbit>/!\ ATTENTION: (default-local) paid account successfully upgraded /!\
23:01:36  <pkrumins>hmm rowbit shouldnt be telling me servers are STILL down
23:01:59  <pkrumins>but cash money messages always welcome
23:13:55  * saijanai_joined
23:13:56  * saijanai_quit (Excess Flood)
23:15:31  * shykeschanged nick to zz_shykes
23:20:01  <rowbit>Hourly usage stats: [developer: 11, free: 19]
23:21:31  * zz_shykeschanged nick to shykes
23:34:52  * _sorensenquit (Ping timeout: 252 seconds)
23:40:52  * mike-djoined
23:43:06  * mike-dquit (Client Quit)
23:56:57  <rowbit>/!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\
23:56:57  <rowbit>/!\ ATTENTION: (default-local) paid account successfully upgraded /!\
23:58:07  <pkrumins>more please