[00:02] BradleyS has joined the channel
[00:05] dnolen_ has joined the channel
[00:08] mikeal has joined the channel
[00:18] mikeal: hrm...
[00:18] mikeal: http.ServerResponse.sendHeader and .sendBody don't return a Promise
[00:19] mikeal: are they blocking? is there any way to tell if they actually succeed or not?
[00:20] inimino: mikeal: they should be synchronous, only one thing has access to the socket at a time
[00:21] mikeal: that's not how any of the other IO write callers work
[00:21] inimino: s/thing/conceptual thread of execution/
[00:22] inimino: mikeal: sure, but then streaming data out over the socket is the whole point
[00:22] inimino: it's everything else that needs to get out of the way for that to happen
[00:24] inimino: hence everything else being asynchronous and not blocking what really matters, i.e. sending data down the pipe as fast as possible
[00:27] mikeal: looking through the code
[00:27] mikeal: it actually seems like the call won't throw an exception if it fails
[00:31] brosner has joined the channel
[00:33] brosner has joined the channel
[00:36] brosner has joined the channel
[00:38] un0mi has joined the channel
[00:41] paulca has joined the channel
[00:44] blackdog has joined the channel
[00:46] binary42 has joined the channel
[00:56] dnolen has joined the channel
[00:56] pjb3 has joined the channel
[01:06] mattly has joined the channel
[01:17] bpot has joined the channel
[01:30] mikeal has joined the channel
[01:34] un0mi has joined the channel
[01:55] softdrink has joined the channel
[02:01] onar has joined the channel
[02:02] stephenlb has joined the channel
[02:10] stephenlb: AnyEvent in Perl. Anyone had the opportunity to play with this? Thoughts? I'm liking AnyEvent very much.
[02:27] achew22 has joined the channel
[02:28] achew22: If you call .wait on a promise does it hang the thread there or does it defer to other requests until the promise has been fulfilled?
[02:36] un0mi has joined the channel
[02:37] dnolen has joined the channel
[02:37] ryah: achew22: neither
[02:37] achew22: ryah: how does .wait behave then?
[02:37] ryah: it reenters the event loop
[02:37] ryah: on top of the current execution stack
[02:38] achew22: so processing can continue elsewhere until the promise is fulfilled?
[02:38] ryah: yes
[02:38] ryah: the problem is if you call another wait() before the first wait() has completed
[02:39] JoePeck has joined the channel
[02:39] achew22: you can have the waits depending on the other by accident (is that what you are hinting at)?
[02:40] ryah: basically wait() shouldn't be used except in the most simple situations
[02:40] ryah: i'm probably going to remove it
[02:41] JoePeck: Does anyone else find the description of process.exit pretty useless? http://bit.ly/8DMWbK
[02:41] JoePeck: "The parameter code is the integer exit code passed to process.exit()."
[02:41] ryah: JoePeck: oh yeah. i should fix that :)
[02:41] JoePeck: was that supposed to say it is the exit code that would be returned from the process
[02:41] JoePeck: ryah: I'm going through the docs now
[02:41] JoePeck: ryah: first timer, fresh eye's I'll post a bunch of updates then
[02:42] JoePeck: just making sure I wasn't missing anything obvious though =)
[02:42] inimino: that's the description of the event, not the function call
[02:42] JoePeck: inimino: ahh, yah I just got that
[02:46] micheil: ryah: any ideas on those fs.sendfile test errors?
[02:47] micheil: (Is there a possibility that it may be related to the other os x issue on the ML)
[02:47] mattly has joined the channel
[02:53] achew22: Is there documentation on naming conventions for modules in node (or should it be commonjs)
[02:58] inimino: anybody know the RedHat equivalent of build-essential?
[03:05] binary42 has joined the channel
[03:09] inimino: ACTION asked in #rhel, the answer is "there isn't one"
[03:09] stephenlb: heh
[03:09] inimino: but installing gcc-c++ and make seems to be sufficient
[03:11] JoePeck: how is doc/api.html generated from api.txt? Is it just textile?
[03:14] kriszyp has joined the channel
[03:14] un0mi has joined the channel
[03:16] ryah: micheil: yeah probably. i haven't looked at it yet.
[03:16] ryah: JoePeck: asciidoc
[03:17] ryah: JoePeck: make doc
[03:17] JoePeck: ryah: awesome, thanks. I'll try it out
[03:22] micheil: ryah: if you need someone to test out the mac stuff, just ask :)
[03:26] stephenlb has joined the channel
[03:29] softdrink has joined the channel
[03:34] BryanWB has joined the channel
[03:35] BryanWB: i have a dumb newbie question
[03:36] BryanWB: since all users accessing a website running on node.js would run in the same event-loop, what's to keep one user request from crashing the whole loop?
[03:37] BryanWB: and killing other user requests?
[03:37] inimino: BryanWB: nothing
[03:38] inimino: BryanWB: if your code is buggy and crashes the server, then the server will go down
[03:38] BryanWB: inimino, so that's just a risk u take then
[03:38] BryanWB: inimino, i c
[03:39] BryanWB: whereas my buggy cgi script just crashes my buggy cgi process
[03:39] inimino: it's like running Apache, if you load a buggy Apache module and it takes down Apache...
[03:39] inimino: but yes, CGI gets its own process, and with that you get OS-level isolation
[03:39] inimino: if you want the performance benefits of running everything in the same process then you take the risk as well
[03:40] BryanWB: i wonder how jsgi deals w/ this issue, will have to ask kriskowal
[03:40] allnickstaken has joined the channel
[03:40] BryanWB: inimino, tks
[03:41] inimino: sure
[03:41] inimino: of course, just like with Apache, hopefully you'd be running a monitoring and restarting system
[03:42] BryanWB: inimino, i would love to see better integration b/w narwhal's rhino implementation and node.js
[03:42] tlrobinson: BryanWB: that's not really something JSGI is concerned with
[03:42] BryanWB: tlrobinson, ah
[03:42] tlrobinson: BryanWB: typically you run something like monit or god
[03:43] BryanWB: inimino, then I could have a kick ass js webserver but still integrate to tons of java legacy crap
[03:43] tlrobinson: but thats true of any app server
[03:43] BryanWB: tlrobinson, tks
[03:43] tlrobinson: BryanWB: i'm not sure how you would integrate the two, they're entirely different js engines
[03:43] inimino: hm, depending on what kind of legacy crap it is... yeah...
[03:44] deanlandolt: tlrobinson: IPC? :)
[03:44] inimino: probably some kind of proxy or socket IPC
[03:44] BryanWB: inimino, all the corporate enterpisey stuff
[03:44] BryanWB: tlrobinson, kriskowal had some good ideas on cross-engine communication but I can't remember them now
[03:44] deanlandolt: perhaps workers could be used in that kind of capacity
[03:45] deanlandolt: it's all just message passing anyway
[03:45] tlrobinson: BryanWB: yeah that would be neat
[03:45] inimino: yeah workers once they are a little more stable/mature
[03:45] bry has joined the channel
[03:45] kriszyp has joined the channel
[03:45] brosner has joined the channel
[03:45] alex-desktop has joined the channel
[03:45] [mighty]Mike has joined the channel
[03:46] JoePeck: hmm, there is a --nonet switch on xsltproc for `make doc`
[03:46] inimino: JoePeck: related to fetching DTDs
[03:46] binary42 has joined the channel
[03:47] inimino: and maybe doc() function in XSLT too
[03:47] JoePeck: well, it seems to prevent the imports
[03:47] JoePeck: that are remote
[03:47] inimino: that would be doc()
[03:47] JoePeck: okay, how can I get it to build with that switch?
[03:47] JoePeck: removing the switch, although it took a minute, worked
[03:48] inimino: ACTION has no more knowledge on the topic
[03:48] JoePeck: hehe
[04:07] jspiros has joined the channel
[04:13] erichocean has joined the channel
[04:19] ryah: BradleyS:
[04:19] ryah: oops
[04:19] ryah: i was going to stay to BryanWB that you can always load balance across multiple processes
[04:26] moosecrumpet has joined the channel
[04:32] steadicat has joined the channel
[04:36] micheil: alternatively you could use child-processes of node to load up individual applications
[04:42] ryah: ACTION git-bisecting
[04:42] micheil: I've actually never done a git-bisect..
[04:45] micheil: ryah: would it be wise for future versions of node to include a ssl/tls module, rather then intergrating it with tcp/http?
[04:46] micheil: (that way you could do something like: var ssl = require("ssl"); if(ssl.available){...} )
[04:46] ryah: micheil: yes
[04:46] ryah: hm
[04:46] ryah: well maybe not that
[04:46] ryah: but i do want to seperate out the ssl stuff
[04:46] micheil: that would also remove the errors in the tests when there isn't ssl/tls
[04:47] micheil: by available, I'm just meaning if openSSL / gnutls is available
[04:47] ryah: yeah
[04:47] ryah: i don't know. maybe we can have a process.features ? or something
[04:47] micheil: ssl.setSecure(conn, ... );
[04:47] micheil: yeah
[04:47] micheil: something like that would be good
[04:47] micheil: process.env could also handle it?
[04:48] ryah: how do you mean?
[04:49] micheil: if(process.env.ssl)
[04:49] micheil: or something
[04:49] micheil: and then use a compile time flag to switch it to true / false
[04:50] micheil: because it is an environmental thing
[04:51] softdrink has joined the channel
[04:51] micheil: I still haven't worked out the change in naming between the new buffer and net2 stuff and the older stuff
[04:52] micheil: InitBuffer(process); vs IOWatcher::Initialize(process_;
[04:52] micheil: /_/)
[04:53] ryah: micheil: process.env is the environment
[04:53] micheil: true
[04:53] micheil: I guess process.features is good anyhow
[04:54] micheil: (in the end the functionality is all the same)
[04:54] ryah: so the test-fs-sendfile.js bug appeared in bfd31448617dc4d66f6de5ced7c260562e01349f
[04:55] micheil: I'm not sure when it came up..
[04:57] micheil: I'm running the last that passed the tests atm, and I had that down as g4ab37a7
[05:00] micheil: also, shouldn't server.close() auto call socket.close() ?
[05:03] ryah: the 16,000 problem seems unrelaed
[05:03] ryah: micheil: no, i don't think so
[05:03] micheil: okay
[05:03] ryah: you should be able to have sockets open without accepting new connections
[05:04] micheil: hmm.. okay
[05:05] micheil: The fs-sendfile test was the first time I'd seen someone closing both server & socket
[05:05] kriskowal has joined the channel
[05:05] micheil: (for the protocol stuff I'm working on, that's a non-issue..)
[05:06] micheil: but for the various http projects, surely that could be source of a small memory leak?
[05:06] ryah: yeah this 16,000 bug, i think is related to ulimit -n
[05:06] micheil: ulimit -n... umm..
[05:06] ryah: maybe not
[05:08] micheil: just trying with ulimit -n 256
[05:10] micheil: nup
[05:13] bpot has joined the channel
[05:14] ryah: yeah.. this is really a problem
[05:17] micheil: could it be something to do with kern.ipc.somaxconn
[05:18] micheil: http://www.macgeekery.com/tips/configuration/mac_os_x_network_tuning_guide_revisited
[05:23] micheil: the number reported was around 16342 wasn't it?
[05:27] micheil: I can find a bunch of solaris related stuff, but not anything on mac os x
[05:40] micheil: ryah: I'm not sure if this is an introduced bug or not
[05:40] micheil: I'm going to revert back a few months and check
[05:40] micheil: ryah: I did find: http://www.communigate.com/communigatepro/Scalability.html
[05:41] micheil: under "additions to /etc/system"
[05:41] micheil: although, I couldn't find anything mac specific, that seemed solaris specific
[05:53] micheil: ryah: this also sounds some what related http://www.gamedev.net/community/forums/topic.asp?topic_id=513268
[05:55] micheil: I'm wondering if it's an ab issue?
[05:57] micheil: here we go.. 32676 connections on os x
[05:57] micheil: it's an ab issue
[05:58] micheil: ab reaches 16000 requests and then hangs
[05:58] micheil: (rather, more close to 16350)
[05:58] micheil: I modified the sample script to keep a count of requests handled, and puts() the number on each request
[06:05] micheil has joined the channel
[06:10] unomi: cool
[06:11] unomi: thats what you get for paying top dollar for a ripped off kernel :p
[06:11] unomi: you could check it thru a vm?
[06:12] micheil: umm..
[06:12] unomi: if it is ab specific, do ab from a client os
[06:13] micheil: I'm not sure which other boxes in the house have ab installed
[06:13] micheil: one sec
[06:15] unomi: or, if you got a port open I can ab you
[06:32] konobi: moo!
[06:36] achew22 has left the channel
[06:39] JoePeck: in http.ServerRequest the headers's are key/value pairs. The keys have been made lowercase: http://grab.by/1VUz
[06:39] JoePeck: I guess it doesn't matter, because http headers are case insensitive?
[06:40] JoePeck: I think its worth mentioning in the docs
[06:50] visua has joined the channel
[06:53] joshbuddy has joined the channel
[07:12] ryah: JoePeck: sure. going to include it in your docs patch?
[07:12] JoePeck: well, re-reading things
[07:12] JoePeck: there is a header example right at the start of the HTTP section
[07:12] JoePeck: but it shows an example with the headers non-lowercase
[07:12] ryah: indeed
[07:12] ryah: mistake
[07:13] JoePeck: okay
[07:13] JoePeck: I'm trying to get a patch up tonight so you can at least look at it
[07:13] JoePeck: you might not want everything, but I'm just covering obvious errors
[07:21] visua: Hey guys, is there a templating system floating around for node?
[07:23] JoePeck: visua: a bunch are mentioned in the main repo's module listing => http://wiki.github.com/ry/node/modules#templating
[07:24] visua: Thanks JoePeck
[07:24] visua: Oh sass? sweet :D
[07:24] JoePeck: visua: and probably some more mentioned on the mailing list, a recent thread => http://bit.ly/7GARJE
[07:24] JoePeck: sure
[07:25] JoePeck: am I seeing this correctly? path.basename is replaced by path.filename ?
[07:26] JoePeck: hmm, nevermind I see the code now
[07:26] JoePeck: maybe I should rebuild
[07:26] JoePeck: =o
[07:31] isaacs: JoePeck: other way around, i believe.
[07:31] JoePeck: yah
[07:31] JoePeck: I guess my build was so old
[07:31] isaacs: ACTION wrote that
[07:31] JoePeck: that filepath (which is shown in the examples) worked
[07:32] isaacs: yikes! there's documentation that shows filename rather than basename?
[07:32] JoePeck: I just reconfigured and built
[07:32] isaacs: (if so, that's a bug)
[07:32] JoePeck: yah, I'll have a patch you guys can look at tonight
[07:32] JoePeck: I'm now about 90% of the way through
[07:32] isaacs: sweet
[07:35] isaacs: micheil: you around?
[07:36] isaacs: oops, i meant mikeal, not micheil. carry on.
[07:40] blackdog has joined the channel
[07:40] JoePeck: I wish the REPL was mentioned before the very end of the api docs... I could have used that =P
[07:47] isaacs: hey, this might be a stupid question... since node sends the header as an object, how do you set more than one cookie?
[07:48] JoePeck: ryah: Let me know if there is a change you didn't like: https://gist.github.com/2ee9af917ba101323639
[07:56] ryah: isaacs: i think you can do "cookie": [a, b]
[07:57] isaacs: ryah: nope
[07:58] isaacs: i can make it work, i believe. just wondering if it's worth doing, or if there's already another way to send the same header multiple times.
[07:58] ryah: JoePeck: lgtm, thanks
[07:58] isaacs: doing "cookie" : [ "foo=bar", "bar=baz"] results in getting: foo=bar: bar=baz
[07:58] JoePeck: ryah: sure
[07:58] JoePeck: any plans to switch from asciidocs to something else?
[07:59] ryah: JoePeck: well, vague plans. once the network stuff moves out of c into js
[07:59] ryah: (and the http server too)
[07:59] ryah: i'll switch to a js doc generator
[07:59] JoePeck: okay cool, as long as its on the radar
[07:59] JoePeck: cheers, and g'nite!
[08:00] ryah: night
[08:01] isaacs: you can do "cookie" : [ "set-cookie", [ "foo=bar", "bar=baz"] ] to get set-cookie: foo=bar,bar=baz
[08:03] CIA-78: node: 03Joseph Pecoraro 07master * rc99e33b 10/ doc/api.txt : Fix minor issues in the documentation. - http://bit.ly/7EoS5s
[08:05] isaacs: ryah: you know if anyone's actually using sendHeader(200, { blah : [ key, value] }) anywhere?
[08:05] isaacs: seems a bit of a wonky approach, since then the key in the object isn't even looked at.
[08:06] isaacs: also, not documented.
[08:14] isaacs: ryah: for your consideration http://github.com/isaacs/node/commit/2573139cd1f05761b18043d23a0d1100225c7784
[08:16] ryah: isaacs: we had a bunch of back and forth about this a few months ago
[08:17] isaacs: orly?
[08:17] isaacs: musta missed that
[08:17] ryah: i think you can do sendHeader(200, [["Cookie": a], ["cookie", b], ["other-header", c]]
[08:17] ryah: which is what you used to have to do
[08:17] isaacs: sure, the "arrays as kv pairs" approach.
[08:18] isaacs: but that approach is weird.
[08:18] isaacs: arrays should be ordered collections of like things.
[08:19] erichocean has joined the channel
[08:19] isaacs: (at least, in js where "everything is an object". in a lisp, where "everything is a list", it makes perfect sense to construct objects out of lists)
[08:30] r11t has joined the channel
[08:44] scudco has joined the channel
[08:50] micheil: isaacs: agreed on using a proper nix for serving live traffic, atm I'm toying with arch..
[08:52] isaacs: ryah: it's not too hard to keep support for the list-of-lists style (though, for the record, it's weird like mayonnaise on toast), and still be able to send multiple headers using object-style without the oddball "the keys do nothing" style: http://github.com/isaacs/node/commits/multiple-header-field-as-array
[08:53] isaacs: got it working now. here's a gist showing what this lets you do: http://gist.github.com/285107
[08:54] micheil: isaacs: you know what would be even better? res.setCookie(key, value);
[08:54] isaacs: micheil: sure, but that belongs higher up
[08:54] micheil: didyouseewhatididthere?
[08:55] micheil: :P
[08:55] micheil: there was that argument on the ML about whether we need a setCookie method, I'm personally in favour of it, I believe others were against it
[08:55] isaacs: i'm against it.
[08:55] isaacs: i like that node doesn't know what a "cookie" is
[08:55] micheil: okay then
[08:55] micheil: setHeader()
[08:56] micheil: res.setHeader(...); res.begin(status); ...
[08:56] micheil: after begin is called, the headers are sent
[08:56] isaacs: so, you know, from the pov of an http lib, the "header" is one thing. it's the status line and a list of header fields, terminated by \r\n\r\n
[08:57] isaacs: setHeader and begin(200) belong higher up.
[08:57] micheil: but the http headers are different
[08:58] micheil: yes, you have a header of the response, but the http headers are the actual key/values in that header
[08:58] isaacs: i'm not sure when we all decided that the header is to be referred to in the plural, but i'm pretty sure i missed that meeting.
[08:58] isaacs: no, the "http header" is "HTTP 1.1/200 OK\r\nsome-field:some-value\r\n\r\n"
[08:59] isaacs: there's one http header and one http body per response.
[08:59] isaacs: the key/value pairs are header fields.
[08:59] isaacs: but i'm being persnickety. it's like the phrase "beg the question". at some point, the semantics nerd just has to accept that the language has changed.
[09:01] micheil: okay, setField :F
[09:01] micheil: :P
[09:03] isaacs: you could have something called setHeader that takes either or both of a number (status code), object (bag of fields), and boolean (true = drop any existing data, false/default = merge in with the existing fields)
[09:04] isaacs: s/either or both/any or all/ (nobody expects the spanish inquisition...)
[09:04] [k2] has joined the channel
[09:08] isaacs: micheil: in any event, that should be in your library. node shouldn't be in the business of SETTING header data. it's the thing that SENDs the header.
[09:08] micheil: okay then
[09:08] micheil: I don't care to argue on it.. I'm working on databases and protocols now
[09:23] qFox has joined the channel
[09:24] felixge has joined the channel
[10:25] BBB has joined the channel
[10:40] dekz has joined the channel
[10:43] mikeal has joined the channel
[10:53] cc has joined the channel
[10:54] cc: hello there
[10:54] mikeal has joined the channel
[10:54] cc: what is the power of node.js ?
[10:55] cc: have you tried something that show it much better than the betters like nginx, erlang, whatelse ?
[10:58] micheil: yes
[10:59] micheil: it's in ryan's slides from JSConf.eu
[11:00] cc: perfect, go reading it thx :)
[11:13] spoob has joined the channel
[11:13] dekz: May I ask a particular noobish question in regards to websockets and handshaking in here?
[11:14] dekz: (using in the context of node.js)
[11:14] spoob: I don't know much myself, but I've had a bit of a play with what you're asking about
[11:15] dekz: well I'm just attempting to get something simple running, and getting some unexpected response codes when i send the socket a header
[11:15] dekz: handshake*
[11:16] spoob: websockets isn't pure TCP, it has some header on it
[11:16] spoob: have you downloaded either of the two websockets implementations for nodejs?
[11:16] dekz: I'm looking through, http://github.com/Guille/node.websocket.js/
[11:17] spoob: ok, and do you have an HTML5 web browser for testing it?
[11:17] dekz: yep
[11:17] dekz: chromium nightly
[11:17] dekz: I hardcoded the header, just for testing
[11:17] dekz: http://pastie.org/792106
[11:18] dekz: and I'm sending this, user.socket.send(responseHeaders.join('\r\n'));
[11:19] dekz: (it's essentially the same header from the example, just with the location changed)
[11:19] spoob: Hmm. Have you tried websocket-server-node just to see if the other implementaton works OK?
[11:19] dekz: yep
[11:19] dekz: works fine, and I outputted it's reponse headers and just changed the socket location
[11:20] spoob: OK, I'm on Safari nightly and I can say that websocket worked for me without any hassle, so I am wondering if you can eliminate Chrominium as a source of the problem
[11:21] spoob: all of the stuff in HTML5 is very exciting and so much better than before, however it does still have a range of basic problems that pop up in the nightlies.
[11:21] dekz: I've ran them both in the same browser instance, so I'm pretty sure it's a 1D10T error
[11:22] spoob: 1D10T?
[11:22] spoob: oh
[11:22] dekz: :P
[11:23] spoob: ok, can you point your client at a websocket server on the internet ?
[11:23] spoob: actually, at this point I'm just going into general debugging of which I'm sure you're entirely capable. So I think I can't help here, sorry
[11:24] spoob: I am aware of general problems with eio in nodejs, so you may find that an earlier nodejs works while the latest nightlies dont
[11:24] dekz: Thanks anyway spoob
[11:25] spoob: as far as websockets goes, it's basically TCP with a header on it. I recall some vague mention of needing to have an authentication server similar to Flash on poer 843 or something, but I've never been much interested in web stuff before
[11:26] spoob: I remember something in the code for websocket-nodejs that has an authentication server on 843, so that may be something for you to check. If you have that firewalled, then you would have problems
[11:34] dekz: yeah it has to me something else
[11:35] dekz: from what I can see the headers should be fine
[11:37] spoob: I see the default implementations of websocket only accept local connections, such being defined as file://
[11:37] spoob: There is this comment in one file:
[11:38] spoob: These are the lines that are sent as a handshake from the client.
[11:38] spoob: Chromium sends two blank lines that might be a part of the
[11:38] spoob: specification.
[11:38] spoob: Can you try testing with a different browser than Chromium?
[11:42] dekz: let me download a nightly webkit and run that
[11:45] dekz: oh wow
[11:45] dekz: Sorry to waste your time spoob
[11:45] dekz: I had accidentally left a test socket.send a couple of lines up
[11:46] dekz: thats the reason it was failing, the test was being sent before the headers
[11:46] dekz: wow
[11:46] spoob: OK, no problem. Glad to hear that it works
[11:46] spoob: In fact, gladder to hear that it works as it means everyone else's will as well
[11:48] spoob: And it's because of your question that I've now discovered redis
[11:51] spoob: redis looks really good
[12:12] jfd has joined the channel
[12:33] rolfb has joined the channel
[12:34] rolfb has joined the channel
[12:41] brosner has joined the channel
[12:42] kriszyp has joined the channel
[12:45] felixge_ has joined the channel
[13:33] stevestmartin has joined the channel
[13:38] stevestmartin has left the channel
[13:49] hassox has joined the channel
[14:01] felixge has joined the channel
[14:04] lifo_ has joined the channel
[14:23] joshbuddy has joined the channel
[14:25] hassox_ has joined the channel
[15:34] aho has joined the channel
[15:38] aguynamedben has joined the channel
[15:39] alex-desktop has joined the channel
[15:40] BBB has joined the channel
[15:53] kriszyp has joined the channel
[16:00] mies_ has joined the channel
[16:34] gwoo has joined the channel
[16:43] Booster has joined the channel
[16:56] eikke_ has joined the channel
[16:56] eikke_: did anyone, by accident, ever use node-mongodb and picard in one app?
[17:34] rednul_ has joined the channel
[17:46] unom1 has joined the channel
[17:47] technoweenie has joined the channel
[18:00] scudco has joined the channel
[18:11] dnolen has joined the channel
[18:13] paulca has joined the channel
[18:18] aguynamedben has joined the channel
[18:41] unom1 has joined the channel
[19:06] sixtus42 has joined the channel
[19:08] binary42 has joined the channel
[19:21] ayo has joined the channel
[19:34] paulca has joined the channel
[19:41] CIA-78: node: 03Ryan Dahl 07net2 * r42ee169 10/ (5 files in 3 dirs): Implement new http-parser binding using Buffer - http://bit.ly/5oCAhm
[19:41] almay has joined the channel
[20:03] pjb3_ has joined the channel
[20:13] felixge: ryah: this new process.Buffer, does it handle utf8 streams?
[20:15] ryah: felixge: well, it's quite low-level. i'd say "it doesn't not handle them" :)
[20:15] ryah: so you can do buffer.utf8Slice(0, 10)
[20:15] ryah: which will give you string
[20:16] paulca has joined the channel
[20:16] ryah: but suppose byte 10 lays between a character
[20:16] ryah: that function returns the number of bytes used for the string, say 9
[20:17] ryah: so you need to remember that byte at offset 9 is where you should start the next utf8Slice once more data is available
[20:17] ryah: er
[20:18] ryah: oh right
[20:18] ryah: you have to do something like
[20:18] ryah: buffer.utf8Length(0,10) // => 9
[20:18] ryah: buffer.utf8Slice(0, 9)
[20:18] richtaur has joined the channel
[20:18] ryah: does that make sense?
[20:19] ryah: where utf8Length returns the number of bytes
[20:19] ryah: in net2 neither tcp nor http will be doing utf8 endoing
[20:19] ryah: that will be left to higher interfaces
[20:20] ryah: tcp only emits buffers
[20:20] felixge: ryah: yeah, makes sense
[20:20] felixge: ok, so the buffers emitted by tcp will always be binary?
[20:20] ryah: http emits ascii sometimes (for headers) but Buffer objects for the body
[20:21] ryah: tcp only emits Buffer objects - which is just raw data
[20:21] felixge: ok
[20:21] ryah: i'll try to write up some docs soon
[20:21] ryah: almost done with the http server
[20:21] ryah: the http parser binding works though
[20:21] ryah: should be awesome.
[20:22] felixge: but lets say I have a stream of utf8 coming in, I could use the Buffer object to convert chunks to utf8 without breaking apart a multibyte character?
[20:22] ryah: yes, but you have to be careful
[20:22] binary42: ryah: Looking through quickly, I like the new Buffer setup.
[20:22] ryah: you have to call buffer.utf8Length(startIndex, endIndex)
[20:23] felixge: ryah: yeah, that makes sense
[20:23] ryah: which will say how many bytes make up a string.
[20:23] ryah: buffer.utf8Length(startIndex, endIndex) <= endIndex - startIndex
[20:23] ryah: ^-- always true
[20:23] ryah: binary42: me too. allows a lot of control
[20:24] ryah: can do smart and fancy buffering for tcp/unix streams
[20:24] binary42: Yup. Exactly.
[20:24] felixge: ryah: so if the endIndex would be last the byte but this byte indicates its part of a multibyte character, utf8Length would exclude this byte automatically, right?
[20:25] ryah: felixge: yeah
[20:25] felixge: awesome
[20:25] felixge: love it : )
[20:25] ryah: felixge: then you do sliceUtf8 without that last chars
[20:25] felixge: sweet
[20:25] ryah: (or was it utf8Slice?)
[20:25] felixge: I need to upgrade multipart in the net2 branch soon
[20:25] felixge: so it can handle different encodings for different parts
[20:27] ryah: http://github.com/ry/node/blob/42ee16978e81a0f1fba0768e163b5e9584178fa3/lib/net.js#L129-151
[20:27] ryah: http://github.com/ry/node/blob/42ee16978e81a0f1fba0768e163b5e9584178fa3/lib/net.js#L129-147
[20:27] ryah: pretty simple logic right now -but gives an idea of what you can do
[20:28] ryah: what's good is that buffer.slice() (which returns another buffer) and buffer.asciiSlice() do not copy data
[20:28] ryah: so slicing out http headers should be much cheaper
[20:28] felixge: nice
[20:28] ryah: also uses less memory
[20:29] felixge: can you overwrite data in a buffer?
[20:29] felixge: or are they append-only?
[20:29] ryah: buffers don't have any protection - you an modify it
[20:29] ryah: they can't be grown though
[20:29] ryah: just simple memory chunks
[20:29] ryah: but yeah.. buffer[0] = 123;
[20:30] felixge: so if you modify a buffer that is a slice of another buffer, both buffers change?
[20:30] ryah: yes
[20:30] felixge: interesting, and good to know :)
[20:30] felixge: ryah: will you implement an indexOf() for buffers as well?
[20:31] ryah: the base buffer (which almost always will be allocated by the socket) will be GCed when references to all slices and itself are lost
[20:32] ryah: felixge: hmm.. probably not initially - you need that for multipart right?
[20:33] ryah: i think doing buffer.indexOf('asciistring') should be do able
[20:33] ryah: hm
[20:33] felixge: ryah: well I think it would make sense to make multipart use buffer
[20:34] ryah: well, just do something easy in js at first
[20:34] felixge: yeah
[20:34] ryah: i'll probably add a faster method later
[20:36] ryah: also need a buffer.unpack()
[20:46] felixge: ryah: I might be able to steal v8's String indexOf method as well
[20:46] felixge: : )
[20:47] dnolen has joined the channel
[20:51] rictic has joined the channel
[20:51] jamiew has joined the channel
[20:51] zimbatm: if module A and module B require module C, then the module C's parent will be what ?
[20:52] un0mi has joined the channel
[20:52] zimbatm: from the node.js, it looks like the first module loading C will be the parent ?
[20:53] sixtus42 has joined the channel
[20:54] kriszyp_afk has joined the channel
[20:59] kriszyp has joined the channel
[21:05] zimbatm: ryah: can I ask you some questions about the event system ?
[21:05] inimino: ryah: that all sounds excellent
[21:05] inimino: ACTION is excited about net2
[21:06] zimbatm: yup :)
[21:08] felixge: zimbatm: maybe I can help as well?
[21:09] zimbatm: sure
[21:09] zimbatm: I'm trying to figure out the whole event system to clean things up correctly
[21:10] zimbatm: for example I uncovered yet another bug in the Promise
[21:10] zimbatm: so I thought maybe we can simplify some things up
[21:10] zimbatm: but there are lots of things I don't know, especially in the C++ part
[21:10] felixge: Yeah
[21:11] zimbatm: for example, do you know if there is a single event queue somewhere ?
[21:11] felixge: I think the event system is in C++ right now because ryan uses the the EventEmitter class to wrap C++ variables
[21:11] felixge: zimbatm: you mean for the event emitters? Or for low level events?
[21:12] zimbatm: I mean in the loop
[21:12] felixge: ah
[21:12] felixge: afaik there is no single queue
[21:12] felixge: libeio has its own queue
[21:12] felixge: so does libev
[21:13] zimbatm: is this a deliberate design ?
[21:13] felixge: but I'm no expert on those so I can only provide my understanding of things :)
[21:13] zimbatm: somehow it would be nice to have access to the queue in js :-p
[21:13] felixge: yeah, well libev and libeio are dependencies, but they are both written by the same author and they do quite some different stuff
[21:13] felixge: libev is the event loop
[21:13] felixge: libeio is used to use POSIX within an event loop
[21:14] felixge: libeio spawns its own thread pool to do blocking stuff in the background
[21:14] felixge: zimbatm: it would be nice, but I think this is way too low-level to expose to JS without killing performance
[21:14] felixge: but we can make certain things accessible
[21:15] felixge: for example ryan implement process.IdleWatcher which can be used to create a fairly low level libev watcher
[21:15] zimbatm: nice, I didn't knew libeio was for that
[21:15] felixge: * implemented
[21:15] felixge: libev has pretty good documentation
[21:15] felixge: libeio has considerably less, but you can learn some stuff from it as well
[21:16] felixge: I was also able to grok bits & pieces from reading through the source of both
[21:16] felixge: but my C skills are that of a 3-year old :)
[21:16] ryah: zimbatm: what queue?
[21:16] felixge: I'm at the stage where I get good at re-using words & phrases I see other people using to make up new stuff :)(
[21:17] felixge: ryah: I think he is talking about a global queue for all tasks node is currently performing in the background
[21:18] zimbatm: ryah: my mental model is that there is a queue somewhere with stuff waiting to be processes but apparently there are many
[21:18] felixge: does libev even use a queue?
[21:18] ryah: zimbatm: yeah, depends on what part of the system
[21:18] ryah: felixge: yes it has a queue for watchers that need to be processed
[21:19] ryah: zimbatm: whats the bug?
[21:19] zimbatm: ryah: the bug is for late addCall/errbacks
[21:19] zimbatm: if you look at the code, if (this.hasFired) is will call the callback, even it isn't a value/error
[21:21] zimbatm: L 265 of node.js
[21:21] zimbatm: plus it returns different kinds of values if the callback is late or not
[21:21] zimbatm: plus it may throw an error if the promise is late but not on callback
[21:21] zimbatm: sorry if I'm overwhelming
[21:22] zimbatm: I have the feeling that the promise behavior is not very well defined but I'm willing to help :-)
[21:22] felixge: zimbatm: any help with promises is welcome
[21:22] felixge: the goal is to move towards awesome chainable promises
[21:23] felixge: but we're going slowly as its pretty tricky to get the subtle behaviors right
[21:23] felixge: :)
[21:23] zimbatm: yeah, I'm looking forward for extracting some patterns to promises, like maps and chains
[21:23] ryah: zimbatm: if you can add a test case to test/mjsunit/test-promise i'll fix it
[21:24] felixge: zimbatm: maps ?
[21:24] zimbatm: ryah: I'll submit a patch for those problems a bit later
[21:25] zimbatm: ryah: ok, will do it
[21:27] zimbatm: felixge: waiting for an array of promises to complete
[21:27] zimbatm: imagine an empty array that gets filled asynchronously
[21:27] felixge: zimbatm: yeah, that's a tricky thing
[21:28] felixge: but I'd love to look at your implementation
[21:28] felixge: we need chaining & grouping both
[21:28] zimbatm: promise.map(p1, p2, p3).addCallback( => v1, v2, v3 ) on completion
[21:28] felixge: zimbatm: that works if you assume promises resolve to a singe value, yeah
[21:29] felixge: but that's something we'd want to move towards I think
[21:29] zimbatm: that's what I was going to say
[21:29] isaacs has joined the channel
[21:29] zimbatm: plus, I must refrain from bikeshedding, I prefer promise.commit and promise.break :-p
[21:30] felixge: to me the ideal promise implementation heavily borrows as heavily from the async function all metaphor as possible
[21:30] felixge: commit / break?
[21:30] felixge: for emitSuccess / emitError ?
[21:30] zimbatm: yup
[21:30] zimbatm: and remove the timeout
[21:31] zimbatm: it can easily be added externally anyways
[21:31] felixge: I think the timeout is too useful to remove
[21:31] zimbatm: but then I start changing the whole project and don't know if ryan would like it :-p
[21:32] felixge: well, in my experience he likes simple implementations - so removing something is always interesting :)
[21:32] r11t has joined the channel
[21:34] zimbatm: ok, back to work then :-)
[21:35] felixge: zimbatm: I like Promise.break()
[21:35] felixge: but commit() seems the wrong word
[21:35] felixge: maybe Promise.keep()
[21:35] zimbatm: yeah, that's the idea, keep it semantically correct
[21:36] zimbatm: but I'm not a native english speaker :)
[21:36] felixge: me neither : )
[21:36] felixge: where are you located?
[21:40] eviltwin has joined the channel
[21:40] zimbatm: felixge in the french part of switzerland
[21:41] rictic has joined the channel
[21:41] felixge: zimbatm: berlin here, grüße
[21:42] zimbatm: felixge: danke gleichfalls :)
[21:42] isaacs: ryah: you around?
[21:43] felixge: ACTION wonders why he has to write PHP code on a sunday ... :)
[21:46] jamiew has joined the channel
[21:47] mikeal has joined the channel
[21:48] zimbatm: ryah: http://gist.github.com/285470
[21:49] zimbatm: ryah: what is your preffed patch distribution method ?
[21:51] ryah: zimbatm: that's good
[21:51] ryah: isaacs: yeah
[21:51] isaacs: ryah: ever get around to that dns thing from blaine?
[21:52] ryah: no, but it's on my todo list - i had forgotten about it :)
[21:53] isaacs: kewl. he's pinging me asking about it, and has some new test cases for url
[21:56] gwoo has joined the channel
[21:58] ryah: felixge: any interest in fixing zimbatm's bug ? :)
[21:59] ryah: felixge: (since you're the promise guy)
[21:59] felixge: ryah: yes, gonna take a look in a sec
[22:00] ryah: felixge: awesome
[22:02] cloudhead has joined the channel
[22:16] felixge: ryah: http://github.com/felixge/node/commit/d493dde932ebb93d40296ed3f10a2a0e8689ae1b
[22:17] felixge: that was quite a bad oversight of me :(
[22:19] cloudhead: ryah: did you get my email/patch about the url module?
[22:20] isaacs: cloudhead: what's up with the url module?
[22:20] cloudhead: there's an inline require() in there, which should be moved to the top
[22:21] cloudhead: it's causing some asyncrhonicity when you call url.parse
[22:21] benw has joined the channel
[22:21] cloudhead: took me 3 hours to figure out what was going on
[22:21] cloudhead: lol
[22:22] isaacs: cloudhead: ah, yeah... that amkes sense
[22:22] isaacs: because require() uses wait() even when the module is already loaded.
[22:22] cloudhead: yea
[22:22] CIA-78: node: 03Ryan Dahl 07net2 * rbffa18b 10/ (src/node_buffer.cc src/node_buffer.h): Expose buffer_root() - http://bit.ly/6cOTwP
[22:22] CIA-78: node: 03Ryan Dahl 07net2 * rdda1d68 10/ (src/node_http_parser.cc test/mjsunit/test-http-parser.js): Provide buffer in HTTPParser callbacks. - http://bit.ly/65l5fp
[22:23] isaacs: cloudhead: you have a patch?
[22:23] cloudhead: ya
[22:23] cloudhead: 1 sec
[22:23] isaacs: i'd like to keep querystring parsing in there as an optional arg, but i guess just doing the require() at the top is fine.
[22:24] isaacs: we should probably fix require() at some point, too
[22:24] felixge: damn, does anybody know why AsssertationError !== instanceof Error ?
[22:24] isaacs: because it's misspelled, maybe? :P
[22:24] cloudhead: https://gist.github.com/6a3fd107c0763345a165
[22:24] ryah: i wish we had a code review setup
[22:25] ryah: isaacs: want to code review cloudhead's patch?
[22:25] isaacs: cloudhead: lgtm
[22:25] cloudhead: isaacs: yea, it's a tiny module
[22:25] isaacs: ryah: he just did exactly what i just suggested.
[22:25] isaacs: it's a pretty simple bit of code, really
[22:25] cloudhead: yah
[22:25] isaacs: ryah, cloudhead: ship it!
[22:27] mikeal: ryah: I had a question about http.ServerResponse
[22:27] ryah: mikeal: yeah?
[22:27] mikeal: the sendHeader and sendBody calls don't return promises
[22:27] ryah: no
[22:28] mikeal: like most other calls in node that do IO
[22:28] mikeal: is there a reason?
[22:28] ryah: socket i/o != file i/o
[22:28] mikeal: ok
[22:29] sktrdie has left the channel
[22:29] ryah: they behave quite differently - it's a hard-learned mistake to try and treat them with a similar api
[22:29] mikeal: ok, i'm going to change the ngi spec a bit then
[22:30] isaacs: mikeal: hey, i was thinking, why rewrite all of jsgi? why not just say that apps return an event emitter rather than a fully-baked object?
[22:31] isaacs: then middleware can hijack those events, and return a different event emitter.
[22:31] mikeal: so, leaving out middleware for a second
[22:31] isaacs: k
[22:31] mikeal: there needs to be a spec that an assure portability for the application layer
[22:31] isaacs: agreed
[22:32] mikeal: since jsgi supports a blocking and non-blocking standard they can't insure portability
[22:32] isaacs: rigt
[22:32] ryah: i think there should just be a way to do filters on the body stream
[22:32] mikeal: this was a huge and very long argument in the WSGI community actually
[22:32] isaacs: right, and something that's just like jsgi, but instead of returning a response object, returns an event emitter, then middleware can hop in and filter the body stream easily.
[22:33] mikeal: and what it came down to was WSGI had to be blocking only and support threading and process models, and everyone who needed non-blocking just forked the spec
[22:33] isaacs: the "return a response or a promise that returns a response" still means taht at some point, you need to have a fully-baked response body.
[22:33] felixge: ryah: when you look at merging my promise fix, please also merge: http://github.com/felixge/node/commit/1cc1a0eaed57898fa43a15aee47d9f2a82c2d286
[22:33] mikeal: isaacs: that's not a very nice api to use tho
[22:34] mikeal: here is my point
[22:34] mikeal: what does it mean to say that you are jsgi compliant? without qualifying it some other way?
[22:34] isaacs: mikeal: why not? my app can just take a request as an argument, create an emitter, and then emit whatever's appropriate at the appropraite times, and return the emitter.
[22:34] mikeal: because it doesn't mean you're application is portable between servers
[22:34] isaacs: so, that just meanst aht you need to have a single spec.
[22:34] isaacs: i agree with that.
[22:35] isaacs: and that spec is not "jsgi + blah"
[22:35] isaacs: it's some other thing. and that's what you're doing. and it's great.
[22:35] isaacs: i'm suggesting simplifying it, so you don't have as many different objects and stuff, and so that middleware is easier.
[22:35] ryah: felixge: errors in the main module?
[22:35] mikeal: oh, one question, i was going to reply on the list but since you're here :)
[22:35] mikeal: the script_name vs. scriptName thing
[22:36] felixge: ryah: if you did assert.ok(false) in a unit test it would report a very ugly exception
[22:36] mikeal: i totally see the argument for using the standard js convention
[22:36] felixge: which is due to the try..catch block in which the module code is executed
[22:36] felixge: which gets then delegated to the load promise
[22:36] mikeal: but I've always like knowing which attributes are driven by the spec and which aren't and differing the naming helps me, but I may be in the minority
[22:36] felixge: which had no error handler and thous tried to report the emitvalue as JSON
[22:36] mikeal: if everyone likes scriptName better I can just change it
[22:36] isaacs: mikeal: then namespace them on a different object or something.
[22:37] mikeal: and requestMethod
[22:37] ryah: felixge: hm.
[22:37] isaacs: mikeal: yes, please, camelCase is the convention.
[22:37] mikeal: they are namespace, they are in environ, but i'm sure middleware is going add crap to environ some day
[22:37] ryah: felixge: how is that different than when i do "./node does-not-exist"
[22:37] isaacs: mikeal: yep. until we have Object.freeze, thems the breaks.
[22:38] isaacs: mikeal: middleware will add some_stupid_thing someday, too
[22:38] isaacs: may as well make it less ugly when you can.
[22:38] mikeal: hehe, after i finish this reference implementation
[22:38] mikeal: i'm going to work on ngi-plugins
[22:38] felixge: ryah: that actually throws an instanceof Error object which doesn't cause any display problems
[22:38] ryah: felixge: is the problem that assert errors are not instances of Error?
[22:38] mikeal: which is another spec to provide a good way for application layer middleware to use
[22:39] felixge: ryah: yes and no. I first though that that would be the problem
[22:39] mikeal: isaacs: another question, content_type and content_length
[22:39] felixge: but really, the stuff that is try..catch'ed for the main module should be explicitely re-thrown
[22:39] isaacs: mikeal: i gotta run. email i@izs.me or the list, i'll see it. this is good things your'e doing.
[22:39] isaacs: cheers!
[22:39] mikeal: thanks, i will
[22:39] CIA-78: node: 03Ryan Dahl 07master * rc420c89 10/ lib/assert.js : Make assert.AssertionError instance of Error - http://bit.ly/8iItuA
[22:39] felixge: as those are real exceptions and which have nothing todo with undhandled promise erros
[22:40] felixge: ryah: that's not a real fix. If I throw "Foo" inside a module I'll get an undhandled emitError
[22:40] felixge: which is very confusing
[22:40] felixge: having AssertionError instanceof Error is generally a good idea, but its not the problem at hand here
[22:41] dekz has joined the channel
[22:41] ryah: felixge: okay
[22:41] r11t has joined the channel
[22:42] ryah: felixge: of course the error reported by "throw 'error'" it not so helpful
[22:42] ryah: (even with the patch)
[22:43] ryah: people should never throw errors which arn't instances of ERror
[22:43] felixge: ryah: right, but if they do I'd rather not confuse them even further
[22:50] ryah: felixge: i think the error message without the patch is better
[22:50] ryah: when you run a script with just 'throw "foo"'
[22:50] ryah: with patch:
[22:50] ryah: cloth 0 ~/node > ./node x.js
[22:50] ryah: [object Object].emitError (node.js:249:15)
[22:50] ryah: [object Object]. (node.js:930:19)
[22:50] ryah: [object Object].emitSuccess (node.js:240:15)
[22:50] ryah: [object Object]. (node.js:653:21)
[22:51] ryah: [object Object].emitSuccess (node.js:240:15)
[22:51] ryah: node.js:510:29
[22:51] ryah: node.js:990:9
[22:51] ryah: node.js:994:1
[22:51] rictic has joined the channel
[22:51] ryah: without patch:
[22:51] ryah: cloth 0 ~/node > ./node x.js
[22:51] ryah: Error: Unhandled emitError: ["foo"] at node.js:257:15 at IdleWatcher.callback (node.js:347:5) at node.js:985:9 at node.js:989:1
[22:53] achew22 has joined the channel
[22:54] felixge: hm
[22:54] felixge: I guess
[23:09] RayMorgan has joined the channel
[23:11] bpot has joined the channel
[23:12] scudco has joined the channel
[23:23] binary42 has joined the channel
[23:24] benw: ryah: Did you get a chance to look at the process.exceptionCatcher stuff?
[23:26] benw: I've since committed a fix for a bug I introduced in removeListener, writing test cases now.
[23:27] benw: BTW, you were right - I didn't need to worry about getters and setters and storing the catcher in a C++ variable.
[23:33] mikeal has joined the channel
[23:33] achew22: Is there any documentation on making functions that return promises?
[23:37] mikeal: var p = new Promise(); return p;
[23:37] mikeal: :P
[23:37] achew22: quite the documentation