[00:14] scudco has joined the channel
[00:16] isaacs: kriskowal: Added tests for resolveObject() and format() http://gist.github.com/267693
[00:17] kriskowal: isaacs. there's a huge body of tests for resolve somewhere.
[00:18] kriskowal: some of them were written by the tim
[00:18] isaacs: oh? nice.
[00:18] kriskowal: i'll have to dig them up
[00:18] kriskowal: in any case, it's no small chore to port them
[00:18] isaacs: i've worked on the assumption that resolve(a, b) should be like if you're at "a" in a web browser, and have <a href="b">
[00:18] isaacs: where would that take you
[00:18] kriskowal: that's the intent.
[00:19] isaacs: that's why i added tests for weird stuff like https:/p/a/t/h
[00:19] isaacs: from http://foo.com/a/b/c/d?a=b
[00:19] kriskowal: yep yep
[00:19] kriskowal: and stuff like //example.com/foo
[00:19] isaacs: yep
[00:19] isaacs: i've got that in there
[00:20] isaacs: for a while, i was confounded because the uri module's format() was running like 2 OOM faster than the url module
[00:20] kriskowal: http://code.google.com/p/chironjs/source/browse/trunk/src/test/http/resolve.js
[00:20] isaacs: turns out i was passing a string, so it was just returning it, whereas the url module will parse the string and then format that
[00:20] kriskowal: right, normalizing
[00:20] kriskowal: i can imagine that both would be desirable features in different cases.
[00:21] kriskowal: on one hand you want normalization and on the other coercion
[00:21] kriskowal: http://code.google.com/p/chironjs/source/browse/trunk/src/test/http/relative.js
[00:21] kriskowal: both of those are obviously incomplete.
[00:22] kriskowal: and they're not quite commonjs.  they're written for chiron, so some porting needs to be done.
[00:22] kriskowal: http://code.google.com/p/chironjs/source/browse/trunk/src/test/http/url.js
[00:23] kriskowal: http://code.google.com/p/chironjs/source/browse/trunk/src/test/http/formatUrl.js
[00:23] kriskowal: have fun :P
[00:23] isaacs: hahah
[00:24] isaacs: i'm not so sure i agree with this: ['../../../g','http://a/../g'],
[00:24] isaacs: it breaks the "a tag resolution" rule.
[00:24] kriskowal: i'm not sure i agree with all of them either.
[00:24] kriskowal: many of those tests were written a couple decades ago
[00:25] isaacs: since the use-case is "i'm at a url, and want to go to this other relative url that i'm seeing in some web page and have it work like a web page", it seems like it's better to do what browsers actually do rather than what the w3c says they ought to do.
[00:25] kriskowal: if they're omitted, they should be commented, annotated, tested against real world browser(s!)
[00:26] isaacs: i've actually seen urls like "../../../../../../foo" getting resolved against something like "http://domain.com/bar" in the wild.
[00:26] kriskowal: yeah, i'd count that as undefined.
[00:26] isaacs: this was a major bug in one version of YAP when i was working on it
[00:26] isaacs: it was only 3 ../'s, i think
[00:26] kriskowal: it might even be acceptable to throw an error for that in some cases
[00:27] kriskowal: not in the browser case, but possibly in the server case, and probably in the secure subset case
[00:27] isaacs: the developer had this clever thing where the dev url had an extra dir in the path, so it'd hit the root in production, but go somewhere different in dev.
[00:27] kriskowal: cheeky monkey
[00:27] isaacs: and, like a jerk, we'd told them "it works just like browser url resolution", and they figured that we meant it.
[00:42] orlandov: hi, is there any way to "profile" a program for blocking calls?
[00:43] orlandov: i'd like to know that while running my unit tests my program never blocks on recv, connect, calls etc
[00:46] creationix has joined the channel
[00:47] charlenopires has joined the channel
[00:54] mikeal has joined the channel
[01:39] mikeal has joined the channel
[02:10] ryah: hi
[02:16] grantmichaels: hi
[02:17] emyller: hey
[02:18] CIA-56: node: 03Tim Caswell 07master * r732c6f2 10/ (lib/sys.js test/mjsunit/test-sys.js): Fix inspect for the special case of an Object that inherits from Array, but has other properties. - http://bit.ly/7AuWcz
[02:18] CIA-56: node: 03Tim Caswell 07master * r6c68a96 10/ (lib/sys.js test/mjsunit/test-sys.js): 
[02:18] CIA-56: node: Fix inspect to not trigger dynamic properties
[02:18] CIA-56: node: but to display them as special. Add unit tests to match - http://bit.ly/8YHLdp
[02:35] bryanl has joined the channel
[02:47] orlandov: <3 valgrind
[02:50] mikeal has joined the channel
[02:51] ryah: me too
[02:51] ryah: orlandov: ./node --prof myscript.js
[03:14] binary42 has joined the channel
[03:57] Sembiance: :)
[03:57] mikeal has joined the channel
[04:01] bentomas has joined the channel
[04:01] bentomas has left the channel
[04:03] nsm has joined the channel
[04:19] kriszyp has joined the channel
[04:32] jed has joined the channel
[04:54] kriszyp_ has joined the channel
[05:05] brandon_beacher_ has joined the channel
[05:24] JoePeck has joined the channel
[05:34] isaacs: kriskowal: i hope you realize that you pretty much destroyed my Saturday with that list of test cases. :P
[05:34] kriskowal: did i fail to say "have a nice day" or something equally horrible?
[05:34] kriskowal: i mean, i definitely knew that was going to happen.
[05:35] isaacs: hahaha
[05:35] isaacs: oh, you did.
[05:35] isaacs: you were pretty blatant about how horrible it was.
[05:35] kriskowal: i guess i'm saying, i'm pleading guilty of both deed and intent
[05:35] isaacs: hahaha
[05:35] isaacs: good is coming of it, though
[05:37] kriskowal: awesome on all counts.  thanks for picking that up.  i recall leaving that particular effort content but frustrated it wasn't perfect
[05:39] isaacs: 
ACTION is WAY too OCD for that.

[05:42] kriskowal: at some point, the body is weaker than the ocd
[05:44] JoePeck_ has joined the channel
[05:45] isaacs: i'm seriously almost there
[05:54] micheil has joined the channel
[05:59] elliottcable: isaacs: almost where?
[06:02] keeto has joined the channel
[06:08] isaacs: elliottcable: kriskowal gave me a very long and extremely thorough list of test cases for url resolution logic.
[06:08] isaacs: it's like mailing someone 100 boxes of bubble wrap.
[06:08] isaacs: seriously, not kind.
[06:08] elliottcable: isaacs: hahahahahahahaha
[06:08] isaacs: must... crush... all... bugs....
[06:08] elliottcable: shit, I want to do that to somebody now v.v
[06:09] elliottcable: 
ACTION looks up prices on bubble wrap

[06:09] elliottcable: shit though you have to put something expensive in *one* of them
[06:09] elliottcable: and include in every one, a piece of paper explaining that fact
[06:09] elliottcable: otherwise they might get fed up and throw them all away
[06:09] kriskowal: "sorry, the princess is in another castle"
[06:11] elliottcable: “sorry, the process is in another castle”
[06:19] mikeal has joined the channel
[06:23] isaacs: wait, what?  ok, these rules are intentionally fucking with me.
[06:23] isaacs: g:h is treated differently than ftp:h or http:h or https:h
[06:53] elliottcable: Best possible thing I could do with the last 30 minutes? http://doesthissayno.com/
[07:10] qFox has joined the channel
[07:38] keeto has joined the channel
[08:04] jamiew has joined the channel
[08:12] tlrobinson has joined the channel
[08:28] isaacs: kriskowal: passing all tests.
[08:28] isaacs: except the ones that are wrong ;)
[08:32] kriskowal: awesome
[08:34] botanicus_ has joined the channel
[08:37] scudco has joined the channel
[08:37] mikeal has joined the channel
[08:41] isaacs: by "wrong", i mean, "different from firefox and chrome's url resolution logic"
[08:42] isaacs: lost about half my parse speed score, though
[09:12] kriskowal: isaacs you might consider having different parsers for basic splitting and resolving
[09:13] kriskowal: i gravely suspect that making the fast one the primary API would be premature optimization
[09:13] kriskowal: but if you need speed, and can sacrifice features to get that speed, multiple implementations are in order.
[09:13] isaacs: i dunno.  i think it's fairly mature optimization.
[09:13] kriskowal: just make sure to cross-test
[09:14] isaacs: i mean, there's been a ridiculous amount of chatter on the nodejs list about what people are actually using this module for, and what they care about.
[09:14] kriskowal: yeah, i noticed
[09:15] isaacs: it's a fairly well-understood problem, and i think this approach delivers the required functionality at a reasonable performance
[09:15] kriskowal: i almost exclusively use resolve and relative
[09:15] isaacs: what do you use relative for?  i've yet to actually need it for anything.
[09:15] isaacs: resolve, of course, is extremely useful
[09:15] kriskowal: generating loosely coupled urls
[09:16] kriskowal: and, in its file system analog, generating loosely coupled symbolic links
[09:16] kriskowal: resolve and relative are two sides of the same coin, really.
[09:16] isaacs: sure
[09:17] isaacs: i've just always figured that if you have the absolute url already, why not just use that?
[09:17] kriskowal: depends on whether it's for your own consumption or for later consumption by someone or something else.
[09:17] isaacs: i haven't ever had a need to programmatically generate relative urls from absolute urls
[09:18] kriskowal: and if  you had had a need, you would have had to find a workaround since almost no api's provide it
[09:18] kriskowal: hammers and nails
[09:19] kriskowal: (the solution avails the problem)
[09:20] isaacs: nah, if i had a need, i'd spend a weekend writing a relative url generator ;)
[09:22] kriskowal: yeh, and you'd probably put it in your url module, since that'd make sense.
[09:22] isaacs: haha, probably
[09:25] kriskowal: uh oh.  i sense that the caffeine is about to wear out.  time to bike home.
[09:25] kriskowal: a pleasure as always.
[09:31] rednul_ has joined the channel
[09:32] mattly has joined the channel
[09:46] mikeal has joined the channel
[09:58] hassox has joined the channel
[10:51] teemow has joined the channel
[11:06] rednul_: has anyone created a http server that executes .js files on the fly much like a cgi-bin ?
[11:20] mikeal has joined the channel
[12:00] isaacs has joined the channel
[12:10] jviereck has joined the channel
[12:12] jviereck: hey. I've started a bash child process in node with bash = process.createChildProcess("bash"); After that I execute a command with bash.write("<command>\n");. That works fine but I can't figure out how to send the ^C combination to the bash to stop this command again. calling bash.kill() doesn't work while the command is still running :( Any idea?
[12:39] eviltwin has joined the channel
[12:48] micheil has joined the channel
[12:50] micheil has left the channel
[12:50] micheil has joined the channel
[12:51] teemow has joined the channel
[12:56] bryanl has joined the channel
[12:57] creationix has joined the channel
[12:58] spoob has joined the channel
[13:13] unom1 has joined the channel
[13:18] DamZ has joined the channel
[13:19] charlenopires has joined the channel
[13:20] DamZ has joined the channel
[13:20] creationix has joined the channel
[13:21] DamZ_ has joined the channel
[13:42] isaacs: jviereck: you tried process.kill(pid, "SIGTERM") already?
[14:07] jviereck: nope
[14:08] jviereck: will try
[14:12] jviereck: mhmm, the bash is killed now but the process within the bash is still running
[14:17] gwoo has joined the channel
[14:40] keeto_ has joined the channel
[14:41] keeto has joined the channel
[14:53] teemow has joined the channel
[15:02] alex-desktop has joined the channel
[15:09] brandon_beacher has joined the channel
[15:50] keeto has joined the channel
[16:27] kriszyp has joined the channel
[16:35] jed has joined the channel
[16:49] JoePeck has joined the channel
[16:53] inimino: ryah_away: got an API question for you, when you are around
[16:54] inimino: ryah_away: if you write() some string in UTF-8, then you get back a byte count, you have to rescan the string to find where to cut it, to write the next chunk...
[16:59] inimino: I guess explicit conversion methods and binary-only I/O would be a nicer API if you can get good performance out of V8 that way
[17:09] jed_ has joined the channel
[17:20] rictic has joined the channel
[17:21] jed: hey all, what's the most reliable way to detect that you're in a node.js environment?
[17:22] jed: i'm making a module that works with both commonJS and node, but i need to run special code for node.
[17:22] jed: there's a version on the process object, but not much else that i can find.
[17:23] inimino: jed: what's the special code?
[17:24] jed: a JSGI app.
[17:24] jed: if this environment is node, i need to add an adapter.
[17:25] inimino: hm
[17:25] bryanl has joined the channel
[17:25] jed: only thing i can think of is to look at ARGV, but that's easily broken.
[17:26] inimino: seems if there is going to be JSGI support in node it should just work
[17:27] inimino: even though it might be inefficient
[17:27] inimino: s/in node/for node/
[17:31] jed: would it not make sense to put something in node's ENV?
[17:32] binary42 has joined the channel
[17:32] jed: or on the process object?
[17:36] inimino: to me it would make sense for there to be a node ↔ JSGI compatibility layer, and if that is loaded, things should just work
[17:41] inimino: ryah_away: also, unless I'm misreading the API, lib/file.js contains this bug also :/
[17:44] grantmichaels has joined the channel
[17:44] inimino: ...and my previous file-writing code has a slight variation on it
[17:46] jed: inimino: cool. i guess i'll poke around for a workaround for now.
[17:46] inimino: ok
[18:00] aurynn has joined the channel
[18:27] bry has joined the channel
[18:31] soveran has joined the channel
[19:07] creationix has joined the channel
[19:09] jed has joined the channel
[19:12] rolfb has joined the channel
[19:14] sudoer has joined the channel
[19:32] charlenopires has joined the channel
[19:34] jviereck has joined the channel
[19:52] hassox has joined the channel
[19:53] emyller_ has joined the channel
[19:54] emyller_ has joined the channel
[19:57] isaacs has joined the channel
[19:59] isaacs: inimino: re node ↔ JSGI, check out http://github.com/kriszyp/jsgi-node/
[20:04] mikeal has joined the channel
[20:07] jed: isaacs: do you have any thoughts on how to determine whether the current environment is node?
[20:07] emyller__ has joined the channel
[20:10] isaacs: jed: maybe you could sniff process?  like, if (typeof(process) === "object" && process && process.version))
[20:11] isaacs: if you wanna be strict, there's also process.ENV.ARVG[0] which should be "node" somewhere
[20:11] jed: isaacs: would the latter still work after rlwrap or whatever?
[20:12] isaacs: yeah
[20:12] isaacs: try it in the repl: if (process.ARGV[0].slice(-4) === "node") sys.debug("i am node!")
[20:12] jed: isaacs: that seems like a better bet. lemme give that a shot.
[20:13] jed: isaacs: indeed, that works. thanks for the tip!
[20:13] isaacs: f (typeof(process) === "object" && process && process.ARGV && process.ARGV[0] && process.ARGV[0].slice(-4) === "node"))
[20:14] isaacs: if you wanna not error out in other common js'es
[20:14] isaacs: since they might not have a "process" global
[20:15] jed: isaacs: okay cool. by the way, why do you need (1) _and_ (2) in the above?
[20:15] emyller_ has joined the channel
[20:16] isaacs: try doing if (flahs9ehlahs9f) in the repl
[20:17] isaacs: the first tests for its existence, the second tests for it being truthy (ie, non-null), the third tests for a truthy ARGV, the fourth tests for a truthy ARGV[0], and the last tests that ARGV[0] ends with "node"
[20:17] isaacs: if you hard-link the node binary to something else it won't work, though
[20:17] jed: isaacs: i was also wondering whether there might be some self-referential test, too.
[20:18] isaacs: yeah, if i were you, i'd just sniff for process.version
[20:18] isaacs: maybe bring it up as a suggestion to ryah_away if you're interested, though
[20:18] jed: isaacs: like x.document.defaultView === x
[20:19] isaacs: would'nt be hard to add some kind of definite indicator
[20:19] jed: isaacs: to test for a window in a browser, or what have you.
[20:19] isaacs: right
[20:19] jed: does narwhal et al do that?
[20:19] isaacs: don't know, offhand
[20:19] isaacs: ask kriskowal or tlrobinson if they're around
[20:19] jed: it'd be nice to be able to provide a single library that would just work on a bunch of platforms. a la jQuery.
[20:20] isaacs: haha, you could just do if (typeof(node) === "object"), i guess
[20:20] isaacs: but i think the node object is on its way to deprecationville
[20:21] jed: isaacs: whoa, i didn't know that existed.
[20:21] isaacs: it's old and crusty
[20:21] isaacs: from the pre-commonjs days
[20:21] jed: yeah, seems like it's ready for a one-way trip to florida, if you know what i mean.
[20:21] isaacs: every function in it throws
[20:22] isaacs: i'd probably push for either: 1) using feature detection over platform detection if possible, and 2) adding a definitive platform indicator in the env somewhere for when it's not.
[20:23] hassox: hallo lads
[20:23] hassox: quick q for you guys... I haven't been able to get Object#create working :(
[20:23] hassox: http://wiki.github.com/ry/node/ecma-5mozilla-features-implemented-in-v8
[20:23] hassox: keeps coming up as undefined... any clues?
[20:24] jed: isaacs: cool, thanks much for the help.
[20:24] isaacs: np
[20:26] isaacs: hassox: works for me?
[20:26] isaacs: node> Object.create
[20:26] isaacs: [Function]
[20:26] isaacs: node> Object.keys
[20:26] isaacs: [Function]
[20:26] hassox: perhaps I need a new version :|
[20:26] isaacs: you pull from ry and rebuild lately?
[20:26] isaacs: there was a v8 drop a few days ago
[20:27] hassox: just doing that now
[20:27] hassox: still not there :|
[20:27] hassox: node> Object.create
[20:27] hassox: node>
[20:28] isaacs: hm.  maybe make clean and then do a cmi?
[20:28] hassox: boo
[20:28] isaacs: ./configure && make && sudo make install
[20:28] hassox: my git pull wasn't doing :(
[20:28] isaacs: i see
[20:28] hassox: my fault
[20:28] hassox: as usual ;)
[20:32] cadorn has joined the channel
[20:36] creationix has joined the channel
[20:41] scudco has joined the channel
[21:06] emyller_ has joined the channel
[21:09] mikeal has joined the channel
[21:15] hassox has joined the channel
[21:31] jed has joined the channel
[21:33] rictic has joined the channel
[21:35] elliottcable: hassox: pff Object.create sucks anyway d-;
[21:35] elliottcable: hassox: beget()!
[21:35] hassox: :)
[21:36] hassox: I was looking for a way to splat arguments on constructors
[21:36] hassox: elliottcable: when will I be able to require it though!
[21:36] hassox: I need a package manager
[21:36] elliottcable: hassox: eh? o_O
[21:36] hassox: elliottcable: you know ruby right?
[21:36] elliottcable: hassox: it works fine via from *or* require, by design. It ships with `from`
[21:36] hassox:   Foo.new(*some_args)
[21:36] elliottcable: hassox: quite, quite well. You know that d-:
[21:36] hassox: ;)
[21:37] hassox: elliottcable: how to be installing and stuff though so I don't have to vendor
[21:37] elliottcable: hassox: ah, you can’t splat, but you *can* make them take a single array/object and splat it internally
[21:37] hassox: yeah that's what I resorted to
[21:37] elliottcable: hassox: beget() passes a blueprint on to constructors, as a single argument; it’s designed to work like named arguments in Ruby
[21:37] hassox: noice
[21:37] elliottcable: hassox: myThing.beget({ isAwesome: true, use: coolOtherThing })
[21:37] hassox: :)
[21:38] elliottcable: hassox: as for a package *management* system; I haven’t bothered with a solution to that yet.
[21:38] elliottcable: hassox: as of the moment, all of my packages are directly dependant upon one another; you have to clone the whole bunch to use any of the higher-level ones; so I’m not too worried about writing a package manager. When my ecosystem is more developed, I’ll need one, though
[21:39] elliottcable: hassox: I’m planning to keep it simple; just .tar.gz’d folders, untarr’d into a libraries folder
[21:39] elliottcable: hassox: here’s beget() with a blueprint in the wild: http://github.com/elliottcable/Paws.js/blob/Master/Packages/Paws.js/Things/list.js#L24
[21:40] stephenlb has joined the channel
[21:46] hassox: sorry was doing work things
[21:46] felixge has joined the channel
[21:47] hassox: initializeNaughty <-- hehe
[21:49] emyller_ has joined the channel
[21:51] eviltwin has joined the channel
[22:03] LordMetroid has joined the channel
[22:04] LordMetroid: How do I generate an html source through non-blocking i/o, the file would necessarily have to be built in parallel, right?
[22:06] binary42 has joined the channel
[22:06] ryah: hi
[22:15] Sembiance: yo ryah. yo.
[22:16] jamiew has joined the channel
[22:16] jamiew_ has joined the channel
[22:18] mikeal has joined the channel
[22:20] LordMetroid: Can I even generate an HTTP output asynchronously?
[22:20] creationix has joined the channel
[22:21] charlenopires has joined the channel
[22:28] tlrobinson: ryah: is there a reason node can't use the commonjs "system" module instead of process for argv, env, etc
[22:28] tlrobinson: seems like low hanging fruit
[22:29] rednul has joined the channel
[22:30] tlrobinson: (in response to jed's earlier question, that's *why* we think commonjs is important)
[22:32] tlrobinson: (we have an opportunity to avoid the clusterfuck that is the browser agent/feature detection)
[22:32] jamiew_ has joined the channel
[22:38] ryah: gtg. tlrobinson: we'll talk later
[22:39] tlrobinson: k
[22:40] binary42 has joined the channel
[22:46] LordMetroid: hmm, res.sendBody doesn't work with I/O :( http://pastebin.com/dbba611f
[22:47] LordMetroid: That would have been hell of a nice thing, to be able to query the database for data and generate a response body as the data arrived
[22:47] LordMetroid: So I am still stuck to serial generation of a response body?
[22:49] mediacoder: LordMetroid: you just can send strings with sendBody, your function doesnt return anything. you could pass your response to the function and sendBody in the callback with your params
[22:51] LordMetroid: Could you show me?
[22:52] mediacoder: LordMetroid: maybe somhting like this http://pastebin.com/m3445dd7f
[22:54] mediacoder: ah..im missing finish.. but you cant res.finish(9 while you have pending res.sendBody ..but im not sure her
[22:55] LordMetroid: hmm
[22:56] LordMetroid: Well I got "213" as a result
[22:57] mediacoder: well, thats good then, isnt it? :-)
[22:57] LordMetroid: No, to create a website one would want to have them ordered 123 even though they are asynchronous
[22:57] mediacoder: why should they be ordered?
[22:58] mediacoder: you send them with different timeouts
[22:58] inimino: ah, I missed ryah
[22:58] LordMetroid: If I got to a database to fetch data in order to generate a webpage dynamically
[22:59] DamZ has joined the channel
[23:00] LordMetroid: *If I generate a webpage dynamically, I will fetch data from databases and use to determine just how the HTML source shall be written
[23:00] LordMetroid: The HTML source needs to be ordered
[23:00] mediacoder: well, then you need to use a template or whatever.. the lowlever http connection doesnt help you here
[23:01] LordMetroid: But wouldn't I need to wait for all databases to report with their result?
[23:02] mediacoder: there might be async template-engines..not sure
[23:02] LordMetroid: hm
[23:07] jamiew_ has joined the channel
[23:09] kriskowal has joined the channel
[23:09] orlandov has joined the channel
[23:18] creationix: there are async template engines
[23:18] creationix: I'm working on one, and there is another already made
[23:19] mikeal has joined the channel
[23:20] creationix: here is mine http://bit.ly/7rL7h1 It's extermely beta though
[23:21] jed: creationix: how does grain work? does it flush as soon as it hits an async part?
[23:21] creationix: and Malte's part is at http://j.mp/7SGLLi
[23:22] creationix: mine is still in development, but the plan is to buffer completed parts till slower part farther up completes
[23:23] LordMetroid: Interesting
[23:23] creationix: I'm pretty sure that's how the other works though
[23:23] creationix: another idea I'm thinking about it to send the data asynchronously in some sort of container and have the page put it back together.
[23:23] creationix: not too good for static pages without Javascript
[23:25] LordMetroid: Writing the final resulting source body shouldn't take a whole lot of time. It is the I/O and possible processing that would take time
[23:25] creationix: well in that case it's easy, just buffer all the just html server side till it's done
[23:26] creationix: aarg, I can't type without my glasses, sorry for the crazy grammer
[23:26] LordMetroid: np
[23:27] creationix: I'm not on IRC much, but if you have any suggestions for my grain library feel free to message me.  
[23:31] scudco has joined the channel
[23:38] LordMetroid: A cool, async 
[23:38] LordMetroid: I love async
[23:46] grantmichaels has joined the channel