--- Log opened Sun Mar 10 00:00:47 2013
00:11 < gozala> Raynos: too late, I'm already home
00:13 < sorensen> substack: ping
00:47 < Raynos> dominictarr: I realized I called your `o.computed` mapMany ( https://github.com/Raynos/graphics/blob/master/examples/full/mario.js#L37 ) and I called your `o.transform` map ( https://github.com/Raynos/graphics/blob/master/examples/react/mouse-position-image.js#L10 )
00:48 < dominictarr> very good
00:48 < Raynos> Am I'm like. YES same abstractions different stupid name
00:49 < Raynos> Do you have something like foldp? ( https://github.com/Raynos/graphics/blob/master/examples/full/mario.js#L84 ). i.e. given prev state and curr observable state compute some new current state
00:50 < Raynos> which I guess is like keeping some state in a closure and doing a transform
00:54 < dominictarr> Raynos: no I don't have anything like that
00:54 < dominictarr> nothing that computes a rate of change or an integral sort of thing
00:55 < dominictarr> you could, but there is nothing to guarantee that you get all the changes - it's not a stream.
00:55 < dominictarr> so, something like that might not be reliable.
00:55 < dominictarr> oh,
00:56 < dominictarr> Raynos: what do you think about my new level-* style?
00:56 < mbalho> prefixes ftw
00:58 < Raynos> dominictarr: https://github.com/dominictarr/level-trigger
00:58 < Raynos> forcing the user to install sublevel sucks
00:58 < Raynos> can't you just check if its installed and if not install it?
00:58 < dominictarr> Raynos: sure,
00:59 < dominictarr> I'm just doing that so I can iterate quickly
00:59 < Raynos> That makes sense
00:59 < dominictarr> I want to pull level-sublevel into levelup once it's good - but that is something we need to discuss
00:59 < Raynos> Forcing the user to manage the correct order and hierachy of all the plugins smells like express.use
00:59 < Raynos> and "oh my plugin breaks if you forget to use express.session()"
01:00 < Raynos> thats the only thing I want to avoid
01:00 < Raynos> the rest is fine
01:00 < dominictarr> right - so, the new pattern only uses level-sublevel
01:00 < dominictarr> there is no more monkey patching the main db after thta
01:01 < dominictarr> so, just pretend that isn't happening - imagine that is part of levelup
01:01 < dominictarr> Raynos: the test of this idea is ease of building your own plugins
01:01 < dominictarr> i.e. people other than me
01:02 < Raynos> hopefully
01:02 < Raynos> im kind of out of the loop :(
01:05 < defunctzombie> I want coffeescript people to stop using node
01:06 < defunctzombie> they need to go make their own runtime or whatever
01:16 < Raynos> +1
01:16 < Raynos> I think they should all go use component
01:19 < substack> sorensen: pong
01:19 < sorensen> i made an extended version of your 'defined' lib
01:19 < sorensen> thought you might be interested
01:20 < substack> Raynos: people writing coffee script and using component are still creating value that we need to figure out how to better appropriate for our own purposes
01:20 < substack> sorensen: publish it!
01:20 < sorensen> https://github.com/sorensen/defined-args
01:20 < sorensen> i did :)
01:21 < sorensen> tried to give you credits for it, saw tblobaums code first
01:21 < sorensen> realized you had a module for it after
01:21 < sorensen> i feel like a canadian using it
01:22 < sorensen> daaaa bears
01:23 < sorensen> substack: let me know what you think, also, are you going to be at node conf?
01:24 < Raynos> substack: I know, its hard
01:28 < substack> sorensen: yep
01:29 < sorensen> cool cool, hopefully we'll see each other
01:29 < dominictarr> defunctzombie: some one should write a coffeescript vm in ruby
01:29 < dominictarr> that doesn't run js
01:29 < defunctzombie> hahaha
01:30 < dominictarr> you should have to convert javascript to coffeescript to use it
01:30 < sorensen> wanted to see you out in oak town last time i was in SF but had the little sis with me
01:32 < defunctzombie> juliangruber: tapedeck doesn't seem to work
01:33 < defunctzombie> juliangruber: output goes to console even in server mode (which is fine) but it tries to load a reporter.js which it can't find?
01:35 < Raynos> substack: I want to use their work too. I think the best thing to do is fork and fix
01:36 < defunctzombie> yes
01:36 < dominictarr> coffee script often doesn't embrace the strengths of js
01:36 < defunctzombie> just fork fix and publish to npm or keep on github
01:37 < dominictarr> often I see Object Orientation when it's not an object
01:37 < dominictarr> when a closure would be fine
01:37 < dominictarr> or just a straight function
01:38 < dominictarr> It's only an object if it has both state and behavior.
01:44 < defunctzombie> agreed
01:44 < defunctzombie> coffescript people tend to think OOP when they really shouldn't
01:45 < Raynos> Everyone thinks OOP when they shouldnt
01:45 < defunctzombie> regardless, it is a different language and they need to come to terms with that and stop asking for support haha
01:45 < Raynos> btw
01:45 < Raynos> I was talking to a friend about JS jobs
01:45 < Raynos> and he mentioned he wouldnt take a coffeescript job. On principal
01:46 < Raynos> Is that a good principle or is that being an opinionated dick as an engineer
01:46 < Raynos> im worried its shallow to not work with people because they use coffeescript
01:47 < defunctzombie> it isn't
01:47 < defunctzombie> I won't take c# jobs or java jobs
01:47 < defunctzombie> those languages may be fine, but I tend to not like hte projects those languages are used for
01:47 < defunctzombie> and the decisions made as a result
01:48 < defunctzombie> I find correlation between it and am in a position to not take the jobs
01:49 < Raynos> I see
01:49 < Raynos> what do you actually like working on?
01:50 < defunctzombie> hm
01:50 < defunctzombie> shit that helps people do something better and isn't boring for me to work on
01:51 < defunctzombie> these days I like doing js stuff because it is very flexible and we are making interesting tools
01:51 < defunctzombie> really I like the "subset" of js that I tend to see many here use (subset/style)
01:52 < defunctzombie> and methodologies of testing, etc
01:53 < Raynos> If your looking for something let me know, I know something suitable
02:03 < dominictarr> Raynos: I nearly had a coffee-script job.
02:03 < dominictarr> I feel I can maintain a charitable opinion about coffee script as long as I don't use it
02:03 < dominictarr> but that is because I am good at js.
02:04 < dominictarr> to do good coffee script you need to understand good js
02:05 < dominictarr> and anyway, the important thing isn't syntax
02:05 < dominictarr> it doesn't matter whether you have a pretty syntax - that is just patterns that you can learn to read, and learn to type fast
02:05 < dominictarr> the truly important thing is architecture
02:06 < dominictarr> whether what you are building is elegant at a high level
02:06 < dominictarr> that is what is _actually_ important.
02:08 < Raynos> dominictarr: can you do a testling badge for observable?
02:17 < Raynos> dominictarr: I think i'll rewrite my signal portion of Raynos/graphics to use observable instead of reducible
02:17 < Raynos> its way less complex
02:17 < dominictarr> cool!
02:17 < dominictarr> yeah, you can completely write an observable in ~ 5-10 lines
02:19 < dominictarr> Raynos: is there a command to testlingify a module?
02:19 < Raynos> not yet
02:20 < dominictarr> If there was, all my modules would be on testling
02:21 < Raynos> :(
02:21 < dominictarr> how are you adding testling?
02:21 < Raynos> I have a ngen
02:21 < Raynos> that auto generates package.json with testling noise
02:21 < Raynos> and manually go into github and add hook and test hook
02:22 < dominictarr> https://npmjs.org/package/travisify
02:22 < dominictarr> that adds a travis hook automatically
02:23 < Raynos> yea
02:23 < Raynos> someone needs to write this module :D
02:24 < dominictarr> indeed
02:28 < mbalho> new version of javascript-editor http://maxogden.github.com/javascript-editor/
02:32 < dominictarr> mbalho: is it possible to use it without passing in a #editor thing
02:32 < dominictarr> ?
02:32 < dominictarr> can it just return an element
02:32 < dominictarr> or return an emitter with a .element property?
02:33 < jesusabdullah> mbalho: are you or have you ever been max ogden y/n
02:33 < dominictarr> you don't have to answer that
02:34 < mbalho> dominictarr: it defaults to document.body
02:34 < mbalho> dominictarr: you just have to give it a cotnainer
02:34 < mbalho> dominictarr: it creates its own elements inside the container
02:35 < dominictarr> so, can I go editer({container: document.createElement('div')})
02:35 < dominictarr> does it matter if it has been added to the dom yet?
02:36 < jesusabdullah> dominictarr: DAMN YOU PUBLIC DEFENDER DAMN YOUUUUU
02:47 < mbalho> dominictarr: hmm i am not sure
03:17 < defunctzombie> http://phpthegoodparts.tumblr.com/
03:33 < defunctzombie> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/40738.pdf
03:34 < dominictarr> wow, that looks good
04:17 < hij1nx> cool new leveldb logo! http://d.pr/i/fZzN
04:30 < rvagg> hij1nx: very nice
04:30 < rvagg> hij1nx: tho I think dominic was saying he thought lots of hexagons in it would be good; to link in a bit with node
04:30 < rvagg> but I'm easy! we should use it on all our projects on our READMEs
04:33 < hij1nx> well, that might be good for a leveldb-node account or something ;)
04:34 < rvagg> hij1nx: we need to make the node connection a subconcious thing
04:34 < hij1nx> we should try to keep it semi-platform agnostic
04:34 < hij1nx> agreed, thats why its green ;)
04:35 < hij1nx> the node green, plus it says "Tweetery about LevelDB things. Node.js in particular."
04:36 < rvagg> upload that baby!
04:37 < hij1nx> btw, https://twitter.com/LevelDB
04:39 < rvagg> tweet it too
04:44 < hij1nx> https://twitter.com/LevelDB/status/310610922240634880
05:02 < substack> http://substack.net/images/leveldb.png
05:02 < substack> more hexagons!
05:13 < hij1nx> hexagons are so 2012
05:14 < hij1nx> i thought she did a nice job, and its classy :)
05:15 < substack> yeah looks good
05:15 < substack> I was just looking for a distraction from this paperworky task
05:42 < rvagg> hij1nx: can we get a vector version of it?
05:45 < hij1nx> rvagg: yeah, where should we put it?
05:46 < rvagg> turns out, if you mention hexagons on twitter then this thing retweets you: https://twitter.com/hexagonbot ..
05:46 < rvagg> hij1nx: lets make a gh-pages branch on levelup and publish it there
05:46 < rvagg> along with a good size to embed in README pages
05:46 < rvagg> png
05:47 < rvagg> original vector, as svg would be handy tho if people want to use it elsewhere, like in presentations
05:55 < hij1nx> cool. its acutally pretty viable to publish a module from a gist! https://gist.github.com/hij1nx/5105621
05:56 < hij1nx> so i guess for things that are just too tiny to deserve a regular repo?
05:56 < hij1nx> but i like how a gist is actually a repo really, and then it just turns into a conversation
05:58 < hij1nx> rvagg: ok, will do
05:59 < hij1nx> rvagg: hexagonbot has a lot of followers, im going to mention hexagons in every tweet from now on ;)
06:06 < hij1nx> DOMINICTARR.
06:09 < rvagg> hij1nx: are you definitely going to be in dublin at the end of the month?
06:36 < Raynos> hij1nx: `ngen module-name description && git init && hub create Raynos/module-name && git add. && git commit -m "initial" && npublish`
06:36 < Raynos> still like 5 commands too many
06:37 < Raynos> I need to write `npmify` command that does all of that :D
07:00 < chrisdickinson> mine is: "init-repo; git first; git add .; git ci -m 'initial code commit'; npm version patch; git push -u origin master; git push --tags; npm publish"
07:37 < Raynos> chrisdickinson: You need to get `hub create`. Totally badass
07:37 < chrisdickinson> yeah
07:37 < Raynos> I also use `npublish` to `npm version patch && git push origin master --tags && npm publish`
07:37 < chrisdickinson> init-repo does that for me + adds testling hooks
07:38 < Raynos> O_O
07:38 < Raynos> you need to open source testling hooks
07:38 < Raynos> I wants them
07:40 < chrisdickinson> Raynos: https://gist.github.com/chrisdickinson/5127523
07:40 < chrisdickinson> assuming you have your github auth token saved as ~/.github-token
09:25 < Raynos> http://lanyrd.com/2012/scotlandjs/sccxkr/ :D
09:25 < Raynos> I feel sorry for scotland js
09:43 < Raynos> I cange mind
09:43 < Raynos> I feel jealous
09:51 < kanzure> scotlandjs is a neat name for a conference.
09:52 < kanzure> that is all.
10:01 < rvagg> isaacs: npm-www bug? https://npmjs.org/package/hoarders - "undefined"
10:30 < juliangruber> rvagg: multilevel is faster than mongodb for simple PUTs :) https://gist.github.com/juliangruber/5128036
10:32 < juliangruber> correction, I mean GETs
10:38 < rvagg> juliangruber: niiiice, but you can do better I think!
10:39 < juliangruber> that means I have to benchmark and improve the whole dependency tree :O
10:39 < rvagg> but you know what levelup is capable of from those benchmarks, so it's just the bits between
10:39 < rvagg> trim the fat
10:40 < juliangruber> if the underlying implementation were leveled I could make it much faster by removing mux-demux
10:40 < juliangruber> then it would only be dnode
10:41 < juliangruber> but I'll see how far I can get
10:42 < rvagg> juliangruber: mux-demux is needed for the streams?
10:43 < juliangruber> and events
10:43 < rvagg> ahhhh
10:43 < rvagg> hm
10:43 < rvagg> that's unfortunate I suppose
10:43 < juliangruber> I'll do a quick multilevel with leveled
10:43 < juliangruber> and see how that performs
10:43 < rvagg> impressive that you've managed to export the whole API tho
10:43 < juliangruber> and that it was so easy!
10:43 < rvagg> perhaps you should do a multilevel on leveldown
10:43 < juliangruber> or that!
10:44 < juliangruber> then you could pass that to the constructor of levelUp
10:44 < rvagg> then if we had the { db: <whatever> } then you can have levelup on the client end
10:44 < juliangruber> cool
10:44 < juliangruber> will do
10:44 < rvagg> a `db` option is on my todo list, it seems like a no-brainer
10:45 < rvagg> then you don't need no stinkin' events or streams
10:45 < juliangruber> I AM EXCITE
10:45 < LOUDBOT> WHERE THE HELL IS THE SPACE SHUTTLE
10:45 < rvagg> btw, levelup runs on my Kindle Paperwhite! I got Node to work on it tonight and for that I AM EXCITE
10:45 < juliangruber> :OOO
10:46 < juliangruber> that is sweet, man!
10:46 < rvagg> just working on a quick web server to expose to the world, before I go to bed
10:46 < juliangruber> multilevel-http?
10:47 < rvagg> no, just a standard node web server running on the kindle
10:47 < rvagg> just for the pure thrill
10:47 < rvagg> I don't actually need levelup running on there, but since I have cross-compiling working for it now it's pretty simple
11:58 < rvagg> http://home.va.gg:8080/
16:33 < isaacs> rvagg: yeah, deleted packages don't disappear all the way
16:34 < isaacs> rvagg: deleted the cache entry for it.  getting a proper 404 now
18:16 < mbalho> rvagg: hey can you put a node binary for kindle somewhere i can download?
18:16 < mbalho> everyones talking to rvagg!
18:19 < substack> whoa the taliban is employing 3d animators now http://www.youtube.com/watch?v=WusWrL0lZTk
18:48 < defunctzombie> it is hard to convince someone when they clearly don't understand
18:48 < defunctzombie> https://github.com/substack/mmmify/issues/3
18:49 < defunctzombie> I think thing guy wants to love es6 modules so hard
18:51 < defunctzombie> juliangruber: tapedeck doesn't work in IE8 it seems
19:09 < defunctzombie> pkrumins: substack: http://about.travis-ci.org/docs/user/how-to-skip-a-build/
19:09 < defunctzombie> ^ would be a nice thing to minimize useless testing
20:33 < defunctzombie> juliangruber: I think it has to do with the use of "shoe" or such. Maybe try a simpler live reloading server. tapedeck should work in all browsers otherwise the incentive to use it is less
20:33 < defunctzombie> juliangruber: I had to revert to mocha as a result :(
20:33 < juliangruber> defunctzombie: I only used it to check if tests are working before pushing to testling
20:33 < defunctzombie> juliangruber: when tests don't work on testling, I need to be able to debug locally
20:34 < juliangruber> since I don't want to have all those browsers running on my machine
20:34 < defunctzombie> juliangruber: I use ievms :)
20:34 < defunctzombie> debugging with testling is impossible currently
20:34 < juliangruber> you can debug failed tests in browserling, testling-ci added those nice links
20:34 < defunctzombie> juliangruber: not really
20:34 < defunctzombie> because I can't make code changes
20:34 < defunctzombie> or get good dev consoles
20:34 < defunctzombie> it really is not a substitute
20:34 < defunctzombie> I have tried
20:34 < defunctzombie> it does not work
20:35 < defunctzombie> I *must* be able to run locally, that is way more important than any live reload feature :)
20:36 < chrisdickinson> i wonder what a modern, stream-focused node.js framework would look like.
20:37  * defunctzombie does not want streams anywhere near the core/low level stuff
20:37 < defunctzombie> streams are too opinionated and complex
20:37 < defunctzombie> streams are a framework
20:37 < juliangruber> defunctzombie: then we have 2 use cases: I use it while developing and didn't yet care about debugging in browsers. BUT, since it's all tap, you should be able to swap test runners for that
20:38 < defunctzombie> juliangruber: it is all one use case
20:38 < defunctzombie> juliangruber: developing is debugging
20:38 < juliangruber> defunctzombie: but I want live reload!
20:38 < defunctzombie> juliangruber: if I can't debug with it, it is useless
20:38 < defunctzombie> juliangruber: sure, then make it work :)
20:38 < juliangruber> then don't use it or make a PR ;)
20:38 < defunctzombie> juliangruber: just saying that it isn't currently a replacement for my workflow because it has browser limitations
20:39 < defunctzombie> when I need to debug an issue, I have to stop using it which is unfortunate
20:39 < defunctzombie> cause I shouldn't have to do that
20:39 < defunctzombie> test tools should not be the ones causing breakages
20:39 < defunctzombie> if they do, then they are not to be relied on
20:40 < thl0> substack, defunctzombie: need some input on how to adapt browserify cli args to support sourcemap
20:40 < thl0> originally I had a sourcemapBundle arg that would tell me where the bundle ends up and when given automatically turns sourcemaps on
20:41 < thl0> however we already have an outfile arg, so that would be duplicate
20:41 < defunctzombie> thl0: I am more interested in api personally
20:41 < thl0> defunctzombie: well it has to match up with api cli uses though
20:41 < defunctzombie> thl0: other way around for me
20:41 < defunctzombie> thl0: I make the api first and then figure out how to expose via cli
20:42 < thl0> defunctzombie: exactly what I did
20:42 < thl0> and then I realize that for cli you'd have to give me bundle path twice
20:42 < defunctzombie> some problems have no easy answer
20:43 < thl0> i.e. for outfile (no affect on sourcemap) and then for sourcemap (turn them on and tell me what generated file they relate to)
20:43 < thl0> ok, I'll keep the extra sourcemap param around, make a PR and then we can decide if/how it can be improved
20:44 < defunctzombie> I personally am a fan of sourceURL
20:44 < defunctzombie> since that does what I need anyway
20:44 < defunctzombie> I don't really care about coffeescript
20:44 < thl0> right, but then you'd need to eval
20:45 < thl0> so I'm already way past that, I used sourcemappingURL and am in the last steps integrating into browserify
20:45 < thl0> will PR on browser-pack in a minute to support this and then on browserify itself
20:45 < defunctzombie> thl0: so you eval, whatever
20:46 < defunctzombie> thl0: I only do it for development anyway
20:46 < defunctzombie> thl0: eval is not evil
20:46 < thl0> defunctzombie: well @substack didn't like the eval and sourcemapping URLs are way more powerful
20:46 < defunctzombie> sure, I am not against the sourcemapping url
20:46 < defunctzombie> probably a cleaner long term solution
20:47 < thl0> defunctzombie: not only for coffeescript, but also allows you to debug minified code and see full variable names
20:47 < thl0> defunctzombie: cool
20:47 < chrisdickinson> defunctzombie: ah, wasn't saying that a framework should be baked into node. i just was wondering what a "modern, streaming" node.js framework might look like, so when i say that I don't like express I can point to something else.
20:47 < defunctzombie> chrisdickinson: ah
20:47 < defunctzombie> chrisdickinson: personally, I don't buy into streams for everything
20:48 < defunctzombie> chrisdickinson: I have toyed with the idea of a more streamy http routing system
20:48 < chrisdickinson> or, a framework that uses observables / reducers
20:48 < defunctzombie> chrisdickinson: but the api/ux never comes out as nice
20:48 < defunctzombie> chrisdickinson: don't really care for reducers or all that stuff in my basic http routing setup
20:48 < defunctzombie> chrisdickinson: more and more I am actually moving away from just lots of api routes and toward something like dnode probably
20:49 < defunctzombie> or persistent two way communication
20:49 < chrisdickinson> hm
20:50 < chrisdickinson> dnode is definitely awesome, but i wouldn't replace restful routes for it
20:50 < defunctzombie> chrisdickinson: sure, just depends on the usecase
20:50 < chrisdickinson> s/for it/with it/g
20:51 < chrisdickinson> yeah
20:51 < defunctzombie> for restful routes I am very very happy with express
20:51 < defunctzombie> no other thing I have seen yet is better
20:51 < defunctzombie> not even close actually in terms of clarity
20:59 < rvagg> mbalho: download node off my KINDLE WEB SERVER: http://home.va.gg:8080/noodle.img.gz
20:59 < rvagg> mbalho: it's a mountable image, have to do it that way cause of the crappy filesystem used on the rest of the kindle
21:00 < rvagg> mbalho: put it in /mnt/us/ and make a mount script, noodlemount.sh, with this in it:
21:01 < rvagg> #!/bin/sh
21:01 < rvagg> mount -o loop,noatime -t ext3 /mnt/us/noodle.img /opt/node
21:02 < rvagg> then you'll have an /opt/node/ directory to play with
21:02 < rvagg> export PATH="${PATH}:/opt/node/bin"
21:02 < rvagg> install global modules by going into /opt/node/lib and `npm install` there
21:02 < rvagg> and make your node apps in /opt/node cause npm will bork at installing on the normal fs
21:03 < rvagg> oh, and there's a compiled version of levelup in that image, /opt/node/lib/node_modules/levelup, works like a charm
21:10 < rvagg> mbalho: I'm having trouble on my home network, so grab it here:  http://js.vagg.org/noodle.img.gz
21:10 < rvagg> it's only 9M but it's actually a 250M image file so you have space to play once mounted
21:15 < thl0> defunctzombie: so API would look like this:  .bundle({ sourcemapBundle: bundlePath }) -- if sourcemapBundle prop is not given no sourcemaps are generated
21:21 < defunctzombie> thl0: is this going to put a file on my disk?
21:22 < thl0> defunctzombie: nope
21:22 < defunctzombie> thl0: it is just for urls in the sourcemap?
21:22 < thl0> defunctzombie: it just needs to know where it is gonna be since chrome will try to find the original files relative to the generated file path
21:22 < defunctzombie> thl0: also, why not just "sourcemapPath": ?
21:22 < thl0> defunctzombie: yep
21:22 < defunctzombie> or some such since that is what it is
21:22 < defunctzombie> thl0: well, the problem with original files relative to that
21:22 < defunctzombie> thl0: is that I have many files which are not web server accessibe
21:23 < defunctzombie> *accessible
21:23 < thl0> defunctzombie: because its the path of the bundle (that contains also wil contain sourcemap)
21:23 < defunctzombie> they are part of final bundles, but not something you can ever make an http request to get
21:23 < ralphtheninja> rvagg, mbalho you guys should blog about the kindle
21:23 < thl0> defunctzombie: server works since it will just ask server for the original files (relative to where bundle loaded from)
21:24 < ralphtheninja> share that info yo! :)
21:24 < defunctzombie> thl0: won't work cause some of those files won't be obtainable ;)
21:24 < thl0> defunctzombie: path can be any path
21:24 < substack> thl0: it'd be nice if we could just do --debug like before
21:24 < thl0> defunctzombie: files have to be attainable
21:24 < substack> are paths strictly necessary?
21:24 < defunctzombie> thl0: I am saying they are not
21:24 < thl0> substack: but chrome needs to know where bundle is to find originals relative to it
21:24 < defunctzombie> thl0: imagine I have my "public" js files in /public/js
21:25 < defunctzombie> and those reference things in /libs/
21:25 < substack> thl0: I think so long as the names are the same nobody will care
21:25 < defunctzombie> libs in not publicly visible
21:25 < thl0> defunctzombie: if you don't have them there this won't work -- I thought of this, but that is unavoidable
21:25 < substack> chrome doesn't seem to care whether files exist or not either
21:25 < defunctzombie> thl0: I will probably need to put the sourceURL option back for debugging heh
21:25 < substack> at least with sourceURL that is the case
21:25 < thl0> substack: it does not until you look into the file and it is emptyu
21:26 < thl0> substack: b/c if it doesn't find it it loads no source into it
21:26 < substack> do the stack traces show up though?
21:26 < defunctzombie> with sourceURL I don't really look at the files, I just care about reasonable stacktraces and relative locations
21:26 < thl0> substack: yep
21:26 < substack> probably it's fine without it then
21:26 < defunctzombie> substack: thl0: I think once we have something to play with we will get a better idea of it :)
21:27 < substack> I don't like having to pass debug paths around
21:27 < substack> would rather just do --debug and have it mostly work even if it's not 100%
21:27 < thl0> substack: bottom line is for this to work properly we need to give the mapper the generated bundle path
21:28 < thl0> substack: otherwise it will never be able to find the original files and you cannot put breakpoints and look at the code since they'll appear empty
21:28 < substack> look at the -o param
21:28 < thl0> substack: so I thought sourcemapBundle is ok (doubles as flag and a way to tell me where you'll save the bundle)
21:29 < thl0> substack: -o is just for commandline
21:29 < substack> or if the bundle is output on stdout just have part of it not work
21:29 < thl0> substack: but people may want to give -o but want to have no sourcemaps
21:29 < substack> then they wouldn't say --debug
21:29 < substack> combinations: --debug, -o + --debug, -o
21:30 < substack> 3 of them
21:30 < substack> or the empty set makes 4
21:30 < thl0> substack: but what if they say --debug but don't give -o ?
21:30 < substack> then have it partly work
21:31 < substack> so long as stack traces show up properly I don't even care about the other part
21:31 < thl0> substack: or if they want --debug but want to write file themselves
21:31 < substack> I can open the files myself
21:31 < substack> I barely even use the debugger except to look at console log output and stack traces
21:31 < thl0> substack: ok, I'll do it that way, but then for the js API, you'd have to give me 'outfile' as well although it wouldn't be actually written
21:31 < substack> the fanciness of it seems too IDE-esque usually
21:32 < substack> thl0: you can have a second param for that explicitly
21:32 < substack> I'm more thinking about how the command-line tool should infer the paths
21:32 < thl0> substack: i.e. 'sourcemapRoot' ?
21:32 < substack> having to specify 2 params to get source maps sucks
21:32 < substack> sourcemapRoot doesn't really tell people what that is supposed to be
21:33 < thl0> substack: so even for non-cli we'd give --debug and outfile (but not write outfile) ?
21:33 < substack> no
21:33 < substack> outfile is only something that the command line tool has
21:34 < substack> the lib doesn't write any files
21:34 < thl0> substack: ok so how would the api workk then
21:34 < substack> first, what does the sourcemapRoot actually *do*
21:34 < thl0> substack: we still need a way to turn on sourcemaps and pass bundle path into browser-pack
21:34 < substack> and what should it be
21:34 < substack> can you give an example?
21:35 < thl0> substack: so when I generate the sourcemap, the original files get included with paths relative to it
21:35 < thl0> substack: if this in not done properly, chrome cannot find them and they are empty in dev tools
21:36 < thl0> substack: i.e. chrome makes an actual server request (or loads from filesystem) to get the original sources
21:36 < thl0> substack: this only happens when dev tools are open
21:36 < substack> most of the time those files aren't even accessible
21:36 < substack> I wish sourceURL didn't need an eval() container
21:36 < substack> then I would just ignore sourcemaps completely
21:36 < substack> paul_irish_: ^^^
21:36 < thl0> substack: but mappingURLs are so much more powerful
21:37 < substack> but they are much more tightly bound to the file system organization
21:37 < thl0> substack: people will want them (i.e. you could debug minified code with variable names being restored)
21:37 < substack> they aren't portable when you move files around
21:37 < substack> since the refs get all mis-aligned
21:37 < thl0> substack: all you have to do is set up your server properly to serve the original files (while developing)
21:38 < substack> and they depend on placing the files properly into a publically-accessible location
21:38 < substack> I usually have a browser/ and static/ where the original files in browser/ aren't even accessible directly
21:38 < thl0> substack: I thought you were aware of this when we decided to go the mappingURL route?
21:39 < substack> if you have to set up your server "properly" that is imposing an unwarranted constraint downstream on users I think
21:39 < substack> I hadn't looked very much into how these work
21:39 < substack> this seems pretty terrible
21:39 < thl0> substack: well, all you'd have to do IMO is have the root be above all your original files
21:40 < thl0> substack: that way you can still serve them properly
21:40 < substack> it might be better to just Function(function(){ //@ sourceURL=...\n $CONTENT }.toString())
21:40 < substack> that way the files show up not all in a string but sourceURL still works
21:41 < substack> bundles should be portable
21:41 < substack> if they impose external file organization constraints that is a bad api that bleeds out
21:44 < thl0> substack: lsts experiment with this then - I'll just make this work on my fork (which will work togehter with my browser-pack fork)
21:45 < substack> experimentation is good
21:45 < thl0> substack: ok - so ignore browser-pack PR for now
21:46 < thl0> substack: it'd be nice to find a way to somehow make chrome load the src from within the bundle, but that is not what this is trying to do
21:46 < thl0> substack: the specification is written with transpiled/minified code in mind, so they expect the original to look entirely different
21:48 < substack> this is what happens when people invent new things without testing them in reality first >_<
21:49 < thl0> substack: I don't see the big pain point here though, since this is only to support development
21:50 < thl0> substack: i.e. you could have the files in proper locations while developing -- you'll see in the example I'll commit
21:50 < substack> but sourceURL is a much better fit
21:50 < thl0> substack: then in production you just don't deploy those files
21:50 < thl0> substack: until you want to make transpilers happy
21:50 < substack> the only reason I dislike sourceURL is because of the eval() constraint
21:51 < thl0> substack: I believe more people will use transpilers in the future (since browsers support these mappings now)
21:52 < thl0> substack: if you want to make browserify useful for more people, we should support this
21:52 < thl0> substack: here is a thought: make souremappingURLs only work via a javascript API which people can use and add sourceURL option as well
21:53 < substack> maybe
21:53 < thl0> substack: sourceURL option would work from cli (via --debug) and be what most people use, but at least if needed people can leverage the more advanced sourcemapping
21:53 < substack> it feels very messy
21:53 < substack> --debug should just do sourceURL, I agree
21:54 < substack> since there seems to be no way to provide that functionality cleanly
21:54 < substack> with source maps
21:54 < thl0> substack: ok, that'd be another PR
21:54 < substack> I can just write that part
21:56 < thl0> substack: well I don't think it is that bad, all you have to do during development is put the bundle above the original files
21:56 < thl0> substack: but ok, lets divide it up then, you'll put sourceURLs back in and I'll have a fork with sourceMappingURLs that people can try
21:57 < substack> sounds good
21:57 < substack> doing this now
22:00 < thl0> substack: a little sad though - took a while to get this all working properly (sourceURL is rather trivial compared to full fledged mappings)
22:03 < Raynos> thl0: why are sourcemaps fucked?
22:03 < substack> thl0: we can have them, it's just sad that they suck so much
22:03 < thl0> Raynos: cause they try to be very flexible and support transpiled/minified languages
22:04 < Raynos> why cant we use them for our use-case?
22:04 < Raynos> I can bitch at the firefox devs for sourcemaps
22:04 < substack> Raynos: they impose file organization constraints
22:04 < Raynos> so consider me a liason
22:04 < substack> end-users will need to organize their files in a particular way
22:04 < thl0> substack: ok - I'll finish these tests and check into my fork, then you can have a look
22:04 < substack> Raynos: complain at them to make //@ sourceURL work in function-scope
22:04 < substack> instead of eval-scope
22:04 < substack> problem solved
22:04 < Raynos> no thats not the way
22:05 < Raynos> we need to fix source maps
22:05 < Raynos> but I dont understand the problem
22:05 < thl0> substack: actually they just have to be organized like always (i.e. for require to work, files also have to be organized)
22:05 < substack> Raynos: the problem is that to use source maps you need to put your original source files in a particular place
22:05 < thl0> substack: you'll see from the example that it is maybe not that bad - give me a few mins then I'll check in
22:06 < Raynos> I dont understand the problem
22:06 < substack> Raynos: so you can't just move the bundle.js around however you please
22:06 < Raynos> so the bundle has to be relative to the file locations?
22:07 < Raynos> Well how do you serve the bundle from memory?
22:22 < thl0> substack: Raynos: it's checked in you can 'git clone -b sourcemaps git://github.com/thlorenz/node-browserify.git'
22:23 < thl0> Raynos: substack: then go to example/source_maps and either 'build.sh' or node the build js - open index and look in your browser console
22:23 < thl0> Raynos: substack: requires chrome beta or canary
22:24 < thl0> substack: just confirmed, stacktraces still work without the files actually being loaded, but then they are empty
22:31 < mbalho> rvagg: hahaha 'nood'e
22:33 < thl0> Raynos: I don't think it's such a big problem - check out the example in my fork
22:33 < mbalho> 'noodle'
22:33 < thl0> Raynos: currently working on a simple sample app that uses express and browserify with sourcemapURLs
22:34 < thl0> Raynos: I hope that will show that it is actually ok, although I agree that people should have option to use simple sourceUrls as well
22:34 < Raynos> thl0: this sounds complex :(
22:34 < thl0> Raynos: sourceURLs would work like in browserify@1 - @substack is working on that right now
22:35 < thl0> Raynos: it's not complex - have a look at the example in the fork (or the sample app once I built it ;) )
22:38 < thl0> Raynos: just a bit annoying since the original files have to actually exist and be resolvable by chrome
22:38 < thl0> Raynos: that's the only way though that transpiled language debugging in browser would work
22:42 < Raynos> :(
22:42 < Raynos> wtf do you mean the original files have to exist
22:42 < Raynos> But I gave them the fucking original files
22:42 < Raynos> in the fucking bundle
22:43 < Raynos> man this is epic bullshit
22:43 < Raynos> EPIC BULLSHIT
22:43 < LOUDBOT> OH NO SAD MOUSE IS DYING
22:43 < Raynos> thl0: from my point of view I want to patch tryme & browservefy
22:43 < Raynos> so that both of them work with source maps
22:44 < thl0> Raynos: but if your bundled files had been transpiled (i.e. where minfied or originally coffeescript) then the source in the bunle is not the original
22:44 < Raynos> true dat
22:45 < thl0> Raynos: so chrome wants to load the actual original code before it was transformed in any way since the whole point is to debug your code as you see it in your editor
22:45 < thl0> Raynos: and get stacktraces pointing to lines in your editor
22:45 < Raynos> I see your point
22:45 < Raynos> I still think
22:46 < Raynos> It's ok
22:46 < thl0> so sourcemapURLs support that - not such a big deal since they could also just exist in memory as long as you serve them to chrome when it asks for it
22:46 < Raynos> defunctzombie: remind to remove the reducible bullshit from Raynos/tryme so you land my fork :D
22:48 < thl0> Raynos: this is actually pretty cool if you think about it, since now you could write and debug any language in the browser that transpiles sourcemap information
22:48 < thl0> Raynos: although I personally am perfectly fine with JavaScript ES5 ;)
23:50 < ralphtheninja> mbalho: have any good pointers to sites with public and sound data?
23:50 < ralphtheninja> mbalho: want pretty much any kind of data, population in cities, temperatures, whatever
23:50 < ralphtheninja> preferrably in json of course :)
23:52 < ralphtheninja> and if it's just streams you can connect to, even better
23:54 < rvagg> mbalho: gunzip that file before you put it on your kindle btw
23:55 < thl0> substack: Raynos: created sample express app using sourcemaps here: https://github.com/thlorenz/browserify-sourcemap-example
23:56 < thl0> it's actually no pain at all
23:56 < substack> I'll need to play around with this
23:57 < thl0> substack: cool - all I did is use a static file server to serve original files
23:58 < thl0> substack: bundle is generated on the fly during development to reflect changes
--- Log closed Mon Mar 11 00:00:45 2013