00:09:42
| * yorick | quit (Remote host closed the connection) |
00:22:10
| <jjjohnnny> | can i get one of these at IKEA? |
00:22:13
| <jjjohnnny> | http://www.synthtopia.com/content/2012/11/07/the-mr-808-is-an-808-style-mechanical-robot-drum-machine/ |
00:23:17
| * shuaib | quit (Ping timeout: 255 seconds) |
00:25:39
| * shuaib | joined |
00:26:02
| <st_luke> | substack: got my html5 shirt, looks good. |
00:26:36
| <substack> | nice |
00:27:11
| <substack> | finishing secure-peer replay attack protection here |
00:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 61] |
00:33:15
| <st_luke> | oh man, just realized I can integrate seaport, fleet, and propagit into the company infrastructure soon |
00:34:18
| <st_luke> | I'm using a decently powered server now for dev, I think I want to scale down and use a bunch of tiny VMs dispersed around the globe for this app |
00:37:55
| <substack> | :D |
00:38:14
| <substack> | distribute state with crdt/scuttlebutt too |
00:38:24
| <substack> | eventual consistency was never SO EASY |
00:39:09
| * sorensen_ | joined |
00:40:11
| <substack> | st_luke: the next version of fleet is going to use secure-peer all over the place |
00:40:13
| * sorensen_ | quit (Read error: Connection reset by peer) |
00:40:19
| <substack> | for auth and for crypto |
00:40:27
| <st_luke> | substack: I thought that might happen eventually |
00:40:31
| <substack> | since it's basically a really light weight version of ssh |
00:40:45
| <substack> | where every node can be a server or a client |
00:40:50
| <substack> | p2pssh |
00:42:34
| * _sorensen | quit (Ping timeout: 240 seconds) |
00:43:19
| <jjjohnnny> | p2psshaw |
00:44:20
| <st_luke> | "Can the father of C# save us from the tyranny of JavaScript" |
00:44:29
| <st_luke> | I hope the guy that wrote that article drives into a ditch |
00:44:40
| <fotoverite> | FUUUU |
00:44:44
| <fotoverite> | Really that's just... |
00:48:00
| * fotoverite | quit (Quit: fotoverite) |
00:52:01
| <st_luke> | substack: I would buy a gossip protocol shirt |
00:53:33
| <st_luke> | it would be cool to use the svg version of that picture to make a visual representation by adding more xml that represents the humanoid figures in the picture |
00:53:45
| <st_luke> | programmatically |
00:59:50
| <substack> | ok I just wrote a failing test that did a replay attack against secure-peer and then I fixed it |
00:59:56
| <substack> | next doing an ordering attack |
01:00:00
| <substack> | related |
01:00:07
| <substack> | I need a sequence id I think |
01:11:32
| * tilgovi | quit (Remote host closed the connection) |
01:11:44
| * fotoverite | joined |
01:15:29
| * thatguydan | quit (Ping timeout: 255 seconds) |
01:18:00
| * thatguydan | joined |
01:27:56
| <rowbit> | Hourly usage stats: [developer: 3, free: 39] |
01:30:21
| <jden> | I made a thing. http://things.aretheanswerwhatwasthequestion.com |
01:32:27
| <dominictarr> | substack, can you merge this https://github.com/substack/node-browserify/pull/235 ? |
01:33:58
| <substack> | yep one sec |
01:34:13
| <substack> | ok so I just pushed [email protected] |
01:34:20
| <substack> | it fixes the replay and ordering attacks |
01:34:28
| <substack> | I wrote failing tests that implement those attacks successfully |
01:36:00
| <dominictarr> | sweet |
01:36:49
| * fotoverite | quit (Quit: fotoverite) |
01:37:49
| * deirdres | quit (Quit: deirdres) |
01:37:50
| <substack> | https://github.com/substack/secure-peer/blob/master/test/ordering.js |
01:37:53
| <substack> | https://github.com/substack/secure-peer/blob/master/test/replay.js |
01:38:19
| <substack> | it was crazy to see these tests fail and the attacks succeed |
01:38:36
| <substack> | I'm leveling the fuck up in crypto wizard levels right now |
01:45:32
| <dominictarr> | haha, awesome. |
01:46:04
| <dominictarr> | gonna go eat |
01:46:08
| <dominictarr> | catch you dudes later |
01:50:03
| <Raynos> | substack: +1 on string_decoder |
01:50:14
| * dominictarr | quit (Ping timeout: 240 seconds) |
01:50:41
| <isaacs> | Raynos: what's that about string_decoder? |
01:50:56
| <Raynos> | isaacs: making browserify with require("string_decoder") work |
01:51:02
| <isaacs> | Raynos: oh,browser stuff |
01:51:05
| <isaacs> | ;P |
01:51:08
| <Raynos> | otherwise readable-stream breaks |
01:51:14
| <isaacs> | dude, i've been sanding down edges like craaaazy in streams2 |
01:51:15
| <Raynos> | https://github.com/substack/node-browserify/pull/235 https://github.com/Raynos/node-browserify/commit/a35c58c93aa48bff14ab3794d12e036ec3768a0d |
01:51:23
| <isaacs> | i've gotta port all that stuff over to the readable-stream repo |
01:51:42
| <Raynos> | isaacs: I've been bending my head around FRP and signals and want to use that as an alternative to synthetic userland streams |
01:51:54
| <isaacs> | Raynos: frp? |
01:51:59
| <Raynos> | functional reactive programming |
01:52:24
| <Raynos> | Oh btw mdb + ::findjsobjects is madness |
01:52:35
| <Raynos> | Not enough madness to make finding memory leaks trivial but enough madness to be like woh. |
01:54:40
| <Raynos> | Gozala has an implementation of FRP signals ( https://github.com/gozala/signalize#signalize ) |
01:59:57
| <substack> | this bug down https://github.com/substack/secure-peer/issues/4 https://github.com/substack/secure-peer/blob/master/test/mitm_end.js |
02:02:06
| * CoverSlide|TPFR | quit (Ping timeout: 245 seconds) |
02:02:28
| <isaacs> | Raynos: yeah, ::findjsobjects |
02:02:33
| <isaacs> | Raynos: it's powerful juju, for sure |
02:02:40
| <Raynos> | im trying to use -r |
02:02:45
| <Raynos> | but it doesnt tell me where they are referenced |
02:02:57
| <Raynos> | Ideally I want it to tell me which closure is this object in |
02:03:01
| <Raynos> | because its in the heap |
02:03:04
| <Raynos> | so someone has a reference to it |
02:03:54
| * CoverSlide|TPFR | joined |
02:08:41
| <Raynos> | isaacs: I see why you like constructor functions |
02:08:49
| <Raynos> | Type information in mdb is the best |
02:09:24
| <isaacs> | Raynos: yeah, i've learned that you tend to win a lot, in surprising and delightful ways, by going with the grain of your programming language. |
02:09:39
| <Raynos> | you mean with the grain of v8 |
02:10:40
| <substack> | I like constructor functions for keeping the indentation level down |
02:11:33
| <Raynos> | how do they keep indentation down? |
02:13:19
| <substack> | F.prototype.foo = function () { |
02:13:27
| <substack> | | <-- 1 indent |
02:13:49
| <substack> | { |
02:13:55
| <substack> | foo : function () { |
02:13:59
| <substack> | | <-- 2 indents |
02:24:33
| * shykes | changed nick to zz_shykes |
02:24:39
| <substack> | ok all crypto issues fixed except for the possibility of the oracle attack |
02:26:13
| * zz_shykes | changed nick to shykes |
02:27:56
| <rowbit> | Hourly usage stats: [developer: 6, free: 24] |
02:44:45
| * st_luke | quit |
02:46:28
| * jibay | quit (Quit: Leaving) |
02:50:56
| * st_luke | joined |
02:52:10
| <niftylettuce> | upvotes plz! http://news.ycombinator.com/newest "Show HN: PinPigeon - Send pins as printed & shipped postcards for only 1.95" :) <3 |
02:52:45
| <niftylettuce> | substack pkrumins chapel chadskidmore AvianFlu paul_irish jesusabdullah mikeal ryanseddon tanepiper ^^ |
02:53:16
| <niftylettuce> | built with express/jade/mongoose/redis/sincerely/stripe and bouncy |
02:53:20
| <niftylettuce> | request to |
02:53:22
| <niftylettuce> | too* |
03:00:25
| * shykes | changed nick to zz_shykes |
03:10:59
| * mikeal | quit (Quit: Leaving.) |
03:11:27
| * st_luke | quit (Remote host closed the connection) |
03:11:50
| * mikeal | joined |
03:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 23] |
03:29:41
| <substack> | bah ruby bros https://twitter.com/bascule/status/266731250344132608 |
03:39:00
| * eagsalazar | joined |
03:39:24
| <eagsalazar> | Hi, I downgraded my account via email in May but it looks like I was still being charged. |
03:39:42
| <substack> | eagsalazar: oh no, what's your email address? |
03:39:52
| <eagsalazar> | np, [email protected] |
03:40:36
| <eagsalazar> | I got a confirmation email on May 16th from James Halliday [email protected] |
03:41:12
| <substack> | yes I see it from my email records |
03:42:07
| <substack> | whoa so this is odd |
03:42:19
| <substack> | you cancelled on the 12th |
03:42:45
| <substack> | but the furthest back record I can see is 2012/05/29 ! |
03:43:10
| <substack> | not sure how you can cancel before we started billing you unless there was a glitch somewhere |
03:43:18
| <substack> | anyhow I'm refunding all the transactions right now |
03:43:20
| <eagsalazar> | not sure, maybe |
03:43:25
| <eagsalazar> | Cool thanks a lot |
03:44:28
| * tphummel | quit (Quit: tphummel) |
03:44:46
| <substack> | ok account closed, charges refunded |
03:45:08
| <substack> | really sorry about that, looks like you slipped through the cracks somehow! |
03:45:24
| * zz_shykes | changed nick to shykes |
03:48:35
| <eagsalazar> | np |
03:48:41
| * eagsalazar | quit (Quit: Page closed) |
03:59:10
| * st_luke | joined |
04:09:38
| <substack> | haha I have 91 projects in travis right now |
04:21:11
| <st_luke> | $0.00 per month |
04:21:11
| <substack> | https://gist.github.com/4043667 |
04:21:12
| <st_luke> | good deal |
04:21:15
| <substack> | yes |
04:21:29
| <substack> | I would give them money if I had money to throw around at such things |
04:21:54
| <substack> | st_luke: check this out https://twitter.com/bascule/status/266731250344132608 |
04:22:10
| <substack> | epitome of ruby bro culture |
04:22:24
| <st_luke> | wow |
04:22:38
| <substack> | interesting anthropological specimen |
04:23:05
| <st_luke> | but a fairly shitty human being |
04:23:26
| <substack> | their culture values such things |
04:23:53
| <substack> | it makes sense since ruby is just one gigantic cargo cult |
04:24:03
| <st_luke> | yeah, I've unfortunately had a lot of up close experience with people like that in the ruby community |
04:24:25
| <substack> | poor fotoverite |
04:25:02
| <st_luke> | I don't even know what the fuck their end game is |
04:25:21
| <substack> | ruby? |
04:25:30
| <st_luke> | yeah ruby programmers like that |
04:25:47
| <substack> | they'll just keep building mile-high abstractions that fall over themselves |
04:26:11
| <st_luke> | no idea what the fuck drives them other than money and high horses |
04:26:16
| <substack> | instead of hunting for the right abstractions independently from everything else |
04:27:15
| <substack> | I like to think of programming like being a detective following the clues to see what solution reality is converging towards |
04:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 10] |
04:28:03
| <substack> | but you can't do that in the context of a big sprawling project |
04:28:17
| <st_luke> | no you can't |
04:28:21
| <substack> | you can only do that when you filter out everything else that is unimportant |
04:28:50
| <st_luke> | I'm reading through some of this guy's other tweets. he's a grade A piece of shit. |
04:29:36
| <substack> | anyhow are you doing node knockout? |
04:30:05
| <st_luke> | oh, he's that guy that wrote that blog post in august about why rails is great for everything ever. |
04:30:09
| <st_luke> | yeah, I signed up for it |
04:30:13
| * fotoverite | joined |
04:30:19
| <st_luke> | I had some ideas about what to do but they're not exciting enough and just basic web apps |
04:31:21
| * fotoverite | quit (Client Quit) |
04:32:34
| <st_luke> | will need to think of something really good or I might withdraw my team so someone else can sign up |
04:36:57
| <substack> | correction: actually 95 repos |
04:37:11
| <st_luke> | is github's notification system barely functioning for anyone else? |
04:39:39
| <substack> | seems to work ok |
04:40:24
| <st_luke> | I get comments on things and no web notifications |
04:42:36
| <st_luke> | oh well |
04:43:19
| <st_luke> | maybe I'll write something with their api and do my own notifications |
04:43:43
| <substack> | do it |
04:43:52
| <substack> | that could be a knockout entry |
04:44:37
| <st_luke> | yes. It would need a cool front end because that's what seems to do well in nko, but I might be able to do some cool visualizations with d3 for it |
04:45:33
| <substack> | wouldn't it be mostly a frontend? |
04:46:04
| <st_luke> | actually yes |
04:46:45
| <st_luke> | it would feel weird to enter a node contest with only a very basic back end though |
04:49:35
| <st_luke> | markdown is the only sensible choice for writing a résumé |
05:27:56
| <rowbit> | Daily usage stats: [developer: 46, free: 140] |
05:27:57
| <rowbit> | Hourly usage stats: [developer: 0, free: 39] |
05:37:37
| <st_luke> | substack: I just saw your website's 500 error |
05:38:12
| <st_luke> | the look on the robot's face is relatable |
05:40:29
| * anoemi | quit (Quit: anoemi) |
06:08:04
| * shykes | changed nick to zz_shykes |
06:19:27
| * rannmann | quit (Ping timeout: 260 seconds) |
06:27:56
| <rowbit> | Hourly usage stats: [developer: 4, free: 59] |
06:40:13
| * AvianFlu | quit (Remote host closed the connection) |
06:45:01
| * zz_shykes | changed nick to shykes |
07:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 57] |
07:39:39
| * mikeal | quit (Quit: Leaving.) |
07:41:00
| * mikeal | joined |
07:55:09
| * dominictarr | joined |
08:08:14
| <substack> | dominictarr: pull req merged |
08:08:55
| <dominictarr> | sweet |
08:15:16
| <substack> | 58 stars on secure-peer already O_O |
08:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 27] |
08:31:45
| <dominictarr> | yeah, I got 11 retweets on my link to it. |
08:33:05
| <substack> | it's still trending on http://github.com/explore even |
08:37:08
| <substack> | dominictarr: also hater bros are hilarious https://twitter.com/bascule/status/266731250344132608 |
08:38:07
| * substack | zzz & |
08:39:40
| <dominictarr> | clearly, loads of people want this... |
08:40:00
| <substack> | because giant apps like openssh are such a pain to work with |
08:40:13
| <substack> | or even just tls is far too complicated |
08:40:26
| <substack> | and not symmetric so not well suited for peer to peer |
08:44:25
| * dominictarr | quit (Ping timeout: 246 seconds) |
09:20:19
| * fotoverite | joined |
09:26:23
| * thatguydan | quit (Quit: thatguydan) |
09:27:56
| <rowbit> | Hourly usage stats: [developer: 3, free: 16] |
10:05:47
| * saijanai_ | quit (Ping timeout: 260 seconds) |
10:27:56
| <rowbit> | Hourly usage stats: [developer: 3, free: 38] |
10:28:30
| * shykes | changed nick to zz_shykes |
11:05:26
| * yorick | joined |
11:05:26
| * yorick | quit (Changing host) |
11:05:27
| * yorick | joined |
11:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 25] |
11:37:25
| <mbalho> | substack: that bascule guy sucks |
11:38:23
| * zz_shykes | changed nick to shykes |
11:40:46
| <mbalho> | substack: also it should be spelled haqueria |
11:41:12
| <mbalho> | substack: is hackistanza a combination of hack, pakistan, stanza and tony danza? |
11:43:14
| * shykes | changed nick to zz_shykes |
12:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 49] |
13:16:13
| * rannmann | joined |
13:16:13
| * rannmann | quit (Changing host) |
13:16:13
| * rannmann | joined |
13:21:47
| * AvianFlu | joined |
13:27:56
| <rowbit> | Hourly usage stats: [developer: 8, free: 47] |
13:36:54
| * dominictarr | joined |
14:09:32
| <dominictarr> | substack, and there is soooo much painful config. |
14:10:02
| <dominictarr> | I just want to add a secure backdoor repl into my app, etc. |
14:11:31
| * AvianFlu | quit (Remote host closed the connection) |
14:14:18
| * jibay | joined |
14:21:45
| <guybrush> | well until now i just used tls |
14:23:31
| <guybrush> | i mean for repl-stuff |
14:24:27
| <guybrush> | though this secure-peer is super interesting, i agree _lots_ of people are looking for such a thing |
14:24:49
| <guybrush> | now when p2p will get bigger and bigger |
14:27:56
| <rowbit> | Hourly usage stats: [developer: 2, free: 39] |
14:37:58
| <mbalho> | substack: i wanna make an open seaport registry for registering worker processes |
14:38:16
| <mbalho> | substack: and when a worker process connects it can ask to get given a job to do |
14:38:33
| <mbalho> | substack: and ensure that another worker wont start the same job |
14:40:13
| <mbalho> | substack: which module is best for election stuff? |
14:40:18
| <mbalho> | dominictarr: cc o/ |
14:40:29
| <dominictarr> | mbalho, hey whats up? |
14:40:46
| <mbalho> | dominictarr: tryin to have a central stateful queue with distributed workers who get assigned tasks |
14:41:05
| <mbalho> | dominictarr: without duplication of tasks (or minimized duplication) |
14:41:32
| <dominictarr> | I'm interested in minimizied duplication. |
14:41:51
| <dominictarr> | what if a worker could realize it's duplicated and then just stop. |
14:41:55
| <mbalho> | yea exactly |
14:42:08
| <mbalho> | seems like a service registry + scuttlebutt |
14:42:15
| <dominictarr> | the work would need to have the right property, |
14:42:23
| <mbalho> | scuttlebutt would replicate the list of in process tasks |
14:42:29
| <dominictarr> | probably wouldn't work for, say, credit card processing jobs. |
14:42:43
| <dominictarr> | yeah, exactly. |
14:42:49
| <mbalho> | im trying to write a generic version of [email protected] basically |
14:42:54
| <mbalho> | so the central server has a list of tasks |
14:43:02
| <mbalho> | and worker nodes connect and get assigned work |
14:43:06
| <mbalho> | when they complete work they get more work |
14:43:34
| <mbalho> | hmm maybe im overcomplicating |
14:43:42
| <mbalho> | since i could just do a round robin thing on the server |
14:43:54
| <mbalho> | with a timeout that puts a job back in the queue if it never returns |
14:44:42
| <dominictarr> | what sort of thing are you gonna use it for? |
14:45:26
| <dominictarr> | one way to think about it: jobs are just temporary services. |
14:45:38
| <mbalho> | so i wanna have a api that you can post web scrapers |
14:45:38
| <dominictarr> | hmm... no that is not really right... |
14:45:40
| <mbalho> | similar to scraperwiki |
14:45:48
| <dominictarr> | oh, right. |
14:45:53
| <dominictarr> | that sounds useful. |
14:46:02
| <mbalho> | so you post the scraper and then anyone can volunteer to help scrape |
14:46:23
| <dominictarr> | that is cool. |
14:46:34
| <dominictarr> | where would the scraped data end up? |
14:47:28
| <dominictarr> | does it get sent back to the user? |
14:50:31
| <mbalho> | yea probably a webhook or soomething |
14:51:17
| <dominictarr> | right, it probably becomes another job in their system. |
14:51:34
| <dominictarr> | but, about putting it in the data base, and deciding what to do next. |
14:51:50
| <dominictarr> | I think this is called "workflow" |
14:53:19
| <mbalho> | dominictarr: im in london hacking with @okfn |
14:53:32
| <mbalho> | dominictarr: and they have a thing called crowdcrafting.com |
14:53:44
| <mbalho> | crowdcrafting.org |
14:53:50
| <mbalho> | its basically an open source mechanical turk |
14:54:06
| <dominictarr> | ah, interesting. |
14:54:12
| <mbalho> | and im trying to add a web scraper version to their existing UI |
15:16:41
| <mbalho> | "Google is blessing @substack" |
15:16:48
| <mbalho> | https://twitter.com/janl/status/266921395089440768 |
15:21:51
| <guybrush> | mbalho: i think this tweet is related to http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html -- https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver |
15:22:35
| <mbalho> | guybrush: its related to https://github.com/GoogleChrome/net-chromeify |
15:22:59
| <guybrush> | ah i see |
15:23:06
| <guybrush> | nice |
15:26:04
| * jden | changed nick to jden|away |
15:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 36] |
15:36:06
| * LOUDBOT | quit (Ping timeout: 240 seconds) |
16:11:38
| * _sorensen | joined |
16:17:39
| <fotoverite> | Node Knockout! |
16:19:46
| * anoemi | joined |
16:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 49] |
16:28:37
| * ircretary | quit (Remote host closed the connection) |
16:28:45
| * ircretary | joined |
16:31:09
| * ircretary | quit (Remote host closed the connection) |
16:31:16
| * ircretary | joined |
16:32:29
| * ircretary | quit (Remote host closed the connection) |
16:32:36
| * ircretary | joined |
16:34:20
| * ircretary | quit (Remote host closed the connection) |
16:34:28
| * ircretary | joined |
16:35:00
| * fotoverite | quit (Quit: fotoverite) |
16:36:51
| * dominictarr | quit (Ping timeout: 260 seconds) |
16:36:59
| * ircretary | quit (Remote host closed the connection) |
16:37:06
| * ircretary | joined |
16:37:23
| * anoemi | quit (Quit: anoemi) |
16:38:58
| <isaacs> | [email protected][email protected][email protected] |
16:39:15
| * zz_shykes | changed nick to shykes |
16:41:04
| * shykes | changed nick to zz_shykes |
16:42:11
| * zz_shykes | changed nick to shykes |
16:46:33
| * yorick | quit (Read error: Connection reset by peer) |
16:57:44
| <substack> | mbalho: just use a distributed algorithm to pick which worker should get a job since all the workers have the complete list of all the other works from seaport https://github.com/substack/node-marx |
16:58:39
| <substack> | just run marx against the results of a .query() for some job hash |
16:59:51
| * shykes | changed nick to zz_shykes |
17:01:59
| <mbalho> | substack: WOOT MARK |
17:02:16
| <mbalho> | substack: is there a module that does a stream API on top of websockets? like shoe without the fallbacks |
17:02:32
| <mbalho> | substack: tried binaryjs but it is too complex also |
17:03:18
| <substack> | I don't know of any |
17:03:37
| <mbalho> | dang! |
17:04:30
| <mbalho> | substack: that is dumb |
17:05:02
| <mbalho> | substack: ooh https://npmjs.org/package/webstream |
17:06:06
| <mbalho> | dangit https://github.com/eladb/node-webstream/blob/master/lib/webstream-client.js |
17:06:50
| * fotoverite | joined |
17:07:55
| <mbalho> | i dont think that works in a browser... |
17:14:01
| * fotoverite | quit (Quit: fotoverite) |
17:27:56
| <rowbit> | Hourly usage stats: [developer: 0, free: 44] |
17:45:04
| * juliangruber_ | joined |
17:46:36
| <substack> | Raynos: npm-used is pretty amusing |
17:46:37
| <substack> | just found it |
17:48:57
| <juliangruber_> | haha :D |
17:53:32
| * anoemi | joined |
18:07:47
| * anoemi_ | joined |
18:08:02
| * anoemi | quit (Read error: Connection reset by peer) |
18:08:03
| * anoemi_ | changed nick to anoemi |
18:10:44
| * juliangruber_ | quit (Quit: juliangruber_) |
18:27:05
| <Raynos> | substack: the problem is you need to know what communities contain interesting things |
18:27:14
| * zz_shykes | changed nick to shykes |
18:27:19
| <Raynos> | substack: Idealy I want to build something similar but npm-local-search within those "communities" |
18:27:47
| <Raynos> | mbalho: refactor shoe so you can pass it in a websocket like object |
18:27:56
| <rowbit> | Hourly usage stats: [developer: 2, free: 45] |
18:28:22
| * tomshreds | joined |
18:28:24
| <substack> | mbalho: fork shoe and rip out the sockjs part in favor of webstream + WebSocket |
18:31:51
| * fotoverite | joined |
18:31:56
| <fotoverite> | My speaker deck |
18:31:57
| <fotoverite> | https://speakerdeck.com/fotoverite/tyranny-of-choice |
18:35:33
| <Raynos> | substack: actually I need to fix shoe so it simply does the "take websocket like interface and return stream" |
18:35:51
| <Raynos> | substack: because webrtc datachannels are a websocket like interface |
18:38:35
| <Raynos> | fotoverite: o/ |
18:39:01
| <fotoverite> | \o |
18:45:45
| * AvianFlu | joined |
18:46:13
| <Raynos> | fotoverite: even though that quote is correct, layers are dangerous as well |
18:46:35
| <Raynos> | every layer adds a lot of complexity |
18:48:07
| <Raynos> | what you want to do is periodically smash all the layers |
18:48:10
| <Raynos> | and start from scratch |
18:48:21
| <Raynos> | or build smaller layers |
18:49:00
| <Raynos> | like for example crdt is complex |
18:49:08
| <Raynos> | build a smaller thing on top of scuttlebutt thats less complex |
18:49:58
| <Raynos> | Actually you know what's even better |
18:50:02
| <Raynos> | not layering everything |
18:50:11
| <Raynos> | flat horizontal composability |
18:50:17
| <Raynos> | which is what makes streams good |
18:57:14
| <isaacs> | thoughts? https://gist.github.com/4047419 |
19:00:05
| <substack> | Raynos: if you want websockets without fallbacks you shouldn't need to bundle the fallback logic |
19:00:11
| <substack> | just release that as a separate module |
19:00:47
| <Raynos> | substack: true but want shoe(ws) -> stream and shoe(Sock.whatever()) -> stream |
19:02:24
| * mikeal | quit (Quit: Leaving.) |
19:02:49
| <Raynos> | and drops all the written data for requests that don't get a response. |
19:02:53
| * mikeal | joined |
19:02:56
| <Raynos> | isaacs: what type of requests dont get responses? |
19:04:17
| <Raynos> | isaacs: https://gist.github.com/4047419#L55 forgot a .bind(this) |
19:04:59
| <Raynos> | or does event emitter make the value of this be the event emitter |
19:05:19
| <Raynos> | Oh it does |
19:05:50
| <Raynos> | https://gist.github.com/4047419#L39 all of those seem annoying |
19:05:58
| <Raynos> | those should be weakmaps |
19:07:28
| * tilgovi | joined |
19:08:55
| <fotoverite> | Can't concentrate still shaking from talk. |
19:09:17
| <fotoverite> | I agree horizontal is good, but you can't include so many different thoughts. Easier to talk about small decoupled modules then all the different ways to combine |
19:10:38
| <Raynos> | True |
19:10:42
| <Raynos> | but the ways to combine are simple |
19:10:46
| <Raynos> | composition techniques |
19:10:58
| <fotoverite> | Yes but one talk at a time |
19:10:59
| <Raynos> | of which there are currently two functional & Stream.pipe |
19:11:01
| <Raynos> | :D |
19:15:32
| <isaacs> | Raynos: you don't have to .bind(this) for event handlers. |
19:15:48
| <isaacs> | Raynos: they're bound to the ee by default |
19:16:05
| <substack> | fotoverite: good slides |
19:16:07
| <isaacs> | Raynos: 304 responses, 206 responses, and responses to HEAD requests cannot get a body |
19:16:22
| <isaacs> | s/don't get a response/don't get a response body/ |
19:19:44
| * mikeal | quit (Quit: Leaving.) |
19:20:42
| * mikeal | joined |
19:27:56
| <rowbit> | Hourly usage stats: [developer: 1, free: 47] |
19:40:53
| * tphummel | joined |
19:41:06
| * tphummel | quit (Client Quit) |
19:42:46
| * tphummel | joined |
19:46:43
| * mikeal | quit (Quit: Leaving.) |
19:47:02
| * mikeal | joined |
19:47:36
| * shykes | changed nick to zz_shykes |
19:50:16
| * mikeal | quit (Client Quit) |
20:19:33
| * mikeal | joined |
20:27:56
| <rowbit> | Hourly usage stats: [developer: 2, free: 59] |
20:28:06
| * anoemi | quit (Quit: anoemi) |
20:32:44
| * mikeal | quit (Quit: Leaving.) |
20:45:30
| * tilgovi | quit (Remote host closed the connection) |
20:50:07
| <substack> | Raynos: renaming our repo, they fucked it up |
20:50:32
| <substack> | RENAME COMPLETE |
20:50:57
| <substack> | what were they using, a varchar(20) or something |
20:53:18
| <substack> | https://github.com/nko3/teh-wizzards-of-streamz |
20:57:29
| * zz_shykes | changed nick to shykes |
21:01:32
| * mikeal | joined |
21:02:14
| * shykes | changed nick to zz_shykes |
21:03:43
| <substack> | blarg actually it's probably a thing that they need to be in a place nevermind putting it back |
21:06:50
| <AvianFlu> | substack: I was just gonna say, your jitsu username for nko is gonna be exactly whatever that is, for better or worse |
21:11:55
| <substack> | blarg lame |
21:12:11
| <substack> | who truncates data anymore! |
21:17:12
| <substack> | /!\ idea for copters /!\ |
21:17:27
| <substack> | using peer-stream on quadcopters to build an scp/ssh thing |
21:17:50
| <substack> | also I want to do git push deploys to my copter |
21:17:55
| <substack> | could use git-stream for that probs |
21:18:37
| * jibay_ | joined |
21:19:48
| * jibay | quit (Ping timeout: 248 seconds) |
21:22:23
| <AvianFlu> | hilarious |
21:22:33
| <AvianFlu> | substack: wait, git-stream? |
21:22:36
| <AvianFlu> | whose is that? |
21:22:49
| <substack> | hij1nx |
21:23:25
| <fotoverite> | LoL |
21:23:29
| <fotoverite> | That really sucks |
21:26:03
| <AvianFlu> | ? |
21:26:16
| <fotoverite> | the renaming of the repo |
21:27:07
| * dominictarr | joined |
21:27:56
| <rowbit> | Hourly usage stats: [developer: 4, free: 28] |
21:36:51
| <substack> | dominictarr: your talk is at 17:00? [y/n] |
21:36:56
| <dominictarr> | Y |
21:37:16
| <substack> | neat I'll try to watch from over at joyent |
21:37:25
| <rowbit> | /!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\ |
21:37:25
| <rowbit> | /!\ ATTENTION: (default-local) paid account successfully upgraded /!\ |
21:37:30
| <substack> | yay money |
21:43:26
| <fotoverite> | Gay turbo links reminds me why Rails is a dead end. |
21:43:34
| <fotoverite> | god |
21:43:53
| <fotoverite> | Meant to say God turbo. What the hells is wrong with my keyboard. :( |
21:44:49
| <dominictarr> | your keyboard is a biggot |
21:45:08
| <fotoverite> | Yes yes it is. |
21:45:10
| <fotoverite> | Bad keyboard |
21:45:14
| * mike-d | quit (Read error: Connection reset by peer) |
21:45:27
| * mike-d | joined |
21:46:40
| <fotoverite> | Asset pipeline all over again. Node needs to always be kept small. |
21:47:10
| <substack> | ok after node knockout I'll rip out all the middleware cruft in browserify and make people use a plugin if they want automatic coffee-script compilation |
21:47:24
| <substack> | and bump the major to 2.0.0 |
21:47:36
| <fotoverite> | That makes sense |
21:48:47
| <substack> | I had not yet fully developed my aesthetic sense for module scope when I started browserify |
21:49:53
| <substack> | I had also not yet realized how harmful it can be for long-term maintainability and layering to include common things that people usually use |
21:51:01
| <substack> | also once I rip out that stuff I'll try to use defunktzombie's require data structure module |
21:51:17
| <substack> | then browserify can just be a lib that transforms those structures into bundles |
21:51:45
| <substack> | and plugins can just be other programs in a unix pipeline that modify the json structure |
21:53:09
| <substack> | browserify main.js --json | plugin1 | plugin2 | browserify --json > bundle.js |
21:53:14
| <substack> | DUPLEX STREAMS IN THE SHELL |
21:53:17
| <substack> | dominictarr: ^^^^ |
21:53:23
| * zz_shykes | changed nick to shykes |
21:53:43
| * mikeal | quit (Quit: Leaving.) |
21:53:53
| <Raynos> | substack: no rename? |
21:54:37
| <dominictarr> | the second browserify shouldn't have --JSON option, I think. |
21:54:58
| <dominictarr> | right? |
21:55:03
| <substack> | dominictarr: but it needs to be told to reason json instead of expecting javascript |
21:55:08
| <substack> | *to read |
21:55:24
| <dominictarr> | just check if stdio is tty |
21:55:29
| <dominictarr> | stdin |
21:55:32
| <dominictarr> | i mean |
21:55:39
| <substack> | maybe |
21:55:50
| <substack> | could work well actually |
21:56:09
| <substack> | browserify main.js --json | plugin1 | plugin2 | browserify > bundle.js |
21:56:11
| <dominictarr> | hmm, if there is no main.js then you could assume input is coming |
21:56:11
| <substack> | yes I like that |
21:56:16
| * mikeal | joined |
21:56:36
| <substack> | well if somebody just types `browserify` on a tty showing the help message seems good |
21:56:48
| <dominictarr> | yes. |
21:57:07
| <substack> | and if you want the help message on a non-tty you just need to explicitly --help |
21:57:18
| <dominictarr> | yeah. |
21:57:36
| <substack> | going to be the unixiest shit ever |
21:57:40
| <substack> | in the best possible way |
21:58:05
| <dominictarr> | what about plugins that transform source? |
21:58:16
| <dominictarr> | hmm, you could put that in the JSON? |
21:58:32
| <substack> | !. the source could be in the json |
21:58:35
| <substack> | 1. the source could be in the json |
21:59:04
| <substack> | 2. browserify main.json --json | plugin1 | browserify --plugin plugin2 | browserify > bundle.js |
21:59:13
| * mike-d | quit (Read error: Connection reset by peer) |
21:59:23
| <substack> | or perhaps not --plugin but --source-plugin? |
21:59:31
| * mike-d | joined |
21:59:44
| <substack> | anyways using browserify itself to read each file from the incoming json and execute a user-specified command |
21:59:55
| <dominictarr> | oh, right. |
22:00:07
| <dominictarr> | browserify --transform cmd |
22:00:32
| <substack> | yes |
22:00:41
| <substack> | so browserify --transform plugin2 |
22:00:52
| <substack> | could execute `plugin2 filename` and write the file contents to stdout |
22:01:14
| <substack> | and perhaps put more metadata into additional arguments |
22:03:06
| <dominictarr> | so like, plugins are minifiers, and stuff? |
22:03:37
| <substack> | could be anything! |
22:03:37
| <dominictarr> | hmm, and I guess the bundler itself is just a plugin, more or less? |
22:03:38
| <substack> | yep |
22:03:59
| <dominictarr> | or the difference is that it would opperate on the whole 'manifest'? |
22:04:05
| <substack> | well "plugins" is a term I am somewhat co-opting here to get people to think in the correct terms about modularity |
22:04:15
| <dominictarr> | oh, right. |
22:04:18
| <substack> | really they are just programs that do one thing, transforming stdin to produce stdout |
22:04:33
| <substack> | they could be compilers or minifiers or whatever |
22:04:42
| <dominictarr> | so, there could just be a bfy-transform command |
22:05:02
| <substack> | I'd want the transform command to be part of browserify itself |
22:05:38
| <substack> | so that people use that as a basis for writing "plugins" |
22:05:41
| <dominictarr> | right, so you could make it that the source is optionally included in the manifest |
22:05:49
| <substack> | but plugins are actually just programs that read stdin and output stdout |
22:06:31
| <substack> | yes there could be a switch that controls whether to inline the source in the javascript |
22:06:45
| <dominictarr> | and then the bundler can read it from there or the file. |
22:06:49
| <substack> | when you | browserify > bundle.js if the source isn't already there browserify will know to go and read the files |
22:06:56
| <substack> | yes exactly! |
22:08:49
| * defunctzombie | joined |
22:08:53
| <substack> | wooo |
22:08:59
| <substack> | defunctzombie: so here's the plan |
22:09:06
| <substack> | you'll be able to do: |
22:09:11
| <defunctzombie> | kk lets hear the plan :) |
22:09:19
| <substack> | browserify main.js --json | plugin1 | plugin2 | browserify > bundle.js |
22:09:39
| <substack> | and each of the plugins in the pipeline accepts json on stdin and writes json to stdout |
22:10:04
| <substack> | and at the end browserify checks to see if it is not a tty and if so it writes the json blob to a bundle |
22:10:08
| <defunctzombie> | interesting |
22:10:14
| <substack> | and you'll be able to explicitly control that with browserify --bundle |
22:10:16
| <defunctzombie> | I played around with a similar idea recently |
22:10:23
| <defunctzombie> | it works out pretty well |
22:10:31
| <defunctzombie> | since the json can have things like all the aliases, etc |
22:10:37
| <defunctzombie> | and you can transform it how you want |
22:10:46
| <defunctzombie> | that is what I ended up doing for shimming in script |
22:11:00
| <substack> | yes exactly! |
22:11:04
| <substack> | and another piece |
22:11:16
| <substack> | will be a `browserify --transform cmd` command |
22:11:41
| <substack> | that will execute `cmd filename {extra meta data}` and write the file contents to it on stdin |
22:11:56
| <defunctzombie> | interesting |
22:12:11
| <substack> | perhaps with an additional --filter param |
22:12:14
| <defunctzombie> | what will the api look like? api is pretty important for me since I like to shove this into middleware |
22:12:15
| <substack> | so people can do: |
22:12:19
| <defunctzombie> | to avoid a "build" step when I deploy |
22:12:42
| <substack> | oh middleware is going away |
22:12:47
| <substack> | it will be a .pipe() api I think |
22:12:54
| <substack> | but you'll be able to do the same kinds of things |
22:12:57
| <defunctzombie> | makes sense |
22:12:57
| <substack> | so the cool part is |
22:13:03
| <defunctzombie> | yes.. middleware should not be in the module |
22:13:11
| <defunctzombie> | easy enough to make a separate module that does that |
22:13:17
| <defunctzombie> | for the different http systems out there |
22:13:35
| <substack> | you can switch it into --watch mode and the pipeline will just keep running |
22:13:40
| <defunctzombie> | nice |
22:13:48
| <substack> | so you just keep the same pipeline |
22:13:51
| <substack> | but do --watch |
22:13:54
| <defunctzombie> | that would be good for the chrome app stuff for sure |
22:13:56
| <substack> | and everything should just work the same |
22:14:00
| <substack> | yes exactly! |
22:14:03
| <defunctzombie> | for node app I usually end up using node-dev |
22:14:07
| <defunctzombie> | to relaunch the whole app |
22:14:11
| <substack> | so the chrome app thing could just be a plugin that you plumb into the pipeline |
22:14:14
| <defunctzombie> | and since this is just one part it all works out |
22:14:29
| <defunctzombie> | yea.. I didn't have to even plumb anything into it |
22:14:45
| <defunctzombie> | I just need to undo some minor things |
22:14:52
| <defunctzombie> | like I hate how core uses 'util' everythwere |
22:15:06
| <defunctzombie> | which makes that nonsense get pulled in.. but that doesn't matter |
22:15:17
| <defunctzombie> | can your pipeline idea handle the idea of externals? |
22:15:22
| <defunctzombie> | sounds like it can |
22:15:26
| <substack> | it could I think |
22:15:31
| <defunctzombie> | that was another important then when I thought about script |
22:15:38
| <defunctzombie> | I think it can too |
22:15:43
| <substack> | you could write additional ast things that look for different syntaxes from require() |
22:15:48
| <defunctzombie> | yep |
22:15:51
| <substack> | and just plug them into the plugin pipeline |
22:15:54
| <defunctzombie> | I like where this is going |
22:15:55
| <substack> | this idea has a ton of promise |
22:16:04
| <substack> | shit is about to get amazing I think |
22:16:05
| <defunctzombie> | yes.. no pun intended ;) |
22:16:08
| <defunctzombie> | hahaha |
22:16:27
| <defunctzombie> | so the way script currently works is it starts with the node-required output |
22:16:36
| <defunctzombie> | then there is a step to identify shims |
22:16:47
| <defunctzombie> | then there is a step to identify externals |
22:16:57
| <defunctzombie> | and then the final json is passed to the generator |
22:17:01
| <defunctzombie> | which makes the js output |
22:17:13
| <defunctzombie> | what you describe sounds like a more generic view of that |
22:17:14
| <substack> | also `browserify main.js | plugin1 | plugin2 | browserify > bundle.js` is pretty much a duplex stream using unix pipes I realized |
22:17:15
| <defunctzombie> | I like it :) |
22:17:28
| <substack> | well in watch mode you'd have to use -o instead of > |
22:17:32
| <substack> | UNLESS |
22:17:55
| <substack> | perhaps it's possible using unix tricks to read the fd of a redirect |
22:18:10
| <substack> | then I could overwrite the file |
22:18:21
| <substack> | or tell the fd to seek to 0 |
22:18:23
| <defunctzombie> | hm |
22:18:27
| <substack> | and call truncate on it |
22:18:30
| <defunctzombie> | maybe something with `tee`? |
22:18:32
| <substack> | requires research |
22:18:44
| <defunctzombie> | I think you would need something that can stay open |
22:18:49
| <defunctzombie> | -o doesn't seem bad tho |
22:18:52
| <defunctzombie> | if that can't be done |
22:19:04
| <substack> | yes |
22:19:30
| <defunctzombie> | so what are the important parts of the json? |
22:19:38
| <defunctzombie> | so far for me it was the node-required output |
22:19:47
| <defunctzombie> | and then aliases |
22:19:55
| <defunctzombie> | and all of the path stuff (which I do server side) |
22:20:54
| <defunctzombie> | time to make a new branch for browserify :) |
22:20:59
| <substack> | aliases can just be a plugin |
22:21:02
| <defunctzombie> | yes |
22:21:06
| <defunctzombie> | all of it should be a plugin |
22:21:09
| <substack> | I would be happy moving those out of browserify itself |
22:21:14
| <substack> | they are really ugly hacks |
22:21:59
| <defunctzombie> | so the json/object passed between pipes |
22:22:07
| <defunctzombie> | is it predefined? |
22:22:22
| <defunctzombie> | or does it plugin have a say on what it outputs? |
22:23:08
| <substack> | plugins should read json on stdin and write json on stdout |
22:23:34
| <defunctzombie> | interesting |
22:24:45
| <defunctzombie> | for an api tho it would be the same then? |
22:25:00
| <defunctzombie> | just an object being passed through composed functions |
22:25:21
| <substack> | possibly |
22:25:34
| <substack> | perhaps passing the objects with .pipe() |
22:25:42
| <defunctzombie> | k |
22:26:03
| <defunctzombie> | I guess the big thing is getting that json object figured out |
22:26:12
| <defunctzombie> | like what is important to replicate current functionality |
22:26:14
| <substack> | oh I think dominictarr's convoy-stream might be a good fit for this with --watch mode |
22:26:21
| <defunctzombie> | and what someone might want to do with a plugin |
22:26:35
| <defunctzombie> | what does convoy-stream do? |
22:26:35
| <substack> | actually it can just be newline separated json |
22:26:47
| <substack> | easier to plug into real processes that way |
22:26:59
| <defunctzombie> | why newline separated? why not just a single json object? |
22:27:06
| <defunctzombie> | is there more than one thing to send? |
22:27:13
| <substack> | watch mode |
22:27:34
| <defunctzombie> | hm |
22:27:35
| <substack> | would need to send deltas or else the entire object again |
22:27:42
| <defunctzombie> | yea |
22:27:48
| <defunctzombie> | entire object seems fine |
22:27:52
| <substack> | probably |
22:27:53
| <defunctzombie> | certainly easier I would think |
22:27:56
| <rowbit> | Hourly usage stats: [developer: 4, free: 26] |
22:28:21
| <substack> | oh sweeet, required is already async |
22:28:25
| <defunctzombie> | yes |
22:28:27
| <defunctzombie> | ;) |
22:28:31
| <substack> | yes I want the new browserify to be async |
22:28:34
| * anoemi | joined |
22:28:34
| <defunctzombie> | yes |
22:28:38
| <defunctzombie> | that was important to me as well |
22:28:44
| <defunctzombie> | for the middleware reason I described above |
22:28:59
| <substack> | that is really hard to do when browserify conflates the steps but with the new approach it should be much simpler |
22:29:48
| <defunctzombie> | I will be at the nyc node knockout event hacking on stuff |
22:29:58
| <defunctzombie> | so can hack on random pieces of this as well |
22:31:20
| * mikeal | quit (Quit: Leaving.) |
22:31:22
| <substack> | well I'm going to hack this up at some point after knockout |
22:31:34
| <defunctzombie> | excellent |
22:31:34
| <substack> | I just had the idea all of the sudden |
22:31:42
| <defunctzombie> | sounds like it will be good |
22:31:51
| <substack> | had to write it down and talk it out |
22:31:54
| * mike-d | quit (Read error: Connection reset by peer) |
22:32:12
| <defunctzombie> | will be cool cause every part after node-required can be a "plugin" |
22:32:21
| <defunctzombie> | which means improvements can be made piece by piece |
22:32:27
| <defunctzombie> | and it can be reconfigured to do whatever |
22:32:33
| * mike-d | joined |
22:32:55
| * jibay_ | quit (Ping timeout: 260 seconds) |
22:33:10
| <defunctzombie> | btw... I have you to thank for putting streams into my mind.. made dealing with the chrome socket stuff much easier |
22:33:19
| <defunctzombie> | once I just built pieces for each step as a stream |
22:33:28
| <defunctzombie> | then when I piped it.. it just worked :) |
22:33:41
| <defunctzombie> | and I used domenictar's split stream module to cap it all off |
22:33:51
| <defunctzombie> | yay for npm module reuse |
22:34:14
| <substack> | yep! |
22:35:16
| <substack> | https://gist.github.com/4048765 |
22:36:35
| <defunctzombie> | "rip out coffee-script" |
22:36:39
| * jibay_ | joined |
22:36:39
| <defunctzombie> | YES :) |
22:37:21
| <defunctzombie> | under plugins I would think about the api (at least add it is a todo) |
22:37:35
| <defunctzombie> | whether it is pipe, or just that the plugin is a single function |
22:37:44
| <defunctzombie> | that takes the js object and calls some callback when done |
22:38:07
| <defunctzombie> | or modifies in place.. whatever |
22:39:04
| <defunctzombie> | some thoughts on mutiple json objects.. which one takes precedence? the final one I guess |
22:39:44
| <substack> | the final one yes |
22:39:56
| <substack> | because each json blob is generated whenever a file changes |
22:40:17
| <defunctzombie> | also.. with the idea of writing such plugins.. might be nice to either have a gist or lib that someone can just define the function for their plugin |
22:40:23
| <defunctzombie> | and not worry about handling stdin |
22:40:25
| <defunctzombie> | properly |
22:40:30
| <defunctzombie> | or linefeeding, et |
22:40:31
| <defunctzombie> | *etc |
22:40:41
| <defunctzombie> | a gist or copy paste example might be enough |
22:40:45
| * jden|away | changed nick to jden |
22:41:03
| <substack> | using JSONStream yes |
22:41:11
| * mike-d_ | joined |
22:41:12
| <substack> | I'll write a module browserify-plugin |
22:41:14
| <substack> | that makes it easy |
22:41:15
| <defunctzombie> | yea |
22:41:21
| <defunctzombie> | that sounds reasonable |
22:41:32
| <defunctzombie> | that way a plugin can be as simple as a function |
22:41:42
| <defunctzombie> | and you don't have to worry about the CLI crap, etc |
22:42:01
| <Raynos> | substack: --watch is out of scope for browserify |
22:42:32
| <defunctzombie> | Raynos: is there a better way to identify if files are changed and rerun command? |
22:42:40
| <Raynos> | if you want watching just watch the file system and run `file | browserify > file` |
22:42:47
| <defunctzombie> | na |
22:42:50
| <defunctzombie> | that doesn't work |
22:42:51
| <Raynos> | defunctzombie: I use `wr` |
22:42:55
| <defunctzombie> | cause you want to watch the required files |
22:43:01
| <defunctzombie> | not just the entry file |
22:43:03
| <Raynos> | then write a program |
22:43:05
| <substack> | Raynos: for performance reasons you want browserify to watch files |
22:43:06
| <Raynos> | that watches the required files |
22:43:22
| <substack> | running browserify can be crazy slow sometimes |
22:43:24
| <Raynos> | substack: psh. it should be seperate and browserify should do caching for performance reasons |
22:43:29
| <substack> | if you only rescan files that change it's much faster |
22:43:38
| <substack> | it already does caching |
22:43:40
| <Raynos> | substack: if browerify is crazy slow then reduce complexity and optimize |
22:43:42
| <substack> | it's still really slow sometimes |
22:43:51
| <Raynos> | rip out the bullshit in it |
22:43:54
| <Raynos> | all of it :D |
22:43:54
| <substack> | no it's slow because it needs to read a ton of files |
22:43:59
| <defunctzombie> | Raynos: it isn't about complexity, it is more about that ^ |
22:44:15
| <substack> | if you have a deep dependency graph browserify needs to read a ton of files |
22:44:17
| <substack> | which is slow |
22:44:33
| * mike-d | quit (Ping timeout: 256 seconds) |
22:44:34
| * mike-d_ | changed nick to mike-d |
22:44:34
| <substack> | oh but here's an idea |
22:45:01
| <substack> | browserify main.js --json | browserify-watch | plugin1 | plugin2 | browserify -o bundle.json |
22:45:14
| <substack> | could issue watches on all the files in the json blob |
22:45:21
| <substack> | and then re-run browserify on just the deltas |
22:45:28
| <substack> | but! |
22:45:45
| <substack> | then browserify -o bundle needs to be aware of multiple incoming json objects |
22:45:50
| <substack> | newline separated probably |
22:45:52
| <substack> | could work |
22:46:06
| <defunctzombie> | well, you don't need to issue watches explicitly |
22:46:19
| <defunctzombie> | that will be obvious from the required paths in the json |
22:46:59
| <defunctzombie> | the question is.. is it worth it to do it that way? |
22:47:13
| <substack> | I think ripping out --watch is too many changes for 2..0 |
22:47:16
| <substack> | *2.0.0 |
22:47:21
| <substack> | perhaps in a subsequent release |
22:47:42
| * defunctz_ | joined |
22:48:29
| * defunctz_ | quit (Remote host closed the connection) |
22:49:43
| * _sorensen | quit (Ping timeout: 260 seconds) |
22:51:42
| * defunctzombie | quit (Ping timeout: 264 seconds) |
22:59:21
| * substack | heads to joyent & |
23:01:31
| * mikeal | joined |
23:05:52
| <Raynos> | substack: you gone? |
23:06:21
| * tilgovi | joined |
23:09:32
| * devaholic | joined |
23:10:08
| <isaacs> | i guess i should probably head there, too.. |
23:11:34
| * mikeal | quit (Ping timeout: 240 seconds) |
23:13:57
| * shykes | changed nick to zz_shykes |
23:18:45
| * defunctzombie | joined |
23:21:56
| <defunctzombie> | substack: so what was decided about watch mode? easier to leave it in? |
23:21:57
| * sorensen | joined |
23:25:13
| * zz_shykes | changed nick to shykes |
23:27:56
| <rowbit> | Hourly usage stats: [developer: 2, free: 40] |
23:32:36
| * shuaib | quit (Quit: Textual IRC Client: http://www.textualapp.com/) |
23:35:28
| * tilgovi | quit (Ping timeout: 246 seconds) |
23:37:46
| * mikeal | joined |
23:45:56
| * mike-d | quit (Read error: Connection reset by peer) |
23:47:47
| * mike-d | joined |
23:48:52
| * mikeal | quit (Ping timeout: 265 seconds) |
23:52:08
| * mike-d_ | joined |
23:52:15
| * mike-d | quit (Ping timeout: 260 seconds) |
23:52:15
| * mike-d_ | changed nick to mike-d |
23:53:03
| * defunctzombie | quit (Remote host closed the connection) |
23:56:04
| * dominictarr | quit (Remote host closed the connection) |
23:59:18
| <Raynos> | substack: beep boop |