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