--- Log opened Thu Jan 31 00:00:28 2013
--- Day changed Thu Jan 31 2013
00:00 < substack> is it easy to shim that?
00:01 < substack> Raynos: looking at your browser field pull req I thought the browser field was an object mapping require paths to browser-specific files
00:01 < substack> doesn't seem as though your patch does that
00:06 < defunctzombie> substack: that is the more complex case https://gist.github.com/4339901
00:06 < defunctzombie> the simple case is similar to the browserify field and is easier to implement in current browserify
00:06 < defunctzombie> substack: shim what? engine.io?
00:06 < defunctzombie> assert?
00:11 < Raynos> defunctzombie: oh hi
00:11 < Raynos> defunctzombie: done parameter is bullshit. Use assert.end()
00:12 < defunctzombie> meh, ties assertions with the testing harness/framework meh
00:12 < Raynos> substack: I thought browser is the same as browserify
00:12 < Raynos> defunctzombie: the test API is bullshit sugar. The real api is a assert that outputs TAP with an end method
00:13 < defunctzombie> Raynos: browserify is a subset of the browser field
00:13 < Raynos> I see
00:13 < defunctzombie> in many cases (small modules) replacing main is enough
00:13 < defunctzombie> sometimes it is advantageous to do more
00:13 < defunctzombie> all these modules replacing main is what we want
00:13 < Raynos> defunctzombie: more is out of scope! OUT OF SCOPE
00:14 < defunctzombie> Raynos: I don't think it is out of scope
00:14 < defunctzombie> read the gist about why the more exists
00:14 < defunctzombie> there is a reason and it can be very helpful
00:15 < Raynos> defunctzombie: also `var test = function (name, cb)  { require("assert-tap").test(name, function (a) { cb(a, a.end) }) }`
00:15 < defunctzombie> nice
00:15 < Raynos> defunctzombie: In many cases, there is a large amount of code which is applicable to both client and server. If is easier to just replace some files instead of craeting a completely new entry point. To do this, just specify an object versus a single string.
00:15 < Raynos> Bullshit
00:16 < Raynos> if there is a large amount of code there is a large amount of modules
00:16 < Raynos> if you ahve many modules then you have many main's
00:16 < Raynos> problem solved
00:16 < defunctzombie> well, some people don't always make modules or will make modules
00:16 < defunctzombie> one example I had was with engine.io
00:16 < defunctzombie> and their flashget stuff or something
00:16 < Raynos> engine.io is bullshit
00:16 < defunctzombie> it was like one 3 line function that had to be different
00:16 < Raynos> they should fix it to be modular
00:17 < defunctzombie> a 3 line module for it is useless because it has no other reuse than inside engine.io
00:17 < defunctzombie> just because something is a separate module doesn't make it "modular"
00:17 < Raynos> no u
00:17 < defunctzombie> if it is only relevant to that single use in that single package
00:17 < defunctzombie> engine.io has some issues, but overall I like what it does :) and it does it quickly
00:17 < defunctzombie> maybe I will modularize it more
00:18 < defunctzombie> and remove the flash stuff
00:18 < defunctzombie> which no one cares about anymore anyway
00:18 < defunctzombie> I prefer engine io to sockjs because I can't fix coffeescript
00:18 < defunctzombie> and engine.io has faster bootup
00:20 < substack> is there a streaming wrapper for engine.io?
00:20 < substack> I like streams
00:20 < defunctzombie> substack: want me to make one?
00:20 < defunctzombie> it would be quite easy
00:21 < substack> do it!
00:21 < defunctzombie> ok
00:21 < defunctzombie> you just want it to expose the socket io as a stream? or do you want the shoe style api?
00:21 < defunctzombie> I can make something that looks like shoe on top of engine.io if you want
00:21 < CoverSlide> do it!
00:21 < substack> shoe api might be a good starting point but is by no means some sort of platonic ideal or anything
00:21 < defunctzombie> k
00:22 < defunctzombie> engine.io api is already very thin, just doesn't expose a "node stream"
00:23 < CoverSlide> well the main thing is converting message events to data events
00:24 < defunctzombie> yep
00:24 < defunctzombie> that is basically it
00:26 < substack> I'm getting a hankering to hack in browserify today
00:26 < defunctzombie> haha
00:26 < substack> but first I need to fix the queue bug in browserling
00:26 < defunctzombie> did you guys deploy https badges to testling?
00:26 < substack> not yet
00:26 < defunctzombie> :'(
00:27 < substack> timeout retries are working pretty good but there are some lingering issues still
00:27 < defunctzombie> I am gonna go eat.. I will need a name for this stream wrapper for engine.io
00:27 < defunctzombie> and will take suggestions
00:28 < substack> wheel is available
00:28 < substack> shoe::sockjs : wheel:engine.io
00:28 < substack> tire is also available
00:29 < CoverSlide> skate
00:29 < CoverSlide> oh engine nvm
00:29 < CoverSlide> i like tire
00:32 < defunctzombie> haha
00:40 < mbalho> substack: is it proper behavior for emit('syntaxError') on syntax errors but request.post({url: "http://localhost:8080", body: "var foo = require'util')"}, function(e,r,b) { console.log(b)
00:40 < mbalho> substack: AHH HIT PASTE
00:40 < mbalho> substack: meant to say but throw moduleError('Cannot find module'); when it cant find a module
00:41 < substack> I think that's what it does now yes
00:42 < substack> not necessarily ideal
00:42 < mbalho> substack: kewl just checking. i can check if the module is installed first with npm
00:50 < guybrush> holy cow im addicted http://labs.dinahmoe.com/plink/
00:50 < Raynos> substack: https://github.com/substack/node-parents can I make it polymorphic and make it work for DOMElement
00:50 < Raynos> parents(elem) -> all its parents in an array. parents(str) -> all the parents of the path in an array
00:51 < guybrush> had SUCH a great session with some random guys right now, incredible :D
00:53 < guybrush> but now my mouse-hand hurts lol
00:59 < substack> Raynos: it's just for paths, not for dom elements
00:59 < Raynos> it could be polymorphic!
00:59 < substack> handling dom elements should be a separate thing
00:59 < Raynos> agreed but the name parents is nice :3
00:59 < substack> polymorphic -> it should be conflated with other unnrelated concepts!
01:11 < chrisdickinson> Raynos: see npm.im/ancestors
01:12 < Raynos> chrisdickinson: why can't I find it when I do `npm search parents` :D
01:12 < chrisdickinson> because somehow the name parents was taken D:
01:12 < chrisdickinson> i can add it to the tags?
01:12 < Raynos> why you no keywords
01:12 < chrisdickinson> i did put in "parentNode", to my credit
01:13 < Raynos> o lol
01:13 < chrisdickinson> also, "parents"
01:13 < Raynos> it did show up :D
01:13 < Raynos> I just ignored it
01:13 < chrisdickinson> D`:
01:13 < Raynos> cause its not called parents xd
01:13 < Raynos> ok cool
01:14 < chrisdickinson> it's got a filter function so you can do the whole parents(el, function(x) { x.matchesSelector('#bloo') }) thing
01:14 < chrisdickinson> (or use cssauron-html, `parents(el, lang('#bloo'))`)
01:23 < Raynos> Yeah thats bullshit
01:23 < Raynos> I dont need that
01:23 < Raynos> I use it ( https://gist.github.com/f1eeacdaf1adb4107840 )
01:26 < mbalho> isaacs: programatically with npm is there a way to check if a module installed that doesnt throw an error if it isnt? read-installed returns a tree which i can probably traverse but i was hoping there was a simpler way
02:28 < defunctzombie> Raynos: substack: intake, wheel, radiator, sparkplug
02:34 < fotoverite> mbalho: you are a mad genius!
02:35 < mbalho> fotoverite: im gonna use this to make a voxeljs game editor
03:18 < chrisdickinson> Raynos: which part is bs?
05:59 < Raynos> chrisdickinson: filtering parents by QS
06:08 < sorensen> this channel just keeps getting bigger and bigger
06:37 < fotoverite> anyone here worked with css transitions?
06:37 < fotoverite> have a very weird error I'm trying to fix in chrome
07:26 < juliangruber> dominictarr: multilevel doesn't have events yet, but all the methods
07:29 < juliangruber> dominictarr:
07:40 < juliangruber> dominictarr: https://github.com/juliangruber/multilevel-http
09:17 < chrisdickinson> substack: did you see https://github.com/substack/ever/pull/5 ?
11:55 < elliottcable> substack, pkrumins ⑊ Er. Trying to use Testling-CI for the first time now, after I talked to you guys about it a couple weeks ago. However, I'm having no luck getting my simple example-code Mocha tests to run/pass.
11:55 < elliottcable> http://ci.testling.com/elliottcable/ConformingLikeALittleBitch
11:56 < elliottcable> Fails in every single browser, no useful output, saying there's zero tests and zero passing. Clicking “debug” simply shows me a white page in the browser in question.
11:56 < elliottcable> here's the test-file in question:
11:56 < elliottcable> https://github.com/elliottcable/ConformingLikeALittleBitch/blob/Master/test/getting_started.test.coffee
11:57 < elliottcable> I'm new to approximately ten different tools in play here (trying to learn to use the idiomatic, “traditional” Node software stack, and do it properly), so I'm not sure where the failing in my understanding is cropping up. This is an amalgamation of Mocha, Chai, Testling-CI, npm, and CoffeeScript (none of which I've used before).
15:44 < isaacs> mbalho: hm.  not sure.
16:26 < defunctzombie> isaacs: do I need to file an issue about that npm error for shorthand git repos and not existing in npm?
16:55 < isaacs> defunctzombie_zz: i think there's on ealready
17:13 < fotoverite> So who's the first to tear this MF down I wonder
17:13 < fotoverite> http://engineering.twitter.com/2013/01/introducing-flight-web-application.html?utm_source=dlvr.it&utm_medium=twitter
17:17 < AvianFlu> IT'S A STUPID PUN CAUSE THEIR LOGO IS A BIRD
17:17 < LOUDBOT> I WAS SMUGGLING THEM  THATS WHY THEY WERE IN MY PANTS OK
17:17 < fotoverite> And AvianFlu is a winner
17:17 < fotoverite> also you are a bird or a bird disease
17:17 < fotoverite> are you an avian who has the flue or the disease itself?
17:18 < AvianFlu> the disease
17:18 < AvianFlu> CAUSE I'M JUST THAT SICK AT PROGRAMMING
17:18 < LOUDBOT> I FEEL INCOMPLETE IF SHIT'S NOT WORKING
17:18 < fotoverite> *is scared of loudbot sometimes
17:19 < jesusabdullah> nice
17:19 < jesusabdullah> ugh can't concentrate tonight
17:20 < fotoverite> Just push through at least the internet has lost itself yet
17:28 < jesusabdullah> something like that XD
17:28 < ins0mnia> substack: How about adding a status field (registered/freed) to the underlying CRDT document in Seaport?
17:32 < jesusabdullah> lulz, yc startup offers free beer and fixies to new hires
17:32 < jesusabdullah> >_<
17:32 < fotoverite> Do they offer them to crush some code?
17:33 < jesusabdullah> http://jobs.amicushq.com/ judge for yourself hombre
17:33 < jesusabdullah> tbh I'd rather they literally gave me the cow
17:34 < jesusabdullah> as much of a white elephant as that is
17:36 < jesusabdullah> fotoverite: They *do* use ruby...
17:36 < fotoverite> Kiss of death
17:37 < fotoverite> Also My god what are the hours for the perks
17:37 < fotoverite> do you leave the office?
17:38 < jesusabdullah> no idea
17:41 < jesusabdullah> http://news.ycombinator.com/item?id=5145294 totally just discovered nodejs brah
17:44 < fotoverite> + And for lulz: A Minecraft mod/voxel.js project for devirtualizing virtualized servers. Basically a minecraft mod that allows you to control AWS instances by putting down/picking up blocks :-)
17:44 < fotoverite> That might be the dumbest thing ever
17:44 < fotoverite> we all know it should be heroku.
17:48 < jesusabdullah> I mean
17:49 < jesusabdullah> I would aim slightly lower and slightly more fun than that project
17:49 < jesusabdullah> that's more of a, "oh hey people like this voxelthing right?"
17:49 < fotoverite> yeah
17:49 < jesusabdullah> "WE SHOULD NAME DROP THE SHIT OUT OF THAT"
17:49 < LOUDBOT> LETS MAKE A CLIENT THAT INTERLACES ALL CHANNELS TOGETHER SUCH THAT YOU DON'T KNOW WHERE YOU ARE TALKING OR WHO IS WHERE
17:49 < jesusabdullah> YES
17:49 < fotoverite> The whole thing is name droping
17:50 < isaacs> Stream Freaks! Assemble!
17:51 < isaacs> Raynos, dominictarr!  I summon thee!
17:51 < isaacs> so, there are cases where we get _read(n,cb) called.
17:51 < isaacs> however, we don't have any data right now.
17:51 < isaacs> but! we might have data later.  so, if you want it later, then ask later.
17:51 < isaacs> and it's not EOF
17:51 < isaacs> currently, returning an empty buffer or null is interpreted as EOF.
18:01 < CoverSlide> I thought return false was the result in that scenario
18:14 < isaacs> CoverSlide: no, the return value of _read is not relevant
18:15 < CoverSlide> right, of _read
19:28 < Raynos> isaacs: oh hi
19:28 < Raynos> isaacs: Can't you just have _read logic be like "no data now. Ok ill wait and call you later"
19:29 < Raynos> isaacs: The way I see it your source is either pull or push
19:29 < Raynos> If pull then you can pull in _read and cb when you have it
19:29 < isaacs> Raynos: well, in this case, the src is pull
19:29 < Raynos> if push then _read = noop
19:29 < isaacs> if push then _read is resume
19:29 < Raynos> and you just stream.push(whatever) when you have it
19:29 < Raynos> BLARGH
19:29 < Raynos> I forgot about that
19:29 < isaacs> Raynos: you stream.push(whatever) || src.pause
19:29 < isaacs> Raynos: whatever, not the issue right now
19:30 < Raynos> isaacs: then _read(n, cb) -> never call cb
19:30 < isaacs> Raynos: i'm talking about a pull stream source.
19:30 < isaacs> Raynos: now state.reading = true
19:30 < isaacs> forever.
19:30 < Raynos> oh a pull stream source, well just pull in _read
19:30 < isaacs> right.
19:30 < isaacs> you pull, and get no data.
19:30 < isaacs> but, it's not EOF
19:30 < isaacs> it's just empty right now
19:30 < Raynos> isaacs: you should document what I'm supposed to do with _read in a push stream because I will literally do stream._read = source.resume
19:31 < Raynos> isaacs: oh then you pull again
19:31 < isaacs> Raynos: it's documented already.  look at teh docs on stream.push.  there's even examplecode.
19:31 < isaacs> Raynos: when do i pull again?
19:31 < Raynos> I see
19:31 < Raynos> whenever
19:31 < isaacs> right.  so... when whenever?
19:31 < isaacs> 10ms?
19:31 < Raynos> I actually expect pull sources to return [data, isEoF]
19:31 < Raynos> isaacs: upto the source implementation
19:31 < Raynos> it's very pull source specific
19:31 < isaacs> no pull sources return that
19:32 < isaacs> you mean cb(er, data, isEOF)?
19:32 < Raynos> not quite
19:32 < isaacs> why not just use data==null as the eof?
19:32 < Raynos> I mean if I'm reading from disk I'm going to get some bytes and maybe an eof
19:32 < Raynos> isaacs: i can your source is not a string and null is a valid result
19:32 < Raynos> but that's a bullshit edgecase
19:33 < Raynos> the point is if your underlying source returns [null, not_empty] then you have some very source specific logic of when to check for data again
19:33 < Raynos> I dont know of any sources that would do that
19:33 < Raynos> other then long polling a HTTP backend
19:33 < isaacs> Raynos: if you're reading from disk, you're going to get some bytes, or eof.
19:34 < isaacs> Raynos: if yor'e reading form openssl, you're going to get some bytes, or no bytes, or eof.
19:34 < Raynos> and in the long polling case if your connection is terminated with [null, not_empty] after the 30s timeout then you make an immediate long poll request again
19:34 < isaacs> Raynos: the disk is not the problem.
19:34 < isaacs> Raynos: again, different thing entirely.
19:35 < Raynos> ok so the question is what do you do when openssl returns no bytes
19:35 < Raynos> I would default to "dont call cb, try again later then call cb"
19:35 < isaacs> Raynos: now the reading flag stays set, and we think that we're waiting for a cb
19:36 < Raynos> isaacs: but you are waiting for the cb
19:36 < Raynos> because there is no data yet
19:36 < Raynos> as in _read tries again later
19:36 < Raynos> not _read gets called again later by Readable
19:36 < isaacs> i have no way of knowing when there will be data.  someone else will have to tell me when to check again later.
19:36 < Raynos> the _read implementation details does the retrying
19:36 < isaacs> so, the way that i'm proposing is this:
19:36 < Raynos> why should someone else tell you
19:36 < isaacs> new Buffer(0) = not eof
19:37 < isaacs> Raynos: because there's no point checking for enc bytes if you haven't written any new cleartext yet.
19:37 < Raynos> oh
19:37 < Raynos> there you go
19:37 < Raynos> its a duplex thing
19:37 < isaacs> it's a double-duplex!
19:37 < Raynos> and theres no point calling _read until someone else calls write
19:37 < isaacs> a quadplex!
19:37 < Raynos> ok so you have a very specific usecase here
19:37 < isaacs> another way to do this is to split it into two transform streams.
19:37 < Raynos> isaacs: I would prefer a _read(n, cb, empty) instead of Buffer(0)
19:37 < isaacs> so instead of an enc side and a clear side, we have a clear-to-enc side and a enc-to-clear side.
19:38 < isaacs> then the "cleartextstream" just proxies its reads and writes.
19:38 < isaacs> and we proxy the reads and writes on the other side to an actual socket.
19:39 < Raynos> THIS IS MADNESS
19:39 < LOUDBOT> TIME TO PUT ON SOME SHOES AND GET THE MAIL IN MY UNDERWEAR
19:42 < isaacs> nvm, the double transform is not workable in this case.
19:52 < Raynos> isaacs: give up on streams and build a complex FSM
20:01 < isaacs> hahah
20:01 < isaacs> it has to expose teh stream interface for https to use it
20:01 < isaacs> this is what tls.connect does
20:06 < substack> elliottcable: perhaps try not using quite so many new things at once
20:09 < substack> elliottcable: oh I see you got your tests to run at any rate, hooray!
20:10 < pkrumins> elliottcable: nice job!
20:47 < defunctzombie> substack: Raynos: https://github.com/shtylman/node-radiator
20:47 < defunctzombie> not sold on the API yet, but otherwise it works for some basic tests
20:47 < defunctzombie> need to check some of the stream hookup stuff still
20:47 < defunctzombie> it uses the browser field for the radiator package
20:48 < defunctzombie> and the engine.io and engine.io-client packages used are bundleable
22:17 < Raynos> defunctzombie: https://github.com/Raynos/engine.io-stream
22:18 < defunctzombie> Raynos: why you no share this earlier?
22:18 < Raynos> defunctzombie: why you no npm search engine stream
22:19 < Raynos> defunctzombie: your server implementation sucks and assumes one client
22:19 < defunctzombie> ?
22:19 < defunctzombie> one client of what
22:19 < Raynos> https://github.com/shtylman/node-radiator/blob/master/index.js#L25
22:19 < defunctzombie> Raynos: can this be bundled?
22:19 < Raynos> every socket that connects to your server
22:19 < Raynos> fails
22:19 < Raynos> defunctzombie: it can with browserify
22:19 < defunctzombie> Raynos: oops :)
22:20 < Raynos> defunctzombie: It can if you support the browserify field in node-script
22:20 < Raynos> in fact it doesnt matter
22:20 < Raynos> just require("engine.io-stream") on the client and require("engine.io-stream/server") on the server
22:20 < defunctzombie> I do, but I don't support (require()); bs
22:20 < defunctzombie> k, I will check it out!
22:20 < defunctzombie> awesome
22:21 < Raynos> defunctzombie: also https://github.com/Raynos/engine.io-client/commit/89201c18ea41cbe974a5d281db487ef9d8ab73b5
22:21 < defunctzombie> Raynos: yea, that is bullshit
22:21 < defunctzombie> I will fork and use my engine.io-client
22:21 < defunctzombie> that doesn't have this issue
22:21 < defunctzombie> but cool, thanks for pointing this out to me :)
22:24 < defunctzombie> Raynos: I patched engine.io to have normal requires (removing the lib-cov crap they have as well)
22:24 < defunctzombie> given that the 'ws' module supports the browser field
22:24 < defunctzombie> and I have xmlhttprequest that does too
22:24 < Raynos> defunctzombie: does xmlhttprequest support the browser field?
22:24 < Raynos> xd
22:24 < Raynos> I see
22:25 < defunctzombie> yea.. I have been trying
22:25 < Raynos> thats a different way to solve the problem
22:25 < defunctzombie> but the dude is unresponsive
22:25 < Raynos> I think the best way to solve it
22:25 < Raynos> is rewrite engine.io
22:25 < defunctzombie> haha
22:25 < Raynos> to not suck
22:25 < Raynos> the many balls
22:25 < defunctzombie> my latest patchset for bundling support is very small
22:25 < defunctzombie> once modules support browser field actually
22:25 < defunctzombie> just mostly updating the package.json to latest versions
22:28 < defunctzombie> Raynos: https://github.com/shtylman/engine.io-client/commits/v0.4.1-dz1
22:28 < defunctzombie> the only "real" commit is "use bundleable version of xmlhttprequest"
22:28 < defunctzombie> all the others should just be there in the first place
22:28 < defunctzombie> the require emitter-component is bs and they should just do what that commit does
22:28 < defunctzombie> same with all the others
22:29 < mbalho> chrisdickinson: i have some general feedback for browservefy -- i would like it more if you said 'browservefy foo.js -o bundle.js'
22:29 < chrisdickinson> mbalho: ?
22:29 < mbalho> chrisdickinson: where foo.js is your source code and bundle.js is what you put in your html
22:30 < defunctzombie> Raynos: if you use a "browser" field supporting browserify on that version it will work
22:30 < chrisdickinson> ah yeah
22:30 < chrisdickinson> aliases!
22:30 < mbalho> chrisdickinson: that works now?
22:30 < chrisdickinson> not yet
22:30 < chrisdickinson> but i think it's a good idea
22:30 < chrisdickinson> i was originally going to do browservefy foo.js:bundle.js
22:30 < chrisdickinson> but -o might be nicer
22:30 < Raynos> defunctzombie: make substack land the browser field :p
22:30 < mbalho> chrisdickinson: same syntax as browserify that way
22:30 < defunctzombie> haha
22:30 < chrisdickinson> +1
22:31 < chrisdickinson> i need to add "help"
22:31 < Raynos> defuntzombie: lol require("emitter-component") man those guys are trolls
22:31 < chrisdickinson> since it's growing useful options
22:31 < mbalho> yea
22:35 < defunctzombie> Raynos: yea
22:35 < defunctzombie> the bigger problem is they also require("emitter")
22:35 < defunctzombie> whic his installed via component
22:35 < mbalho> 963 byte module https://github.com/maxogden/element-class
22:35 < defunctzombie> so it is a total clusterfuck for someone figuring out the code
22:45 < Raynos> defunctzombie: I think they should either support component or npm
22:45 < Raynos> not both
22:54 < defunctzombie> haha
22:58 < defunctzombie> Raynos: reemit, is that really useful over just passing in a bound function?
22:58 < Raynos> its sugar
22:59 < Raynos> reemit(source, dest, ["error", "data", "end"])
22:59 < Raynos> reemit(source, dest, ["error", "data", "end", "readable", "finish", "drain"])
22:59 < defunctzombie> I see
22:59 < Raynos> fucking complex event emitters :P
22:59 < defunctzombie> hah
22:59 < defunctzombie> browserify server is a terrible dev dep
22:59 < defunctzombie> jesus
23:00 < defunctzombie> makes so much install all the time
23:00 < substack> servers?
23:01 < defunctzombie> browserify-server module
23:02 < defunctzombie> sorry substack, don't be worried :)
23:07 < defunctzombie> Raynos: what is the purpose of read-write-stream?
23:07 < defunctzombie> why not just handle the events?
23:07 < Raynos> defunctzombie: duplex vs transform
23:07 < Raynos> read-write-stream is a duplex base class
23:08 < defunctzombie> don't we have duplex-stream?
23:08 < defunctzombie> or something like that?
23:12 < defunctzombie> Raynos: the duplex module, isn't that a duplex stream?
23:12 < Raynos> i should call it duplex-stream
23:13 < Raynos> defunctzombie: yes it is :D
23:13 < Raynos> so is testem
23:13 < rvagg> isaacs: does node-tap have a `t.after()` or similar? like a `finally` block or a standard XUnit `tearDown`?
23:14 < Raynos> defunctzombie: dominictarr/duplex is a duplex stream (old stream)
23:14 < Raynos> defunctzombie: Raynos/duplexer is duplex(write, read) -> duplex stream (old stream)
23:14 < defunctzombie> wut
23:14 < Raynos> read-write-stream is a streams2 stream
23:14 < defunctzombie> your dependencies are fucked I can't use this
23:15 < Raynos> rvagg: it's called t. after is just another test case `test("teardown", teardown)`
23:15 < defunctzombie> read-write-stream depends on 'readable-stream': 'git://github.com/isaacs/readable-stream.git
23:15 < Raynos> defunctzombie: Why?
23:15 < defunctzombie> which is a floating thing
23:15 < Raynos> floating?
23:15 < defunctzombie> yes
23:15 < defunctzombie> depending on when I clone your code and npm install
23:15 < Raynos> then go fix them to not float
23:15 < defunctzombie> I will get different codebases
23:15 < Raynos> yes
23:15 < Raynos> expected behaviour
23:15 < defunctzombie> that is fucked up
23:15 < Raynos> no it's not
23:15 < defunctzombie> yea, it is
23:16 < defunctzombie> you are changing history
23:16 < Raynos> It means I always wnat whatever is on master on isaacs/readable-stream
23:16 < Raynos> its like `~`
23:16 < defunctzombie> then you want a lie
23:16 < defunctzombie> and I will never use your modules
23:16 < defunctzombie> no it is not like ~
23:16 < Raynos> ...
23:16 < Raynos> Ok
23:16 < defunctzombie> because your modules will break my code in a month
23:16 < defunctzombie> :D
23:16 < Raynos> its like `*` :D
23:16 < defunctzombie> yea, and '*' should never exist
23:16 < Raynos> except it means every commit ever
23:16 < Raynos> its convenient
23:16 < defunctzombie> ever ever ever
23:16 < Raynos> PR welcome :D
23:18 < Raynos> i have a bunch of git dependencies all over the place for my forks
23:21 < guybrush> defunctzombie: the thing is lots of people put semver dependencies in their package.json, and basically everything becomes floating :p
23:21 < guybrush> git-dependencies without #git-ref though are the hardcore-floating things
23:22 < Raynos> why
23:22 < Raynos> its #master
23:23 < Raynos> why is #master better then #some-branch
23:23 < guybrush> thats hardcore-floating thing
23:23 < guybrush> but i guess since you shouldnt role your deployment with npm anyway its all not so important in the end
23:24 < rvagg> Raynos: I need to be able to clean up temporary fixtures that won't make it to clean-up in case of test-failure
23:29 < defunctzombie> Raynos: I don't do #somebranch
23:29 < defunctzombie> I do #commit_id
23:29 < defunctzombie> many people are stupid when it comes to dependencies and just don't care about other developers
23:30 < Raynos> rvagg: If one test fails the next one still runs so its all good
23:30 < rvagg> Raynos: still misses the point
23:30 < substack> if I can get these browserling fixes rolled out today I want to spend some time on browserify patches
23:30 < Raynos> test("setup", setup) && test("thing", testThing) && test("teardown", teardown)
23:30 < Raynos> defunctzombie: publisher convenience ;)
23:31 < rvagg> Raynos: ah, I see what you mean, fair enough
23:31 < Raynos> i dont want to update 10 modules when I bump read-stream to 0.7 so ill do 0.6.10
23:31 < Raynos> fuck the fact its a new feature in a patch version
23:31 < rvagg> isaacs: would you consider a PR to add something like `t.after(function (done) { /* ... */; done() })` to node-tap?
23:33 < guybrush> defunctzombie: thats not stupid, i have lots of private stuff going on pointing to floating git-branches
23:34 < guybrush> i just want to fix one bug, and update a bunch of projects - without pushing new commits to the apps
23:35 < defunctzombie> guybrush: private is fine if you also don't care about your sanity and history
23:35 < defunctzombie> but if you publish libs
23:35 < guybrush> well
23:35 < defunctzombie> or modules for others to use
23:35 < defunctzombie> this is terrible
23:35 < guybrush> its sane :D
23:35 < defunctzombie> you tested with a specific version
23:35 < defunctzombie> it is not sane
23:35 < guybrush> oh boy it is :p
23:35 < defunctzombie> you just don't understand the problem
23:35 < chrisdickinson> defunctzombie: there are cases for *
23:35 < defunctzombie> there are not
23:35 < guybrush> well i really know what you want to say, but you dont know what i am doing here
23:36 < defunctzombie> there are NO cases for '*' in dependencies
23:36 < defunctzombie> guybrush: ;)
23:36 < chrisdickinson> if 3 modules all depend on another module, but don't care what version that module is, your code should peg that module and all of the 3 subordinate modules should use that
23:36 < defunctzombie> chrisdickinson: what you said is not true
23:36 < chrisdickinson> if they're each pegged, it's harder to get that to work with dedupe
23:36 < defunctzombie> you never "don't care what version"
23:37 < defunctzombie> even the developer tested against an exact version
23:37 < defunctzombie> and if you clone your code 1 year from now
23:37 < chrisdickinson> the modules don't care, you should -- the end user pegs the version that works
23:37 < defunctzombie> it will be a total shitshow
23:37 < defunctzombie> no
23:37 < defunctzombie> that is incorrect
23:37 < defunctzombie> a module's dependencies are NOT MY PROBLEM
23:37 < defunctzombie> they should not leak out to me
23:37 < defunctzombie> I expect your code to work by your documented api
23:38 < defunctzombie> and not some plugin system
23:38 < defunctzombie> if something is broken with your module, I don't care if the issue is your dependency
23:38 < defunctzombie> it was your module that broke
23:38 < defunctzombie> by using a dependency you accepted its bugs as well
23:38 < defunctzombie> that is how an end user views it btw :)
23:39 < defunctzombie> I expect to have a consistent copy of code when I clone it in a month to track down an issue
23:40 < defunctzombie> if I can't do that, then why the fuck did I version control in the first place?
23:40 < chrisdickinson> "i want to use cssauron-html, cssauron-falafel, and cssauron-glsl all at once. i add cssauron to deps at a pegged version, then add the subordinate libraries at pegged versions."
23:40 < chrisdickinson> "they all end up using the correct cssauron."
23:41 < guybrush> im using npm here for apps, that dont be required by anything else
23:41 < guybrush> pushing the dependencies for _endpoint_ apps
23:41 < guybrush> is lots of work
23:41 < guybrush> sure it can be done and would be more.... strict or what ever
23:41 < guybrush> but for me it just worked without writing even a single line :D
23:41 < guybrush> im running 20 apps and just update 1 package and run 1 command
23:41 < guybrush> so for me thats not stupid, but i see your point anyway
23:41 < guybrush> i think i am using npm here for a thing its not built for :) but really it works so well
23:41 < guybrush> otherwise i could just drop npm and use git-submodules :p
23:42 < defunctzombie> chrisdickinson: then you have peer dependencies
23:43 < defunctzombie> and you are assuming they will work across the version you installed
23:43 < defunctzombie> which may not be true
23:43 < defunctzombie> and if those are plugins then that is different
23:43 < chrisdickinson> not plugins, but specializations
23:43 < defunctzombie> guybrush: I use npm for apps too
23:43 < defunctzombie> chrisdickinson: then those need to pin to the version they were tested for
23:43 < chrisdickinson> essentially, cssauron exports a function that returns a function.
23:43 < guybrush> but without pointing to branches :D
23:43 < guybrush> you see, i have 1 module all my apps run with
23:44 < defunctzombie> guybrush: I use npm for my app deps and my module deps and I pin, because I need to be able to come back to things and know what was going on
23:44 < chrisdickinson> the specializations export just that returned function.
23:44 < guybrush> i update that module and all my apps get updated
23:44 < guybrush> withouth pushing 20x versionupdates to every app
23:44 < chrisdickinson> i could remove all of their deps on cssauron and do `cssauron = require('cssauron'), lang = cssauron(require('cssauron-html'))`
23:44 < guybrush> defunctzombie: but i really get your point
23:45 < chrisdickinson> if i removed the direct cssauron call inside the module
23:45 < chrisdickinson> and it's an api that will not change.
23:45 < defunctzombie> chrisdickinson: sounds like your modules actually do depend on specific versions but you refuse to admit that :)
23:45 < guybrush> i do it now how i do it, because i didnt talk to you about this before i implemented my deployment :)
23:45 < defunctzombie> and because you are the author of al of them
23:45 < defunctzombie> you think it is ok ;)
23:45 < chrisdickinson> defunctzombie: they don't depend on a specific version :)
23:45 < defunctzombie> chrisdickinson: yes they do
23:45 < defunctzombie> if you don't realize that make a breaking api change
23:45 < defunctzombie> and see how well it goes ;)
23:46 < defunctzombie> guybrush: :)
23:46 < chrisdickinson> there won't be one, because cssauron is set in stone :)
23:46 < defunctzombie> what you just said is a lie
23:46 < defunctzombie> :)
23:46 < defunctzombie> to me I have no way to verify this
23:46 < defunctzombie> I have to trust you
23:46 < defunctzombie> and I don't trust you
23:46 < defunctzombie> also
23:46 < defunctzombie> a missing semicolon
23:46 < defunctzombie> in a patch update
23:46 < defunctzombie> can bring down your whole app ;)
23:47 < chrisdickinson> that's why when you use cssauron, you should peg your version of cssauron.
23:47 < chrisdickinson> any of the specializations will just use that one.
23:48 < defunctzombie> chrisdickinson: you are talking about a plugin based system
23:48 < chrisdickinson> if there's a better way of doing that -- because yeah, i don't particularly like * deps -- let me know, but ideally updating cssauron shouldn't cause an update of all specializations
23:48 < defunctzombie> btw those also depend on specific versions
23:48 < defunctzombie> you are doing what jquery plugins all do and pay to god that jquery never breaks
23:48 < defunctzombie> because none of them specify what version they support
23:48 < defunctzombie> chrisdickinson: peer dependencies
23:48 < defunctzombie> is made for plugin type stuff
23:49 < chrisdickinson> this is all it does: https://github.com/chrisdickinson/cssauron-html/blob/master/index.js
23:49 < defunctzombie> chrisdickinson: if you say it will never change
23:49 < chrisdickinson> and i could remove `cssauron`, and just export that object, and have the user explicitly pass it to their cssauron
23:49 < defunctzombie> then you should have no problem pinning the dependency
23:49 < chrisdickinson> and remove the star dep
23:49 < defunctzombie> and if you add the same version at the top level
23:49 < defunctzombie> npm is smart
23:49 < defunctzombie> and installs it only once
23:49 < defunctzombie> if that is really what you wanted
23:51 < chrisdickinson> npm wouldn't hoist that, though
23:51 < chrisdickinson> afaik
23:51 < defunctzombie> yes it will
23:51 < defunctzombie> if all the versions match
23:51 < defunctzombie> and it exists at top level
23:51 < defunctzombie> it will hoist it
23:51 < chrisdickinson> really? that seems incorrect unless the user specifically asks for it
23:51 < chrisdickinson> ah
23:51 < chrisdickinson> yeah
23:51 < chrisdickinson> okay if the user specifically pegs it.
23:51 < chrisdickinson> at top level.
23:52 < chrisdickinson> how's that different, exactly?
23:52 < chrisdickinson> aside from making more work for me?
23:52 < chrisdickinson> i suppose it could be argued that it handles the "i only need one of these child modules" case.
23:52 < defunctzombie> again, you guys are complaining about work because you created 20 modules all with 5 lines and now have no good way to manage consistency for them :)
23:53 < defunctzombie> in your case I would look at peer deps as it sounds like you have a plugin type system or some such
23:53 < guybrush> haha just recently i noticed the new npm i --save doesnt put semver in package.json anymore :p
23:53 < guybrush> just before i wanted to start an issue about it
23:53 < defunctzombie> or just use the function you meant to and don't make a superfunction :)
23:53 < chrisdickinson> it's not so much plugin-y as it is "these modules simply generate the argument necessary to make cssauron work this this particular AST"
23:54 < defunctzombie> guybrush: what does it do?
23:54 < chrisdickinson> i would argue that cssauron is exactly not a megafunction -- it just understands how to traverse an ast given css selectors
23:54 < chrisdickinson> and if you tell it the kinds of traversals you can perform, it can apply it to any given ast
23:55 < chrisdickinson> as in, "i need to get to a parent"; in one AST / tree structure, that's `node.parentNode`, in another, it's just `node.parent`.
23:57 < defunctzombie> chrisdickinson: agreed, but the functionality of the things that use it depend on a specific working version of it
23:57 < defunctzombie> so the fact that you called it cssauron-html is just a byproduct
23:57 < defunctzombie> really it became its own indepndent thing
23:57 < defunctzombie> that just happens to be a single call to cssauron
23:57 < chrisdickinson> i think the best argument for pegging the version is so that people can just add cssauron-html to their package.json without having to peg cssauron as well
23:58 < defunctzombie> but from an actual standpoint, it is a completely wrapping function which hides what it uses
23:58 < chrisdickinson> that might be the one that wins me over
23:58 < defunctzombie> chrisdickinson: it should be possible to add cssauron-html to package.json without adding cssauron as well
23:58 < chrisdickinson> the other route being making those modules not require cssauron at all, and simply exporting that object that contains the specifics for forms of traversal
23:59 < chrisdickinson> which might be a better idea, because then people can use those outside of cssauron entirely
23:59 < defunctzombie> chrisdickinson: or that :)
--- Log closed Fri Feb 01 00:00:03 2013