00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:21  * wolfeidauquit (Remote host closed the connection)
00:13:22  * keslaquit (Ping timeout: 246 seconds)
00:20:16  * jibayquit (Remote host closed the connection)
00:25:16  * gwenbellquit (Ping timeout: 246 seconds)
00:32:25  * thlorenzjoined
00:52:23  * yorickquit (Remote host closed the connection)
00:53:31  * AvianFlujoined
01:01:51  <Domenic_>If anyone is interested in the future of file APIs for the web, there's a really-quite-interesting thread in public-script-coord right now. http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html /cc creationix mbalho
01:02:11  <Domenic_>I am pushing for a minimal core that users can build off of but am somewhat alone.
01:03:07  * kumavisjoined
01:04:17  * no9quit (Quit: Leaving)
01:05:03  <mbalho>Domenic_: is that not a known position across all working groups?
01:05:32  <Domenic_>mbalho: that is a guiding philosophy *in theory*, but they are having trouble applying it in practice.
01:05:41  <mbalho>Domenic_: imo filesystem api doesnt need to exist, it can be implemented on top of indexeddb in userland
01:06:11  <mbalho>Domenic_: filereader needs work though
01:06:33  <Domenic_>mbalho: haha apparently standards groups have been saying that for a long time but nobody believes them so they are implementing a real fs api
01:07:02  <mbalho>Domenic_: :(
01:08:00  <Domenic_>we are trying to get them to create a usable streams abstraction as part of this. isaacs has been very helpful so far. they seem to be listening, somewhat.
01:08:28  <mbalho>Domenic_: ok so literally the *only* requirement for a good streams api is: receive data in chunks
01:08:46  <mbalho>Domenic_: everything else is optional
01:08:51  <Domenic_>mbalho: well we'd want backpressure and such too.
01:09:04  <mbalho>Domenic_: that would be nice
01:09:13  <mbalho>Domenic_: but IMO receive data in chunks is highest priority
01:09:26  <mbalho>Domenic_: because you cant receive data in chunks in xhr2 today
01:09:34  <Domenic_>yeah
01:09:56  <mbalho>Domenic_: so as long as it has that i dont really care what else is in there
01:10:25  <mbalho>Domenic_: filereader also cant pause a read, so backpressure would be good there
01:10:59  <mbalho>Domenic_: you have to read a range, then kill it and start a new filereader at the next byte range you want when you wanna read more data, its crazy
01:11:51  <mbalho>Domenic_: and xhr2.responseType = 'arraybuffer' emits readystate 3 one time, at the end of the request. the response body isnt accessible to JS before that, it just buffers the whole thing into one chunk
01:12:21  <mbalho>Domenic_: responseType text emits readystate 3 multiple times but it isnt in chunks, it is still 1 huge response string, but at least you can get at the data before the request finishes
01:12:36  <mbalho>Domenic_: so in light of how crappy the current apis are I just wanna see 'receive data in chunks'
01:12:44  <Domenic_>haha gotcha :)
01:13:26  <Domenic_>currently streams are looking something like `Promise<ArrayBuffer | EOFSignalProbablyUndefined> read(n)`.
01:13:48  * AvianFluquit (Remote host closed the connection)
01:13:57  <mbalho>with an event that tells you when its readable?
01:14:06  <mbalho>what does the <> syntax mean in standards land
01:14:12  <mbalho>what it emits?
01:14:35  <Domenic_>more or less, yeah it's just generics. Promise for either an ArrayBuffer or some type of EOF signal
01:14:48  <Domenic_>They haven't gotten as far as a readable event yet
01:14:50  <mbalho>cool that seems pretty simple
01:14:50  * wolfeidaujoined
01:15:08  <Domenic_>yay
01:17:43  * AvianFlujoined
01:21:13  * wolfeidauquit (Read error: Connection reset by peer)
01:21:37  * kumavisquit (Quit: kumavis)
01:22:19  * wolfeidaujoined
01:22:43  * kumavisjoined
01:28:22  * kumavisquit (Quit: kumavis)
01:31:15  <ricardobeat>Domenic_: any idea if these APIs will support callbacks besides promises? or are things heading to promises everywhere?
01:32:23  * AvianFluquit (Remote host closed the connection)
01:32:31  <mbalho>callbacks arent fancy enough
01:32:46  <mbalho>i was thinking of naming all of my callbacks promise
01:32:57  <mbalho>like fs.readFile(function promise(err, data){})
01:33:17  * AvianFlujoined
01:33:24  <mbalho>to dress them up a little
01:33:30  <mbalho>putting the prom in promise
01:36:11  <ricardobeat>or yet, what will happen to existing APIs after ES7 if this happens? they can't change to start returning promises
01:36:44  <mbalho>Domenic_: id like to hear an argument as to why a filesystem api has to be native and cant be done in pure js
01:37:20  <jesusabdullah>the thing is: promises still use callbacks
01:37:21  <jesusabdullah>:)
01:37:24  <ricardobeat>mbalho: apparently they intend for it to access the actual file system in the future
01:37:49  <mbalho>really?
01:38:29  <ricardobeat>"it is expected that this API will eventually also be used for
01:38:30  <ricardobeat>accessing real filesystems eventually"
01:38:49  * wolfeidauquit (Read error: Connection reset by peer)
01:38:49  <mbalho>'expected' 'eventually' hah
01:39:01  <ricardobeat>eventually*2
01:40:31  * wolfeidaujoined
01:42:25  <ricardobeat>jesusabdullah: oh well
01:43:56  * mcollinajoined
01:44:05  <ricardobeat>jesusabdullah: call it callback-passing then
01:46:35  <Domenic_>ricardobeat: no, the language is moving toward promises. existing APIs will be augmented or wrapped, just like Node's are today.
01:47:57  <Domenic_>mbalho: what do you mean exactly. on top of indexeddb?
01:49:33  <mbalho>Domenic_: yea
01:49:59  <mbalho>Domenic_: i look at browsers like i look at node, js apis provided by native code, and always wonder what the decision making process is to add more native code
01:50:11  <Domenic_>mbalho: i think that perspective on-list would be appreciated. they are under the impression all developers hate indexeddb and that people are doing development for chrome only because it has a nice fs api. (Actually, I think creationix is one of those people?)
01:50:49  <mbalho>interesting
01:51:22  <mbalho>so are they like 'since we cant fix indexeddb lets just make a new api that will be perfect but not address the failings of indexeddb'
01:52:28  <Domenic_>well to some extent yeah, that's how the web has to work since you can't kill old APIs. but also something with a "file system" abstraction instead of a "database" abstraction. Not every developer can see that one can be built on top of the other, or wants to invest the effort in doing so.
01:53:09  <mbalho>yea but it only takes 1 john resig and then nobody has to write against browser supplied apis :)
01:53:11  * calvinfoquit (Quit: Leaving.)
01:54:07  * wolfeidauquit (Remote host closed the connection)
01:54:27  <Domenic_>i'm not sure that works for things with audiences as small as "file system access."
01:54:59  <mbalho>well if the filesystem api intends on exposing actual file systems then i think its necessary, i wasnt aware of that goal
01:55:00  <Domenic_>everyone knows, to do dom manip, use jQuery. It's going to be harder getting the message out that, to do fs access, use github.com/maxogden/fs
01:55:22  <mbalho>people arent going to write webrtc themselves anymore because there are tons of competing abstractions
01:55:37  <mbalho>i 100% dont believe that standards bodies should think that normal people will use their apis
01:56:39  <Domenic_>hmm. well i guess that's where they (and I) disagree. they're hoping for a new era of not designing sucky stuff.
01:56:50  <mbalho>if we had non crappy i/o then people would come up with good solutions for storing that i/o in the existing i/o storage mechanism (idb)
01:57:07  <mbalho>i think standards bodies should focus on making things possible, not making things pretty
01:57:16  <mbalho>i dont care how pretty something is
01:57:51  <Domenic_>so, right, to some extent that is the philosophy. but (a) theory vs. practice, habits are hard to break; (b) the low-level stuff would be nicer if it were pretty, so they're trying.
01:58:09  <Domenic_>also (c) browser game theory
01:58:25  <Domenic_>i.e. if Chrome ships a FS API that people are using, Mozilla has to ship one or they lose developer marketshare.
01:58:48  <mbalho>as long as there are no sacrifices made in terms of making things possible then i dont care how pretty they try to make it
01:59:00  <mbalho>but i feel like a lot of time and effort is currently being taken up by pretty stuff
01:59:43  <mbalho>e.g. you cant read idb in a web worker in firefix, you cant read a canvas as binary, you cant pause a file reader, you cant do openssl rsa encryption in the browser, etc
01:59:57  <Domenic_>that's true
02:00:04  <Domenic_>and that sucks
02:00:09  <mbalho>but we hace a artisinally crafted backwards compatible future proof promises api that has been bikeshedded for thousands of man hours
02:00:12  <mbalho>have*
02:00:37  <mbalho>anyway, </rant>
02:00:44  <Domenic_>i don't think enough people are communicating to them the specific failures like that
02:01:33  <mbalho>its a representative democracy kind of thing, i dont have the time to sit through the bureacracy so i complain to you instead
02:01:51  <Domenic_>all they have is vague stuff like "people hate indexeddb, we're not sure why. people are using chrome's fs, so we should probably prioritize that"
02:02:29  <Domenic_>sure and that's totally valid. if you would take the time to write up a few sentences about each of those (why they're important, what use cases they block, etc.) I'd love to do my best to push for them to be fixed.
02:02:38  <mbalho>cool
02:04:41  <Domenic_>i've been pushing for real streams for a while based mainly on your presentation, and that seems to be getting *somewhere*... slowly.
02:05:24  <mbalho>we should have public elections for commitees haha
02:05:31  <mbalho>i would vote for the i/o part
02:05:34  <mbalho>party*
02:07:19  <Domenic_>haha
02:07:52  <Domenic_>the thing is it's not like people are competing for these spots. it's really just whoever has the bandwidth to actually take the time and push through an API.
02:08:19  <mbalho>ah yea
02:08:30  <mbalho>we need to create competition :D
02:08:31  <Domenic_>especially since whatwg, where all the real work happens these days, doesn't have the whole "member organizations" bs. anyone who writes a good spec and convinces implementers wins.
02:09:32  * mikealjoined
02:10:16  * mikealquit (Client Quit)
02:21:49  * ricardobeatquit (Ping timeout: 246 seconds)
02:26:50  * jxsonjoined
02:27:38  * stagasjoined
02:35:18  * jxsonquit (Remote host closed the connection)
02:36:53  * jxsonjoined
02:36:56  * jxsonquit (Remote host closed the connection)
02:49:20  * ricardobeatjoined
02:54:35  * gwenbelljoined
03:03:50  * gwenbellquit (Ping timeout: 240 seconds)
03:08:07  * wolfeidaujoined
03:08:25  * wolfeidauquit (Remote host closed the connection)
03:09:59  * mikealjoined
03:11:25  * jergasonjoined
03:13:50  * gwenbelljoined
03:14:26  * gwenbellquit (Client Quit)
03:20:33  * wolfeidaujoined
03:24:05  * thlorenzquit (Remote host closed the connection)
03:27:42  * ins0mniaquit (Ping timeout: 264 seconds)
03:28:15  * calvinfojoined
03:33:02  * calvinfoquit (Client Quit)
03:34:56  * tmcwjoined
03:34:59  * tmcwquit (Remote host closed the connection)
03:46:43  * mikealquit (Ping timeout: 264 seconds)
03:48:18  * stagas_joined
03:48:37  * timoxleyjoined
03:50:53  * stagasquit (Ping timeout: 256 seconds)
03:51:08  * stagas_changed nick to stagas
03:54:15  * timoxleyquit (Ping timeout: 260 seconds)
04:01:00  * wolfeidauquit (Remote host closed the connection)
04:12:16  * mikealjoined
04:27:28  * ralphtheninjaquit (Ping timeout: 264 seconds)
04:28:25  * timoxleyjoined
04:29:08  * timoxleyquit (Remote host closed the connection)
04:32:16  * ricardobeatquit (Ping timeout: 264 seconds)
04:33:52  * vitorpachecojoined
04:35:21  * vitorpachecoquit (Read error: Connection reset by peer)
04:36:10  * jergasonquit (Remote host closed the connection)
04:38:51  * jergasonjoined
04:38:55  * jergasonquit (Remote host closed the connection)
05:05:52  * kumavisjoined
05:12:37  <dimadima>was just reading through http://stackoverflow.com/questions/1606797/use-of-apply-with-new-operator-is-this-possible and bam! scrolled down and saw substack. <3 the internet
05:15:13  * chapeljoined
05:20:53  * kumavisquit (Quit: kumavis)
05:26:41  <dimadima>where's everyone else from the Internet idling?
05:29:09  <ik>hi
05:29:22  * mikealquit (Read error: Connection reset by peer)
05:31:16  <dimadima>hi ik
05:31:20  <ik>hi
05:31:38  <ik>It's late/early
05:32:19  <dimadima>hah ya it is
05:32:41  <dimadima>tiem is relative though
05:34:01  * mikealjoined
05:36:58  * st_lukejoined
05:37:30  <ik>relative to when i last slept
05:54:22  <dimadima>:)
05:54:54  * mk30joined
05:57:23  * mk30_quit (Ping timeout: 250 seconds)
06:00:19  * st_lukequit (Remote host closed the connection)
06:00:31  * AvianFluquit (Remote host closed the connection)
06:00:58  * AvianFlujoined
06:14:14  * defunctzombiechanged nick to defunctzombie_zz
07:01:10  * mk30quit (Quit: Page closed)
07:01:26  * mk30joined
07:15:53  * defunctzombie_zzchanged nick to defunctzombie
07:48:55  * mikealquit (Quit: Leaving.)
08:34:11  * mikealjoined
08:37:30  * mk30quit (Quit: Page closed)
08:37:45  * mk30joined
08:42:29  * jcrugzzquit (Ping timeout: 264 seconds)
08:49:24  <substack>isaacs: http://www.python.org/dev/peps/pep-0450/
08:49:32  <substack>never do this.
09:08:03  * mk30quit (Ping timeout: 250 seconds)
09:34:03  * jcrugzzjoined
09:39:14  * keslajoined
10:05:09  * defunctzombiechanged nick to defunctzombie_zz
10:29:30  * keslaquit (Ping timeout: 264 seconds)
10:34:28  * jibayjoined
10:53:19  * jcrugzzquit (Quit: leaving)
11:05:45  * ralphtheninjajoined
11:14:06  * no9joined
11:15:06  * jibayquit (Remote host closed the connection)
11:49:17  * yorickjoined
12:00:22  * ins0mniajoined
12:10:40  * jibayjoined
13:44:56  * mikolalysenkojoined
14:05:46  * whit537quit (Quit: whit537)
14:16:50  * dominictarrjoined
14:25:23  * dominictarrquit (Quit: dominictarr)
14:37:47  * jergasonjoined
14:39:06  <jesusabdullah>derf
15:04:18  * jergasonquit (Remote host closed the connection)
15:07:03  * dominictarrjoined
15:34:47  * jergasonjoined
15:59:42  * jergasonquit (Ping timeout: 276 seconds)
16:07:50  * tmcwjoined
16:10:17  * tmcwquit (Remote host closed the connection)
16:13:07  * mikolalysenkoquit (Ping timeout: 264 seconds)
16:21:28  * owen1quit (Ping timeout: 246 seconds)
16:24:31  * tmcwjoined
16:28:23  * mcollinaquit (Ping timeout: 260 seconds)
16:30:53  * mikolalysenkojoined
16:39:25  * tmcwquit (Remote host closed the connection)
16:48:35  * mikealquit (Quit: Leaving.)
17:02:52  * tmcwjoined
17:05:52  <kanzure>where is the http module defined here? https://github.com/alexgorbatchev/node-browser-builtins/blob/master/builtin/https.js
17:11:57  <kanzure>oh.. https://github.com/substack/http-browserify
17:12:04  <kanzure>cool
17:17:05  * kumavisjoined
17:20:24  * kumavisquit (Client Quit)
17:31:03  * tmcwquit (Remote host closed the connection)
17:32:05  * mikealjoined
17:33:17  * jibayquit (Read error: Operation timed out)
17:34:47  * kumavisjoined
17:36:24  * tmcwjoined
17:43:59  * mikealquit (Quit: Leaving.)
17:47:35  * jibayjoined
17:48:56  * AvianFluquit (Remote host closed the connection)
17:49:36  * tmcwquit (Remote host closed the connection)
17:50:05  * AvianFlujoined
17:55:40  * mikolalysenkoquit (Ping timeout: 264 seconds)
17:57:29  * tmcwjoined
17:58:14  * mikealjoined
18:01:47  * mk30joined
18:04:14  * mikealquit (Quit: Leaving.)
18:08:45  * jibayquit (Quit: Leaving)
18:22:44  * jergasonjoined
18:27:14  * jergasonquit (Ping timeout: 264 seconds)
18:30:54  * tmcwquit (Remote host closed the connection)
18:33:43  <dominictarr>isaacs: question about compiled extensions:
18:33:57  <dominictarr>do you need to recompile for every change in node version?
18:34:03  <dominictarr>like updating a patch?
18:34:42  <dominictarr>or will it become more stable?
18:46:30  * owen1joined
18:47:25  * mk30quit (Ping timeout: 250 seconds)
18:54:23  * defunctzombie_zzchanged nick to defunctzombie
19:06:26  <dominictarr>THOUGHT: A service is better than a tool.
19:06:31  <dominictarr>like, a CLI
19:06:33  <dominictarr>too
19:06:35  <dominictarr>tool
19:06:52  <dominictarr>because a service is dynamic and always running
19:07:21  <dominictarr>instead of having your workflow be a bunch of programs that you run
19:07:47  <dominictarr>what would be way better, would if commands where messages that you sent to services
19:08:27  <dominictarr>like, lets say you have a git service...
19:08:36  <dominictarr>then you type git commit
19:08:46  <dominictarr>and that is a message you are sending to that service.
19:09:05  <dominictarr>which can then broardcast messages to other things that might care
19:11:22  <dominictarr>or...
19:11:46  <dominictarr>if npm was a service, rather than a program… then it becomes way cooler
19:11:58  <dominictarr>firstly, it can manage your services for you
19:12:03  <dominictarr>also, you can use it remotely
19:12:10  <dominictarr>npm install X
19:12:13  <dominictarr>to install X locally
19:12:26  <dlmanning>CaaS
19:12:33  <dominictarr>or npm --host myserver.com:9090 install X
19:12:39  <dominictarr>to install X on that machine
19:12:43  <dominictarr>dlmanning: C?
19:12:47  <dlmanning>Clients
19:13:41  <dominictarr>dlmanning: aha, right.
19:13:55  <dominictarr>I've kinda stopped thinking of npm as a client
19:14:01  <dominictarr>since working on npmd
19:14:24  <dominictarr>like if npm is a service, it can pull down and keep it's cache uptodate
19:14:46  <dominictarr>by connecting to the changes feed from the npm registry service
19:20:25  * calvinfojoined
19:21:53  <isaacs>dominictarr: you need to recompile for every unstable node version change.
19:21:59  <isaacs>dominictarr: or if you switch between stable versions
19:22:11  <dominictarr>isaacs: even patches?
19:22:17  <isaacs>dominictarr: binary addons should not need to be recompiled going from, for example, 0.10.1 to 0.10.99
19:22:21  <isaacs>dominictarr: yes.
19:22:29  <isaacs>dominictarr: unstable releases do not guarantee binary compatibility
19:22:36  <isaacs>or API compatibility
19:22:54  <dominictarr>right - so recompile when using unstable, but stable patches are okay
19:22:59  <isaacs>dominictarr: eg, in the last 0.11 release, we completely changed the V8 API
19:23:04  <isaacs>yes
19:33:46  * calvinfoquit (Quit: Leaving.)
19:35:21  * jergasonjoined
19:53:50  <dominictarr>Raynos: continuable needs a function that turns a normal async callback style into a continuable
19:54:28  <dominictarr>oh, I already implemented that
20:26:10  * mikealjoined
20:30:41  * mikealquit (Client Quit)
20:50:45  * kumavisquit (Quit: kumavis)
20:51:42  * jibayjoined
20:54:52  * Kesslerjoined
21:08:28  <Kessler>guys, maybe someone can tell me how do I deal with a problem like this: https://gist.github.com/kessler-y/6206812 (Recursive process.nextTick detected coming from a _stream_readable) any help would be vastly appreciated :)
21:10:01  <Kessler>even hints or general direction pointing fingers ....
21:19:39  * kumavisjoined
21:25:30  * evboguejoined
21:34:29  * wolfeidaujoined
21:51:41  * wolfeidauquit (Remote host closed the connection)
21:52:20  * stagasquit (Ping timeout: 240 seconds)
22:16:59  * Kesslerquit (Ping timeout: 260 seconds)
22:30:46  * kumavisquit (Quit: kumavis)
23:08:12  * st_lukejoined
23:15:24  * jergasonquit (Remote host closed the connection)
23:15:33  * jcrugzzjoined
23:18:47  * damonoehlmanjoined
23:19:31  * mikealjoined
23:33:58  * dominictarrquit (Quit: dominictarr)
23:55:16  * thlorenzjoined
23:59:42  * kumavisjoined