[15:34] nodelog has joined the channel
[15:34] felixge_: welcome back nodelog 
[15:35] nodelog has joined the channel
[15:35] felixge_: !!log
[15:35] felixge_: !log
[15:35] felixge_: ah ok
[15:35] felixge_: good
[15:38] pmuellr has joined the channel
[15:51] nua has joined the channel
[15:53] nua: really pleased to see some updates to Promises being comitted, sounds like they'll act much more like I first expected them to now... :)
[15:53] nua: I'm eager to get started with them, can I expect a new release of node soon? or should I start running trunk?
[15:54] nua: ...don't worry, not in production ;)
[15:55] nefD: 
ACTION watches the channel stats, hoping it will one again rise above 100 users

[15:56] mediacoder: nua: ryan is workning on merging the net2 branch so a bigger release might be there soon (i think he said something about end of week, if all goes well)
[15:58] jed_: does the net2 release differ significantly in API. or is it mostly under the hood?
[15:58] nua: mediacoder: ok, thanks
[15:58] mediacoder: jed_: i dunno..but i think its rather under the hood 
[15:59] bry has joined the channel
[16:00] deanlandolt has joined the channel
[16:01] jed_: mediacoder: cool, thanks.
[16:09] steadicat has joined the channel
[16:09] cloudhead has joined the channel
[16:19] cheapRoc has joined the channel
[16:19] felixge_: nua: you can run the trunk
[16:19] Yuffster has joined the channel
[16:19] felixge_: I'm compiling HEAD every day, so if there are problems you'll see me bitching in here or on the mailing list :)
[16:27] steadicat has joined the channel
[16:33] rictic has joined the channel
[16:50] stevestmartin has joined the channel
[16:54] jed_ has joined the channel
[16:55] jed_: debugging is much easier in the latest build... nice work, felixge_!
[16:58] DamZ has joined the channel
[17:01] quirkey has joined the channel
[17:07] eddanger has joined the channel
[17:09] felixge_: jed_: because of the promise exceptions?
[17:09] RayMorgan has joined the channel
[17:10] jed_: felixge_: yes. specifically, this: http://github.com/ry/node/commit/bfd31448617dc4d66f6de5ced7c260562e01349f#L1R297
[17:11] felixge_: jed_: I actually have one patch to improve that waiting to be reviewed by ryan
[17:11] jed_: (though i wonder if there's a nicer way to display such a trace for output.)
[17:11] jed_: felixge_: what's that?
[17:12] felixge_: http://github.com/felixge/node/commit/d0fe1d14927f76e404c9dc572fc000f62d685ac8
[17:12] rictic has joined the channel
[17:12] bpot has joined the channel
[17:12] jed_: ah, nice. that will make it clearer.
[17:13] bentomas has joined the channel
[17:17] felixge_: I really want chaining & grouping still
[17:17] felixge_: but hopefully we'll reach a consensus on it soon
[17:20] bentomas: well, hopefully we have convinced ryan of the usefulness of chainable promises
[17:20] charlenopires has joined the channel
[17:26] _ry: morning
[17:28] stevestmartin: morning
[17:31] CIA-78: node: 03Felix Geisendörfer 07master * rb57d7d9 10/ src/node.js : 
[17:31] CIA-78: node: Treat 'typeof Error' promise errors properly
[17:31] CIA-78: node: Instead of JSON encoding them, just rethrow promise errors since that
[17:31] CIA-78: node: produces much cleaner error messages. - http://bit.ly/4GpyRL
[17:36] jed_: nice.
[17:36] aguynamedben has joined the channel
[17:36] inimino: morning
[17:39] CIA-78: node: 03Ryan Dahl 07master * r152d956 10/ deps/v8/SConstruct : Remove -Werror from V8 - http://bit.ly/7dVUxa
[17:45] micheil: moin _ry 
[17:46] micheil: and morning it is.. 15 to 5am.. whoops.
[17:46] _ry: micheil: where are you?
[17:47] sudoer has joined the channel
[17:47] micheil: australia
[17:47] micheil: -- out.
[17:50] _ry: i want to do a release - is there anything that needs to be fixed?
[17:51] stephenlb has joined the channel
[17:51] pmuellr has joined the channel
[17:51] bentomas1 has joined the channel
[17:58] brandon_beacher has joined the channel
[18:11] CIA-78: node: 03Ryan Dahl 07master * rfaefb3f 10/ test/mjsunit/test-http-eof-on-connect.js : test-http-eof-on-connect missing require('./common') - http://bit.ly/4QwFyq
[18:12] markwubben has joined the channel
[18:16] felixge has joined the channel
[18:16] ericflo has joined the channel
[18:28] BradleyS has joined the channel
[18:29] kriszyp has joined the channel
[18:35] charlenopires has joined the channel
[18:35] isaacs_mobile has joined the channel
[18:38] fictorial has joined the channel
[18:38] okito has joined the channel
[18:39] felixge has joined the channel
[18:40] konobi has joined the channel
[18:41] konobi: oioi
[18:43] konobi: _ry: how goes?
[18:51] _ry: konobi: hey
[18:53] mikeal has joined the channel
[19:05] konobi: _ry: <-- Scott M... cow-orker... btw
[19:05] steadicat has joined the channel
[19:05] orlandov: konobi: quit orking my cows, damn it
[19:06] konobi: orlandov: =0P
[19:06] mediacoder: :-)
[19:06] konobi: orlandov: i could spill over into the hot mom jokes... but meh
[19:07] cheapRoc_ has joined the channel
[19:10] sudoer has joined the channel
[19:13] jamiew has joined the channel
[19:14] aho has joined the channel
[19:16] un0mi has joined the channel
[19:18] technoweenie has joined the channel
[19:19] CIA-78: node: 03Ryan Dahl 07master * rf88d39d 10/ src/node.cc : getmem() for solaris - http://bit.ly/5l0fVP
[19:29] felixge: we're in the 100th again
[19:29] felixge: awesome
[19:29] _ry: ?
[19:32] JoePeck has joined the channel
[19:33] piranha has joined the channel
[19:35] felixge: _ry: 100+ folks in here
[19:41] CIA-78: node: 03Ryan Dahl 07master * rda00413 10/ (ChangeLog doc/api.txt doc/index.html wscript): bump version - http://bit.ly/5EK3PG
[19:45] felixge: yea, release time : )
[19:47] stevestmartin: does that mean net2 will be in our future shortly :)
[19:54] jan____: felixge: I got an appointment tomorrow afternoon :/
[19:54] gf3 has joined the channel
[19:54] felixge: jan____: so no hack fun?
[19:55] felixge: jan____: how long is the appointment?
[19:56] cheapRoc has joined the channel
[19:56] konobi: _ry++ # solaris support... awesome
[19:56] rtomayko has joined the channel
[20:00] jan____: felixge: 2-4 but it might take longer, I'm a bit thin stretched on time anyway this week so it probably wouldn't be much joint hacking :)
[20:01] felixge: jan____: when I say hacking I really mean drinking beer
[20:01] felixge: but I hear ya : )
[20:01] jan____: felixge: we can have beer any time ;)
[20:01] jan____: except any time
[20:01] _ry: stevestmartin: i'm going to try to merge net2 in the next release
[20:01] felixge: jan____: HAH
[20:02] stevestmartin: _ry: how often do you generally try to do releases
[20:02] _ry: stevestmartin: ideally weekly
[20:03] orlandov: quick question, what's up with the leading underscores on process.__filename and process.__dirname?
[20:03] felixge: jan____: lets try next week
[20:03] felixge: jan____: at the very lest I'll be at the meetup in feb
[20:04] _ry: orlandov: bad judgement on my part
[20:04] _ry: orlandov: i want to fix that, but can't think of a better api
[20:04] _ry: orlandov: it's not process.__filename, it's just __filename
[20:05] orlandov: _ry: ah right you are; i think my mind wanted it to exist within process :)
[20:06] orlandov: wouldn't be a terrible place to put it
[20:07] _ry: can't put it there, actually. "process" is shared between all modules
[20:08] _ry: require.filename might be okay
[20:08] _ry: module.filename might also be okay
[20:08] felixge: yeah
[20:08] felixge: I like module.filename
[20:08] bentomas1: I do as well
[20:10] orlandov: ah, i misunderstood __filename, i thought it was like filename of the main script being executed. got it
[20:13] bentomas1: orlandov:  Most of the time, I think that is process.ARGV[1]
[20:36] ako has joined the channel
[20:37] ayo has joined the channel
[20:52] RayMorgan_ has joined the channel
[20:52] okito has joined the channel
[20:56] un0mi has joined the channel
[21:04] hassox has joined the channel
[21:04] hassox: kriszyp: Hey man you here?
[21:05] kriszyp: yes
[21:05] hassox: Yours is the jsgi for bode right?
[21:05] hassox: Node
[21:05] hassox: Soz on my phone
[21:05] kriszyp: yes
[21:06] kriszyp: np
[21:06] hassox: I was playing about with it last night
[21:06] hassox: It's very nice code btw
[21:06] kriszyp: oh, thank you
[21:06] hassox: I had some strange results thiugh
[21:06] kriszyp: ok
[21:06] hassox: When I did
[21:07] hassox: Request.input.read().decodeToString()
[21:07] hassox: The complete event never fired :(
[21:08] hassox: So it just hung on the promise.wait()
[21:08] hassox: The complete one
[21:08] kriszyp: hmm
[21:08] hassox: Is itjust me or does that happen to you too?
[21:08] kriszyp: I know it works for me...
[21:09] kriszyp: the http request does have a body?
[21:09] hassox: No
[21:09] kriszyp: hmm, I wonder if that is the problem
[21:09] hassox: It's a get request
[21:09] hassox: Didn't seem to be
[21:09] kriszyp: I haven't tested doing a read() without a body...
[21:09] hassox: I threw a post at it too
[21:09] kriszyp: with a body?
[21:10] hassox: Yeah
[21:10] kriszyp: and same thing?
[21:10] hassox: If I split the read and the decodeToString with a callbakck it worked
[21:10] hassox: Ja
[21:12] hassox: I commented out the wait and added a puts line to the complete listener and that fires
[21:12] hassox: Just not when it was waiting. :(
[21:12] kriszyp: oh, I have seen an issue like that
[21:12] kriszyp: thought I fixed it though...
[21:13] kriszyp: let me see if my code is up-to-date
[21:13] hassox: Oh right... What would be causing it do you think?
[21:15] kriszyp: so I thought that I fixed it be doing the setTimeout to ensure that the wait is called after request event takes finishes
[21:15] hassox: Why is that imprtant?
[21:16] kriszyp: I thought that node failed to fire the complete event until the initial request actually finished
[21:16] kriszyp: I don't know why that was important
[21:16] kriszyp: it wasn't the behavior the expected from node
[21:17] hassox: Why do you mean when the request event yakes finishes?
[21:17] hassox: Takes
[21:18] kriszyp: the event handler that gets called by the http server, it seems that has to finish its event turn before the "complete" event will fire for the request object
[21:18] kriszyp: at least that is what I thought I was observing
[21:18] joshbuddy has joined the channel
[21:19] hassox: Sorry for being thick
[21:19] hassox: What do you mean by event turn?
[21:20] hassox: Is that were all te callbacks for that listener have returned?
[21:20] un0mi has joined the channel
[21:22] kriszyp: right. an event turn would be the execution of an event  by the event loop handler before going to the next event in the event queue
[21:23] kriszyp: hassox: does this work for you: http://gist.github.com/282279
[21:23] kriszyp: it works properly for me...
[21:23] hassox: And that is effectively all the callbacks have returned?
[21:23] hassox: I can't tell, on the phone atm
[21:23] kriszyp: oh, ok, sorry
[21:24] kriszyp: but yes, after the callbacks have returned
[21:24] kriszyp: I didn't dig into the node source to debug any further
[21:24] hassox: Np, I'll look it up and try it as soon as I can
[21:24] hassox: Can I ask you one other q?
[21:25] kriszyp: sure
[21:25] kriszyp: and btw, it does work for no-body get for me as well
[21:25] hassox: Say I want accept file uploads
[21:25] hassox: Nice :)
[21:25] hassox: Just with raw node handler
[21:25] hassox: And I faf about for a few event cycles
[21:26] hassox: Then I attach a listener on body and complete on the request
[21:26] hassox: Do I loose data because it was emitting events before I added the listener?
[21:26] technoweenie: hey how do you daemonize node?  
[21:27] kriszyp: I believe so
[21:27] technoweenie: hmm i bet i can use runit
[21:27] kriszyp: that is my understanding, maybe _ry can correct me if I am wrong
[21:27] hassox: Hrm so the listeners have to be added as soon as therequest come in :(
[21:28] kriszyp: yeah
[21:28] hassox: That blows
[21:28] inimino: technoweenie: "node foo.js &"
[21:28] cloudhead has joined the channel
[21:28] robrighter has joined the channel
[21:28] technoweenie: inimino: yeaaaa thats ghetto but its good for now :)
[21:29] technoweenie: my redis/node.js service is live! muahaha
[21:29] hassox: Nice
[21:29] hassox: _ry here?
[21:29] RayMorgan has joined the channel
[21:30] gf3: robrighter: hah, good one
[21:30] gf3: robrighter: I'll add a test and try and think of a good fix
[21:31] gf3: robrighter: thanks!
[21:31] RayMorgan has joined the channel
[21:31] konobi: anyone know how complete the node-amqp implementation is?
[21:31] RayMorgan has joined the channel
[21:31] _ry: hassox: hey
[21:31] konobi: oh, not at all apparently
[21:32] _ry: konobi: i'm trying to built it right now
[21:32] hassox: Hey _ry
[21:32] _ry: build
[21:32] hassox: _ry if I'm late binding a listener to the request body event 
[21:32] binary42 has joined the channel
[21:33] robrighter: gf3: yea there are a number of ways to get around your sandbox
[21:33] hassox: I.e I faf about fir a dew event cycles
[21:33] hassox: Does that mean I miss the data that has already been emitted?
[21:33] _ry: hassox: you'll miss the body
[21:33] hassox: Right
[21:33] hassox: So it has to be buffered
[21:33] robrighter: gf3: prototype of function and object, etc
[21:33] _ry: hassox: yes
[21:33] hassox: K thx
[21:34] micheil: moin, _ry, hassox, et-all
[21:34] sveisvei has joined the channel
[21:34] hassox: Hey micheil 
[21:34] rtomayko has joined the channel
[21:34] micheil: _ry: yeah, didn't get too much sleep. ;P
[21:35] _ry: micheil: :)
[21:42] robrighter: gf3: For what its worth, I think the sandbox idea is a good one. It would be great to have it for a project that we are working on. But I dont think you can do it without setting up a totally separate v8 environment.
[21:42] alexiskander has joined the channel
[21:43] inimino: _ry: you credited me for the setTimeout and setInterval extra params, but someone else wrote that
[21:43] joshbuddy has joined the channel
[21:44] _ry: oh
[21:44] _ry: inimino: oops
[21:44] _ry: oh well
[21:44] inimino: _ry: ah, it was micheil
[21:44] _ry: micheil: sorry
[21:44] micheil: no worries :P
[21:45] micheil: _ry: 
[21:45] micheil: _ry: maybe that's why pulling in forks is better?
[21:46] inimino: it's correct in the commit log, probably just a typo when writing the email to the list :)
[21:47] inimino: 
ACTION posts a correction to the list just for the record...

[21:48] CIA-78: node: 03Ryan Dahl 07master * rfe48b5f 10/ ChangeLog : Fix author in ChangeLog - http://bit.ly/4HTmxq
[21:54] inimino: _ry: I just read your email on the Binary/E thread... what do you think about implementing Binary/E or something like it on top of your Buffer?
[21:55] inimino: _ry: looks like it should be pretty easy, I might try it if I have some time
[21:56] micheil: inimino: What is the binary/E stuff, I haven't really been following it
[21:57] gf3: robrighter: I was worried it might come to that
[21:57] deanlandolt: micheil: one in a long line (err, 5) of Binary commonjs proposals
[21:57] gf3: robrighter: I'll see if I can come up with quick fix in the mean time
[21:57] inimino: micheil: CommonJS proposal for JavaScript binary data API
[21:57] deanlandolt: but one that finally looks like it could be close to something that's ratifyable
[21:57] micheil: hm..
[21:58] inimino: yes
[21:59] micheil: I'm curious as to why a binary buffer would be used, if I've got it right, it looks like you write data -> encode it to bin -> store. then later read store -> convert to ascii / utf8 -> read data
[21:59] inimino: yes
[21:59] jed_ has joined the channel
[22:00] cloudhead: anyone familiar with the assert implementation?
[22:00] inimino: that's where it would be used
[22:00] inimino: or in dealing with binary data that actually is binary data
[22:00] inimino: images, or whatever
[22:00] micheil: inimino: has net.js been around for long?
[22:01] cloudhead: I'd like to extend the error messages, but not sure if I should replace fail() or AssertionError.prototype.toString()
[22:01] inimino: <canvas> will use it for pixel data once there's something appropriate in the language
[22:01] inimino: micheil: the one in the net2 branch is a few weeks old
[22:02] okito has joined the channel
[22:14] hassox has joined the channel
[22:15] isaacs has joined the channel
[22:16] isaacs: process.nextTick(callback) is badass.  I was just about to propose something like that, since setTimeout(fn) is a bit heavier than you usually need for that.
[22:22] felixge has joined the channel
[22:27] orlandov: isaacs: is that something that exists currently? because i could certaintly use it
[22:27] orlandov: setTimeout(foo, 0) seems a bit gross to me
[22:27] isaacs: orlandov: latest nodejs has it.
[22:27] orlandov: neat!
[22:30] JoePeck has joined the channel
[22:31] _ry: yeah, nextTick is pretty light
[22:32] _ry: well, a lot lighter than setTimeout(fn, 0)
[22:32] orlandov: is that the recommended way of shoving something into the event loop for later execution?
[22:32] micheil: _ry: I have to say, it's interesting how setTimeout actually works..
[22:33] _ry: orlandov: yes
[22:33] _ry: although with felix's latest promise changes, it shouldn't be necessary as much as it once was
[22:41] bentomas1: _ry: would you be willing to accept a patch for chainable promises now?  It isn't clear from the latest thread if you have changed your mind...
[22:43] benw has joined the channel
[22:44] _ry: bentomas1: yeah...sure
[22:45] nefD: colorbot ftw http://www.ansi.ws/colorbot/ :o
[22:45] bentomas1: kriszyp: you around?
[22:50] isaacs: felixge: hey, what's the state of require() these days?
[22:50] isaacs: still fluxing?
[22:50] isaacs: i'd like to get module.exports locked down as soon as feasible.
[22:50] _ry: module.exports?
[22:50] isaacs: _ry: yeah
[22:51] isaacs: my setExports branch (which is quite out of date at this point) also sets up a setter on module.exports so that you can't screw the pooch by setting it after it's already been acquired.
[22:52] _ry: oh
[22:52] _ry: :/
[22:52] isaacs: ie, supporting all the crazy edge cases brought up in the setExports discussion on commonjs.
[22:53] joshbuddy:  nextTick, hot
[22:53] isaacs: i'm ok with not exposing setExports, since it can be a setter just as easily.
[22:53] micheil: nextTick sounds like something to find when the event queue is idle..
[22:53] joshbuddy: micheil: feels natural to me coming from eventmachine
[22:54] micheil: am I right in what I said about an idle status finder?
[22:54] _ry: no
[22:54] joshbuddy: no, its way to execute something on the eventloop
[22:54] _ry: it executes the next time around the event loop
[22:54] micheil: ah
[22:54] joshbuddy: it does it as soon as possible.
[22:55] _ry: but there is also process.IdleWatcher now too
[22:55] _ry: if you want to get that behavior
[23:00] un0mi has joined the channel
[23:08] gf3: hey robrighter, I've committed a fix to address the specific example in your issue
[23:08] gf3: http://github.com/gf3/node-sandbox/commit/4883d4ceffeb86cc7ef598d77267d0265b96f95f
[23:11] _ry: so tired..
[23:11] gf3: _ry: caffeine!
[23:14] micheil: _ry: I'd offer coffee, but it'd be cold by the time it got there
[23:18] benw: 
ACTION is thinking about exception handling in an http server.

[23:19] benw: Any suggestions on how to stop an uncaught exception in one request handler from killing the whole app and all  connections?
[23:20] _ry: benw: good question....
[23:20] _ry: process.addListener("unhandledException") can help
[23:20] benw: Bonus points for making it return 500 Internal Server Error to the request :)
[23:20] benw: Ooh, thanks
[23:20] _ry: but it'd be nice if you could catch it from the server somehow
[23:21] benw: He's what I'm dreaming of: http://gist.github.com/282399
[23:22] un0mi has joined the channel
[23:23] micheil: benw: what about try {...} catch (e) {}
[23:24] micheil: oh, wait, yeah
[23:24] benw: micheil: That only works if handleRequest has done everything by the time it returns, i.e. performs no I/O.
[23:24] micheil: as to catching Errback's on promises and things, that's possible
[23:24] benw: Sentinel would have to do some magic
[23:26] benw: I assume process.addListener() is program-wide in effect; I want something specific to a chain of callbacks dealing with one request.
[23:26] micheil: 
ACTION doesn't quite get the reference with the name sentinel

[23:26] sudoer has joined the channel
[23:26] benw: micheil: A thing that watches? I dunno
[23:27] micheil: promise.addListener("error) or rather promise.Errback()
[23:27] benw: But I want to do it once at the start, not at every step in the chain of things that create callbacks
[23:28] micheil: so you'd need something that bubbles up the events
[23:28] _ry: would be cool to do: req.addListener("unhandledException")
[23:28] _ry: would be cool to do: req.addListener("unhandledException", function (exception, event) { } )
[23:28] benw: Yeah I think it means a pointer to a Sentinel stack that's attached to every callback
[23:29] benw: So when an event is dispatched, the current Sentinel stack pointer becomes part of the execution context and is attached to any new callbacks, etc
[23:30] micheil: I'll leave you guys to nut that out.. lost me ;P
[23:30] stevestmartin has joined the channel
[23:30] benw: _ry: I'm not sure req is the thing that's listening for the unhandled exception, exactly
[23:30] benw: micheil: Like I said, requires magic  :)
[23:31] okito has joined the channel
[23:32] benw: I'm not familiar with V8 internals, but is there a way to attach extra stuff to contexts?
[23:33] benw: If so, would be interesting to expose the context object in js
[23:33] _ry: attach extra stuff?
[23:34] benw: Yeah, like my pointer to a Sentinel stack
[23:34] gwoo_ has joined the channel
[23:34] benw: Hmm, but probably the whole program runs in a single V8 context
[23:35] _ry: ye
[23:35] _ry: s
[23:35] benw: Could a single event loop dispatch events to multiple contexts?
[23:36] benw: I've no idea how much if anything can be shared between contexts
[23:37] inimino: benw: what do you have that throws exceptions that you can't catch?
[23:37] benw: I'm just imagining http dispatching each request to an insulated context.
[23:37] _ry: benw: i kind of like req.addListener("unhandledException")
[23:38] inimino: I've seen people asking for this twice now but can't understand the use case
[23:38] benw: inimino: Nothing, but it does require me to write a try-catch block for every callback and to do something sensible in it.
[23:39] inimino: in places where exceptions can be thrown, sure
[23:39] inimino: is that a significant hardship?
[23:40] benw: In the synchronous one-thread-per request world, handleRequest sits inside a single try block, where the catch block returns a 500 Internal Server Error or whatever, and it's all done in one piece of code.
[23:41] inimino: sure
[23:41] inimino: I've just never had a case so far where something threw an exception except because of a programming error
[23:41] benw: hardship: Yeah I think currently we're asking people to code async and to think about exception handling over and over again for every callback that might ever be involved.
[23:42] _ry: benw: i guess his point is, most of the time you want it to crash
[23:42] micheil: benw: 
[23:42] inimino: I mean... if there's an error in Apache, and it segfaults, I don't expect to see a 500 server error in the browser
[23:42] benw: Sure, I don't want my code throwing exceptions either, but I make mistakes and I don't want them to bring down my whole server, just one request.
[23:42] micheil: um.. surely implementing something like that would require rather serious hacking to events / promises..
[23:43] benw: Right, but if there's an error in a CGI, it doesn't crash apache
[23:43] benw: micheil: Yeah maybe, I don't know how feasible this is.
[23:44] benw: But I think it's worth recognising that we're asking server-side coders currently to deal with a different level of risk.
[23:44] micheil: unless there's some way to implement a try catch around everything inside a listener in req, I'm not sure
[23:44] benw: Well, a different level of consequece.
[23:44] inimino: sure, but if you're loading untrusted code, you'd probably need to do it in a separate process anyway
[23:44] inimino: (just like CGI)
[23:44] inimino: I don't think it's any different, but node isn't CGI
[23:45] benw: Rather than compare this to apache, let's compare it to rails, or mojolicious or something.
[23:45] charlenopires has joined the channel
[23:45] benw: Not that I know anything about rails
[23:45] inimino: if you need that kind of isolation you can build it on top
[23:45] inimino: node is more like Apache
[23:45] inimino: if you're writing an Apache module and you crash the server, well there you have it
[23:46] dnolen has joined the channel
[23:46] benw: Well... maybe, but we're writing web frameworks for node
[23:46] benw: Express looks like Sinatra, right?
[23:46] inimino: well that makes two of us :)
[23:46] inimino: I spent a weekend evaluating rails and haven't looked at it since
[23:47] benw: What's your favourite web framework pre- node.js?
[23:47] micheil: something between rails, sinatra, and django
[23:47] inimino: yes... people are doing that sort of thing
[23:47] inimino: but you're still loading code into the same process
[23:47] inimino: it could just as easily go into an infinite loop
[23:48] erichocean has joined the channel
[23:48] benw: Sure, I'm not suggesting we can make any absolute guarantees here, with process isolation etc
[23:49] benw: But I'd like my web framework to be able to say: "Just handle this request callback. And if you stuff up and it throws an exception, the connection will see a 500 error and the server will keep running."
[23:49] benw: I haven't tried it in other web frameworks but it's trivial to do in the thread-per-connection model.
[23:50] inimino: sure
[23:50] inimino: but I don't think there's much benefit to it
[23:50] inimino: in development, there's no benefit
[23:50] bentomas1: web frameworks can build try/catches into the appropriate places, so you don't have to worry about it.  I don't think anything needs to be added to node to handle this sort of thing
[23:51] bentomas1: if you are using the bare node http server, then yes, you'll have to be careful.
[23:51] micheil: I agree with bentomas1 
[23:51] benw: Fair enough
[23:51] inimino: and in production, you should have something monitoring it and bringing it back up anyway if it goes down
[23:51] inimino: yes
[23:52] benw: Sure, of course
[23:52] inimino: the only real benefit is that if it is production, the user sees a 500 which they don't understand, instead of a 'connection timed out' which they don't understand
[23:52] micheil: I'm not sure why my coffee tastes like it has a hint of irish whiskey in it..
[23:53] micheil: I think I prefer the connection timed out
[23:53] micheil: (I get those heaps on my connection)
[23:54] _ry: isaacs: ping
[23:54] benw: bentomas1: I'm writing a small web framework. (All the kool kids are, right?) I'm struggling with how to deal exceptions so that users of the framework get some basic insulation between requests.
[23:54] benw: _ry: What would req.addListener("unhandledException") actually mean?
[23:55] _ry: benw: any time an exception was called during an evented emitted by req, it would call that handler
[23:55] technoweenie: oh that would rock
[23:55] technoweenie: an unhandledException event
[23:55] benw: Sounds good - what does it mean for req to emit evens?
[23:56] micheil: _ry: and if listeners.length <= 0, bubble up the stack.
[23:56] ericflo has joined the channel
[23:56] _ry: micheil: "stack"
[23:56] micheil: stack as in node / v8's stack trace.
[23:56] rauchg has joined the channel
[23:57] bentomas1: _ry: it seems like that would make more since to exist on http.Server
[23:57] benw: micheil: The next thing up on the stack trace is probably the event loop.
[23:57] _ry: micheil: what benw said ---^
[23:58] bentomas1: so you'd say var s = http.createServer(myfunc).addListener('unhandledException', myerrorhandler);
[23:58] micheil: server.addListener("unhandledException", func)
[23:58] micheil: yeah
[23:58] benw: I'm still trying to figure out when unhandledException would fire in that case.
[23:59] bryanl has joined the channel
[23:59] bentomas1: whenever myfunc throws an error
[23:59] micheil: and if there's no unhandledException listener, then it would crash node as normal
[23:59] _ry: server.addListener("request", function () { throw "error"; } )
[23:59] _ry: ^--- would execute unhandledException on each request
[23:59] micheil: yeah
[23:59] benw: _ry: Sorry, I don't follow