| 00:00:38
| * substack | topic: Unofficial browserling/testling mad science channel. For official help /join #browserling |
| 00:03:31
| * dguttman | quit (Client Quit) |
| 00:05:01
| * dguttman | joined |
| 00:09:21
| <dominictarr> | rvagg: is it possible for something like approximateSize to get the number of keys? |
| 00:09:44
| <rvagg> | dominictarr: no, it's a low-level LevelDB operation |
| 00:09:50
| <dominictarr> | okay |
| 00:09:54
| <rvagg> | you'd have to use an iterator to do it |
| 00:13:41
| <rowbit> | /!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\ |
| 00:13:42
| <rowbit> | /!\ ATTENTION: (default-local) paid account successfully upgraded /!\ |
| 00:17:01
| * mirkok | joined |
| 00:17:38
| * st_luke | joined |
| 00:17:38
| * st_luke | quit (Client Quit) |
| 00:17:48
| * st_luke | joined |
| 00:18:03
| <st_luke> | substack: what a massive troll |
| 00:18:16
| <st_luke> | ask him what the boundary for ripping people off on kickstarter for an open source project is |
| 00:18:23
| <st_luke> | http://www.kickstarter.com/projects/1397300529/railsapp |
| 00:18:35
| <st_luke> | $50k to do an open source project that he never finished |
| 00:18:45
| * lyaunzbe | quit (Remote host closed the connection) |
| 00:19:12
| * lyaunzbe | joined |
| 00:23:17
| * mikolalysenko | quit (Ping timeout: 248 seconds) |
| 00:23:52
| * lyaunzbe | quit (Ping timeout: 276 seconds) |
| 00:29:04
| <dominictarr> | substack: st_luke or just ignore him |
| 00:29:25
| <st_luke> | dominictarr: yeah, I know, I usually do |
| 00:29:43
| <substack> | dominictarr: he's on tc39 too |
| 00:29:49
| <substack> | dominictarr: also! https://github.com/substack/shux |
| 00:29:57
| <dominictarr> | I saw! |
| 00:30:15
| <substack> | so this is pretty much ssh+screen, over http https://github.com/substack/shux/blob/master/example/http/server.js |
| 00:30:25
| <substack> | 23 sloc |
| 00:30:37
| <dominictarr> | except without split screen? |
| 00:30:49
| <substack> | yeah only attach/detach |
| 00:31:02
| <substack> | but anyways this is the power of modularity |
| 00:31:09
| <dominictarr> | indeed |
| 00:31:19
| <substack> | you can plug tiny pieces into one another and recombine them in powerful ways |
| 00:31:30
| <dominictarr> | now, we just need to get node running on the bare metal |
| 00:32:24
| <substack> | boot to node |
| 00:32:36
| <substack> | chromeos/firefoxos style |
| 00:39:49
| <dominictarr> | and the fs is just leveldb |
| 00:40:13
| <substack> | unixier than unix |
| 00:40:22
| <rvagg> | javascript-on-a-chip, a.k.a JoC |
| 00:43:28
| <dominictarr> | substack: the other day max and I where discussing how to get low power cyberhobo computers |
| 00:43:52
| <dominictarr> | turns out you can use a kindle as a screen! |
| 00:44:19
| <dominictarr> | you just have to jailbreak it, and then you ssh into a screen session from some terminal emulator |
| 00:44:37
| <substack> | I read that! |
| 00:45:02
| <dominictarr> | I say a video, a little weird, but good enough |
| 00:47:30
| * kenperkins | quit (Ping timeout: 252 seconds) |
| 00:47:59
| <substack> | people walking past me have been speaking 3 different languages in the past 2 minutes |
| 00:49:29
| <substack> | I should write a blog post about writing tiny pieces that work together |
| 00:49:41
| <substack> | it seems that there is not much written on this topic |
| 00:51:59
| * dominictarr | quit (Quit: dominictarr) |
| 00:52:29
| * dguttman | quit (Quit: dguttman) |
| 00:52:53
| * dguttman | joined |
| 00:58:41
| <substack> | gah naming is so hard |
| 00:58:52
| <substack> | writing the actual code is so easy in comparison |
| 00:59:49
| <substack> | I need a term for a function to create a botnet control instance that will have a createStream function |
| 01:00:23
| <substack> | then I need a term for the function to create a botnet instance |
| 01:00:36
| <substack> | .worker() I guess |
| 01:01:44
| <substack> | perhaps .work() and .control() |
| 01:03:50
| <substack> | .rule() and .obey() :D |
| 01:04:20
| <substack> | or .reign() |
| 01:08:15
| * lyaunzbe | joined |
| 01:10:46
| <substack> | regime.rule(), regime.obey() |
| 01:10:48
| <substack> | PERFECT |
| 01:14:09
| * dominictarr | joined |
| 01:15:58
| * mirkok | quit (Quit: mirkok) |
| 01:18:05
| * mikeal | quit (Quit: Leaving.) |
| 01:19:01
| * mikeal | joined |
| 01:21:08
| <dominictarr> | hij1nx: lev doesn't print out each key on a new line. |
| 01:22:26
| <st_luke> | dominictarr: put "format": true in .lev |
| 01:22:37
| <st_luke> | as json in your home dir |
| 01:22:41
| <st_luke> | keys will get printed on a new line |
| 01:23:17
| <substack> | regime.appoint() |
| 01:23:21
| <dominictarr> | thanks |
| 01:23:33
| <substack> | to authorize peers to rule over your workers |
| 01:25:29
| <dominictarr> | substack: there was, by authors such as Lao Tzu, and Sun Tzu |
| 01:26:24
| * st_luke | quit (Remote host closed the connection) |
| 01:27:45
| * mikeal | quit (Quit: Leaving.) |
| 01:40:09
| <substack> | haha regime is basically a terminal multiplexer multiplexer |
| 01:40:19
| <substack> | so much multiplexing |
| 01:44:18
| * ins0mnia | quit (Ping timeout: 244 seconds) |
| 01:48:14
| * jibay | quit (Remote host closed the connection) |
| 01:49:33
| * kenperkins | joined |
| 02:10:54
| * dguttman | quit (Quit: dguttman) |
| 02:15:29
| * tilgovi | joined |
| 02:15:29
| * fotoverite | quit (Quit: fotoverite) |
| 02:27:15
| * mikeal | joined |
| 02:31:46
| * mikeal | quit (Read error: Connection reset by peer) |
| 02:44:32
| * mikeal | joined |
| 02:52:03
| <dools> | trace buster buster buster http://www.youtube.com/watch?v=Iw3G80bplTg |
| 02:53:15
| * mikeal | quit (Ping timeout: 252 seconds) |
| 03:05:47
| * tphummel | quit (Quit: tphummel) |
| 03:14:09
| * ralphtheninja | quit (Ping timeout: 252 seconds) |
| 03:15:58
| * defunctzombie_zz | changed nick to defunctzombie |
| 03:16:16
| <dominictarr> | simple queries on leveldb https://github.com/dominictarr/level-map-merge (simpler than map-reduce) |
| 03:16:18
| * tilgovi | quit (Remote host closed the connection) |
| 03:16:31
| <dominictarr> | Raynos: ^ like the 'lambda' architecture |
| 03:19:58
| <rvagg> | dominictarr: merge is like a batch reduce? |
| 03:19:59
| <rvagg> | `little` meaning it's chunks of data? |
| 03:20:10
| <dominictarr> | yeah, |
| 03:20:33
| <dominictarr> | It's like a map-reduce |
| 03:20:36
| <rvagg> | dominictarr: btw, I've been thinking more about your ideas on sub-databases based on prefixes + the whole modularity/pluggable architecture and I have some awesome ideas in my head but currently no time to make them come out of my fingers |
| 03:20:37
| <rvagg> | soon |
| 03:21:21
| <dominictarr> | the only difference is that there updates are processed in realtime |
| 03:21:37
| <dominictarr> | but deletes don't get processed until the batch runs again. |
| 03:23:58
| <dominictarr> | those cases are rare, of course, so you can just handle them when you read the view. |
| 03:28:05
| * mikeal | joined |
| 03:37:46
| * mikolalysenko | joined |
| 03:45:16
| <defunctzombie> | instead of catering to stupid client side libs that patch globals and shit people should be migrating them to use require and exports |
| 03:45:41
| <defunctzombie> | stop supporting the hordes of stupid js organization! |
| 03:45:46
| <defunctzombie> | down with the evil! |
| 03:53:27
| * st_luke | joined |
| 04:00:34
| * thatguydan | joined |
| 04:02:10
| <defunctzombie> | Raynos: multiple callback calls on error but not on success is weird |
| 04:02:29
| <Raynos> | multiple errors is weird |
| 04:03:02
| <defunctzombie> | the library makes it seem like the callback will be called only once |
| 04:03:07
| <defunctzombie> | but breaks this rule for errors |
| 04:03:42
| <Raynos> | yes |
| 04:04:05
| <Raynos> | juliangruber: https://github.com/Colingo/pubnub-stream |
| 04:04:56
| <defunctzombie> | Raynos: another issue with after is that I could technically call it with error over and over |
| 04:05:14
| <defunctzombie> | very weird |
| 04:05:58
| <dominictarr> | Raynos: make EXACTLY ONE CALLBACK |
| 04:06:07
| <dominictarr> | or use an EventEmitter |
| 04:06:17
| <defunctzombie> | ^ this |
| 04:07:37
| <Raynos> | agreed |
| 04:07:40
| <Raynos> | but fuck error handling |
| 04:07:45
| <Raynos> | fuck all the things |
| 04:07:47
| <defunctzombie> | hahaha |
| 04:07:50
| <Raynos> | I AM TOO BUSY DOING FRP |
| 04:07:50
| <LOUDBOT> | JAMES Y U SO HANDWAVEY |
| 04:07:52
| <defunctzombie> | fuck it all |
| 04:07:53
| <Raynos> | GO AWAY WITH YOUR CALLBACKS |
| 04:07:53
| <LOUDBOT> | WHAT THE FUCK MARS? WHY ARE YOU NOT MAKING THEM ANYMORE I READ UNSUBSTANTIATED CLAIMS ON WIKIPEDIA THAT SAID THEY MADE YOU THE MOST MONEY! |
| 04:08:07
| <Raynos> | IF ITS NOT MONADS IM NOT LISTENING |
| 04:08:07
| <LOUDBOT> | THEN I'M LIVING IN THE FUTURE |
| 04:10:25
| <st_luke> | isaacs: would you take an npm patch that aliases repo to repository so you can do `npm view repo url` instead of `npm view repository url` |
| 04:10:33
| <st_luke> | i mean npm view [module] repo url |
| 04:11:07
| <isaacs> | st_luke: meh. sure, why not. |
| 04:11:15
| <Raynos> | defunctzombie: Having used after in production I find that calling the cb multiple times is the least retarded thing |
| 04:11:21
| <isaacs> | st_luke: doesn't it usually just `npm view module repo`? |
| 04:11:48
| <st_luke> | isaacs: just repo returns nothing for me currently |
| 04:11:58
| <st_luke> | have to type out the whole repository |
| 04:12:05
| <isaacs> | st_luke: well, `npm view module repository` |
| 04:12:06
| <isaacs> | yeah |
| 04:12:10
| <isaacs> | not repourl |
| 04:12:10
| <st_luke> | it's an awkward word to type |
| 04:12:12
| <isaacs> | repo.url |
| 04:12:14
| <isaacs> | repository |
| 04:12:16
| <isaacs> | i dunno |
| 04:12:20
| <isaacs> | seems easy enough to me |
| 04:12:29
| <isaacs> | i type pacakges a lot, though |
| 04:12:35
| <st_luke> | nbd either way |
| 04:12:37
| <isaacs> | and node_Modules |
| 04:12:42
| <isaacs> | vim alias vtw |
| 04:12:44
| <isaacs> | ftw |
| 04:12:50
| <st_luke> | this new laptop is awkward to type on |
| 04:12:56
| <isaacs> | vtw = VIM THE WIM! |
| 04:13:12
| <defunctzombie> | Raynos: :/ still seems like it is breaking what the module claims |
| 04:13:25
| <defunctzombie> | returning last or first is arbitrary |
| 04:13:28
| <defunctzombie> | why not Nth? |
| 04:13:35
| <dominictarr> | Raynos: a callback IS a monad |
| 04:13:37
| <Raynos> | > @shtylman actually, fuck error handling. Don't propagate any errors or values. Just call the callback with zero arguments after N calls |
| 04:13:44
| <Raynos> | dominictarr: your mom IS a monad |
| 04:13:48
| <defunctzombie> | wow |
| 04:14:12
| <substack> | all talk of monads makes me glaze over |
| 04:14:19
| <dominictarr> | the whole universe is a just a huge Maybe Monad |
| 04:14:22
| <Raynos> | https://github.com/Raynos/after/commit/f849455887fd3113e06152aa1c3cf229f83d2e51 |
| 04:14:27
| <dominictarr> | Maybe, |
| 04:14:53
| <defunctzombie> | Raynos: not good |
| 04:14:57
| <defunctzombie> | Raynos: don't eat my errors |
| 04:15:28
| <defunctzombie> | Raynos: also, when the number underflows you could call the callback again hahaha |
| 04:15:35
| <defunctzombie> | ;) |
| 04:16:08
| <dominictarr> | at least, put a notice in the readme that says anymodule that depends on that won't work as expected |
| 04:16:09
| <st_luke> | isaacs: actually never mind, it wouldn't really make sense to put it in view.js cause it's expecting an *actual* field in the package.json, so it would not work properly if someone ended up really putting a 'repo' key in it |
| 04:16:15
| <st_luke> | ill just deal with typing out repository and not be lazy |
| 04:16:38
| <isaacs> | st_luke: tab completion works kinda |
| 04:16:52
| <defunctzombie> | hahaha |
| 04:17:00
| <Raynos> | Defunctzombie: fixed is fixed |
| 04:17:10
| <Raynos> | Its a proper callback |
| 04:17:14
| <isaacs> | st_luke: . <(npm completion); npm view npm repo<TAB>....sitory |
| 04:17:19
| <defunctzombie> | Raynos: not fixed cause you eat my errors |
| 04:17:25
| <defunctzombie> | this is crap |
| 04:17:28
| <Raynos> | What errors |
| 04:17:36
| * dominictarr_ | joined |
| 04:17:36
| <defunctzombie> | seriously |
| 04:17:38
| <Raynos> | Why call it with errors |
| 04:17:39
| <isaacs> | st_luke: teh `...` is waiting a long time if it's not already cached |
| 04:17:45
| <Raynos> | Wait |
| 04:18:06
| <defunctzombie> | Raynos: either do forwarding of arguments with capturing (if I want) or leave it like you have it |
| 04:18:25
| <defunctzombie> | Raynos: personally, I wouldn't mind the .capture thing from before and let the person decide |
| 04:18:43
| <defunctzombie> | and then the lib doesn't have to have any knowledge of errors or such |
| 04:18:55
| <defunctzombie> | and is just a callback collecting library |
| 04:19:35
| <Raynos> | defunctzombie: `npm owner ls after` |
| 04:19:36
| <Raynos> | good luck |
| 04:19:49
| <defunctzombie> | Raynos: wut |
| 04:19:58
| <Raynos> | i dont care |
| 04:19:59
| <defunctzombie> | how did this happen |
| 04:20:00
| <Raynos> | its your module now |
| 04:20:04
| <defunctzombie> | :( |
| 04:20:09
| <defunctzombie> | you should care about your babies |
| 04:20:12
| <defunctzombie> | :D |
| 04:20:18
| <Raynos> | i only care about my pretty babies |
| 04:20:21
| <Raynos> | the uglies ones can die |
| 04:20:36
| <defunctzombie> | ouch |
| 04:21:03
| <Raynos> | seriously I don't care. patch it yourself with optimum api |
| 04:21:07
| * dominictarr | quit (Ping timeout: 276 seconds) |
| 04:21:08
| * dominictarr_ | changed nick to dominictarr |
| 04:21:13
| <Raynos> | bump the major version though |
| 04:22:37
| <defunctzombie> | ok |
| 04:23:25
| <defunctzombie> | dominictarr: https://gist.github.com/shtylman/cf3e288773a8e8e2bd02 |
| 04:23:43
| <defunctzombie> | I was playing around with this notion earlier today |
| 04:24:06
| <st_luke> | wow: https://github.com/justinethier/node-kdtree |
| 04:24:13
| <defunctzombie> | dominictarr: the idea is you can use after as is with no capture (as Raynos has in latest "fixed." haha) |
| 04:24:17
| <st_luke> | just made my life a million times easier |
| 04:24:29
| <defunctzombie> | or, you could capture by name certain calls |
| 04:24:42
| <defunctzombie> | or take out the whole error concept altogether |
| 04:24:52
| <defunctzombie> | and just allow capture by name if the person wants |
| 04:24:54
| <dominictarr> | Raynos: defunctzombie it's just as easy to write that stuff inline |
| 04:25:05
| <Raynos> | dominictarr: sure is! |
| 04:25:15
| <defunctzombie> | easier than a single function call? |
| 04:25:20
| <Raynos> | the only thing thats painful is https://github.com/Raynos/end-stream |
| 04:25:30
| <dominictarr> | easier than clicking around to read your code |
| 04:26:07
| <defunctzombie> | well, if you know something will be called after N times |
| 04:26:07
| <dominictarr> | and then finding out that raynos is ignoring errors |
| 04:26:56
| <dominictarr> | indirection is like a heaver kind of indentation |
| 04:27:09
| <defunctzombie> | how would you write it nicely inline? |
| 04:27:12
| <dominictarr> | it's only worthwhile if you have a bunch of uses. |
| 04:27:20
| <defunctzombie> | I really like the simple nature of after |
| 04:27:26
| <dominictarr> | well, you can't… it's still kinda ugly |
| 04:27:38
| <dominictarr> | but it's right there and you can see it |
| 04:27:39
| <defunctzombie> | really useful for testing and other little places |
| 04:27:56
| <dominictarr> | and as you master the pattern you can just see it, rather than read it |
| 04:27:57
| <dominictarr> | . |
| 04:27:58
| <defunctzombie> | dominictarr: I tend to agree, but that is what I like about after(N, fn) |
| 04:28:03
| <defunctzombie> | so clear what i wnat to happen |
| 04:28:22
| <dominictarr> | oh, well, this is just my opinion |
| 04:28:34
| <dominictarr> | I'm not gonna not use your modules because you do that |
| 04:28:42
| <defunctzombie> | do what? |
| 04:28:54
| <dominictarr> | use after (or things like it) |
| 04:28:59
| <defunctzombie> | haha sure |
| 04:29:08
| <defunctzombie> | I just wnat to make a nice usable api that is minimal |
| 04:29:14
| <dominictarr> | but I am gonna not use Raynos 's modules that drop errors! |
| 04:29:28
| <defunctzombie> | errors must not be dropped |
| 04:29:49
| <defunctzombie> | there are actually very few options to this api |
| 04:29:54
| <dominictarr> | it's easier to stay out of the minefield than to figure out where all the mines are! |
| 04:30:09
| <defunctzombie> | 1: assume nodejs style callback where error is first arg |
| 04:30:20
| <defunctzombie> | capture errors and call fn with errors (but call only once) |
| 04:30:43
| <defunctzombie> | 2: assume no callback style, capture arguments to calls to "after" instances and return those to "fn" |
| 04:30:47
| <defunctzombie> | and let the user sort it out |
| 04:30:53
| <dominictarr> | it does assume that the callbacks are well behaved and will always cb exactly once. |
| 04:31:19
| <defunctzombie> | 3: assume nodejs api, and call the callback only if nothing errors |
| 04:31:28
| <defunctzombie> | if anything errors call an error handler fn |
| 04:31:33
| <defunctzombie> | after(N, fn, err_fn) |
| 04:32:12
| <defunctzombie> | personally, if you don't assume a nodejs style api and just let the user decide, then I kinda think that is better ? |
| 04:33:42
| <dominictarr> | yeah, better to let the user decide (not to use your module) |
| 04:36:07
| <defunctzombie> | :( |
| 04:36:16
| <defunctzombie> | ultimate sadness |
| 04:37:50
| <Raynos> | Dominictarr: it doesn't drop errors |
| 04:38:16
| <defunctzombie> | well, your latest commit to master does, but yea, otherwise it doesn't |
| 04:38:21
| <defunctzombie> | just calls the callback multiple times |
| 04:38:37
| <Raynos> | Well that's because you qq. |
| 04:38:45
| <defunctzombie> | if the user is handling errors in the callback call then that is ok |
| 04:38:53
| <Raynos> | There is no good solution to this |
| 04:38:56
| <defunctzombie> | so after assumes a node style api |
| 04:38:59
| <defunctzombie> | lets start with that |
| 04:39:03
| <defunctzombie> | where error is first arg |
| 04:39:05
| <Raynos> | Either don't handle errors |
| 04:39:24
| <dominictarr> | Raynos: cb more or less than once breaks control flow assumptions |
| 04:39:44
| <dominictarr> | and makes hard to debug strange behaviour |
| 04:39:55
| <Raynos> | Or make some assumptions about error handling flow |
| 04:40:35
| <Raynos> | The only correct thing to do is return an event emitter |
| 04:40:41
| <dominictarr> | agree |
| 04:40:56
| <dominictarr> | or maybe callback the first error is enough |
| 04:41:00
| <Raynos> | Or throw an exception if you done(err) |
| 04:41:17
| <dominictarr> | if there are more than one error, that is a unhandleable error |
| 04:41:28
| <Raynos> | And say fuck you. After does not fix errors |
| 04:43:10
| <dominictarr> | Everyone needs to do their part is handling errors |
| 04:43:15
| <defunctzombie> | haha |
| 04:43:19
| <dominictarr> | is/in/s |
| 04:43:21
| <defunctzombie> | reminds me of starship troopers |
| 04:43:24
| <defunctzombie> | do your part |
| 04:43:52
| <defunctzombie> | ok.. so are we assuming nodejs style error first arguments? |
| 04:44:21
| <defunctzombie> | if we make that assumption, I think a reasonable thing to consider is a third arg to after which is is a function to handle errors? |
| 04:44:38
| <defunctzombie> | throwing seems not so how? |
| 04:44:41
| <defunctzombie> | *hot |
| 04:45:02
| <defunctzombie> | no clean way to capture that |
| 04:45:50
| <defunctzombie> | if no error_fn provided, THEN throw? |
| 04:46:07
| <dominictarr> | return an EventEmitter |
| 04:46:17
| <dominictarr> | is the most established node.js way |
| 04:46:18
| <st_luke> | what was the last node version to use waf |
| 04:46:33
| <dominictarr> | and if they havn't registered an error listener, that is an error |
| 04:46:53
| <defunctzombie> | dominictarr: this makes after way more complex :/ |
| 04:47:18
| <dominictarr> | either that, or just return the first error |
| 04:47:37
| <dominictarr> | one error is enough to know it's broken |
| 04:47:53
| <defunctzombie> | and the others? |
| 04:48:10
| <defunctzombie> | just drop them? |
| 04:48:13
| <defunctzombie> | :/ |
| 04:48:14
| <dominictarr> | well, how you react to that depends on what you are trying to do |
| 04:48:18
| <defunctzombie> | yea |
| 04:48:25
| <dominictarr> | they is why I just write this inline |
| 04:48:32
| <defunctzombie> | certainly capturing AN error is better than not |
| 04:48:55
| <dominictarr> | often, with a think like this, I'd just bail on the frist error |
| 04:49:08
| <defunctzombie> | yea, I could buy that |
| 04:49:10
| <defunctzombie> | ok |
| 04:49:13
| <dominictarr> | like if I had to read a bunch of files and one isn't there, |
| 04:49:19
| <dominictarr> | just give up! |
| 04:49:23
| <defunctzombie> | Raynos: first error passed, then done, nothing else |
| 04:49:48
| <dominictarr> | the trouble with thing like this is temptation to generalize |
| 04:49:49
| <defunctzombie> | dominictarr: well, the other async stuff might still run or something but yea |
| 04:49:54
| <defunctzombie> | I agree |
| 04:50:17
| <dominictarr> | when I try to generalize stuff like this I end up with cancelable operations |
| 04:50:48
| <dominictarr> | function async(arg, cb) {startAsync(cb), return function () {cancelCb(cb)}) |
| 04:50:58
| <dominictarr> | return a cancel function that aborts |
| 04:51:03
| <dominictarr> | (if possible) |
| 04:51:22
| <dominictarr> | and calls the cb with (new Error('aborted')) |
| 04:51:30
| <dominictarr> | (or somethnig) |
| 04:52:03
| <dominictarr> | that makes it a lot more complex, but you need that for correctness, sometimes. |
| 04:56:29
| <defunctzombie> | Raynos: dominictarr: https://github.com/Raynos/after/commit/6c258ba8139b6745e7022b38ab884682904afe41 |
| 04:56:52
| * dguttman | joined |
| 04:56:55
| <defunctzombie> | Raynos: can you update the travis.ci stuff |
| 04:56:59
| <defunctzombie> | it points to the wrong repo |
| 04:57:04
| <defunctzombie> | and as a result doesn't run tets |
| 04:57:07
| <defunctzombie> | *tests |
| 04:59:41
| <defunctzombie> | ok, pushed a bunch of meta info updates |
| 04:59:56
| <defunctzombie> | to bring after out of its dark deep slumber |
| 04:59:57
| <defunctzombie> | haha |
| 04:59:58
| <defunctzombie> | anyhow |
| 05:00:10
| <defunctzombie> | callback called only once now |
| 05:00:15
| <defunctzombie> | error is passed along |
| 05:00:21
| <defunctzombie> | callback will not be called again |
| 05:00:47
| <defunctzombie> | lib remains simple |
| 05:02:25
| * dguttman | quit (Quit: dguttman) |
| 05:02:54
| * thatguydan | quit (Read error: Connection reset by peer) |
| 05:07:22
| <dominictarr> | Raynos this is too complicated https://npmjs.org/package/presence |
| 05:09:17
| * thatguydan | joined |
| 05:20:44
| * mikeal | quit (Quit: Leaving.) |
| 05:20:58
| * mikeal | joined |
| 05:25:14
| * dguttman | joined |
| 05:25:31
| * shama | quit (Remote host closed the connection) |
| 05:26:04
| * dguttman | quit (Client Quit) |
| 05:27:38
| <defunctzombie> | https://github.com/substack/node-browserify/commit/50200306282c8b1361335a0b03637067c7ef226c#commitcomment-2693188 |
| 05:27:47
| <defunctzombie> | my solution is to just stop using shitty ass libraries |
| 05:28:10
| <defunctzombie> | if you can't be bothered to add a module.exports = line to your vendor file then wtf |
| 05:28:27
| <defunctzombie> | you might need to re-evaluate your role as a developer hahaha |
| 05:28:57
| <substack> | I'm inclined to agree with thlorenz |
| 05:29:16
| <Raynos> | dominictarr: why? |
| 05:29:36
| <defunctzombie> | substack: I am inlined to agree as well |
| 05:29:47
| <defunctzombie> | substack: but my inner voice just keeps fighting me |
| 05:29:59
| <defunctzombie> | ;) |
| 05:30:07
| <defunctzombie> | I totally get the mindset |
| 05:30:22
| <dominictarr> | Raynos: well, because it had the same name I wanted to use but not the same api :( |
| 05:30:27
| <defunctzombie> | but I think that the way to make a prepackaged vendor lib work with this setup is so easy |
| 05:30:38
| <defunctzombie> | that it doesn't warrant more complex solutions |
| 05:31:17
| <substack> | who cares, plugins will let you do this |
| 05:31:18
| <dominictarr> | I just want to attach the some details of the current user, and to see who is currently connected. |
| 05:31:25
| <defunctzombie> | substack: yea |
| 05:31:27
| <substack> | the point of plugins is so that people can do this kind of thing without bloating core |
| 05:31:35
| <defunctzombie> | yep |
| 05:31:42
| <Raynos> | dominictarr: link? |
| 05:31:45
| <substack> | plugins will require sending some patches to required it seems |
| 05:31:54
| <substack> | to pre-process source files |
| 05:31:59
| <defunctzombie> | I just like to encourage to people think about not overengineering shit |
| 05:32:05
| <defunctzombie> | cause developers love to overengineer shit |
| 05:32:08
| <defunctzombie> | for no reason |
| 05:32:15
| <dominictarr> | Raynos: I don't have a link yet, because I havn't written my version yet |
| 05:32:25
| <defunctzombie> | substack: to what end? |
| 05:32:30
| <Raynos> | if you have a good api suggestion then ill listen |
| 05:32:34
| <defunctzombie> | coffeescript? |
| 05:32:37
| <defunctzombie> | fuck that |
| 05:32:49
| <mikolalysenko> | speaking of not over engineering shit, you guys got a moment to critique a library I am working on? |
| 05:32:51
| <defunctzombie> | those people can go make their own shit |
| 05:33:03
| <defunctzombie> | coffescript is not javascript |
| 05:33:10
| <defunctzombie> | and they need to come to terms with that |
| 05:33:18
| <substack> | defunctzombie: adding hooks to make coffeescript work necessarily entails adding hooks for more interesting things |
| 05:33:34
| <defunctzombie> | substack: I wanna hear the more interesting things |
| 05:33:48
| <defunctzombie> | and have 0 desire for coffeescript nonsense |
| 05:34:08
| <defunctzombie> | all about doing cool stuff tho |
| 05:34:21
| <substack> | like require() rewriting to inline to the declarations https://github.com/substack/node-browserify/issues/296#issuecomment-14086638 |
| 05:34:46
| <substack> | so uglify can have an easier job of minifying browserify bundles |
| 05:35:11
| <substack> | and a fs.readFileSync() plugin to load static assets |
| 05:36:00
| <defunctzombie> | substack: don't follow the inlining thing |
| 05:36:14
| <defunctzombie> | substack: I am 100% against the readFileSync thing actually |
| 05:36:18
| <dominictarr> | Raynos: I just want to attach some info from the current user, and be able to get the data from the users who are currently connected… |
| 05:36:29
| <defunctzombie> | I think the use cases presented have not been meaningful enough :/ |
| 05:36:33
| <dominictarr> | and for one crdt=one room |
| 05:36:33
| <Raynos> | i have something similar |
| 05:36:33
| <defunctzombie> | substack: this d3 stuff tho |
| 05:36:42
| <defunctzombie> | substack: what was the issue? |
| 05:36:56
| <Raynos> | dominictarr: https://github.com/Raynos/peer-nodes |
| 05:37:10
| <Raynos> | dominictarr: Colingo/presence is aimed at managing presence information for rooms of people |
| 05:37:11
| <defunctzombie> | substack: I can't believe there is that much difference between concat vs using require |
| 05:37:15
| <defunctzombie> | something seems wrong there |
| 05:37:32
| <Raynos> | defunctzombie: HOW I REQUIRE HTML?! |
| 05:37:37
| <dominictarr> | Raynos: but does the crdt store all the rooms? |
| 05:37:45
| <Raynos> | dominictarr: yes |
| 05:37:57
| <dominictarr> | so, what if I have 1000 rooms? |
| 05:38:04
| <defunctzombie> | Raynos: you don't require HTML |
| 05:38:18
| <Raynos> | dominictarr: then dont use crdt for stuff |
| 05:38:24
| <Raynos> | defunctzombie: how I template? |
| 05:38:33
| <dominictarr> | it's easy to have heaps of scuttlebutts now, with rumours, so I can make it one per room |
| 05:38:48
| <defunctzombie> | Raynos: template in a module? |
| 05:38:56
| <defunctzombie> | write a smaller module |
| 05:39:04
| <substack> | defunctzombie: that doesn't address the issue |
| 05:39:06
| <Raynos> | defunctzombie: https://github.com/shtylman/typeahead/blob/master/typeahead.js#L8 |
| 05:39:06
| <defunctzombie> | template in your app, well that is up to you |
| 05:39:08
| <Raynos> | that's bullshit |
| 05:39:12
| <Raynos> | my templates are 10 lines of HTML |
| 05:39:16
| <Raynos> | I want a seperate file for them |
| 05:39:17
| <substack> | the issue is getting static assets into the client is really annoying |
| 05:39:18
| <defunctzombie> | Raynos: that is not bullshit |
| 05:39:21
| <defunctzombie> | that was a tiny line |
| 05:39:27
| <Raynos> | yeah it works |
| 05:39:28
| <defunctzombie> | substack: loading in js is NOT the answer |
| 05:39:30
| <Raynos> | but wont scale |
| 05:39:31
| <defunctzombie> | NO WAY |
| 05:39:40
| <defunctzombie> | that is just not a good way to do it imho |
| 05:39:46
| <defunctzombie> | you miss out on lots of caching |
| 05:39:50
| <defunctzombie> | and other client specific things |
| 05:39:56
| <defunctzombie> | Raynos: scales just fine |
| 05:40:03
| <defunctzombie> | keep your shit modular and small |
| 05:40:04
| <substack> | defunctzombie: it doesn't make sense to pull in <1k of template data with a separate io call |
| 05:40:14
| <Raynos> | defunctzombie: my smallest tempaltes are 10 lines |
| 05:40:17
| <Raynos> | and I keep them really small |
| 05:40:25
| <substack> | there is a really good case for inlining templates into bundles |
| 05:40:28
| <defunctzombie> | Raynos: are these in modules or in your final app code? |
| 05:40:30
| <defunctzombie> | there is a difference |
| 05:40:34
| <Raynos> | both |
| 05:40:36
| <Raynos> | i spllit my app |
| 05:40:37
| <dominictarr> | substack: Raynos defunctzombie does anyone have a module to tell be what the browser is? |
| 05:40:39
| <Raynos> | across many modules |
| 05:40:48
| <Raynos> | dominictarr: useragent |
| 05:40:55
| <dominictarr> | thanks |
| 05:41:00
| <substack> | defunctzombie: in node it's not a problem loading static data since you can just fs.readFileSync() |
| 05:41:14
| <defunctzombie> | substack: and in the browser you can just ajax it |
| 05:41:23
| <Raynos> | no you cant just ajax it |
| 05:41:28
| <Raynos> | you could just ajax js |
| 05:41:29
| <Raynos> | go on |
| 05:41:30
| <substack> | that doesn't compose well |
| 05:41:32
| <Raynos> | just ajax it |
| 05:41:37
| <Raynos> | have fun with your async require |
| 05:41:46
| <dominictarr> | so much documentation! |
| 05:41:59
| <defunctzombie> | dominictarr: yea, but it is pretty easy to use |
| 05:42:04
| <substack> | doing an external ajax call for a tiny snippet of html for ideological reasons incurs a huge performance hit |
| 05:42:17
| * tphummel | joined |
| 05:42:27
| <defunctzombie> | substack: then make a string and inline it |
| 05:42:32
| <Raynos> | no. |
| 05:42:34
| <defunctzombie> | or use a builder |
| 05:42:35
| <Raynos> | i want a html file |
| 05:42:36
| <defunctzombie> | or do something |
| 05:42:38
| <dominictarr> | I think I see it |
| 05:42:38
| <Raynos> | that people can edit |
| 05:42:39
| <Raynos> | cleanly |
| 05:42:47
| <defunctzombie> | ok |
| 05:42:57
| <Raynos> | the only alternative is to use hyperscript |
| 05:43:13
| <substack> | fs.readFileSync() is a very clean way of supporting this in such a way that also works in node |
| 05:43:30
| <defunctzombie> | that is a terrible too open ended way |
| 05:43:35
| <defunctzombie> | people will read images |
| 05:43:42
| <defunctzombie> | they will read bullshit, who knows what |
| 05:43:44
| <substack> | I don't care if people shoot themselves in the foot |
| 05:43:47
| <substack> | I'm not their dad |
| 05:43:51
| * tphummel | quit (Client Quit) |
| 05:43:51
| <defunctzombie> | I do |
| 05:43:54
| <dominictarr> | Raynos: hyperscript is FRP |
| 05:44:01
| <defunctzombie> | I try to make things that don't fuck people up ;) |
| 05:44:03
| <Raynos> | i disagree |
| 05:44:07
| <substack> | I'll leave the gun cupboard unlocked and even tell them where the magazine is hidden |
| 05:44:15
| <defunctzombie> | I think that is bad UI |
| 05:44:18
| <dominictarr> | defunctzombie: you can add you're own requires much easier with bfy2 |
| 05:44:20
| <defunctzombie> | and API is UI |
| 05:44:32
| <defunctzombie> | dominictarr: ? |
| 05:44:52
| <defunctzombie> | substack: I do not disagree that a better approach to load html templates is needed |
| 05:44:56
| <defunctzombie> | substack: I found one for css |
| 05:44:58
| <defunctzombie> | with npm-css |
| 05:45:03
| <substack> | defunctzombie: it's very bad UI to force huge latency penalties to fetch very small amounts of static content |
| 05:45:04
| <defunctzombie> | that I think is a very good approach |
| 05:45:09
| <Raynos> | defunctzombie: there is no better approach for templates |
| 05:45:12
| <substack> | and it doesn't compose well at all |
| 05:45:12
| <defunctzombie> | but I have not heard a good answer to the html side |
| 05:45:21
| <defunctzombie> | I agree |
| 05:45:48
| <substack> | because when you ship a lib, users downstream will need to serve up the static content in such a way that their apps can fetch the resources with xhr |
| 05:45:53
| <dominictarr> | what I don't understand, is why anyone likes HTML |
| 05:46:00
| <substack> | and that scales really terribly when you have dozens of libs with static content |
| 05:46:01
| <defunctzombie> | dominictarr: familiarity |
| 05:46:08
| <defunctzombie> | that goes a long way |
| 05:46:09
| * tphummel | joined |
| 05:46:12
| <dominictarr> | yeah, that is not a good reason. |
| 05:46:15
| <substack> | because that means dozens of round-trips for static content |
| 05:46:19
| <defunctzombie> | it is a very good reason actually |
| 05:46:25
| <defunctzombie> | substack: I agree 100% |
| 05:47:19
| <dominictarr> | defunctzombie: you can have HTML, but you have to have a build step too |
| 05:47:23
| <defunctzombie> | however, I am more inclined to say you can just watch-build an html file into a js string which you can require at this time |
| 05:47:41
| <defunctzombie> | I want to be convinced of a clean alternative :) |
| 05:47:43
| <substack> | Raynos: ok so how should modules specify that they need to be run through particular plugins when being browserified? |
| 05:47:49
| <defunctzombie> | that is not some open ended thing |
| 05:47:52
| <substack> | the obvious place to put this would seem to be the package.json |
| 05:47:57
| <defunctzombie> | but specific to html templates |
| 05:48:00
| <Raynos> | substack: package.json ? |
| 05:48:01
| <defunctzombie> | which seems to be the issue here |
| 05:48:35
| <dominictarr> | it should be the author's job to bundle their shit before being published |
| 05:48:38
| <substack> | Raynos: otherwise consumers of modules will need to adjust what plugins they use based on what their dependencies are |
| 05:48:46
| <dominictarr> | before publishing the module |
| 05:48:51
| <substack> | if we are going to have plugins, they should be module-local |
| 05:48:53
| <Raynos> | defunctzombie: fs.readHtmlSync(...) |
| 05:49:05
| <Raynos> | throw an exception if the file does not contain valid html |
| 05:49:12
| <defunctzombie> | haha |
| 05:49:16
| <dominictarr> | require.requireText(file) |
| 05:49:22
| <substack> | dominictarr: that also could work |
| 05:49:26
| <substack> | a prepublish hook |
| 05:49:46
| <defunctzombie> | now we have to parse for that? |
| 05:49:52
| <defunctzombie> | at least that is more contained |
| 05:49:54
| <substack> | the api for this already exists, works in node, and is general-purpose: fs.readFileSync() |
| 05:50:01
| <dominictarr> | require.requireBase64(…) <-- but this won't work in node |
| 05:50:12
| * tphummel | quit (Client Quit) |
| 05:50:37
| <dominictarr> | substack: so, if you only bundle things that don't have variable expressions in the name (apart from __dirname) |
| 05:50:38
| <substack> | so one problem with pre-publishing |
| 05:50:43
| <dominictarr> | it will work fine. |
| 05:50:48
| <substack> | dominictarr: yep |
| 05:50:53
| * mikeal | quit (Quit: Leaving.) |
| 05:51:02
| <defunctzombie> | I would not want something that doesn't work if I don't use some browserify plugin |
| 05:51:03
| <defunctzombie> | personally |
| 05:51:22
| <substack> | defunctzombie: you would just install it and then require() it in your app |
| 05:51:31
| <substack> | users won't even know they are using plugins |
| 05:51:36
| <substack> | and the plugins will be module-scoped |
| 05:52:02
| * defunctzombie | is not sold yet on the idea |
| 05:52:15
| <defunctzombie> | I do wanna revisit this commonjs inlining thing and d3 for a moment |
| 05:52:28
| <defunctzombie> | and why the overhead percentages were so huge? |
| 05:52:37
| <dominictarr> | prepublish is simplest, overall. |
| 05:52:46
| <defunctzombie> | I would expect the d3.js concat and built with require to be almost hte same |
| 05:53:15
| <substack> | dominictarr: there is a problem with prepublish: "main" or the "browsers" field needs to point at some generated content |
| 05:53:26
| <defunctzombie> | oh, I see why, cause of all the damn require statements |
| 05:53:43
| <defunctzombie> | substack: not a problem, just generate the template into another file |
| 05:53:54
| <defunctzombie> | that is required by the main js or such |
| 05:53:57
| <dominictarr> | exactly |
| 05:54:14
| <dominictarr> | module.exports = string |
| 05:54:33
| <defunctzombie> | better yet, browsers field could be used to point to generated on if available or some node one that sync loads your script and returns it |
| 05:54:52
| <substack> | this seems like a poor solution |
| 05:54:58
| <defunctzombie> | probably |
| 05:55:00
| <substack> | browserify should build the bundle when run |
| 05:55:08
| <defunctzombie> | what is a poor solution is: https://github.com/sebmarkbage/d3/blob/cjs/src/d3.geo.js |
| 05:55:09
| <defunctzombie> | wow |
| 05:55:20
| <substack> | generating temporary files does not seem like a very good solution |
| 05:55:24
| <substack> | very easy to get out of sync |
| 05:55:45
| <Raynos> | substack: the problem with fs.readFileSync |
| 05:55:48
| <defunctzombie> | substack: I think the idea would be to generate a string file on publish |
| 05:55:48
| <Raynos> | is __dirname |
| 05:55:56
| <defunctzombie> | but yes, I agree I am not sold on that either |
| 05:56:06
| <Raynos> | fs.readFileSync(__dirname + "/templates/x.html") |
| 05:56:15
| <substack> | Raynos: that's not a problem |
| 05:56:39
| <substack> | Raynos: it's a plugin-writer problem, out of scope for browserify core and solvable |
| 05:57:22
| * saijanai_ | joined |
| 05:57:59
| <substack> | defunctzombie: that tightly-couples publish events with static file changes |
| 05:58:04
| <substack> | I don't like that |
| 05:58:08
| <defunctzombie> | agreed |
| 05:58:24
| <substack> | anyways arguing about things is for tc39 |
| 05:58:28
| <substack> | I'm just going to build this |
| 05:58:31
| <defunctzombie> | personally, I think require('foo.html') isn't so terrible but it does break the notion that you require js or json |
| 05:58:38
| <substack> | that is pretty bad |
| 05:58:44
| <defunctzombie> | yea |
| 05:58:50
| <substack> | not ever going to support require('foo.html') |
| 05:58:53
| <substack> | that doesn't work in node |
| 05:58:56
| <defunctzombie> | right |
| 05:58:57
| <defunctzombie> | yep |
| 05:59:12
| <substack> | fs.readFileSync() works in node |
| 05:59:15
| <defunctzombie> | what are your thoughts on this mess: https://github.com/sebmarkbage/d3/blob/cjs/src/d3.geo.js |
| 05:59:17
| <substack> | so that's what I'll do, but in a plugin |
| 05:59:51
| <substack> | defunctzombie: jump on the thread and lay down what's actually going on |
| 06:00:03
| <substack> | the problem is that the dependencies will take some more to winnow down |
| 06:00:14
| <substack> | everything is a global mish-mash at the moment |
| 06:00:30
| <defunctzombie> | wow |
| 06:01:11
| <substack> | shouldn't expect to get parity with concat right away with the first pass, it will take some work to get similar results with more explicit dependencies |
| 06:01:22
| <defunctzombie> | yea |
| 06:01:38
| <defunctzombie> | I would basically just tell him that it is way more maintainable as modules |
| 06:01:41
| <defunctzombie> | and testable |
| 06:01:46
| <defunctzombie> | versus some global god knows what |
| 06:01:59
| <substack> | and with time it can be made to be more compact in the final bundle size |
| 06:02:01
| <defunctzombie> | every other programming languages uses modular code |
| 06:02:08
| <defunctzombie> | yea |
| 06:02:14
| <defunctzombie> | I just wish I had a better response :/ |
| 06:02:22
| <defunctzombie> | than "be strong, fight the good fight" |
| 06:04:08
| <defunctzombie> | wow: https://github.com/sebmarkbage/d3/blob/cjs/src/d3.core.js |
| 06:04:20
| <defunctzombie> | I am amazed this was done by hand |
| 06:04:38
| <defunctzombie> | https://github.com/sebmarkbage/d3/blob/cjs/src/d3.core.js |
| 06:04:40
| <defunctzombie> | oh jesus |
| 06:04:45
| <defunctzombie> | ok.. I can comment on that :) |
| 06:04:53
| <substack> | just link to those files in your response |
| 06:05:16
| <substack> | and show how it can be done better in a more modular way that also decreases the bundle sizes |
| 06:05:44
| <defunctzombie> | yea |
| 06:07:25
| <dominictarr> | argh useragent won't browserify nicely, it's MASSIVE |
| 06:07:43
| <defunctzombie> | dominictarr: yea, it isn't really made for client side |
| 06:07:52
| <defunctzombie> | it has a db within it basically |
| 06:07:54
| <defunctzombie> | iirc |
| 06:08:11
| <defunctzombie> | substack: buddy of mine has an interesting hack with testling that I think he will do |
| 06:08:18
| <defunctzombie> | substack: since testling outputs json data |
| 06:08:30
| <defunctzombie> | he is gonna scrape it to make feature compat tables |
| 06:08:31
| <defunctzombie> | haha |
| 06:08:32
| <substack> | testling or testling-ci? |
| 06:08:35
| <defunctzombie> | ci |
| 06:08:40
| <substack> | ok good |
| 06:08:47
| <substack> | going to hide away the old stuff soon |
| 06:09:15
| <defunctzombie> | he has some cool modules for compat stuff |
| 06:09:15
| <defunctzombie> | https://github.com/marcello3d/browser-bencher |
| 06:09:19
| <defunctzombie> | https://github.com/marcello3d/polyfill.js |
| 06:09:24
| <substack> | cool |
| 06:09:35
| <defunctzombie> | https://github.com/marcello3d/node-bs |
| 06:09:38
| <dominictarr> | there is another lib that is not as bad |
| 06:12:55
| <defunctzombie> | haha |
| 06:14:30
| <defunctzombie> | substack: source processing can be done after required since you still have the source |
| 06:14:32
| <defunctzombie> | and location |
| 06:14:40
| <defunctzombie> | I think |
| 06:15:00
| <substack> | required should parse the source after it's been transformed |
| 06:15:22
| <Raynos> | ok |
| 06:15:25
| <Raynos> | all I want to do |
| 06:15:29
| <Raynos> | is ... |
| 06:15:34
| <Raynos> | I should just write a js templating engine |
| 06:15:34
| <defunctzombie> | 3 dots? |
| 06:16:39
| <defunctzombie> | yea, that isn't gonna end in sadness at all |
| 06:17:33
| <defunctzombie> | substack: why after? |
| 06:18:08
| <defunctzombie> | substack: I am tempted to make required behave in an interative manner, something like: |
| 06:18:18
| <defunctzombie> | required(src, filename, cb); |
| 06:18:24
| <defunctzombie> | to get the first level of deps for that source |
| 06:18:31
| <defunctzombie> | and then if you want more you just keep going |
| 06:18:48
| <defunctzombie> | until you have had enough hahaha |
| 06:19:08
| <defunctzombie> | filename is needed for relative requires and module lookup |
| 06:19:13
| <defunctzombie> | could even be pathname actually |
| 06:19:22
| <substack> | defunctzombie: that'd be pretty good |
| 06:19:30
| <substack> | module-deps is just a readable stream |
| 06:19:33
| <substack> | so it fits better |
| 06:19:36
| <defunctzombie> | yea |
| 06:19:47
| <defunctzombie> | so you can just iterate it however you want |
| 06:19:56
| <substack> | can required just have an opts.transform function to wrap around the src? |
| 06:20:15
| <substack> | src = (opts.transform || String)(src, filename) |
| 06:20:17
| <defunctzombie> | substack: it could, but I kinda feel like this approach would be simpler |
| 06:20:26
| <defunctzombie> | and instead of having to hook into all sorts of things |
| 06:20:33
| <defunctzombie> | that you might ever want required to do |
| 06:20:40
| <defunctzombie> | you just ask it to resolve the current level |
| 06:21:09
| <defunctzombie> | basically, it is resolve except it starts with a js source and return multiple resolved deps |
| 06:21:12
| <substack> | but what about transforming the src? |
| 06:21:23
| <defunctzombie> | substack: you give it whatever source you want |
| 06:21:32
| <defunctzombie> | so transform it before you give it the source |
| 06:21:32
| <substack> | with an opt? |
| 06:21:35
| <defunctzombie> | substack: nope |
| 06:21:42
| <substack> | yeah that's the same as I was saying I think |
| 06:21:45
| <substack> | except I am confused now |
| 06:21:46
| <defunctzombie> | required(src, path, cb); |
| 06:21:48
| <defunctzombie> | haha |
| 06:21:57
| <defunctzombie> | I am saying that instead of returning a deep tree |
| 06:22:02
| <defunctzombie> | only process one level |
| 06:22:08
| <defunctzombie> | based on input source and path |
| 06:22:11
| <defunctzombie> | that is it |
| 06:22:24
| <defunctzombie> | you get back the same list of deps but only at that level |
| 06:22:31
| <defunctzombie> | so if you want to build a tree you can |
| 06:22:40
| <defunctzombie> | if you don't wnat to, you don't have to |
| 06:22:42
| <substack> | so just a thin wrapper on top of detective and browser-resolve? |
| 06:22:47
| <defunctzombie> | basically |
| 06:22:48
| <substack> | resolve is already a param |
| 06:23:00
| <defunctzombie> | yea, so that would stay a param |
| 06:23:14
| <defunctzombie> | since that is the point of "required" |
| 06:23:27
| <defunctzombie> | is to glue detective and resolve together |
| 06:23:43
| <defunctzombie> | really, you could do this without it hahaha |
| 06:23:51
| <substack> | yes I was thinking that |
| 06:24:01
| <defunctzombie> | it becomes really simple |
| 06:24:20
| <defunctzombie> | just a function that takes src, path, opt, and cb |
| 06:24:30
| <defunctzombie> | and just returns that level of deps/info |
| 06:24:39
| <defunctzombie> | then you again do whatever you want to read the source |
| 06:24:43
| <defunctzombie> | transform, etc |
| 06:24:45
| <defunctzombie> | and call it again |
| 06:25:11
| <defunctzombie> | really having browser-resolve as a separate module is the bigger win here |
| 06:25:21
| <defunctzombie> | cause the detective stuff can be done in many ways |
| 06:26:00
| <defunctzombie> | and I think this could fit nicer with your streaming stuff (maybe) and also open up for this source transformation or whatever crazy |
| 06:26:44
| <defunctzombie> | I need to sleep |
| 06:30:17
| <defunctzombie> | substack: idea for the future |
| 06:30:22
| <defunctzombie> | if detective can take an AST |
| 06:30:37
| <defunctzombie> | then module deps can make an AST, get detective to read it |
| 06:30:40
| <defunctzombie> | get the deps |
| 06:30:46
| <defunctzombie> | then minify the requires |
| 06:30:52
| <defunctzombie> | down to numbers or something |
| 06:31:06
| <defunctzombie> | but really, I think that is mucho overkill in most cases |
| 06:31:33
| <defunctzombie> | the d3 stuff is a rare exception of massive and is not how many smaller libs are assembled |
| 06:33:12
| * mikeal | joined |
| 06:34:02
| * defunctzombie | changed nick to defunctzombie_zz |
| 06:35:32
| <substack> | yes |
| 06:35:45
| <substack> | I'm open for experimenting with AST ideas |
| 06:35:50
| <dominictarr> | defunctzombie_zz: Raynos okay, fixed http://dominictarr.github.com/useragent-wtf/ |
| 06:36:19
| * AvianFlu | quit (Remote host closed the connection) |
| 06:37:53
| * mikeal | quit (Ping timeout: 248 seconds) |
| 06:42:20
| * lyaunzbe_ | joined |
| 06:44:46
| * lyaunzbe | quit (Ping timeout: 276 seconds) |
| 06:57:35
| * dominictarr | quit (Quit: dominictarr) |
| 07:04:04
| * mikeal | joined |
| 07:05:44
| * slaskis | joined |
| 07:09:06
| * mikeal | quit (Ping timeout: 264 seconds) |
| 07:24:31
| * shuaib | joined |
| 07:25:18
| * ins0mnia | joined |
| 07:28:56
| * mikolalysenko | quit (Ping timeout: 246 seconds) |
| 07:35:29
| * ins0mnia | quit (Ping timeout: 248 seconds) |
| 07:35:34
| * mikeal | joined |
| 07:39:18
| * sveisvei | quit (*.net *.split) |
| 07:39:47
| * mikeal | quit (Ping timeout: 246 seconds) |
| 07:40:36
| * mikeal | joined |
| 07:51:04
| * sveisvei | joined |
| 08:02:14
| * slaskis | quit (Quit: slaskis) |
| 08:21:37
| * st_luke | quit (Remote host closed the connection) |
| 08:22:11
| * shuaib | quit (Quit: Computer has gone to sleep.) |
| 08:26:41
| * on9 | joined |
| 08:34:30
| * slaskis | joined |
| 08:45:48
| * shuaib | joined |
| 08:51:01
| <Altreus> | pkrumins: map { (split / /)[0,1] } :) |
| 08:51:12
| <Altreus> | I will leave a comment!! |
| 09:04:33
| * fotoverite | joined |
| 09:10:10
| * lyaunzbe | joined |
| 09:12:45
| * lyaunzbe_ | quit (Ping timeout: 252 seconds) |
| 09:21:52
| * kenperkins | quit (Quit: Computer has gone to sleep.) |
| 09:40:50
| * mirkok | joined |
| 10:34:05
| * jibay | joined |
| 10:43:24
| * ins0mnia | joined |
| 10:44:44
| * shuaib | quit (Ping timeout: 252 seconds) |
| 10:49:19
| * shuaib | joined |
| 10:52:03
| * fotoverite | quit (Quit: fotoverite) |
| 11:17:46
| * shuaib | quit (Ping timeout: 276 seconds) |
| 11:21:47
| * shuaib | joined |
| 12:04:11
| * ralphtheninja | joined |
| 12:37:58
| * CryptoQuick | quit (Quit: CryptoQuick) |
| 13:52:44
| * shuaib | quit (Ping timeout: 255 seconds) |
| 14:03:07
| * shuaib | joined |
| 14:07:29
| * shuaib | quit (Ping timeout: 252 seconds) |
| 14:11:08
| * shuaib | joined |
| 14:14:33
| * mikolalysenko | joined |
| 14:33:52
| <ralphtheninja> | juliangruber: I like multilevel-http! :) |
| 14:35:42
| <ralphtheninja> | juliangruber: and multilevel is awesome too, very good idea to wrap it like that so multiple processes can use it |
| 14:36:49
| <juliangruber> | ralphtheninja: hehe :) |
| 14:37:00
| <ralphtheninja> | I was actually thinking about this last night |
| 14:37:45
| <ralphtheninja> | because I have this script/process that I want to use levelup, but I also want to expose the data to other processes |
| 14:47:50
| <juliangruber> | jup |
| 14:48:08
| <juliangruber> | does anyone have experience with /dev/udp/ in bash? |
| 14:54:51
| <juliangruber> | mongostat --noheaders --all 1 | awk '{if (NR!=1) {print "mongodb01.connections:" $19 "|g"}}' | nc -w 1 -u STATSD_HOSTNAME 8125 |
| 14:55:02
| <juliangruber> | log the number of open connections to mongodb to statsd |
| 14:55:43
| * CryptoQuick | joined |
| 15:17:46
| * kenperkins | joined |
| 15:19:44
| * mikolalysenko | quit (Ping timeout: 252 seconds) |
| 15:20:56
| * AvianFlu | joined |
| 15:24:04
| * defunctzombie_zz | changed nick to defunctzombie |
| 15:25:46
| * thatguydan | quit (Read error: Connection reset by peer) |
| 15:26:17
| * thatguydan | joined |
| 15:26:42
| * mikeal | quit (Quit: Leaving.) |
| 15:27:41
| <defunctzombie> | substack: this insert globals slowness needs to be resolved |
| 15:27:50
| <defunctzombie> | it is impossible to use jquery |
| 15:27:58
| <defunctzombie> | or really anything big |
| 15:28:15
| <defunctzombie> | I think it should be dumber actually |
| 15:28:25
| <defunctzombie> | and just look for a regex pattern |
| 15:28:36
| <defunctzombie> | cause hte overhead of inserting the function(global) is trivial in size |
| 15:46:03
| * mikolalysenko | joined |
| 15:46:26
| <defunctzombie> | substack: also, the global thing could be inserted once per bundle versus once per module |
| 15:46:41
| <defunctzombie> | same with process technically |
| 15:46:49
| <defunctzombie> | just __filename and __dirname aren't |
| 15:50:05
| <defunctzombie> | substack: so here is what I think should happen (open to other ideas :)) |
| 15:50:16
| <defunctzombie> | global is always inserted into the function that calls the module |
| 15:50:37
| <defunctzombie> | the overhead of this is very little after minification |
| 15:50:55
| <defunctzombie> | i.e. on the same line where function(require, exports, module) are |
| 15:51:23
| <defunctzombie> | for process, __filename, and __dirname use a basic regex rule |
| 15:51:38
| * saijanai_ | quit (Read error: Connection reset by peer) |
| 15:51:44
| <defunctzombie> | off the top of my head I would start with /\wprocess[.]/ |
| 15:52:05
| * saijanai_ | joined |
| 15:52:07
| <defunctzombie> | or /(\w|;)process[.]/ |
| 15:55:31
| <defunctzombie> | and I think the global detection is broken |
| 15:55:38
| <defunctzombie> | in the current form |
| 15:55:48
| <defunctzombie> | false positive |
| 16:00:14
| * dguttman | joined |
| 16:02:50
| * dguttman | quit (Client Quit) |
| 16:05:36
| * mikeal | joined |
| 16:06:34
| * dguttman | joined |
| 16:10:29
| <juliangruber> | defunctzombie: what about process in strings or comments? |
| 16:10:54
| <defunctzombie> | juliangruber: that is what the [.].* would be for in the regex |
| 16:11:06
| <defunctzombie> | and in any case |
| 16:11:07
| <defunctzombie> | whatever |
| 16:11:16
| <defunctzombie> | the overhead of adding it is not so crazy |
| 16:11:31
| <defunctzombie> | but the overhead of this smart detection is pretty bad right now |
| 16:11:48
| <defunctzombie> | when the smart detection can be on part with the basic regex |
| 16:11:53
| <defunctzombie> | then I think it will be ok |
| 16:12:04
| <juliangruber> | v8 exposing its ast would be awesome |
| 16:16:11
| <juliangruber> | https://alpha.app.net/tenderlove/post/2404890 |
| 16:16:36
| <juliangruber> | http://stackoverflow.com/questions/9451067/access-the-abstract-syntax-tree-of-v8-engine |
| 16:17:17
| <defunctzombie> | well, we already get the AST for the source |
| 16:17:33
| <defunctzombie> | I just think the overhead is not warranted |
| 16:17:34
| <defunctzombie> | atm |
| 16:17:43
| <juliangruber> | so getting the AST isn't the slow part? |
| 16:18:02
| <chrisdickinson> | are there any plans to revisit buffer-browserify and base it on typed arrays? |
| 16:18:02
| <chrisdickinson> | (the lack of array-index lookup tends to break anything that needs buffers in browserify) |
| 16:18:05
| <chrisdickinson> | also, for some reason using the global Buffer object doesn't trigger the auto-require of 'buffer' |
| 16:18:05
| <chrisdickinson> | (not in my code -- in a dependency of my code) |
| 16:18:48
| <chrisdickinson> | cc defunctzombie ^^ |
| 16:19:20
| <defunctzombie> | chrisdickinson: use of global Buffer is not supported |
| 16:19:25
| <defunctzombie> | use require('buffer') instead |
| 16:19:28
| <chrisdickinson> | 'kk, that's one problem solved |
| 16:19:37
| <defunctzombie> | when in doubt, require :) |
| 16:19:41
| <chrisdickinson> | that means i need to either fork or send prs to whoever's using it |
| 16:19:42
| <defunctzombie> | you can require process now too |
| 16:19:44
| <chrisdickinson> | (it's not me) |
| 16:19:47
| <defunctzombie> | send PRs |
| 16:19:52
| <defunctzombie> | global variables are bad |
| 16:19:54
| <chrisdickinson> | it's also for a really old module |
| 16:19:56
| <chrisdickinson> | yeah, noted |
| 16:19:58
| <defunctzombie> | node should not have introduced more |
| 16:20:04
| <chrisdickinson> | though a lot of the time you don't have control over that |
| 16:20:11
| <defunctzombie> | send prs |
| 16:20:11
| <chrisdickinson> | sub-sub-sub dependencies, etc |
| 16:20:15
| <defunctzombie> | make the world a better place :) |
| 16:20:19
| <chrisdickinson> | hah |
| 16:20:28
| <defunctzombie> | chrisdickinson: for the buffer thing I would open an issue |
| 16:20:35
| <defunctzombie> | in your own usage you can certainly override anything you want |
| 16:20:38
| <chrisdickinson> | 'kk. there's already an issue open |
| 16:20:40
| <chrisdickinson> | how? |
| 16:20:49
| <defunctzombie> | via bundle.require(/file.js, { expose: 'buffer' }); |
| 16:20:49
| <chrisdickinson> | just bundle my own buffer-browserify? |
| 16:20:58
| <defunctzombie> | or in your module |
| 16:21:02
| <defunctzombie> | use the "browser" field |
| 16:21:14
| <defunctzombie> | with "buffer": "alternative buffer module or file" |
| 16:21:18
| <chrisdickinson> | ah, and that'll replace buffer for sub dependencies? |
| 16:21:29
| <defunctzombie> | at the module level no |
| 16:21:31
| <defunctzombie> | the api one will |
| 16:21:33
| <chrisdickinson> | (so, i'm using block-stream -- mostly because the original node-tar does) |
| 16:21:49
| * dguttman | quit (Quit: dguttman) |
| 16:22:09
| <chrisdickinson> | sigh sigh sigh; i know it'd introduce cruft but i kind of wish there was a "support legacy globals" flag in browserify |
| 16:22:35
| * dguttman | joined |
| 16:22:37
| <chrisdickinson> | module level? you mean in my package.json? |
| 16:23:10
| <chrisdickinson> | it kind of undermines "just use browserify to put your modules in the browser!" to have a bunch of cases where it becomes "roll your own browserify to use this module in the browser" |
| 16:23:24
| <chrisdickinson> | especially since you only have control at the root |
| 16:23:52
| <chrisdickinson> | and what if there's two packages that require different "roll your own browserify" bits? |
| 16:24:10
| <defunctzombie> | chrisdickinson: buffer global was never supported iirc |
| 16:24:26
| <chrisdickinson> | http://nodejs.org/api/globals.html#globals_class_buffer |
| 16:24:38
| <defunctzombie> | chrisdickinson: you don't have to roll your own browserify |
| 16:24:40
| <chrisdickinson> | not saying that's a *good* thing |
| 16:24:55
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 16:25:17
| <defunctzombie> | chrisdickinson: just saying the behavior has not changed from before |
| 16:25:25
| <chrisdickinson> | oh i know :) |
| 16:25:32
| <chrisdickinson> | i tried it with [email protected] too |
| 16:25:40
| <chrisdickinson> | but that's a bug, since we support other globals |
| 16:25:46
| <defunctzombie> | chrisdickinson: also, it isn't an easy problem everyone starts to have different needs and demands, the buffer index thing we could revisit most likely |
| 16:25:58
| <defunctzombie> | just takes someone to provide a working implementation we are comfortable with |
| 16:26:09
| <chrisdickinson> | yeah |
| 16:26:10
| <defunctzombie> | but at the same time, like I said, you can replace your use of it with whatever |
| 16:26:13
| <chrisdickinson> | that's difficult :( |
| 16:26:20
| <defunctzombie> | that is what makes it more powerful |
| 16:26:32
| <chrisdickinson> | well, i'd need to replace it at the `tar-parse` level, *and* at the block-stream level |
| 16:26:45
| <chrisdickinson> | which sucks |
| 16:27:31
| <chrisdickinson> | but yeah, supporting global Buffer (do we warn on implicit globals? we should, somehow) would be awesome |
| 16:27:43
| <chrisdickinson> | i'll see about making a better buffer-browserify and issuing prs |
| 16:28:10
| <chrisdickinson> | it's so close to api compatibility, it's just missing index lookup / setting, which is also unfortunately the hard part |
| 16:28:23
| <chrisdickinson> | had this issue with my png chunk stream as well |
| 16:32:28
| * CryptoQuick_ | joined |
| 16:32:41
| * mikeal | quit (Quit: Leaving.) |
| 16:33:17
| * CryptoQuick | quit (Read error: Operation timed out) |
| 16:33:17
| * CryptoQuick_ | changed nick to CryptoQuick |
| 16:38:50
| * yorick | joined |
| 16:38:51
| * yorick | quit (Changing host) |
| 16:38:51
| * yorick | joined |
| 16:40:13
| * mirkok | quit (Quit: mirkok) |
| 16:40:54
| * mirkok | joined |
| 16:42:11
| * CryptoQuick | quit (Ping timeout: 248 seconds) |
| 16:44:09
| * mikolalysenko | joined |
| 16:45:30
| * lyaunzbe | quit (Read error: Connection reset by peer) |
| 16:45:47
| * lyaunzbe | joined |
| 16:46:26
| * CryptoQuick | joined |
| 17:02:02
| * mikolalysenko | quit (Ping timeout: 252 seconds) |
| 17:03:18
| * mikeal | joined |
| 17:14:08
| * mikeal | quit (Ping timeout: 252 seconds) |
| 17:18:11
| * on9 | quit (Remote host closed the connection) |
| 17:43:44
| * mikolalysenko | joined |
| 17:45:17
| * mikeal | joined |
| 17:46:51
| <defunctzombie> | pkrumins: https? |
| 17:49:02
| <defunctzombie> | my github badges get stale :( |
| 17:53:22
| <pkrumins> | ok getting https right now |
| 17:56:17
| <pkrumins> | it will be done today |
| 18:00:59
| <ins0mnia> | am I the only one who hates coffeescript??? |
| 18:01:59
| <ins0mnia> | this thing gives nausea to look at |
| 18:02:35
| <pkrumins> | there is no need to hate it, it's simply irrelevant |
| 18:02:50
| <ins0mnia> | pkrumins: good point |
| 18:02:58
| <pkrumins> | you just ignore anything that matches /coffeescript/ in all mediums, that's all. |
| 18:03:14
| <defunctzombie> | ^ +1 |
| 18:03:17
| <pkrumins> | like you ignore ads. coffeescript blindness. |
| 18:03:20
| <defunctzombie> | pkrumins: \o/ :) |
| 18:03:29
| <ins0mnia> | I was reading an issue someone submitted to one of the substack's modules and he wrote the sample in coffeescript.. |
| 18:03:50
| <ins0mnia> | pkrumins: lol |
| 18:04:06
| <defunctzombie> | ins0mnia: yea, happens more than you think |
| 18:08:08
| * mirkok | quit (Quit: mirkok) |
| 18:13:02
| <lyaunzbe> | Hey guys, so say I want to use path (the library) on the client side, is this something I could do with browserify? |
| 18:15:35
| * fotoverite | joined |
| 18:16:23
| * heath | quit (Remote host closed the connection) |
| 18:16:40
| * heath | joined |
| 18:20:29
| * heath | quit (Changing host) |
| 18:20:29
| * heath | joined |
| 18:20:35
| * heath | changed nick to ybit2 |
| 18:20:44
| * ybit2 | changed nick to heath |
| 18:24:01
| * lyaunzbe | quit (Remote host closed the connection) |
| 18:29:37
| * mirkok | joined |
| 18:31:50
| * CryptoQuick | quit (Read error: Connection reset by peer) |
| 18:31:56
| * CryptoQuick_ | joined |
| 18:35:46
| * thatguydan | quit (Quit: thatguydan) |
| 18:37:30
| * TToivanen | joined |
| 18:37:33
| * TToivanen | part |
| 18:40:19
| <Raynos> | defunctzombie, substack: Maybe put require extensions back for node compat, making coffeescript people not hate you, allowing for loading template / html assets |
| 18:40:38
| <Raynos> | alternatively just export any non js file as text or buffer |
| 18:40:39
| * fotoverite | quit (Read error: Connection reset by peer) |
| 18:40:40
| <defunctzombie> | Raynos: I don't care if CS people hate me |
| 18:40:56
| <defunctzombie> | CS is not javascript |
| 18:41:00
| <defunctzombie> | I care about bundling javascript |
| 18:41:00
| <Raynos> | well yes |
| 18:41:12
| <Raynos> | I will still patch your thing to just require non-js files as text |
| 18:41:17
| <defunctzombie> | they can go do whatever they want in their separate language land |
| 18:41:46
| <defunctzombie> | Raynos: the point of the various components was to make it easy to assemble whatever you needed |
| 18:42:03
| <defunctzombie> | I personally think browserify is a great bundling tool and leave it at that |
| 18:42:07
| <defunctzombie> | plugins will help with this |
| 18:42:18
| <Raynos> | but I want to a way to bundle static assets |
| 18:42:20
| <Raynos> | mainly templates |
| 18:42:23
| <defunctzombie> | I know |
| 18:42:24
| <Raynos> | or anything pre-processed |
| 18:42:25
| <defunctzombie> | :D |
| 18:42:35
| <Raynos> | why won't you let me run a preprocessor on my files on the fly |
| 18:42:41
| <defunctzombie> | Raynos: we will |
| 18:42:41
| <Raynos> | why do I need to run it seperately before the bundling |
| 18:42:45
| <Raynos> | cmon! |
| 18:42:51
| <defunctzombie> | Raynos: we talked about a nice way to do it |
| 18:42:55
| <Raynos> | Look at your express plugins that bundle all kinds of shit on the fly |
| 18:43:26
| <defunctzombie> | yea, and they work on stock browserify heh |
| 18:43:47
| * mirkok | quit (Quit: mirkok) |
| 18:43:53
| <defunctzombie> | Raynos: I feel your pain about templates |
| 18:43:58
| <defunctzombie> | the issue gets more complex tho |
| 18:44:02
| <defunctzombie> | lets say you wnat html templates |
| 18:44:06
| <defunctzombie> | someone else wants handlebars |
| 18:44:18
| <Raynos> | just allow arbitary preprocessors |
| 18:44:21
| <defunctzombie> | now to use their shit I need to have handlebars plugins for browserify to inline |
| 18:44:29
| <defunctzombie> | and then some other complex use case comes up |
| 18:44:30
| <Raynos> | { ".file-extension": "COMMAND LINE COMMAND" } |
| 18:44:42
| <defunctzombie> | the reality is that a simple.. here is the file is the lowest common thing |
| 18:44:53
| <Raynos> | well what about screwing those people |
| 18:44:57
| <Raynos> | and only returning a string |
| 18:45:16
| <Raynos> | handlebars people can still call `require("handlebars").compile(require("./templates/x.handlebars"))` |
| 18:45:28
| <Raynos> | same with coffeescript |
| 18:45:37
| <Raynos> | they can just compile their coffeescript down to js in the client and eval it |
| 18:45:42
| <defunctzombie> | yea, if the string approach is used |
| 18:45:45
| <Raynos> | Actually ignore the coffeescript use-case |
| 18:45:48
| <defunctzombie> | haha |
| 18:45:57
| <defunctzombie> | Raynos: I totally understand the template desire, I am not against it |
| 18:46:09
| <defunctzombie> | I think it is an important part of making web components/widgets |
| 18:46:09
| <Raynos> | I also want to require .svg files btw |
| 18:46:16
| <robertjd_> | isaacs: how big should i expect the npm registry to be in /var/db/couchdb ? |
| 18:46:19
| <defunctzombie> | but see, that is where it gets out of control |
| 18:46:29
| <defunctzombie> | as a user of your lib I would not want that |
| 18:46:35
| <defunctzombie> | I may have better ways to provide static assets |
| 18:46:41
| <Raynos> | ? |
| 18:46:41
| <defunctzombie> | like images and such |
| 18:46:51
| <Raynos> | tough shit, who cares |
| 18:47:01
| <defunctzombie> | I care, my website, my servers |
| 18:47:34
| <defunctzombie> | anyhow, because i care I can bring up arguments against supporting it in a general sense, if you want it for your thing.. have at it :) |
| 18:47:54
| <defunctzombie> | personally I think it pushes app responsibility items to modules where such things shouldn't live |
| 18:48:04
| <defunctzombie> | Raynos: if you want static assets, go use component :p |
| 18:48:09
| <defunctzombie> | it will do it all for you hahaha |
| 18:49:11
| <defunctzombie> | Raynos: what I really want to see is a clever solution to try it out and less talk about it :D |
| 18:49:23
| <defunctzombie> | the browser field was this way for me |
| 18:49:32
| <defunctzombie> | I just went and did it cause no one else cared |
| 18:50:58
| <isaacs> | robertjd_: check it out on http://isaacs.iriscouch.com/_utils/ |
| 18:52:00
| * mirkok | joined |
| 19:00:21
| * shama | joined |
| 19:21:41
| * shuaib | quit (Quit: Textual IRC Client: http://www.textualapp.com/) |
| 19:22:19
| * mikeal | quit (Quit: Leaving.) |
| 19:24:05
| <defunctzombie> | I should probably stop trolling people on github issues |
| 19:25:32
| <mbalho> | - everyone, ever |
| 19:28:25
| <robertjd_> | isaacs: what does it mean if my registry.couch is 57gb, 10 larger than yours? |
| 19:28:57
| * mikolalysenko | quit (Quit: Lost terminal) |
| 19:33:28
| <Raynos> | defunctzombie: +1 |
| 19:52:08
| * thatguydan | joined |
| 19:52:36
| * mikeal | joined |
| 19:56:49
| * mikeal | quit (Ping timeout: 248 seconds) |
| 20:02:11
| * AvianFlu | quit (Remote host closed the connection) |
| 20:02:13
| * tilgovi | joined |
| 20:06:10
| * AvianFlu | joined |
| 20:09:14
| * thatguydan | quit (Read error: Connection reset by peer) |
| 20:10:24
| * thatguydan | joined |
| 20:11:32
| * mirkok | quit (Quit: mirkok) |
| 20:12:36
| * mirkok | joined |
| 20:29:44
| <rowbit> | /!\ ATTENTION: (default-local) [email protected] successfully signed up for developer browserling plan ($20). Cash money! /!\ |
| 20:29:44
| <rowbit> | /!\ ATTENTION: (default-local) paid account successfully upgraded /!\ |
| 20:38:59
| <Altreus> | guise I need advice |
| 20:39:01
| <Altreus> | anyone around? |
| 20:39:16
| <defunctzombie> | don't do it |
| 20:39:23
| <Altreus> | I don't know how to resynchronise async stuff - or should I just asynch everything and pass callbacks all over the place |
| 20:39:49
| <CoverSlide> | Altreus: yes |
| 20:40:00
| <defunctzombie> | Altreus: maybe, no, yes |
| 20:41:16
| <defunctzombie> | Raynos: https://github.com/Raynos/after/commit/6c258ba8139b6745e7022b38ab884682904afe41 |
| 20:41:21
| <defunctzombie> | think that is on for a 0.6.1 |
| 20:41:26
| <defunctzombie> | or do you want 0.7.0 for that behavior |
| 20:41:42
| <Altreus> | okay |
| 20:41:45
| <Altreus> | thanks :) |
| 20:41:46
| <Raynos> | I think that's correct behaviour |
| 20:41:49
| <Raynos> | feel free to bump minor |
| 20:41:49
| * lyaunzbe | joined |
| 20:42:05
| <defunctzombie> | Raynos: will do |
| 20:42:08
| <Raynos> | return the first error, swallow the rest |
| 20:42:12
| <defunctzombie> | yea |
| 20:42:18
| <Raynos> | feel free to add some kind of hook thing |
| 20:42:19
| <defunctzombie> | follows with what the readme says |
| 20:42:29
| <Raynos> | like an optional argument for other errors |
| 20:42:30
| <defunctzombie> | about callback called after N |
| 20:42:36
| <defunctzombie> | Raynos: yea, I think that could be good |
| 20:42:46
| <defunctzombie> | I will think about it and see if some nice way comes to mind |
| 20:42:47
| <Raynos> | after(n, callback, otherErrors) |
| 20:42:50
| <defunctzombie> | yea |
| 20:42:53
| <defunctzombie> | that is what I was thinking |
| 20:42:56
| <Raynos> | the problem is |
| 20:42:59
| <hij1nx> | dominictarr |
| 20:43:03
| <defunctzombie> | haha |
| 20:43:04
| <Raynos> | multiple errors from a single thing sucks |
| 20:43:11
| <defunctzombie> | I like how those statements ordered |
| 20:43:36
| <Raynos> | You really want a function to either return a (value OR err) or stream of [value, value, ..., (error OR end)] |
| 20:43:42
| <defunctzombie> | yea |
| 20:43:47
| <defunctzombie> | but to keep after simple |
| 20:43:51
| <Raynos> | even a stream should only emit one error |
| 20:44:00
| <defunctzombie> | I guess the compromise is you can have an optional error fn to capture other stuff |
| 20:44:05
| <defunctzombie> | if you really want |
| 20:44:12
| <defunctzombie> | this way no current users are broken |
| 20:44:21
| <defunctzombie> | and future users can get errors they care about |
| 20:47:19
| <defunctzombie> | Raynos: what should happen if after is called more than N times? |
| 20:47:25
| <defunctzombie> | should calls after N just be ignored? |
| 20:47:35
| <defunctzombie> | regardless of if they have error or not? |
| 20:49:04
| <Raynos> | defunctzombie: I think they should be ignored |
| 20:49:09
| <defunctzombie> | k |
| 20:49:10
| <Raynos> | you could throw an exception |
| 20:49:12
| <Raynos> | that works too |
| 20:49:44
| <Raynos> | `throw new Error("your an idiot. Fix your code")` |
| 20:49:57
| <Raynos> | throw new Error("after/index.js: Raynos hates you. Fix your code")` |
| 20:50:58
| <defunctzombie> | haha |
| 20:51:22
| <defunctzombie> | throwing could be good here |
| 20:51:32
| <defunctzombie> | it is an exceptional situation |
| 20:53:09
| * mikeal | joined |
| 20:53:30
| <Raynos> | I think literally putting 'Raynos makes you suffer by crashing your process' in the error message is pretty good |
| 20:53:54
| <defunctzombie> | haha |
| 20:57:25
| * mikeal | quit (Ping timeout: 248 seconds) |
| 21:01:38
| * ITpro | joined |
| 21:02:27
| * mirkok | quit (Quit: mirkok) |
| 21:03:20
| * slaskis | quit (Quit: slaskis) |
| 21:13:02
| * mirkok | joined |
| 21:15:56
| <defunctzombie> | Raynos: I sent you some shits for review |
| 21:23:54
| * mikeal | joined |
| 21:24:07
| * mirkok_ | joined |
| 21:25:51
| * mikolalysenko | joined |
| 21:26:46
| * mirkok | quit (Ping timeout: 256 seconds) |
| 21:26:47
| * mirkok_ | changed nick to mirkok |
| 21:28:54
| * mikeal | quit (Ping timeout: 264 seconds) |
| 21:30:52
| * mikeal | joined |
| 22:09:31
| <Raynos> | Captain OCD |
| 22:09:33
| <Raynos> | reviews your things |
| 22:10:42
| * dominictarr | joined |
| 22:12:07
| <dominictarr> | ins0mnia: hey you should publish the html-element thing we where working on the other day |
| 22:12:35
| <dominictarr> | https://npmjs.org/html-element |
| 22:12:42
| <dominictarr> | ^needs to exist! |
| 22:17:39
| <defunctzombie> | Raynos: Captain OCD misspoke |
| 22:17:39
| <Raynos> | defunctzombie: https://github.com/Raynos/after/pull/5 |
| 22:18:05
| <defunctzombie> | Raynos: hot |
| 22:18:12
| <defunctzombie> | now I think *that* can be a 0.7.0 |
| 22:18:19
| <Raynos> | dominictarr: what is html-element? |
| 22:18:37
| <defunctzombie> | i'll go ahead and bump it, thanks for the review |
| 22:19:09
| <ins0mnia> | dominictarr: y0 dominic, yeah this should be published |
| 22:19:27
| <dominictarr> | it's an minimal implementation of HTMLElement, so that hyperscript works in node. |
| 22:19:33
| <defunctzombie> | Raynos: dominictarr: I am guessing a wrapper around HTMLElement? |
| 22:19:35
| <ins0mnia> | dominictarr: was there anything missing in the last modification you made? |
| 22:19:40
| <defunctzombie> | or that |
| 22:19:53
| <Raynos> | dominictarr: I wanted one of those! |
| 22:20:04
| <dominictarr> | oh, there is still stuff to add, but it passes the tests we have! |
| 22:20:11
| <Raynos> | does it have a toString method and does it support attributes and childNodes ? |
| 22:20:19
| <ins0mnia> | dominictarr: hehe yeah :) |
| 22:20:30
| <dominictarr> | but publish it now, and then we'll add features as we need them |
| 22:20:35
| <hij1nx> | dominictarr: you had said something about lev earlier? |
| 22:20:36
| <Raynos> | maybe I should just use hyperscript |
| 22:20:41
| <ins0mnia> | dominictarr: ok then, gimme few mins |
| 22:20:51
| <hij1nx> | dominictarr: im doing some work on it now. |
| 22:21:02
| <dominictarr> | hij1nx: st_luke told me what I needed to know |
| 22:21:22
| <hij1nx> | dominictarr: ok, btw: `lev /path/to/db` works now |
| 22:21:35
| <ins0mnia> | Raynos: it has toString and childNodes |
| 22:21:38
| <dominictarr> | Raynos: to has toString, but not attributes yet (5 mins PR though!) |
| 22:21:55
| <Raynos> | i think thats all I need to run my widgets on the server |
| 22:22:12
| <Raynos> | #winning |
| 22:22:34
| <defunctzombie> | haha |
| 22:22:50
| <defunctzombie> | client/server being different things my ass. |
| 22:22:53
| <defunctzombie> | JS ALL THE THINGS!! |
| 22:22:53
| <LOUDBOT> | I DON'T GET CBC AND IT'S YOUR FAULT |
| 22:22:54
| <dominictarr> | hij1nx: sweet! |
| 22:23:12
| <dominictarr> | the browser is just a VM where you don't have root access |
| 22:24:01
| <hij1nx> | npm defunctzombie |
| 22:24:16
| <defunctzombie> | 404 |
| 22:24:26
| <hij1nx> | npm substack |
| 22:24:30
| <Raynos> | defunctzombie: thanks for actually fixing after. I was being a dick |
| 22:24:37
| <defunctzombie> | Raynos: no worries |
| 22:24:37
| * dominictarr | quit (Quit: dominictarr) |
| 22:24:38
| <substack> | beep boop |
| 22:24:49
| <defunctzombie> | Raynos: its all fun and games! |
| 22:24:56
| <Raynos> | dominictarr: do you have a strategy for "render a widget/component on the server, then find it in the client and enhance with event listeners" |
| 22:24:58
| <defunctzombie> | until someone uses coffeescript |
| 22:27:07
| <Raynos> | with client-side rendering you have a reference to the thing you need to attach events to |
| 22:27:19
| <substack> | here's how v2 plugins will work: |
| 22:27:43
| <substack> | for top-level compilation which will not affect anything in node_modules: |
| 22:28:09
| <substack> | browserify -t pluginname main.js > bundle.js |
| 22:28:39
| <substack> | first searches for pluginname as a module and expects it to have a module.exports that returns a through stream |
| 22:28:59
| <substack> | otherwise searches for pluginname in node_modules/.bin as a command and writes to its stdin, reading its stdout |
| 22:29:08
| <substack> | finally searches for pluginname in $PATH |
| 22:29:13
| <substack> | and writes to its stdin |
| 22:29:22
| <substack> | for module-level compilation: |
| 22:29:32
| <substack> | "browserify": { "transform": "pluginname" } |
| 22:29:58
| <substack> | which similar semantics but only operational on the local module files, not transferrable into parent or children node_modules |
| 22:30:34
| <defunctzombie> | substack: api? |
| 22:30:55
| <substack> | something like .transform('pluginname') |
| 22:31:04
| <substack> | which you can call multiple times to create a pipeline chain |
| 22:31:16
| <substack> | same semantics as -t |
| 22:31:26
| * lyaunzbe | quit (Remote host closed the connection) |
| 22:31:36
| <substack> | oh and you can have multiple -t args that will just call .transform() each time to set up a pipeline chain |
| 22:31:59
| <substack> | things that will not happen: overloading require() semantics to support non-js and non-json files |
| 22:32:28
| * thatguydan | quit (Read error: Connection reset by peer) |
| 22:32:37
| <substack> | and this can all be handled by module-deps |
| 22:32:48
| <substack> | I'll just pass the options directly through to module-deps from browserify |
| 22:32:49
| <defunctzombie> | substack: maybe .use is shorter? also, at what point will plugins be involved? |
| 22:32:52
| * thatguydan | joined |
| 22:32:53
| <defunctzombie> | are they after module deps? |
| 22:32:59
| <defunctzombie> | before? during? |
| 22:33:19
| <substack> | before being parsed for require() calls |
| 22:33:25
| <defunctzombie> | substack: also, sent over some insert global updates (one of them is a must have) the other a strong recommends :) |
| 22:33:31
| <defunctzombie> | cool |
| 22:33:52
| <substack> | but I'm open to later having some post-transform hooks |
| 22:33:53
| <defunctzombie> | so Raynos will be able to have something that inlines his html |
| 22:34:00
| <substack> | I'm just less clear on what the use case will be for that |
| 22:34:02
| <substack> | defunctzombie: yep |
| 22:34:05
| <defunctzombie> | since that doesn't change require semantics |
| 22:34:13
| <defunctzombie> | awesome |
| 22:34:14
| <substack> | coffee folk can have their thing too not that I like coffeescript particularly much |
| 22:34:33
| <defunctzombie> | substack: you gonna roll require(d) within module-deps |
| 22:34:41
| <defunctzombie> | or want required to expose that api we talked about? |
| 22:34:53
| <substack> | either way works |
| 22:35:09
| <substack> | I was just going to hack it into module-deps but if you want to support this in required i can wait and just use that |
| 22:36:54
| <kanzure> | hi substack. |
| 22:36:58
| <defunctzombie> | substack: hacking into module deps seems good by me |
| 22:37:19
| <defunctzombie> | or required can expose it if we like it and want others to play with it heh |
| 22:37:41
| <defunctzombie> | personally doesn't make much nevermind to me |
| 22:39:01
| * dominictarr | joined |
| 22:39:37
| <substack> | the commands being executed should also have some way to know what the filename is of the file they are transforming |
| 22:40:06
| <substack> | an env var seems like a good place for that |
| 22:40:25
| <defunctzombie> | substack: why not just get it in the stream data? |
| 22:40:31
| <defunctzombie> | I wouldn't rely on an env var |
| 22:40:56
| <substack> | out-of-band communication |
| 22:42:19
| * dominictarr | quit (Client Quit) |
| 22:44:07
| <defunctzombie> | substack: does it have to be out of bank? |
| 22:44:08
| <defunctzombie> | *band |
| 22:44:10
| <defunctzombie> | jesys |
| 22:44:29
| <defunctzombie> | too much money handling for me |
| 22:46:54
| * lyaunzbe | joined |
| 22:51:00
| <Raynos> | Let the FRP consume you ( http://www.ustream.tv/recorded/29330499 ) |
| 22:51:19
| * st_luke | joined |
| 22:51:30
| * mirkok | quit (Quit: mirkok) |
| 22:52:12
| <st_luke> | defunctzombie: do you remember that super cheap vps place you linked a while back? |
| 22:53:07
| <defunctzombie> | st_luke: digital ocean? |
| 22:53:23
| <st_luke> | yeah i think thats it, thanks |
| 22:54:06
| * mirkok | joined |
| 22:54:09
| <st_luke> | gonna transfer all my paas stuff to it |
| 22:54:34
| <Raynos> | st_luke: transfer it to joyent! |
| 22:54:36
| <Raynos> | Traitor. |
| 22:55:09
| <st_luke> | Raynos: these are super unimportant sites |
| 22:55:21
| <st_luke> | the important stuff goes on joyent :) |
| 22:55:23
| <Raynos> | get some free goodies from nodejitsu |
| 22:56:22
| <st_luke> | nodejitsu is cool but i dont think its really for me |
| 22:56:41
| <defunctzombie> | st_luke: you should, it is pretty good |
| 22:56:55
| <defunctzombie> | st_luke: sometimes a bit "laggy" feeling over ssh |
| 22:57:03
| <defunctzombie> | because they are 1 cpu instances |
| 22:57:05
| <defunctzombie> | but otherwise |
| 22:57:06
| <defunctzombie> | for 5$ |
| 22:57:08
| <defunctzombie> | amazing |
| 22:57:09
| <st_luke> | defunctzombie: no big deal, not putting anything critical on there |
| 22:57:12
| <defunctzombie> | yep |
| 23:00:05
| <defunctzombie> | I use nodejitsu when I have an in memory thing |
| 23:00:10
| <defunctzombie> | so something like tryme |
| 23:00:33
| <defunctzombie> | cause it is just a side project and I don't want to deal with deploying it |
| 23:00:52
| <defunctzombie> | speaking of tryme, more people need to make interactive examples |
| 23:01:05
| <defunctzombie> | all client oriented modules should have interactive examples |
| 23:03:45
| * defunctzombie | changed nick to defunctzombie_zz |
| 23:08:02
| <st_luke> | defunctzombie_zz: yea, having easy deploys is nice but i think if deploys ever start to feel inconvenient then I should write my own tool |
| 23:15:25
| * dominictarr | joined |
| 23:27:25
| * mikolalysenko | quit (Ping timeout: 240 seconds) |
| 23:37:18
| * mikolalysenko | joined |
| 23:49:07
| * tphummel | joined |
| 23:49:26
| * lyaunzbe | quit (Remote host closed the connection) |