--- Log opened Wed Feb 05 00:00:10 2014
01:20 < dominictarr> juliangruber, your co-stream looks a lot like a pull/min streams except with yeild
01:21 < dominictarr> aha, I see you linked it in the readme
01:24 < dominictarr> the real test of an alternative stream is to actually implement some non-trivial stream utils
01:24 < dominictarr> say: https://github.com/dominictarr/pull-cat
01:27 < substack> dominictarr: perhaps a stream-interop module could be of use for streams experimentation
01:28 < substack> takes a pull stream or co-stream or whatever and converts to/from a node stream
01:28 < substack> and it auto-detects the stream type
01:28 < substack> then people with competing streams implementations can pull request the streams-interop module to detect and convert their kind of stream to core streams
01:30 < dominictarr> substack, I have a pull-stream-to-stream and stream-to-pull-stream already
01:31 < dominictarr> I don't think autodetect will work, because many alt-streams are just a function
01:31 < substack> but you could add properties to those functions to denote their type
01:31 < substack> and you could hackishly check the fn.name
01:32 < substack> and establish that as a alt-stream detection convention
01:36 < dominictarr> you could do that
01:36 < dominictarr> maybe just have a .type='co-stream'
01:43 < dominictarr> substack, wow, this hand tool guy is amazing
01:45 < dominictarr> substack, I've been thinking about a slightly more organized mad science org., like a mad science grad school
01:50 < dominictarr> basically, it would be like a supervisor student thing, the supervisor doesn't tell the student what to do
01:50 < dominictarr> but they can give them advice and feedback, ask them hard questions, and introduce them to other people working on the related areas.
01:52 < substack> dominictarr: jjjohnny has been poking around a lot with that kind of a model
01:53 < dominictarr> I don't think this would be a way to make money, but it could be a good way to make modules
01:53 < dominictarr> it would encourage people to publish what they are doing, as well as communicate what their project is about
01:53 < dominictarr> everyone would get good practice at writing english too
01:54 < grncdr> substack: I've come up with a way to accomplish what I want with http-browserify, but it's a bit janky
01:54 < grncdr> basically delaying the xhr.open(…) call until the next tick
01:55 < grncdr> it doesn't break parity with the node core http, but it might break things for users that are accessing request.xhr directly
01:55 < grncdr> like me
01:57 < grncdr> PR'ing in a second, but I was thinking about emitting an event after xhr.open(…) so that users could interact with it reliably
02:25 < substack> dominictarr: that lcd from the camera I got in china fits a tiny computer that somebody dropped off at sudoroom
02:28 < dominictarr> this is clever: http://www.wired.com/dangerroom/2014/01/army-communications-balloon/
02:29 < dominictarr> substack, awesome! have you got it displaying?
02:29 < substack> not yet, I need a usb cable to power it up
02:30 < dominictarr> I brought one of the gps screens since, but vga is no good for text
02:30 < dominictarr> I've tried coding with it, but spent half the time trying to guess which letter I typed
02:38 < substack> what about with bitmapped fonts?
02:38 < substack> you used to be able to plug computers into televisions back in the earliest days
02:42 < dominictarr> probably readable if you went under 10x40
02:44 < gildean> i still have a couple of c=64's i can just plug in to my tv and start playing rock 'n wrestle
02:44 < dominictarr> but that is really taking it too far I think a better approach would be a android development board
02:44 < dominictarr> gildean, nice
03:01 < mikolalysenko> rvagg: in workshopper v2, will it be possible to write custom validators?
03:02 < rvagg> mikolalysenko: yes, totally, that's one of the core goals
03:02 < mikolalysenko> rvagg: awesome, I'm looking forward to it
03:03 < rvagg> mikolalysenko: the structure now is that workshopper itself just runs the menu bit and defers to "exercise" objects to execute and validate the exercise, just passing in what was given on the cmdline
03:03 < rvagg> mikolalysenko: then you plug together the exercise how you need to setup, execute, validate and cleanup a run/verify
03:03 < mikolalysenko> rvagg: ok.  so it will be possible for example to execute the exercise within a browser
03:03 < rvagg> mikolalysenko: in theory, you should talk to hughsk, he's wanting to do the same thing and has been privy to the dev of this next version of workshopper
03:04 < rvagg> mikolalysenko: check out the workshopper-* repos in my github, starting with workshopper-exercise
03:04 < mikolalysenko> ie spin up local server, open websocket and run code in page
03:04 < rvagg> mikolalysenko: you ought to be able to replace the core workshopper component with a workshopper-browser that does the same thing and the exercises themselves could be pretty much the same as in node
03:05 < rvagg> mikolalysenko: right, well there are async setup/process/cleanup stages, you just need to hook in to those as you need
03:05 < rvagg> then for 'process' you just give back a boolean for pass/fail, but along the way you can also emit 'pass' and 'fail' events to display ticks and crosses for various validation steps you might have
03:05 < rvagg> so if you have a browser running in the background and you're connecting to it for validation then that'll work too
03:06 < mikolalysenko> rvagg: ok
03:06 < rvagg> mikolalysenko: I'm just writing another component for something I need but the next step is documentation and converting learnyounode and levelmeup to serve as examples
03:07 < mikolalysenko> rvagg: great, can't wait for the next version
03:08 < rvagg> mikolalysenko: it's basically ended up like a test framework, so it's best to think of it in those terms, I don't think it'll be nearly as difficult to bend it to do all sorts of odd things
03:08 < rvagg> (as the current version)
03:18 < mikolalysenko> rvagg: yeah, that makes sense
04:28 < dominictarr> substack, does testling test all the branches?
04:28 < feross_> dominictarr: it will test whatever branch you push
04:28 < feross_> dominictarr: whichever you push last will be what the badge shows too
04:29 < substack> dominictarr: yep!
06:31 < juliangruber> substack: are you planning to write a blog post about all the attr- modules?
06:33 < juliangruber> substack dominictarr: i've been thinking about writing a processing module that creates processing chains out of many kinds of streams, (a)sync functions and more
06:34 < substack> juliangruber: yes once I get a few more pieces
06:35 < substack> once I fix the bug in scope or bind, it just needs a handlebars templating engine that works like angular with scoping but does automatic live updating and ranges from level like meteor
06:36 < substack> that will make a really compelling demo video
06:42 < juliangruber> oh yes
06:42 < juliangruber> substack: you should use that as a talk mind blowing device
06:46 < substack> juliangruber: well it's not much more than multilevel already gives you, just with the html part of it more taken care of
06:49 < juliangruber> substack: but some of it is steep enough to be worth a guided introduction, like the multilevel range mapping
06:58 < dominictarr> should I bother fixing ie 8 or should I just take that out of my testling config?
06:59 < substack> dominictarr: which module?
07:06 < dominictarr> substack, console.log({}, {}, {}) will do it
07:07 < dominictarr> if you have multiple args where the first is not a string then that test will have a false negative
07:11 < substack> dominictarr: which module?
07:11 < substack> oh or just in testling itself?
07:15 < dominictarr> substack, yeah, it's testling itself, I think I put in a PR to fix this a while ago, but the testling servers arn't running the latest version.
07:15 < substack> dominictarr: testling servers don't run the testling bin itself
07:15 < substack> but they have basically the same code
07:16 < dominictarr> they don't have the fix
07:16 < substack> yes
07:24 < dominictarr> hmm, through doesn't work with ie8 no body has every complained about that...
07:25 < dominictarr> but having the red flag makes me want to fix it...
07:27 < dominictarr> feross, idea: p2p music streaming via webtorrent, with adds, but 100% of the income goes to the artists
07:33 < owen1> juliangruber: attractor is mind-blowing. it's like having angular and meteor but using tiny modules. the problem is very few people can uderstand what's going on there and how to use it. i pasted i link to a demo of 'live-updating' but no one on #meteor cared..
07:34 < chapel> people use meteor because they don't have to think about what they are building
07:35 < chapel> or how to build it
07:35 < chapel> just slap some code together and hope the magic black box works
07:35 < owen1> i am sure that i'll get similar reaction on angular. i would like to start using it but scared of 0 adoption and not sure how to integrate it with other libraries.
07:37 < chapel> its just js
07:37 < owen1> i guess what we need is a complete demo project that is using attractor. similar to riot.js - https://moot.it/riotjs/docs/
07:40 < feross> dominictarr: neat idea. i support this idea
07:41 < feross> dominictarr: but first i need to get webtorrent into a better state
07:41 < dominictarr> yeah sure
07:54 < substack> owen1: or just make a slick video and a web page with decent docs
07:55 < substack> owen1: also even fewer people understand what's going on inside of angular and meteor
07:55 < substack> at least with tiny modules you can go and read the docs and completely understand the tiny module in isolation
08:04 < guybrush> dominictarr: very nice idea (webtorrent-music)
08:07 < guybrush> kinda like the original idea of batoto.net (but they struggle with "ad-network-functionality") -- http://www.batoto.net/forums/topic/1957-batoto-is/
08:08 < guybrush> (batoto.net is web-comic-reader where groups can publish their translations and stuff)
08:31 < dominictarr> juliangruber, can you do: metaTransform = pipe(transform1,transform2,transform2)
08:31 < dominictarr> can your streams distinguish between a source, a sink and a transform?
08:31 < juliangruber> that doesn't work
08:31 < juliangruber> transform streams take their source as an argument
08:32 < juliangruber> transform2(transform2(transform1(source)))
08:32 < juliangruber> transform2(transform2(transform1(source())))
08:32 < dominictarr> but a transform returns another function
08:32 < dominictarr> but a sink returns undefined
08:32 < juliangruber> a sink is just a function that while (true) yield read()
08:33 < substack> juliangruber: you should post an issue on https://github.com/whatwg/streams about generators and streams
08:33 < dominictarr> juliangruber, how is end marked?
08:33 < juliangruber> substack: they're already using promises :((((
08:33 < substack> :(
08:33 < dominictarr> does it return a sentinel value that means end?
08:33 < juliangruber> dominictarr: currently it's non object streams only, so just return a falsy value
08:33 < juliangruber> but
08:33 < juliangruber> i'm thinking about changing that to the `end` argument
08:34 < dominictarr> yeah, this is messy which is why I used a separate argument that means end in pull stream
08:34 < substack> Domenic_: you should take a look at https://github.com/juliangruber/co-stream if you haven't already!
08:34 < dominictarr> because I saw the weakness of checking sentinels in reducers
08:35 < juliangruber> dominictarr: https://gist.github.com/juliangruber/8819364
08:35 < juliangruber> dominictarr: if we had destructuring assignment that would be awesome
08:35 < dominictarr> best not to use singletons in js, especially with node_modules
08:35 < juliangruber> return [false, data] in the readable
08:35 < substack> juliangruber: is there any way to write a generator functions that can automatically fall back to using regular callbacks?
08:35 < juliangruber> and let { end, data } = yield read()
08:36 < substack> if your env doesn't have generator support
08:36 < dominictarr> right, undefined is end
08:36 < substack> or if you just want to use a callback for that part also
08:36 < dominictarr> sorry falsey
08:36 < juliangruber> substack: yes if you don't use the yield keyword internally you can call a function like this: var data = yield read(); and read()(function(err, data){})
08:37 < dominictarr> juliangruber, also checkout creationix's minstream it's basically the cb version of this, and he made it keeping fibers in mind
08:39 < juliangruber> dominictarr: i will thanks
08:39 < juliangruber> dominictarr: if javascript had `var a = false; var b = false; assert(a != b)` we could use a boolean for signaling end and abort
08:40 < juliangruber> and yield arbitraty js objects
08:40 < juliangruber> even yield false
08:40 < juliangruber> and the stream wouldn't end
08:40 < juliangruber> maybe we should use node stream's `null` as the end value and start supporting object streams
08:42 < dominictarr> juliangruber, if false != false?
08:43 < juliangruber> if we could compare references not values
08:43 < juliangruber> for booleans
08:43 < dominictarr> oh right
08:43 < dominictarr> references are weird
08:43 < juliangruber> with es6 we could use symbols
08:43 < juliangruber> that would work
08:43 < dominictarr> because that is singletons
08:43 < dominictarr> you could just about do: hash('END')
08:43 < dominictarr> and hash('ABORT')
08:44 < juliangruber> dominictarr: the singleton will be created by the sink so it should be in your control
08:44 < juliangruber> dominictarr: it would be killer if you wouldn't need any dependencies to make co-streams work
08:44 < juliangruber> like, wow, mindblown
08:44 < juliangruber> no stream library?
08:44 < dominictarr> this is complicated with node_modules though, you need to use globals.
08:44 < juliangruber> wow such core
08:45 < dominictarr> juliangruber, you don't with pull streams or min streams
08:45 < juliangruber> dominictarr: the sink creates the `end` singleton and passes it down the chain and others pass it up again
08:45 < juliangruber> dominictarr: oh
08:45 < dominictarr> if don't use the compose/pipe function
08:45 < juliangruber> dominictarr: do you have a source transform sink example that doesn't use any modules?
08:46 < juliangruber> ie no pull.*
08:46 < dominictarr> juliangruber, now if | was a compose operator, that would be one thing I'd add.
08:46 < dominictarr> yeah
08:47 < dominictarr> function values (ary) { var i = 0; return function (end, cb) { if (i < ary.length) { cb(true) } else { cb(null, ary[i++]) } } }
08:47 < juliangruber> yeah that'd be killer but it's not possible without global state, right? i remember hij1nx's pipe module relying on globals
08:48 < dominictarr> function sync (read) { read(null, function next (err, data) { console.log(data) if(!end) read(null, next) })}
08:48 < dominictarr> and map:
08:49 < substack> juliangruber: no, you can do it with state variables
08:49 < dominictarr> function map(func) { return function (read) { return function (end, cb) { read(end, function (end, data) { cb(end, !end && func(data))})}}}
08:49 < dominictarr> then:
08:49 < substack> juliangruber:
08:49 < substack> function F (x) {this.x = x}; F.prototype.valueOf = function () { console.log('X=', this.x) }
08:49 < substack> var a = new F(3), b = new F(5); a | b
08:50 < juliangruber> :O
08:50 < dominictarr> sink()(map(function (e) { return e*10})(values([1,2,3])))
08:50 < juliangruber> that would be nice
08:50 < juliangruber> but then stream creates would have to do that or use a module
08:50 < dominictarr> juliangruber, no deps!
08:51 < substack> juliangruber: oh actually to track the arguments inside of valueOf it looks like global state is necessary
08:51 < dominictarr> juliangruber, see also, observable is simple enough for a no dep pattern
08:51 < substack> anyways it's a cute api but probably too hacky to be a good idea
08:52 < juliangruber> dominictarr: sweet, reading
08:52 < juliangruber> substack: super cute
08:53 < dominictarr> don't be cute
08:53 < juliangruber> in case anyone else wants to have a look at the complete picture: https://gist.github.com/juliangruber/8819556
08:53 < substack> be boring
08:53 < juliangruber> dominictarr: :D :D :D
08:56 < dominictarr> be obvious
08:57 < juliangruber> dominictarr: your example written with co-streams: https://gist.github.com/juliangruber/8819607
08:57 < juliangruber> they're very similar
08:57 < juliangruber> but the strict `null` for signaling end is a pita
08:58 < juliangruber> very tempted to keep it binary/string streams for now
08:59 < dominictarr> juliangruber, minimal streams are great for object streams though
08:59 < juliangruber> yeah
08:59 < juliangruber> meh
09:00 < dominictarr> juliangruber, benchmarks!
09:00 < dominictarr> is simpler faster?
09:01 < juliangruber> dominictarr: good idea!
09:01 < dominictarr> * away
09:05 < niftylettuce_> urgent https://github.com/stripe/stripe-node/issues/87 /cc isaacs
09:05 < niftylettuce_> npm issue maybe?
09:09 < niftylettuce_> errr nvm
09:09 < niftylettuce_> hmm
09:11  * niftylettuce_ npm v1.3.24... im trying to upgrade to npm v.1.3.26 to see if htat resolves
14:16 < substack_> I killed my laptop :(
14:17 < substack_> my screwing a screw that was too long in too far
14:17 < trodrigues> ouch :(
14:17 < substack_> it ate into the motherboard
14:27 < gildean> substack_: well that sucks
16:19 < substack_> beep boop
16:25 < substack_> pow, already hooked up a replacement laptop
16:26 < substack_> heading out at 10am to get it
16:26 < substack_> it's down in san jose
16:26 < substack_> NO WAY SAN JOSE
16:26 < LOUDBOT> OUR ENEMY HIDES IN METAL BOXES
16:30 < jjjohnny> substack_: http://www.youtube.com/watch?v=jqWt49o7R-k #sanJose
16:31 < substack_> YAY AREA
16:31 < LOUDBOT> BACK SHORTLY. AND THEN I TOO WILL HAVE CANNED FRUITS
16:32 < jjjohnny> http://monoskop.org/log/?p=10535
17:28 < greweb> LOUDBOT
17:28 < greweb> -_-
18:09 < mikolalysenko> substack: is there a way to detect if a transform is being run in debug vs production mode?
18:09 < mikolalysenko> for example, in glslify it would be nice to automatically run minification on the glsl if you aren't in debug mode
18:10 < mikolalysenko> though if you are building a bundle for debugging, you don't want to do this since it obfuscates the code
18:16 < defunctzombie> substack_: trying to look at what makes browserify slower than just using detective on a file
18:17 < defunctzombie> substack_: the current perf with just using detective on jquery 1.11 on my machine is 0.194 seconds
18:17 < defunctzombie> while the same file with browserify is .9 seconds
18:36 < andreypopp> defunctzombie: I/O, checking package.json and son
18:36 < andreypopp> and so on
18:37 < andreypopp> my guess
18:37 < defunctzombie> lots of stuff going on
18:37 < defunctzombie> on my computer just loading all the modules to run browserify takes ~200 ms
18:37 < defunctzombie> so that is 200ms of startup time
18:37 < defunctzombie> which is crazy!
18:42 < defunctzombie> ok.. browserify is out of control 200ms for startup time..
18:43 < andreypopp> defunctzombie: we can reduce I/O, by browserifying browserify
18:43 < defunctzombie> rofl
18:43 < andreypopp> with --no-builtins to run inside node
18:43 < defunctzombie> oh man...
18:43 < andreypopp> trying that now, but latest version can't browserify uglify due to bug
18:43 < defunctzombie> haha
18:43 < defunctzombie> awesome!
18:43 < defunctzombie> let me know how that is
18:44 < defunctzombie> I think that would be hilarious
18:44 < defunctzombie> why is uglify even used?!
18:44 < defunctzombie> what the hell
18:59 < andreypopp> heh, it's not that easy
19:00 < andreypopp> but certainly should be possible
19:04 < defunctzombie> andreypopp: well, one perf issue in detective has been identified
19:04 < andreypopp> which one?
19:09 < defunctzombie> andreypopp: https://github.com/substack/node-detective/blob/master/index.js#L6
19:09 < andreypopp> re: "why is uglify is even used?" — umd depends on it for some reason
19:10 < defunctzombie> andreypopp: these closures get made recursively
19:10 < defunctzombie> andreypopp: so if you use regular looping and not functions it is faster
19:10 < defunctzombie> ~160ms gain on a macbook air
19:10 < defunctzombie> running on three.js
19:14 < andreypopp> heh, browserified browserify just 80ms faster
19:14 < andreypopp> on startup
19:17 < defunctzombie> andreypopp: ahaha
19:17 < defunctzombie> andreypopp: we found a better speed perf
19:17 < defunctzombie> https://github.com/creationix/js-linker/blob/master/mine.js
19:18 < andreypopp> miniparser, cool
19:18 < andreypopp> this one should be fast
19:19 < defunctzombie> it is very very fast
19:19 < airportyh> defunctzombie: https://gist.github.com/airportyh/8831028
19:20 < andreypopp> defunctzombie: PR to browserify!
19:23 < defunctzombie> all the detect globals shit browserify does is causing major slowdown
19:24 < defunctzombie> I just want something that isn't trying to be so clever
19:32 < defunctzombie> substack: do we care about supporting the old detective stuff with require expressions?
19:32 < defunctzombie> substack: the stuff that wants to use escodegen
19:33 < defunctzombie> if not, then I think we should use that faster parsing stuff
19:46 < defunctzombie> thlorenz: ping
19:46 < defunctzombie> thlorenz: experimenting with (https://github.com/creationix/js-linker/blob/master/mine.js) instead of detective
19:47 < defunctzombie> thlorenz: I see you added some stuff to detective recently for esprima options and returning nodes
19:47 < defunctzombie> do you need any of that stuff?
19:49 < defunctzombie> creationix: ping
19:52 < thlorenz> defunctzombie: I needed all the info to replace requires
19:53 < defunctzombie> thlorenz: hm... well, detective is ass slow
19:53 < defunctzombie> cause esprima is slow
19:53 < defunctzombie> using mine.js stuff is much much faster
19:53  * thlorenz was just gonna say that
19:54 < defunctzombie> what is the point of replacing requires?
19:54 < defunctzombie> I mean, it is cool I guess but I would rather have the speed
19:54 < thlorenz> defunctzombie: this is what I needed the extra info for: https://github.com/thlorenz/exposify/blob/master/expose.js#L55
19:54 < thlorenz> that's the point ;)
19:55 < thlorenz> to be able to say require'jquery' and it becomes window.jquery
19:55 < defunctzombie> thlorenz: sigh
19:55 < thlorenz> so your code stays agnostic to the fact that you are getting jq via a script tag
19:55 < thlorenz> defunctzombie: it's not THAT bad ;)
19:56 < defunctzombie> thlorenz: couldn't you just do that with a transform?
19:56 < defunctzombie> thlorenz: and in the transform check against a map and return relevant new source?
19:56 < jesusabdullah> Or just learn to stop worrying and love the script tag ;D
19:56 < defunctzombie> thlorenz: I agree it isn't that bad.. just needed to know if ripping out detective from module-deps would break anything
19:56 < defunctzombie> and it doesn't seem like it will
19:56 < defunctzombie> cause this use is separate
19:56 < thlorenz> defunctzombie: exposify IS a transform
19:57 < thlorenz> jesusabdullah: and loose advantage of using browser cache (CDN)
19:57 < thlorenz> and wait for your bundle to load in dev cuz you are bundling ember
19:57 < defunctzombie> thlorenz: so why do this detective thing?
19:57 < thlorenz> cuz it finds requires and then I replace them
19:58 < thlorenz> agree that esprima is slow though
19:58 < thlorenz> talked to chrisdickinson lately about this
19:58 < chrisdickinson> yessss.
19:58 < thlorenz> defunctzombie: I believe it'd be nice if a transform would also be able to work on ASTs
19:59 < thlorenz> so browserify would provide that once (one parse) instead of each transform parsing code over and over
19:59 < defunctzombie> thlorenz: oh I see... why not just make a file/module called jquery that just module.exports = window.jQuery ?
20:00 < thlorenz> defunctzombie: cuz I don't want to do that everywhere
20:00 < thlorenz> this works for ALL modules
20:00 < defunctzombie> thlorenz: AST stuff is made for globals detection too I think
20:00 < defunctzombie> very annoying as well
20:00 < thlorenz> defunctzombie: same discussion we had about b-shim about a year ago
20:00 < defunctzombie> anyhow.. ripping it out of module-deps
20:00 < defunctzombie> helps a lot
20:00 < thlorenz> and what do you know lots of ppl use it now ;)
20:01 < defunctzombie> yea... lots of people do stupid things ;)
20:01 < defunctzombie> I like it tho
20:01 < thlorenz> defunctzombie: whatevs, so the new stupid thing you can do with it now is do "jquery": "global:$" https://github.com/thlorenz/browserify-shim#packagejson
20:01 < defunctzombie> haha
20:02 < thlorenz> and then just put jquery in your script tag and be able to require it
20:02 < defunctzombie> cool
20:02 < defunctzombie> if you are into jquery I guess rofl
20:02 < defunctzombie> the three thing is nice
20:02 < defunctzombie> case three.js is massive
20:03 < thlorenz> yep and I want that from a CDN so the user only loads that once
20:03 < defunctzombie> so how is the new thing different than browserify cdn?
20:03 < thlorenz> but my code doesn't have to know that ;)
20:03 < defunctzombie> er
20:03 < defunctzombie> browserify-shim
20:03 < defunctzombie> exposify vs browserify-shim that is
20:03 < thlorenz> no vs exposify is used by browserify-shim
20:04 < thlorenz> I just did it as small as possible modules all the way ;)
20:04 < thlorenz> so if you only need exposify you don't have to use b-shim
20:05 < thlorenz> defunctzombie: chrisdickinson: I suppose this'd be related? https://github.com/substack/node-browserify/issues/633
20:06 < defunctzombie> thlorenz: ah
20:06 < thlorenz> defunctzombie: chrisdickinson I think we should do a kickstarter to write a drop in replacement for esprima in C with node bindings
20:07 < chrisdickinson> thlorenz: i'm pretty sure you could get some nice perf improvements by writing it in such a way that ... any of the functions it calls a billion times in a row are inlineable
20:07 < defunctzombie> thlorenz: chrisdickinson: andreypopp: never quite understood what would conflict if left the same as 'require' name... since inside the bundle it is the require from browserify no?
20:07 < defunctzombie> thlorenz: why?
20:07 < defunctzombie> thlorenz: mine.js is so much faster already
20:07 < defunctzombie> and not in c
20:07 < thlorenz> defunctzombie: speed
20:08 < defunctzombie> you don't need the AST shit
20:08 < thlorenz> have you seen achorn?
20:08 < defunctzombie> yea
20:08 < thlorenz> defunctzombie: for most stuff an AST is useful
20:08 < thlorenz> and tokens
20:08 < chrisdickinson> C isn't (necessarily) cheetah blood
20:08 < thlorenz> maybe not to find requires, but lots of other stuff I do needs an AST
20:08 < defunctzombie> meh.. I think for browserify core functionality tho it may not be needed
20:08 < defunctzombie> actually I want to get away from "emulate node in browser" shit
20:08 < thlorenz> defunctzombie: ok so browserify specific maybe
20:08 < defunctzombie> and just make something that doesn't suck at packaging js
20:09 < defunctzombie> thlorenz: yea.. I can see where transforms or other stuff might like an AST
20:09 < thlorenz> yeah, that'll break anyways once ppl write modules using ES6 for the server side
20:09 < defunctzombie> jesus
20:09 < defunctzombie> I am really gonna hate shit then hahaha
20:09 < thlorenz> so agreed - module authors should advertise if it runs in the browser and add a badge
20:09 < chrisdickinson> being forced to "use strict" will likely drive me insane
20:09 < thlorenz> but browserify should not do too much magic about it
20:10 < chrisdickinson> since i actually *like* function hoisting :\
20:10 < thlorenz> chrisdickinson: your code looks more and more like python to me every day :P
20:10 < chrisdickinson> haha
20:10 < thlorenz> really clean tho
20:10 < chrisdickinson> thanks :)
20:11 < chrisdickinson> it's also going to be unpossible to write it that way once ES6 hits (since, if i'm not mistaken, using es6 modules drops you into strict mode by default)
20:12 < thlorenz> defunctzombie: chrisdickinson to write faster parser this will be interesting: https://twitter.com/thlorenz/status/426405069526142976
20:13 < defunctzombie> thlorenz: the globals logic in browserify is also really slow and annoying
20:13 < defunctzombie> thlorenz: taking that out and replacing detective with mine.js
20:13 < defunctzombie> lets me bundle three.js
20:13 < chrisdickinson> oo, nice link
20:13 < defunctzombie> in ~130 ms on my mac
20:14 < defunctzombie> versus ~1.1s otherwise
20:14 < pfraze> defunctzombie: are you anti-browserify, or what do you mean by node in the browser?
20:14 < defunctzombie> 10x improvement
20:14 < defunctzombie> pfraze: I love browserify :)
20:14 < thlorenz> defunctzombie: you should do a PR - lately they switched to ES6 branch of esprima though
20:14 < defunctzombie> pfraze: I like browserify as a packager more than something that peddles to the idiosyncrasies created by some globals in node.
20:14 < chrisdickinson> i've found that i don't really use most of the node shims in browserify
20:15 < thlorenz> so you'd have to be able to handle that too
20:15 < chrisdickinson> the packager aspect of it is way enticing
20:15 < defunctzombie> thlorenz: yea.. airportyh is working on a PR for module-deps
20:15 < pfraze> defunctzombie: I gotcha, yeah
20:15 < thlorenz> defunctzombie: awesome!
20:15 < defunctzombie> thlorenz: I mentioned support for ES6 stuff
20:15 < defunctzombie> will port over the detective tests
20:15 < defunctzombie> since those are good (mostly0
20:16 < thlorenz> although I never had any problems with bundle speed lately (using chrisdickinson beefy or my own appup - which both cache akaik)
20:16 < thlorenz> but then I'm not bundling ember either ^ johnkpaul jesusabdullah ;)
20:18 < defunctzombie> haha
20:18 < defunctzombie> ember.. rofl
20:18 < chrisdickinson> we bundle at work and it takes a bit, but we run a lot of AST transforms
20:18 < mikolalysenko> maybe for getting module deps you could do something like boyer moore and just get all the occurences of require()
20:18 < prettyrobots> So...
20:18 < defunctzombie> mikolalysenko: creationix already has a good js file that does it really fast
20:19 < prettyrobots> In `package.json` the `url` property is the `url` of the package hosting?
20:19 < prettyrobots> It is a redirect?
20:19 < prettyrobots> If so, then I'm doing it wrong.
20:19 < chrisdickinson> it would be neat for someone to take https://github.com/mikolalysenko/strongly-connected-components and make a global transform that splits the bundle into groups
20:19 < defunctzombie> prettyrobots: typically a url to the "homepage"
20:19 < prettyrobots> Is it a synonym to the "homepage"?
20:20 < prettyrobots> https://npmjs.org/doc/json.html#homepage
20:20 < terinjokes> chrisdickinson: an automated factor-bundle?
20:20 < terinjokes> of sorts
20:20  * chrisdickinson nods
20:20 < mikolalysenko> might be useful.  you can also use the condensation that it spits out to do smarter updates
20:21 < mikolalysenko> like you update something in component x, then all components that depend on x get rebuilt lazily
20:21 < chrisdickinson> it would really put paid to the "require.js lets you optimize your javascript experience by lazy loading and browserify doesn't" argument, i think
20:21 < chrisdickinson> in that "browserify automatically splits your bundle into smaller bundles that are more likely to be cache hits"
20:22 < defunctzombie> anyone who makes the lazy loading argument doesn't know what they are talking about
20:22 < terinjokes> chrisdickinson: something would need to be able to handle those
20:23 < defunctzombie> you can probably ignore them
20:23 < terinjokes> fetching those*
20:23 < defunctzombie> and anything they say on any topic
20:23 < mikolalysenko> so the real question is how to make an incremental browserify
20:23 < terinjokes> chrisdickinson: by splitting ourselves with factor-bundle at least we know where to put the fetch logic
20:26 < terinjokes> chrisdickinson: but i would be interested nontheless
20:26 < mikolalysenko> I think it might not actually be too bad though, but you need to store a bit of state
20:27 < mikolalysenko> basically you'd have a directed graph of modules + dependencies + timestamps for last time the file got modified
20:27 < mikolalysenko> then when you check for an update, you stat all the files to find which ones changed
20:27 < mikolalysenko> once that's done, compute the condenstation of the graph then rebundle all the files which change, and update the dependency graph
20:28 < mikolalysenko> so I guess there would be a table that stores the module/timestamp/last built bundle data
20:28 < mikolalysenko> and the dependency graph would be stored on top of it
20:28 < thlorenz> defunctzombie: btw here is my hacky but superfast require replacer: https://github.com/thlorenz/brace/blob/master/build/fix-requires.js
20:29 < thlorenz> works for the entire ace module (which is huge too)
20:29 < defunctzombie> hahaha
20:29 < defunctzombie> amazing
20:29 < defunctzombie> will totally destroy codebases
20:29 < thlorenz> :)
20:29 < defunctzombie> any error message with "require" in it rofl
20:29 < thlorenz> it's just used to refactor ace (which has it's own require)
20:30 < thlorenz> wouldn't recommend it for anywhere else
20:30 < thlorenz> defunctzombie: well it'd just make it acequire in the error message -- no harm done :P
20:30 < mikolalysenko> thlorenz: you could probably detect requires not in strings with a regexp
20:30 < mikolalysenko> but maybe it is slow
20:31 < thlorenz> mikolalysenko: faster than generating an AST anytime
20:31 < mikolalysenko> haha, maybe
20:31 < defunctzombie> thlorenz: rofl.. ripple emulator had its own require called "ripple"
20:31 < mikolalysenko> just check the number quotes before it is even
20:32 < mikolalysenko> of course it doesn't quite work because of single quotes...
20:32 < thlorenz> mikolalysenko: yeah that could totally be done, defunctzombie isn't that kind of what jslinker/mine.js is doing?
20:32 < defunctzombie> thlorenz: somewhat
20:32 < andreypopp> + comments
20:33 < thlorenz> OMG how I hate that // and // (one comment, other regex) exist in JS - makes it unlexable
20:43 < kriskowal> thlorenz: word. besides, it should have been the inverse of ** (Math.pow)
20:44 < kriskowal> alas that only flies in languages that observe # comments
20:45 < thlorenz> kriskowal: :), oh well I wish we coud force a subset of JS on everyone that only allows regexes in parens, then we could lex that again
20:45 < pfraze> anybody have insight on this shadow dom standards ordeal?
20:46 < thlorenz> well actually no (//)hello comment or regex?
20:46 < thlorenz> so regexes should have used different char alltogether
20:49 < mikolalysenko> you could alos replace comments with string literals
20:49 < mikolalysenko> *also
20:50 < mikolalysenko> thus removing an extra case from the lexer
20:56 < kriskowal> mikolalysenko: thlorenz: Python uses string literal prefixes. quasiliterals coming in ES-something would mitigate the problem, if regexes were dropped :P
20:57 < kriskowal> similar implications for value types
21:00 < defunctzombie> isaacs: you forgot the most important point
21:00 < defunctzombie> isaacs: is it faster?
21:04 < andreypopp> defunctzombie: reading the log, I agree with you that the best thing is to avoid using things in client code which trigger emulation of Nodeisms. Maybe browserify should have --no-insert-globals by default and only check with regexp against bundle if there's process/__dirname/__filename usage and warn user that they might need to use --insert-globals flag
21:05 < defunctzombie> andreypopp: that could be interesting
22:03 < isaacs> defunctzombie_zz: haha
22:03 < isaacs> defunctzombie_zz: yeah, but not because of us.  mostly because Fastly
22:12 < substack_> defunctzombie_zz: browserify should absolutely use a faster ast parser if possible, so long as the tests all still pass
22:13 < terinjokes> andreypopp: otoh, it's somewhat easy to pull in lots of nodeism
22:14 < terinjokes> bring in anything that touches streams, and you'll get buffers, event emitters, all of util
22:14 < terinjokes> er, is a stream*
22:14 < substack_> mikolalysenko: the only good way right now for transforms to take parameters is with env vars
22:15 < substack_> andreypopp: the problem with that is "other people"
22:15 < substack_> andreypopp: you've got to convince all module authors to not use nodeisms, but many of them aren't even aware that their modules can run in the browser at all
22:16 < substack_> convincing people is really hard. i would rather everything just worked, even if it's slower or bulkier until it gets fixed upstream
22:30  * substack back on regular ssh
22:32 < DTrejo> hey substack is your computer OK? / bought another already?
22:47 < defunctzombie> substack_: module-deps tests will pass
22:48 < defunctzombie> substack: https://github.com/creationix/mine/pull/1
22:48 < defunctzombie> substack: using that module instead of detective in module-deps
22:55 < substack> DTrejo: yes I just got the new one swapped in
22:59 < DTrejo> nice :)
23:03 < ogd> hahahah https://www.youtube.com/watch?v=waEeJJVZ5P8
23:08 < rowbit> substack, pkrumins: Encoders down: 50.57.72.32 (free10)
23:09 < defunctzombie> ogd: rofl
23:10 < defunctzombie> ogd: HACKERS!!!
23:10 < defunctzombie> ogd: that guy opening the macbook WTF
23:10 < defunctzombie> ogd: HAS HE NEVER OPENED A MACBOOK BEFORE?
23:11 < kanzure> there should be a way to do streaming multi-sig transactions
23:11 < kanzure> or at least building up a multi-sig transaction
23:24 < andreypopp> ogd: that's scary sh*t... I've been to this cafe... probably I got HACKED too
23:28 < ogd> lol
23:31 < marcello3d> defunctzombie: hah! the ripping of the box
23:31 < defunctzombie> marcello3d: yea.. wtf
23:31 < defunctzombie> marcello3d: who does that
23:31 < marcello3d> people who are too busy staring at the camera
23:43 < substack> isaacs: npm ERR! Error: forbidden name invalid: undefined: optimist
23:44 < substack> when I try to do a publish or an `npm deprecate`
23:46 < substack> ok now officially deprecated https://github.com/substack/node-optimist#deprecation-notice
23:48 < substack> isaacs: probably because it's a really old module
23:51 < terinjokes> substack: and now for me to move my projects to yargs :)
23:52 < substack> please do
23:56 < jjjohnny> lol gold doubooleans
23:56 < rowbit> Hourly usage stats: [developer: 0, free: 30]
--- Log closed Thu Feb 06 00:00:17 2014