| 00:00:00
| * ircretary | quit (Remote host closed the connection) |
| 00:00:08
| * ircretary | joined |
| 00:00:58
| * lyaunzbe_ | quit (Remote host closed the connection) |
| 00:05:20
| * ryan_stevens | quit (Ping timeout: 252 seconds) |
| 00:07:29
| * mikolalysenko | joined |
| 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
| * evbogue | joined |
| 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_luke | joined |
| 00:14:14
| * lyaunzbe | joined |
| 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_stevens | joined |
| 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_luke | quit (Remote host closed the connection) |
| 00:33:00
| * devaholic | quit (Remote host closed the connection) |
| 00:36:45
| * ryan_stevens1 | joined |
| 00:40:19
| * ryan_stevens | quit (Ping timeout: 260 seconds) |
| 00:51:18
| * tilgovi | quit (Remote host closed the connection) |
| 00:57:45
| * evbogue | quit (Remote host closed the connection) |
| 00:59:46
| * CryptoQuick_ | joined |
| 01:02:58
| * CryptoQuick | quit (Ping timeout: 244 seconds) |
| 01:02:58
| * CryptoQuick_ | changed nick to CryptoQuick |
| 01:07:38
| * CryptoQuick | quit (Quit: CryptoQuick) |
| 01:08:20
| * jden_ | joined |
| 01:08:44
| * jden_ | changed nick to Guest70663 |
| 01:11:33
| * ryan_stevens | joined |
| 01:13:54
| * ryan_stevens1 | quit (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_stevens | quit (Quit: Leaving.) |
| 01:43:26
| * ins0mnia | quit (Ping timeout: 252 seconds) |
| 01:43:58
| * lyaunzbe | quit (Remote host closed the connection) |
| 01:49:33
| * Guest70663 | quit (Ping timeout: 276 seconds) |
| 01:56:03
| * ryan_stevens | joined |
| 01:58:50
| * jden_ | joined |
| 01:59:07
| * mikeal | quit (Quit: Leaving.) |
| 01:59:14
| * jden_ | changed nick to Guest83359 |
| 02:30:09
| * ryan_stevens | quit (Quit: Leaving.) |
| 02:34:06
| * ralphtheninja | quit (Ping timeout: 252 seconds) |
| 02:48:36
| * mikeal | joined |
| 03:00:35
| * ryan_stevens | joined |
| 03:03:13
| * lyaunzbe | joined |
| 03:10:06
| * ryan_stevens | quit (Read error: Connection reset by peer) |
| 03:10:08
| * ryan_stevens1 | joined |
| 03:11:48
| * ryan_stevens1 | quit (Client Quit) |
| 03:13:07
| * tphummel | quit (Quit: tphummel) |
| 03:15:12
| * st_luke | joined |
| 03:21:58
| * ryan_stevens | joined |
| 03:22:30
| * mikolalysenko | quit (Ping timeout: 276 seconds) |
| 03:23:40
| * ryan_stevens | quit (Client Quit) |
| 03:25:06
| * ryan_stevens | joined |
| 03:30:33
| * ryan_stevens | quit (Quit: Leaving.) |
| 03:30:52
| * st_luke | quit (Remote host closed the connection) |
| 03:32:25
| * mikolalysenko | joined |
| 03:43:49
| * mikolalysenko | quit (Ping timeout: 256 seconds) |
| 03:48:46
| * Guest83359 | quit (Ping timeout: 245 seconds) |
| 04:04:23
| * mikolalysenko | joined |
| 04:04:51
| * dguttman | quit (Quit: dguttman) |
| 04:12:41
| * dguttman | joined |
| 04:22:06
| * mikolalysenko | quit (Ping timeout: 256 seconds) |
| 05:00:29
| * defunctzombie_zz | changed 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_stevens | joined |
| 05:27:39
| * defunctzombie | changed nick to defunctzombie_zz |
| 05:45:41
| * jden_ | joined |
| 05:46:05
| * jden_ | changed nick to Guest27189 |
| 05:54:23
| * CryptoQuick | joined |
| 06:29:33
| * AvianFlu | quit (Remote host closed the connection) |
| 06:35:31
| * dguttman | quit (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_stevens | quit (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
| * mikeal | quit (Read error: Connection reset by peer) |
| 09:08:26
| * mikeal | joined |
| 09:13:44
| <niftylettuce> | FIRST THEY IGNORE YOU, THEN LAUGH AT YOU, THEN FIGHT YOU, THEN YOU WIN. |
| 09:13:45
| <LOUDBOT> | YOU COMPLETE MY WAKEFUL NIGHTMARE |
| 09:16:15
| <jesusabdullah> | maan did the stizz really fall asleep on me? XD |
| 09:38:41
| * dguttman | joined |
| 09:42:08
| * ralphtheninja | joined |
| 10:08:20
| * dguttman | quit (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
| * Guest27189 | quit (Ping timeout: 264 seconds) |
| 11:28:36
| * yorick | joined |
| 11:31:01
| * jden_ | joined |
| 11:31:25
| * jden_ | changed nick to Guest7620 |
| 11:43:21
| * Guest7620 | quit (Ping timeout: 245 seconds) |
| 12:10:07
| * jden__ | joined |
| 12:12:12
| * ins0mnia | joined |
| 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
| * CryptoQuick | quit (Quit: CryptoQuick) |
| 13:06:50
| * Guest88373 | quit (Ping timeout: 256 seconds) |
| 13:16:24
| * mikolalysenko | joined |
| 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
| * mikolalysenko | quit (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
| * mikolalysenko | joined |
| 13:49:36
| * Guest74854 | quit (Ping timeout: 256 seconds) |
| 13:51:31
| * defunctzombie_zz | changed 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
| * jibay | joined |
| 13:58:24
| * defunctzombie | changed 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
| * AvianFlu | joined |
| 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
| * Guest60195 | quit (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
| * xaq | joined |
| 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
| * Guest75510 | quit (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
| * dguttman | joined |
| 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
| * shuaib | joined |
| 16:43:25
| <chrisdickinson> | mikolalysenko: https://github.com/chrisdickinson/bfy-worker |
| 16:45:59
| * mikolalysenko | quit (Ping timeout: 255 seconds) |
| 16:53:16
| * mikolalysenko | joined |
| 17:04:15
| * jden_ | joined |
| 17:04:39
| * jden_ | changed nick to Guest41095 |
| 17:19:48
| * dguttman | quit (Quit: dguttman) |
| 17:19:54
| * Guest41095 | quit (Ping timeout: 264 seconds) |
| 17:21:29
| * dguttman | joined |
| 17:24:27
| * dguttman | quit (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
| * spion | joined |
| 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
| * chrisdickinson | reads |
| 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_stevens | joined |
| 18:01:18
| * Guest10458 | quit (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_stevens | quit (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
| * mikeal | quit (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
| * mikeal | joined |
| 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
| * Guest58678 | quit (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
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 19:58:54
| * mikeal | quit (Quit: Leaving.) |
| 20:00:10
| * mikeal | joined |
| 20:03:15
| * Guest44264 | quit (Ping timeout: 248 seconds) |
| 20:06:21
| * mikolalysenko | joined |
| 20:20:20
| * xaq | quit (Remote host closed the connection) |
| 20:29:15
| * mikeal | quit (Quit: Leaving.) |
| 20:29:15
| * jden__ | joined |
| 20:42:59
| * AvianFlu | quit (Remote host closed the connection) |
| 20:43:09
| * jden__ | quit (Ping timeout: 276 seconds) |
| 20:59:28
| * mikeal | joined |
| 21:07:50
| * ryan_stevens | joined |
| 21:08:26
| * mikeal | quit (Ping timeout: 255 seconds) |
| 21:08:41
| * jden_ | joined |
| 21:09:05
| * jden_ | changed nick to Guest24301 |
| 21:10:57
| * dguttman | joined |
| 21:15:18
| * mikeal | joined |
| 21:16:06
| * mikeal | quit (Client Quit) |
| 21:18:05
| * AvianFlu | joined |
| 21:21:42
| * Guest24301 | quit (Ping timeout: 264 seconds) |
| 21:26:40
| * ryan_stevens | quit (Quit: Leaving.) |
| 21:30:56
| * AvianFlu | quit (Remote host closed the connection) |
| 21:32:28
| * ryan_stevens | joined |
| 21:33:19
| * mikeal | joined |
| 21:36:30
| * devaholic | joined |
| 21:40:06
| * defunctzombie_zz | changed 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
| * evbogue | joined |
| 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_stevens | quit (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
| * AvianFlu | joined |
| 22:48:40
| * CryptoQuick | joined |
| 22:48:54
| * mikeal | quit (Quit: Leaving.) |
| 22:50:01
| <mikolalysenko> | Raynos: ok, maybe I will switch to browservefy too |
| 23:03:55
| * mikeal | joined |
| 23:04:12
| * mikeal | quit (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
| * dguttman | quit (Ping timeout: 260 seconds) |
| 23:24:11
| * evbogue | quit (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
| * mikeal | joined |
| 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 |
| 23:59:53
| <LOUDBOT> | LIMES ARE REALLY JUST UNRIPENED LEMONS |