[00:01] derferman has joined the channel
[00:07] pdelgallego has joined the channel
[00:08] maushu: It is pitch black. You are likely to be eaten by a grue.
[00:11] markwubben has joined the channel
[00:11] pdelgallego has joined the channel
[00:12] maushu: node-mud anyone? :3
[00:17] stepheneb has joined the channel
[00:19] pjb3_ has joined the channel
[00:29] pdelgallego has joined the channel
[00:32] rauchg: _ry: is there an easy way to keep the ServerRequest.connection open
[00:32] rauchg: after a successful request
[00:38] felixge has joined the channel
[00:38] felixge has joined the channel
[00:44] whoahbot has joined the channel
[00:46] rauchg: _ry: the fact that HTTPConnection::onReceive closes the connection makes it impossible to upgrade a http.Server to WebSocket :/
[00:47] _ry: rauchg: yeah - we should probably fix that
[00:47] rauchg: so far i've been doing with TCP
[00:47] rauchg: but of course kills the port 80 
[00:47] rauchg: for anything else 
[00:50] keeto: psst, rauchg. :P
[00:51] rauchg: hi keeto :P
[00:52] _ry: rauchg: i'm in the process of merging in a new http server which is more hackable
[00:52] rauchg: i see
[00:52] _ry: i'd rather think about this after then
[00:52] rauchg: is that in master ?
[00:52] rauchg: sounds good
[00:52] _ry: no, net2
[00:53] _ry: rauchg: http://github.com/ry/node/blob/c6ebfb0cc6be203f702762c0fc484e18592ef2bb/lib/http2.js#L401
[00:54] _ry: probably support is needed in the parser
[00:55] tmpvar: alright, i got node-avro building ^_^
[00:55] _ry: tmpvar: nice
[01:01] RayMorgan: _ry: how is net2 coming along these days?
[01:05] _ry: RayMorgan: it's close
[01:05] RayMorgan: very cool
[01:05] aryounce has joined the channel
[01:05] binary42 has joined the channel
[01:07] schell: what's the net2 branch about?
[01:08] rauchg: apparently doing more in js, what c was doing before 
[01:09] rauchg: it's new to me too
[01:09] rauchg: i'm wondering if this will make node slower 
[01:09] _ry: schell: rewrite of the networking system
[01:09] schell: ah, cool
[01:09] _ry: rauchg: i'm trying very hard to not make that so
[01:10] _ry: it's been sitting on the shelf for months because it was slow
[01:10] _ry: these days its pretty comparable
[01:10] rauchg: i see, that's great
[01:11] schell: is that because v8 sped up or your magic?
[01:12] _ry: until this last commit i made it was faster - but that last commit just improved master's http by 7% 
[01:12] _ry: it seems :/
[01:13] _ry: schell: lots of little hacks
[01:13] Booster has joined the channel
[01:13] schell: hehe
[01:13] schell: magic
[01:14] felixge has joined the channel
[01:14] felixge has joined the channel
[01:15] ryah: http://buildbot.nodejs.org:8010/waterfall <--
[01:16] ryah: lookin good :)
[01:16] ryah: even freebsd isn't so bad
[01:16] Booster_ has joined the channel
[01:19] rauchg: wow
[01:19] rauchg: buildbot ftw
[01:21] rauchg: ryah: is buildbot written in node ?
[01:22] rauchg: it'd be nice to rewrite buildbot in node haha
[01:22] ryah: no
[01:23] ryah: it a python/twisted daemon
[01:25] schell: is buildbot actually building the project or is it more like scanning the code for platform specific gotchas?
[01:25] ryah: it builds it
[01:25] ryah: it checks out a new version each time
[01:27] rauchg: does he tweet /
[01:28] felixge: ryah: is http.server.listen() sync?
[01:29] Cainus has joined the channel
[01:33] ryah: felixge: yes - it won't be in the future though
[01:33] felixge: hm, ok. I'm seeing some odd behavior on OSX right now, need to look into it
[01:36] derferman has joined the channel
[01:39] michaelk^ has joined the channel
[01:40] maushu: rauchg, you need to sacrifice performance for versatility.
[01:41] rauchg: yep
[01:41] maushu: Anyways, I think using v8 shouldn't be too slow since it uses cute ideas behind it.
[01:41] rauchg: in fact it seems like we won't have a performance sacrifice :)
[01:41] rauchg: or a small one
[01:42] JimBastard: javascript party time yaaa
[01:42] brainproxy: has anyone tried bulding node.js on android? possible?
[01:42] maushu: Isn't android based on java?
[01:42] schell: yeah
[01:42] brainproxy: well v8 is implemented on android
[01:43] brainproxy: and you can build python on it too
[01:43] brainproxy: though w/ some limitations
[01:43] maushu: It should be possible. I wonder why you would want to, though.
[01:43] brainproxy: maybe some lightweight listening app
[01:43] brainproxy: dunno, just thinking
[01:45] ssteinerX has joined the channel
[01:49] mikeal has joined the channel
[01:53] brainproxy: I think I'm going to try to build something wity Faye, should simplify some things for me; anyone have experience with how it will deal server-side with very high volumes of traffic in a single channel?
[01:55] kriszyp has joined the channel
[02:01] softdrink has joined the channel
[02:11] derferman has joined the channel
[02:17] ryah: brainproxy: i don't think anyone has got node on android, but it should be posible
[02:17] ryah: might hve to hack around a bit 
[02:18] brainproxy: yeah, i was wondering if I could use it as a very lightweight daemon which could listen for events and fire up another process if needed
[02:19] brainproxy: anyway, just curious, it's going to be awhile before I'm ready to try to implement that
[02:19] brainproxy: there may be facilities in the OS designed for that, which might be more efficient
[02:20] brainproxy: a friend of mine who is a real android hacker was describing the "intent" system
[02:37] steadicat has joined the channel
[02:44] ditesh has joined the channel
[02:45] RayMorgan has joined the channel
[02:46] softdrink has joined the channel
[02:48] binary42 has joined the channel
[02:49] binary42_ has joined the channel
[02:59] r11t_ has joined the channel
[02:59] binary42 has joined the channel
[03:00] CIA-77: node: 03Ryan Dahl 07net2 * r96f08cf 10/ (4 files in 2 dirs): Work on net2 http client - http://bit.ly/dq160D
[03:00] CIA-77: node: 03Ryan Dahl 07master * r61c8014 10/ (AUTHORS ChangeLog doc/api.txt doc/index.html wscript): bump version - http://bit.ly/aKmhzu
[03:05] r11t_ has joined the channel
[03:06] derferman has joined the channel
[03:06] binary42 has joined the channel
[03:07] morgan has joined the channel
[03:08] stepheneb has joined the channel
[03:09] cloudhead has joined the channel
[03:10] r11t_ has joined the channel
[03:11] cloudhead: what's going on with process.mixin?
[03:11] inimino: cloudhead: it's gone
[03:12] cloudhead: inimino: for what reason?
[03:13] Tim_Smart: cloudhead: It was un-neccasary
[03:13] Tim_Smart: cloudhead: Utility functions should be in modules, not core
[03:13] inimino: exactly
[03:14] inimino: sys.inherits should go too
[03:15] mikeal has joined the channel
[03:16] cloudhead: hmm I see
[03:16] cloudhead: well, I'll just have to do some copy/pasting
[03:17] ryah: it's not gone yet
[03:17] ryah: it's on its way out
[03:18] cloudhead: ryah: howbout when mixing into GLOBAL?
[03:18] cloudhead: shouldn't that be in core?
[03:18] ryah: cloudhead: *shrug*
[03:18] inimino: it's called 'global' now, but you shouldn't be doing that at all, right?
[03:19] ryah: not really necessary
[03:19] cloudhead: inimino: why not?
[03:19] tmpvar: cloudhead, bad practice
[03:19] inimino: because polluting the global namespace is bad in general?
[03:20] tmpvar: speaking of bad practice.. ryah: do you know a g++ compiler flag will make g++ not barf when it sees "typedef struct avro_writer_t *avro_writer_t;" ?
[03:20] cloudhead: hmm actually I don't use it that way, I just checked, I use it with require() though
[03:20] ryah: tmpvar: don't do that - i hate when people do that
[03:20] tmpvar: ryah, our avro friends do that
[03:21] ryah: oh
[03:21] ryah: groan
[03:21] JimBastard: javascript party
[03:21] ryah: tmpvar: i dn't know - what's the error?
[03:21] tmpvar: error: conflicting declaration �typedef struct avro_reader_t* avro_reader_t�
[03:22] tmpvar: the error makes sense to me, heh
[03:23] ryah: tmpvar: compile that part with gcc
[03:23] ryah: tmpvar: like how i compile libev with gcc
[03:24] tmpvar: ill peek it
[03:24] cloudhead: anyone got an elegant example of a js project which works both clientside and serverside?
[03:25] ryah: cloudhead: js.io has some cool examples, i think
[03:26] cloudhead: cool, thanks
[03:26] tmpvar: cloud, i ported html-minifier to node last night
[03:26] tmpvar: so it now works on the browser and node
[03:27] cloudhead: oh interesting
[03:27] cloudhead: got a link?
[03:28] tmpvar: http://github.com/tmpvar/html-minifier
[03:28] tmpvar: there is a difference however.. the original lib used qunit.. so i had to sort of hack around it to use msjunit on node
[03:29] cloudhead: hmm
[03:29] cloudhead: no require()s?
[03:29] tmpvar: oh, there are requires heh
[03:29] tmpvar: http://github.com/tmpvar/html-minifier/blob/gh-pages/tests/node.js
[03:29] tmpvar: qunit requires a dom and all sorts of browsery stuff
[03:30] tmpvar: i mapped equals/ok to mjsunit functions
[03:31] tmpvar: among other things heh
[03:31] cloudhead: hmm
[03:31] tmpvar: http://github.com/tmpvar/html-minifier/commit/97b0a35c5090c2e4a9d27a16488a9e620a7f31c6
[03:31] tmpvar: thats the bulk of the changes
[03:31] cloudhead: what I'm having trouble with is doing requires inside files which run both on node and in the browser
[03:31] cloudhead: right now it checks for `window`, and requires if it's undefined
[03:32] cloudhead: but I got a dozen files
[03:32] cloudhead: so in the 1 file version, theres 12 of those checks
[03:32] tmpvar: ah
[03:32] cloudhead: works, but kinda ugly
[03:32] tmpvar: yeah, might be good to go in the direction of using an async require
[03:33] cloudhead: even for the browser?
[03:33] tmpvar: yeah, i believe there is one out there
[03:33] cloudhead: well, that's not very optimal though
[03:33] cloudhead: performance-wise
[03:33] tmpvar: http://github.com/tomyan/soda
[03:33] cloudhead: lots of files
[03:34] cloudhead: the other way I thought of is to use the same build script for the browser, when running it from node
[03:34] cloudhead: so it would rebuild every time you run it
[03:34] tmpvar: ah, I haven't gone down that road as of yet
[03:34] tmpvar: but i'd like to hear what you find out 
[03:39] Tim_Smart: urgh, someone really hates me....
[03:39] cloudhead: yea, I'm hoping I'll find a nice way to do it
[03:41] rictic: Has anyone messed with isaacs/npm?
[03:42] Tim_Smart: rictic: Nope, but it looks promising. A couple here have though
[03:42] rictic: I just used it to install ejsgi, and it seems to have been successful (creating a dir in ~/.node_libraries for ejsgi), but I can't just require("ejsgi")
[03:42] Tim_Smart: *couple people
[03:42] morgan has joined the channel
[03:42] Tim_Smart: rictic: What is the output of require.paths ?
[03:42] rictic: Ahh, I need to activate it
[03:42] Tim_Smart: :p
[03:43] rictic: I missed that step: npm activate ejsgi 0.0.3
[03:43] inimino: I have written a package.json file for it but haven't tried installing my own package yet :/
[03:44] derferman has joined the channel
[03:48] ditesh has joined the channel
[03:56] softdrink has joined the channel
[04:07] isaacs has joined the channel
[04:10] Tim_Smart: isaacs: rictic 16:41 Has anyone messed with isaacs/npm?
[04:10] isaacs: rictic: i have!
[04:10] rictic: I got my issue working :)
[04:10] isaacs: oh, neat
[04:10] isaacs: what was your issue?
[04:10] rictic: Remembering to activate after installing, heh
[04:10] isaacs: i know, that sucks, right?
[04:10] isaacs: it's on my todo list.  if you're installing the first version of something, it should auto-activate
[04:10] kriszyp_ has joined the channel
[04:11] isaacs: the cli needs a lot of work.
[04:11] rictic: Yeah, I've seen other package managers work like that
[04:11] isaacs: Tim_Smart: evalcx!!
[04:11] isaacs: Tim_Smart: wooootttt!!!!
[04:11] rictic: It's nice that npm is out there though, makes me want to package up all of the little bits of functionality I've written over the years
[04:12] isaacs: rictic: that's fantastic!
[04:12] Tim_Smart: isaacs: What did you need it for?
[04:12] isaacs: Tim_Smart: i don't remember.  but it's neat!!
[04:12] isaacs: rictic: feel free to peek under the hood.  it's not very much code, really.
[04:13] Tim_Smart: isaacs: registerExtension is in there too somewhere, ryah made a few changes
[04:13] Tim_Smart: we decided to so sync only
[04:13] isaacs: rictic: or just use it and let me know when you hit snags.  publish and tag are gonna make it a lot nicer.
[04:13] Tim_Smart: s/so/go/
[04:13] rictic: publish and tag?
[04:13] isaacs: rictic: (once i get the couchdb stuff sorted on my host)
[04:13] isaacs: yah
[04:13] isaacs: so you can do this now, but it doesn't quite work without a lot of setup legwork: npm publish http://github.com/isaacs/npm/tarball/master
[04:13] kriszyp_: good work on registerExtension, Tim_Smart, looking forward to trying that out
[04:14] unomi has joined the channel
[04:14] isaacs: rictic: then that looks in the tarball, and publishes that package/version to the registry
[04:14] rictic: Ah, and tag is an aid for searching?
[04:14] isaacs: rictic: then, when i get around to combing through it all (probably this weekend) you'll be able to just do: npm install npm 1.2.3
[04:14] rictic: nice
[04:14] isaacs: and it'll look in the registry site for that package and version
[04:14] isaacs: also, that means that circular deps can work, and that you can auto-install deps.
[04:15] isaacs: (whereas right now, it just fails if they're not there already)
[04:15] Tim_Smart: isaacs: http://github.com/Tim-Smart/node/blob/master/test/simple/test-module-loading.js#L66
[04:15] Tim_Smart: we got the non-string thing in too
[04:16] isaacs: Tim_Smart: that's awesome.
[04:16] isaacs: Tim_Smart: really looking forward to having node stimulate the to-js languages
[04:16] isaacs: they're a cool bunch
[04:17] Tim_Smart: isaacs: Yeah me too. Using coffee in projects will be fun :p
[04:17] Tim_Smart: without having to have the overhead of compiling
[04:17] isaacs: Tim_Smart: plus, maybe we can somehow build an arc server that isn't dog slow ;)
[04:22] ssteinerX: isaacs: have you looked at using git repos as a back-end like mode?
[04:22] isaacs: ssteinerX: i actually specifically chose not to use git for a few reasons.
[04:23] isaacs: ssteinerX: mikeal has written a registry as a couchapp that does what npm needs.  and since things are assumed to be "frozen" once they're published, the whole concept of revisions and such is kinda overkill.
[04:24] isaacs: ssteinerX: also, change tracking is sorta unnecessary, and i'd like to be able to limit access to a simple and protected http api
[04:24] ssteinerX: isaacs: except for being able to pull a fresh dev branch tip out if you're working through a bug with the author
[04:24] isaacs: ssteinerX: you can do that with the registry we've designed
[04:24] isaacs: ssteinerX: (NOT YET FUNCTIONAL) npm install foo nightly
[04:25] ssteinerX: ah, the old NYF trick ;-)
[04:25] isaacs: hehe
[04:25] isaacs: it's my fav!
[04:25] isaacs: srsly, that'll be there pretty soon though.  this weekend or next week.
[04:25] isaacs: depending on how much my server decides to be difficult, mostly
[04:26] isaacs: plus, i don't want inimino to feel like he's left out of the party just cuz he doesn't use git ;P
[04:27] isaacs: ok, gotta run.  birthday party.
[04:27] ssteinerX: l8r
[04:35] PyroPeter has joined the channel
[04:37] cpleppert has joined the channel
[04:43] indiefan has joined the channel
[04:50] derferman has joined the channel
[04:51] derferman has left the channel
[04:54] steadicat has joined the channel
[05:05] tmpvar: ugh... patched avro.
[05:06] rauchg has joined the channel
[05:41] ssteinerX has left the channel
[05:56] mikeal has joined the channel
[05:58] mattly has joined the channel
[06:09] mattly has joined the channel
[06:12] mikeal has joined the channel
[06:29] bentomas has joined the channel
[06:33] indiefan has joined the channel
[06:45] schell has joined the channel
[06:52] binary42 has joined the channel
[06:55] binary42 has joined the channel
[07:03] tmpvar has joined the channel
[07:11] kennethkalmer has joined the channel
[07:15] steadicat has joined the channel
[07:19] jpoz has joined the channel
[07:23] BryanWB has joined the channel
[07:27] JimBastard has joined the channel
[07:32] JoePeck has joined the channel
[07:37] xueyu has joined the channel
[07:43] xueyu_ has joined the channel
[07:46] xueyu_ has joined the channel
[07:49] xueyu has joined the channel
[07:52] pdelgallego has joined the channel
[07:59] gf3 has joined the channel
[08:02] javajunky has joined the channel
[08:15] mikeal has joined the channel
[08:19] Cainus has joined the channel
[08:32] qFox has joined the channel
[08:33] Tim_Smart has joined the channel
[08:36] BryanWB has joined the channel
[08:42] steadicat has joined the channel
[08:43] xueyu has joined the channel
[08:49] teemow has joined the channel
[09:14] pdelgallego has joined the channel
[09:22] pdelgallego has joined the channel
[09:29] pdelgallego has joined the channel
[09:56] felixge has joined the channel
[09:56] felixge has joined the channel
[10:08] pdelgallego has joined the channel
[10:27] kjeldahl has joined the channel
[11:18] spoob has joined the channel
[11:21] ditesh|cassini has joined the channel
[11:27] derferman has joined the channel
[12:02] chakrit has joined the channel
[12:07] maritz has joined the channel
[12:09] ditesh|cassini has joined the channel
[12:15] teemow has joined the channel
[12:19] felixge_ has joined the channel
[12:19] felixge_ has joined the channel
[12:25] ditesh|cassini has joined the channel
[12:31] inarru has joined the channel
[12:33] OSInet has joined the channel
[12:37] ditesh|cassini has joined the channel
[12:40] MattJ has joined the channel
[12:54] piranha has joined the channel
[12:54] BryanWB has joined the channel
[13:03] pdelgallego has joined the channel
[13:06] pjb3 has joined the channel
[13:09] ditesh|cassini has joined the channel
[13:29] confounds has joined the channel
[13:32] pdelgallego has joined the channel
[13:57] kriszyp has joined the channel
[14:06] markwubben has joined the channel
[14:06] binary42 has joined the channel
[14:13] stepheneb has joined the channel
[14:32] pdelgallego has joined the channel
[14:39] codeswing has joined the channel
[14:54] jed has joined the channel
[15:00] jed: this fails silently in node: http://gist.github.com/331357
[15:01] jed: question is, what is the correct behavior? (1) throw an error or (2) send empty headers and default status?
[15:06] alex-desktop has joined the channel
[15:13] maritz: throw
[15:13] maritz: else it encourages bad behavious in my opinion
[15:17] maritz: +r
[15:24] jed: maritz: cool, writing a patch now.
[15:25] micheil has joined the channel
[15:34] JAAulde has joined the channel
[15:34] JAAulde: morning
[15:37] inimino: morning
[15:37] JAAulde: :)
[15:38] JAAulde: my freebsd buildslave failed last night before it even got in to testing node...anyone know what I should fix? http://buildbot.nodejs.org:8010/builders/FreeBSD/builds/3/steps/git/logs/stdio
[15:38] JAAulde: looks like git hosed up, but I don't know why
[15:39] pdelgallego: Hi anybody knows if Nodejs has apply finally to Google Summer of Code
[15:40] inimino: JAAulde: is git in the path?
[15:41] inimino: pdelgallego: yes, yesterday
[15:41] JAAulde: inimino: I believe so, i have had a test get into shell_2 before
[15:41] pdelgallego: inimino, great, I would like to apply as an student. There are some good Ideas in the github wiki
[15:42] inimino: JAAulde: in this path: PATH=/sbin:/bin:/usr/sbin:/usr/bin ?
[15:42] inimino: pdelgallego: great!
[15:42] JAAulde: "which git" outputs "/usr/local/bin/git"
[15:42] JAAulde: and "echo $PATH" outputs "/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin"
[15:42] JAAulde: so I'd say yes
[15:43] inimino: JAAulde: I'd say no, since the path I just pasted above is from your build log...
[15:43] JAAulde: oh
[15:43] JAAulde: weird
[15:43] JAAulde: how on earth did that change?
[15:44] inimino: the build system probably sets up its own environment
[15:44] JAAulde: but i had git work fine before
[15:45] JAAulde: do you know how to destroy a build slave and rebuild it?
[15:45] pdelgallego: inimino, is there a easy familiarize with  node?  I mean not with javascript, but with node internals and design? I am familiar with ruby event machine and I was a commiter in Rubinius VM. So I have some understanding in VM and event programming
[15:45] JAAulde: i wonder if i call create-slave pointing at the same path
[15:46] pdelgallego: inimino, I mean , any starting point more easy than checkout the code from github (that I already did)
[15:46] inimino: pdelgallego: there's pretty good API docs, the code itself is extremely readable, and you can always ask in here if you have questions
[15:46] inimino: nothing more easy no :)
[15:46] inimino: =b 27
[15:46] inimino: erm
[15:47] inimino: disregard that
[15:50] pdelgallego: inimino, Some the I guess I need to have a big cup of coffee  :)
[15:51] inimino: I recommend tea :)
[15:57] JAAulde: well, i rebuilt the slave
[15:57] JAAulde: so we'll see what happens
[15:59] inimino: cool
[16:02] xueyu has joined the channel
[16:16] ssteinerX has joined the channel
[16:20] lifo has joined the channel
[16:32] jed has joined the channel
[16:39] indiefan has joined the channel
[16:43] Harrison has joined the channel
[16:46] ithinkihaveacat has joined the channel
[16:50] xueyu has joined the channel
[16:50] ithinkihaveacat: what's the replacement for process.mixin?
[16:51] ithinkihaveacat: (as used for inheritance)
[16:51] ithinkihaveacat: i don't need a deep copy
[16:52] ashb: for ( var i in o) t[i] = o[i];
[16:52] ashb: or there abouts
[16:53] jed__ has joined the channel
[16:58] Cainus: hey all... Can anyone tell me what's popular for unit-testing node.js apps?  is there a framework, or do people just use the built-in asserts?
[17:01] whoahbot has joined the channel
[17:06] felixge_: Cainus: the built-in assert stuff is perfect I think
[17:06] Cainus: it's a little lo-fi though
[17:06] Cainus: for building suites, etc
[17:06] felixge_: Cainus: just write your own little Makefile or Rakefile
[17:07] confounds has joined the channel
[17:07] Cainus: matching is a bit weak too... but maybe I can build something just for that (ie hamcrest)
[17:08] felixge_: I'm doing *a lot* of unit testing with the build in stuff right now
[17:08] felixge_: I only added a few tiny additions
[17:08] felixge_: Cainus: https://gist.github.com/01cf1517a77f5aad8b4e
[17:08] Cainus: k..so I know make and rake are build config files, but haven't used them... Is that as easy as a framework?  Sounds like it wouldn't be...
[17:09] Cainus: that's for asynch support?
[17:09] felixge_: Cainus: http://gist.github.com/331437
[17:09] felixge_: this will execute all unit tests in your test folder that start with 'test-*'
[17:10] ashb: i've been calling my test files .t.js
[17:10] felixge_: you don't need to execute your unit tests async, I mean node is so blazing fast you'd need a *huge* suite to make this worthwile
[17:10] felixge_: * worthwhile
[17:10] Cainus: you keep test files mixed with source, or in a different tree?
[17:10] felixge_: (unless ofc you are doing it wrong and your tests take forever)
[17:10] steadicat has joined the channel
[17:10] Cainus: nonono... I mean for testing asynch calls
[17:11] felixge_: Cainus: this is how I organize my code: https://gist.github.com/c2441f941f9adc840c7b
[17:11] felixge_: you don't need a suite, I mean just look how node does it's unit tests internally
[17:12] felixge_: it works pretty well
[17:12] felixge_: anyway, brb, 20min
[17:12] Cainus: k... looks like a separate tree for tests
[17:12] ashb: mine is similar
[17:12] Cainus: cool thanks
[17:13] ashb: test support libs go under test/lib
[17:13] ashb: and tests are named test/*.t.js
[17:13] Cainus: so how are people testing asynchronous calls then?
[17:16] alexiskander has joined the channel
[17:17] Cainus: this looks like 1-file-per-test too... is that right?
[17:22] mikeal has joined the channel
[17:23] ashb: Cainus: i do one file per 'thing i'm testing' and how many tests in depends on what the thing is
[17:24] gsf has joined the channel
[17:24] Cainus: yeah that's what I'd rather do
[17:24] Cainus: so how do you test asynchronous stuff?  like an http client fetch?
[17:25] indiefan has joined the channel
[17:25] ashb: haven't need to yet :)
[17:25] Cainus: obviously you can put asserts in the callbacks, but how do you fail if a callback isn't called?
[17:25] Cainus: ah alright
[17:26] Cainus: the asynch part is what I like about node, so I'm sure I'll need to do that a lot
[17:27] Cainus: and how does this system do reporting?
[17:27] dnolen has joined the channel
[17:27] Cainus: I'll want to get it running on a CI server eventually 
[17:35] dnolen_ has joined the channel
[17:40] indiefan_ has joined the channel
[17:43] mikeal has joined the channel
[17:51] unomi has joined the channel
[17:58] teemow has joined the channel
[18:13] stepheneb has joined the channel
[18:14] dnolen has joined the channel
[18:19] morgan has joined the channel
[18:22] OSInet has left the channel
[18:24] bpot has joined the channel
[18:25] lifo_ has joined the channel
[18:38] mikeal has joined the channel
[18:47] ditesh has joined the channel
[18:48] whoahbot has joined the channel
[18:50] dsboulder has joined the channel
[18:52] tmpvar has joined the channel
[18:52] Cainus has joined the channel
[18:57] teemow has joined the channel
[18:58] cpleppert has joined the channel
[19:02] dsboulder: anyone know anything about process.compile?  I'm having scope issues with it...
[19:04] dsboulder: anything I define before I process.compile is unreachable inside the compiled code.  If I switch to eval, it works fine
[19:05] dnolen has joined the channel
[19:07] mikeal: dsboulder: that's by desing
[19:08] mikeal: process.compile is a "safer" eval, it doesn't have access to the scope it is called in
[19:08] dsboulder: mikeal: okay, so I'm stuck with eval if I want it to have access to things I've declared?
[19:08] mikeal: well, no
[19:08] dsboulder: mikeal: I'm trying to eval some jasmine spec code and get nice stack traces
[19:09] mikeal: you can wrap your statement in a function to eval and then call .apply on the evaled function
[19:10] dsboulder: ah, interesting, I think I need to go learn more about what "apply" does
[19:10] mikeal: so
[19:10] mikeal: just do this
[19:10] mikeal: var source = string_to_eval
[19:11] mikeal: var funcwrap = process.compile('function (var1, var2, var3) { return ' + source + '}', 'name')
[19:11] mikeal: funcwrap.apply(funcwrap, [var1, var2, var3])
[19:11] dsboulder: nice, I see!
[19:12] dsboulder: I was just writing that out...
[19:12] mikeal: it's the lazy man's eval context :)
[19:12] mikeal: the only catch is that what you eval needs to be a literal because it has to be returned by the function
[19:13] dsboulder: ok
[19:13] dsboulder: I'll give it a shot, thanks!
[19:13] mikeal: np
[19:19] dsboulder: mikeal: that seemed to work, and I think I now have good stack traces!
[19:19] mikeal: sweet
[19:21] dsboulder: mikeal: what if you don't know all the items you want defined in the eval()? I noticed you pass in var1,var2,var3... I'm assuming those are the functions or data you want available in the compiled code?
[19:22] mikeal: yeah, you have to explicitely send stuff in
[19:23] dsboulder: I see, I think I can dynamically construct that argument list by iterating over the keys in the current scope
[19:24] r11t has joined the channel
[19:26] dsboulder: any idea why there's no process.compile which acts exactly like eval but provides stack traces?
[19:28] r11t_ has joined the channel
[19:31] piranha has joined the channel
[19:32] JoePeck has joined the channel
[19:42] RayMorgan has joined the channel
[19:45] sveimac has joined the channel
[19:45] sveimac has joined the channel
[19:47] r11t has joined the channel
[19:51] pdelgallego has joined the channel
[19:54] pdelgallego has joined the channel
[20:06] mikeal has joined the channel
[20:11] markwubben has joined the channel
[20:20] rauchg has joined the channel
[20:28] Cainus: anyone know what happened to fs.realpath()/fs.realpathSync()?  they're in the docs, but not in the module
[20:29] mikeal: can someone explain to me what this new require proposal actually accomplishes 
[20:29] ssteinerX has left the channel
[20:31] Cainus: bah I must not be up-to-date
[20:45] softdrink has joined the channel
[20:52] kriskowal has joined the channel
[21:24] indiefan has joined the channel
[21:30] jherdman has joined the channel
[21:31] okito has joined the channel
[21:33] ssteinerX has joined the channel
[21:40] felixge_: dsboulder: process.compile does not act like eval, it does not inherit the current scope
[21:40] felixge_: dsboulder: eval does not provide stack trace because JS does not have a feature for it
[21:41] felixge_: dsboulder: process.compile uses internal v8 API's to accomplish backtraces / etc.
[21:41] piranha has joined the channel
[21:52] micheil_mbp has joined the channel
[21:53] r11t_ has joined the channel
[22:00] morgan has joined the channel
[22:07] Duncan has joined the channel
[22:09] Duncan: hi, hope someone can help me with a question regarding multipart.Stream:
[22:09] rauchg: tmpvar: did you email avro-dev@hadoop.apache.org regarding your problems with the C bindings ?
[22:09] tmpvar: i did not
[22:10] rauchg: that'd probably be a good idea
[22:10] Duncan: I found an upload example which uses stream.bytesReceived and stream.bytesTotal but it seems those attr. are no longer available in the latest node release. How do I get the current uploaded data size to calculate the remaining part?
[22:10] tmpvar: rauchg, that may be true.. have you looked at my attempt?
[22:10] rauchg: was looking at it 
[22:11] tmpvar: this is the current error: http://pastie.org/867525
[22:12] tmpvar: which i'd rather not try and unwind, tried a couple times and realized that its going to be a pita
[22:13] tmpvar: something else that looked promising was upb, but from what I've read from the author it doesn't look "ready for use"
[22:15] joshbuddy has joined the channel
[22:21] drostie has joined the channel
[22:33] pdelgallego has joined the channel
[22:33] aryounce has joined the channel
[22:38] okito has joined the channel
[22:43] tmpvar: rauchg, alright I sent off a mail (to avro-user).  do you think you could take a quick peek into the issue? (im far from being a c/c++ guru)
[22:44] rauchg: me neither but i know the guy who wrote the C bindings 
[22:44] rauchg: he also wrote Ganglia 
[22:44] rauchg: he knows his C-fu 
[22:44] rauchg: so i'm sure this'll have a simpler solution than a rewrite
[22:44] rauchg: /hopes
[22:44] tmpvar: surprising considering some of the typedef's :P
[22:45] tmpvar: yeah.. i hope as well
[22:45] tmpvar: goog's pb is going to be a bit of work as well.
[22:50] indiefan has joined the channel
[22:53] paulbaumgart has joined the channel
[22:53] isaacs has joined the channel
[22:59] tmpvar: what is the benefit of using avro as apposed to one of these other protocol buffers?
[22:59] tmpvar: hadoop support?
[23:01] rauchg: that could be one of the benefits
[23:01] rauchg: as well as pig, hive, etc
[23:05] tmpvar: i see
[23:06] rauchg: what i never understood is why a new project was created as opposed to hacking on thrift / PB
[23:06] rauchg: both open source
[23:06] tmpvar: yeah, i dunno
[23:13] steadicat has joined the channel
[23:18] broofa has joined the channel
[23:19] broofa: Hi folks, does anyone here know about the internals of fs.writeFile()?   How efficient is that?
[23:20] tmpvar: broofa, http://github.com/ry/node/blob/master/lib/fs.js#L221
[23:20] tmpvar: (around that line hah)
[23:21] schell has joined the channel
[23:21] schell: hey guys, anyone here?
[23:21] broofa: tmpvar: cool, thx.  looking at that code now.
[23:22] broofa: I guess what I'm after is whether or not it there are performance issues if you have 100's of files being watched. (or 1000's or...?)
[23:22] schell: does anyone know how to catch errors that would otherwise exit execution of a script?
[23:23] schell: like ReferenceErrors, TypeErrors, etc - but in a general way?
[23:23] tmpvar: try {} catch (e) {} ?
[23:23] schell: yeah, tried that - i kind of need it to be more general
[23:23] tmpvar: broofa, what do you mean, watched?
[23:24] schell: wrapping my whole application entry point in try{} catch {} didn't seem to work
[23:24] tmpvar: schell, i think a code example might be helpful
[23:25] broofa: tmpvar: where's stat.start() defined?
[23:26] broofa: tmpvar: I'm debating whether or not it makes sense to implement an in-memory file cache, for serving static files.
[23:26] broofa: assuming it does, it'd be pretty nice if the I could use watchFile() to see when a file changed, and drop the cache for the file.
[23:27] tmpvar: ah, thats much different than writeFile ;)
[23:27] schell: http://gist.github.com/331627
[23:27] broofa: oh, cr*p... I did write 'writefile' didn't I?  oops. :P
[23:28] broofa: meant watchFile.
[23:28] schell: so db creates a child process for couchdb
[23:29] schell: if there is any error that exits execution of the node script, i'm guessing that process is killed brutally, because it locks whatever port couchdb was bound to
[23:29] schell: which means any time there is an error i have to use a new port
[23:30] schell: edit couchdb config, restart
[23:30] tmpvar: ouch
[23:30] schell: i just need a catch-all that i can use to shut down couchdb before the script exits
[23:30] tmpvar: do you have a stacktrace of the explosion?
[23:31] schell: yeah, it's no big deal, it's just any error - like if i delete the definition of a var or function
[23:31] tmpvar: broofa, http://github.com/ry/node/blob/master/src/node_stat.cc 
[23:32] broofa: thx!
[23:32] schell: stacktrace http://gist.github.com/331627
[23:35] schell: bbl
[23:38] paulbaumgart has left the channel
[23:39] broofa: tmpvar: so... looking into bowels of stat.start -> ev_stat_start -> infy_add ... (and, mind you, I'm no C++ guru) ... it looks like stat changes are detected via polling?  Which would seem to suggest that having 100's or 1000's of files being watched is probably not a good idea?  Do I have that right?
[23:40] tmpvar: i doubt it would be a problem
[23:40] broofa: really?  huh, interesting.  Easy enough to test I guess.  thx!
[23:41] tmpvar: it is polling, which is the only way to get at that data.  but since node is an event loop its not going to block on the stat calls
[23:41] tmpvar: so you wont grind to a halt waiting for all 1000 stat's to complete :)
[23:41] broofa: no, I understand that.
[23:42] broofa: but if each file is being polled separately, at some point that's going to add up to a lot of FS churn.
[23:42] pdelgallego has joined the channel
[23:42] broofa: whether it happens in the main loop, or elsewhere... it's still load on FS (and CPU?)
[23:42] kriszyp has joined the channel
[23:42] broofa: ... but I don't have a good feel for where performance issues might lie in this sort of thing.
[23:43] tmpvar: yeah
[23:43] broofa: still pretty new to Node.
[23:43] Cainus: anyone know if there's a way to catch  deprecation warnings?
[23:43] tmpvar: write a test :P .. but im willing to guess you'll be hitting the hd cache for a large amount of your stats
[23:43] broofa: proly, yeah.
[23:44] broofa: thx for your help... off to write some code.  Whee! :D
[23:44] tmpvar: broofa, also.. why not instead of running a large number of stats, just stat the file before sending it across the wire (do caching there)
[23:45] broofa: that works up to a point.  but if you're getting 100's of reqs/second for static resources... dunno.  maybe you're right, given that it's a polling solution either way.
[23:45] Cainus: or maybe suppress them?
[23:46] tmpvar: Cainus, generally the depreciation messages are there to help you know that the functionality is gone/moved
[23:46] broofa: tmpvar: Oh, actually... one reason (possibly) is that I may want to cache gzip'ed versions of the files.
[23:46] Cainus: might as well take it out instead of deprecate it then ;)
[23:46] tmpvar: Cainus, well, then your code would just break with no hint
[23:46] Cainus: for any app that uses standard i/o, it breaks the app
[23:46] broofa: ... since html/css/js can be served gzip'ed. 
[23:47] pdelgallego has joined the channel
[23:47] Cainus: the hint would be that the function doesn't exist
[23:48] tmpvar: Cainus, sure
[23:48] Cainus: yeah you get that for free without deprecation warnings :)
[23:48] tmpvar: broofa, id definately go with the stat on request
[23:49] Cainus: deprecation means its recommended not to use something, and it'll go away in the future... it's not meant to be a way to render something unusable :)
[23:49] tmpvar: in this case, it is the future
[23:49] tmpvar: and they can be used to point you in the right direction aka show you how to fix the problem
[23:50] Cainus: heh is there a case when it's not the future with this scheme?
[23:50] tmpvar: doubtful
[23:50] Cainus: yet the functionality still exists
[23:51] tmpvar: what exactly are you referring to?
[23:51] Tim_Smart has joined the channel
[23:51] Cainus: process.mixin in this case
[23:51] softdrink has joined the channel
[23:51] Cainus: it's easy to fix, but that's not the point
[23:52] Tim_Smart: Cainus: Hmm what is this about process.mixin?
[23:52] rictic has joined the channel
[23:52] tmpvar: he's complaining about the deprecation exceptions
[23:52] Cainus: are they really exceptions?  can I catch them?
[23:52] Cainus: seems like I can't
[23:53] Tim_Smart: Cainus: I think you can
[23:53] tmpvar: no clue, you cant use the code (that no longer exists) in any case
[23:53] Tim_Smart: 
ACTION checks source

[23:53] Cainus: I'm wrapping the require() in try...catch
[23:54] Cainus: I can't really use it, because my app uses standard I/O for the user, and those warnings show up all over the screen
[23:54] tmpvar: oh, yeah.. its just written to stderr
[23:54] tmpvar: and i was incorrect. the code does exist. my bad
[23:54] tmpvar: s/code/functionality
[23:54] Cainus: can I redirect stderr output somehow?
[23:55] Tim_Smart: yeah depreciated functions throw exceptions
[23:55] Tim_Smart: um, not sure
[23:56] tmpvar: http://github.com/ry/node/blob/master/src/node.js#L97
[23:56] tmpvar: yeah, im not certain either
[23:56] Cainus: I just synched an hour ago and my try..catch isn't catching these
[23:56] Cainus: yeah that looks uncatchable
[23:57] Tim_Smart: you won't catch that one, it doesn't throw that one
[23:57] Tim_Smart: *throw an exception
[23:59] Cainus: looks like a bug to me then
[23:59] Cainus: unless there's some way to redir stdio