[00:00] benw: (And the idea is incompatible with the current "uncaughtException" event.)
[00:00] benw: I'll add .catcher to each class that gets queued in the event queue.
[00:01] benw: When an event is queued, someevent.catcher = process.catcher.
[00:01] benw: When the event is dispatched, process.catcher = someevent.catcher
[00:01] ryah: i think we should dicuss this on the mailing list (i have to run in a few minutes)
[00:01] ryah: i'm not convinced this is the right direction
[00:02] ryah: maybe other people have some ideas to share too
[00:02] benw: Then FatalException dispatches to process.catcher instead of the uncaughtException event.
[00:02] benw: Let me try it out first
[00:02] ryah: sure, if you want. i reserve the right to reject :)
[00:02] benw: Never mind all that, just help me with the getter/setter crap :)
[00:02] benw: Of course
[00:03] benw: Should I just expose process._setCatcher and process._getCatcher from C++,
[00:03] benw: and have node.js makes those the getter and setter for process.catcher?
[00:03] robrighter_ has joined the channel
[00:03] ryah: checkout node_net.cc for the ready_state_symbol
[00:03] benw: Or is there a cleaner way without the extra _[gs]etCatcher symbols being visible to JS?
[00:04] benw: Will do, thanks
[00:04] benw: Isn't connection.readyState readonly?
[00:05] RayMorgan: Is the http client able to do https request?
[00:06] ryah: benw: yeah.. but the setter is similer
[00:07] ryah: look at deps/v8/include/v8.h
[00:07] benw: ryah: Thanks, yeah this is helpful.
[00:07] benw: Will do
[00:08] benw: ryah: I assume I do this direct on the C++ process object, not on PrototypeTemplate()
[00:09] ryah: yeah
[00:09] ryah: uh
[00:09] ryah: i forget, acutally
[00:09] ryah: maybe you have to do it on the template
[00:09] benw: I don't see a template for process
[00:09] paulca has joined the channel
[00:09] mattly has joined the channel
[00:10] benw: Oh wait, process_template
[00:11] benw: Looks like it would work either way
[00:12] ryah: jan____: can you add me to http://ssjs.pbworks.com/San+Francisco+-+January+2010
[00:12] ryah: :)
[00:12] ryah: to save a login
[00:13] ryah: nevermind they hve openid
[00:16] jan____: heh, I bugged tlrobinson to add me for the same reason :)
[00:19] tlrobinson: openid ftw!
[00:19] tlrobinson: jan____: what would you have preferred though
[00:19] tlrobinson: i'm not sold on pbwiki
[00:20] jan____: tlrobinson: I have no alternative, we used some free-append thing for the zeitgeist meetup
[00:20] ryah: joyent offered to buy pizza for the meetup
[00:21] jan____: screw pizza, we need booze
[00:22] mikeal: jan____: Relaxed should buy pizza :)
[00:22] mikeal: er beer
[00:22] mikeal: :)
[00:22] mahemoff has joined the channel
[00:22] jan____: :)
[00:23] tlrobinson: ryah: cool, sounds good
[00:23] mikeal: i have to sign up for an account to RSVP?
[00:23] mikeal: and it doesn't support OpenID
[00:23] tlrobinson: openid
[00:23] mikeal: fail
[00:23] tlrobinson: it does
[00:24] mikeal: where?
[00:24] tlrobinson: the little orangeish icon
[00:24] tlrobinson: gray and orange
[00:24] tlrobinson: openid logo. its subtle
[00:24] mikeal: AHA
[00:27] jan____: gnight
[00:27] mikeal: hrm… this isn't working with gmail openid
[00:27] mikeal: grrrr
[00:28] ryah: mikeal: want me to add you?
[00:28] mikeal: yes!
[00:28] ryah: mikeal: what should i add?
[00:28] mikeal: just put "mikeal"
[00:28] mikeal: that's enough :)
[00:28] ryah: okay :)
[00:29] sveimac has joined the channel
[00:29] cheapRoc has joined the channel
[00:29] mikeal: nobody else spells their name this horribly
[00:32] Micheil_away: mikeal: hmm.. mines not bad?
[00:33] Micheil: mikeal: hmm.. I'd guess a scotish name, perhaps?
[00:34] bentomas has left the channel
[00:34] konobi: we did?
[00:40] mikeal: mine isn't from any region
[00:40] mikeal: it's just hippie spelling
[00:42] orlandov: polish is even weirder, michal
[00:43] steadicat has joined the channel
[00:48] aho has joined the channel
[00:50] Micheil: hey, ryah, have you seen http://twitter.com/tjholowaychuk/status/8047307933
[00:51] Micheil: It probably would be handy for testing
[00:51] Micheil: mikeal: oh, my name's meant to be spelt something similar to yours, something to do with scottish heritage or something
[01:06] erichocean has joined the channel
[01:09] r11t has joined the channel
[01:10] robrighter has joined the channel
[01:15] ryah: Micheil: yeah...
[01:15] ryah: seems a bit difficult to do
[01:16] ryah: what i'd like is a blocking wait()
[01:16] ryah: which i could replace with the current wait
[01:17] Micheil: hmm..
[01:17] benw: Can anyone explain this from node.cc:
[01:17] benw: Local uncaught_exception_symbol_l = Local::New(uncaught_exception_symbol);
[01:18] ryah: cast from Persistent
[01:19] benw: So the arguments to listeners->Call must be Local not Persistent?
[01:20] ryah: i guess
[01:20] benw: Fair enuf
[01:23] steadicat has joined the channel
[01:27] mahemoff has joined the channel
[01:34] stevestmartin has joined the channel
[01:44] benw: Error: Unhandled emitError
[01:44] rtomayko has joined the channel
[01:49] un0mi has joined the channel
[02:01] paulca has joined the channel
[02:04] ryah: isaacs: need a async benching tool
[02:04] ryah: with a done() cb
[02:05] isaacs: ryah: could be done.
[02:06] isaacs: just need to rejigger the loop-with-wait into a .done-with-callback
[02:06] isaacs: i just took what i already had and factored it a teeny bit.
[02:16] isaacs: ryah: do you have a use case that you need to benchmark asynchronously?
[02:17] kennethk_ has joined the channel
[02:17] isaacs: as i'm thinking about it, node-bench as i have it right now isn't very useful without isolating the tests from one another (so they're not affecting one another) and that kinda means running them one after the other, so it's sync by nature.
[02:20] ryah: isaacs: have you checked out the bencharmks directory?
[02:20] ryah: in node?
[02:20] isaacs: nope
[02:20] isaacs: ACTION looking
[02:20] ryah: "make benchmark"
[02:22] isaacs: is ee
[02:23] isaacs: see, the problem is, that's testing how long it takes to run something, whereas benchmarking at a lower level is better done by testing how many times you can do something in a given tie.
[02:23] isaacs: *time
[02:23] isaacs: and then averaging out procs/sec
[02:24] isaacs: node-bench (as it is now) tries to give you the answer to "which of these approaches is best, and by how much"
[02:25] ryah: require("bench").bench(function (done) { setTimeout(function () { done(); }, 1); })
[02:26] ryah: require("bench").bench({"setTimeout": function (done) { setTimeout(function () { done(); }, 1); }, "nextTick": function (done) { nextTick(function () { done() }); }})
[02:26] isaacs: gotcha
[02:27] isaacs: kk, i can do that, i think.
[02:28] isaacs: the script as a whole will still be sync, but i'll just chain them one after another, and then if you give me a "done" function, i'll run that at the end with the results, with the default "done" function being the bench.show function that outputs the scores.
[02:28] isaacs: but, yah, testing nextTick vs setTimeout seems like a good use case.
[02:32] isaacs: so it'd look like: exports.compare={nextTick:function(d){ nextTick(d) }, setTimeout: function(d) { setTimeout(d) } }
[02:34] ryah: isaacs: i also think node-bench should be available as a library so people can embed it in their programs
[02:34] ryah: somehow
[02:34] ryah: but yeah..
[02:34] isaacs: k, i can do that
[02:34] bpot has joined the channel
[02:34] isaacs: actually, if you just put node-bench/bench.js in your NODE_PATHS, then it'll work with require("bench")
[02:35] isaacs: erm, lib/bench.js
[02:47] robrighter has left the channel
[02:49] bentomas has joined the channel
[02:51] isaacs: ryah_away: so, turns out, that's not so good for testing very fast things.
[02:51] isaacs: ie, where the delta between A and B is smaller than the overhead of nextTick or setTimeout or whatever I use.
[02:54] mikeal: i'm actually about to do something like this
[02:54] mikeal: i have another vector I need to worry about tho, so this won't work
[02:54] isaacs: oh, hey, doy. i can just run it a bunch of times first.
[02:55] isaacs: oh, but that won't work for testing nextTick vs setTimeout, for example..
[02:58] isaacs: ie, when testing nextTick vs setTimeout, you want to know "how soon does the cb get fired". when testing function.call vs function.apply, you wnat to know "how much overhead is involved in this action"
[02:58] isaacs: mikeal: what's your use case?
[03:01] mahemoff has joined the channel
[03:02] mikeal: isaacs: performance testing couchdb
[03:02] mikeal: so i wrote a concurrent client in node
[03:03] mikeal: and i need to chart the average response time under load from 1 − 5 minutes
[03:03] mikeal: then chart that against the latest release and the latest trunk
[03:03] mikeal: so you can see how your current git branch stacks up
[03:03] mikeal: but what I really care about is the **difference** between the versions
[03:04] mikeal: because i rerun the baseline every time i run the tests in order to eliminate other factors that creep in to the box over time
[03:04] mikeal: and i don't have to store a permanent baseline
[03:04] isaacs: right, i see what you mean
[03:04] mikeal: the client is already working fine
[03:05] mikeal: what i'm working on now is TestBot
[03:05] mikeal: which is a system to manage all the boxes and handle cross box communication and results storage, etc
[03:09] kriszyp_ has joined the channel
[03:10] sprsquish has joined the channel
[03:20] binary42 has joined the channel
[03:24] isaacs: ryah_away: how about this: if you return a promise, i'll add a callback to run the next iteration. otherwise, i'll just run it 1000 times before checking the clock.
[03:24] bentomas: I made a simple script for testing async code and am curious as to whether or not anybody thinks it has potential. I don't know if I'm trying to solve the right problem or not: http://github.com/bentomas/node-asyncTesting
[03:27] isaacs: ryah_away: http://github.com/isaacs/node-bench/blob/async-bench/examples/nexttick-vs-settimeout.js how about this?
[03:27] isaacs: (also, turns out that nextTick is way faster, btw.)
[03:32] isaacs: bentomas: i'm usually afraid of capitalized letters in filenames.
[03:32] isaacs: would you be very opposed to using async-testing.js instead?
[03:33] bentomas: yeah, you're completely right. no not at all
[03:33] bentomas: I'm not even all that attached to the name
[03:33] isaacs: looks handy, though
[03:34] bentomas: well, I wish using it was a little more elegant, but I think the ideas might be useful
[03:34] bentomas: I don't know. I'll give it a try in a couple projects and see how I like it
[03:35] isaacs: are you familiar with spectacular or yuitest?
[03:35] isaacs: http://github.com/hassox/spectacular/
[03:37] bentomas: I looked at spectacular, I'm not crazy about the "describe" and "it…should" syntax, so I didn't look into it too deeply
[03:37] bentomas: is it good?
[03:37] isaacs: seems to work. hassox lifted the rspec syntax from ruby, i believe.
[03:38] bentomas: yeah, that's where I've seen/used it before. I don't like rspec :)
[03:38] isaacs: hehe
[03:40] bentomas: looks interesting
[03:40] jamiew has joined the channel
[03:40] bentomas: yuitest appears to be just for in a browser environment...
[03:40] bentomas: "YUI Test is a testing framework for browser-based JavaScript solutions. " http://developer.yahoo.com/yui/3/test/
[03:41] isaacs: bentomas: that is true.
[03:41] isaacs: but it's got some good ideas in it.
[03:41] isaacs: i think if you read through the description, you'll get some inspiration.
[03:41] bentomas: I'm on it!
[03:42] isaacs: ^_^
[03:42] isaacs: i've used yuitest quite a bunch. it's good mojo.
[03:48] bentomas: I didn't know you could look at func.length to see how many arguments a function takes. that's cool
[04:09] eddanger has joined the channel
[04:10] hassox has joined the channel
[04:13] bentomas: For those that are curious, I changed the name to be lowercase: http://github.com/bentomas/node-async-testing
[04:14] bentomas: so the old link won't work. And I'd still welcome feedback!
[04:19] bentomas has left the channel
[04:22] steadicat has joined the channel
[04:28] isaacs has joined the channel
[04:29] dnolen has joined the channel
[04:39] bentomas has joined the channel
[04:40] bentomas: How are people documenting their code? I looked into Doxygen, by it sounds like it is a pain to get that working with Javascript. I don't like the output of Natural docs. Any suggestions?
[04:40] mikeal: umn...
[04:40] mikeal: atul wrote something a while ago
[04:40] mikeal: here it is
[04:40] mikeal: http://www.toolness.com/wp/?p=441
[04:40] bentomas: oh nice!
[04:41] bentomas: thanks!
[04:42] mikeal: np
[04:45] mattly has joined the channel
[04:45] ryah_away: isaacs: how much faster?
[04:45] isaacs: ryah_away: about twice.
[04:46] isaacs: (running again...)
[04:46] isaacs: 56.2% faster
[04:46] isaacs: 2.28 times as fast
[04:46] isaacs: 182.969569733912 vs 80.14201288350519
[04:47] isaacs: what that means, btw, is that you can only actually do about 80 setTimeouts per second.
[04:47] isaacs: so setTimeout(fn, 1) is effectively identical to setTimeout(fn, 100)
[04:47] ryah_away: :)
[04:47] ryah_away: what about with "0" ?
[04:47] isaacs: i was calling it without any timeout
[04:48] ryah_away: that's pretty crappy
[04:48] isaacs: here's the test: http://github.com/isaacs/node-bench/blob/master/examples/nexttick-vs-settimeout.js
[04:48] ryah_away: i wonder what the bottle neck in that is
[04:48] ryah_away: what if you do it without the promise?
[04:48] isaacs: probably there's some extra overhead in just tossing the promise around.
[04:48] isaacs: because i want to support both sync and async cases
[04:49] ryah_away: yeah
[04:49] isaacs: and, if you're testing fn() vs fn.call(), then it gets lost in the overhead of calling the callback.
[04:49] isaacs: very fast things are better tested synchronously, and many times in a row for each pass.
[04:50] ryah_away: yeah
[04:50] isaacs: lemme up the count and the time to see if that settles out the overhead some..
[04:50] ryah_away: maybe you should have a syncBench and asyncBench
[04:50] ryah_away: i'd like to see it with a done() callback instead of promise
[04:51] mikeal: ryah_away: make that one site, the other site turned off invites :(
[04:51] Yuffster has joined the channel
[04:52] isaacs: ryah_away: i could also just have a "sync" field that takes a boolean.
[04:52] isaacs: so, the promise overhead is insignificant.
[04:53] isaacs: just ran the test again with 10000 iterations per lap and had it go for 10000 ms. almost the same numbers.
[04:57] benw: ACTION is having some success with the exception handling stuff
[05:07] kriszyp has joined the channel
[05:24] cloudhead has joined the channel
[05:27] benw: If I throw inside an uncaughtException handler, will FatalException be reentered?
[05:30] ryah_away: i think so
[05:30] Pilate: is there a simple way to remove the keep-alive header on an http response?
[05:31] ryah_away: Pilate: send a connection: close header
[05:31] benw: I've got process.catcher working beautifully, but I've failed to make it play nicely with uncaughtException.
[05:31] Pilate: cant get rid of it entirely though?
[05:32] ryah_away: Pilate: if you send "Connection": "close" it wont send keep-alive
[05:34] Pilate: aye, the connection:close isnt going over well on the client though, seems to be pretty particular
[05:34] ryah_away: ?
[05:35] ryah_away: what's it doing? what client?
[05:35] Pilate: dont have control over the client source, trying to emulate the server response
[05:36] benw: Ah, my bad
[05:44] alex-desktop has joined the channel
[06:07] benw: Woop!
[06:09] mikeal has joined the channel
[06:12] dkubb has joined the channel
[06:14] RayMorgan has joined the channel
[06:15] eddanger has joined the channel
[06:17] cloudhead: any reason why my promises are executing instantaniously since I updated node?
[06:17] benw: I think "uncaughtException" is weird, because zero listeners means the program barfs on exception, but one or more listeners means all exceptions are considered handled at the top level.
[06:19] onar has joined the channel
[06:24] r11t has joined the channel
[06:25] benw: Woop! http://github.com/benw/node/commit/78b69e750b7fdd3a22ed51eafb1bc1fceee7d0ec
[06:26] cloudhead: isn't the promise success callback supposed to emit on the next tick?
[06:26] isaacs has joined the channel
[06:26] cloudhead: did anything change in there?
[06:27] cloudhead: It used to be that if I had a bunch of addCallbacks in a row, the code would execute to the end, and only once that was done would the callbacks be called
[06:27] benw: Here's what the above commit lets me do: http://gist.github.com/283552
[06:27] bentomas: benw: do you have an example of using process.exceptionCatcher in action?
[06:28] bentomas: ahh! perfect!
[06:28] benw: :)
[06:31] benw: bentomas: That example making sense?
[06:32] benw: Here's the output: http://gist.github.com/283555
[06:33] dkubb has left the channel
[06:37] isaacs: benw: so it captures the value of exceptionCatcher when the callback is registered?
[06:37] benw: Yep
[06:38] isaacs: benw: is that reference ever dropped?
[06:38] isaacs: or does the callback function have to fall out of scope for it to be gc'ed?
[06:38] benw: It's collected once the callback function is collected
[06:38] isaacs: i see...
[06:39] isaacs: well, assuming that process doesn't still link to it, of course
[06:39] benw: yeah
[06:39] benw: or other callbacks etc
[06:39] isaacs: i'd be nervous about that functionality, simply because it seems like a magic way to save state, which could be problematic in high-load situations.
[06:40] isaacs: i mean, saving state is great when you need to do that, but it feels scary to have it happen when the code doesn't look like it's saving state, you know?
[06:41] cloudhead: is there a way I can get around the late promise callback binding?
[06:41] benw: I think you'll only run into problems if you recursively explicitly set process.exceptionCatcher to some new value.
[06:41] cloudhead: it's screwing up my code
[06:41] benw: I gotta run
[06:41] isaacs: k, i'll review more and email or comment or something
[06:41] benw: isaacs: Interested in discussing further though
[06:41] benw: Great, thanks
[06:41] isaacs: benw: absolutely! :)
[06:42] benw: Cya
[06:42] isaacs: cloudhead: gist?
[06:43] rictic has joined the channel
[06:43] cloudhead: well it's just that I'm running some tests on the promises, but I need them to execute asyncrhonously
[06:43] isaacs: cloudhead: i meant, can you put a code sample on gist.github.com or pastie?
[06:43] cloudhead: yea I know, lemme do that
[06:44] isaacs: kk :)
[06:44] isaacs: (wasn't sure if you thot i meant "what's the gist of your problem", if you've been under a rock and hadn't heard of github or something)
[06:44] isaacs: you can always use process.nextTick to *make* something async
[06:45] cloudhead: hehe
[06:45] cloudhead: well, I tried to use that, but doesn't seem to do anything
[06:46] cloudhead: I have a wrapper around addCallback
[06:46] cloudhead: hm
[06:48] cloudhead: https://gist.github.com/02c266dc16d9986274d0
[06:48] cloudhead: something like this
[06:48] cloudhead: except I need all the tests() to run before the success events are emitted
[06:48] cloudhead: which used to be the case in 0.1.25
[07:06] dnolen has joined the channel
[07:12] lifo has joined the channel
[07:12] kennethkalmer has joined the channel
[07:22] isaacs: cloudhead: what's "promise" that youer' attaching this "test" function to?
[07:23] cloudhead: isaacs: ah sorry, that should be events.Promise.prototype
[07:23] cloudhead: I think I found the problem though
[07:23] cloudhead: but I dont understand
[07:23] cloudhead: it's 'ticking' for no reason
[07:24] cloudhead: as in, executing my nextTick before finishing what I consider the current tick
[07:24] cloudhead: is there anything that could potentially do that?
[07:24] isaacs: testing now.
[07:25] cloudhead: console output maybe?
[07:25] cloudhead: I can't reproduce it though : /
[07:28] isaacs: cloudhead: i'm not sure i follow.
[07:28] isaacs: nextTick always seems to occur after the current chain of events.
[07:28] isaacs: can you make a self-contained test case that shows the problem?
[07:28] isaacs: are you perhpas writing one to stdout and the other to stderr and creating a race condition?
[07:29] mikeal has joined the channel
[07:29] cloudhead: hmmmm yes that's possible
[07:30] isaacs: cloudhead: this works for me: http://gist.github.com/283571
[07:31] cloudhead: https://gist.github.com/02c266dc16d9986274d0
[07:31] cloudhead: here's what I'm getting
[07:31] cloudhead: now to figure out why..
[07:31] cloudhead: yea, yours is behaving as expected
[07:32] isaacs: this works too: http://gist.github.com/283571
[07:32] isaacs: so, writing to stdout is async
[07:32] isaacs: that's what's happening
[07:34] isaacs: try it with sys.debug or sys.error and you'll get different results.
[07:34] cloudhead: getting the same pattern with debug
[07:35] isaacs: hmm....
[07:38] cloudhead: omg
[07:38] cloudhead: figured it out : /
[07:39] cloudhead: I had a require('uri').parse()
[07:39] cloudhead: inside the code somewhere
[07:39] isaacs: ok...?
[07:40] isaacs: where's the get() function?
[07:40] isaacs: can you show me that?
[07:40] cloudhead: well, it must have been causing a tick
[07:40] cloudhead: moving it out to the top fixed the problem
[07:40] isaacs: no, i'm about as sure as i can be that require("url").parse is sync
[07:40] cloudhead: oh
[07:40] cloudhead: hm
[07:40] isaacs: and, last i checked, js is single threaded.
[07:41] mikeal has joined the channel
[07:41] isaacs: maybe your first get("/") is returning a promise that is emitting true right away.
[07:41] isaacs: emitting success, i mea
[07:41] cloudhead: the emitSuccess is inside a nextTick
[07:41] cloudhead: in get()
[07:41] cloudhead: but moving the require in an out of it
[07:41] cloudhead: changes the order of evaluation
[07:42] cloudhead: lemme see if I can reproduce it in a small test
[07:42] isaacs: because this works fine: http://gist.github.com/283571
[07:42] isaacs: oh, it's the require()
[07:43] isaacs: erm... maybe...
[07:43] isaacs: yeah, that's it
[07:43] cloudhead: yea
[07:43] isaacs: put require()s at the top of your modules, always.
[07:44] cloudhead: https://gist.github.com/7e6934267bb99414478b
[07:44] cloudhead: yea, I usually do, but for this one, I was doing a quick fix because of the recent chagne
[07:44] cloudhead: change*
[07:45] cloudhead: and didn't think this could be a consequence
[07:45] cloudhead: now I know not to mess around with requires : D
[07:45] isaacs: cloudhead: well, it's fine if themodule is already loaded, actually.
[07:45] isaacs: oh, no, wait, nvm
[07:45] isaacs: calling require() after the module setup is just a bad idea, it seems, if you care about synchronicity of your output.
[07:47] isaacs: really, anything with a .wait()
[07:47] isaacs: wait is very magical.
[07:47] cloudhead: yea
[07:48] cloudhead: well, thanks for your help dude
[07:48] cloudhead: much appreciated
[07:48] cloudhead: was going crazy
[07:54] jamiew_ has joined the channel
[07:59] mikeal has joined the channel
[08:04] qFox has joined the channel
[08:06] shfx has joined the channel
[08:06] shfx has left the channel
[08:14] felixge has joined the channel
[08:28] zmoog has joined the channel
[08:42] piranha has joined the channel
[08:54] DamZ has joined the channel
[08:59] felixge has joined the channel
[09:07] DamZ has joined the channel
[09:08] paulca has joined the channel
[09:22] binary42 has joined the channel
[10:05] tisba has joined the channel
[10:14] ayo has joined the channel
[10:25] spoob_ has joined the channel
[10:32] markwubben has joined the channel
[10:33] tisba has joined the channel
[10:39] BradleyS has joined the channel
[10:53] mahemoff has joined the channel
[10:57] jfd has joined the channel
[11:19] blackdog has joined the channel
[11:23] DamZ has joined the channel
[11:27] sveimac_ has joined the channel
[11:41] erichocean has joined the channel
[11:45] kriszyp has joined the channel
[11:51] mahemoff_ has joined the channel
[11:52] un0mi has joined the channel
[11:56] charlenopires has joined the channel
[12:02] Micheil: Can you have more then one process.inherits?
[12:18] Micheil: ryah_away: how can you include node_natives.h in node.cc when there's no file node_natives.h?
[12:18] Micheil: ryah_away: also, where's tcp.cc / tcp.h meant to be?
[12:19] Micheil: or is tcp.cc / tcp.h really node_net.cc / node_net.h
[12:19] Micheil: ?
[12:25] DamZ has joined the channel
[12:42] alex-desktop has joined the channel
[12:43] piranha has joined the channel
[12:45] Micheil: hmm.. note to self.. make distclean is bad.
[12:51] Micheil: ryah_away: reading thought some of the net2 branch, it looks like a lot is changing, especially in the node.cc / node.h / node.js area
[13:15] deanlandolt has joined the channel
[13:21] paulca has joined the channel
[13:21] tisba has joined the channel
[13:22] Micheil: inimino: are you about?
[13:23] pmuellr has joined the channel
[13:24] Micheil: ryah_away: is fs-sendfile experimental?
[13:24] Micheil: I've got memory errors in that module when running the tests.
[13:33] markwubben has joined the channel
[13:39] steadicat has joined the channel
[13:41] paulca has joined the channel
[14:09] inimino: Micheil: yes
[14:10] Micheil: are you running HEAD?
[14:10] charlenopires_ has joined the channel
[14:10] inimino: yes
[14:10] inimino: as of yesterday or so, at least
[14:12] Micheil: okay, run the tests, tell me if you get a mem alloc error
[14:12] Micheil: hmm.. node.js is featured in The Changelog podcast this week
[14:12] davidsklar has joined the channel
[14:13] Micheil: Path: mjsunit/test-fs-sendfile
[14:13] Micheil: Error: Cannot allocate memory
[14:14] inimino: http://www.pastie.org/789762
[14:15] Micheil: woah
[14:15] Micheil: inimino: try pulling the latest..
[14:16] inimino: building now
[14:17] mediacoder: Micheil: just built and run all tests successfully
[14:17] mediacoder: *ran
[14:17] Micheil: hmm..
[14:17] n8o has joined the channel
[14:22] kennethkalmer has joined the channel
[14:22] dnolen has joined the channel
[14:35] inimino: ah...
[14:35] inimino: ACTION runs tests
[14:36] sixtus42 has joined the channel
[14:36] inimino: http://www.pastie.org/789791
[14:37] Micheil: that's not good.
[14:37] inimino: that's about what I always see when I run make test
[14:37] inimino: not sure if it's looking better for anyone else
[14:38] inimino: in the past some of the tests failed because all the HTTP tests seem to use different randomly chosen ports
[14:38] inimino: some of which were in use
[14:39] Micheil: http://www.pastie.org/789795
[14:39] inimino: that should really be cleaned up
[14:40] kennethkalmer has joined the channel
[14:40] inimino: Micheil: how much memory is available?
[14:40] Micheil: 4gb's
[14:41] Micheil: this is on my MBP
[14:41] inimino: it's probably not that then
[14:41] inimino: bbl
[14:43] Micheil: ln985 is the core process.loop
[14:46] Booster has joined the channel
[14:49] bryanl has joined the channel
[14:55] cloudhead has joined the channel
[14:59] sixtus42 has joined the channel
[15:16] bry has joined the channel
[15:16] fictorial has joined the channel
[15:24] steadicat has joined the channel
[15:24] felixge has joined the channel
[15:24] xantus has joined the channel
[15:26] kennethkalmer has joined the channel
[15:29] felixge: Micheil: I'm getting the memory fail as well
[15:29] felixge: but I've been getting that on and off
[15:29] felixge: inimino: did you ever make distclean + re-configure?
[15:29] felixge: afaik you need to do that when v8 is updated
[15:32] davidsklar has joined the channel
[15:39] jed_ has joined the channel
[15:40] kriszyp has joined the channel
[15:44] dnolen has joined the channel
[15:49] cloudhea has joined the channel
[15:53] fictorial has joined the channel
[16:05] alexiskander has joined the channel
[16:06] olivierG has joined the channel
[16:18] sixtus42 has joined the channel
[16:20] qFox has joined the channel
[16:25] PowerToExt has joined the channel
[16:29] joshbuddy has joined the channel
[16:31] joshbuddy has joined the channel
[16:32] bentomas has joined the channel
[16:33] DamZ has joined the channel
[16:34] DamZ has joined the channel
[16:34] olivierG has left the channel
[16:35] jamiew has joined the channel
[16:36] DamZ has joined the channel
[16:37] DamZ has joined the channel
[16:39] DamZ has joined the channel
[16:40] hornbeck has joined the channel
[16:44] Yuffster has joined the channel
[16:44] bpot has joined the channel
[16:48] DamZ has joined the channel
[16:49] DamZ has joined the channel
[16:50] gf3 has joined the channel
[16:52] RayMorgan has joined the channel
[16:59] DamZ has joined the channel
[17:04] JimBastard has joined the channel
[17:10] dnolen has joined the channel
[17:27] DamZ has joined the channel
[17:36] sudoer has joined the channel
[17:40] jtoy has joined the channel
[17:50] jacobolus has joined the channel
[17:52] joshbuddy has joined the channel
[17:52] scudco has joined the channel
[17:57] webben has joined the channel
[18:04] rictic has joined the channel
[18:05] stephenlb has joined the channel
[18:14] aguynamedben has joined the channel
[18:14] CIA-78: node: 03Felix Geisendörfer 07master * ra76c7a8 10/ (doc/api.txt src/node.js test/mjsunit/test-module-loading.js):
[18:14] CIA-78: node: Implemented __dirname
[18:14] CIA-78: node: It seems that the current __filename module global is mainly used to
[18:14] CIA-78: node: determine the directory the current module is in. To make that
[18:14] CIA-78: node: easier, this patch adds support for a __dirname module global
[18:14] CIA-78: node: directly. - http://bit.ly/62Ggra
[18:15] onar has joined the channel
[18:16] BBBB has joined the channel
[18:40] jacobolus has joined the channel
[18:52] binary42 has joined the channel
[18:55] inimino: http://www.pastie.org/790149
[18:56] inimino: Micheil, felixge: ↑
[18:56] inimino: (after make distclean)
[18:56] inimino: I think it's the same as before, actually
[18:56] inimino: no memory error
[19:10] paulca has joined the channel
[19:15] felixge has joined the channel
[19:21] gwoo has joined the channel
[19:23] cdorn has joined the channel
[19:31] felixge: ryah_Away: yt?
[19:31] ryah_Away: yeah
[19:31] felixge: ryah: how do you feel about this: http://github.com/felixge/node/commit/2cf20ee8fbb70588fd10d33c12939b0eed4355dd ?
[19:32] felixge: oh shit, nevermind my copy & paste fail in the api.txt, fixing that
[19:33] felixge: ryah: proper version: http://github.com/felixge/node/commit/dd68c870dee2248d9338f461fd2d8851bdb27701
[19:33] ryah: felixge: seems unnecessary
[19:34] felixge: I was thinking wether all errors should be instanceof Error and if that should be the way to distinguish them, but I think that'd be wrong. You can throw any object, so emitError() should accept any object as well
[19:34] felixge: ryah: you think so?
[19:34] felixge: ryah: how would you handle shared logic that needs to run on the completion of a promise regardless the outcome?
[19:34] felixge: so far I had to use helper functions for that
[19:34] ryah: hm
[19:35] ryah: yeah, with helper functions
[19:35] ryah: also, doens't dojo addBoth() do something different?
[19:35] felixge: I mean this is essentially the same as "finally" in a try..catch block
[19:36] felixge: ryah: the only difference is that dojo converts anything thats passed to emitError into an instance of Error
[19:36] felixge: so there isn't a need for a first parameter that indicates if there was an error or not
[19:36] felixge: but I think thats wrong because not all data structures convert well to error objects
[19:36] felixge: nor is it efficient to do
[19:36] felixge: nor is it in sync with how functions exceptions work
[19:37] felixge: * function exceptions
[19:37] felixge: that's why there is the first parameter
[19:37] felixge: dojo also has a 'addCallbacks' which is the same as CommonJS.then(), but I don't see us needing that
[19:39] ryah: oh, i confused it with addCallbacks
[19:39] felixge: yeah
[19:40] felixge: I don't think we absolutely need addBoth() either, but its very convenient when you need it and the implementation is very straight-forward
[19:41] ryah: i'd rather not add it
[19:41] felixge: ok, I'll count how often I run into needing it over the next weeks and will bring it up again depending on that
[19:41] felixge: deal?
[19:42] ryah: :)
[19:42] ryah: okay
[19:42] felixge: k, lets do it : )
[19:43] felixge: alright, heading out to start some non-blocking beer processes : )
[19:44] felixge: see ya
[19:45] ryah: lata
[19:53] technoweenie has joined the channel
[20:05] gf3 has joined the channel
[20:08] dnolen has joined the channel
[20:19] joshbuddy has joined the channel
[20:34] mikeal has joined the channel
[20:43] joshbuddy has joined the channel
[21:10] jacobolus has joined the channel
[21:12] gf3 has joined the channel
[21:14] gf3 has joined the channel
[21:16] gf3 has joined the channel
[21:18] xavier___ has joined the channel
[21:18] xavier___: ah here it is
[21:18] xavier___: not node, not nodejs
[21:19] xavier___: node.js
[21:19] xshay: ryah: what's the go with amqp?
[21:20] ryah: xshay: hey
[21:21] ryah: xshay: i'm just trying to figure out the best way to use it
[21:22] ryah: i've looked at your node-amqp but the parsing is not interruptable
[21:22] cloudhead has joined the channel
[21:23] xshay: ryah: I've got some other code here that parses it with ragel in a c extension
[21:23] JimBastard has joined the channel
[21:23] xshay: ryah: fairly certain that's interruptable, coz it processes streams, you just hand it chunks at a time?
[21:24] ryah: i want to be able to call it one byte at a time
[21:25] xshay: ryah yeah I think it meets that criteria. I ran into problems though with no binary data in V8 :(
[21:25] ryah: xshay: yeah - i have a new branch (called net2) which does binary differently
[21:25] xshay: I'll upload it somewhere, hold on
[21:25] ryah: okay
[21:26] mikeal has joined the channel
[21:33] xshay: ryah: http://github.com/xaviershay/node-amqp-ragel
[21:34] xshay: ryah: two branches, master and amqp. I think amqp was me trying to get binary data passing working.
[21:34] mattly has joined the channel
[21:35] xshay: ryah: sorry it's all a bit shit, I never polished it up
[21:36] xshay: ryah: if you move the int res; var out into a persistent variable, I reckon it could parse byte by byte
[21:37] xshay: I can't exactly remember which var ragel keeps state in
[21:38] cheapRoc has joined the channel
[21:41] inimino has joined the channel
[21:42] ryah: xshay: cs
[21:42] ryah: (iirc)
[21:44] xshay: ryah: oh yeah right, that's already an ivar, so should be fine
[21:46] Yuffster_ has joined the channel
[21:49] aguynamedben has joined the channel
[21:54] konobi: ryah: have you got an amqp server running or do you need something setup?
[21:56] ryah: konobi: i have one
[21:57] inimino` has joined the channel
[21:57] konobi: ryah: gd gd... trixx is also a pretty reasonable way to get a GUI insight into what's going on within rabbitmq
[21:59] voodootikigod has joined the channel
[22:00] ryah: konobi: okay
[22:16] benw has joined the channel
[22:20] rtomayko has joined the channel
[22:21] benw has joined the channel
[22:22] joshbuddy has joined the channel
[22:33] gwoo_ has joined the channel
[22:38] mikeal: ok
[22:38] mikeal: i wrote a spec
[22:39] mikeal: that competes with JSGI
[22:39] mikeal: http://github.com/mikeal/ngi/blob/master/spec.mkd
[22:39] mikeal: but is node.js specific
[22:39] mikeal: and a lot nicer/cleaner
[22:39] mikeal: and avoids all the crap in WSGI that never should have ended up in JSGI
[22:40] mikeal: sent an email to the list
[22:41] ryah: mikeal: i think headers should be created before res.start()
[22:41] kriszyp: mikeal: did you send it to the commonjs list?
[22:41] ryah: so that the res object can be passed around and headers added
[22:41] kriszyp: we have been hoping to have a spec for something more node-ish
[22:41] ryah: before actually replying
[22:42] ryah: res.headers.push(["content-type", "text/plain"])
[22:42] ryah: res.start(200)
[22:42] ryah: res.write("blah")
[22:42] mikeal: it's node specific, so i didn't send it to the commonjs list
[22:42] ryah: res.end()
[22:43] ryah: also something like res.hasStarted ?
[22:43] ryah: a boolean
[22:43] ryah: some readyState
[22:43] tlrobinson: no middleware?
[22:44] tlrobinson: that's one of the most interesting parts of the *GI's IMO
[22:44] mikeal: yeah, a readystate is a good idea
[22:44] kriszyp: IMO, I think it would be cool to have a spec sometime for node's type of http interface, (aka "HTTP Event Interface")
[22:44] ashb: mikeal its not a spec unless there is more than one implementation
[22:45] tlrobinson: kriszyp: i agree, though if possible it should share things line the request objects
[22:45] mikeal: ashb: gotta start somewhere
[22:45] mikeal: i'm going to write a reference implementation this weekend
[22:45] ashb: mikeal: sure :)
[22:45] ashb: request.request_method
[22:46] CIA-78: node: 03David Sklar 07net2 * r6f738d6 10/ test/mjsunit/test-net-fd-passing.js : Adjust passing-FDs test to wait until socket is really writeable - http://bit.ly/8lFnJd
[22:46] ashb: the request_ there seems duplicated to me
[22:46] konobi: ashb: hey ash
[22:46] jasondavies has joined the channel
[22:47] ashb: konobi: what are you doing in here
[22:47] inimino: mikeal: what's protocol?
[22:47] ashb: konobi: trying to confuse me aren't you
[22:47] mikeal: tlrobinson: the WSGI specification itself doesn't support middleware, there are bunch of conventions strapped on to WSGI that do middleware
[22:47] mikeal: i have comments at the end about supporting middleware
[22:47] konobi: ashb: joyent is investing with node.js
[22:47] konobi: =0)
[22:47] ashb: heh
[22:47] mikeal: inimino: the HTTP protocol version, 1.0 or 1.1
[22:48] ashb: mikeal: http protocol is not a number
[22:48] ashb: its 2 numbers
[22:48] ashb: go read the bit of the HTTP RFC
[22:48] mikeal: ashb: so, the problem with using .method
[22:48] mikeal: is that people who love Crockford add Object.prototype.method
[22:48] mikeal: for dynamically adding new methods to objects
[22:48] konobi: ashb: btw... any luck with commonjs on smart?
[22:48] ashb: mikeal: can go fuck themselves for puttung things on Object.prototype
[22:48] mikeal: which is why I use request_method instead
[22:48] ashb: konobi: its somewhere near the top of my stack
[22:49] inimino: mikeal: why is content-length a string?
[22:49] kriszyp: I've never heard of a Crockford-ism for Object.prototype.method, what does he recommend there?
[22:49] mikeal: ryah: that's a good idea
[22:49] mikeal: initializing res.headers
[22:49] mikeal: inimino: ahh, good catch, fixing
[22:50] inimino: mikeal: ok, call it version then, and it's ... what ashb said
[22:50] inimino: Object.prototype.method?
[22:50] inimino: I haven't even heard of it
[22:50] mikeal: it's the his book "JavaScript: the good parts"
[22:50] mikeal: which is pretty damn popular
[22:50] mikeal: Object.prototype.method = function (name, meth) {this[name] = meth}
[22:51] mikeal: is what he has
[22:51] inimino: mikeal: it seems excessive to have both content_type and content_length but not parse the rest of the headers
[22:51] kriszyp: yeah, I have it, but I don't rembember a Object.prototype.method method
[22:51] kriszyp: ah, ok
[22:51] mikeal: inimino: applications access those headers more than any other header, and headers has to be a array or 2 length arrays because the keys aren't necessarily unique, so pulling out a header is kind of annoying
[22:52] inimino: mikeal: also, s/array of 2 length arrays/array of length 2 arrays/g
[22:52] inimino: or "array of length-2 arrays"
[22:52] mikeal: parsing the rest of the headers also seems inefficient since most applications will never look at them
[22:52] RayMorgan has joined the channel
[22:52] mikeal: thanks for clarifying that inimino cause my eyes were going buggy trying to read the replace statement :)
[22:53] inimino: why would Crockford of all people write a method just to do assignment?
[22:53] inimino: gah
[22:53] inimino: anyway, that's idiotic, whatever it is, don't base naming kludges on it
[22:54] inimino: mikeal: yeah, I realize that
[22:54] inimino: mikeal: but I think you should either go low-level and not parse any of them, or parse them all and give a nice object like node gives you
[22:55] inimino: (if you parse them of course you have to decide what to do with duplicates, etc)
[22:55] inimino: btw I seem to have some kind of horrible lag in case my replies appear late...
[22:56] mikeal: so, i actually have really strong opinions about he headers parsing
[22:56] inimino: (like, uh, a minute late, ugh)
[22:56] mikeal: because I've dealt a lot with implementating proxies
[22:56] mikeal: if someone on the Application side, like a web framework, wants to create a nicer object that's a good idea
[22:57] mikeal: but the server should not be stepping on the headers
[22:57] mikeal: and the gateway interface shouldn't specify how to merge headers
[22:58] inimino: two minutes late actually :(
[22:59] inimino: that sounds reasonable
[23:01] mikeal: ok, updates made, pushed
[23:01] inimino: ok
[23:01] inimino: so I'd just not parse any of them in that case, and let some higher-level thing deal with it
[23:02] inimino: mikeal: I think it's great that you're starting this
[23:02] mikeal: inimino: this is different
[23:02] mikeal: because content-type and content-length can't be sent more than once
[23:03] mikeal: HTTP says only one will ever win
[23:03] inimino: mikeal: I'd rename it AGI or something and post it to the CommonJS list too
[23:03] inimino: at least once other node people are happy with it
[23:03] mikeal: so it helps to explicitly call out which one is going to win
[23:03] mikeal: it's not just async
[23:03] mikeal: it specifies usage of EventEmitter and Promises
[23:04] mikeal: which are node specific
[23:04] mikeal: if someone with intricate knowledge of async in other platforms wants to get involved then I'd feel a little more confident about taking on the responsibility of making the specification not specific to node
[23:05] dnolen has joined the channel
[23:05] mikeal: the purpose of the spec is to provide a path to compliance, and I can't write a spec that provides compliance to a bunch of alternate environments I have very little working knowledge of
[23:06] inimino: mikeal: Promises are not node-specific, in fact they predate node by quite a bit
[23:06] inimino: ok
[23:07] inimino: well, fair enough, but I'd change the name even so :-)
[23:07] mikeal: haha
[23:07] mikeal: i might after it matures
[23:08] mikeal: i want it to do exactly what its trying to do for node
[23:08] mikeal: and if after that is stable and a little proven we want to add to it to help provide for other environments, that's great
[23:09] mikeal: man, GitHub has a really nice default styling for markdown
[23:09] jfd_ has joined the channel
[23:11] inimino: sure
[23:16] jed has joined the channel
[23:17] mattly has joined the channel
[23:18] inimino` has joined the channel
[23:19] inimino` has joined the channel
[23:21] inimino` has joined the channel
[23:27] inimino has left the channel
[23:31] jacobolus has joined the channel
[23:52] pjb3 has joined the channel
[23:54] paulca has joined the channel
[23:56] dnolen has joined the channel
[23:59] jfd has joined the channel