Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-01-31:

[21:15] <isaacs> tlrobinson: hey, how does jsgi handle body encoding
[21:15] <isaacs> ?
[21:17] <tlrobinson> isaacs: it calls toByteString on the objects
[21:17] <tlrobinson> which will just use the default encoding without any args
[21:17] <isaacs> ok, so it's up to String.toByteString() to turn it into the right array of bytes.
[21:17] <tlrobinson> or you can pass it an already encoded binary object
[21:17] <tlrobinson> in which case toByteString() just returns itself
[21:18] <isaacs> hmmm
[21:18] <tlrobinson> does that not make sense?
[21:19] <isaacs> nono, it does, but node's way of doing it also makes sense, and is completely different.
[21:19] <tlrobinson> how is that?
[21:19] <tlrobinson> the server (or middleware) could do something smart like passing the encoding specified in the content-type header to toByteString()
[21:19] <isaacs> well, with node, you do res.sendBody(blah, enc)
[21:20] <isaacs> where "blah" is your data, and "enc" is either "binary", "ascii", or "utf8"
[21:20] <isaacs> (i think "utf-8" is also ok)
[21:20] <tlrobinson> blah.toByteString(enc)
[21:20] <tlrobinson> then returning that
[21:21] <tlrobinson> except it works with any encoding supported by the system
[21:21] <isaacs> there's no "toByteString" in node
[21:21] <isaacs> afaik
[21:21] <tlrobinson> there should be :)
[21:21] <tlrobinson> "blah" is always a JS string?
[21:22] <isaacs> yeah, but it might actually be bytes from a file or something
[21:22] <tlrobinson> isaacs: node doesn't even really have a binary type yet, does it?
[21:23] <tlrobinson> dumping binary data into a string feels really hacky to me
[21:23] <isaacs> i think ryah said something about using v8's binary stuff, but i don't recall what happened with that
[21:24] <tlrobinson> especially since js engines use UTF-16 (or UCS-2?) to store strings, it uses double the space
[21:24] <tlrobinson> V8 has a binary type built in?
[21:24] <nrstott> when're we going to have a binary type in narwhal ;0
[21:24] <nrstott> having binary regex would be so nice, would make parse multipart much less ugly
[21:25] <tlrobinson> nrstott: we do, ByteString and ByteArray
[21:25] <ashb> tlrobinson: ryah submitted a patch to v8 for a basic binary type
[21:25] <isaacs> ahh
[21:25] <isaacs> that's what i'm remembering.
[21:25] <tlrobinson> ashb: orly. what was their reaction?
[21:25] <nrstott> tlrobinson, yeah im aware of those... even using them, guess i just need to see if in trunk some of the stuff that used to be broken is fixed now
[21:25] <ashb> no idea
[21:25] <ashb> i HATE gnu autotools
[21:25] <ashb> that is all.
[21:25] <nrstott> and id love it if someone had an idea for how to get binary regex ;0
[21:25] <tlrobinson> i don't see them accepting that if its not any sort of standard
[21:25] <nrstott> autotools is the worst thing ever
[21:27] <tlrobinson> nrstott: yes that would be useful, for, say parseMutlipart :)
[21:27] <nrstott> yeah :)
[21:27] <nrstott> tlrobinson, I recently did a big cleanup as a part of a bug fix on parseMultipart. It's _less_ ugly now
[21:27] <nrstott> it's _still_ ugly though :)
[21:29] <tlrobinson> yeah
[21:29] <tlrobinson> well, i ported that from ruby
[21:29] <tlrobinson> soooo
[21:29] <nrstott> i kind of hate how git did a complete file rewrite because I changed a signifincat percentage of the file
[21:29] <nrstott> it makes it so that you can't see what i really changed
[21:29] <nrstott> is there a way to keep git from doing that?
[21:29] <tlrobinson> ah, id on't know
[21:30] <ashb> nrstott: no
[21:30] <ashb> don't rename and move in one op if thats the case :)
[21:30] <nrstott> i didn't rename ;0
[21:30] <nrstott> i jsut changed a large %tage of the file
[21:30] <ashb> oh
[21:30] <nrstott> and it did a coplete rewrite
[21:30] <ashb> it records it as a del+add?
[21:30] <nrstott> http://github.com/nrstott/jack/commit/18e73ba3e5fc976bc3252978395783a6bc89e2f0
[21:31] <nrstott> that's the commit
[21:31] <ashb> nrstott: it could be line endings?
[21:31] <nrstott> hm, i don't know?
[21:31] <nrstott> maybe
[21:31] <nrstott> im working on linux though
[21:31] <ashb> http://help.github.com/dealing-with-lineendings/
[21:31] <nrstott> id assume everyone else in jack is too
[21:31] <ashb> run file on it befopre that commit and after
[21:32] <nrstott> yes that article is on my cmopanies wiki man :)
[21:32] <nrstott> we had huge trouble iwth that
[21:32] <ashb> does it say '... with CRLF'
[21:32] <nrstott> i have set core.autocrlf input on my linux box
[21:32] <nrstott> run 'file' on it?
[21:32] <ashb> file lib/jack/utils.js
[21:33] <ashb> isaacs: browsers probably treat it s chunked-encoding
[21:33] <ashb> or just read everything till EOF
[21:33] <isaacs> what's line chunked encoding now?
[21:34] <isaacs> oh, my tweet
[21:34] <ashb> :)
[21:34] <isaacs> yeah, it seems like they do 100% the right thing without it, and occasionally die with it
[21:34] <isaacs> (ie, if i'ts not exactly right)
[21:34] <isaacs> i guess it helps to know if you've gotten the whole thing, maybe they can close the connection sooner or something?
[21:35] <nrstott> ashb, after that commit and before that commit it says ASCII C++ program text, with CRLF line terminators
[21:35] <nrstott> says same thing before and after
[21:35] <ashb> nrstott: hmmm. not sure then
[21:35] <ashb> that's typically what i'd expect
[21:35] <nrstott> ive read and noticed that if you change a signifcant %tage of a file, git does an entire file rewrite
[21:35] <nrstott> im pretty sure thats what happened
[21:35] <nrstott> and i really hate that behavior
[21:45] <nrstott> why is mustache becoming such a popular templating language?
[21:45] <nrstott> ive looked at it and i dont see the 'killer feature' i guess
[21:52] <isaacs> how does jsgi handle multiple headers of the same key on the incoming re quest?
[21:52] <isaacs> req.headers = { cookie : [ "one", "two" ] } like outgoing headers?
[22:00] <ashb> isaacs: yeah.
[22:00] <ashb> i think the spec says SHOULD turn multiple incoming headers into an array
[22:01] <isaacs> ok, cool
[22:01] <ashb> isaacs: since techinically cookie: ["one", "two"] is the same as cookie: ["one,two"]
[22:01] <ashb> Cookie is the only header wheres its not
[22:01] <tlrobinson> ashb: does that mean headers should be split on commas?
[22:01] <ashb> tlrobinson: ish.
[22:01] <ashb> tlrobinson: in practice, no
[22:02] <ashb> just make it a header when you have multiple Header: lines
[22:02] <technoweenie> hey is there something for js packaging yet?
[22:02] <technoweenie> i see a module spec and packaging spec, but is there an implementation
[22:02] <ashb> of sorts
[22:02] <tlrobinson> technoweenie: narwhal has one. it's not up to date with the spec though
[22:02] <tlrobinson> "tusk"
[22:03] <technoweenie> i basically just need something that can install versioned libs
[22:03] <technoweenie> right now i symlink stuff to ~/.node_libraries
[22:03] <tlrobinson> oh and doesn't really support versioning yet :-/
[22:03] <isaacs> technoweenie: you could check out npm
[22:03] <ashb> technoweenie: for node you probably want isacs npm
[22:04] <isaacs> it doesn't really support versioning yet either, but it does support installing from a remote tarball, and symlinks into node_libraries just like you're doing manually
[22:05] <ashb> `zip` is the worst program ever.
[22:06] <isaacs> ashb: that's why npm requires tar+gzip
[22:07] <isaacs> it's not the 90s any more. windows users can go get tar
[22:07] <ashb> oh i forgot tar and boost. arse.
[22:07] <ashb> i'm building up a mingw env for windows
[22:08] <ashb> curl, libbzip2, gcc, make etc
[22:09] <ashb> its only taken about 3 days to script it and work ouy how to build it all
[22:09] <ashb> (except i still couldn't work out how to build the right kind of cross-compile for gcc, so i cheated and used a pre-build one of those
[22:16] <technoweenie> hmm thanks
[22:17] <isaacs> technoweenie: i've got a sketch for versioning, and i'll be building a package registry in streaming jsgi soonis
[22:17] <isaacs> h
[22:17] <technoweenie> seems like you'd need some directory with your packages sorted by name/version
[22:17] <technoweenie> and then some special require function that takes name+version adds that to require.paths
[22:19] <technoweenie> foo = npm("foo", "1.0") // adds ~/.npm/packages/foo/1.0/lib to require.paths and returns "require('foo')"
[22:19] <isaacs> technoweenie: actually, i just create a "index.js" inside of ~/.node_libraries/foo/, and you do require("foo") in your app
[22:20] <isaacs> and foo/index.js requires whatever the package uses as its endpoint
[22:20] <isaacs> so you just use require() normally, and have YOUR code require THAT code, and you know it's the right version.
[22:20] <technoweenie> yea thats what i do now, but that doesnt allow for versions
[22:20] <isaacs> well, it kinda does..
[22:20] <isaacs> i mean, npm doesn't yet
[22:20] <isaacs> but you can have a concept of an "active" eversin
[22:21] <isaacs> so, you have 1.0, 1.1, and 2.0 installed. if you clean, it'll delete out the ones you'er not using.
[22:21] <ashb> hmmm my VM appears to be melting
[22:21] <ashb> i blame windows
[22:21] <hassox> why index.js and not foo/foo.js
[22:21] <hassox> ?
[22:21] <isaacs> because then you'd have to require("foo/foo")
[22:21] <isaacs> var Foo = require("foo/foo").Foo
[22:21] <hassox> ?
[22:21] <technoweenie> isaacs: but then you cant have multiple versions of a lib loaded for different libs
[22:22] <hassox> you're making it so require('foo') will look for index.js right?
[22:22] <isaacs> technoweenie: i'd call that a bug, not a feature.
[22:22] <hassox> why not just make it look for foo.js?
[22:22] <isaacs> hassox: because this way keeps *everything* related to the foo project inside the foo/ directory.
[22:22] <technoweenie> isaacs: i guess its fine if you only ever have one node app running on a machine
[22:22] <isaacs> but yeah, that'd work, too
[22:22] <isaacs> technoweenie: well, npm only has a single place per-instance. but you could point it at a different root.
[22:23] <isaacs> and add that different root to your NODE_PATHS for that other instance of node.
[22:23] <technoweenie> so you're talking about having something like ~/.node_libraries for each app
[22:23] <isaacs> technoweenie: sure.
[22:23] <isaacs> if you actually want to keep multiple different versions of the same codebase running at the same time in the same env, you're asking for trouble.
[22:24] <isaacs> if you want to shoot yourself in the foot, that's fine, but you're gonna have to drive yourself the store to get the bullets.
[22:24] <technoweenie> well, i dont want it, but it happens
[22:24] <isaacs> hehe
[22:24] <technoweenie> you're using 2 libs taht depend on the same thing. one of them upgrades that thing to a newer version and the other breaks
[22:25] <isaacs> then the other should say that it requires between version X and Y of said dependency.
[22:25] <ashb> thats when you take out chainsaw assurance
[22:25] <isaacs> then when you try to upgrade, npm can say "Oh, i can't upgrade that without upgrading this other thing, too, is that ok?"
[22:25] <ashb> assurance thant if that happens, someone goes to the author with a chainsaw
[22:25] <isaacs> ashb: lolz
[22:26] <hassox> isaacs: but in node you can right
[22:26] <isaacs> if we're all using appropriately semantic versioning, then it's not such a problem
[22:26] <technoweenie> yea, if node only has like 10 libs its not a problem
[22:26] <hassox> since you import objects, two "versions" of a library can exist at the same time
[22:26] <hassox> isn't that one of the ideas behind the hot code reloading thing?
[22:27] <ashb> hassox: you can do it in any commonjs env
[22:27] <hassox> right
[22:27] <hassox> my point is...
[22:27] <hassox> if two libs need two different versions of a lib... why can't they have it?
[22:27] <ashb> oh the hot reload where each module sees a consistent view?
[22:27] <technoweenie> assuming your lib doesnt extend GLOBAL (like express)
[22:28] <ashb> express?
[22:28] <Dantman> Sigh.... package managers that make existing libraries change their versioning scheme are fun...
[22:29] <technoweenie> a node web server
[22:29] <hassox> technoweenie: true
[22:29] <hassox> but that's evil
[22:29] <technoweenie> Dantman: well as far as i can tell there is no convention so every lib is all over the place
[22:30] <technoweenie> do you have foo/lib/foo.js? foo/index.js? foo/lib/index.js?
[22:30] <ashb> which is why we decided to force semver on commonjs
[22:30] <ashb> to my mind it is A Very Good Thing
[22:30] <ashb> oh like that
[22:31] <isaacs> semver ++
[22:31] <isaacs> technoweenie: that's also why npm bundles everything about the actual lib away in its own folder, and then just gives you one consistent means to bring it in
[22:35] <technoweenie> feels like going through the same discussions again
[22:36] <technoweenie> i dont really know what semver has to do with anything though
[22:37] <ashb> nothing with that file layout
[22:37] <technoweenie> those libs that do it Correctly have bitten me in the ass because they decide to go with a bleeding edge version of a lib
[22:37] <technoweenie> i really just want to keep it simple, which is why i like npm in some ways
[22:38] <tlrobinson> isn't the semver thing in the packages spec more of a suggestion?
[22:40] <ashb> thats not how i recal it
[22:40] <isaacs> imo, semver is really a way to broadcast that you give a shit about your users, more than anything else.
[22:40] <isaacs> but there are other ways to broadcast that.
[22:40] <isaacs> not polluting the global space, writing readable code, consistent docs, etc.
[22:41] <isaacs> a package manager ought to be able to work with non-shit-giving packages, while still being kind to the package manager users.
[22:46] <ashb> gah msys is *slow*
[23:07] <ashb> yay 18mins for the configure to finish then the compile to fail at the first hurdle.
[23:07] <ashb> wonderful >_<

 

 

Logs by date :