--- Log opened Sun Apr 28 00:00:59 2013
00:37 < chrisdickinson> hearing such great things about using browserify in #js-git
00:37 < chrisdickinson> creationix is still a lil' iffy on it
00:38 < chrisdickinson> but others are pretty happy with it
00:40 < mbalho> git with the times, creationix!
00:40 < mbalho> git checkout modernity
00:44 < chrisdickinson> hah
00:45 < chrisdickinson> mbalho: the hardest things to get over are that he doesn't want to use node's streams and that he dislikes the buffer abstraction
00:45 < chrisdickinson> (to be fair, there's been kind of a diaspora re: streams since 0.10; and browserify's buffers are … a weird place to be)
00:51 < mbalho> yea i actually -1 buffer as well
00:51 < mbalho> but more work on it would be awesome
00:51 < mbalho> maybe he can write a buffer that works in both envs
00:51 < mbalho> (if that is possible)
01:08 < dominictarr> the seal has been broken
01:09 < dominictarr> if you have 2 types of streams you might as well have MANY
01:27 < substack> everything used to be so simple :/
02:40 < thl0> do we have something like a CDN for browserify modules anywhere substack?
02:40 < thl0> it would host precompiled browserify modules
02:41 < thl0> so people whose apps are not using browserify can still use them, just an idea
02:43 < mbalho> ive wanted that for a while too
02:44 < thl0> I just see this divide between the component people, then the ones who still use vendor modules, the bower people and the browserify ones
02:45 < thl0> leading to stuff like this: https://github.com/twolfson/computedStyle/tree/master/dist
02:46 < mbalho> :O
02:46 < thl0> so if each module system also provided a generic form of each package, people could use modules from all faiths
02:47 < thl0> and combine them in their apps, although of course using npm for module management oughta be preferred
02:57 < substack> thl0: I think the "npm ought to be preferred" is where most of the disagreements come from
02:58 < thl0> substack: I guess it's more obvious for people who already use it to manager their server side modules with it
02:58 < thl0> what I'm seeing is just that lots of effort will be duplicated across different module systems
02:58 < thl0> cause they can't work together easily
03:04 < substack> that's intrinsic to having separate module systems
03:04 < substack> if 2 module systems are trivially interoperable then they are 1 module system
03:17 < thl0> substack: well you could have a service that hosts browserified bundles so I could consume them without browserify
03:18 < thl0> a simple but bad way would be to add a suffix at the bottom that requires all of them and attaches to the window (not suggesting that as a solution)
03:19 < thl0> it would be cool though to provide a solution I could just source via a script tag (i.e. if you want to use it in your github page)
03:21 < thl0> substack: on the other hand we could also hope that everyone eventually finds their way to browserify ;)
06:54 < jesusabdullah> thl0: I wrote something kind of like this some time ago, it's on my github, ctrl-f browserify
06:55 < jesusabdullah> thl0: I did a rewrite in flatiron so it's not my best work but there is a nodejitsu blog post about it, conceptually fairly straightforward
06:56 < jesusabdullah> thl0: used to be hosted on nodejitsu when I had free drones...
07:07 < jesusabdullah> thl0: http://blog.jit.su/getting-started-with-flatiron blog post about browserify-cdn, https://github.com/jesusabdullah/browserify-cdn code, probably more or less works ootb and simple enough to refactor
08:50 < juliangruber> Raynos: looks like in browserify v2 the (require)('./bla') hack doesn't work anymore
08:50 < juliangruber> it broke engine.io-client
08:50 < substack> correct
08:50 < substack> use the browser field now
08:50 < substack> or var require_ = require; require_()
08:51 < juliangruber> :D
08:51 < juliangruber> ok, thanks
08:51 < substack> browser field is better
08:55 < juliangruber> substack: you were talking about a ignore-field or something for browserify yesterday, right?
08:55 < juliangruber> engine.io has those try { emitter = require('emitter') } catch(e){ Emitter = require('emitter-componet') } things all over the place
08:57 < substack> those are lame
08:58 < juliangruber> do you mean those try/catches or the learnboost guys? :P
09:55 < substack> pirates getting some seats in iceland
09:55 < substack> and so it begins!
10:20 < substack> juliangruber: was it you who wrote an inherit() that works in non-es5 browsers?
10:29 < substack> I'll just require('inherits/inherits-old')
11:52 < juliangruber> substack: I only use util.inherits
12:13 < juliangruber> substack: doesn't the browserify version of util.inherits work in older browsers?
12:13 < substack> probably
12:57 < juliangruber> i know it works in ie8
13:41 < juliangruber> how can I check if a net connection is still up?
13:42 < juliangruber> net.readable == net.writable == true?
13:47 < juliangruber> /net/connection/
14:13 < defunctzombie> juliangruber: I have an engine.io client version that works
14:13 < defunctzombie> juliangruber: with browserify
14:13 < juliangruber> defunctzombie: raynos's will work too with my 2 pull requests merged
14:22 < defunctzombie> juliangruber: is that more up to date?
14:23 < juliangruber> defunctzombie: dunno. can you give me a link of your version?
14:24 < defunctzombie> juliangruber: https://github.com/shtylman/engine.io-client/tree/v0.4.3-dz1
14:24 < defunctzombie> juliangruber: I think that is the latest I have
14:24 < juliangruber> yours is more recent
14:24 < juliangruber> raynos has 0.4.0
14:24 < defunctzombie> juliangruber: you patches are incorrect I think
14:24 < defunctzombie> with the browser field
14:25 < juliangruber> engine.io-stream whould use yours then
14:25 < juliangruber> why?
14:25 < defunctzombie> juliangruber: oh, yea, I also have a more recent engine.io-stream
14:25 < defunctzombie> haha
14:25 < defunctzombie> https://github.com/Raynos/engine.io-stream/tree/wip-refactor
14:26 < juliangruber> oh sweet
14:26 < juliangruber> has the api changed?
14:26 < juliangruber> yes it has
14:26 < defunctzombie> don't think so
14:26 < defunctzombie> the api stayed the same
14:26 < defunctzombie> some internal things changed
14:26 < juliangruber> the requires are different
14:26 < juliangruber> you don't need the require('engine-stream/server') in your version
14:27 < defunctzombie> yea
14:27 < defunctzombie> you can if you want
14:27 < defunctzombie> but you don't need it with browserify
14:27 < defunctzombie> cause I use the browser field for that
14:29 < juliangruber> yes
14:29 < juliangruber> hm, my thing is broken with the newer version
14:29 < juliangruber> http://localhost:4000/engine/?EIO=undefined&transport=polling
14:29 < juliangruber> that url looks broken
14:30 < juliangruber> it's not transmitting any data
14:31 < defunctzombie> that url is quite broken
14:31 < defunctzombie> undefined haha
14:32 < defunctzombie> I should also update the client to 0.5.0
14:34 < defunctzombie> Raynos: should I merge those engine.io-stream things?
15:02 < thl0> juliangruber: that browserify as a service thing looks promising
15:02 < thl0> unfortunately http://browserify.nodejitsu.com/ is dead
15:03 < thl0> sorry meant jesusabdullah
15:06 < thl0> substack: is browser field the same as browserify field in package.json?
15:06 < thl0> a bit confused since shoe has   "browserify": "browser.js"
15:06 < dominictarr> js build farm!
15:31 < defunctzombie> thl0: https://gist.github.com/shtylman/4339901
15:53 < thl0> defunctzombie_zz: ah, so browserify field is obsolete?
15:55 < mcollina> hi everyone :)
15:57 < ralphtheninja> mcollina: Heya! Welcome :)
15:57 < dominictarr> mcollina: hey, whats up?
15:59 < mcollina> Coding as usual, while I have to write some stuff.
16:00 < mcollina> ralphtheninja: thanks for the tip on this channel.
16:01 < ralphtheninja> mcollina: yw! it's nice to have a common place, all sorts of weird stuff happening in here
16:01 < ralphtheninja> I'm mostly babbling :D
16:03 < dominictarr> mcollina: _lots_ of mad science happens in here
16:05 < mcollina> I love mad science. Impossible things being done because the inventors didn't know they were impossible :D.
16:05 < dominictarr> exactly!
16:09 < dominictarr> mcollina: so, this graph database is something I've wanted to do with levelup for a while!
16:10 < dominictarr> I'm very glad that you have started the project!
16:13 < dominictarr> hey, there is something different about nextTick in 0.10, right?
16:13 < mcollina> It has been kind of an accident. Having a couple of free hours, the Hexastore paper printed on the desk, and a tweet about levelup. LevelDB is really crazy, and LevelUp is super-simple to use.
16:15 < mcollina> Yes, it's executed always before any I/O.
16:15 < mcollina> in v0.8 this was not guaranted.
16:20 < dominictarr> hmm, yeah, I'm getting a race condition in level-trigger ...
16:20 < dominictarr> mcollina: yeah - I am particularily interested in graph traversals
16:20 < dominictarr> shortest path is pretty simple
16:20 < dominictarr> A*
16:20 < dominictarr> etc
16:21 < dominictarr> but I would love to see how fast they are in leveldb
16:21 < ralphtheninja> mcollina: a happy accident!
16:21 < mcollina> dominictarr: I guessed right in asking for your opinion then.
16:21 < dominictarr> yes!
16:22 < dominictarr> should be better than shoe horning that into a non imbedded db, because you don't have to go to the network.
16:22 < mcollina> dominictarr: we need good implementations for graph traversal in node.js. Generic, reusable stuff.
16:22 < dominictarr> so, I implemented the thing that resolves node modules
16:23 < mcollina> Cool!
16:23 < dominictarr> https://github.com/dominictarr/npmd/blob/master/resolve.js
16:23 < dominictarr> that takes 50ms once the cache is warm
16:23 < dominictarr> for browserify
16:23 < dominictarr> which is a large module
16:23 < mcollina> ralphtheninja: yes! It's now my more popular thing on Github. Like 43 stars in three days.
16:24 < ralphtheninja> more and more people showing up from all around, I like the node approach to levelup, with a simple core and then build clean abstractions on top of it
16:25 < dominictarr> browserify has 72 recursive deps
16:25 < dominictarr> so, to resolve that, it has to hit the db many times
16:25 < dominictarr> and, for many, it has to wait for the round trip
16:26 < ralphtheninja> dominictarr: how much improvement is 50ms to the time it takes now? must be enormous
16:26 < dominictarr> well, that isn't installing the modules
16:26 < dominictarr> npm resolves as it installs
16:26 < dominictarr> so you can't compare it really.
16:27 < mcollina> dominictarr: you are pre downloading the full npm index, right? How big it is?
16:28 < dominictarr> mcollina: 480mb
16:28 < dominictarr> currently
16:28 < dominictarr> it was only 360 a month ago
16:28 < dominictarr> once it's downloaded, it just pulls in the changes, though.
16:29 < mcollina> So it's 50ms in that setup, right?
16:29 < dominictarr> when the cache is warm.
16:29 < dominictarr> yes
16:31 < ralphtheninja> dominictarr: the cache is warm .. meaning the files have been hit at least once by the os?
16:31 < dominictarr> something like that - I think leveldb has it's own cache, but there is a os cache too
16:32 < dominictarr> mcollina: I read the google pregel paper a while back.
16:32 < dominictarr> very interesting stuff there
16:32 < ralphtheninja> dominictarr: correct, there is a read cache for frequently accessed keys
16:35 < mcollina> dominictarr: Then I will read the Pregel paper :).
16:39 < mcollina> dominictarr: the things is that hacking on the graph algorithms and on npm stuff at the same time might not be really clear. In the land of ms, an algorithm problem can slow things down. A good implementation of the depth-first, bread-first, A*, ecc algorithms might be very helpful. Moreover, everything should be done asynchronously :).
16:40 < dominictarr> yes - I have a generic depthWidth, and leafFirst
16:40 < dominictarr> and widthFirst
16:41 < dominictarr> you just pass in a function that returns a stream of the child nodes
16:41 < dominictarr> I have used them to traverse files and directories also!
16:41 < mcollina> repo? :)
16:42 < dominictarr> https://github.com/dominictarr/pull-stream/blob/master/sources.js#L73-L137
16:42 < dominictarr> should probably pull them into their own repo.
16:43 < dominictarr> A* should be pretty simple to build on top of that, but I need a use for it.
16:48 < mcollina> Or you might write a better README for the pull-stream package. Looking at the source is pretty cool, but you don't get the full thing. These graph algorithm traversal are so compact because of it.
16:51 < dominictarr> mcollina: tell me what you find confusing/unclear
16:51 < dominictarr> I need help to see it as a beginner, since I wrote it.
16:52 < mcollina> Implementing A* can be done by adding a "score" function, and sorting the nodes to open using it. A valid heuristic function might be the package "semver" or the package age, or just the number of package dependencies. However in the npm case, you have to open all the nodes (I believe).
16:58 < mcollina> The real question I have when I open a README is "what I use this for". The pull-stream library answer with "simplify the usage of stream". However you can do graph-traversal and the like with a few lines of code. In the readme there is no "wow" effect. You should add a quick-example solving a real-world proble like async does.
17:11 < dominictarr> mcollina: thanks.
17:13 < mcollina> If I knew about pull-stream a couple of month before I would have saved lots of time :P. I implemented https://github.com/mcollina/kanban without using streams, that was a very bad idea.
17:13 < mcollina> :)
17:15 < dominictarr> pull-stream didn't exist 2 months ago!
17:18 < dominictarr> mcollina: maybe I should implement A* with pull streams just so I have a good example...
17:20 < mcollina> yeah! :) Add these graph-stuff in the pull-stream readme too! (or put them in a separate package).
17:23 < dominictarr> pull-stream is largly about lazy async iteration
17:24 < dominictarr> and being able to do complex things that would be difficult with normal node streams.
17:27 < mcollina> The other thing that's misleading is that it seems it is based on node's Stream, when it's not. I know how hard can be these things.
17:31 < mcollina> I had hit a fairly typical performance-wall while spawning multiple process to do CPU-bound stuff. Then, I have written my own pull-based library. Pull-stream does exactly what I was looking for.
17:36 < dominictarr> cool!
17:37 < fotoverite> dominictarr: you got a food truck rec for downtown portland?
17:37 < fotoverite> Too bad there is no cheese wizards here
17:37 < dominictarr> they are all good.
17:37 < fotoverite> :D
17:38 < fotoverite> How goes the streams
17:38 < dominictarr> I got a strange bug in something
18:08 < jjjjohnnny> in the browser, better to have one giant float32array or many small ones, your guess or mine
18:10 < jjjjohnnny> as expected, concaculatin' the many small ones is not eventually enough
18:11 < jjjjohnnny> oh smash
18:49 < juliangruber> did anyone get smartos running on a macbook?
18:49 < juliangruber> doesn't even boot on mine
18:50 < juliangruber> chromeos didn't work either -.-
19:16 < no9> juliangruber side install or VM?
19:17 < juliangruber> no9: main install, as it's my side computer
19:17 < no9> K did you try open indiana?
19:18 < no9> Has a live cd to you can see what the story is
19:18 < no9> http://openindiana.org/
19:47 < juliangruber> no9: not yet, thanks, I will!
20:00 < jjjjohnnny> a module that treats many (an array) of buffers as a single buffer #abracadabra
20:03 < jjjjohnnny> of course https://github.com/substack/node-buffers
20:05 < substack> beep boop
20:06 < jjjjohnnny> substack: will that work with float32arrays
20:06 < mbalho> jjjjohnnny: arent arraybuffers what you want
20:06 < jjjjohnnny> mbalho: working with floats :\
20:07 < jjjjohnnny> which is a view on an arraybuffer
20:13 < jjjjohnnny> i'll just pull out these silly errors and the module will work with any arraybuffer i bet
20:15 < jjjjohnnny> oooh copy foul
20:17 < chrisdickinson> fotoverite: if you manage to make it over to the east side, there are tons of good food cart at se 12th and hawthorne
20:17 < chrisdickinson> *carts, even
20:17 < chrisdickinson> though, saw your tweet; luc lac is also really good
20:17 < chrisdickinson> double dragon is delicious and is on se 12th and division (another bahn mi-ish place); and is happily situated between beermongers and apex
20:17 < chrisdickinson> & of course there's bailey's and santeria in downtown on broadway / ankeny
20:17 < chrisdickinson> (i think it's ankeny...)
20:18 < chrisdickinson> there's also a pdxnode meetup this week i think at new relic
21:17 < jez0990_> is there a REST module/layer for levelup?
21:18 < jez0990_> or perhaps a nice a way of implementing one?
21:22 < dominictarr> jesusabdullah: multilevel-http
21:22 < dominictarr> I mean jez0990_ ! sorry!
21:24 < jez0990_> dominictarr: awesome, thanks!
21:33 < jez0990_> defunctzombie_zz: thinking about it now, would this solve your email queue problem requirements for level...?
21:34 < mikeal> what is that library people are using to concat files in to browserify?
21:35 < substack> into?
21:35 < mikeal> well, before i guess is a better term
21:35 < substack> what are you trying to do?
21:36 < mikeal> basically, i have the browserify bundle which i stream to a response object
21:36 < mikeal> i need to stick some other javascript files before it
21:36 < mikeal> like the socketio client
21:36 < mikeal> which aren't getting run through browserify
21:36 < substack> so just do that?
21:37 < substack> https://github.com/dominictarr/convoy-stream
21:37 < substack> oh wait it uses message packing to reconstruct
21:38 < dominictarr> try https://ghub.io/stream-stream
21:38 < substack> yeah that looks about right
21:41 < Raynos> defunctzombie: you can merge & fix the engine.io-stream things
21:45 < mikeal> anyone using uglify-js as a stream?
21:53 < defunctzombie> jez0990_: I came up with this for now: https://github.com/shtylman/node-filepile
21:54 < defunctzombie> jez0990_: basically, I don't want another "service" that I have to run for something like email queues
21:54 < defunctzombie> jez0990_: most of the time the emails are sent immediately
21:54 < defunctzombie> jez0990_: I just need to handle the case when one is not sent or something to retry it
21:57 < defunctzombie> Raynos: what should be fixed?
22:16 < dominictarr> hmm
22:16 < dominictarr> oh, tape doesn't exit in 0.10?
22:30 < jjjjohnnny> i have successfully ripped the aac from youtube vids, streamed it to the browser, decompressed and resampled with web workers, and now i can play secret synthesizers on an ipad
22:31 < juliangruber> jjjjohnnny: sounds way too good!
22:32 < jjjjohnnny> juliangruber: it is. it is the missing link
22:38 < jjjjohnnny> what is the node file system method for checking a file exists without throwing an error if it doesn't?
22:40 < jjjjohnnny> i consistently have try catch syntax errors, what is my malfunction?
22:40 < jjjjohnnny> (I never use try catch)
22:46 < jjjjohnnny> mercy itit give smee chills
22:48 < dominictarr> substack: defunctzombie_zz Raynos juliangruber does anyone actually use subtests in tape/tap?
22:50 < jjjjohnnny> bout to put a accelowhammy bar on every song ever
22:55 < substack> accelowhammy!
23:03 < dominictarr> substack: tape in 0.10 is really weird!
23:06 < dominictarr> in 0.10 it runs some tests twice!
23:09 < substack> I'm working on fixing it right now
23:09 < substack> by ripping a lot of it out
23:18 < jjjjohnnny> ipad sounds like it is losing power. maybe a belt is slipping?
23:18 < jjjjohnnny> spring module cleaning
23:19 < substack> tighten the sprockets
23:20 < substack> change the liquid crystals
23:30 < mikeal> testling image is broken :( https://github.com/mikeal/broquire
23:31 < substack> investigating
23:32 < mbalho> "broquire" :(
23:33 < mikeal> haha :)
23:36 < dominictarr> substack: it's totally weird, how come it keeps looping?
23:36 < substack> I didn't put in the effort to figure that out since it was messy anyways
23:43 < dominictarr> if there is something that needs to be correct, it's a test framework.
23:43 < dominictarr> oh yeah - substack you should module.expots = test; test.test = test
23:43 < dominictarr> so that is is drop in compat with tap
23:43 < substack> good idea
--- Log closed Mon Apr 29 00:00:04 2013