--- Log opened Wed May 29 00:00:13 2013
--- Day changed Wed May 29 2013
00:00 < substack> "good" is sufficiently subjective to be completely open-ended
00:00 < substack> just tell people not to use bad abstractions and show them good abstractions instead
00:00 < dominictarr> yes, that is an interpretation I can live with
00:01 < substack> all the best practices you ever need to know are all on http://www.faqs.org/docs/artu/ch01s06.html
00:02 < substack> everything else is just a special case
00:02 < dominictarr> but then, some of the current core abstractions, has sort of deabstracted a bit...
00:02 < dominictarr> these are all what you arrive at following "programming muthafucker!"
00:03 < dominictarr> prehaps I should sleep on this before I respond.
00:04 < dominictarr> on that note
00:04 < dominictarr> night all
00:11 < Raynos> isaacs: https://github.com/isaacs/npm/issues/3491
00:11 < Raynos> npm publish is slow, recommend areas of code to optimize and ill look into it
00:11 < jesusabdullah> substack: any advice/modules for recursively traversing a directory?
00:15 < isaacs> Raynos: yeah, we've talked about this
00:15 < isaacs> Raynos: whneever i explain the situation, whoever i'm talking to glazes over and goes, "I guess 10 seconds isn't so bad..."
00:15 < Raynos> isaacs: we have?
00:16 < isaacs> Raynos: either you or defunctzombie i think
00:16 < Raynos> npm publish is pretty critical to my "MODULE ALL THE FUNCTIONS" work flow
00:16 < isaacs> Raynos: it's next up once 'm done with the new http client.
00:16 < isaacs> Raynos: yeah
00:16 < isaacs> Raynos: i agree.
00:16 < Raynos> which means
00:16 < Raynos> I will actually try to fix it
00:16 < isaacs> Raynos: there are two things that will make this much better:
00:16 < defunctzombie> the code has to be completely rewritten
00:16 < isaacs> right
00:16 < Raynos> or at least steal the easy subsets of the problem and write modules
00:16 < defunctzombie> I unfortunately don't have the time to devote right now :)
00:17 < defunctzombie> so have stopped complaining
00:17 < isaacs> basically, i need a standalone module thing that gets modules out of the npm registry, and puts them in
00:17 < isaacs> and it should always be a single stream pipe chain
00:17 < Raynos> i can do that with some guidance
00:17 < defunctzombie> at one point I had figure out more or less a good module breakdown
00:17 < defunctzombie> cause i was working on the tryme stuff
00:17 < defunctzombie> which needed to download and install stuff
00:18 < Raynos> if someone can add comments to the thread explaining potential solutions i will see what I can do
00:31 < Raynos> isaacs: what would the api for getting and putting to a registry look like?
00:34 < isaacs> Raynos: whatever.
00:34 < Raynos> isaacs: It's more, I'm not sure _what_ is being put
00:35 < Raynos> is it a tarball ?
00:35 < Raynos> or files
00:35 < Raynos> or a folder
00:35 < Raynos> or a package.json
00:35 < isaacs> Raynos: construct a thing passing some config options to a constructor.  then the object has a publish(thing, cb) and a install(thing, place, cb) method
00:35 < isaacs> Raynos: yes, any of those.
00:35 < isaacs> Raynos: i want to throw any random shit at it, and it figures it the fuck out.
00:35 < Raynos> oh
00:35 < Raynos> I see
00:35 < isaacs> Raynos: i'm curisng because you'll curse, writing this thing, i promise.
00:35 < isaacs> :)
00:35 < Raynos> is there a list
00:35 < Raynos> of all possible things ?
00:35 < isaacs> Raynos: lib/cache.js
00:35 < isaacs> Raynos: in npm.
00:36 < isaacs> Raynos: that's the thing with all the logic that figures out what you're trying to fetch
00:36 < Raynos> so I just need to write a fast publish(thing, cb) to make npm publish fast
00:36 < isaacs> Raynos: it *shouldn't* do all the logic of install.
00:36 < isaacs> Raynos: basically, yeah.
00:36 < Raynos> is a fast install(thing, place, cb) needed for npm publish ?
00:36 < Raynos> or is that someone else's problem? :D
00:36 < isaacs> Raynos: also, instead of putting everything in one place first, and doing 3 PUT requests, it should do one PUT request, and not use any temp or caches.
00:37 < isaacs> Raynos: this codebase predates Stream.pipe
00:37 < Raynos> fast is fast
00:38 < isaacs> Raynos: to do the one PUT, it probably should use some kind of "put a couchdb doc with an attachment in one single atomic put using base64" lib.
00:38 < isaacs> Raynos: without deleting all the other attachments.
00:39 < Raynos> ok cool
00:39 < Raynos> that's a decent enough starting place
00:39 < Raynos> I may do this
00:39 < Raynos> I may ragequit after I read lib/cache.js though
00:40 < substack> https://github.com/substack/persona-id
00:41 < isaacs> Raynos: i predict that it'll take me a week or two to do this.
00:41 < isaacs> Raynos: and i'm intimately familiar with the codebase.
00:41 < Raynos> isaacs: so I can't just "do this", this evening? :(
00:42 < isaacs> Raynos: here's the thing: if you YOU do it, it'll STILL take me 2 weeks to accept it, unless you're interested in supporting npm forever.
00:42 < isaacs> Raynos: because i'll have to read everything you do and really grok it
00:44 < Raynos> i see.
00:44 < Raynos> that kind of sucks
00:45 < isaacs> substack: why do you use ecstatic rather than st?
00:46 < jesusabdullah> why do you use st instead of ecstatic?
00:46 < isaacs> jesusabdullah: because it does a lot fewer syscalls.
00:46 < isaacs> jesusabdullah: and caches way more agressively.
00:47 < substack> isaacs: I bounce completely on the st readme
00:47 < substack> there's too much config
00:47 < isaacs> substack: it's like 100% optional
00:48 < substack> that's not obvious
00:48 < isaacs> substack: i'll write a tl;dr section. thanks for the feedback :)
00:48 < substack> write a tinier example and put it before the longer one
00:50 < thl0> Raynos: https://github.com/thlorenz/testlingify/commits/master
00:51 < Raynos> isaacs: I use ecstatic instead of st because of the caching
00:51 < Raynos> i find st's caching defaults way too aggressive locally
00:51 < Raynos> I use st in production
00:51 < Raynos> thl0: cool
00:52 < thl0> yeah, you guys convinced me it's the right thing to do
00:52 < jesusabdullah> fyi I take pull requests on ecstatic XD
00:53  * substack foods it up &
00:54 < isaacs> Raynos: yeah, i set cache:false in dev
00:54 < isaacs> Raynos: this is why configuration is better than convention ;)
00:54 < isaacs> Raynos: or i just restart the server all the time in dev.
00:54 < isaacs> cuz why not.
00:54 < Raynos> thats a pain in the ass
01:11 < defunctzombie> I just restart the server using node-dev
01:11 < defunctzombie> I don't use st or ecstatic tho :)
01:17 < timoxley> ok need some streams assistance
01:17 < timoxley> consider: childProcess.stdout.pipe(anotherStream)
01:17 < timoxley> when the childProcess exits, I want to write to anotherStream some data about the status code it exited with…
01:18 < timoxley> but anotherStream is ended before I get a chance to do such a thing
01:19 < timoxley> I've gotten around it by doing something like:
01:20 < timoxley> a through stream with an end handler
01:21 < timoxley> that waits for the childProcess 'close' and writing before emitting end
01:21 < timoxley> but I'm not sure if this is "the way" to solve this
01:25 < guybrush_> woah this is nice
01:25 < guybrush_> http://bitcoop.sourceforge.net/
01:25 < guybrush_> friends can share their backups, encrypted and compressed
01:33 < defunctzombie> timoxley: yea, I think that is the way
01:33 < defunctzombie> timoxley: you can also do pipe with end: false
01:33 < defunctzombie> and wait for close yourself
01:33 < timoxley> defunctzombie ahh
01:34 < defunctzombie> guybrush_: would be interesting to see something like this built on bittorrent sync
01:35 < jesusabdullah> guys I wrote a CONTROVERSIAL BLOG POST http://jesusabdullah.github.io/
01:36 < jesusabdullah> https://twitter.com/jesusabdullah/status/339555476532518912 if you care to retweet
01:36 < jesusabdullah> who was I talking about this stuff about with the other day
01:38 < defunctzombie> jesusabdullah: the dependency issue is better solved be separating CLI from "lib" like modules
01:38 < defunctzombie> but we don't really do that much cause it doesn't matter that much
01:38 < defunctzombie> the space taken by the deps is trivial
01:38 < defunctzombie> also, I don't like that this has you write in some weird ORM like language
01:38 < defunctzombie> versus just making it basic js
01:38 < Raynos> timoxley:
01:38 < jesusabdullah> read closer
01:39 < Raynos> a.pipe(b, { end: false })
01:39 < defunctzombie> the express thing you described is actually not bad at all
01:39 < timoxley> Raynos that simple. great. thanks.
01:39 < Raynos> timoxley: remember to manually call .end()
01:40 < timoxley> is there a better way to signal exit status across a stream than a magic bit at the end?
01:40 < Raynos> timoxley: events?
01:40 < timoxley> stream is across a network
01:40 < Raynos> oh
01:41 < Raynos> custom documented protocol
01:41 < Raynos> that works
01:41 < timoxley> ok
01:41 < Raynos> or use HTTP and trailing headers
01:41 < timoxley> that's exactly what I was trying to avoid
01:41 < timoxley> trailing headers?
01:41  * timoxley investigates
01:42 < Raynos> they are HTTP 1.1 and weird
01:44 < timoxley> jesusabdullah your npm install output is gross ├──
01:44 < timoxley> jesusabdullah try npm install  --color false prompt
01:45 < jesusabdullah> oh maaaaan
01:45 < jesusabdullah> what is that
01:45 < jesusabdullah> browser y u no
01:45 < jesusabdullah> timoxley: it's the tree characters not the colors
01:45 < timoxley> oooh
01:52 < jesusabdullah> timoxley: maybe a screenie is a good idea though
01:52 < isaacs> substack: updated the st readme
02:27 < jesusabdullah> woo chilts thx4retweet
02:31 < chilts> jesusabdullah: pleasure ... I like the idea and will have to try it to see if I like it more :)
02:31 < chilts> hmm, I need to make my irssi highlight when people say my nick in the middle of lines
02:32 < jesusabdullah> hah
02:55 < jesusabdullah> dangit youdaman I sold the shit out of that
02:55 < jesusabdullah> XD
05:45 < Nexxy> jesusabdullah, thanks :) we weren't technically until today
05:47 < jesusabdullah> ah!
05:47 < jesusabdullah> well that's fantastic!
05:47 < jesusabdullah> where did you have it?
05:47 < Nexxy> this tiny little chapel in the mountains of Washington
05:47 < jesusabdullah> oh nice
05:48 < Nexxy> it's a liek
05:48 < Nexxy> chapel/women's retreat/nursery
05:48 < Nexxy> with a giant wooden checkers board and a garden train and
05:48 < Nexxy> a view of the gorge
05:48 < substack> congrats! even though I scorn both marriage and chapels in the abstract
05:48 < jesusabdullah> elven sanctuary
05:49 < Nexxy> haha yeah
05:49 < Nexxy> it was a non-secular chapel
05:49 < Nexxy> just a pretty place
05:49 < substack> good good
05:49 < Nexxy> also marriage is an important legal distinction when you have a child
05:50 < substack> yeah it's fucked up still
05:52 < substack> but anyways!
05:56 < Nexxy> substack, but there's also the aspect that my state doesn't do same sex marriage
05:56 < Nexxy> and yet we are legally married because of how fucked up the system is
05:57 < substack> yes everything is so screwy :/
06:00 < substack> but things that are not screwy: npm modules
06:00 < substack> and streams! yay
06:01 < substack> this streaming templatey stuff is quite nice
06:08 < substack> isaacs: st(__dirname + '/static') was hanging on some of my routes :/
06:44 < owen1> isaacs: love the new readme. send a pull request but it's just my opinion. feel free to ignore it
07:01 < jesusabdullah> dangit where's dominic?
07:53 < timoxley> substack how to go about dynamically updating a "row" in a stream
07:53 < timoxley> as in, I've rendered some data, but that data has changed
07:53 < timoxley> don't want to redraw whole list
07:54 < timoxley> this is in the browser
07:57 < substack> timoxley: save the rows into an object or array and check the rows that stream in to do something custom
07:58 < substack> or you could just query for the row from the dom directly given the row params
07:59 < timoxley> substack my brain wants to call for "data binding"
08:00 < dominictarr> timoxley: give each row an ID of some kind?
08:02 < timoxley> ok I think I have an idea. the complexity is that the dom is rendered once via one stream, and then updated based on another
08:03 < timoxley> "complexity"
08:03 < substack> it can be the same stream for both
08:03 < substack> just check for a property to tell you what kind of update you're dealing with
08:04 < timoxley> ok. sounds simple.
08:44 < timoxley> dominictarr is map-stream the best way to make a stream filter
08:44 < dominictarr> no, use through
08:44 < dominictarr> bbab, food
08:44 < timoxley> and just don't push if the data shouldn't be included
08:44 < jesusabdullah> dangit dominictarr I was gonna ask you about something and now I don't remember what
08:44 < timoxley> ok
08:44 < jesusabdullah> oh I remember now
08:45 < jesusabdullah> dominictarr: whenever you get back lol
08:45 < dominictarr> jesusabdullah: what was it?
08:45 < jesusabdullah> remember when we talked about mtimes stuff? for emulating make?
08:45 < dominictarr> yeah
08:45 < jesusabdullah> did we ever find anything that did that? I know we talked api
08:45 < jesusabdullah> I think I could use it bout now
08:46 < dominictarr> no. I don't know if anyone has written a module for it.
08:46 < jesusabdullah> yeah I couldn't find one
08:46 < dominictarr> jesusabdullah: you win! that means you get to write it!
08:47 < dominictarr> bbaib. food.
08:55 < jesusabdullah> hah was it really this easy? XD
08:57 < jesusabdullah> dominictarr: how about a recursive directory listing? You know of one of those?
09:00 < jesusabdullah> dominictarr: ohey you wrote that
09:01 < jesusabdullah> dominictarr: bad readme! BAD https://github.com/dominictarr/ls-r
09:10 < jesusabdullah> hahaha! Anyways I used that plus 'behind' (new module) to implement mtime-based recompile ^__^
09:18 < jesusabdullah> don't worry, readme for behind is next to useless as well
09:18 < jesusabdullah> no, nonexistent therefore actually useless
09:35 < dominictarr> jesusabdullah: I wrote a way better one: pull-glob
09:37 < jesusabdullah> feel free to show me
09:51 < dominictarr> var glob = require('pull-glob'); glob('./**/*.js').pipe(….) //get a pull-stream of js files above current working directory
09:52 < dominictarr> jesusabdullah: ^
09:55 < jesusabdullah> stream's too complex for my needs
09:55 < jesusabdullah> also idk how a pull-stream works
09:56 < dominictarr> glob('./**/*.js').pipe(pull.collect(function (err, array) {…})) // get an array like that
09:57 < jesusabdullah> I don't understand
09:57 < jesusabdullah> what is pull
09:57 < dominictarr> jesusabdullah: it's super simple, much simpler than node streams
09:57 < dominictarr> var pull = require('pull-stream')
09:57 < jesusabdullah> I, uhh
09:57 < jesusabdullah> but what IS it
09:58 < dominictarr> so, the converse is a push stream
09:58 < dominictarr> node's streams 0.8 and before where push stream
09:58 < dominictarr> a push stream is like a normal plumbing...
09:59 < dominictarr> when the tap is open the data just comes squirting out.
09:59 < dominictarr> a pull stream is the opposite, it's like a drinking straw.
10:00 < jesusabdullah> what are 0.10 streams
10:00 < dominictarr> the data only moves when the consumer pulls ("sucks") it through.
10:00 < dominictarr> 0.10 are almost pull streams
10:00 < dominictarr> they are pull when you only have two,
10:01 < dominictarr> but 0.10 streams are more like veins, or your throat...
10:01 < dominictarr> "swallow streams"
10:01 < dominictarr> each streams pull-pushes it into the next bit
10:02 < jesusabdullah> why are there 3 kinds of streams now :C
10:02 < dominictarr> in 0.10 pipe pulls out of the readable and then pushes into the writable
10:02 < dominictarr> jesusabdullah: there are more than 3.
10:02 < dominictarr> but these are the basic 3 types the occur in nature :)
10:03 < jesusabdullah> but why
10:03 < jesusabdullah> why do I have to know this stuff now?
10:03 < dominictarr> because you are an engineer.
10:04 < jesusabdullah> ugh
10:04 < jesusabdullah> I'm irritated that people are making up too many abstractions
10:04 < dominictarr> yes, well.
10:04 < dominictarr> streams2 broke the seal.
10:05 < jesusabdullah> okay so let me get this straight
10:05 < jesusabdullah> streams2 has a lot of nitty-gritty
10:05 < dominictarr> the difference between 1 and 2, is really the difference between 1 ande infinite
10:05 < jesusabdullah> so you can make streams that implement *part* of it?
10:05 < jesusabdullah> are these streams all vaguely compatible?
10:05 < dominictarr> yes.
10:05 < dominictarr> ultimately, they are all the same idea
10:06 < jesusabdullah> but what can and what can't I pipe to what?
10:06 < dominictarr> but they are all crude implementations of the platonic ideal steam.
10:06 < timoxley> dominictarr is "from" still good? or is there an alternative?
10:06 < dominictarr> so, you can pipe stream1 and streams2, but with pull streams you need to use a converter to pipe it to node stremas
10:07 < dominictarr> timoxley: sure, I never found that I needed it much, though.
10:07 < jesusabdullah> okay that's kind of weird dominictarr why can't you pile a pull stream to a node stream
10:08 < dominictarr> just because adding the feature detection, etc, would make it ugly and complicated.
10:08 < timoxley> dominictarr I just want to cache some data so each time someone connects to the server I don't have to go fetch it from the remote service again
10:08 < jesusabdullah> what's the "converter" ?
10:08 < dominictarr> stream-to-pull-stream, and pull-stream-to-stream
10:10 < dominictarr> jesusabdullah: so, a pull stream is very simple, and optimized for "object" streams
10:11 < jesusabdullah> huh
10:11 < dominictarr> you have a readable stream, which is just an async function that you call repeatedly
10:11 < dominictarr> and it calls back with each chunk
10:13 < dominictarr> function values (array) { var i = 0; return function (abort, cb) { if(i < array.length) cb(null, array[i++]); else cb(true) } }
10:13 < dominictarr> that is a valid readable stream that reads an array!
10:15 < jesusabdullah> I'll allow it
10:15 < dominictarr> and then instead of a writable stream,
10:15 < dominictarr> you have a READER stream
10:15 < dominictarr> that is also just a function
10:16 < jesusabdullah> uhuh
10:16 < dominictarr> function logger (read) { read(null, function next (end, data) { if(end) return; console.log(data); read(null, next) }}
10:16 < dominictarr> a function that calls a read function repeatedly, until it cb(truthy)
10:17 < jesusabdullah> whose using this in the wild right now?
10:17 < dominictarr> (end and error are both things that end a stream)
10:17 < dominictarr> I'm using it heaps
10:17 < dominictarr> raynos
10:17 < dominictarr> creationix is using something very similar
10:17 < jesusabdullah> hmm
10:18 < dominictarr> some of my level modules use it, so people who use that
10:18 < dominictarr> one other person published 2 modules with it.
10:18 < jesusabdullah> cool
10:19 < timoxley> dominictarr you should blog on it
10:19 < timoxley> pull streams
10:20 < dominictarr> was just thinking about that at breakfast, actually.
10:21 < dominictarr> jesusabdullah: and so a through stream is simple too,
10:22 < substack> There are so many leveldb libs now. Is there an easy thing for just storing data and subscribing to updates?
10:22 < jesusabdullah> dominictarr: yeah I bet
10:22 < dominictarr> substack: level + level-sublevel
10:22 < dominictarr> then db.post(listener)
10:22 < substack> ok
10:26 < dominictarr> jesusabdullah: a through stream is also just a function
10:26 < dominictarr> but, it's like a reader stream that returns a readable stream
10:27 < dominictarr> function through (read) { return function (abort, cb) { read(abort, cb) } }
10:27 < dominictarr> then can pipe them like this
10:28 < dominictarr> logger(through(values([1, 2, 3])))
10:29 < dominictarr> now, streams1 was pretty simple. but I'd never be able to explain it by typing the code into irc...
10:31 < dominictarr> substack: can you publish the new baudio on npm?
10:31 < dominictarr> it seems to be out of date
10:31 < dominictarr> oh, hang on
10:37 < substack> the new?
10:53 < dominictarr> okay, I got it working...
10:53 < dominictarr> but my old stuff is now playing half speed
10:56 < substack> how old?
10:57 < dominictarr> oh, figured it out.
10:57 < dominictarr> was playing sounds for two channels in one channel
11:15 < dominictarr> substack: did you see this? http://www.youtube.com/watch?v=NnvynOyZI-Q
11:26 < dominictarr> jjjjohnn1y: webaudio is not on github!
14:04 < ralphtheninja> dominictarr: http://radar.oreilly.com/2013/05/bitcoin-is-a-money-platform-with-many-apis.html
14:07 < dominictarr> good article
14:08 < ralphtheninja> yup, by one of the guys in lets talk bitcoin
14:33 < dominictarr> substack: http://mashable.com/2013/05/24/3d-printed-ear-princeton/#:eyJzIjoiZyIsImkiOiIxMTU5Mzg2MTQwMTg4NzI4Mzg4MzgifQ
14:33 < dominictarr> bionic ear that lets you hear radio
16:37 < Raynos> Dominictarr: pong
16:37 < dominictarr> yo
16:38 < isaacs> substack: so, it seems like st's semantics around the url mounting is a bit different from ecstatic's
16:39 < dominictarr> Raynos: I figured out how to do pull stream with multiple errors
16:39 < isaacs> substack: specificlaly st(__dirname+'/static') is not equal to st({path:__dirname+'/static',url:''})
16:40 < isaacs> substack: lmk when you become online and waking.  i'm not opposed to changing the default to be more intuitive, but wanna make sure i grok what you're expecting it to do.
16:40 < dominictarr> you just make the error a stream of errors.
16:41 < mbalho> isaacs: ecstatic (and github.coms gh-pages http server) both have defaults, like '/' defaults to index.html and '/index' if 404 will try /index.html (you can specify the default extension to try on 404)
16:42 < dominictarr> which is also very similar to how node resolves .js files
16:42 < dominictarr> back later
16:57 < jjjjohnn1y> dominictarr: use https://npmjs.org/package/jsynth
16:59 < jjjjohnn1y> dominictarr: i've been waiting for advanced attachable ears
17:04 < jjjjohnn1y> dominictarr: http://secret.synth.fm/
17:06 < jez0990> jjjjohnn1y: you seen this before http://synth.bitsnbites.eu/ ?
17:06 < jez0990> and what are your thoughts about loading in .wav samples? how does that fit into your vision?
17:08 < jjjjohnn1y> jez0990: pretty sweet
17:08 < jjjjohnn1y> jez0990: i have a module for loading files into web audio https://npmjs.org/package/jsynth-file-sample
17:10 < jjjjohnn1y> it is slow in the b2a conversion, but its only meant for small samples, and I havent optimized it yet
17:10 < jez0990> jjjjohnn1y: awesome :)
17:10 < jjjjohnn1y> https://github.com/nhq/jsynth-file-sample
17:11 < jjjjohnn1y> theres the repo
17:11 < jjjjohnn1y> its tiny
17:11 < jjjjohnn1y> https://github.com/NHQ/jsynth-file-sample/blob/master/index.js
17:11 < jjjjohnn1y> loading waves with xhr as ArrayBuffers is even more straightforward
17:11 < jjjjohnn1y> just cut the base64 part out
17:12 < jjjjohnn1y> jez0990: try this out https://gist.github.com/NHQ/5610708
17:12 < Raynos> dominictarr: show me
17:12 < Raynos> show it me now
17:13 < jjjjohnn1y> the next update to the dsp live coder at secret.synth.com will keep yr compile diffs so you can go back, plus many more cool things
17:14 < jjjjohnn1y> and that is only one "synth" of many about to come through there
17:15 < jjjjohnn1y> by the way, if anybody wants to get a jump on making synthesizers, you will be able to distribute / integrate them with the synth.fm music playing platypus
17:15 < jjjjohnn1y> ie sell them app store like
17:15 < jjjjohnn1y> just use use https://github.com/nhq/jsynth
17:15 < jjjjohnn1y> as yr base
17:16 < jjjjohnn1y> or whatever
17:16 < jjjjohnn1y> if it can connect and / or recieve connections a la the web audio api, that is all that  matters
17:16 < jez0990> jjjjohnn1y: the bells are great!
17:17 < jjjjohnn1y> THX ^_^
17:17 < LOUDBOT> BITCHES DON'T KNOW 'BOUT MY CYTOKINE STORMS
17:17 < jjjjohnn1y> YR MOM DO THO
17:17 < LOUDBOT> I KNOW, LET'S HAVE THE REMNANT OF HUMANITY GO TO THEIR CIVILIZATION'S REBIRTH ON THE CONTINENT WHERE HUMANITY WAS BORN, AT AN APPROPRIATELY NAMED LOCATION
17:22 < jjjjohnn1y> jez0990: the constants on line 15 do a lot
17:22 < jjjjohnn1y> you can change them for effect
17:22 < jjjjohnn1y> recompiling repeatedly has a cool effect
17:25 < jjjjohnn1y> i made this when I hacked that algoritmo https://soundcloud.com/the-pipes-of-unix/gaussian-one-way-2
17:28 < jjjjohnn1y> at 3:55 my lady says "i love you, but you have a long way to go before kraftwerk"
17:29 < mbalho> lol
17:31 < jjjjohnn1y> i like the long way
17:40 < dominictarr> Raynos: I'm not gonna implement it unless you can give me a real-world example that actually warrants it.
17:42 < Raynos> dominictarr: oh I see. I have none
17:42 < dominictarr> if we ever come across one, we can use that approach though
17:48 < dominictarr> jjjjohnn1y: jsynth demo doesn't work
17:49 < dominictarr> HUP HUP GUP
17:49 < LOUDBOT> THE ONLY SHIT I REMEMBER IS THE SHIT THAT CAME OUT OF MY ASS A FEW HOURS AGO
17:49 < dominictarr> Error: Cannot find module 'brfs'
17:49 < dominictarr> npm install brfs
17:49 < dominictarr> opa
17:49 < dominictarr> Server listening at http://localhost:11001
17:49 < dominictarr> HUP HUP GUP
17:49 < LOUDBOT> ALL EVENTS POSSIBLE ARE EQUALLY LIKELY TO OCCUR
17:49 < dominictarr> Error: module "./jsynth" not found from "/Users/dominictarr/c/jsynth/entry.js"
18:17 < isaacs> mbalho: right, so in ecstatic, if you don't specify a url folder, it mounts on /?
18:18 < mbalho> isaacs: i dunno what the url option does, all i know is that ecstatic will run a static file server from the directory you give
18:18 < isaacs> mbalho: i mean:  ecstatic('/static')(req, res)
18:18 < isaacs> mbalho: if i request http://localhost/foo
18:18 < isaacs> mbalho: what gets loaded?
18:18 < isaacs> mbalho: ./static/foo?
18:19 < isaacs> mbalho: what if i do http://localhost/static/foo?
18:19 < isaacs> mbalho: will that look in ./static/static/foo?
18:19 < mbalho> yea
18:19 < isaacs> i see.
18:19 < isaacs> so yeah, in st terms, the default "url" param is / rather than "path to static folders, minus cwd"
18:20 < isaacs> that's strictly simpler.  i like it.
18:20 < mbalho> yea
18:20 < isaacs> but changing it requires updating some of my stuff, and is a potentially surprising breaking change.
18:21 < mbalho> the way st works seems liek it would confuse me every once in a while
18:21 < isaacs> mbalho: it's good when you have a ./static file that's ./static on the server.
18:22 < mbalho> i guess i dont expect urls and file system trees to match up
18:22 < mbalho> isaacs: are you in florida?
18:24 < mbalho> isaacs: also how do i get the path to the node core .js files on my system, the ones that `node` uses
18:34 < guybrush_> hey isaacs regarding st it doesnt parse the dot-arg properly https://github.com/isaacs/st/pull/18
18:38 < dominictarr> ralphtheninja: so, I'm guessing that the bitcoin server guy is normally a c programmer
18:46 < isaacs> mbalho: no
18:46 < isaacs> mbalho: those files are not on your system.
18:46 < isaacs> mbalho: they're inside of node
18:47 < dominictarr> it's so disapointing to see some one use javascript to write C.
18:48 < dominictarr> this is a classic example: https://github.com/bitcoinjs/bitcoinjs-server/blob/master/lib/storage.js#L12-L51
18:48 < mbalho> isaacs: oh!
18:48 < mbalho> isaacs: i got an error like 'at Object.exports.resolve (path.js:313:15)' and was like NEED PATH
18:48 < dominictarr> could just be require('./db/''+storageProtocol+'/storage')
18:49 < isaacs> mbalho: it's at process.binding('natives').path
18:49 < isaacs> mbalho: that's where the code lives.
18:49 < isaacs> mbalho: once it's compiled.
18:49 < isaacs> mbalho: you can edit it in the node source code lib/ folder.
18:49 < isaacs> mbalho: then recompile and see your changes.
18:54 < chrisdickinson> dominictarr: or an object mapping!
18:54 < dominictarr> indeed.
18:54 < ralphtheninja> dominictarr: who do you mean?
18:54 < chrisdickinson> i suppose require'ing those storages has side effects
18:54 < ralphtheninja> aah ok
18:54 < chrisdickinson> which is kind of sad
18:55 < chrisdickinson> otherwise i'd say just require 'em all at the top
18:55 < chrisdickinson> then map
18:55 < dominictarr> well, I'm assuming that it's mostly written by one guy
18:55 < ralphtheninja> yeah it is
18:55 < ralphtheninja> mostly
18:55 < dominictarr> best is each storage thing is an outside module
18:57 < ralphtheninja> dominictarr: https://github.com/spesmilo/libbitcoin
18:58 < ralphtheninja> that's amir taakis async c++ lib
18:58 < isaacs> mbalho: are you in florida?
18:58 < dominictarr> ralphtheninja: are you suggesting it's a direct 1:1 port?
18:59 < ralphtheninja> that what is a direct port of what? :)
19:00 < ralphtheninja> I saw amirs talk about async and realized he basically made his own node to get an asyncronous bitcoin implementation
19:01 < dominictarr> ralphtheninja: oh, so this is different to the satoshi one?
19:01 < ralphtheninja> I think the best way to get a node version of bitcoin is to start with one simple module and build ontop of that
19:01 < ralphtheninja> yeah that's another implementation of the bitcoin protocol
19:02 < dominictarr> aha, but everyone uses amir's?
19:03 < dominictarr> there are other silly things too, like this: https://github.com/bitcoinjs/bitcoinjs-server/blob/master/lib/db/levelup/storage.js#L18-L37
19:03 < dominictarr> when you can just have Block.prototype.toJSON
19:03 < dominictarr> and then it gets used once, instead of c/p into every storage adapter
19:05 < ralphtheninja> nope, not everyone uses amirs .. bitcoind/bitcoin-qt is the reference implementation that gavin andresen et al codes
19:07 < dominictarr> this one? https://github.com/bitcoin/bitcoin
19:07 < ralphtheninja> I was thinking that you could build a small core that basically just talks to other peers and stores the blockchain and then build modules for each functionality in the protocol
19:07 < ralphtheninja> yeah that's the one
19:07 < ralphtheninja> but it's a shitload of work :)
19:08 < dominictarr> you could probably get a long way by just tiding up bitcoinjs-server
19:09 < dominictarr> plus, if that dude learns to write js properly, then it's a double win
19:10 < ralphtheninja> aye, or start from scratch and pick out the good parts from it
19:16 < jjjjohnn1y> dominictarr: lol HUP HUP GUP should mean its working, but I thought I took that out
19:16 < dominictarr> sure, but then you are working in parallel, instead of together
19:16 < dominictarr> maybe you havn't published your latest version?
19:17 < ralphtheninja> aye, you're right
19:18 < jjjjohnn1y> i am an embarassement to npm
19:21 < dominictarr> and none of the examples are node.on('trx_to_me', ...)
19:22 < jjjjohnn1y> ok i fixed the entry file and pushed it
19:23 < jjjjohnn1y> example should work
19:26 < dominictarr> ralphtheninja: looks like the core would be Block, Transaction, Script, and ScriptInterpreter
19:28 < jjjjohnn1y> ralphtheninja: dominictarr are we gonna pay ourselved with distributed client side bitcoin mining or what?
19:28 < dominictarr> ralphtheninja: what about a struct.js lib, that let you transform c style structs to js objects and back?
19:29 < dominictarr> jjjjohnn1y: nah, gonna get everyone to fund open source with bitcoins
19:33 < jjjjohnn1y> dominictarr: the people who need ot be open funding open source are not not internet technology people, and probably won't go near bitcoin yet
19:33 < jjjjohnn1y> open source needs to be funded by non programmers, by particular industries or niches
19:33 < jjjjohnn1y> by the users
19:34 < dominictarr> hmm, that is a fair point.
19:34 < ralphtheninja> jxson: why funded by non programmers?
19:34 < ralphtheninja> jxson: sorry meant jjjjohnn1y
19:34 < dominictarr> my reasoning though, is that credit cards are horrible
19:34 < jjjjohnn1y> true
19:34 < dominictarr> but you could make a bitcoin module that just let you do
19:34 < jjjjohnn1y> dwolla looks neat
19:35 < dominictarr> bitcoins.on('pay_me', function (amt, bal) { this.pay(jjjohnny, 1) })
19:35 < dominictarr> that easy
19:35 < jjjjohnn1y> but i dont really care if the capital system has to get its cut so I can fund my cuts at the capital system
19:35 < ralphtheninja> jjjjohnn1y: bitcoin is still very experimental and lacks infrastructure for non internet technology people, but that will change
19:36 < dominictarr> also, the technology people who are into bitcoin need to fund bitcoin development
19:36 < jjjjohnn1y> ralphtheninja: yeah thats my point. it will be a while yet I predict, until you can get money from your uncle in bitcoin
19:36 < dominictarr> because bitcoin is opensource money
19:36 < jjjjohnn1y> unless greece or spain adopt it as their currency
19:36 < dominictarr> jjjjohnn1y: that is true
19:37 < guybrush_> haha bitcoins.on('pay_me',fn) i would use that
19:37 < dominictarr> but it's like node
19:37 < jjjjohnn1y> however, if you can make an open source app that is used by millions, and you have them mine coin for you in another process
19:37 < dominictarr> you could say: oh, but you can build a perfectly fine block with php
19:37 < dominictarr> blog, I mean
19:38 < jjjjohnn1y> which is why I am always looking for an up to date implementation of the miner in JS.
19:38 < dominictarr> jjjjohnn1y: this is the sort of thing where you must be ahead of the curve.
19:38 < jjjjohnn1y> :(
19:39 < dominictarr> there is no point in waiting for some one else to write the miner, if you think that is a good plan.
19:39 < jjjjohnn1y> i am ahead of some curves, but not the crypto programming one
19:40 < jjjjohnn1y> its cool, i mean, this stuff is still a short future away.
19:40 < dominictarr> jjjjohnn1y: If I had more free time I'd seriously consider this http://www.matasano.com/articles/crypto-challenges/
19:41 < dominictarr> anyway, it's not about crypto per se
19:41 < dominictarr> it's about technology development patterns
19:41 < dominictarr> read innovators delemma
19:41 < jjjjohnn1y> i was going to say laziness
19:41 < jjjjohnn1y> dominictarr: i am pretty clever at waiting
19:42 < jjjjohnn1y> i call it patience
19:43 < jjjjohnn1y> i guess i should read that
19:43 < dominictarr> you can read it while you are waiting
19:49 < dominictarr> ralphtheninja: I figure that the basic stuff to handle the data should be one module
19:50 < ralphtheninja> gah there are so much code duplication
19:50 < dominictarr> because it could be useful to work with blocks etc on it's own
19:50 < ralphtheninja> and why have support for a million databases?
19:50 < dominictarr> indeed.
19:50 < dominictarr> when I see stuff like that, I'm like, why are you even using javascript?
19:50 < ralphtheninja> hehe
19:51 < dominictarr> just support one database, and hit the others with polyfils
19:51 < dominictarr> (naturally, that one database is levelup)
19:53 < ralphtheninja> they have support for both levelup and leveldown
19:53 < ralphtheninja> ffs
20:03 < ralphtheninja> dominictarr: is there any advantage to use leveldown instead of levelup?
20:04 < dominictarr> mainly, it's a disadvantage
20:04 < dominictarr> maybe you could argue it's slightly more performant
20:04 < ralphtheninja> nods, I know he's all about performance
20:04 < dominictarr> but I don't think that is a bottlekneck for this application
20:04 < ralphtheninja> what are the disadvantages? gonna try lobby for levelup
20:05 < dominictarr> well, with levelup, we can hook in all the levelup modules
20:05 < dominictarr> that is the biggest thing
20:05 < ralphtheninja> aah of course
20:05 < dominictarr> make it easy to work with the data
20:06 < dominictarr> which is what I really want.
20:07 < ralphtheninja> hmm so you could in theory export the levelup db from bitcoinjs-server and apply some level-* to it
20:08 < dominictarr> yeah!
20:08 < dominictarr> although, running them in the same process
20:08 < dominictarr> or, maybe adding some extensions
20:08 < dominictarr> and then connecting the app to it with multilevel
20:13 < ralphtheninja> dominictarr: multilevel in itself is a good argument for picking levelup
20:13 < ralphtheninja> so you could have a bitcoin node running and serve stuff over shoe or whatever
20:14 < dominictarr> exactly
20:14 < dominictarr> and the level-* community
20:14 < ralphtheninja> keep the bitcoin node simple and build stuff ontop of it via multilevel instead
20:14 < ralphtheninja> nods
20:14 < dominictarr> there could also be a btc-* community
20:14 < ralphtheninja> can you apply level-* on the other end of multilevel? like on the client side?
20:21 < dominictarr> some parts you can, but as a rule no.
20:22 < dominictarr> you need to have direct access to the database for anything that uses prehooks to work properly.
20:46 < defunctzombie> substack: what is this sudoroom thing?
20:47 < substack> defunctzombie: east bay hackerspace
20:47 < defunctzombie> huh
20:48 < mbalho> east bay: a region of the san francisco bay area located on the east side of the bay
20:48 < mbalho> hackerspace: a place for hackers to hang out and work on projects
20:49 < defunctzombie> thank you
20:50 < dominictarr> defunctzombie: what do you do to integrate into bitcoin stuff? what modules do you use?
20:50 < defunctzombie> dominictarr: depends on what you need to integrate with and how
20:50 < defunctzombie> dominictarr: https://github.com/bitfloor/node-bitcoin
20:51 < defunctzombie> I use that to talk to the bitcoind client when I don't need to many crazy custom things
20:51 < defunctzombie> dominictarr: https://github.com/bitfloor/bitcoinjs-lib
20:51 < defunctzombie> I use that if I want to do some address/custom related things without the whole client or blockchain
20:52 < dominictarr> right, ralphtheninja and I had just been looking at the more recent version of that lib bitcoinjs-server
20:53 < dominictarr> very disapointed at how unmodular it was :(
20:53 < defunctzombie> yea
20:53 < defunctzombie> I started to make it more modular
20:53 < defunctzombie> thus I pointed you at my fork
20:54 < dominictarr> yes, I can trust you would do a good job of that.
20:55 < dominictarr> there is a long way bitcoinjs-server needs to come before it's stackvm compatible
20:55 < defunctzombie> yes
20:55 < defunctzombie> I haven't even touched the server stuff
20:55 < defunctzombie> and the -lib stuff has things that need to be separate libs and other parts that should just be "examples" as they are really too high level
20:56 < defunctzombie> stefan (guy who started the project) is now working on ripple
20:56 < defunctzombie> so this project doesn't get much love
20:56 < ralphtheninja> oh my
21:06 < dominictarr> he works at ripple?
21:07 < dominictarr> defunctzombie: but how did you import the bitcoin blockchain?
21:07 < defunctzombie> dominictarr: ?
21:08 < dominictarr> oh, you didn't need to
21:08 < defunctzombie> depends what you want to do and what you are talking about :)
21:12 < defunctzombie> anyone know anything about boost.vc ? I am thinking about applying for their summer "class" to work on courseoff stuff
22:27 < jesusabdullah> dominictarr: pull streams remind me a little bit of python iterators
22:27 < jesusabdullah> dominictarr: kind of
22:29 < dominictarr> is that a good thing?
22:29 < dominictarr> anyway, that is what I mean when I say they are all the same abstraction.
22:33 < jesusabdullah> dominictarr: yeah, it kind of is
22:34 < jesusabdullah> dominictarr: because it's "lazy" the same way pull-streams are, in that it only has to calculate the next value when something pulls on it
22:35 < dominictarr> yeah, turns out that is super useful
22:35 < jesusabdullah> right, that's the useful part of python iterators
22:35 < dominictarr> I was reluctant to leave classic-streams at first, but eventually raynos showed be the light
22:38 < substack> if I just keep using through will I get all the new-fangled benefits without updating my code?
22:39 < dominictarr> in some cases it's easy to drop in through
22:40 < dominictarr> if you only do this.queue(…) that works
22:40 < dominictarr> with pull-through
22:40 < dominictarr> but if you do t = through()
22:40 < dominictarr> t.queue(...)
22:41 < dominictarr> that doesn't work well, because the way that pull-streams are functions, not objects.
22:41 < dominictarr> but, it's not really a big deal, because pull-streams are very simple
23:05 < jesusabdullah> https://github.com/joyent/node/issues/5596 hehe
23:06 < jesusabdullah> waiting for the "y ur using writeFileSync??" "does it matter there is still a perf problem here"
23:10 < dominictarr> this guy has figured out enough, he could make a pull request
23:12 < AvianFlu> jesusabdullah: there's a lot of lulz in core issues quite a bit of the time
23:12 < AvianFlu> did you see the one where the dude made like 40 lines of libuv changes in node's deps/libuv folder?
23:12 < AvianFlu> I saw that a few minutes ago and was deeply amused
23:13 < jesusabdullah> yeah AvianFlu I Actually Follow node
23:13 < jesusabdullah> AvianFlu: did not actually see the libuv changes one
23:13 < jesusabdullah> where's that? XD
23:13 < AvianFlu> I'll link
23:13 < AvianFlu> I've spent a lot of today reading over node and libuv issues
23:13 < AvianFlu> https://github.com/joyent/node/pull/5595
23:14 < AvianFlu> also bonus points cause it's one big commit that touches like 6 different files
23:14 < AvianFlu> OH MAN
23:14 < AvianFlu> I DIDN'T LOOK AT HIS FIXTURE UNTIL JUST NOW
23:14 < LOUDBOT> CAN I SCRAP THE SYSTEM AND START OVER!
23:14 < AvianFlu> that's kinda priceless by itself
23:14 < defunctzombie> well, to be fair all the code is in the one repo
23:15 < AvianFlu> yeah it's true
23:15 < defunctzombie> so from the standpoint of a user
23:15 < defunctzombie> they fixed it in the project
23:15 < defunctzombie> this is why you don't copy the deps to your project unless you plan to maintain a separate "fork" of it
23:15 < jesusabdullah> AvianFlu: lolwut all the "fixes" are pure libuv
23:16 < AvianFlu> defunctzombie: static linking like this is an exception in my mind
23:16 < AvianFlu> node bundles that stuff for simplicity
23:16 < defunctzombie> yea
23:16 < AvianFlu> jesusabdullah: also yes lolz
23:16 < defunctzombie> there are never any good answers
23:16 < defunctzombie> people do what they are familiar with
23:16 < AvianFlu> this guy's ultimate point is probably a good one, about the windows stdio stuff
23:16 < AvianFlu> it's just kinda lulz
23:16 < jesusabdullah> yeah
23:16 < defunctzombie> in this case I would have favored github subrepo or whatever, but doesn't matter
23:16 < AvianFlu> and like BRO USE A LOOP IN THAT FIXTURE PLEASE
23:17 < defunctzombie> yea
23:17 < AvianFlu> right
23:17 < defunctzombie> that was funny
23:17 < jesusabdullah> defunctzombie: git submodules brah
23:17 < defunctzombie> yea.. that one
23:17 < defunctzombie> clearly I never use it
23:17 < AvianFlu> we use submodules when we take libuv as a static dep, but it still ends up in a deps/ folder
23:17 < defunctzombie> yea
23:17 < AvianFlu> so it's not really that different to me
23:18 < defunctzombie> isaacs: one thing that trumps namespaces for me is some sort of "hash" on what I expect to be installed via npm
23:18 < isaacs> hash?
23:18 < isaacs> defunctzombie: like a checksum hash?
23:18 < defunctzombie> yea
23:18 < defunctzombie> of the downloaded content
23:19 < isaacs> defunctzombie: you know that npm has this already, right?
23:19 < defunctzombie> ?
23:19 < isaacs> defunctzombie: but it's only used for in-transit errors, because legacy codebase
23:19 < isaacs> defunctzombie: ie, not for locking down contents in a shrinkwrap
23:19 < isaacs> defunctzombie: but that IS hte plan
23:19 < defunctzombie> right
23:19 < defunctzombie> that is what I am talking about
23:19 < isaacs> right
23:19 < defunctzombie> when I list a dep v#.#.#
23:19 < defunctzombie> I really want to say a specific hash as well
23:19 < defunctzombie> or whatnot
23:20 < isaacs> well, you can just install it as dep@x.y.z and then do `npm shrinkwrap` and it'll lock down the hash
23:20 < isaacs> and if that chnages, then the install fails.
23:20 < isaacs> to track force publishes
23:20 < defunctzombie> ah
23:20 < defunctzombie> didn't know that
23:21 < isaacs> defunctzombie: well, it's vaporware for now :)
23:21 < isaacs> defunctzombie: like i said.
23:21 < isaacs> defunctzombie: because legacy shit code.
23:21 < isaacs> defunctzombie: but that's an explicit goal of the forthcoming rewrite
23:21 < defunctzombie> heh
23:21 < defunctzombie> I always found it weird that shrinkwarp was separate
23:21 < substack> whoa https://github.com/facebook/react/blob/master/package.json#L41
23:21 < defunctzombie> to me the whole notion of a module manager is to lock down deps
23:22 < isaacs> substack: you're famous!
23:22  * isaacs still gets a kick out of this whole file.  "Facebook has a package.json!  squeee!"
23:22 < jesusabdullah> haha nice
23:22 < defunctzombie> non pinned dependencies ...
23:22 < isaacs> defunctzombie: you're too dogmatic!
23:22 < defunctzombie> yea
23:23 < defunctzombie> I like preservation of history :)
23:23 < substack> isaacs: pretty much yeah
23:23 < jesusabdullah> http://facebook.github.io/react/docs/syntax.html wut
23:23 < defunctzombie> substack: you need some browserify stuff to avoid those build.sh files :)
23:23 < substack> it seems like every frontend build tool is written in node
23:24 < substack> defunctzombie: I like sh files
23:24 < substack> I can just as well put them in package.json scripts but meh
23:24 < defunctzombie> I meant more along the lines of nothing at all :)
23:24 < defunctzombie> should just happen when you launch server.js or whatever
23:24 < substack> I only do that for apps though
23:24 < defunctzombie> unless you are making a static site for github pages or something
23:24 < substack> I don't want to build the whole bundle when my server.js fires up because that's slow
23:25 < defunctzombie> "Writing JavaScript with XML syntax."
23:25 < defunctzombie> wow
23:25 < defunctzombie> well, make it faster :p
23:25 < substack> and if my server crashes and comes back I don't want it to hang while the bundle recompiles
23:25 < substack> working on that
23:25 < defunctzombie> I have it rebuild all the time, never causes much problems
23:25 < defunctzombie> by the time I refresh the webpage it is good to go
23:26 < substack> isaacs: use of browserify is just an artifact of npm "winning"
23:26 < defunctzombie> +1
23:27 < isaacs> substack: yep
23:27 < isaacs> substack: well, not JUST an artifact.
23:27 < isaacs> substack: browserify is *helping* npm win
23:27 < isaacs> substack: as npm wins, browserify gets more useful, and vice versa.
23:28  * isaacs feeling all symbiotic
23:28 < jesusabdullah> gross
23:28 < substack> virtuous cycles!
23:28 < defunctzombie> hahaha
23:28 < substack> npm is the kind of thing where network effects dominate
23:28 < defunctzombie> complementary
23:28 < substack> that's why I think all these little upstart competitors are so silly
23:28 < substack> like bower, jam, et all
23:29 < substack> if you publish to a smaller repository your options for dependencies are limited
23:29 < defunctzombie> I personally like browserify cause it works the best with my workflow
23:29 < defunctzombie> I am already using npm
23:29 < defunctzombie> so why would I use anything else?
23:30 < defunctzombie> isaacs: idea, apt-get repo like stacking of npm deps
23:30 < jesusabdullah> because component
23:31 < defunctzombie> isaacs: so instead of running a full clone of npm or whatnot, I can give it a list of priority check places
23:31 < isaacs> defunctzombie: yeah
23:31 < isaacs> defunctzombie: something like that is planned, but not exactly that
23:31 < substack> nice
23:31 < defunctzombie> this could also be the thing that handles all the github stuff, etc
23:31 < defunctzombie> cause you can just make "simulated" repo providers that do all the github passthrough, etc
23:32 < defunctzombie> all very hand wavey but could be interesting for those who want some level of isolated control (or maybe a company deployment setting)
23:35 < substack> isaacs: oh also, the binary dists of node for linux are really crappy
23:35 < substack> there's no `make install`
23:36 < substack> I want a dist of node that ships with nave
23:36 < substack> so you can just bootstrap into getting whatever versions you need
23:38 < defunctzombie> substack: I just use nvm
23:38 < isaacs> substack: why not just use nave, then?
23:39 < isaacs> substack: it's just a bash script, put it wherever
23:39 < substack> isaacs: because you need to have node and npm already installed
23:39 < isaacs> substack: nuh uh
23:39 < substack> oh wait...
23:39 < substack> !!
23:39 < substack> didn't know this
23:39 < substack> there should be a dedicated website explaining how to do this
23:39 < isaacs> substack: wget https://raw.github.com/isaacs/nave/master/nave.sh
23:39 < isaacs> substack: or curl https://raw.github.com/isaacs/nave/master/nave.sh > /usr/local/bin/nave
23:39 < isaacs> or whatever.
23:40 < substack> that's pretty sweet
23:40 < isaacs> substack: i made a dedicated website for you: https://github.com/isaacs/nave#installation
23:40 < substack> hooray!
23:40 < substack> I just need to update my mental firmware to take this into account
23:41 < defunctzombie> isaacs: how is nave different from nvm?
23:41 < isaacs> :D
23:41 < isaacs> defunctzombie: nave is a shell script.  nvm is a shell function.
23:41 < isaacs> defunctzombie: nave doesn't require you to source anything.
23:41 < isaacs> defunctzombie: and it leaves your parent env pristine
23:41 < defunctzombie> isaacs: subshell?
23:41 < isaacs> defunctzombie: it does this by entering a bash child process
23:41 < isaacs> yes.
23:41 < isaacs> subshell
23:41 < defunctzombie> ah
23:41 < defunctzombie> hm
23:42 < isaacs> though, you can use `nave usemain 0.10` or whateer to install to the default global location
23:42 < defunctzombie> so if you want to just have node available to a user you always have to use nave?
23:42 < isaacs> like /usr/local or whatever.
23:42 < defunctzombie> the nice thing about nvm is that by sourcing it
23:42 < defunctzombie> I can have a local node installed and always available to use
23:42 < defunctzombie> without /usr/local or such
23:42 < defunctzombie> but to each his own
23:45 < isaacs> defunctzombie: sure, so, do something like this in your bashrc: `[ "$NAVE" == "" ] && nave use 0.8`
23:46 < defunctzombie> isaacs: you should make it replace the current shell (methinks there is some way to do that)
23:46 < defunctzombie> I will remember nave for my next deployments and maybe give it a try
23:46 < defunctzombie> too bad digitalocean snapshots can't be shared
23:46 < defunctzombie> otherwise would be cool to have a node ready one
23:47 < defunctzombie> for people to experiment with
--- Log closed Thu May 30 00:00:31 2013