00:00:09  * ircretaryjoined
00:06:08  * rakmquit (Quit: Connection closed for inactivity)
00:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 16]
00:28:58  * AvianPhonequit (Remote host closed the connection)
00:29:27  * AvianFlujoined
00:30:31  * tilgoviquit (Remote host closed the connection)
00:36:58  * thlorenzjoined
00:37:53  * kumavisjoined
00:38:17  * contraha_quit (Quit: Sleeping)
00:39:53  * contraha_joined
00:41:53  * thlorenzquit (Remote host closed the connection)
00:42:13  * thlorenzjoined
00:45:51  * ednapiranhajoined
01:04:25  * ednapiranhaquit (Remote host closed the connection)
01:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 25]
01:31:58  * taterbasejoined
01:40:37  * wolfeidauquit
02:02:47  * AvianFluquit (Remote host closed the connection)
02:15:28  * wolfeidaujoined
02:18:13  * kumavisquit (Ping timeout: 250 seconds)
02:20:29  * kumavisjoined
02:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 14]
02:29:00  * jxsonjoined
02:49:06  * thlorenzquit (Remote host closed the connection)
02:54:55  * kumavisquit (Quit: Textual IRC Client: www.textualapp.com)
03:09:38  * phatedquit (Remote host closed the connection)
03:10:02  * kumavisjoined
03:13:50  * thlorenzjoined
03:18:11  * kriskowaljoined
03:20:43  * thlorenzquit (Remote host closed the connection)
03:25:23  * kumavisquit (Ping timeout: 250 seconds)
03:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 15]
03:36:52  * jxsonquit (Remote host closed the connection)
03:37:34  * kumavisjoined
03:46:59  * phatedjoined
03:52:19  * jxsonjoined
03:55:17  * ednapiranhajoined
04:08:30  * phatedquit (Remote host closed the connection)
04:12:50  <rowbit1>substack, pkrumins: These encoders are STILL down: 50.56.27.70(dev-ie6-1), 50.57.171.229(dev-ie6-2), 184.106.99.27(dev-ie7-3)
04:21:04  * dguttmanjoined
04:24:07  * dguttmanquit (Client Quit)
04:24:46  * jxsonquit (Remote host closed the connection)
04:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 21]
04:34:32  * dguttmanjoined
04:42:47  * mikolalysenkoquit (Quit: Lost terminal)
04:46:35  * phatedjoined
04:46:48  * phatedquit (Remote host closed the connection)
05:00:21  * dguttmanquit (Quit: dguttman)
05:03:51  * dominic_joined
05:04:30  * ednapiranhaquit (Quit: Leaving...)
05:25:52  * kirbysayshiquit (Quit: Leaving...)
05:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 23]
05:31:16  * contraha_quit (Quit: Sleeping)
05:35:10  * phatedjoined
05:46:39  * Maciek416quit (Remote host closed the connection)
05:54:49  * contraha_joined
05:59:37  * thealphanerdjoined
05:59:55  * thealphanerdquit (Client Quit)
06:00:11  * thealphanerdjoined
06:07:30  * fotoveritequit (Quit: fotoverite)
06:13:01  * thealphanerdquit (Quit: thealphanerd)
06:26:51  <rowbit1>Daily usage stats: [developer: 10, free: 436]
06:26:52  <rowbit1>Hourly usage stats: [developer: 1, free: 26]
06:28:26  * dominic_quit (Ping timeout: 240 seconds)
06:33:00  * brianloveswordsjoined
06:37:40  * thealphanerdjoined
06:52:50  * ins0mniajoined
07:10:06  * jiangplu1quit (Quit: leaving)
07:10:20  * jiangplusjoined
07:24:09  * kumavisquit (Ping timeout: 252 seconds)
07:26:52  <rowbit1>Hourly usage stats: [developer: 1, free: 26]
07:35:26  * Maciek416joined
07:39:38  * Maciek416quit (Ping timeout: 240 seconds)
07:41:33  * brianloveswordsquit (Quit: Computer has gone to sleep.)
08:00:43  * addisonjquit (Quit: Connection closed for inactivity)
08:01:41  * phatedquit (Remote host closed the connection)
08:19:18  * thealphanerdquit (Quit: thealphanerd)
08:26:51  <rowbit1>Hourly usage stats: [developer: 4, free: 46]
08:56:57  * contraha_quit (Quit: Sleeping)
09:24:15  * Maciek416joined
09:26:51  <rowbit1>Hourly usage stats: [developer: 1, free: 86]
09:28:26  * Maciek416quit (Ping timeout: 240 seconds)
09:46:28  * yorickjoined
10:05:30  * dominic_joined
10:12:51  <rowbit1>substack, pkrumins: These encoders are STILL down: 50.56.27.70(dev-ie6-1), 50.57.171.229(dev-ie6-2), 184.106.99.27(dev-ie7-3)
10:26:51  <rowbit1>Hourly usage stats: [developer: 0, free: 45]
10:38:24  * AvianFlujoined
11:00:45  * taterbasequit (Quit: Connection closed for inactivity)
11:13:03  * Maciek416joined
11:14:40  * _mattjoined
11:17:30  * Maciek416quit (Ping timeout: 240 seconds)
11:17:53  * _mattquit (Client Quit)
11:21:13  * calvinmetcalfjoined
11:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 27]
11:55:56  <dominic_>feross: hey, when do you get to budapest?
12:00:26  * fotoveritejoined
12:02:12  * phatedjoined
12:07:02  * phatedquit (Ping timeout: 255 seconds)
12:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 46]
12:50:42  * kenperkinsquit (Ping timeout: 240 seconds)
12:54:43  * kenperkinsjoined
12:58:40  * thlorenzjoined
13:01:57  * Maciek416joined
13:06:53  * Maciek416quit (Ping timeout: 264 seconds)
13:21:15  * dominic_quit (Ping timeout: 276 seconds)
13:22:06  * thlorenzquit (Remote host closed the connection)
13:23:59  * kevino80joined
13:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 46]
13:31:03  <rwaldron>A Johnny-Five user just filed an issue with an error that I've never seen before: https://github.com/rwaldron/johnny-five/issues/325
13:31:16  <rwaldron>I searched joyent/node issues for anything similar and came up with nothing.
13:31:44  * ednapiranhajoined
13:34:15  * thlorenzjoined
13:36:34  <yorick>rwaldron: something is calling something that isn't a function, apparently
13:42:38  * thlorenzquit (Ping timeout: 240 seconds)
13:43:03  * mbrevoortquit (Remote host closed the connection)
13:45:36  * pfrazejoined
13:56:56  * pfrazequit (Ping timeout: 252 seconds)
13:57:02  * pfraze_joined
13:59:39  * pfrazejoined
14:01:28  * thlorenzjoined
14:02:31  * ednapiranhaquit (Remote host closed the connection)
14:02:51  * pfraze_quit (Ping timeout: 276 seconds)
14:11:37  * Maciek416joined
14:17:45  * brianloveswordsjoined
14:20:18  <rwaldron>yorick right, in node.cc, not at the JS layer... the latter is easy to debug
14:26:51  <rowbit1>Hourly usage stats: [developer: 1, free: 49]
14:38:22  * kevino80quit (Remote host closed the connection)
14:39:11  * defunctzombiechanged nick to defunctzombie_zz
14:56:30  * mbrevoortjoined
15:04:32  * addisonjjoined
15:08:54  * shamajoined
15:16:40  * mikolalysenkojoined
15:22:21  * kevino80joined
15:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 60]
15:29:01  * defunctzombie_zzchanged nick to defunctzombie
15:51:14  * AvianFluquit (Remote host closed the connection)
16:05:58  * kevino80quit (Remote host closed the connection)
16:09:34  * thlorenzquit (Remote host closed the connection)
16:12:52  <rowbit1>substack, pkrumins: These encoders are STILL down: 50.56.27.70(dev-ie6-1), 50.57.171.229(dev-ie6-2), 184.106.99.27(dev-ie7-3)
16:13:13  * ednapiranhajoined
16:16:24  * taterbasejoined
16:17:29  * defunctzombiechanged nick to defunctzombie_zz
16:25:51  * mikolalysenkoquit (Ping timeout: 276 seconds)
16:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 45]
16:31:06  * ednapiranhaquit (Remote host closed the connection)
16:41:00  * fotoveritequit (Quit: fotoverite)
16:41:29  * ednapiranhajoined
16:44:22  * gozalajoined
16:45:24  * kumavisjoined
16:45:52  * phatedjoined
16:52:16  * AvianFlujoined
16:52:29  * phatedquit (Ping timeout: 264 seconds)
16:53:14  * ednapiranhaquit (Quit: Leaving...)
16:55:03  * ednapiranhajoined
16:56:35  * thlorenzjoined
16:56:51  * dguttmanjoined
16:58:19  * tilgovijoined
17:00:28  * thlorenz_joined
17:00:30  * kumavisquit (Read error: Connection reset by peer)
17:00:38  * kevino80joined
17:00:50  * thlorenzquit (Ping timeout: 240 seconds)
17:00:58  * kumavisjoined
17:12:20  * kenperkinsquit (Quit: Computer has gone to sleep.)
17:13:39  * ednapiranhaquit (Remote host closed the connection)
17:17:14  * kumavisquit (Ping timeout: 240 seconds)
17:19:22  <rowbit1>/!\ New profesh signup from "Robert Hurst. Plan: 50_testling_ci_plan. $50/month. Cash money!
17:19:50  * kumavisjoined
17:23:04  * dominic_joined
17:23:24  * fotoveritejoined
17:26:12  * thealphanerdjoined
17:26:52  <rowbit1>Hourly usage stats: [developer: 0, free: 34]
17:30:35  * phatedjoined
17:30:58  * jxsonjoined
17:38:35  * phatedquit (Remote host closed the connection)
17:43:19  * ednapira_joined
17:43:43  * ednapira_changed nick to ednapiranha_
17:44:19  <rowbit1>substack, pkrumins: testling server android (osx, browserling1 user) is down!
17:44:19  <rowbit1>substack, pkrumins: testling server safari6 (osx, browserling1 user) is down!
17:44:20  <rowbit1>substack, pkrumins: testling server iphone6, ipad6 (osx, browserling1 user) is down!
17:47:29  * kenperkinsjoined
17:54:32  * pfrazequit (Ping timeout: 252 seconds)
17:55:04  * wolfeidauquit (Remote host closed the connection)
17:55:33  * wolfeidaujoined
17:56:03  * phatedjoined
18:05:21  * kenperkinsquit (Quit: Computer has gone to sleep.)
18:05:57  * defunctzombie_zzchanged nick to defunctzombie
18:08:30  * kenperkinsjoined
18:16:06  * kevino80quit (Remote host closed the connection)
18:24:17  <jjjohnny>dominic_: yodel
18:26:52  <rowbit1>Hourly usage stats: [developer: 1, free: 38]
18:27:57  <dominic_>jjjohnny: GOATDB is about to get a big push
18:28:05  <dominic_>not just a readme
18:28:25  <dominic_>but now an honest to god goat themed database written in javascript
18:37:55  * ednapiranha_changed nick to ednapiranha
18:43:04  * anoemi_joined
18:45:44  * anoemi_quit (Remote host closed the connection)
18:46:59  <jjjohnny>lol
18:47:13  <jjjohnny>dominic_: whats it do
18:47:35  * contraha_joined
18:47:42  <jjjohnny>on the subject of dbs
18:48:04  <jjjohnny>what is the equivalent of a bitcoin like backend w/o the hashing and stuff
18:48:45  <jjjohnny>honest to goat god goat themed database
18:48:46  <dominic_>jjjohnny: stores your data safely until you want to get it agoin
18:49:23  <jjjohnny>so all gets are also deletes
18:50:32  <dominic_>haha
18:50:49  <dominic_>you should post an issue if you are seeing that behavior
18:51:05  <dominic_>it's also 3x faster than level!
18:51:11  <dominic_>(to npm install)
18:51:33  <jjjohnny>haha
18:52:38  <jjjohnny>so its not a level backed db
18:55:00  <dominic_>nope. just some files.
18:55:26  <dominic_>it's backed with kiddb, json-logdb and json-sst
18:55:45  <dominic_>goatdb just brings those together and implements compaction
18:55:58  <jjjohnny>a kid is a young goat!
18:56:12  <dominic_>exactly.
18:56:41  <dominic_>jjjohnny: kiddb is also pretty goatscale.
18:57:01  * jjjohnnyis a capricorn
18:57:03  <dominic_>and also has a leveldown subset
18:57:36  * kenperkinsquit (Quit: Computer has gone to sleep.)
18:57:36  <jjjohnny>goats are one o my animal people
18:59:09  <jjjohnny>dominic_: when are we gonna get distributed with these dbs
19:00:32  <dominic_>jjjohnny: I had a pet goat once or twice
19:00:57  <dominic_>brb, eats
19:03:58  <jjjohnny>data _data __data
19:04:21  <jjjohnny>the new album by Tony Toni Tone
19:06:06  * jxson_joined
19:06:24  * dominic_quit (Ping timeout: 276 seconds)
19:07:54  * jxsonquit (Ping timeout: 240 seconds)
19:26:51  <rowbit1>Hourly usage stats: [free: 8]
19:28:11  * peutetrejoined
19:31:09  * mbrevoortquit (Remote host closed the connection)
19:35:17  * pfrazejoined
19:42:26  * nfroidurequit (Quit: Ex-Chat)
19:50:39  * kevino80joined
19:54:50  * kevino80quit (Ping timeout: 240 seconds)
19:57:44  * kenperkinsjoined
19:58:46  * kenperkinsquit (Client Quit)
20:02:12  <defunctzombie>Raynos: you can probably start with some of the things I did there, but I will say that the "tcp wrap" stuff from node is really not that heavyweight
20:02:41  <defunctzombie>you aren't gonna get many wins doing anything else... lots of the cost actually comes from the c++/js barrier
20:04:04  <Raynos>defunctzombie: I want a lowe level interface
20:04:07  <Raynos>I think ill play with your thing
20:04:10  <Raynos>opening an issue now
20:04:17  <defunctzombie>Raynos: let me know if you have questions
20:04:24  <defunctzombie>I haven't had time to poke at it recently
20:04:32  <defunctzombie>but it should be the lowest level interface
20:04:38  <defunctzombie>tho maybe you could make a lower one
20:04:47  <defunctzombie>I tried to be low level thin right on top of libuv
20:06:16  * peutetrequit (Quit: peutetre)
20:08:12  * ednapiranhaquit (Remote host closed the connection)
20:08:24  * contraha_quit (Ping timeout: 252 seconds)
20:09:38  * peutetrejoined
20:11:27  <Raynos>defunctzombie: https://github.com/defunctzombie/libuv.js/issues/3
20:11:45  <Raynos>the thing that is confusing about it is the methods instead of uv function calls
20:12:03  <ogd>calvinmetcalf: ahh https://github.com/AppGeo/coati is cool, i did some npm searching yesterday but it didnt come up
20:12:28  <defunctzombie>Raynos: https://github.com/defunctzombie/libuv.js/blob/master/test/tcp.js#L16
20:12:33  <defunctzombie>Raynos: oh, I see
20:12:48  <defunctzombie>Raynos: yea.. this is kinda where I make libuv.js less "thin"
20:13:04  <Raynos>defunctzombie: is there a performance reason for these methods or is it just "this is nicer"
20:13:05  <defunctzombie>because I gotta unwrap things properly
20:13:22  <defunctzombie>Raynos: hm.. I think there may be a casting reason
20:13:50  <defunctzombie>also nicer was certainly a factor
20:14:00  <calvinmetcalf>odg slowly I'm getting all my coworkers to do nothing but browserify streams for all projects
20:14:02  <defunctzombie>the reason it isn't like that in c
20:14:16  <defunctzombie>Raynos: is cause c doesn't have a "class" concept
20:14:25  <Raynos>defunctzombie: so I might make a PR / fix to to expose this lowe level interface
20:14:39  <Raynos>i personally find static functions nicer then methods & classes (FP influence)
20:14:52  <defunctzombie>sure, except when what you can pass in is very limited
20:14:55  <defunctzombie>as in this case
20:15:01  <defunctzombie>I think a free function also means more checks
20:15:09  <defunctzombie>on the arguments
20:15:16  <defunctzombie>and then you still have to uwrap them
20:15:22  <ogd>calvinmetcalf: nice
20:15:41  <Raynos>defunctzombie: i see the .bind() method as a partially applied uv_tcp_bind with a handle argument
20:15:41  <defunctzombie>Raynos: it leads to dirtier interfaces cause this isn't data transformation
20:16:01  <defunctzombie>Raynos: I agree with the free function approach when it is meant to work on data like things
20:16:03  <ogd>calvinmetcalf: check out filereader-stream and websocket-stream if you havent already. i wish XHR actually streamed :/
20:16:06  <Raynos>defunctzombie: the main reason I want this is I want a simple 1-1 brain dead transformation of libuv C examples
20:16:10  <defunctzombie>but in this case the "handle" is actually the state
20:16:14  <defunctzombie>Raynos: yea
20:16:20  <defunctzombie>Raynos: I thought about going that route
20:16:26  <Raynos>ill play with it and see how it comes out
20:16:31  <defunctzombie>and maybe it is worth it.. but then I kinda decided that was actually detrimental
20:16:35  <defunctzombie>cause js is not C
20:16:51  <Raynos>maybe, but libuv.js should not have the opinions
20:16:51  <defunctzombie>yea, try it
20:16:59  <defunctzombie>I agree
20:17:06  <Raynos>i think there is another thing called libuv-for-js that has an idiomatic js interface for libuv
20:17:23  <defunctzombie>but translating to another language sometimes means changing the idiom
20:17:30  <Raynos>also 1-1 transformation means the documentation is read libuv.h & libuv book :D
20:17:31  <calvinmetcalf>ogd: server sent events!
20:17:43  <defunctzombie>Raynos: kinda... there are always differences
20:17:44  <calvinmetcalf>you could totally stream those
20:17:48  <defunctzombie>Raynos: for example, buffer
20:17:52  <defunctzombie>I am using ArrayBuffers
20:17:58  <defunctzombie>and not libuv buffer
20:18:09  <defunctzombie>so there are little things here and there.
20:18:14  <defunctzombie>by all means tear it apart
20:18:16  <Raynos>sure, that's fine
20:18:22  <ogd>calvinmetcalf: oh yea i havent tested to see if it's truly streaming e.g. does xhr buffer the entire response body
20:18:24  <defunctzombie>see if you can make something you like
20:18:27  <Raynos>defunctzombie: btw how does your require interface work ?
20:18:30  <defunctzombie>this was meant ot be a starting point
20:18:39  <defunctzombie>Raynos: there is a bootstrap script
20:18:47  <ogd>calvinmetcalf: maybe it just re-connects every once in a while as a ghetto way of clearing the buffer
20:18:55  <defunctzombie>https://github.com/defunctzombie/libuv.js/blob/master/Makefile#L18
20:19:12  <defunctzombie>Raynos: which basically creates a global
20:19:20  <defunctzombie>https://github.com/defunctzombie/libuv.js/blob/master/test/support/bootstrap.js
20:19:40  <defunctzombie>and then runs the script in that context
20:19:45  <defunctzombie>https://github.com/defunctzombie/libuv.js/blob/master/test/support/bootstrap.js#L55-L56
20:19:52  * kevino80joined
20:20:02  <calvinmetcalf>ogd I'm talking about http://www.html5rocks.com/en/tutorials/eventsource/basics/
20:20:12  <ogd>calvinmetcalf: yea but it uses xhr under the hood right
20:20:39  <Raynos>defunctzombie: is test/support/bootstrap and uv/lib/bootstrap the same ?
20:20:49  <calvinmetcalf>it's implementation specific I'm pretty sure, but i
20:20:51  <ogd>calvinmetcalf: i just wonder if the implementation of eventSource is 'true' streaming or if they have to do the same ghetto hacks to fake streams on top of xhr2
20:21:01  <calvinmetcalf>ogd not
20:21:03  <calvinmetcalf>sure
20:21:17  <defunctzombie>Raynos: hm.. yes.. I think at one point I was gonna have it be compiled into the "uv(1)" runner
20:21:18  <calvinmetcalf>but I've actually got to roll
20:21:39  <defunctzombie>Raynos: it might be slightly different.. it has been a while :)
20:21:55  <Raynos>defunctzombie: so the one in test is the real one :)
20:22:02  <defunctzombie>Raynos: the "uv" runner was hacked together just for tests at first
20:22:18  <defunctzombie>and not quite meant to be the real "shell"
20:28:33  <rowbit1>/!\ ATTENTION: (default-local) paid account successfully upgraded /!\
20:28:33  <rowbit1>/!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\
20:28:35  * tilgoviquit (Remote host closed the connection)
20:29:09  <rowbit1>Hourly usage stats: [developer: 2, free: 23]
20:29:18  <ogd>lol wut https://twitter.com/Paul_Kinlan/status/458301141454180353
20:29:27  <ogd>google peeps be cray cray
20:30:03  <chapel>those of you that went to nodeconf last year, did you sleep in the dorms?
20:30:14  <chapel>wondering about the beds, how sturdy they are
20:30:23  * chapelis a big guy so its a concern of mine
20:31:10  <ogd>chapel: i would guess they are 'single' sized, not super thick mattresses but still mattresses (e.g. not cots)
20:31:22  <chapel>sure, what type of frames?
20:31:25  <chapel>meta/wood?
20:31:37  <ogd>chapel: ummm i cant really remember...
20:31:43  <chapel>no worries
20:31:46  <ogd>i dont remember thinking they were flimsy though
20:32:50  <chapel>I'll ping mikeal about it
20:42:31  * defunctzombiechanged nick to defunctzombie_zz
20:50:05  <Raynos>defunctzombie: do you do the bit where a tcp wrap in libuv.js gets GC'd and you free the libuv C stuff ?
20:53:44  * peutetrequit (Quit: peutetre)
20:55:55  * ednapiranhajoined
20:57:36  * mbrevoortjoined
20:59:10  * phatedquit (Remote host closed the connection)
20:59:51  * phatedjoined
20:59:52  * mbrevoortquit (Remote host closed the connection)
21:11:10  * rxgxjoined
21:17:10  * No9quit (Quit: Gone to join the choir invisibule)
21:17:39  * ednapiranhaquit (Remote host closed the connection)
21:19:56  * kevino80quit (Remote host closed the connection)
21:20:04  * AvianFluquit (Remote host closed the connection)
21:22:02  * jesusabdullahquit (Ping timeout: 240 seconds)
21:22:53  * thealphanerdquit (Quit: thealphanerd)
21:28:35  * mbrevoortjoined
21:29:09  <rowbit1>Hourly usage stats: [developer: 11, free: 37]
21:29:37  * phatedquit (Remote host closed the connection)
21:37:09  <Domenic_>creationix: I want to be able to store undefined in the stream...
21:37:57  <Domenic_>creationix: .wait(onReady) always calls onReady async?
21:40:48  <creationix>Domenic_ I'm here
21:40:59  <Domenic_>creationix: see above questions :)
21:41:03  <Raynos>hi
21:41:16  <creationix>I'm using a new irc client, it didn't load the backlog
21:41:51  <Domenic_>17:37:09 <Domenic_> creationix: I want to be able to store undefined in the stream...
21:41:51  <Domenic_>17:37:57 <Domenic_> creationix: .wait(onReady) always calls onReady async?
21:41:54  <Raynos>Domenic_: not being able to store `undefined` in the stream is kind of ok
21:42:05  <Raynos>JSON.stringify does not stringify undefined
21:42:13  <creationix>the top stream interface allows anything to be in the stream
21:42:21  <Domenic_>JSON.stringify doesn't allow lots of things ;)
21:42:22  <creationix>it's my existing transform interface that doesn't allow it
21:42:47  <Domenic_>ok i think i see
21:42:54  <Domenic_>that's not very important anyway, seems easily fixable
21:43:01  <Domenic_>but does .wait(onReady) always call onReady async?
21:43:08  <creationix>I'm just showing the transform as an example of how to interface with my existing code
21:43:24  <creationix>I would think wait(onReady) is always async
21:43:39  <creationix>since I batch updates with the queue
21:43:43  <Raynos>i think .wait is continuable based with is zalgo
21:43:44  <Raynos>unless creationix uses non zalgo continuables :P
21:43:47  <Domenic_>so that seems to run into a problem that i am having with whatwg/streams currently
21:43:58  <creationix>simple-streams used zalgo-continuables very heavily
21:44:04  <creationix>these two experiments are non-zalgo
21:44:26  <Domenic_>namely let's say you do .wait(onReady) but then in the same tick someone pushes into the stream
21:44:38  <ogd>http://img.shields.io/badge/Made%20with%20freedom%20in-USA-blue.svg?style=flat
21:44:54  <creationix>Domenic_ right, this style is pretty resistant to that kind of issue
21:45:05  <Domenic_>creationix: I don't understand how, please help :)
21:45:44  <creationix>ok, so onReady will always have true for it's resolved value as long as there *may* be more items in the queue
21:45:58  <creationix>if it resolves to false, then there can never be more items
21:46:11  <Domenic_>ok but
21:46:21  <Domenic_>the problem is that i want to let downstream people process anything pushed to the stream within the same tick
21:46:37  <Domenic_>which seems hard if the downstream people are doing .wait(thenProcessStuff)
21:47:00  <creationix>downstream first looks for items in the queue, they only call wait after consuming everything they want
21:47:14  <Domenic_>so the problem is not really solved
21:47:23  <creationix>what's the problem?
21:47:48  <Domenic_>the problem is that it's easy to consume all the stuff in the queue, but then the stream pushes some stuff in the same tick, and you miss out on that until the next tick
21:47:58  <Domenic_>because after consuming everything you set up a wait() listener
21:48:15  <Domenic_>node side-steps this with sync event emitters
21:48:19  <creationix>well, you could look again in nextTick if you wanted
21:48:20  <Domenic_>zalgo callbacks will also work for this
21:48:48  <Domenic_>yeah i thought about going down that path, wasn't sure it was great. there's still a nextTick delay at every step in the chain I believe
21:49:18  <creationix>well, if you allow the producer to resolve the continuable zalgo style, then it can notify the consumer in the same tick
21:50:04  <Domenic_>yeah, but then, zalgo :(
21:50:14  <creationix>btw, I noticed that google rewrote their TCP APIs to be push style with pause/resume instead of pull-style
21:50:19  <creationix>(for chrome packaged apps)
21:50:26  <Domenic_>i think push style is the only way to solve this
21:50:28  <Domenic_>without zalgo
21:50:39  <Domenic_>because push style means you give it to the consumer as soon as you get it
21:50:41  <creationix>so that's a very well understood pattern and very fast
21:50:51  <creationix>you just need the added complexity of pause/resume
21:50:57  <creationix>and trust the consumer to do the right thing
21:50:57  <Domenic_>i am going to try push style as the base layer
21:51:09  <creationix>also push works very well with my transforms
21:51:12  <Domenic_>and then wrap up the base layer in a buffered pull interface
21:51:14  <creationix>(since they are push)
21:51:27  <creationix>that's essentially what I do in my apps
21:51:35  <creationix>I write the bulk of the logic in sync push transforms
21:51:39  <creationix>there are easy and simple
21:51:49  <creationix>and as long as they are all sync, I can manage back-pressure externally
21:51:57  <creationix>and they compose really well too
21:51:59  <Domenic_>if you are willing to read a long rambly ramble written by me at 4am yesterday coming to that conclusion it's https://github.com/whatwg/streams/issues/24#issuecomment-40921444
21:52:14  <Domenic_>i want to present a ReadableStream that has the same auto-buffering, pull-style ergonomics as Node
21:52:39  <Domenic_>but I wanted to explain the buffering as var bufferedRS = baseRS.pipeThrough(buffererTransform)
21:52:39  <creationix>so my second experiment in that gist is closer to node style (streams 2)
21:53:13  <creationix>are your transforms sync or async?
21:53:15  * phatedjoined
21:53:27  <Domenic_>this particular transform would be sync
21:53:38  <creationix>sync transforms are ones that never touch their input data or emit anything after they return
21:53:40  <Domenic_>this entire journey i found myself on the last few days is how to make sync transforms fast
21:53:54  <creationix>yeah, most binary protocol parsers are just sync state-machines
21:54:10  <creationix>I love to push as much complexity into that format since it's simple and easy to compose
21:54:13  <Domenic_>your second gist seems to be almost exactly what whatwg/streams does right now
21:54:17  <Domenic_>but it presumably has the same problem
21:54:27  <creationix>yeah, I didn't really like the second one
21:54:46  <creationix>so gozala has been pushing for push-style the whole time right?
21:54:48  <Domenic_>no
21:54:52  <Domenic_>he has been pushing for goroutines
21:55:00  <creationix>I guess I never understood his interface then
21:55:23  <gozala>creationix: I have being using push based for FRP stuff
21:55:25  <Domenic_>it is higher-level. it is as if you only had passthrough streams
21:55:34  <gozala>currently I’m trying to push CSP channels
21:55:42  <gozala>that are both push & pull
21:55:46  <creationix>gozala, ahh, that's what I'm rembering then. It was very FRP
21:56:22  <creationix>I must say though, this one made me happy https://gist.github.com/creationix/11155884#file-stream-chunks-js-L7-L10
21:56:23  <gozala>creationix: the beauty of SCP channels is that you can do both push or pull
21:56:32  <gozala>which makes them nice fit for either
21:56:52  <chrisdickinson>creationix: are the top and bottom files related?
21:57:04  <creationix>chrisdickinson: no
21:57:08  <chrisdickinson>hah, okay
21:57:11  <gozala>creationix: which in fact are super close to your min-streams
21:57:50  <chrisdickinson>what ended up being the problem with simple-streams?
21:57:51  <gozala>creationix: you can see details here: https://github.com/Gozala/streams/blob/master/Examples.md
21:58:21  <creationix>chrisdickinson: there are a few edge cases that are really painful. But that's mostly from trying to use read streams to write to sinks
21:58:38  <gozala>creationix: CSP channels are the ones used intensively by go, rust, concurrent ml and core.async
21:58:40  <chrisdickinson>ah
21:58:55  <creationix>I've discovered that my code fits into two common patterns. One is push-style sync transforms
21:59:05  <creationix>for every input event there are 0 or more output events that happen in sync
21:59:08  <gozala>creationix: in fact I wanted to talk to you about this, but never managed to get hold of you
22:00:55  <creationix>The other kind of logic I have is things like the inner app in a server that reacts to events and emits events, but the relationship is less tightly couples and async
22:01:07  <creationix>for these having separate readable and writable interfaces is ideal
22:02:07  * thlorenz_quit (Remote host closed the connection)
22:02:43  * thlorenzjoined
22:03:46  <jjjohnny>PROJECT MANAGER DRIVEN DEVELOPMENT
22:03:46  <LOUDBOT>IT'S CALLED THE CARPAL TUNNEL, IT COVERS MOST OF THE DISTANCE TO PORKTON IN 3 MINUTES BY BOAT
22:04:19  <creationix>gozala: your pipe example looks a lot like my original continuable based r/w streams
22:04:36  <gozala>creationix: that is why I wanted to talk to you :)
22:04:51  <gozala>also arguably put and take are very similar to your read and write
22:05:17  <creationix>my simple one is read() => item, write() => done
22:05:39  <creationix>where => means returns a continuable/promise or accepts a callback-last node style
22:06:12  <gozala>creationix: yes it’s just given that we have promises now in standard
22:06:14  <creationix>gozala: I have a question about your JS. I didn't know about this technique:
22:06:15  <creationix> while (chunk = yield input.take(), chunk !== void(0)) {
22:06:22  <gozala>I don’t think it’s worth pursuing continuables
22:06:33  <creationix>so what's the order of actions here with the yield and the comma operator
22:06:58  <chrisdickinson>input.take(), yield, chunk assign, chunk compare
22:06:59  <gozala>creationix: it’s like grouping of multiple statements
22:07:20  * thlorenzquit (Ping timeout: 255 seconds)
22:07:22  <creationix>chrisdickinson: that makes sense.
22:07:30  <gozala>var x = (chunk =yield input.take(), chunk !== void(0)
22:08:03  <creationix>that's much clearer than how I've been writing it I think. ((chunk = yield input.take()) !== void(0))
22:09:57  <chrisdickinson>using void to ensure a "clean" undefined? or for line length?
22:10:07  <creationix>I just use undefined personally
22:10:26  <chrisdickinson>i tend to as well
22:10:49  * AvianFlujoined
22:11:41  * phated_joined
22:12:07  <creationix>gozala: so a goroutine is like a generator or a coroutine right?
22:12:30  * ednapiranhajoined
22:12:38  <gozala>creationix: yeah they just run them as separate tasks
22:12:52  <rowbit1>substack, pkrumins: These encoders are STILL down: 50.56.27.70(dev-ie6-1), 50.57.171.229(dev-ie6-2), 184.106.99.27(dev-ie7-3)
22:13:01  <creationix>but it looks like they don't even start till end of tick, or is this multi-threaded?
22:13:21  <gozala>creationix: are you referring to go ?
22:13:26  <creationix>right
22:13:31  <creationix>https://gobyexample.com/goroutines
22:13:36  <gozala>in go you can choose weather you wanna use threads or lightweight tasks
22:13:57  <creationix>I guess it doesn't matter because you don't share mutable state between them
22:14:03  * brianloveswordsquit (Quit: Computer has gone to sleep.)
22:14:16  <gozala>creationix: they communicate via channels
22:14:26  * phatedquit (Ping timeout: 240 seconds)
22:14:32  <gozala>which provide certain guarantees
22:14:43  <creationix>right, that's like talking between the main frame and a web worker right?
22:15:02  <gozala>creationix: yeah it’s message passing but a lot lighter
22:15:31  <creationix>oh, is it like rust where you can transfer ownership?
22:15:43  <creationix>(though webworkers have that too for binary data)
22:15:55  <gozala>creationix: well in go you don’t need to transfer ownership
22:15:58  <gozala>but yeah it’s similar
22:16:12  <gozala>rust also has channels for IO and communication between tasks
22:16:22  <gozala>creationix: I believe go is less strict though
22:16:35  <gozala>because you can just access task enclosed variables
22:16:48  <gozala>like channels
22:16:53  <gozala>so you could put and take from them
22:17:17  <creationix>gozala:, ok so in this example https://gobyexample.com/channels is the "ping" being pushed from the goroutine into the main task?
22:17:34  <gozala>creationix: if you’re interested I found this to be the best introduction to cap style channels https://vimeo.com/49718712
22:17:34  <creationix>and then the main task is pulling it out?
22:18:02  <gozala>creationix: ping is send to a messages channel
22:18:31  <gozala>and then main task takes message from messages channel
22:18:33  <creationix>ok, so it's a shared message queue
22:18:40  <creationix>does it support back-pressure then?
22:18:50  <gozala>creationix: it does
22:19:11  <gozala>it provides a lot more powerful task coordination than just back pressure
22:19:28  <gozala>back pressure comes for free
22:19:36  <creationix>interesting
22:19:53  <gozala>creationix: I’d suggest skimming through https://github.com/Gozala/streams/blob/master/Examples.md
22:20:04  <gozala>I explain how that coordination works
22:20:21  <creationix>so your channels are a lot like go channels?
22:20:28  <gozala>and how buffering allows you to make task coordination more flexible
22:20:37  <gozala>like high low watermark stuff
22:20:43  * addisonjquit (Quit: Connection closed for inactivity)
22:21:14  <creationix>so it's more like setting a buffer-size for the queue and back-pressure it baked in?
22:21:24  <gozala>creationix: essentially they are the same
22:21:36  <gozala>although I’d say they’re more closer to rusts implementation
22:21:58  <gozala>creationix: that’s in most primitive case
22:22:06  <gozala>creationix: but it’s more powerful
22:22:14  <gozala>because you can provide your own buffer
22:22:24  <gozala>that can have it’s own strategies for bufferring
22:22:39  <gozala>creationix: take a look at this section
22:22:39  <gozala>https://github.com/Gozala/streams/blob/master/Examples.md#bufferring-strategies
22:22:52  <gozala>creationix: you can define aggregating buffers
22:23:04  <gozala>or never overflowing buffers
22:23:11  <gozala>or even the ones that do compression
22:23:35  <gozala>creationix: key point is that channels are for transferring data between tasks
22:23:48  <gozala>while buffers are for buffering data transferred by channels
22:24:20  <gozala>because you separated those concerns everything becomes more composable and a lot more configurable
22:24:46  <gozala>creationix: as a side benefit you can do stuff like this too
22:24:47  <gozala>http://talks.golang.org/2012/concurrency.slide#50
22:25:21  <gozala>which is coordinate many different tasks and cancel out ones that failed the race
22:26:07  <gozala>creationix: expressing anything similar with node streams will be really hard
22:26:36  <creationix>so the way I've been doing it is having the buffer be a transform
22:26:47  <creationix>but I see that's rather one-directional
22:26:53  <rowbit1>substack, pkrumins: A developer is waiting in the queue for explorer/7.0
22:27:28  <gozala>creationix: well the think is buffer is task bound an can have completely sync stateful API
22:27:47  <gozala>while channels are non stateful and likely async
22:27:51  * brianloveswordsjoined
22:28:13  <gozala>creationix: I would imagine with transform you would loose this separation
22:28:32  <gozala>creationix: also note that there are cases where shared buffer comes handy
22:29:09  <rowbit1>Hourly usage stats: [developer: 11, free: 37]
22:30:02  <gozala>creationix: it also could be that I don’t really understand what transform is
22:30:36  <creationix>it's pretty simple. for each item that comes in, 0 or more items will go out
22:31:22  <creationix>wait, nevermind, sync transforms can't be buffers
22:31:32  <creationix>it was the pull-style transforms from before that could be buffers
22:31:50  <gozala>creationix: I guess what I mean I’m not sure how one would express something like this
22:31:50  <gozala>https://github.com/Gozala/streams/blob/master/Examples.md#aggregators
22:32:04  <creationix>they would pull from their source trying to reach the high-watermark while at the same time their consumer is pulling items out of them
22:32:27  <gozala>creationix: Assuming that ByteBuffer is provided by platform it can be super optimised
22:33:44  <gozala>creationix: yeah I guess you could do that
22:34:02  <gozala>but then it’s just more piping
22:34:11  <gozala>and less composable
22:34:31  <gozala>and suddenly you bound your streams to be inherently stateful
22:34:55  <gozala>while this makes buffering strategy completely independent problem
22:35:37  <gozala>creationix: in other words suddenly your domain becomes just stating weather you are full or empty given the specific state
22:36:24  <creationix>yep
22:36:32  <gozala>and I hope that bunch of Buffers for Binary data can be provided by platform so it’s a lot faster
22:36:49  <gozala>creationix: like C++ can write directly into it without talking to JS at all
22:37:04  <creationix>I care mostly about object streams
22:37:10  <creationix>but I could see how that helps binary streams
22:37:40  <gozala>creationix: there are uses for that in object stream to actually
22:37:50  <gozala>creationix: you can have something like State buffer
22:38:36  <gozala>that batches up all the diffs
22:38:56  <gozala>and on take returns combined version
22:39:05  <gozala>internally reusing data structures
22:39:28  <gozala>So in simple case it can be treated as a queue size
22:39:50  <gozala>but in some cases you can optimise it better
22:42:06  <creationix>I switched IRC clients, that one was driving me crazy
22:42:09  <jlord>ogd: just saw your comment from daaayyyz ago.
22:43:20  <gozala>creationix: so I’d be interested in your feedback
22:43:23  <feross>dominic_: i arrive on april 22, nighttime
22:43:31  <gozala>and constructive criticism
22:44:04  <gozala>creationix: I have being trying to address issues or provide examples for things that ppl seem to think it can’t address
22:44:42  <creationix>gozala: mostly I'm having trouble understanding what it is
22:45:11  <gozala>creationix: it’s just a queue of takes & puts
22:45:16  <feross>ircretary help
22:45:17  <ircretary>feross: I'm not sure what to do with that command. Ask for help in PM.
22:45:18  <gozala>that channel connects
22:45:39  <creationix>can the consumer be notified when items are put in the queue?
22:45:42  <gozala>if you can be more specific, I can try addressing it in readme
22:46:00  <gozala>creationix: well consumer does not needs to know that
22:46:09  <gozala>consumer just says input.take()
22:46:14  <feross>tell dominic_ i arrive in budapest april 22, late, like 10pm
22:46:20  <feross>tell dominic i arrive in budapest april 22, late, like 10pm
22:46:24  <gozala>and the result of it is an operation
22:46:29  <gozala>that is either pending or complete
22:46:30  <creationix>gozala: what if I take and there is nothing there?
22:46:34  <feross>ircretary: tell dominic_ i arrive in budapest april 22, late, like 10pm
22:46:35  <ircretary>feross: I'll be sure to tell dominic_
22:46:36  <jjjohnny>ircretary bomb feross
22:46:37  <ircretary>jjjohnny: Sorry, that requires admin access.
22:46:48  <gozala>creationix: so that would be a pending case
22:46:50  <feross>ircretary: tell dominic i arrive in budapest april 22, late, like 10pm
22:46:51  <ircretary>feross: I'll be sure to tell dominic
22:47:05  <gozala>and in such case take.isPending() => true
22:47:07  <feross>jjjohnny: lol what’s that?
22:47:13  <gozala>and you can do take.then(….)
22:47:22  <gozala>creationix: assuming that take = input.take()
22:47:33  <gozala>if take.isPending() => false
22:47:54  <gozala>you can unbox it via take.valueOf()
22:48:02  <gozala>if it’s pending it’s going to throw
22:48:30  <gozala>creationix: result of output.put(x) is also operation with the same interface
22:48:49  <creationix>does it pend till the consumer gets the message?
22:48:54  <gozala>creationix: if you take from closed channel
22:49:03  <gozala>than it will complete to undefined
22:49:25  <gozala>creationix: that depends on a channel
22:49:34  <gozala>unbufferred channels block on put and take
22:49:43  <gozala>meaning if I put it will be blocked until corresponding take
22:49:48  <gozala>and vice versa
22:49:53  <creationix>ok, so it resolves when the buffer is ready for more
22:49:55  * mbrevoortquit (Remote host closed the connection)
22:50:08  <gozala>for bufferred channels, puts won’t block until buffer is full
22:50:23  <gozala>after that it will start blocking and queuing put operations
22:50:31  <gozala>until there is a take releasing some space in the buffer
22:50:45  * taterbasequit (Quit: Connection closed for inactivity)
22:50:58  <gozala>creationix: well once x is moved to buffer, which is when it’s ready
22:51:16  <creationix>so where do transforms go?
22:51:33  <gozala>creationix: what is transforms ? combinator functions ?
22:51:44  <creationix>I have a stream that speaks raw binary chunks and I want to parse some binary protocol and get objects
22:51:46  <gozala>creationix: like map / filter stuff ?
22:51:58  <creationix>and when I write objects to it I want encoded binary stuff to come out
22:52:12  <creationix>a simple example is transform between newline separated JSON and objects
22:52:20  * taterbasejoined
22:52:29  <creationix>the parser will need to scan for newlines and parse and emit once it finds a whole line
22:52:42  <creationix>the encoder is a simple map of JSON.stringify + "\n"
22:52:57  <gozala>creationix: do you want me to write that ?
22:53:07  <gozala>creationix: it should be very simple
22:53:07  <creationix>well, where does that fit conceptually?
22:53:14  <creationix>does it go in the buffer?
22:53:33  <gozala>creationix: depends on use case I guess
22:53:42  <gozala>it could into either one
22:53:54  * ins0mniaquit (Ping timeout: 276 seconds)
22:54:08  <gozala>creationix: I’d say probably don’t put it into buffer
22:54:24  * jesusabdullahjoined
22:54:30  <gozala>buffers is mainly for storage and chunking
22:54:31  <kanzure>is there anything like this except it also works between "watching sessions" for speedups? https://github.com/gulpjs/gulp/blob/master/docs/recipes/fast-browserify-builds-with-watchify.md
22:54:39  <kanzure>maybe something that stores some state in a temp file somewhere
22:54:40  <creationix>ok, so buffers are primarily good for controlling high-low water-marks
22:55:03  <gozala>creationix: so what I would say
22:55:12  <gozala>I would have buffer that aggregates data
22:55:17  <gozala>and take on it returns a chunk
22:55:23  <gozala>which is from new line to new line
22:55:36  <gozala>creationix: LineBuffer(byteSize)
22:56:04  <gozala>and then I would have var channel = new Channel(new LineBuffer())
22:56:19  <gozala>map(channel.input, JSON.parse)
22:56:20  <creationix>what's byteSize do?
22:56:30  <gozala>creationix: high water mark
22:56:44  <gozala>if it has more than that amount of bytes stored
22:56:49  <gozala>buffer.isFull() will be true
22:56:49  <creationix>ok, so combined buffer and re-framer
22:57:20  <creationix>what if a single line is larger than the byteSize?
22:57:30  <gozala>creationix: Yes! reframing is a good word for it, thanks!
22:57:36  <creationix>you'll just need custom code to keep asking for more if there isn't at least one newline?
22:57:43  <ogd>feels really good to npm publish from the transbay tube
22:57:47  <gozala>creationix: it can overflow it’ll just start pushing back
22:58:05  <gozala>creationix: well you define your isFull such that
22:58:16  <creationix>ogd: how's that working for you
22:58:35  <gozala>this.buffer.byteSyze > this.limit && hasNewLine(this.buffer)
22:58:44  <gozala>creationix: ^
22:58:45  <creationix>gozala: ok, that's what I figured
22:59:02  <creationix>so that example was pretty easy since the JSON part is a simple mapping
22:59:11  <creationix>just need to reframe on the incoming stream
22:59:34  <creationix>but what about a more complex one that didn't have newlines and required a streaming JSON parser to know when one object ended and another started?
22:59:59  <creationix>most of the binary protocols I deal with are like that. They require state-machine logic to know where things end
23:00:00  <gozala>creationix: creationix I think buffer should take care only of storing data and framing
23:00:04  <creationix>ok
23:00:07  <gozala>there rest should be handled by tasks
23:00:26  <creationix>so the task would pull from the TCP socket and push to the object buffer then?
23:01:00  <gozala>creationix: well socket channel and object channel
23:01:07  <creationix>right, that's what I mean
23:02:08  <creationix>that's an interesting way to look at the problem
23:02:15  <creationix>instead of pipes and filters you have tasks and buffers
23:02:32  <creationix>I wonder how efficient that is
23:02:36  <gozala>creationix: the cool thing is we can make channels transferable
23:02:42  <gozala>and actually have tasks be workers
23:03:13  <creationix>I wish node had native workers
23:03:30  <creationix>it's silly for things like crypto and zlib to be async on threads
23:03:34  <gozala>creationix: the beauty of channels is that they let you compose problems concurrently
23:03:39  <creationix>instead we should just have generic workers that run on threads
23:03:47  <gozala>and switching parallelism switch becomes separate decision
23:03:54  <creationix>right, I saw the video :)
23:04:36  <gozala>creationix: this also lets producers and consumers decide between pull vs push
23:04:48  <creationix>the one thing I really like about this approach is it allows non-linear systems
23:04:50  <gozala>based on their own merits and not forcing each other to agree
23:04:56  <creationix>pipe chains are quite linear
23:05:36  <gozala>creationix: well I think interface is also lot more simpler that what streams have
23:05:47  <creationix>node streams are insane
23:05:57  <gozala>also you make same tick / next tick decision separate form your implementation
23:05:58  <creationix>I know why they are what they are, but it's still craazy
23:06:04  <gozala>if you use something like spawn
23:06:29  <gozala>creationix: also as you pointed out non of this needs promises
23:06:32  <creationix>so the library sits in the channel
23:06:40  <creationix>and the user implements buffers and tasks?
23:07:15  <gozala>creationix: I don’t get it sorry ?
23:07:34  <creationix>for this system to work, you need to implement a Channel library right?
23:07:44  <creationix>since there is a fair amount of logic that needs to go there
23:07:50  <creationix>that's where you encode the conventions?
23:07:54  <gozala>well it’s implemented it’s pretty simple actually
23:08:16  <gozala>creationix: I’m trying to push it for web standard instead of streams
23:08:45  <creationix>so a streaming XHR would expose a channel for TCP chunks then?
23:08:51  <gozala>so ref implementation of this is https://www.npmjs.org/package/channel
23:08:54  <creationix>and UI events would be readable channels?
23:09:36  <gozala>creationix: that would be great
23:09:58  <gozala>but for now I’m just hoping to convince everyone that it is better than streams as they are proposed
23:10:18  <gozala>creationix: I also hope that channels could be send over workers or frames
23:10:29  <creationix>right, that should be pretty easy
23:10:32  <gozala>if you use one of the provided buffers
23:10:36  <creationix>like postMessage
23:11:00  <gozala>creationix: yeah so buffer would have to do the data serialisation / parsing
23:11:07  <gozala>so it would have to be coming form platform
23:11:46  <creationix>would the websocket interface be a special buffer or a task behind the scenes that implemented the framing/deframing protocol?
23:11:58  <gozala>creationix: you could also use this for reactive bindings stuff that ppl have being interested in
23:12:45  <gozala>creationix: it obviously could, but I have not done thinking that far ahead to be honest
23:12:50  <Raynos>what are framing/deframing tasks ?
23:12:53  <Raynos>compared to buffer ?
23:13:13  <creationix>well, websocket is a binary protocol
23:13:26  <gozala>Raynos: put(chunk) does not correspond to take() => chunk
23:13:35  <gozala>because buffer does re-framing
23:14:01  <gozala>creationix: I think it really going to be implementors choice
23:14:11  <gozala>which should be opaque for the user
23:14:17  <gozala>and not matter
23:14:23  <gozala>where the framing happens
23:14:24  <creationix>yeah I guess it doesn't matter what the browser does internally
23:14:37  <gozala>creationix: I mean when you get an input port
23:14:38  <creationix>though for my case, I'm implementing HTTP and websocket in userspac
23:14:48  <gozala>you don’t know what it uses as buffer
23:15:12  <creationix>so channels are readable, writable, or both?
23:15:28  <gozala>so for consumer it’s indifferent weather it happens on a taks or in a buffer
23:15:49  <gozala>creationix: var { input, output } = new Channel()
23:15:59  <gozala>creationix: output.put(x)
23:16:05  <gozala>creationix: input.take() => x
23:16:16  <creationix>but they could be the same object right?
23:16:25  <gozala>creationix: yes
23:16:38  <gozala>creationix: go and core.async have channel that has both put and take
23:16:45  <gozala>creationix: rust has different ports
23:16:53  <Raynos>gozala: I meant it sounds like creationix is talking about special buffer & task as different things
23:17:03  <gozala>creationix: use case for rust is that you can transfer ownership of each port independent of each other
23:17:16  <creationix>Raynos: I'm just trying to figure out the best place to do binary protocol logic
23:17:19  <gozala>which also makes sense in case of content policities stuff
23:17:48  <creationix>gozala: right
23:18:02  * ednapiranhaquit (Remote host closed the connection)
23:18:11  <creationix>so the reason I'm thinking about streams today is I need to work on that part of js-git for the talk I'm giving Saturday
23:18:15  * addisonjjoined
23:18:16  <creationix>I'm not happy with simple-streams
23:18:21  <gozala>creationix: so I after talking to rust ppl I switched to { input, output }
23:18:48  <creationix>I like that too, it's just that we don't have destructing yet.
23:19:17  <gozala>Raynos: creationix well buffers and tasks are diff
23:19:28  <gozala>creationix: library itself is coded without destructuring
23:19:32  <gozala>it’s not that bad actually
23:19:46  <gozala>creationix: cause usually you need either one or the other
23:20:01  * rxgxquit (Quit: Connection closed for inactivity)
23:20:14  <gozala>creationix: also in most cases you want some transform anyhow that I would define as
23:22:08  <Raynos>gozala: so what is a "task" ?
23:23:43  <gozala>creationix: https://gist.github.com/Gozala/11159926
23:24:36  <Raynos>gozala: a task is a name for a `map` or `transform` function ?
23:24:44  <gozala>creationix: usually you move data between input & output
23:25:03  <gozala>Raynos: well by task I mean unit of code running concurrently
23:25:09  <creationix>that looks really expensive for a simple transform
23:26:16  <gozala>creationix: you mean one function call ?
23:26:41  <gozala>Raynos: so I think of producer and consumer as a separate tasks
23:26:57  <creationix>ok, so transform() is one-time cost
23:26:58  <gozala>Raynos: every generator is also a task
23:27:06  <creationix>takes a channel and returns a new one
23:27:46  <Raynos>you might need a less general name then task
23:27:51  <Raynos>i kind of get what you mean
23:27:56  <gozala>creationix: I mean you can use it to avoid destructuring :)
23:28:33  <creationix>gozala: in your map, you're just putting to output without checking for back-pressure right?
23:28:36  <gozala>Raynos: I’m calling it a task in a sense task.js calls them
23:28:41  <gozala>in go it’s go routine
23:28:50  <gozala>and in rust it’s also called task
23:29:09  <rowbit1>Hourly usage stats: [developer: 1, free: 24]
23:29:17  <gozala>creationix: you right just fixed that
23:29:18  <gozala>:)
23:29:57  <creationix>ok, so map is a gopher that runs to one side, grabs an item, transforms it and puts it on the other side
23:30:10  <creationix>pipe + map in one
23:30:35  <creationix>so everything between two channels needs to do it's own pumping
23:31:02  <gozala>creationix: as long as they wanna respect back pressure
23:31:18  <gozala>creationix: sometimes you just queue up and don’t care
23:31:41  <gozala>like if all my data is local there is no point on trying to pause / resume
23:31:42  <creationix>right, but that's up to the buffer, not the task right?
23:31:58  <gozala>creationix: no it’s up to a task
23:32:04  <gozala>so map without yield there
23:32:14  <creationix>ok
23:32:22  <gozala>was basically pumping data as fast is was coming
23:32:32  <creationix>but you have to yield on take :P
23:32:32  <gozala>not caring about weather data is queued or bufferred
23:32:58  <Raynos>you can also implement transform reducers style
23:33:00  <gozala>creationix: year or implement high order function that deals with that
23:33:03  <Raynos>instead of pumping into a second channel
23:33:09  <Raynos>just monkey wrap take() or put()
23:33:20  <gozala>Raynos: no, please
23:33:36  <gozala>creationix: creationix but yeah you could
23:34:01  <creationix>so my transforms are very composable. I could just compose several of them in a single transform
23:34:56  <creationix>which is what I do now with simple-streams. I much prefer composing at the transform level where it's a simple function
23:35:03  <Raynos>https://gist.github.com/Raynos/b30f65c86150dd30ae25
23:36:45  * defunctzombie_zzchanged nick to defunctzombie
23:38:35  <gozala>creationix: well isn’t that what map filter do in my combinators examples ?
23:38:52  <gozala>they are all functions that take source & config
23:38:57  <gozala>and return transformed source
23:39:34  <gozala>creationix: you could also go OOP way if you want to
23:43:18  <gozala>creationix: you could do this
23:43:18  <gozala>https://gist.github.com/Gozala/11160381
23:44:26  <creationix>interesting. Not my style, but cleaner than I expected it to be
23:45:35  * yorickquit (Remote host closed the connection)
23:45:48  <gozala>creationix: although to be fare going through the .then will have a tick delay
23:46:08  * thealphanerdjoined
23:46:19  <gozala>creationix: but it’s really matter of adding if checks
23:47:06  <gozala>creationix: In fact I have being talking about Promise.isPending(promise)
23:47:28  <gozala>and promise.unbox() stuff with diff ppl
23:47:54  <gozala>and had some positive reactions
23:48:21  <gozala>creationix: so if that ends up happening my Operation hack won’t be even necessary
23:49:44  <creationix>ES6 promises are basically A+ right?
23:50:00  <gozala>creationix: I believe so
23:50:22  <gozala>creationix: but it’s just if we think you should be able to ask stream if data is readable now
23:50:33  <gozala>there is no reason why you should not be able to do the same with promise
23:51:35  <gozala>the reasons why you would want to do that are same
23:55:36  <creationix>so .then wouldn't be zalgo, but you could get same-tick data if you checked for it.
23:59:39  <gozala>creationix: yeah
23:59:53  <gozala>so then would always defer to next tick