--- Log opened Sat Feb 16 00:00:41 2013
00:11 < mikolalysenko> chrisdickinson: awesome!
00:11 < chrisdickinson> there are, of course, bugs; but at least there's a test page for it and an easy path for reporting the bugs
00:11 < chrisdickinson> the idea is to catch and catalog 'em all.
00:13 < mikolalysenko> fantastic, I'll try to help where I can though it looks like since I am on a macbook you already got mine
00:15 < mikolalysenko> suggestion: maybe make it capture mouse events too?
00:15 < mikolalysenko> since those are actually kind of tricky, especially with the weirdness of left/right/middle
00:17 < mikolalysenko> chrisdickinson: also, have you seen this?  http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/
00:18 < mikolalysenko> apparently the situation is especially weird for swiss/german/swedish users
00:18 < chrisdickinson> yes
00:18 < chrisdickinson> mikolalysenko: kb-controls actually does catch mouse events
00:18 < chrisdickinson> vkey doesn't though
00:18 < mikolalysenko> ok
01:26 < Raynos> chrisdickinson: OH HI
01:27 < Raynos> miko: there's a keyboard module. https://github.com/benvie/keyboard
01:27 < Raynos> I just use https://github.com/gozala/dom-reduce
01:27 < Raynos> events(window, "keyup")
05:04 < defunctzombie> isaacs: nice, that is a reason I can stand behind :)
05:07 < jjjjohnnny> isaacs: is 'a require b require a' not an anti-pattern?
05:09 < jjjjohnnny> seems kind of silly, but who am I to say
05:09 < defunctzombie> it is an anti pattern, but if you use returns they would never return
05:10 < defunctzombie> jjjjohnnny: I was asking in the context of why we didn't just 'return foo'; if we wanted to export foo from a module
05:11 < jjjjohnnny> my brain is really off
07:11 < substack> defunctzombie_zz: can you add a "browserify" field to the process module?
07:11 < substack> to mirror "browser"
07:11 < substack> otherwise it leaves a gap in the migration path from browserify v1 to v2
07:12 < substack> merging the browser field patch into v1 now but people on a slightly older version will run into issues with process.nextTick() from v2 modules
07:13 < substack> I'm thinking I shouldmake using process without requiring it should generate a warning and inline the process code
07:16 < substack> if I do that you can just ignore my thing about the process module
08:58 < jesusabdullah> substack: according to this recruiter I am "highly ranked in javascript" what does this mean >_<
08:59 < jesusabdullah> substack: hahaha you got cc'd on this fucker
08:59 < jesusabdullah> substack: plz2b confirm
09:16 < niftylettuce> FIRST THEY IGNORE YOU, THEN LAUGH AT YOU, THEN FIGHT YOU, THEN YOU WIN.
09:16 < LOUDBOT> YOU COMPLETE MY WAKEFUL NIGHTMARE
09:19 < jesusabdullah> maan did the stizz really fall asleep on me? XD
10:35 < jesusabdullah> isaacs: soz bro my internet died like right before you asked me about publishing
10:45 < substack> jesusabdullah: yes confirmed @ cc'd
10:46 < substack> however that even happened
10:53 < jesusabdullah> lulz
10:53 < jesusabdullah> "I see you are HIGHLY RANKED in JAVASCRIPT"
10:54 < jesusabdullah> must've thought it'd somehow lend some "credibility" to the email?
10:54 < jesusabdullah> though obviously you give about as many shits as I do, if even that
10:54 < jesusabdullah> so, like
10:55 < jesusabdullah> yeah
10:55 < jesusabdullah> I really want to know what kind of leaderboard these people are looking at
10:55 < jesusabdullah> like, where ARE these things?
12:28 < fotoverite> jesusabdullah: coderwall. :P
13:22 < jesusabdullah> fotoverite: may be? Is there an actual lederbord on there per-language?
13:22 < fotoverite> yes
13:25 < jesusabdullah> fotoverite: link? :)
13:26 < fotoverite> Umm https://coderwall.com/n/javascript
13:27 < jesusabdullah> let's see how HIGHLY i RANK
13:27 < jesusabdullah> what the fuck are these protips
13:34 < jesusabdullah> seriously, no aggregate stats on badges anymore? protips are retarded
13:34 < fotoverite> well the whole thing became retarded
13:35 < fotoverite> but still better then geeklist
13:36 < jesusabdullah> yeah well I mean
13:36 < jesusabdullah> I haven't looked at greeklist in ages
13:57 < defunctzombie> substack: Raynos: https://github.com/shtylman/node-process/commit/8b6f96cd48390b3a9932049a959d5f724a64a127
13:57 < defunctzombie> published as version 0.5.1
13:58 < defunctzombie> Raynos: sorry, should have done it earlier, was being stubborn :P
13:59 < substack> oh sweet
14:00 < defunctzombie> well, it would be published if npm was not being stupid
14:01 < mikolalysenko> what is the best way to support workers in browserify?
14:02 < mikolalysenko> in other words, I want some API that lets me spin up workers in my modules that works transparently across both node and browserify
14:02 < mikolalysenko> I can think of a way to do this, but it would require modifying browserify somewhat
14:02 < jesusabdullah> proccor
14:03 < mikolalysenko> do you have a link?
14:06 < jesusabdullah> my internet sucks that had zero context mikolalysenko
14:07 < jesusabdullah> idk what you want to do mikolalysenko but maybe https://github.com/substack/dnode will help?
14:08 < mikolalysenko> no, not dnode
14:08 < mikolalysenko> what I want to do is be able to use webworkers in my modules
14:08 < mikolalysenko> but also have them work in browserify/node
14:09 < mikolalysenko> now on node, I could use child_process.execFile
14:09 < mikolalysenko> but it is a bit clumsy
14:09 < mikolalysenko> and in the browser I can use a worker
14:09 < mikolalysenko> but the problem is that it is a bit opaque
14:09 < mikolalysenko> but obviously not impossible
14:10 < mikolalysenko> for example, I could just browserify each of my worker scripts and then spin up the workers as usual
14:10 < mikolalysenko> the problem comes when I want to start writing things modularly
14:10 < mikolalysenko> if I make a module that uses a worker internally, then anyone who includes my script via browserify needs to know that there is a worker in that script
14:10 < mikolalysenko> and thus they have to host that script on their server/browserify it separately
14:11 < mikolalysenko> which is a crazy proposition
14:11 < mikolalysenko> does this make sense so far?
14:12 < mikolalysenko> so, what I was thinking is that you could do it with one browserify script by doing a hack
14:12 < mikolalysenko> what you would need to do is keep track of all the different worker scripts, and then generate one bundle
14:13 < mikolalysenko> then when you start a worker you could basically spin up the main entry script, wait until you get a message and then switch to the appropriate bundle
14:13 < mikolalysenko> specifying the worker entry points could probably be done using package.json
14:14 < mikolalysenko> but you would need to add some special loader code to the start of your entry in browserify
14:14 < mikolalysenko> so it still isn't very seamless
14:16 < chrisdickinson> mikolalysenko: you can dynamically create webworkers without having to host a file
14:18 < mikolalysenko> chrisdickinson:  yeah, but what if I want to require something in my workers?
14:19 < chrisdickinson> worker = new Worker(URL.getObjectURL(new Blob(['('+function(){ global.isWorker = true; importScripts('bundle.js'); }+')()'], {type: 'text/javascript'}))
14:19 < chrisdickinson> well, in this case `global.isWorker` would be `this.isWorker`
14:20 < chrisdickinson> and then in your entry point you can check to see if the current context is a worker or not
14:21 < mikolalysenko> chrisdickinson: right, I know it should work
14:21 < mikolalysenko> but the problem is if I write a module that uses a worker, there is no standard protocol for my users to follow
14:21 < mikolalysenko> for example, say I want to write a module to asynchronously process large chunks of volumetric data
14:22 < mikolalysenko> I'd prefer to spin up a worker to do the computations rather than block the main thread
14:22 < mikolalysenko> and I'd also like people to be able to use my library doing the simple npm install/require syntax
14:23 < mikolalysenko> if I have to make a custom entry, then that means that anyone who uses my module will need to check for workers and dispatch the appropriate worker entry point which kind of sucks
14:23 < chrisdickinson> ah, i see
14:24 < chrisdickinson> if two people use this strategy in a given bundle it gets hairy, is what you're saying?
14:24 < mikolalysenko> yes
14:24 < mikolalysenko> and if I use a library, that is using this sort of strategy, how do I know to implement it properly?
14:24 < chrisdickinson> this seems like it'd be easy to roll up into a module
14:25 < mikolalysenko> maybe
14:25 < mikolalysenko> though what would be best is if there was a way to override the entry script in browserify
14:25 < mikolalysenko> like before it loads, you could specify global.entry = "myworker.js" and then do that instead of running the main script
14:25 < chrisdickinson> var bfyworker = require('bfyworker'); if(!global.isWorker && !global.workerContext === 'bloo') { var worker = bfyworker('bloo') }
14:26 < chrisdickinson> yeah, the fact that it works like `fork` is a little weird
14:27 < mikolalysenko> I think you could pretty easily emulate workers node-side using child_process.execFile
14:28 < mikolalysenko> but coming up with an API that is acceptable on both sides could be tough
14:29 < mikolalysenko> it might enough in browserify if it was possible to dynamically change the entry point of the bundle
14:29 < mikolalysenko> also is there a good way to get the path to the current script?
14:29 < chrisdickinson> so, you can get the source of the current bundle from the root of a module
14:30 < mikolalysenko> yeah, in node it is possible
14:30 < mikolalysenko> but thinking ahead in the browser, what you want to do is call imporScripts('bundle.js') in the worker
14:30 < chrisdickinson> no, i mean from inside the module in the browser
14:30 < mikolalysenko> ok
14:30 < chrisdickinson> and you can get the arguments that require.define was called with
14:31 < chrisdickinson> well.
14:31 < chrisdickinson> sort of.
14:31 < chrisdickinson> forgot about "use strict", raining on my parade.
14:31 < chrisdickinson> arguments.callee.caller.caller
14:32 < chrisdickinson> the caller with a caller property of null will contain the entire source of the bundle
14:32 < mikolalysenko> is there a way in browserify to toggle executing the entry depending on a flag?
14:32 < mikolalysenko> for example, could I do:  global.noEntry = true;  importScripts('bundle.js');
14:32 < chrisdickinson> i don't think so
14:33 < mikolalysenko> then once I get a message, I could just load up the appropriate module
14:34 < mikolalysenko> the other thing you would need though is that you'd have to specify a list of all the worker entry points to bundle, but that should be doable with package.json
14:34 < mikolalysenko> hmm
14:35 < mikolalysenko> I think making these changes could be a minimally invasive solution to the worker problem
14:35 < mikolalysenko> also using only one bundle should save on page load times, since modules can be reused between the worker/main thread
14:35 < chrisdickinson> mikolalysenko: so if you could safely disregard "use strict" (which might be prohibitive), you could simply get the bundle sources using the arguments.callee.caller trick, remove the last instance of /;,*;}/, and replace it with "this.require = require"
14:36 < mikolalysenko> chrisdickinson:  ah!  that's pretty clever
14:36 < mikolalysenko> have you considered making a module to do that?
14:37 < chrisdickinson> thinking about it now :)
14:37 < chrisdickinson> it falls down if any module calling you uses "use strict", because arguments.callee goes away in strict mode
14:37 < mikolalysenko> hmm
14:37 < mikolalysenko> good point
14:38 < chrisdickinson> browserify could remove all "use strict" commands :)
14:38 < mikolalysenko> no, that would be bad
14:38 < chrisdickinson> yeahhh, i know
14:38 < chrisdickinson> i just dislike "use strict" ):
14:38 < mikolalysenko> maybe you could add a way for browserify to call the script on start up?
14:38 < mikolalysenko> sort of like a pre-emptive require
14:38 < mikolalysenko> that way you could grab the source of the main module when it first loads
14:39 < mikolalysenko> before any "use strict";s get called
14:39 < chrisdickinson> oh, or even better: `require.source = arguments.callee+''`
14:39 < mikolalysenko> ah!  that would work
14:39 < chrisdickinson> which would work because browserify's preamble isn't "use strict"
14:40 < mikolalysenko> very clever
14:40 < mikolalysenko> is there a standard way to add stuff to the preamble?
14:40 < mikolalysenko> what happens if I use two modules that are using this trick?
14:41 < chrisdickinson> wouldn't matter, browserify only ever has the concept of a single entry point
14:41 < mikolalysenko> hmm
14:41 < chrisdickinson> both modules could grab the source code and use it however they like
14:41 < mikolalysenko> but that means that users need to know about this trick if they include a module with workers
14:41 < mikolalysenko> which is not so great
14:41 < mikolalysenko> since they would have to add a require.source = arguments.callee
14:42 < mikolalysenko> err +''
14:42 < chrisdickinson> that's why i'm forking browserify and adding it to the preamble
14:42 < chrisdickinson> so that users won't have to know
14:42 < mikolalysenko> great
14:42 < chrisdickinson> and they can just use whatever neat little web worker modules fall out of this :)
14:42 < mikolalysenko> alright, I am excited
14:46 < mikolalysenko> also:  double check, it is possible to add extra modules/requires to browserify via package.json?
14:47 < chrisdickinson> i think so?
14:47 < chrisdickinson> not sure.
14:52 < mikolalysenko> wait, I got a screwy idea
14:53 < mikolalysenko> oh never mind it won't work
14:57 < chrisdickinson> i got one too
14:58 < chrisdickinson> oo
14:58 < chrisdickinson> and this one might work
15:03 < mikolalysenko> suggestion:  maybe put it in process?
15:03 < mikolalysenko> perhaps it should be process.source = arguments.callee + '';
15:04 < mikolalysenko> instead of require
15:04 < mikolalysenko> that way you can just modify the module instead of digging around in the guts of browserify
15:05 < mikolalysenko> I think it is in builtins/__browserify_process.js
15:05 < mikolalysenko> chrisdickinsin: ^^^
15:05 < mikolalysenko> *chrisdickinson
15:16 < chrisdickinson> mikolalysenko: i think we may not have to fork after all
15:17 < chrisdickinson> will update in a second!
15:24 < mikolalysenko> ok!
15:36 < chrisdickinson> hmmm
15:36 < chrisdickinson> was hoping to use require.modules
15:36 < chrisdickinson> stymied though
15:38 < mikolalysenko> hmm
15:38 < mikolalysenko> what do you think of my suggestion above?
15:39 < mikolalysenko> of adding the source to __browserify_process
15:39 < mikolalysenko> that gets loaded before any modules, and doesn't use strict
15:39 < mikolalysenko> and it requires minimal modification of the run time
15:39 < mikolalysenko> also another problem occurred to me...
15:40 < mikolalysenko> what happens if the source gets minified?  can we still just patch the bundle like you are suggesting?
15:40 < mikolalysenko> it may be more robust to add a global flag to toggle on/off the default entry
15:41 < mikolalysenko> and for another thing:  workers are a little complicated
15:41 < mikolalysenko> they can't do console.log like in a browser
15:41 < mikolalysenko> but those issues can probably be patched within whatever module implements them
15:42 < chrisdickinson> mikolalysenko: what i'm thinking is that if we add a pointer to the original module function in require.modules['name'], we can easily reassemble the bundle for a worker
15:42 < chrisdickinson> https://github.com/chrisdickinson/node-browserify
15:43 < chrisdickinson> ah damn, my dns isn't resolving correctly ):
15:43 < mikolalysenko> hmm
15:44 < mikolalysenko> what I am concerned about is what happens if the bundle gets uglify'd or something?
15:44 < mikolalysenko> can we still reassemble it?
15:44 < chrisdickinson> shouldn't matter if we go this route
15:44 < mikolalysenko> ok
15:44 < chrisdickinson> https://github.com/chrisdickinson/node-browserify/commit/865b92682c238c72b562d83215687a11bfeb61fc
15:45 < mikolalysenko> will that work?
15:45 < chrisdickinson> trying it
15:58 < chrisdickinson> woot
15:58 < chrisdickinson> mikolalysenko: this is the sort of base api it would enable: https://gist.github.com/chrisdickinson/53041c1e8efa064b543c
15:59 < chrisdickinson> (and it works with my fork)
15:59 < chrisdickinson> was going to go a bit further and make workers "pause" streams
15:59 < chrisdickinson> but that'd be better as a higher level module anyway
16:03 < mikolalysenko> hmm
16:03 < mikolalysenko> if I use the module, can I "use strict"?
16:04 < mikolalysenko> though I like the syntax
16:05 < mikolalysenko> but it might be a bit misleading to create workers via a closure, since there is no way to capture variables and pass them to the worker
16:05 < mikolalysenko> I was thinking it might be simpler to stick to the WebWorker/child_process.execFile model and make each worker a separate script
16:05 < mikolalysenko> but this might just be me thinking to fixedly
16:07 < chrisdickinson> you can use strict
16:07 < chrisdickinson> you can also use a string
16:07 < chrisdickinson> but the other nice thing about using functions is that browserify will pick up on requires within them
16:08 < mikolalysenko> that's a good point
16:09 < mikolalysenko> I am thinking though about how to emulate it on the node side
16:09 < mikolalysenko> since you would ideally want an api that works the same in both situations
16:27 < chrisdickinson> combined with a streaming api, it could be pretty neat
16:28 < chrisdickinson> someSetOfRequests.pipe(throughWorker(function(data) { /* crunch data */; this.emit('data', data) }).pipe(somethingElse)
16:28 < mikolalysenko> yeah, I think so too
16:29 < mikolalysenko> though it would probably be better to make the basic worker api just do simple event emitter stuff
16:29 < mikolalysenko> making it as close to the browser as possible
16:29 < mikolalysenko> though I could definitely see building a higher level stream api on top of that being very cool and useful
16:30 < mikolalysenko> for example, a zlib worker in your browser
16:30 < mikolalysenko> but you may also want to create other workers too
16:30 < mikolalysenko> in voxel.js, for example, it would make sense to do all the mesh generation in a worker
16:31 < mikolalysenko> and for that I don't know that streaming makes the most sense
16:32 < chrisdickinson> in that the stream could pause whenever a request is sent and unpause when a response is received, it might make sense
16:32 < chrisdickinson> plus, it caches url + fn -> object url, so you can create a bunch of identical workers
16:33 < chrisdickinson> i mean, path + fn
16:33 < chrisdickinson> to object url
16:33 < mikolalysenko> hmm
16:33 < mikolalysenko> ok, but I am still confused about the use strict problem in node
16:33 < chrisdickinson> (no need to regenerate the source and the blob and the object url)
16:33 < chrisdickinson> there shouldn't be one
16:33 < chrisdickinson> with this
16:33 < mikolalysenko> ok, how does it work?
16:33 < mikolalysenko> I call worker(function() { my code })
16:34 < mikolalysenko> then how does it create the child process to do the work?
16:34 < chrisdickinson> mikolalysenko: https://gist.github.com/chrisdickinson/5f637d50610e4e070fdc
16:35 < chrisdickinson> it'll be worker(function() {}, working_directory)
16:35 < mikolalysenko> ah, I see!
16:35 < chrisdickinson> it just rebuilds the bundle :)
16:35 < mikolalysenko> I didn't realize fn + '' gives you the source code
16:35 < chrisdickinson> yep!
16:35 < mikolalysenko> cool!
16:35 < chrisdickinson> Function#toString returns the original source of the function
16:35 < mikolalysenko> alright, I think this will definitely work
16:35 < chrisdickinson> it's handy for scope rewriting
16:36 < chrisdickinson> new_fn = Function('some', 'new', 'args', 'return '+fn)
16:36 < chrisdickinson> assuming substack is okay with merging in the change
16:37 < mikolalysenko> it is pretty minor, so I don't see why not
16:37 < chrisdickinson> https://github.com/substack/node-browserify/pull/284
16:38 < mikolalysenko> ok, I like where this is going
16:46 < chrisdickinson> mikolalysenko: https://github.com/chrisdickinson/bfy-worker
17:33 < mikolalysenko> chrisdickinson: for bfy-worker, have you started making a server-side version yet?
17:33 < chrisdickinson> nope
17:34 < chrisdickinson> server side is a little more complicated i think
17:34 < mikolalysenko> yeah
17:34 < mikolalysenko> might be good to try to meet in the middle
17:34 < mikolalysenko> maybe wrap process.on in the WebWorker version to handle the onmessage?
17:35 < chrisdickinson> is there any equivalent for postMessage?
17:35 < chrisdickinson> (from a worker?)
17:35 < mikolalysenko> process.emit?
17:36 < mikolalysenko> I don't really know the best solution tbh
17:36 < mikolalysenko> but I think whatever happens it will need to meet in the middle somehow
17:37 < mikolalysenko> since neither node's child_process or WebWorkers are completely ideal
17:37 < chrisdickinson> yeah
17:37 < chrisdickinson> it's probably best to do the process.on/emit thing in web workers
17:38 < mikolalysenko> and I think you could make a similar thing work in node's child_process.execFile
17:39 < mikolalysenko> also important is that at least on the browser you should be able to take advantage of sharing typed arrays
17:39 < mikolalysenko> and though it isn't possible yet in node, we wouldn't want to rule it out as a future extension
17:39 < chrisdickinson> mikolalysenko: basically in node we'd have to be somewhat opinionated about how the processes talk to one another
17:40 < hij1nx> defunctzombie_zz: ping
17:40 < mikolalysenko> chrisdickinson: agreed
17:40 < mikolalysenko> maybe you could do something like extend the process object for the child
17:40 < mikolalysenko> like add an extra method called "send"
17:41 < mikolalysenko> since emit might have undesirable consequences...
17:41 < chrisdickinson> ah, we want child_process.fork -- it does what we want
17:41 < chrisdickinson> .send / .on
17:41 < mikolalysenko> ok
17:41 < mikolalysenko> yeah, that works
17:41 < chrisdickinson> yeah, this package will be one of the ones with a "browserify": field in the package.json so it'll just work wherever you require it
17:42 < mikolalysenko> ok
17:42 < chrisdickinson> although, hmm
17:42 < chrisdickinson> it has to be a file
17:42 < chrisdickinson> blergh
17:42 < chrisdickinson> i can get around that i think
17:42 < chrisdickinson> actually
17:42 < chrisdickinson> haha
17:43 < mikolalysenko> make a temp file and cat the function into it?
17:45 < chrisdickinson> nah
17:45 < chrisdickinson> add a file to the module that has `process.once('data', function(data) { execute(data) })`
17:45 < chrisdickinson> essentially
17:46 < mikolalysenko> ok, that works
17:46 < mikolalysenko> also:  how can we expose this functionality in webworkers:  https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers#Passing_data_by_transferring_.C2.A0ownership_(transferable_objects)
17:46 < mikolalysenko> since not having transferrable objects really sucks
17:47 < mikolalysenko> without it, you spend most of your time in JSON.parse/JSON.stringify
17:47 < mikolalysenko> we could maybe do something a little opaque
17:47 < mikolalysenko> like transfer everything as a stream
17:48 < mikolalysenko> then you could take advantage of this behavior by default
17:48 < mikolalysenko> and if you want to send JSON stuff, you would be responsible for implementing your own protocol
17:48 < mikolalysenko> here is a more readable article:  http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast
17:48  * chrisdickinson reads
17:49 < mikolalysenko> the performance difference of transferrable objects vs. serialized JSON is so huge you can't really ignore it
17:50 < chrisdickinson> mikolalysenko: the other interesting bit: http://developers.whatwg.org/the-canvas-element.html#dom-canvas-transfercontroltoproxy
17:50 < chrisdickinson> you can actually transfer the control of a canvas to a worker
17:50 < chrisdickinson> not sure how we'd model that one :)
17:50 < mikolalysenko> yeah...
17:50 < mikolalysenko> well, in node we don't have canvases but I am working on a webgl port
17:51 < mikolalysenko> https://github.com/mikolalysenko/headless-gl
17:51 < chrisdickinson> cool!
17:52 < mikolalysenko> so being able to transfer a webgl context would be pretty awesome
17:52 < mikolalysenko> also, I think that with the trasferrable canvas feature you could create gpu accelerated workers
17:52 < mikolalysenko> which is too awesome to ignore
17:52 < chrisdickinson> +1
17:52 < mikolalysenko> maybe we could do something like give each worker their own canvas once they get started?
17:53 < mikolalysenko> and then you could just move the canvases around in the dom in the main thread
17:53 < chrisdickinson> i wouldn't want to make that assumption by default
17:53 < mikolalysenko> it might be wasteful though if you don't need it
17:53 < mikolalysenko> true
17:53 < chrisdickinson> but yeah, maybe a similar library could do something like that
17:54 < mikolalysenko> another possibility is we could have a protocol for a worker to request a canvas?
17:54 < mikolalysenko> yeah, that could be in a separate library
17:54 < mikolalysenko> I guess as long as you can get around in the guts of the workers it should be possible to hack something in
17:58 < hij1nx> defunctzombie_zz: i dont get it; what do you think is wrong with `npm install`?
18:09 < mikolalysenko> chrisdickinson: hmm...  bad news, I couldn't get the canvas context transfer to work in chrome
18:09 < chrisdickinson> yeah, not sure where (if anywhere) it's supported
18:09 < chrisdickinson> it's just on the whatwg html5 page :|
18:09 < chrisdickinson> probably works in opera
18:09 < chrisdickinson> ):
18:09 < mikolalysenko> it is a cool feature
18:10 < mikolalysenko> where do you go to submit bugs to chrome?
18:10 < mikolalysenko> also, it would be neat if they had the same thing for webgl too
18:10 < chrisdickinson> i'm not sure, actually
18:10 < chrisdickinson> http://code.google.com/p/chromium/issues/list ?
18:10 < chrisdickinson> i think it would be applicable to webgl
18:10 < mikolalysenko> well, I don't think so
18:11 < mikolalysenko> since it creates a CanvasRenderingContext2D
18:11 < mikolalysenko> not a WebGLRenderingContext
18:11 < mikolalysenko> the first is what you get from canvas.getContext("2d")
18:11 < mikolalysenko> while the other is from canvas.getContext("experimental-webgl")
18:13 < mikolalysenko> I guess they have a mailing list?
18:14 < chrisdickinson> thinking of separating transfer-control from send
18:14 < chrisdickinson> events would get emitted as `transfer`
18:14 < chrisdickinson> or receive, i guess
18:14 < chrisdickinson> hm
18:14 < chrisdickinson> dunno
18:16 < mikolalysenko> maybe have a 'transfer' event
18:16 < mikolalysenko> or 'canvas'
18:17 < mikolalysenko> and use ArrayBuffers for the rest of the stuff
18:31 < mikolalysenko> chrisdickinson: looks like it is being discussed right now:  http://wiki.whatwg.org/wiki/CanvasInWorkers
18:33 < mikolalysenko> not in the context of browserify, but in the bigger world of canvas/gpgpu/web workers
18:33 < chrisdickinson> okay, so "transfer" is a sender semantic now
18:36 < mikolalysenko> yeah, though it looks like support for canvas transfer is pretty limited now; but still it is good to have it available
18:59 < ehd> what was the name of the browserify-ing server again?
19:01 < mikolalysenko> I have one called serverify
19:01 < mikolalysenko> there are many others though
19:01 < mikolalysenko> https://github.com/mikolalysenko/Serverify
19:03 < ehd> cool thanks, i'll try that one
19:06 < ehd> setting the port via --port [n] doesn't work though?
19:06 < chrisdickinson> ehd: also browservefy
19:06 < chrisdickinson> https://github.com/chrisdickinson/browservefy
19:10 < mikolalysenko> also raynos has his own:  https://github.com/Raynos/browserify-server
19:10 < mikolalysenko> and there are probably many others...
19:20 < mikolalysenko> ehd: crap, just realized I was reading the commandline arguments wrong
19:20 < mikolalysenko> but I can't push the update until npm is back online
19:32 < chrisdickinson> i think this worker thing'll be neat
19:36 < chrisdickinson> sweet, console.log works
19:37 < mikolalysenko> awesome!
19:38 < mikolalysenko> if you get it working reliably, I will probably use it in half my projects
19:38 < chrisdickinson> :D
19:38 < chrisdickinson> so it implements a streaming interface too
19:38 < mikolalysenko> great!
19:38 < mikolalysenko> with backpressure?
19:38 < chrisdickinson> yep
19:38 < mikolalysenko> :D
19:39 < chrisdickinson> it's a little backpressure happy at the moment
19:39 < chrisdickinson> it works by setting paused to true every time you write data, and draining every time there's a heartbeat
19:39 < chrisdickinson> i'm open to suggestions on that one
19:39 < mikolalysenko> hmmm
19:39 < mikolalysenko> maybe give it a counter?
19:39 < chrisdickinson> sidenote: you can process.exit() inside of a worker now
19:39 < chrisdickinson> with a return code
19:39 < mikolalysenko> so it has like a backpressure buffer size
19:39 < mikolalysenko> cool!
19:40 < mikolalysenko> also, I had a crazy idea!  worker based stream filters
19:40 < chrisdickinson> yes this
19:40 < chrisdickinson> also, it'll try to use transfer instead of send by default on arraybuffers
19:40 < mikolalysenko> yeah, that is a good idea
21:46 < defunctzombie> is the npm registry having problems?
21:46 < ralphtheninja> defunctzombie: aye
21:50 < defunctzombie> sadness
21:50 < defunctzombie> hij1nx: ping
21:55 < defunctzombie> so we can't npm publish?
21:56 < ralphtheninja> guess so
21:56 < ralphtheninja> we need a p2p version of npm :)
21:57 < defunctzombie> heh
22:02 < evbogue> p2p npm = actually a very good idea.
22:02 < ralphtheninja> yes it is :)
22:03 < evbogue> npm remote origin http://npm.yourserver.com/
22:03 < evbogue> scuttlebutt syncs across servers
22:03 < evbogue> or appropriote database
22:03 < ralphtheninja> just ask the network for a certain module or a version of a module, or publish your stuff from your 'node'
22:04 < ralphtheninja> don't even have to have eventual consistency, if the module is in the network you'll find it
22:04 < evbogue> nice
22:09 < evbogue> how do we build this?
22:09 < evbogue> I vote we use node.
22:10 < ralphtheninja> I vote node as well
22:15 < Raynos> ehd: miko, I use browservefy for examples / demos now
22:53 < mikolalysenko> Raynos:  ok, maybe I will switch to browservefy too
23:15 < defunctzombie> mikolalysenko: wtf.. why were you not already using it?!
23:16 < defunctzombie> makes life so much simpler to just do it :)
23:16 < mikolalysenko> I had serverify!
23:17 < mikolalysenko> it is basically the exact same thing, except I was using it before I found out about browservefy
23:17 < defunctzombie> :)
23:17 < mikolalysenko> and I've been too lazy to switch my projects over
23:18 < mikolalysenko> https://github.com/mikolalysenko/Serverify
23:18 < mikolalysenko> as soon as npm gets back online it is going to get hammered by everyone publishing a shit load of stuff all at once
23:19 < Raynos> oh wait
23:19 < Raynos> is npm down?
23:19 < Raynos> wtf
23:19 < mikolalysenko> yeah
23:19 < mikolalysenko> has been all day
23:19 < mikolalysenko> can't publish :(
23:20 < mikolalysenko> there is an open issue and a pull request with a fix, but isaacs is nowhere to be seen
23:21 < Raynos> where is teh PR?
23:21 < mikolalysenko> https://github.com/isaacs/npmjs.org/issues/94
23:21 < mikolalysenko> https://github.com/isaacs/npmjs.org/pull/95
23:21 < ehd> tsk must be hoarders' fault
23:22 < mikolalysenko> haha, or maybe isaacs' fat fingers
23:22 < mikolalysenko> "verions"
23:22 < mikolalysenko> instead of "versions"
23:23 < ehd> i love me some jshint for avoiding those
23:23 < mikolalysenko> yeah, it happens
23:31 < defunctzombie> sigh
23:31 < defunctzombie> we cannot have a bus number of 1 on this stuff
23:31 < defunctzombie> this is pretty bad
23:38 < isaacs> substack: fixed the publish malfeasance
23:38 < defunctzombie> \o/
23:44 < mikolalysenko> yes!
23:46 < mikolalysenko> hmm
23:46 < mikolalysenko> I am still having issues pushing
23:47 < mikolalysenko> *publishing
--- Log closed Sun Feb 17 00:00:46 2013