[00:11] hassox_ has joined the channel
[00:14] jed has joined the channel
[00:18] okito has joined the channel
[00:22] hassox__ has joined the channel
[00:28] jed_ has joined the channel
[00:38] mattly has joined the channel
[00:49] mikeal has joined the channel
[00:55] bpot has joined the channel
[00:56] dnolen has joined the channel
[00:57] mikeal has joined the channel
[00:59] jed_ has joined the channel
[01:04] technoweenie has joined the channel
[01:06] mcarter has joined the channel
[01:09] dnolen_ has joined the channel
[01:17] okito has joined the channel
[01:22] bpot has joined the channel
[01:27] okito has joined the channel
[01:27] technoweenie has joined the channel
[01:28] cloudhead has joined the channel
[01:28] gwoo_ has joined the channel
[01:35] Booster has joined the channel
[01:40] egorFiNE has joined the channel
[01:40] Booster has joined the channel
[01:52] mikeal has joined the channel
[01:53] steadicat has joined the channel
[02:12] charlenopires has joined the channel
[02:13] erichocean has joined the channel
[02:15] gbot2 has joined the channel
[02:15] mattly_ has joined the channel
[02:16] jed has joined the channel
[02:27] technowe_ has joined the channel
[02:33] technoweenie has joined the channel
[02:37] gbot2 has joined the channel
[02:49] JojoBoss has joined the channel
[02:58] gbot2 has joined the channel
[03:00] un0mi has joined the channel
[03:20] Sidnicious has joined the channel
[03:23] erichocean has joined the channel
[03:27] JimBastard has joined the channel
[03:28] onar_ has joined the channel
[03:30] JimBastard: im having some issues getting images to download from node. any idea whats wrong with this? http://gist.github.com/280630
[03:30] mattly has joined the channel
[03:30] JimBastard: ive got the setEncoding messed up i think
[03:32] steadicat has joined the channel
[03:34] inimino has joined the channel
[03:34] jed: JimBastard: setBodyEncoding is just for requests, i think.
[03:34] Sidnicious: is Content-Length neccesary?
[03:34] jed: JimBastard: the second arg of sendBody should do the trick.
[03:35] JimBastard: sup jed
[03:35] jed: JimBastard: hey, man, how ya.
[03:36] kriszyp: yeah, the second arg to sendBody should be "binary"
[03:36] inimino has joined the channel
[03:37] JimBastard: yeah that worked
[03:37] jed: hey kriszyp.
[03:37] JimBastard: for sure
[03:37] JimBastard: thanks
[03:37] kriszyp: hey
[03:37] JimBastard:  resp.sendBody(content, 'binary');
[03:37] JimBastard: :-)
[03:37] jed: teamwork, w00t.
[03:37] gwoo has joined the channel
[03:37] jed: i think that may be underdocumented.
[03:37] JimBastard: i was digging through some of the frameworks to find the code
[03:37] jed: i guess there are three options, binary, utf8, and ascii?
[03:38] jed: all the docs say is ascii is the default.
[03:38] JimBastard: so i guess ill have to do a STAT in order to determine the body encoding?
[03:39] JimBastard: (of the file im trying to serve)
[03:39] kriszyp: if you are sending static content, you can always do binary
[03:39] JimBastard: thats good to know
[03:40] kriszyp: thats the way my static handler does it, and it works good
[03:40] jed: felixge's paperboy might also be instructive.
[03:43] rtomayko has joined the channel
[03:54] gbot2 has joined the channel
[03:55] eddanger has joined the channel
[04:08] jamiew has joined the channel
[04:15] steadicat has joined the channel
[04:16] onar_ has joined the channel
[04:34] markwubben has joined the channel
[04:35] micheil has joined the channel
[04:36] micheil: morning chaps.
[04:36] hassox: hey micheil 
[04:36] hassox: micheil: where are you based?
[04:36] micheil: Australia
[04:37] hassox: sydney?
[04:37] micheil: about 500km west
[04:37] hassox: I think we've done this before haven't we?
[04:37] hassox: hrm no we haven't then...
[04:37] hassox: are you only just getting up now! :P
[04:37] micheil: excepting last time you asked melbourne, and I said 400km north
[04:38] hassox: oh so we have
[04:38] hassox: cool :)
[04:38] jed: hey hassox. how's chain coming?
[04:39] okito has joined the channel
[04:40] hassox: jed: not bad
[04:40] hassox: I'd like some advice
[04:41] hassox: I've started implementing the relevant (non-sync) bits of http://wiki.commonjs.org/wiki/JSGI/Level0/A/Draft2
[04:41] hassox: atm I'm doing the request...
[04:41] hassox: I'm thinking of making most of them getters / setters
[04:41] hassox: any thoughts?
[04:43] deanlandolt: hassox: that seems reasonable
[04:43] hassox: are getters / setters heaps slower than just setting everything when the request comes in?
[04:43] hassox: do you think...
[04:44] deanlandolt: intuition tells me they'd be a little slower with a (tiny amount) more memory overhead, but my gut's usually wrong
[04:45] hassox: I'm not sure just how to benchmark just yet in node
[04:45] deanlandolt: still, premature optimization and all that...if getters/setters get you to a workable implementation they're perfect
[04:45] mattly has joined the channel
[04:46] cloudhead: what convention do you guys use for require paths and all, when requiring your own libs?
[04:47] deanlandolt: cloudhead: do you mean the question of whether to create a main /lib/mylibrary.js as a public interface and put everything else in /lib/mylibrary/?
[04:47] JoePeck has joined the channel
[04:48] deanlandolt: that's popular...i just had that conversation with kriszyp tonight -- he's just putting everything in /lib/ and brought up some good reasons for doing so
[04:49] cloudhead: deanlandolt: I mean requiring external libs actually
[04:49] cloudhead: so like, if you're writing an app
[04:49] kriszyp: hassox: are you aware of http://github.com/kriszyp/jsgi-node/ ?
[04:49] cloudhead: and write a db client
[04:49] cloudhead: where do you put the db client, and how do you require it from your app
[04:50] kriszyp: are you writing a better one?
[04:50] hassox: kriszyp: yes
[04:50] kriszyp: writing a better one?
[04:50] kriszyp: that would be cool
[04:50] hassox: I'm writing a convention that is not ambiguous as to weather or not it's async
[04:50] hassox: I wrote a post on it today
[04:50] jed: interesting. where is the post?
[04:50] kriszyp: hmm, not sure what that means
[04:50] kriszyp: yeah, can i see the post?
[04:51] hassox: I'm not much of a writer ;)
[04:51] hassox: http://doend.wordpress.com/2010/01/18/chain-async-foundation-for-your-web-apps/
[04:51] jed: i decided to make my framework all async. but with nice handlers so that it codes like it's sync.
[04:51] deanlandolt: cloudhead: this is a db client lib you're important?
[04:51] hassox: jed: what's that one?
[04:51] deanlandolt: s/important/importing
[04:51] jed: hassox: http://github.com/jed/fab/
[04:52] hassox: cool
[04:52] cloudhead: deanlandolt: yea
[04:52] hassox: we should nut out how to mount chain in fab and vice versa
[04:52] cloudhead: but I'd like to put it somewhere which allows me to use it in other projects
[04:52] kriszyp: it doesn't sound like JSGI
[04:53] deanlandolt: cloudhead: i'm not sure of the node convention, but frankly, it shouldn't matter where you put it if you control your own require.paths
[04:53] jed: hassox: yeah, (fab) is all about middleware, so it shouldn't be too hard on my end, depending on what chain supports.
[04:53] jed: hassox: chain is definitely more ambitious, i think.
[04:53] deanlandolt: in narwhal (what i'm used to) the convention is to put everythign in a /packages/ dir, or symlink to the actual packages there
[04:53] hassox: jed:  a chain app is just an object that has an onRequest method that takes the chain env 
[04:53] hassox: kriszyp: ?
[04:54] hassox: what do you mean
[04:54] jed: hassox: well, it must do more than that, no?
[04:54] hassox: not much
[04:54] hassox: jed: it's mostly a convention
[04:54] hassox: it does take care of how to transition between middlewares, and sets up some callbacks, but that's about it
[04:54] kriszyp: maybe I am confused, but a JSGI app is a function that takes a request as a parameter, not an interface that implements onRequest
[04:55] hassox: kriszyp: try making a router that you can dynamically add routes to when it's just a function
[04:55] hassox: or make a middleware that is an event emitter
[04:56] deanlandolt: hassox: both are possible
[04:56] cloudhead: deanlandolt: the problem's that the actual files are in /lib/, so I'd have to individually specify all paths
[04:56] deanlandolt: not strictly an "event emitter" but functionally equiv
[04:56] hassox: I asked for ages how to do and now one could tell me
[04:56] kriszyp: also, just in case you are curious what async-ready (handles both sync and async) middleware for pure JSGI looks like, I have written bunch of them here: http://github.com/kriszyp/pintura/tree/master/lib/jsgi/
[04:56] hassox: using an object means it's flexible, and doesn't melt your brain for noobs
[04:57] kriszyp: maybe you are looking to go in a different direction, not sure
[04:57] hassox: kriszyp: I've seen quite a few
[04:57] kriszyp: ok
[04:57] hassox: I'll open that for later reading though
[04:57] JimBastard: whats up with porting Jack to node?
[04:57] kriszyp: you mean JSGI to node?
[04:57] JimBastard: sure
[04:57] kriszyp: it means that JSGI apps can run on Node :P
[04:58] deanlandolt: JimBastard: are you asking whether it's possible to port Jack to node?
[04:58] kriszyp: (or in my case, a web framework can run on Node and Jack)
[04:58] JimBastard: im saying when is someone gonna do it
[04:58] JimBastard: there isnt any good node middleware im aware of
[04:58] kriszyp: we did
[04:58] kriszyp: http://github.com/kriszyp/jsgi-node/ 
[04:59] JimBastard: o
[04:59] hassox: why port a sync model to an async environment ....
[04:59] kriszyp: I've been using it to run pintura on node
[04:59] deanlandolt: kriszyp: what about all the narwhalisms in jack? like multipart stuff?
[04:59] kriszyp: jsgi is async
[04:59] hassox: it's async bolted onto sync...
[04:59] hassox: kriszyp: we've done this before ;)
[04:59] mikeal: i kinda feel the same way at this point
[04:59] kriszyp: deanlandolt: multipart is a pain, it is not actually working yet in node
[05:00] kriszyp: I'll get to that sometime
[05:00] mikeal: i also don't see the value in describing a container that isn't specific to node
[05:00] deanlandolt: kriszyp: cool...i was just kinda curious -- i'm pretty intimate with the multipart stuff in jack
[05:00] kriszyp: well, like it or not, I am able to run on async web framework on node and jack with it
[05:00] hassox: kriszyp: jsgi is borrowed a lot from rack and wsgi which are both sync
[05:00] mikeal: and jsgi is attempting to be not be node specific
[05:00] hassox: there's so much baggage to support for it, why not start a new spec for a new paradigm?
[05:00] deanlandolt: hassox: so? it's also diverged quite a bit from both
[05:01] deanlandolt: the only baggage is naming conventions, which ultimately we mostly eschewed 
[05:01] mikeal: i really don't see the value in doing something not node specific since the IO model is so unique and specific
[05:01] kriszyp: wouldn't you characterize node as fairly promise-based?
[05:01] hassox: kriszyp: no
[05:01] kriszyp: node isn't very unique, narwhal uses the same event-model
[05:01] hassox: i'd charachterise it as an async environment
[05:01] micheil: cloudhead: generally for importing other libs, I go with /lib/vender/{module name}
[05:01] hassox: promises are one way to achive that
[05:01] mikeal: the thing is
[05:02] micheil: node-smtp is also now purely promise based..
[05:02] kriszyp: node is unique in that it supports v8, which rocks :)
[05:02] mikeal: wsgi, and similar specifications, provide a standard connector between an HTTP server and the language bindings 
[05:02] cloudhead: micheil: but isn't the standard format /foo/lib/foo ?
[05:02] hassox: kriszyp: I love a good standard... please don't get me wrong
[05:02] mikeal: so you can not care about the language VM and not care about the server
[05:02] mikeal: and not care about the application framework
[05:02] micheil: cloudhead: yeah
[05:03] mikeal: but making it not specific to the node VM would be useless
[05:03] hassox: but if the standard is too heavy and mostly not relevant, then I think it needs to be heavily revised rather than shoe-horned
[05:03] kriszyp: I am surprised that you don't think node has a slant towards promises
[05:03] micheil: so you might get require(/lib/vendor/foo/lib/foo)
[05:03] kriszyp: it is in a lot of the apis
[05:03] hassox: kriszyp: sure it's there...
[05:03] hassox: but it's just one option in the async toolbox
[05:03] cloudhead: micheil: I see... that's what I was trying to avoid though, I'd like to just be able to do require('foo')
[05:03] mikeal: kriszyp: do the alternate event machines use promises?
[05:03] kriszyp: mikeal: yes
[05:04] mikeal: very nice
[05:04] mikeal: so yeah, if it's not promise driven it doesn't serve much purpose
[05:04] micheil: cloudhead: the reason I go with the lib/vendor/ thing or vendor/xtyz is to not confuse my code with the work of others
[05:04] kriszyp: almost all major event machines out there have realized the necessity of promises for scalable, encapsulated code
[05:04] mikeal: the problem it's trying to solve doesn't really exist
[05:04] hassox: mikeal: why do you say that
[05:04] kriszyp: so why do you think it is good for files, but bad for http?
[05:04] mikeal: because there aren't a number of alternate http servers that don't use similar APIs
[05:05] mikeal: and there aren't a bunch of VMs that can be supported
[05:05] kriszyp: CPS  style (callbacks) couple async handling with the interface design, promise decouple those concerns
[05:05] mikeal: so a connector between the HTTP server and the Application layer seems somewhat useless
[05:05] hassox: kriszyp: can you ensure if I use jsgi that I'm going to have all my middlewares async.. and that the transitions between them will be async?
[05:06] cloudhead: micheil: hmm, the thing is I'd like to distribute some libs which require other libs, so I want it to work in a pretty standard way
[05:06] deanlandolt: hassox: _you_ can ensure that by just building an async stack
[05:06] kriszyp: you mean can I ensure that everyone who writes middleware will write their code correctly? :P
[05:06] kriszyp: um, no :)
[05:06] hassox: deanlandolt: sure if I want to build ever piece of the stack myself
[05:06] mikeal: it's hard to write blocking code in node
[05:06] micheil: cloudhead: sorry, you're not making much sense, but I've not had much sleep so...
[05:06] hassox: kriszyp: no that not what I mean
[05:06] hassox: this is why I think jsgi's async is broken
[05:06] cloudhead: micheil: say I release two libs, and one depends on the other
[05:06] mikeal: hassox: what is the problem you are trying to solve?
[05:07] hassox: if anything sync should be built on top o f async
[05:07] deanlandolt: hassox: you can _assemble_ your stack from async middleware...what's wrong with that?
[05:07] micheil: then put one in the vendor directory
[05:07] mikeal: because the problem wsgi solves isn't really an issue in node
[05:07] hassox: deanlandolt: ?
[05:07] cloudhead: yea I guess that's the best thing to do at this point
[05:07] mikeal: if you want to build a middleware system why don't you write a plugin system or a framework instead of a server connector specification 
[05:07] cloudhead: as a git submodule or something
[05:07] hassox: I want to maximise the amount of community code re-use for an async environment
[05:07] micheil: cloudhead: structure your libs around the commonjs package syntax, then inside the lib folder, along side all your code, have a vendor directory, which has any external libs
[05:07] deanlandolt: hassox: you build your own middleware stack, obviously -- just use good async middleware, what's wrong with that?
[05:08] cloudhead: micheil: sounds good
[05:08] hassox: we're going to need to have "oh it's jsgi... but is it async or sync?"
[05:08] micheil: cloudhead: check out how I've done node-smtp
[05:08] deanlandolt: hassox: i hear you
[05:08] micheil: that's probably my only example of it though
[05:08] hassox: deanlandolt: why not must make it so that all middleware is async in the convention
[05:08] hassox: done deal
[05:08] kriszyp: all the middleware I have written is async
[05:08] hassox: sure
[05:09] deanlandolt: hassox: because that's not how a lot of folks want to code
[05:09] hassox: then don't use node
[05:09] hassox: and don't pollute the middleware landscape with sync middlewares
[05:09] hassox: IMHO
[05:09] cloudhead: micheil: sounds good, thanks
[05:09] deanlandolt: that's fine...but jsgi's not just for node (it's awesome that it can work on node though...thanks kriszyp and was it jed, right?)
[05:09] kriszyp: yeah, it was jed
[05:09] cloudhead: eventually I hope we get some sort of standardized packaging system
[05:10] mikeal: so
[05:10] cloudhead: to not have to deal with this
[05:10] jed: deanlandolt: naw, all kris.
[05:10] deanlandolt: hassox: there'll always be bad code, sync or async...just don't use it
[05:10] mikeal: if you look at the history of attempting to support async with wsgi
[05:10] mikeal: it's a long list of fail
[05:10] deanlandolt: mikeal: indeed
[05:10] hassox: deanlandolt: there's a whole lot more complexity that's introduced by supporting both
[05:11] mikeal: the problem here, is that you have totally different IO models between node and say Rhino or some other js vm
[05:11] hassox: the base we build on should be dead arse simple
[05:11] deanlandolt: hassox: how?
[05:11] kriszyp: anyway, I am not trying to criticize what you are doing with chain, hassox, sounds cool, but JSGI has good traction, it works well with node, and with all the async code I have written, it feels great.
[05:11] deanlandolt: indeed...but rhino has nio
[05:11] mikeal: so having a connector standard that supports both in sync and async systems is insane
[05:11] hassox: kriszyp: I don't mean to crit jsgi, but I know that I am which makes me sad.. :(
[05:12] hassox: I just don't understand why effort is being put into a compromise that fractures the landscape in an async world
[05:12] mikeal: i think there is a place for something **like** jsgi
[05:12] deanlandolt: mikeal: it's less crazy than you think...it's just a matter of a "when"
[05:12] kriszyp: yeah, I think pretty much all the major SSJS players out there are using or moving to the same type of event-loop based evented I/O as node
[05:12] hassox: that being the case, shouldn't we have a standard that is not a compromise
[05:12] deanlandolt: hassox: fractures the landscape? i don't follow? just because sync is possible?
[05:12] hassox: share as much as we can
[05:13] mikeal: so
[05:13] hassox: deanlandolt: because I have to worry about it
[05:13] mikeal: the reason I actually like node
[05:13] deanlandolt: hassox: i'll buy that...
[05:13] mikeal: much more then say Twisted or one of the other async systems for another language
[05:13] deanlandolt: how about that...
[05:13] mikeal: is becuase **everything** is async
[05:13] deanlandolt: err..how about this...
[05:13] mikeal: and you can grab any module, use it, and not worry about it blocking the event machine
[05:13] deanlandolt: we can write some middleware that tests the middleware chain to ensure nothing blocks :)
[05:14] hassox: mikeal: exactly!
[05:14] mikeal: if you create connector standard for sync and async, basically to help people write code that runs anywhere
[05:14] hassox: deanlandolt: righto...
[05:14] kriszyp: deanlandolt: thats a good idea
[05:14] hassox: I'd be happy to join forces
[05:14] mikeal: you're opening the doors to all this crap that people write for blocking IO models
[05:14] hassox: but I'm not wanting a bandaid fix for something at the very start of it's inception
[05:15] deanlandolt: hassox: fair enough...but js is one big baindaid ;)
[05:15] deanlandolt: some things have traction, and there's no getting around it
[05:15] hassox: sure
[05:15] tlrobinson: it's a very elegant band aid if you ask me ;)
[05:15] deanlandolt: heh :)
[05:15] hassox: I know you guys all love it
[05:15] mikeal: so
[05:16] kriszyp: so the objection to JSGI is the use of promises? (since we know that it is async)
[05:16] deanlandolt: the wsgi/rack model has traction and people get it...we can do /that/ and async...what's so wrong with that?
[05:16] hassox: no
[05:16] hassox: that's not the objection
[05:16] hassox: the objection is that it's not async at it's heart
[05:16] hassox: it's an after thought, a compromise
[05:16] kriszyp: cuz I still think promises rock
[05:16] hassox: kriszyp: why bother returning anything
[05:17] hassox: a middleware chain is irrelevant
[05:17] mikeal: the point of a standard is to provide some measure of interoperability when you comply with the standard
[05:17] kriszyp: if you want to look at the commonjs archives, we discussed async http interface from day one
[05:17] hassox: callbacks can be attached where needed
[05:17] kriszyp: that was one of the first messages, actually
[05:17] steadicat has joined the channel
[05:17] hassox: kriszyp: so why didn't you go twith it
[05:17] hassox: ?
[05:17] kriszyp: not sure I understood that
[05:17] mikeal: if you create a sync/async standard for a connector you're basically creating two diverging paths for compliance
[05:17] kriszyp: is hex form of swearing?
[05:17] deanlandolt: hassox: my guess is because jsgi (jack, at the time) worked (that was before my time)
[05:18] mikeal: which means that being jsgi compliant doesn't mean you interop with anybody necessarily
[05:18] deanlandolt: mikeal: being jsgi-compliant means you understand how to pass a request and what to do with a response...
[05:18] mikeal: no
[05:18] deanlandolt: being async-jsgi compliant means knowing what to do with a responsePromise
[05:19] mikeal: i mean you either block
[05:19] mikeal: or you call something that can't be supported in a blocking IO model
[05:19] hassox: deanlandolt: and the two don't always mix, unless you're expecting it...
[05:19] mikeal: so if I'm jsgi compliant there is a 50% chance I actually work
[05:19] deanlandolt: hassox: i get that you could totally tank an event loop
[05:19] micheil: okay.. I think I've got smtp client nutted out.
[05:19] hassox: and even if you do respond with promises, you still have to walk the full length of the middleware stack before you stop blocking
[05:19] mikeal: well
[05:19] micheil: still need to write tests though for it
[05:20] mikeal: and if you respond with promises, what happens in some other javascript VM that doesn't have them
[05:20] micheil: hmm.. time for breakfast.
[05:20] kriszyp: promises aren't at the VM level
[05:20] mikeal: as much as I love promises 
[05:20] deanlandolt: mikeal: then that vm doesn't have an async jsgi server
[05:20] mikeal: it's in process
[05:20] hassox: why impose the implementation of the async behaviour?
[05:20] mikeal: which means it's part of the runtime
[05:21] deanlandolt: kriszyp: aren't there certain engines that can't support event-loops?
[05:21] mikeal: it's not there in my crazy dojo/Rhino SSJS application
[05:21] hassox: why hnot just say, when there's a transition, the transition must not block
[05:21] deanlandolt: or rather, controlling the event loop
[05:21] kriszyp: well, we have it working on rhino, and all the engines work in the browser which is an event loop
[05:21] mikeal: haha, you have the same problem
[05:21] kriszyp: so, no, I don't think there is any that don't support event loops
[05:22] mikeal: now you're saying "you can return some kind of non-blocking primitive that takes callbacks"
[05:22] mikeal: which means it can return anything, which means now you also don't have a way to write good compliance on the server end
[05:22] hassox: mikeal: agreed
[05:22] hassox: its' confusing especially for noobs
[05:23] mikeal: forget about middelware for a second
[05:23] kriszyp: well, I need to head to bed...
[05:23] kriszyp: fun discussion, async rules ;)
[05:24] mikeal: i'm a developer
[05:24] mikeal: i need to be able to write a server that supports this standard
[05:24] mikeal: or i'm a framework developer, and i need to write a web framework that supports this standard
[05:24] hassox: mikeal: yes
[05:24] mikeal: how can I make sure I'm not broken
[05:24] hassox: yeah... dunno
[05:24] hassox: the question also is how do you do mounted applications robustly
[05:25] hassox: and implement routers and any number of other things that need to be addressed
[05:25] mikeal: solve the simple problem first
[05:25] mikeal: before middleware, before Django, wsgi solved the simple problem first
[05:26] mikeal: and kind of messed that up
[05:26] hassox: mikeal: that's what I've been trying to work on
[05:29] cloudhead: micheil: had to do something like this: http://gist.github.com/280694
[05:29] cloudhead: for it to be reliable, regardless of the directory from which I called the script
[05:50] inimino: I wish hassox would write up his objections to JSGI in a single document somewhere, with examples
[05:50] inimino: I still have no idea what all this is really about
[06:34] howardr has joined the channel
[06:34] technoweenie has joined the channel
[06:38] orlando_ has joined the channel
[07:02] un0mi has joined the channel
[07:18] dnolen has joined the channel
[07:28] felixge has joined the channel
[07:32] rictic has joined the channel
[07:34] lifo has joined the channel
[07:38] un0mi has joined the channel
[07:48] felixge: morning
[07:48] mikeal has joined the channel
[07:48] micheil: pure.
[07:53] inimino: morning felixge
[07:54] felixge: inimino: moin
[07:55] felixge: bah I hate getting up early, this is what a late night backup cron jobs life must feel like :(
[07:56] inimino: hehe
[07:56] felixge: does anybody know if the date object can be trusted across different processes?
[07:57] qFox has joined the channel
[07:57] felixge: I'm trying to measure latency, but I'm not sure how to keep time
[08:08] inimino: felixge: it should work fine, of course it only has ms precision...
[08:09] felixge: ms precision is fine :)
[08:11] piranha has joined the channel
[08:15] DamZ has joined the channel
[08:16] zmoog has joined the channel
[08:26] felixge: is anybody else having issues where sys.puts & friends truncate on large strings?
[08:34] BBB has joined the channel
[08:55] teemow has joined the channel
[08:59] erichocean has joined the channel
[09:14] mikeal has joined the channel
[09:19] hassox has joined the channel
[09:23] dnolen has joined the channel
[09:37] un0mi has joined the channel
[09:57] dnolen has joined the channel
[10:01] eviltwin has joined the channel
[10:15] mikeal has joined the channel
[10:23] howardr_ has joined the channel
[10:37] ZhouYu has joined the channel
[10:38] pdelgallego has joined the channel
[10:39] un0mi has joined the channel
[10:48] JimBastard has joined the channel
[10:48] JimBastard: where can i find docs on the update that broke req.uri.path?
[10:49] micheil: it's called the source code probably
[10:52] JimBastard: do you have any idea what the fix is?
[10:52] JimBastard: fu.js is broken and i cant use node_debug >.<
[10:55] blackdog` has joined the channel
[10:57] JimBastard: its require('url').parse(request.url)
[10:58] JimBastard: just not sure how to call it
[11:07] JimBastard: i got it
[11:09] JimBastard: errr so how do i get params using the new url module?
[11:10] JimBastard: errr updated docs http://nodejs.org/api.html#_url_module
[11:20] JimBastard: micheil you have any idea how the new url module works? i can't seem to get the query string params as an object
[11:20] JimBastard: just text
[11:20] JimBastard: i need to replace this   process.mixin(true, httpParams, req.uri.params);
[11:20] micheil: see: http://nodejs.org/api.html#_query_string_module
[11:21] JimBastard: durr got it
[11:21] JimBastard: had to keep reading
[11:21] micheil: url.parse(url, true)
[11:21] micheil: is also used
[11:24] JimBastard: req.uri.params = querystring.parse(req.uri.query);
[11:24] JimBastard: grrrr
[11:24] JimBastard: gotta update a bunch of shit now
[11:27] JimBastard:   multipart.parse(req).addCallback(function(httpParams) { seems to be shitting itself now too
[11:34] dnolen_ has joined the channel
[11:35] piranha_ has joined the channel
[11:55] pyrotechnick has joined the channel
[11:56] pyrotechnick: Has anyone been experiencing intermittent dropouts with node http?
[11:56] pyrotechnick: like hanging requests, bad responses that kind of thing
[11:57] JimBastard: yeah
[11:57] pyrotechnick: I've tried a number of ways to serve a few pages, an a couple of the web frameworks but they all seem to suffer the same issues
[11:57] JimBastard: thats why i just tried updating
[11:57] pyrotechnick: me too
[11:57] pyrotechnick: it doesn't help
[11:57] pyrotechnick: *sigh*
[11:57] JimBastard: i think a process monitor might be needed to restart
[11:58] JimBastard: there are a few things that caus crashes
[11:58] JimBastard: but its getting better
[11:58] pyrotechnick: hmm>
[11:58] pyrotechnick: process monitor?
[11:58] pyrotechnick: mine doesnt crash
[11:58] JimBastard: o
[11:58] pyrotechnick: in fact it keeps responding to future requests after it "bombs" out
[11:58] pyrotechnick: i mean
[11:58] pyrotechnick: it keeps accepting them
[11:58] pyrotechnick: but it never replies
[11:58] pyrotechnick: everything i've downloaded that uses node http seems to be plagued with the same issue
[11:58] pyrotechnick: as well as the code i've written myself
[11:59] pyrotechnick: its such a shame
[11:59] pyrotechnick: i was really enjoying this project i had begun and node really is the only thing that has made it possible
[11:59] pyrotechnick: but it's probably too early to dedicate this much time to when it's this unreliable
[12:00] pyrotechnick: visionmedia's express has the same issue, works perfectly on the first request, subsequent requests bomb out
[12:02] pyrotechnick: if anyone reads this and has a solution/workaround please please email me pyrotechnick@gmail.com or message me on github@pyrotechnick
[12:12] bry has joined the channel
[12:20] micheil: it would have been useful if pyrotechnick had left their os and version of node they were using..
[12:27] jfd has joined the channel
[12:48] alex-desktop has joined the channel
[12:48] DamZ has joined the channel
[12:52] felixge_ has joined the channel
[13:07] charlenopires has joined the channel
[13:07] lifo_ has joined the channel
[13:12] JimBastard has joined the channel
[13:12] JimBastard: so why does   multipart.parse(req).addCallback(function() { error now?
[13:13] JimBastard: Content-Type header not set
[13:21] kriszyp_afk has joined the channel
[13:26] mcarter_ has joined the channel
[13:26] pmuellr has joined the channel
[13:40] Booster has joined the channel
[13:47] felixge_: JimBastard: you are very likely passing in an invalid request
[13:55] stevestmartin has joined the channel
[14:01] dnolen has joined the channel
[14:14] Booster has joined the channel
[14:14] keeto_ has joined the channel
[14:25] davidsklar has joined the channel
[14:44] Booster has joined the channel
[14:54] alexiskander has joined the channel
[15:18] philippbosch has joined the channel
[15:24] cloudhead has joined the channel
[15:41] ZhouYu has joined the channel
[15:53] voodootikigod_ has joined the channel
[15:55] steadicat has joined the channel
[15:56] brianm has joined the channel
[15:57] charlenopires has joined the channel
[16:02] dnolen has joined the channel
[16:05] steadicat has joined the channel
[16:27] _ry: morning
[16:27] DamZ_ has joined the channel
[16:28] stevestmartin: morning
[16:32] philippbosch: hi guys! sorry for this noob question... i'm trying to run the example for process.createChildProcess which is given in the documentation at http://nodejs.org/api.html#_child_processes – shouldn't that output a directory listing? in my case it doesn't output anything. 
[16:35] inimino: morning
[16:36] philippbosch: if i use sys.exec('...') however it works fine
[16:37] inimino: hm, odd
[16:37] inimino: 
ACTION hasn't tried it

[16:37] inimino: philippbosch: got a test case?
[16:40] philippbosch: my testcase is the code in the documentation. 
[16:41] philippbosch: wait, i'll create a paste
[16:41] mattly has joined the channel