[00:00] softdrink has joined the channel [00:00] dnolen has joined the channel [00:11] pedrobelo has joined the channel [00:13] christkv has joined the channel [00:15] christkv_ has joined the channel [00:28] indiefan has joined the channel [00:30] indiefan has left the channel [00:30] indiefan has joined the channel [00:45] christkv has joined the channel [00:47] jgoulah: compilation problem after git pull http://paste.scsys.co.uk/40455 [00:47] pdelgallego has joined the channel [00:48] tmpvar has joined the channel [00:49] gwoo: jgoulah: yeah the build bots are having issues too [00:50] tmpvar has joined the channel [00:50] jgoulah: ok [00:50] tmpvar: hiyo [00:51] gwoo: jgoulah: the Waf needs to be updated [00:55] jgoulah: ok, whats that [01:03] Tim_Smart: the waf is a python build tool [01:05] r11t has joined the channel [01:05] alexiskander has joined the channel [01:09] konobi: jgoulah: howdy [01:10] jgoulah: konobi: hey man [01:10] konobi: jgoulah: fancy seeing you in a place like this [01:10] jgoulah: :) [01:11] r11t_ has joined the channel [01:15] dekz has joined the channel [01:33] derferman has joined the channel [01:46] CIA-77: node: 03Ryan Dahl 07master * r74614c1 10/ deps/libev/wscript : Change libev/wscript for waf 1.5.14 - http://bit.ly/beKYra [01:48] _ry: jgoulah: fixed--^ [01:59] _ry: i can't get this damn buffer stuff to be fast enough... >:/ [01:59] _ry: maybe 'binary' is best after all [02:05] CIA-77: node: 03isaacs 07master * r5861db8 10/ (77 files in 5 dirs): Remove process.mixin dependency from all tests. - http://bit.ly/cY8R0T [02:05] CIA-77: node: 03isaacs 07master * ra38aa02 10/ lib/fs.js : Remove process.mixin dependency from fs - http://bit.ly/9i7xbF [02:05] CIA-77: node: 03isaacs 07master * rc488e57 10/ (3 files): Remove process.mixin dependencies from benchmark scripts - http://bit.ly/aBjCYV [02:05] CIA-77: node: 03Ryan Dahl 07master * r04999ef 10/ (benchmark/http_simple.js deps/v8/SConstruct): [02:05] CIA-77: node: Remove -Werror from deps/v8/SConstruct [02:05] CIA-77: node: -_- - http://bit.ly/919kuy [02:05] _ry: doh. [02:06] _ry: oh well. [02:08] derferman has joined the channel [02:33] gwoo has joined the channel [02:40] abadr has joined the channel [02:56] ben__714 has joined the channel [02:56] ben__714: Hello All [02:56] ben__714: I think I've found a problem with process.createChildProcess [02:58] ben__714: it's data event reads all bytes > 127 as 65533 [02:59] tilgovi has joined the channel [03:06] aho has joined the channel [03:06] CIA-77: node: 03Ryan Dahl 07master * rfb6dc11 10/ (3 files): Clean up some things in the benchmarks - http://bit.ly/aBP72g [03:07] chrischris has joined the channel [03:10] steadicat has joined the channel [03:17] icey has joined the channel [03:18] ben__714: Is anybody out there? [03:19] brapse has joined the channel [03:19] RayMorgan has joined the channel [03:20] ben__714: I would be very grateful if anyone would run the following command and explain the output [03:20] ben__714: var sys = require('sys'); process.createChildProcess('python', ['-c', 'import sys; sys.stdout.write(chr(128))']).addListener('output', function(data){if (data){sys.puts(data.charCodeAt(0));}}) [03:24] mattly has joined the channel [03:25] icey has left the channel [03:33] isaacs has joined the channel [03:38] Sidnicious has joined the channel [03:41] Sidnicious: Bah. I thought that if I got distracted for a couple of weeks and then resumed tinkering with Node, that QueryString's automagical if-it-looks-like-a-number-it-must-be-a-number-right feature would go away :P [03:41] Sidnicious: or, at least, made optional. [03:42] keeto has joined the channel [03:52] mikeal has joined the channel [03:54] bpot has joined the channel [03:56] Sidnicious: I guess I should whip out the editor... [03:57] BryanWB has joined the channel [04:19] alisdair has joined the channel [04:19] derferman has joined the channel [04:20] gsf has joined the channel [04:33] binary42 has joined the channel [04:36] softdrink: soooo… anyone doing anything awesome with node? [04:40] PyroPeter has joined the channel [04:42] aryounce has joined the channel [04:55] cedric_ has joined the channel [04:58] abadr has joined the channel [05:22] joshholt has joined the channel [05:28] mikeal has joined the channel [05:42] morgan has joined the channel [05:50] dandean has joined the channel [06:13] BryanWB has joined the channel [06:14] jturek has joined the channel [06:21] siculars: so i understand how to parse the url to get values, are there examples (on github) to parse form post data? [06:38] _Pilate: siculars: http://nodejs.org/api.html#_tt_multipart_part_tt [06:40] cedricv has joined the channel [06:47] abadr has joined the channel [06:51] mikeal has joined the channel [06:56] brainss has joined the channel [06:58] rektide: anyone using a js framework with node ? [06:58] rektide: sprocket, javascript-maven-tools [06:59] rektide: right now the only must have feature is some way to combine multiple files together [07:09] kjeldahl has joined the channel [07:09] Tim_Smart: rektide: I'll look at implementing a asset packager later on for biggie [07:09] Tim_Smart: I'll make sure it is a standalone library as well [07:10] rektide: i really really really dont like using eval() [07:10] rektide: whichis what i do now [07:10] rektide: are you on twitter Tim ? [07:14] Tim_Smart: yeah, Tim_Smart, whys that? [07:15] Tim_Smart: rektide: What are you using eval for? [07:17] rektide: i have 8 files, and i read them in and eval them [07:17] rektide: rather than have a 2k+ line monster js file [07:25] Tim_Smart: rektide: Why not use the module system? [07:31] mikeal has joined the channel [07:33] rektide: exports blow [07:33] rektide: sorry [07:33] rektide: i need shared context [07:33] rektide: real men need shared context [07:34] rektide: modules is off in la la land pretending you can modularize everything and theres no inter-relation [07:34] rektide: which is utter rubbish [07:35] jed_ has joined the channel [07:36] Tim_Smart: rektide: Modules are fine, all the exports get cached and the references don't change between files [07:36] Tim_Smart: so inter-relations works as expected [07:46] rektide: Tim_Smart: i just dont see how i can compose modules [07:47] rektide: i have a Commons-chain impl and a base implementation of filter/chain [07:47] rektide: how do i put this in a module? how do i write another module to extend this module? [07:47] Tim_Smart: rektide: Maybe throw a quick example on gist? [07:47] mikeal: does anyone know where process.compile is implemented? [07:47] Tim_Smart: mikeal: In process.cc? [07:48] Tim_Smart: nope [07:48] sveimac has joined the channel [07:48] Tim_Smart: there isn't a process.cc :p [07:48] creationix has joined the channel [07:49] mikeal: process.cc is in v8 samples? [07:49] Tim_Smart: mikeal: Line 853 of node.cc [07:49] creationix: for anyone interested, there is a super alpha version of the new jquery style api docs at http://static.creationix.com/node_docs/browser/ [07:50] creationix: only tested in chrome so far [07:50] johanhil: really neat creationix [07:50] johanhil: thank you [07:50] creationix: It's far from done, but it looks pretty atleast [07:50] creationix: the source is at http://github.com/ry/node_docs [07:51] creationix: now to check the licenses of all the codes I borrowed (css from api.jquery.com and showdown.css) [07:51] creationix: *showdown.js [07:52] spot__ has joined the channel [07:52] chrischris has joined the channel [07:52] Tim_Smart: showdown is BSD, creationix [07:52] mikeal: yeah, this all just calls in to a lower level script compiler [07:53] creationix: I couldn't find anything on the style from the jQuery api site. I just linked to it in the footer to be safe [07:53] chrischris has joined the channel [07:53] Tim_Smart: mikeal: Yeah they all invoke the Script->Run() function [07:53] _ry: creationix: wow [07:53] _ry: nice [07:54] creationix: I think plain markdown will be alright. It means no tables unless you want to embed html [07:54] creationix: but it's working fine so far [07:54] mikeal: i really want decent tracebacks without having to write the source i wanna eval to a temp file [07:54] unomi has joined the channel [07:55] jed_: creationix: that's really great! [07:55] Sidnicious has joined the channel [07:55] Sidnicious has joined the channel [07:57] richardb has left the channel [07:58] markwubben has joined the channel [08:03] piranha has joined the channel [08:05] jamiew has joined the channel [08:07] sveimac: creationix: nice [08:14] christkv has joined the channel [08:15] felixge has joined the channel [08:15] felixge has joined the channel [08:16] abadr has left the channel [08:17] javajunky has joined the channel [08:23] indiefan has left the channel [08:24] javajunky has left the channel [08:30] halorgium: _ry: if you're still up, did the net2 branch diverge (usefully) w.r.t the setup code? [08:49] felixge: halorgium: I think net2 is a dead-end and ryan will only take the buffers from it [08:55] halorgium: felixge: ah, intresting [08:56] felixge: halorgium: net2 has performance problems (10-30% slower for hello world), those are probably due to involving V8 more for every request. [08:57] halorgium: felixge: i was interested in it from node-amqp, any idea on that front? [09:00] BryanWB: halorgium, me too, i am interested in that [09:00] BryanWB: would also be neat if node.js had bindings to 0mq [09:01] qFox has joined the channel [09:04] kriskowal has joined the channel [09:05] felixge: halorgium: I think ryan is still working on/with ampq so I think we'll see updates on that front [09:05] felixge: but I'm not following that stuff too closely [09:13] tisba has joined the channel [09:18] morgan has joined the channel [09:22] paulca has joined the channel [09:26] derferman has joined the channel [09:34] felixge has joined the channel [09:34] felixge has joined the channel [09:37] pdelgallego has joined the channel [09:43] halorgium: felixge: good to hear, do you know what the improvements with net2 where originally? [09:44] felixge: halorgium: new networking features (buffers, passing sockets through sockets, etc.), more stuff in JS than C++ to ease maintainence [09:44] derferman has joined the channel [09:51] mcarter has joined the channel [09:53] halorgium: felixge: hmm, so more in line with JS dev but less peformant? seems like a worthwhile cause [09:59] sveimac_ has joined the channel [10:08] kjeldahl has joined the channel [10:11] Mandar has joined the channel [10:28] tlrobinson_ has joined the channel [10:29] sveimac_ has joined the channel [10:38] keeto has joined the channel [10:47] cedric_ has joined the channel [10:47] MattJ has joined the channel [11:00] sveimac has joined the channel [11:31] cedric__ has joined the channel [11:35] cedricv has joined the channel [11:36] felixge has joined the channel [11:36] cedric_ has joined the channel [11:39] cedric__ has joined the channel [11:42] cedricv has joined the channel [11:50] cedric_ has joined the channel [11:56] cedric__ has joined the channel [12:01] sveimac_ has joined the channel [12:16] jed_ has joined the channel [12:18] tlrobinson_ has joined the channel [12:27] erikcorry|away has joined the channel [12:33] erikcorry|away has joined the channel [12:37] alex-desktop has joined the channel [12:39] chakrit has joined the channel [12:46] jed_ has joined the channel [13:12] dnolen has joined the channel [13:12] sveimac has joined the channel [13:17] Booster has joined the channel [13:20] felixge has joined the channel [13:20] felixge has joined the channel [13:24] jed_ has joined the channel [13:24] jed__ has joined the channel [13:33] sveimac has joined the channel [13:34] sveimac has joined the channel [13:37] brainss has joined the channel [13:39] jfherdman has joined the channel [13:40] jherdman has joined the channel [13:40] brandon_beacher has joined the channel [13:40] pmuellr has joined the channel [13:46] chrischris has joined the channel [14:02] dnolen_ has joined the channel [14:02] kriszyp has joined the channel [14:06] brainss has joined the channel [14:08] davidsklar has joined the channel [14:25] cpojer has joined the channel [14:25] cpojer: hello [14:26] cpojer: is there a way, when I catch an error in an exception to print out the trace? [14:26] cpojer: like try { undefined.fn(); } catch (e){ sys.puts(e); } [14:26] cpojer: by doing that it only prints the message and not the trace [14:30] keeto: cpojer: try { undefined.fn(); } catch (e){ sys.puts(e.stack); } [14:30] cpojer: hello keeto! nice to meet you all around over freenode [14:30] keeto: heh. [14:31] cpojer: very nice, thank you [14:35] gf3 has joined the channel [14:38] christkv has joined the channel [14:41] johanhil has joined the channel [14:57] cpojer has joined the channel [14:57] cpojer has left the channel [15:08] brapse has joined the channel [15:19] softdrink has joined the channel [15:20] mjijackson has joined the channel [15:21] dnolen_ has joined the channel [15:25] aryounce has joined the channel [15:31] atcrabtree has joined the channel [15:39] piranha has joined the channel [15:40] atcrabtree has joined the channel [15:43] bronson has joined the channel [15:44] joshholt has joined the channel [15:54] jherdman has joined the channel [15:57] rtomayko has joined the channel [15:58] mAritz has joined the channel [15:59] dnolen has joined the channel [16:00] rtomayko has joined the channel [16:02] n8o has joined the channel [16:03] brainss has joined the channel [16:07] dnolen has joined the channel [16:08] cloudhead has joined the channel [16:08] chandru_in has joined the channel [16:08] chandru_in: is it possible to uninstall node.js after installation? [16:10] inimino: the question has never been asked before ;) [16:10] chrischris has left the channel [16:10] softdrink: it's just dropped in /usr/local/bin as far as i know [16:10] inimino: there's a man page too [16:11] inimino: maybe it's not installed [16:11] inimino: but you can just re-run make install and look at the output [16:12] alexiskander has joined the channel [16:13] chandru_in: thanks softdrink inimino [16:14] dnolen has joined the channel [16:17] scott_gonzalez has joined the channel [16:18] codeswing has joined the channel [16:20] codeswing: guys getting error for this https://gist.github.com/ad9f0a2187db14a7255c [16:21] ashb: codeswing: my psyic debugging services cost. [16:22] chakrit: anyone have a client-side require implementation? [16:22] codeswing: Error: connection.send() has been renamed to connection.write(). (Also the 'receive' event has been renamed to 'data' and the 'eof' event has been renamed to 'end'.) [16:22] codeswing: at Server. (/Users/anil/Code/node/tcp.js:6:7) [16:23] codeswing: at node.js:1031:9 [16:23] ashb: chakrit: there are a number about [16:23] gf3: codeswing... [16:23] codeswing: that is the error i am getting when I do "telnet 127.0.0.1 8000" [16:23] gwoo: codeswing: follow the error message [16:23] gwoo: codeswing: and rename your methods [16:23] chakrit: codeswing: change c.send to c.write ... if that's not already obvious from the error [16:24] chakrit: ashb: Looking for a good one.. any recommendation? [16:24] ashb: no - i've not needed one. i just know that there are a number floating about [16:24] ashb: sorry i cant be of more help [16:25] chakrit: that's ok :) .... I've just ditched LABjs ... too restrictive and buggy [16:25] codeswing: chakrit: okay [16:27] chakrit: codeswing: :) [16:28] codeswing: $ telnet 127.0.0.1 8000 [16:28] codeswing: Trying 127.0.0.1... [16:28] codeswing: Connected to localhost. [16:28] codeswing: Escape character is '^]'. [16:28] codeswing: helloConnection closed by foreign host. [16:28] codeswing: chakrit: it still does not work [16:28] codeswing: it should send message [16:30] chakrit: codeswing: Let me fire up my linux box.. one sec.... [16:32] codeswing: it actually worked [16:32] codeswing: see hello message there [16:32] codeswing: sorry for it [16:32] chakrit: doh! ... haha nvm. [16:34] sztanpet has joined the channel [16:40] bpot has joined the channel [16:43] gbot2 has joined the channel [16:46] chakrit: Just found out that `in` is actually an operator... hmmm [16:46] chakrit: js> 1+1 [16:46] gbot2: chakrit: 2 [16:46] chakrit: js> "hello" in {"hello": "world"} [16:46] gbot2: chakrit: true [16:48] ashb: jspiros: "h" in {"h": undefined } [16:48] ashb: js> "h" in {"h": undefined } [16:48] gbot2: ashb: true [16:48] ashb: even [16:48] ashb: js> "h" in {"y": undefined } [16:48] gbot2: ashb: false [16:48] ashb: is one of its primary use cases [16:48] ashb: same for {"h": false} etc [16:49] inimino: yep [16:49] chakrit: cool [16:49] chakrit: howabout ... [16:49] inimino: there's also hasOwnProperty [16:50] chakrit: so it's the same as hasOwnProperty? [16:50] inimino: not exactly, it looks at the prototype chain [16:50] chakrit: js> {"h": undefined}.hasOwnProperty("h") [16:50] gbot2: chakrit: Error: SyntaxError: invalid label: {"h": undefined}.hasOwnProperty("h") ....^ [16:50] inimino: which hasOwnProperty does not [16:50] chakrit: oic [16:51] inimino: js> ({h: undefined}).hasOwnProperty('h') // true [16:51] gbot2: inimino: true [16:51] chakrit: ACTION wonders what's the last time he learned something new in js? [16:52] inimino: js> ({h: undefined}).hasOwnProperty('toString') // false [16:52] gbot2: inimino: false [16:52] inimino: while... [16:52] dandean has joined the channel [16:52] inimino: js> 'toString' in {h: undefined} // true [16:52] gbot2: inimino: true [16:54] chakrit: cool :) ... I've been doing it wrong for years it seems [16:55] inimino: there is one other little interesting thing in this corner of JavaScript... [16:56] felixge has joined the channel [16:56] inimino: if you use an object as a generic hash table, with arbitrary property names... [16:56] felixge has joined the channel [16:56] inimino: for example storing some kind of user data [16:57] inimino: then it might have an actual property named 'hasOwnProperty' [16:58] inimino: so you should actually write Object.prototype.hasOwnProperty.call(obj,prop) whenever the object could have arbitrary properties [16:59] chakrit: inimino: good tips! ... I've never encountered such uses though... [17:01] steadicat has joined the channel [17:01] chakrit: js> { 10: "test", "10": "another" }[10] [17:01] gbot2: chakrit: Error: SyntaxError: invalid label: { 10: "test", "10": "another" }[10] ....^ [17:01] RayMorgan has joined the channel [17:03] codeswing: https://gist.github.com/a211e3927c2e10fa13b2 what is wrong with this program .. it prints only "hello" where ... is "world" part going ? [17:05] chakrit: codeswing: Try removing one \n or specifying a Content-Length [17:07] inimino: chakrit: it's 'close' not 'finish' [17:07] inimino: erm, sorry [17:07] inimino: s/chakrit/codeswing/ [17:07] CIA-77: node: 03isaacs 07master * r602d186 10/ bin/node-repl : Remove process.mixin from repl - http://bit.ly/cF1Mjg [17:07] CIA-77: node: 03isaacs 07master * rb90d63b 10/ src/node.js : Change the include() message so that it doesn't recommend process.mixin. - http://bit.ly/bmh3Dp [17:08] chakrit: tab completion madness (: [17:08] codeswing: lol it had worked before now saying "TypeError: Object # has no method 'writeHead'" [17:09] inimino: codeswing: then you're using an old node installation [17:09] codeswing: inimino: it's 0.1.30 [17:09] inimino: writeHead is a recent change. [17:10] codeswing: inimino: it's there right [17:10] codeswing: getting "TypeError: Object # has no method 'writeHead" it had worked with similar version on my machine.. [17:11] codeswing: I did not update / change node.js version [17:11] codeswing: it was working before [17:11] codeswing: https://gist.github.com/dba22f346d8421dd066a if anybody want to try that out [17:12] inimino: codeswing: 0.1.30 does not have writeHead... that's why you're getting that error [17:12] codeswing: inimino: hmm .. it's latest as per homebrew ? [17:12] inimino: the latest is 0.1.31 [17:13] codeswing: okay.. [17:13] inimino: which is the one that actually has readHead in it [17:13] inimino: and doesn't have .close() in it, which is why you'll get the other error about that... [17:13] inimino: trust the error messages... [17:14] codeswing: updating [17:16] pdelgallego has joined the channel [17:20] aguynamedben1 has joined the channel [17:21] chakrit: Anyone using client-side js dependency management lib? Any recommendations? [17:27] kriszyp: chakrit, have you looked at RequireJS? [17:28] kriszyp: I am curious what the different client-side js module libraries provide and how they differ... [17:30] kriszyp: and there is also http://webreflection.blogspot.com/2010/03/commonjs-yagni-based-require.html [17:31] chrischris has joined the channel [17:31] nsm has joined the channel [17:31] rektide: sprocket is fairly easy to use [17:32] chrischris has left the channel [17:32] rektide: i'm considering using it for node.js, as opposed to client side [17:34] morgan has joined the channel [17:35] joshbuddy_ has joined the channel [17:36] kriszyp: is sprocket for ruby? how would you use it with node.js? [17:37] kjeldahl_ has joined the channel [17:39] nsm: felixge: would you mind checking if the gsoc-app is changed, it's stuck loading over here [17:39] felixge: nsm: http://socghop.appspot.com/ is loading for me [17:40] nsm: no i mean our application on the github wiki [17:40] nsm: i'm not sure if my edits got committed [17:41] felixge: nsm: someone seems to have edited it, yeah [17:41] paulca has joined the channel [17:41] nsm: great [17:41] chakrit: kriszyp: oh, thanks ... trying those out [17:42] chakrit: rektide: sprocket is on ruby right? [17:42] kriszyp: chakrit: are you want to do the dep management all on the client side, or have concatenation on the server side? [17:45] chakrit: kriszyp: Yah, sort of weighting options on that right now. [17:47] tmpvar has joined the channel [17:47] indiefan has joined the channel [17:48] kriszyp: I've been wanting to do server side handling of sending files with the deps concatenated since it would be a lot faster, but I am not sure if anything has been done in that area yet (or if I should do something there) [17:48] chakrit: The ideal case is that all dependencies should be defined inside the each script file (locality), supporting load-on-demand if possible (as opposed to simple concatenation). [17:49] kriszyp: do you want multiple modules to be sent at once (to reduce latency)? [17:49] chakrit: Yes, of course. [17:50] chakrit: But then... that might not be practical [17:50] kriszyp: why? [17:50] chakrit: What LABjs does is pretty interesting ... have you tried it out? [17:50] kriszyp: I haven't tried it out, I have read about it [17:51] chakrit: kirszyp: Well... if you know what modules depends on what on the first place, that'd be easy to do just concatenate them or something. [17:51] kriszyp: was kind of hoping for commonjs based modules though, so I could share modules client and server [17:52] chakrit: I kind of like... [17:52] chakrit: want a more modular design that doesn't also burden client load times [17:52] chakrit: kriszyp: Yep, something like that too. [17:53] kriszyp: I think narwhal has some code that is supposed to do that, but I don't know how it works or how to use http://github.com/280north/narwhal/blob/master/lib/narwhal/server.js [17:54] chakrit: mmm havn't checked out narwhal for quiet a while ... let's see [17:54] kriszyp: but yes, something modular enough that I could understand the different parts would be nice :) [17:55] chakrit: Well... it seems I should just write one :) [17:55] chakrit: Woah... this is hardcore stuff : // TODO proper recursive descent parser  /(?:^|\s+|;)require\s*\(\s*(['"])([^'"]+)\1\s*\)/g [17:55] kriszyp: I was thinking that a server module that could resolve deps and send the modules over in RequireJS format (and use RequireJS to actually do the client side) might work [17:57] chakrit: kriszyp: Good idea ... but this would be coupled to node.js then. [17:57] kriszyp: and I know requirejs has a module that can do commonjs to requirejs conversion [17:57] kriszyp: not sure if it does the dep resolution though [17:57] RayMorgan_ has joined the channel [17:57] kriszyp: http://github.com/jrburke/requirejs/blob/master/build/convert/convertCommonJs.js [17:59] christkv has joined the channel [18:00] kriszyp: what would be nice is if you do require(["module1", "module2"]); and RequireJS (or whatever is on the client) could send a single request js/module1.js+module2.js that could grab both [18:00] christkv_ has joined the channel [18:01] kriszyp: and also require(["module3", "-module2"]) that would send js/module3.js-module2.js indicating that module2.js is already loaded, and doesn't need to be included in the dep resolution of module3.js [18:01] kriszyp: anyway, just thinking about this... [18:02] chakrit: kriszyp: Indeed.... [18:05] JimBastard has joined the channel [18:08] christkv: to Do or to Flow that's the question [18:08] christkv: anybody got any experience using either [18:09] mikeal has joined the channel [18:11] derferman has joined the channel [18:20] dnolen has joined the channel [18:24] joshholt: christkv: Do seems nice so far... I haven't tried Flow yet [18:24] christkv: yeah I want to avoid banana code [18:24] christkv: any thing I should be aware of when doing do ? [18:26] joshholt: it's pretty straight forward... just try to make use of the built in functions as much as possible... [18:26] joshholt: also I like to combine it with underscorejs [18:28] christkv: you know some of those functions are native in node [18:29] mattly has joined the channel [18:30] joshholt: yeah, some are just wrappers that will call the native code if it exists [18:32] christkv: awesome [18:32] christkv: thanks [18:32] brapse has joined the channel [18:32] joshholt: np [18:33] stephenlb has joined the channel [18:33] kriszyp: christkv: have you tried node-promise? [18:35] technoweenie has joined the channel [18:35] creationix has joined the channel [18:40] christkv: hmm I'll have a look [18:40] christkv: I need something to chain together calls using the mongodb driver but they need to happen serially [18:42] aheckmann has joined the channel [18:45] kriszyp: yeah, node-promise makes it pretty easy to chain things together serially, and you could use some of the code I wrote for wrapping your mongo driver with promises [18:51] joshbuddy has joined the channel [18:52] rtomayko has joined the channel [18:54] creationix: wow, just looked at flow-js, it's super simple, but brilliant [18:54] creationix: if it was adjusted to work with node's async interface, then it would be perfect for simple cases [18:56] gwoo: hmm, flowjs.com is not working for me [18:56] gwoo: creationix: is that the link? [18:56] creationix: http://github.com/willconant/flow-js [18:56] kriskowal has joined the channel [18:57] gwoo: oh that's better [18:57] gwoo: this is very different than what google turned up [18:57] creationix: yeah, it took me a while to find it [18:57] creationix: maybe it's not the same flow others were talking about [18:59] binary42 has joined the channel [19:01] kriszyp: have you looked at narrativejs at all? any thoughts on that? [19:04] christkv: no that's the one I was talking about [19:05] kriszyp: oh, by flow, you meant narrative? [19:11] christkv: http://github.com/willconant/flow-js [19:15] drostie has joined the channel [19:16] RayMorgan_ has joined the channel [19:17] chakrit has joined the channel [19:17] javajunky has joined the channel [19:17] isaacs has joined the channel [19:17] maushu has joined the channel [19:18] javajunky: evening :) Nervous as to how this will end given my last question re process.mixin resulting in its removal ;) I have a quick question! [19:20] maushu: javajunky, wat. [19:20] maushu: Because of you we don't have process.mixin anymore?! [19:20] javajunky: Currently doing some more work on the 'express' framework, and I was looking at the file upload part of it, am I right in understanding that the current (master branch) multipart parser doesn't have a notion of 'abort' ?… if so is it worth me providing a patch for it ? .. Its just so I can add timeout functionality to this parser (and crucically tell the parser to stop bothering to parse) …otherwise I'm concerned someone could swamp the server with malf [19:20] javajunky: yes ;) good times eh .. I was only reporting a bug (and providing a patch for it!) [19:21] maushu: Excuse me while I go get my pitchfork and torche. [19:21] javajunky: don't shoot me, I wanted it! :) [19:22] maushu: javajunky, abort, eh? [19:23] maushu: have you tried forcing the socket close? [19:23] maushu: *closed [19:23] javajunky: oh yes I'm sure I can cause it to happen, but I was hoping for a more 'elegant' 'abort processing of multipart stream' [19:27] andy_l has joined the channel [19:29] danielvf has joined the channel [19:31] atcrabtree has joined the channel [19:35] pedrobelo has joined the channel [19:38] javajunky: hmm, so that was a deafening silence re multipart processing, I guess I'll take my luck and submit a patch ;) [19:40] mikeal has joined the channel [19:44] bpot has joined the channel [19:45] chakrit has left the channel [19:46] isaacs: javajunky: wha? [19:46] isaacs: javajunky: you don't have to abort the multipart parser, you can just close the connection [19:46] jherdman has joined the channel [19:47] isaacs: javajunky: i've been meaning to rewrite the multipart.js to work like a sax-style one-char-at-a-time type thing [19:47] isaacs: javajunky: rather than being coupled to http [19:47] technoweenie: that'd be awesome for email [19:48] chakrit has joined the channel [19:48] chakrit: js> sys.inspect(this) [19:48] gbot2: chakrit: Error: ReferenceError: sys is not defined [19:48] RayMorgan has joined the channel [19:49] chakrit: js> require("sys").inspect(this) [19:49] gbot2: chakrit: Error: ReferenceError: require is not defined [19:49] javajunky: isaacs: so there's not much overhead with leaving it running and then handling the request like 'normal' .. ..ie sending down a 50x type error ? [19:49] isaacs: javajunky: well, currently, yeah, there is a bit of overhead. [19:49] isaacs: but that's why it needs to be rewritten [19:49] isaacs: it's not MUCH overhead, just passing bytes around and emitting events, but still, unnecessary [19:50] javajunky: I just figured I could set an 'error' in the abort method to stop the parse [19:50] javajunky: if its not worth doing I'll just sack it off and close the connection… if the connection closes 'complete' won't fire, right ? [19:52] chakrit has left the channel [19:56] Mandar has joined the channel [19:56] chakrit has joined the channel [19:57] _ry: net2 is going forward [19:57] mrd`: hurrah [20:00] CIA-77: node: 03Aaron Heckmann 07master * rf8eb163 10/ (3 files in 3 dirs): Add removeAllListeners - http://bit.ly/9aN2GZ [20:01] CIA-77: node: 03Ryan Dahl 07master * rdd21a4f 10/ src/node.cc : Remove the 'Error: (no message)' exceptions print stack trace instead - http://bit.ly/9AGbcX [20:08] javajunky: isaacs: hmm, it seems that since I want to make the timeout decision during a http request handling cycle, response.close doesn't well close until the upload completes ? .. am I missing something obvious here ? [20:08] chakrit1 has joined the channel [20:08] isaacs: javajunky: not sure exactly. ping the list about that one (killing a request before it's done uploading) [20:09] morgan has joined the channel [20:16] Cainus has joined the channel [20:19] _ry: javajunky: req.connection.forceClose [20:19] javajunky: isaacs: asked, thanks I guess I'll shelve that plan for now :) [20:20] isaacs: kewl [20:20] _ry: oops [20:20] _ry: nm [20:21] halorgium: _ry: good news about net2 [20:22] inimino: _ry: what changed? [20:25] scott_gonzalez has joined the channel [20:25] WALoeIII has joined the channel [20:25] WALoeIII: anyone have experience with ajaxim? [20:25] WALoeIII: it implements part of the memcached protocol [20:25] WALoeIII: but it doesn't 'respond' [20:25] WALoeIII: not sure if its because I'm running a newer version of node though [20:32] _ry: running tests on my faster computer shows it marginally faster [20:32] _ry: also much less memory [20:33] whoahbot has joined the channel [20:38] gwoo: WALoeIII: yo dude [20:38] WALoeIII: gwoo: hola [20:39] gwoo: WALoeIII: you doin some node stuff? [20:39] gwoo: or jsut ajaxim? [20:39] WALoeIII: bit of both I've written some screw around stuff [20:40] gwoo: nice [20:40] WALoeIII: but right now I'm attempting to use the ajaxim node.js server as the backend for ajaxim [20:40] WALoeIII: it implements this internal interface that uses memcached style protocol [20:40] gwoo: you comin south next month? [20:40] WALoeIII: ya [20:40] gwoo: nice [20:40] WALoeIII: Seattle team [20:40] WALoeIII: Dalton [20:40] gwoo: oh awesome [20:40] gwoo: we'll have to chat about node :) [20:40] WALoeIII: Anthony Boscolo [20:40] WALoeIII: and Mike and I are driving [20:41] WALoeIII: we have the Hinman this year so trying to get people psyched on that [20:41] WALoeIII: node is fun :D [20:41] gwoo: nice [20:41] gwoo: yeah it is [20:41] WALoeIII: JS is so suited to event programming [20:41] kriskowal has joined the channel [20:41] gwoo: and in my opinion its getting better, even thought some people still want mixins and promises [20:41] WALoeIII: been doing some erlang lately too, so its cool to see different approaches to concurrency [20:41] gwoo: definitely [20:41] WALoeIII: annoyingly this script was built against 0.1.18 [20:42] WALoeIII: so I can' ttell if its node that is broken or the old script [20:42] gwoo: it's the script [20:42] WALoeIII: and a bunch of calls changed in the march to 0.1.31 or something [20:42] gwoo: cause it is using old node [20:42] gwoo: :) [20:42] WALoeIII: sendBody -> write and close -> finish [20:42] WALoeIII: ya, just going to require some poking [20:43] WALoeIII: trying to get node_debug up maybe that will give me some hints [20:46] gwoo: just looking at the code on github [20:47] WALoeIII: gwoo: are you gwoo on github? [20:48] malte_ has joined the channel [20:48] gwoo: yup [20:49] WALoeIII: /follow [20:49] WALoeIII: github.com/loe [20:50] gwoo: done [20:53] inimino: _ry: faster than the old stuff? [20:54] inimino: (on some hardware?) [20:54] inimino: that sounds excellent :) [20:57] Sidnicious has joined the channel [20:57] stepheneb has joined the channel [20:58] softdrink: Is anyone here in Utah Valley and looking for a webdev job? [21:00] _ry: inimino: yes [21:00] inimino: nice :) [21:00] _ry: so i'm going to try to get it in today/tonight [21:01] inimino: awesome [21:01] _ry: then we can start on some mad ipc [21:01] inimino: yeah :) [21:01] maushu: My node-gopher is almost done. [21:02] felixge: that new docs site looks really nice [21:02] felixge: ( http://static.creationix.com/node_docs/browser/ ) [21:03] Sidnicious: I've wanted to add an option to turn off numeral support in the querystring module for a while (think I asked about it in here last month)... just got un-distracted enough to do it this morning. I also added an options object to hold that switch, and the eq and separator options in a forwards-compatible way. Sound reasonable? [21:03] maushu: Blasphemy! [21:03] maushu: That doesn't look like man! [21:04] _ry: felixge: it's going to be great when you can view different versions [21:04] softdrink: that does indeed look nice [21:04] felixge: _ry: absolutely, we need this with the fast pace of removing stuff I love right now :) [21:04] paulca has joined the channel [21:04] maushu: Wait, when did we reach 1.31? [21:04] felixge: _ry: you were saying net2 is performing faster then net1 on your machine now? [21:05] _ry: yes [21:05] felixge: _ry: what happened? Did V8 get faster? [21:06] felixge: _ry: I hate it when stuff just randomly changes their behavior under observations, my quantum computing skills are weak [21:06] CIA-77: node: 03Standa Opichal 07master * rc2c0cfb 10/ bin/node-waf : Making sure node-waf finds its real bindir even when executed through a symlinked path. [21:06] _ry: not sure - exactly [21:07] felixge: _ry: you tested with the same v8 version in both branches? [21:07] _ry: but on my mac it's slightly faster/same and using less memory [21:07] _ry: yes [21:07] _ry: the bottle neck was something cpu bound [21:08] felixge: I guess I will not complain if this holds true for linux :) [21:08] _ry: so on the faster machine it wasn't there [21:08] felixge: _ry: Yeah, I mean no matter what I do in V8, it's very hard to get < 100k operations / sec without aiming for it. So we should have enough headroom given the http overhead [21:08] felixge: this makes me very excited [21:08] felixge: :) [21:09] felixge: I already started to live with the thought of net2 being a dead end [21:09] _ry: the memory difference is pretty drammatic i don't really understand what the difference is [21:10] felixge: _ry: well, you're http parser uses much less memory, right? [21:10] _ry: *dramatic [21:10] malte_: felixge: REST interface for dirty http://github.com/cramforce/node-dirty/commit/931557ce822b7f1e3eaa21f97dc1b6a2d91683de# [21:10] _ry: felixge: it's the same parser in both [21:10] inimino: hm, this API browser thing looks OK [21:11] malte_: OK, that commit was somewhat incomplete :) [21:11] inimino: one of the things I like about the existing documentation though is that you can read the whole thing as a single document [21:11] felixge: malte_: based on v0.2 ? [21:11] felixge: seems so :) [21:11] inimino: which I did when I started using node [21:11] inimino: I think that's worth having [21:12] gwoo: inimino: i agree [21:12] malte_: This is better http://github.com/cramforce/node-dirty/commit/325eb5f7c289b010b054ad25572e33e71fd6a2bc [21:12] felixge: malte_: I'm wondering if I should provide 'forEach' rather than filter(). This way people would be less likely to rely on the return value and could go async easier [21:12] malte_: felixge: Yep. I added a quick and dirty impl of filter [21:13] kriszyp: I'd still like to get node-dirty to plug into pintura, than you could also get a REST interface through that (with all the features of pintura) [21:13] malte_: dont care about the name [21:13] felixge: malte_: this looks very cool :) [21:13] aheckmann: The API browser is great - thanks jQuery! [21:13] kriszyp: I've got the mongo driver workign in pintura now as well [21:14] malte_: I also hid my initial sharding implementation in there [21:14] malte_: :) [21:14] kriszyp: malte_: have you looked at the w3c indexeddb api as a store API for RESTful internal interaction? [21:15] felixge: malte_: So do you already have a jquery client for this? :) [21:16] malte_: kriszyp: No (I really only did you REST as a wire protocol) [21:16] kriszyp: that's what I am using in perstore/pintura, i'd love to be able to plug your stuff/node-dirty based on that API [21:16] felixge: _ry: ok, so I guess we're back to asking when net2 will be merged on daily basis :) [21:17] felixge: (just when you thought life was good, and no more "promises" had to be made) [21:17] malte_: $.get("/rest.dirty?filter="+encodeURIComponent((function () {return true}).toString()), function (data) { alert(data) }) [21:17] r11t_ has joined the channel [21:17] felixge: malte_: fair enough :) [21:18] felixge: malte_: I'm also interested in implementing a subset of the redis API, mostly to have a more meaningful benchmark. [21:18] Sidnicious has left the channel [21:18] aryounce has joined the channel [21:18] malte_: kriszyp: Would that supports passing stringified filter functions to the database? [21:18] jherdman: felixge: could you just use the redis lib already available, or is it dead? [21:19] kriszyp: I've been converting normal URL query parameters to store level queries [21:19] felixge: jherdman: client or server? Afaik jan was working on 'awesome' which is an implementation of redis itself in node [21:19] kriszyp: obviously I don't want to execute arbitrary JS from URLs [21:19] jherdman: felixge: client (http://github.com/fictorial/redis-node-client) [21:19] malte_: kriszyp: Why not? [21:19] kriszyp: heh [21:20] felixge: jherdman: yeah, people could use that. But for the benchmarks I'd probably just send queries by hand [21:20] malte_: mongodb does that [21:20] jherdman: gotcha [21:20] kriszyp: site.com/data?function(){process.exit()} [21:22] r11t_ has joined the channel [21:22] malte_: kriszyp: Sure, but thats only a problem if you expose the API to public internet [21:22] kriszyp: you don't want your REST api to ever be suitable for public consumption? [21:23] inimino: you just need to have some authentication gating various features [21:23] inimino: you wouldn't expose DELETE on / to unauthenticated users either... [21:23] kriszyp: because everyone who can authenticate will never do anything adverse? [21:23] kriszyp: generally apps expose different levels of access [21:24] malte_: I just add an unsafe mode to the server. With a REST API to a data access layer security is needed anyway. [21:24] malte_: Same if you would allow a request to REMOVE / [21:24] kriszyp: sure, but having insecurities built into the REST API design doesn't seem like a good foundation for adding security [21:25] kriszyp: right, but queries are often associated with read-only access [21:25] kriszyp: not just admin-level access (those that could truly be trusted) [21:25] malte_: But the db isnt called "Clean&Safe". Using eval was pretty much mandatory for Dirty [21:25] mrd`: You can always put the admin-level stuff on a separate port that untrusted users can't access. [21:26] derferman has joined the channel [21:26] mrd`: I generally like that as a solution more than using in-channel authentication, just because I trust my firewall rules more than my authentication code. :) [21:26] kriszyp: right, but the functions can be created behind the REST layer [21:26] JimBastard: it burns when iptables [21:26] mrd`: JimBastard: That's why you should be using pf. :) [21:27] kriszyp: for instance, it is pretty reasonable to create filter functions based on url query parameters that can be passed to node-dirty [21:27] JimBastard: its those slutty linksys routers, i knew i shouldnt have VPN'd in without protection [21:27] JimBastard: using default passwords, giving open access to anyone, dirty dirty [21:28] kriszyp: here is some code that I use to convert the queries to filters if it is any help: http://github.com/kriszyp/perstore/blob/master/lib/resource-query.js [21:28] erikvold has joined the channel [21:29] felixge: just for the record: I will not include an official REST interface for dirty. The use cases I have in mind would only expose app-specific interfaces rather than general purpose db features. [21:29] kriszyp: that makes sense felixge [21:29] kriszyp: I think that is good pattern for most storage level systems (let REST be built on top of it) [21:29] felixge: I do however think it would be great to have for doing little jQuery apps quickly [21:30] JimBastard: felixge: are you familiar with sammy.js? [21:30] felixge: JimBastard: yeah, it's cute [21:30] felixge: JimBastard: did not have an excuse to use yet [21:30] kriszyp: and fwiw, with a REST api, you can do a lot OOTB with Dojo as well, like plugging a grid right up to the REST api [21:30] JimBastard: sammy is a good case for what you are talking about i think [21:31] JimBastard: ya, the author AQ is a real cool guy [21:31] felixge: JimBastard: Jed is also planning to make (fab) client side, so I'm curious how that works out [21:32] JimBastard: once you solve the back button issues (aka onhashchange event) cross-browser making sammy like frameworks is pretty easy [21:33] felixge: kriszyp: My vision of dirty is that it acts as the base for re-usable data storage / data access patterns. People just take dirty +1-2 plugins and have a db that does what they want and nothing else [21:33] JimBastard: its just a state machine based on location.hash [21:33] kriszyp: right, which is great [21:33] maritz has joined the channel [21:33] aguynamedben has joined the channel [21:33] kriszyp: I definitely like what you have done with node-dirty, felixge, good work [21:34] felixge: kriszyp: thanks. you coming to jsconf, right? [21:34] JimBastard: how does node-dirty compare to the memory adapter for node-persistance? [21:34] kriszyp: no, not this year [21:35] kriszyp: it stores data on disk? [21:35] felixge: kriszyp: seems like node-peristence does it as well [21:35] felixge: JimBastard: checking it out right now [21:35] felixge: http://github.com/creationix/node-persistence/blob/master/lib/persistence/memory.js [21:35] derferman has joined the channel [21:36] kriszyp: seems funny to call it "memory" then :) [21:36] JimBastard: there are some issues with node-persist right now....but node-dirty sounds just like node-persist, minus everything but the memory adapater [21:36] felixge: JimBastard: looking at the code, dirty should be much faster [21:36] JimBastard: the file part is recent, and its only for between node running [21:36] felixge: JimBastard: well, dirty will never expose any query language by itself [21:37] JimBastard: got ya [21:37] christkv: do I remember wrong but was there any talk at some point to add some basic native binary encoding functionality to node ? [21:37] maritz: i think we need to enforce some kind of rules regarding the wiki/modules section. everyone puts their stuff in it and some try to highlight it in certain ways. :/ [21:37] felixge: JimBastard: the persist stuff looks nice. Just less specialized [21:37] felixge: * or more I should say [21:37] christkv: to encode stuff like integers and floats [21:37] felixge: dirty specializes in simplicity and speed [21:37] felixge: :) [21:37] maritz: also: the describing text could use a little neutrality [21:37] JimBastard: got ya [21:38] JimBastard: really i just want an easy way to persist data to multiple places using a common api [21:38] rictic has joined the channel [21:38] JimBastard: so if i want to switch from sqllite to mongo its a one liner [21:39] felixge: JimBastard: That abstraction is gonna cost you :) [21:39] JimBastard: i mean yeah, but it would cost me even more if i couldnt store my data anywhere [21:39] JimBastard: i can deal with performance hits until it becomes a problem [21:39] felixge: JimBastard: depends on what system you are building [21:40] JimBastard: i can't deal with code hits, because development time is precious [21:40] JimBastard: yeah obviously [21:40] inimino: christkv: coming eventually with net2's buffers [21:40] christkv: also you'll sacrifie functionality [21:40] christkv: inimino: awesome might help me speed up the mongo driver a bit [21:42] kriszyp: having a shared consistent interface for operations that are common doesn't exclude having drivers/data stores exposing additional functionality [21:42] JimBastard: heh does anyone have any extra jsconf tickets btw, ill sell my soul for a couple [21:42] Tim_Smart has joined the channel [21:42] felixge: JimBastard: I'd try talking to companies sponsoring if they have any tickets that may go unused [21:42] JimBastard: of course the moment i had the money to buy tickets it was sold out [21:43] JimBastard: felixge: do you think that would actually work? lol i have 0 experience when it comes to these events [21:43] christkv: kriszyp: up to a point, you can only provide the minimum intersection of functions without breaking the 'compatibility' right [21:44] kriszyp: sure, finding a balance is important [21:44] Tim_Smart: _ry: Hey, is there any tests specific to require()? [21:44] felixge: JimBastard: no idea if it would work, but it has better chances than doing nothing :) [21:44] JimBastard: word word [21:44] felixge: Tim_Smart: test-module-loading [21:44] JimBastard: ill try that and see what i can do [21:44] Tim_Smart: cheers. felixge [21:47] aguynamedben1 has joined the channel [21:52] jed has joined the channel [21:52] felixge: jed: heya :) [21:52] christkv: _ry ? I take it you don't use twitter ? [21:52] felixge: christkv: http://twitter.com/ryah [21:52] r11t has joined the channel [21:52] christkv: awesome thanks [21:52] felixge: jed: question for ya: what shape is fab currently in? [21:53] christkv: are you guys using a specific #tag for node? [21:53] christkv: #nodejs ? [21:53] felixge: christkv: yeah, that's what I use [21:53] christkv: felixge: great, thanks [21:53] jed: felixge: not quite there yet. [21:54] jed: felixge: v3 is a total rewrite. [21:54] WALoeIII: gwoo: the event 'receive' was renamed to 'data' so my event loop was just waiting forever [21:54] felixge: jed: I see [21:54] jed: felixge: but i guarantee you'll like it. [21:54] gwoo: WALoeIII: ah yeah [21:54] felixge: jed: well, I'm supposed to upgrade david's project to node HEAD this week, but I'll suggest to delay that if fab isn't ready yet [21:54] WALoeIII: a little bit of lunch and it comes so easily :D [21:54] felixge: jed: not feeling like porting the old version to node:HEAD :) [21:55] jed: yeah, i had a lot of work come in this week. [21:55] jed: but am back to working on it now. [21:55] jed: felixge: would you like a short gist explaining what it'll look like? [21:56] jed: felixge: it's much simpler than the current version. [21:58] felixge: jed: totally [21:59] jed: felixge: okay, i'll write a quick one. back in 10. [22:02] derferman has joined the channel [22:07] malte_: felixge: Now with sharding http://github.com/cramforce/node-dirty/commit/fed07ebd5fae0971a312c139fde11c40de1650e1 [22:07] malte_: ACTION hides [22:08] felixge: malte_: hah, nice [22:08] felixge: :) [22:10] felixge: malte_: I noticed you use '.listen' rather then something like '.createServer' [22:10] felixge: malte_: why is that? [22:11] malte_: I guess because it already starts listening [22:11] malte_: Could be changed [22:11] javajunky: 'woot' finally commissioned my linode box to play with node.js, good times :) [22:12] felixge: malte_: I kind of like sticking to node's conventions - good or bad - just to make things easier to learn [22:12] malte_: felixge: In node listen is a method of the server [22:12] felixge: right [22:13] christkv: felixge: lol which one :D [22:13] malte_: Thats why I used it so you dont get confused that it is already listening [22:13] felixge: malte_: anyway, I like the rest interface itself [22:14] felixge: I'll have to start thinking on how I want these kinds of plugins/extensions done sooner now :) [22:14] malte_: For a final interface createServer is better so you have a place to call close on [22:14] felixge: so they can work together [22:14] felixge: right now your server would be hard to combine with other dirty things :) [22:14] malte_: you should think about making the API async [22:15] malte_: That makes it more transparent that the implementation is JS only [22:15] derferman has joined the channel [22:15] malte_: and one can implement the Dirty interface with async backends [22:16] malte_: allows switching from internal store to a "real" database without changing the code [22:16] felixge: malte_: well, it'd be hard since there are 2 distinctly different guarantees: a) Data written to memory b) Data written to disk [22:16] malte_: two callbacks? [22:17] felixge: malte_: well, data written to memory is always sync, so I'm not sure it should have a callback [22:17] felixge: malte_: it's only async if you put a network in front of it [22:18] felixge: malte_: I guess I could add an optional callback to '.get' [22:18] malte_: or a process [22:19] Tim_Smart: _ry: Right, test cases added, and internal docs added [22:19] Tim_Smart: for registerExtension [22:19] felixge: Tim_Smart: would love to see the commits [22:20] Tim_Smart: http://github.com/Tim-Smart/node/commits/registerExtension [22:20] felixge: Thttp://github.com/Tim-Smart/node/compare/9c2644575c05bd0d9733c2722d5c3f15252df2d8...e5895d230cfea46f8a1934ee59bf76d0d5b41867 :) [22:20] felixge: * http://github.com/Tim-Smart/node/compare/9c2644575c05bd0d9733c2722d5c3f15252df2d8...e5895d230cfea46f8a1934ee59bf76d0d5b41867 [22:20] felixge: the new compare thingie is nice [22:20] Tim_Smart: felixge: _ry asked me to use braces as much as possible, hence the partially irrelevant braces commit [22:21] felixge: Tim_Smart: why are you changing event emitter? [22:21] Tim_Smart: I'm not [22:21] Tim_Smart: :p [22:22] Tim_Smart: http://github.com/Tim-Smart/node/commit/e939b1f53e63d5411a07b49f1d66fa0931c98906 [22:22] tlrobinson1 has joined the channel [22:23] tlrobinson_ has joined the channel [22:23] tlrobinson1 has left the channel [22:23] _ry: Tim_Smart: hm, i meant in your own code :) [22:23] brapse has joined the channel [22:23] Tim_Smart: felixge: Probably a better compare: http://github.com/Tim-Smart/node/compare/master...registerExtension [22:23] _ry: Tim_Smart: single line ifs are allowed [22:24] felixge: I hate single line ifs :) [22:24] Tim_Smart: I guess it doesn't hurt anyone? [22:24] felixge: they show weak [22:24] felixge: * weakness [22:25] felixge: Tim_Smart: looks like it could be done simpler, the feature [22:25] felixge: unfortunately I gotta sign off for now, but I love seeing this being worked on [22:25] felixge: will allow interesting things [22:25] felixge: :) [22:26] felixge: gn8 [22:26] Tim_Smart: night :p [22:26] _ry: felixge: later [22:26] malte_: Good night (same timezone) [22:26] Tim_Smart: _ry: We could add a extra arg to _loadContent, then compile it in there [22:27] Tim_Smart: the extra arg represent a async require or not [22:27] Tim_Smart: *representing [22:27] _ry: Tim_Smart: would that make it simpler? [22:27] derferman has joined the channel [22:28] _ry: I don't really understand why doing it directly before process.compile wouldn't work [22:28] Tim_Smart: _ry: Probably not [22:28] Tim_Smart: _ry: To add support for async compilers [22:28] _ry: ah [22:28] _ry: is coffee async? [22:28] Tim_Smart: we can make it async, by running it in it's own process [22:29] _ry: hm - why not just sync? [22:29] Tim_Smart: because coffee adds a lot of start-up overhead, and I might want to do a async require in the middle of execution or something [22:30] Tim_Smart: well compilers in general take a lot of time [22:30] _ry: coffee itself is written in js? [22:30] Tim_Smart: yes [22:31] _ry: i don't know. i'm doubtful if this really matters. [22:31] Tim_Smart: I didn't want to compromise require.async with time consuming compiles [22:31] Tim_Smart: so people who strive for having true async for lengthy operations, can if they want [22:32] _ry: i'm pretty sure starting the extra process is going to be more overhead than compiling a script [22:32] isaacs: it'd be best if require.async wasn't broken for coffee's (or any other to-js language) sake [22:32] Tim_Smart: But i agree, having it sync everywhere would be much simpler [22:33] isaacs: the compiler doesn't need to be async if it's not doing IO during the compilation process, though [22:33] _ry: isaacs: right [22:33] _ry: if the compiler needs to do i/o then i would agree with Tim_Smart [22:33] isaacs: what compilers do IO during the compilation process, though? [22:33] _ry: well - a preprocessor loads files [22:33] _ry: in gcc [22:34] isaacs: oh, good point... [22:34] isaacs: but, this isn't gcc [22:34] isaacs: it's js, so why not just turn that into a require()? [22:34] Tim_Smart: isaacs: Yeah, I guess you have to decide where async is needed, because this is a pretty big blocking call [22:34] _ry: Tim_Smart: define 'pretty big' ? [22:34] isaacs: Tim_Smart: the point is, anything that's not-IO, you can pretty much just write off as a rounding error in terms of time/etc. [22:34] Tim_Smart: _ry: As in, definately noticable [22:34] _ry: Tim_Smart: hm [22:35] isaacs: Tim_Smart: like, loading Rhino noticeable? [22:35] _ry: Tim_Smart: really? why? [22:35] _ry: compiling coffee to js shouldn't be difficult [22:35] Tim_Smart: Well, I'll see if I can benchmark a coffee require, compared to a normal one [22:36] sveimac has joined the channel [22:36] _ry: unless i'm misisng something big about coffee script [22:36] _ry: it's just a change of syntax, or? [22:36] isaacs: Tim_Smart: My gut guess is that the time required to load the file is about around 10-50x longer than the time to compile coffee to JS, or else the compiler is deeply broken. [22:36] sveimac has joined the channel [22:37] Tim_Smart: isaacs: Well, I'll come back with some times [22:37] isaacs: (or maybe your hard drive is much faster than mine, and your processor much slower?) [22:43] isaacs: bored? port a ruby module to JS. http://github.com/isaacs/abbrev-js [22:49] morgan has joined the channel [22:50] jed: i guess felixge took off, but in case anyone else here is interested in the approach that v3 of (fab) will take: http://gist.github.com/327241 [22:51] Tim_Smart: isaacs: It is 25x slower [22:51] davemo has joined the channel [22:51] Tim_Smart: overall [22:52] isaacs: Tim_Smart: ok, great! [22:52] isaacs: Tim_Smart: (you mean, the IO is 25x slower than the compile?) [22:52] Tim_Smart: the entire js require, vs the coffee require [22:52] isaacs: or that cs is 25x slower than js? [22:52] isaacs: yikes!!! [22:52] Tim_Smart: so IO + compile [22:52] isaacs: but the JS has the same amount of IO [22:52] Tim_Smart: yes [22:52] isaacs: holy cow [22:53] Tim_Smart: so that is what I mean by 'noticeable', and why I insisted on keep async available to compilers as well [22:53] Tim_Smart: *keeping [22:54] isaacs: right [22:54] isaacs: well, i mean, i might want to do a require() in the middle of some chain of execution, and not want to block for sync io anyhow [22:54] isaacs: require.async still needs to work [22:55] isaacs: but the compiler should jump in to translate the contents of the file into a javascript function [22:55] Tim_Smart: require.async would still work, but it would have a blocking call if I decided to go the simple route [22:55] isaacs: i'm also keen to use this for a template system [22:55] Tim_Smart: sure, that would work :p [22:55] isaacs: so you could use require() to pull in haml files or whatever [22:56] isaacs: just have your app register an extension, and use that to do the view stuff [22:56] Tim_Smart: It also means, the async feature would work nice with the Mu module [22:56] isaacs: exactly [22:56] isaacs: mu, moustache, ejs, etc. [22:56] isaacs: alla them [22:56] Tim_Smart: but, I'm not sure how you would make a sync version from a async module [22:57] Tim_Smart: maybe throw an error or somethign [22:57] isaacs: well, the key is, you don't. [22:57] Tim_Smart: yeah, which is cool with me [22:57] isaacs: require() does two things: it reads the contents of the file, and it turns it into a javascript function. [22:57] isaacs: require.async just does the read step async [22:57] isaacs: you just need registerExtension to let you jump into the middle there. [22:58] Tim_Smart: which it does, but does it do it the best way as of now? [22:58] isaacs: Tim_Smart: i haven't looked at it ;) [22:58] Tim_Smart: http://github.com/Tim-Smart/node/compare/master...registerExtension [22:58] isaacs: Tim_Smart: i just kinda figured you've got "smart" in your name, so you must've done a great job with it. [22:58] isaacs: :P [22:59] Tim_Smart: huh, well, it's only a last name :p [22:59] isaacs: they picked a good one! [23:00] isaacs: single-line blocks are fine. multi-line blocks need {}. [23:00] isaacs: if (something) [23:00] isaacs: thisIsTerrible() [23:00] isaacs: as long as it doesn't break 80 chars [23:02] isaacs: i'd probably do it as: registerExtension(".coffee", function (code, cb) { cb( turnCodeIntoFunction(code) ) }) [23:02] isaacs: then, whether it's sync or not doesn't much matter. [23:03] isaacs: oh, i guess then the compiler needs to be blocking, or else var foo = require("foo"); won't work [23:04] whoahbot has joined the channel [23:04] Tim_Smart: isaacs: ya [23:04] isaacs: in that case maybe you just skip the cb/async stuff [23:04] isaacs: registerExtension(".coffee", function (code) { return someFunction; }) [23:04] Tim_Smart: isaacs: Which it does, and just takes the return value [23:05] isaacs: right [23:05] isaacs: but only in "sync" mode [23:05] Tim_Smart: yup [23:05] isaacs: i'm saying, since require() is gonna async the IO in require.async, just go ahead and block. [23:05] isaacs: if your compiler is really THAT slow that it matters, then it needs work. [23:05] Tim_Smart: I could omit the 'async' parameter, and just pull pass the callback arg as null [23:05] Tim_Smart: when sync [23:06] Tim_Smart: isaacs: Well for app start-up, sync requires won't matter anyhow, as it is start-up [23:06] isaacs: right [23:06] isaacs: Tim_Smart: if you're going to omit the async flag, and pass the cb as null, why not just drop it altogether and make the code tighter? [23:07] Tim_Smart: so having blocking calls there doesn't change much [23:08] Tim_Smart: well it just saves an argument that is all, but I think having the async arg there forces people to think about an async option [23:08] aheckmann has left the channel [23:09] Tim_Smart: which they probably should [23:09] Tim_Smart: http://github.com/Tim-Smart/node/compare/master...registerExtension#diff-2 <- Should explain the guts of it [23:09] Tim_Smart: The test case, that it [23:10] Tim_Smart: *that is [23:11] isaacs: well, but i mean, that's just it... why even give them the option to be slow with their compiling? [23:11] whoahbot has joined the channel [23:11] isaacs: since you have to be able to work when it's a blocking require() anyhow [23:11] Tim_Smart: so drop async, or drop sync? [23:11] isaacs: drop async (from registerExtension) [23:12] Tim_Smart: isaacs: Then people can't use things like Mu module with it [23:12] isaacs: and just rely on require.async to get you the code asynchronously, turn it into a function (sync) and then hand it off [23:12] isaacs: Tim_Smart: sure you can [23:12] Tim_Smart: Mu has no sync option [23:12] isaacs: so, you do this: require.async("somefile.mu" [23:12] isaacs: oh, whaaa? [23:12] isaacs: mu doesn't just transform the code into a function? [23:12] Tim_Smart: isaacs: It streams the result back [23:13] Tim_Smart: So you could compile via a web-service if you wanted as well [23:14] isaacs: Tim_Smart: well.. sure.... but that seems like an odd use-case.. [23:14] brapse has joined the channel [23:14] Tim_Smart: yeah, well, I guess leave the option up to the developer is what I am saying [23:15] isaacs: Tim_Smart: http://github.com/raycmorgan/Mu/commit/a1ef5d766f1aa3eea0e2ec74a9d2923e220e5a47 [23:15] jed_ has joined the channel [23:15] isaacs: looks like Mu is back on the table with sync compilation ;) [23:15] Tim_Smart: ".addListener('data', function (c) { sys.puts(c) });" [23:16] Tim_Smart: not quite :p [23:21] isaacs: oh, well, close enough [23:21] isaacs: oh, no wait... [23:21] isaacs: well, worry about coffeescript, and we'll get mu to work later. [23:22] isaacs: it's possible now-ish [23:22] Tim_Smart: Coffeescript works fine atm :p [23:29] gwoo: isaacs: hows npm? [23:30] isaacs: gwoo: it's coming along. you can install tarballs, link folders, and activate a version of a package. it links in dependencies, and creates bin executable files. it's not very user-friendly, but it works pretty reliably at what it does. [23:30] gwoo: nioce [23:31] isaacs: gwoo: i need to wire it up to the registry site that mikeal wrote yet, but it's not too far off. [23:31] gwoo: what's the deal with kiwi? [23:31] gwoo: isaacs: oh nice [23:31] erikvold has joined the channel [23:31] isaacs: gwoo: not sure. have to ask visionmedia about that one :) [23:31] gf3 has joined the channel [23:31] gwoo: yeah seriously [23:31] mikeal: it's in bash...... [23:31] isaacs: gwoo: i hear it's feature-rich, though. [23:31] mikeal: :( [23:31] mikeal: hahahhahahahhaa [23:31] gwoo: mikeal: oh [23:31] isaacs: ACTION is an ass. [23:31] gwoo: isaacs:haha [23:31] gwoo: yeah that's about all you hear [23:31] gwoo: ahah [23:31] gwoo: but it's sponsord [23:32] isaacs: i submitted a patch to tj with a package.json file, but he hasnt' accepted it. [23:32] mikeal: sponsored by who? [23:32] isaacs: if you pull from my kiwi branch, you can install it with npm. [23:32] gwoo: slicehost [23:32] atmos has joined the channel [23:32] mikeal: how are they sponsoring it? [23:33] gwoo: mikeal: probably hosting [23:33] mikeal: paying vision's salary? [23:33] gwoo: yeah right [23:33] isaacs: mikeal: they're providing hosting for the registry [23:33] mikeal: well, i work for couch.io [23:33] isaacs: mikeal: right, so npm is hosted. [23:33] mikeal: so i can provide plenty of free couchdb hosting [23:33] gwoo: mikeal: oh nice [23:33] mikeal: so npm is hosted and sponsored by 100% awesome [23:33] isaacs: cuz i got the couchdb core development team writing the registry [23:33] gwoo: im a couchdb fan [23:33] gwoo: mikeal: totally! [23:33] mikeal: js-registry is a couchapp [23:34] gwoo: i hooked up couchdb-lucene [23:34] mikeal: all of the logic is the design document and it uses the new rewriter/vhost stuff [23:34] gwoo: for a new project [23:34] gwoo: and it works great [23:34] mikeal: so you just run couchdb on port 80 and BOOM!, done [23:34] mikeal: i've heard great things about it [23:34] mikeal: i'm excited about GeoCouch tho [23:34] gwoo: oh? [23:34] mikeal: we've got vms in the office for a few weeks write a new pure relang rtree implementation [23:35] gwoo: sick [23:36] mikeal: it's pretty awesome [23:37] mikeal: apparently all rtree's are based on some paper these german dudes wrote 20 years ago [23:37] mikeal: and those 2 guys published a new paper last year that changes their base rtree idea [23:37] mikeal: and it's faster than anything anyone else has done :) [23:37] mikeal: so he's doing that [23:38] mikeal: it's his thesis :) [23:38] javajunky: fwiw I've re-written most of kiwi's client in node.js in my branch [23:38] isaacs: javajunky: it looks like tj doesn't really accept commits from anyone else, though. [23:38] javajunky: (I originally re-wrote npm back when isaacs was too busy, and at the time kiwi was more active so switched focus to that, now they're both equally active *Sob) [23:39] gwoo: mikeal: that sounds totally rad [23:39] isaacs: javajunky: i'd love some help if you want to work on a package manager. [23:39] javajunky: hmm, I've not had that issue personally [23:39] isaacs: javajunky: at least, on kiwi [23:39] isaacs: express is pretty social [23:40] javajunky: s'fair point I've not had any patches accepted on kiwi, but then I am re-writing the client so he's nothign to patch :) [23:40] mikeal: npm is actually pretty nice already [23:40] mikeal: it's already better than anything Python has [23:40] gwoo: mikeal: http://anologue.com is couchdb powered [23:40] mikeal: i'm using it locally for all these dev packages [23:41] mikeal: cool [23:41] javajunky: ;) its going to be interesting to see which package manager wins out, the decision to use bash on the client does seem strange, but given that I keep having to write my own 'mkdirs' type functions I can understand why :) [23:42] mikeal: all the fs.Sync calls made this stuff a lot simpler [23:42] mrd`: >:[ [23:43] javajunky: if anyone *is* interested, http://github.com/ciaranj/kiwi/blob/master/bin/kiwi.js is a node.js implementation of the kiwi client, it supports searching, listing and updating .. I've not tried npm since the time I fixed it all for 0.1.17 brokenness (which ironically isaacs you never pulled ), but I have been watching it (I don't care who's pm wins, I just want something as its sorely needed!) [23:43] javajunky: s'dull writing it with sync calls though [23:43] isaacs: javajunky: never got a pull req [23:44] ashb: what format are you all writing your docs in? [23:44] mikeal: javajunky: i'm using npm locally and it's plenty functional [23:44] mikeal: i most use $ npm link . [23:44] isaacs: mikeal: yeah, i use the hell outta that, too [23:44] mikeal: because i have a crap load of git checkouts of packages i want to run [23:44] mikeal: and now that the bin stuff is working I'm all over that [23:44] javajunky: isaacs: ;) iirc you did as we had a discussion on github about it ;) [23:44] isaacs: javajunky: oh, right [23:45] isaacs: javajunky: now i remember. i think you fixed a bunch of things that i'd just deleted, or re-architected, or some crap [23:45] mikeal: i think you ended up rewriting the whole thing around the time promises were removed [23:45] javajunky: I'm not fussed, it was the first node.js code I worked on , so I needed something to learn the idioms [23:45] isaacs: javajunky: sorry bout that. [23:45] mikeal: haha, and then all the idioms changed ;) [23:45] javajunky: it was back at 0.1.17 some other nasty ass changes [23:45] javajunky: meh, happens :) [23:45] isaacs: javajunky: yeah, the whole architecture is a bit more modular and whatnot now [23:45] syd_: gwoo: analogue looks really nice [23:45] isaacs: not just one giant install.js script [23:45] gwoo: thanks syd_ [23:45] mikeal: yeah, analogue looks cool [23:45] javajunky: well there were two, a bootstrap as well . [23:46] gwoo: mikeal: paste in a youtube or flickr link [23:46] gwoo: syd_: ^^ [23:46] isaacs: analogue? [23:46] tmpvar: analogue? [23:46] tmpvar: jinx [23:46] JimBastard: whaddup tmpvar [23:46] gwoo: http://anologue.com/59e1ae404d7eab6a80b15c2175395cbb [23:46] tmpvar: howdy [23:46] gwoo: tmpvar: ^^ isaacs ^^ [23:47] ashb: gwoo: what markdown are you using? [23:47] isaacs: neat! [23:47] syd_: oh wow [23:47] isaacs: javajunky: yeah, that was the stuff that moved everything from node.blerg to process.blerg, right? [23:49] ashb: gwoo: http://github.com/evilstreak/markdown-js/ [23:50] ashb: showdown has massive (general) fail [23:50] Tim_Smart: ashb: Oh really? [23:50] Tim_Smart: I'm using showdown for a userscript I'm working on atm [23:50] ashb: Tim_Smart: its basically a line-for-line, bug-for-bug port of the *horrible* perl implemetnation [23:50] Tim_Smart: I see :p [23:51] ashb: Tim_Smart: but more importantly its tightly coupled [23:51] ashb: makes it hard to tweak the output [23:51] ashb: that markdown-js has a nice intermediate represenation [23:51] javajunky has joined the channel [23:51] ashb: so you can actually store the parse tree, or add/remove/change nodes easily. and on the server :) [23:52] ashb: (the test suite is written commmonJS-ish, but the code itself should work anywhere, incuding browser or node) [23:52] javajunky: goddamit that was bad timing my ISP just took my connection for maintenance. night [23:52] mjijackson: ashb: i've been wanting to write a Node C++ wrapper for Discount for a while, but my C++ fu is lacking [23:52] mjijackson: http://www.pell.portland.or.us/~orc/Code/discount/ [23:53] mjijackson: rtomayko used it in RDiscount and it worked a treat http://github.com/rtomayko/rdiscount [23:53] ashb: mjijackson: dont see the point in binding it [23:54] mjijackson: ashb: besides the fact that you don't have to rewrite the whole thing in js? [23:54] ashb: mjijackson: its already done. [23:54] ashb: oh and done in suchn a way that you can add dialects without having to re-write everything else [23:54] JimBastard has left the channel [23:54] ashb: the main problem with markdown (in general) is that there are 700 'extensions' [23:54] ashb: http://johnmacfarlane.net/pandoc/README.html#title-blocks [23:54] ashb: such as that [23:55] mjijackson: ashb: oh, i misread you earlier [23:55] mjijackson: i thought you were saying that markdown-js was full of bugs [23:55] morgan has joined the channel [23:55] mjijackson: but you were talking about showdown [23:55] ashb: yeah [23:56] mikeal: unfortunately, markdown is full of bugs [23:56] ashb: yes it is [23:56] ashb: http://ashberlin.co.uk/blog/markdown-lists [23:56] mikeal: i love it, but it's really poorly specified [23:56] ashb: such as that [23:56] mjijackson: it's a parser based on regular expressions, whaddya expect? ;) [23:56] mikeal: this is just some JSON [23:56] ashb: 'this'? [23:56] mikeal: you aren't looking at the order of the accept headers [23:57] mikeal: and my browser has application/json in the accept headers after text/html [23:57] mikeal: so you are returning me JSON [23:57] ashb: oh. oops :) [23:57] mikeal: and then you aren't giving it the proper content-type [23:57] ashb: thats running old code - might be fixed [23:57] ashb: mikeal: but what accept headers are you sending? [23:57] mikeal: on no [23:57] mikeal: you are sending the header [23:57] ashb: (exactly, if you please) [23:57] mikeal: but you named it contentType [23:57] mjijackson: ashb: going to give markdown-js a spin. looks great [23:57] mikeal: haha [23:57] mikeal: it needs to be content-type [23:58] ashb: oh i typo'd it. its contentType isn't it? [23:58] mikeal: my accept header looks like this [23:58] mikeal: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json [23:59] ashb: mikeal: yeah i've already fixed the typo in the header name