[00:00] mde: Not for full-stack JS that doesn't involve the JVM. :) [00:00] ryah: i'm interested in node as an experiment of how we can change programming style [00:00] ryah: still unsure if it will actually work [00:00] mde: I mean, devs will have to learn how to use events and callbacks. [00:01] mde: But if something goes south in a globally scoped-callback, you can't just throw up your hands and hope the end-user dev can deal with it. [00:01] ryah: a JS platform with blocking coroutines would be super easy [00:01] ryah: well "super easy" [00:02] ryah: it would be doable [00:02] creationix: ryah: you thinking about a fork of node that slower, but much easier to use? [00:02] mde: Node is going to be way faster than anything in its class, even with queueing. [00:02] creationix: "much easier" [00:02] ryah: creationix: i think it would be similar speed [00:02] creationix: ryah: ok, so just different semantics [00:02] ryah: but my thesis is that it willb e harder to use [00:02] ryah: still unsure if that's true :) [00:03] ryah: the worst thing about node is losing your stacktraces from events [00:03] creationix: and at the same time, that's a feature [00:03] creationix: it keeps stack nice and shallow [00:03] ryah: hard to find errors though.. [00:03] blowery: coming from Spring, I would appreciate a shallow stack [00:03] ryah: i kind of think having dtrace probes is going to make this better [00:03] blowery: it's refreshing [00:04] javajunky has joined the channel [00:04] ryah: well, node is just a lot less than spring [00:04] inimino: in debug mode [00:04] mde: The queueing approach keeps things nice and simple for now, and it's still ridiculously fast compared to something like Rails or even Sinatra. [00:04] ryah: if we had a whole ORM layer, node's also have big stacks [00:04] inimino: you could always track the location of where every event was queued from [00:04] ryah: mde: not fast enough :D [00:04] blowery: ryah: it's not the ORM, it's the DI [00:04] ryah: lately i've been thinking i need to rewrite lib/net.js in c... [00:05] ryah: (again) [00:05] inimino: :) [00:05] mjr_: boo [00:05] mde: ryah: Fast enough depends on what you want to do with it. :) [00:05] inimino: ryah: will it be faster? [00:05] ryah: inimino: we're seeing too many GCs [00:05] Tim_Smart: If we start comparing node to rails, then we are in the wrong mindset [00:05] inimino: oh [00:05] blowery: heh [00:05] mikeal has joined the channel [00:05] blowery: Node.js: Rails done right! [00:05] Tim_Smart: rails is too slow to be in the node.js race [00:05] mde: For me, it's an absolute requirement to return the error with the right response. [00:05] inimino: I thought the Buffers would avoid a lot of GC pressure [00:06] blowery: ACTION hides [00:06] mjr_: faster is hard to argue with, but the current system seems pretty reasonable. [00:06] ryah: inimino: it does, it's a bit unclear [00:06] mde: Yeah, I started benchmarking Geddy against Rails, and it's just so unfair. [00:06] inimino: hrm, ok [00:06] ryah: mjr_: yeah, net.js is nice. if we solidified on these node_net.cc bindings switching out the backend with JSC would be possible [00:06] ryah: which would be rad [00:07] dgathright has joined the channel [00:07] ryah: (obviously sevearl months down the road, we're no where near ready to do that yet) [00:07] mjr_: Yeah, I guess that's my major concern. Right now it still seems like the API might change [00:07] zomgbie has joined the channel [00:07] inimino: what does JSC have over V8 these days? [00:08] ryah: inimino: powerpc [00:08] inimino: ah [00:08] ryah: (for example) [00:08] creationix: mde, actually that's not a bad compromise [00:08] creationix: you still get parallel I/O within the request [00:08] creationix: even if requests themselves aren't parallel [00:08] creationix: works as long as you don't have any long connections [00:09] mde: creationix: With workers, it seems very reasonable. Multi-core is kind of the norm now anyway. [00:10] creationix: mde: yeah, as long as your load isn't high and connections are short, that works great [00:10] creationix: but the original point of node was to get away from "the norm" and not use threads/processes per request to scale [00:10] creationix: performance is all relative [00:10] mde: creationix: It's no the ideal Node approach, but even with that it has major advantages over the status quo. [00:11] mde: Right, exactly. [00:11] ryah: okay what do you all think about this: [00:11] ryah: node --no-errors server.js [00:11] mde: If it's blazingly fast, but normal devs can't figure out how to debug, it's not that helpful. [00:11] ryah: or [00:11] inimino: it removes errors from the code? :-) [00:11] creationix: ryah: what would that do? [00:11] inimino: build it! [00:11] Tim_Smart: ryah: Does it make bad code automagically work? [00:11] ryah: enables process.addListener('uncaughtException') [00:11] ryah: and prints out stack traces [00:12] ryah: also for 'error' events [00:12] Tim_Smart: ah [00:12] ryah: so you don't have to modify your script [00:12] mde: ryah: Would that solve the problem of per-request errors? [00:12] creationix: but even with uncaughtException you still need a lock of one request at a time [00:12] inimino: mde: what's the per-request error problem? [00:12] mde: Yeah, that's the problem I have. [00:12] ryah: mde: not really [00:13] mde: Right, so you still have to queue. [00:13] creationix: now if you could somehow get access to the closure data in scope when the exception happened and pass that along... [00:13] inimino: why are you queueing? [00:13] mde: inimino: It's the fact that you can be juggling multiple requests at a time in a process. [00:13] creationix: that would be golden [00:13] ryah: inimino: responding with 500 and a stack trace when someone does createServer(function (req, res) { setTimeout(function () { [00:13] ryah: throw new Error('blah'); [00:13] mde: And one of them can throw an error in a callback, so you have no idea what request it came from. [00:14] ryah: }, 100); [00:14] ryah: }): [00:14] inimino: hm, ok [00:14] ryah: how do you catch that error in the setTimeout? [00:14] creationix: well, how does uncaughtException work in the first place [00:14] mde: Yeah, that would be ideal. You can't even walk up the arguments.callee.caller chain. [00:14] creationix: what data do you have at the c level [00:15] inimino: well... for me... you add an exception handler, and dump some diagnostic data [00:15] inimino: including the request [00:15] ryah: creationix: basically this: http://github.com/ry/node/blob/20905d9d62a115de63fe56d8128906f3ea4d5cd4/src/node_events.cc#L59-64 [00:15] mde: It's a callback, so it's just like "this happened in the global scope." [00:15] zomgbie has joined the channel [00:15] inimino: but in a --debug mode, you could record a stack trace at everything that queues a future event [00:17] inimino: so every setTimeout, every async fs or network call, generate a stack trace in V8, and then dump all of them when an exception is thrown [00:18] mde: Yeah, y'all are way smarter than I am, it'd be great if you come up with the right way to handle it. [00:18] inimino: mde: would a debug mode be good enough? [00:18] mde: I'd much rather do things the 'Nodely' way. [00:18] ryah: inimino: yeah. [00:18] ryah: or you just die [00:18] mde: inimino: The problem is having a reference to the actual request/response pair that caused the error. [00:18] ryah: browser js <-- most successful platform ever [00:18] mde: So you can do the right thing for the dev or end-user. [00:19] ryah: error handling? none. [00:19] mde: Yeah, it's true. :) [00:19] inimino: yes [00:19] ryah: i think the proper solution for mde is to use two process in debug mode [00:19] ryah: the master proxies requests to the later [00:20] ryah: if the slave dies, it records the stacktrace and prints it to the user [00:20] ryah: maybe we can codify that in someway so it's not so hard.. [00:20] ryah: like with workers.. [00:20] mde: That sounds like it would work, yeah. [00:21] mde: Well, I'm using workers now. [00:21] mde: And during app-startup it does just what you described. [00:22] ryah: in production mode you pre-fork, when a worker dies you restart it [00:22] creationix: I could easily add a middleware to connect that puts a global lock on requests to queue them [00:22] ryah: but all the connections associated with that worker die too [00:22] creationix: but the queue would grow too fast I think [00:22] mde: Even in production mode, you need info about what in the request caused the error though. [00:23] ryah: mde: print it to stdout [00:23] ryah: mde: kill the process [00:23] mde: creationix: That's exactly what Geddy is doing. [00:23] creationix: mde: yeah, that's where I got the idea [00:23] ryah: queueing is only okay for debug mode [00:24] creationix: could we add a flag to the socket in node that only accepts one connection at a time [00:24] mde: I guess you could use some kind of watcher process to close out dead requests. [00:24] creationix: and doesn't accept another till it's closed the first [00:25] mde: I'm sure it can be optimized, but right now I just want something simple that normal devs can use. [00:25] mde: And it's already so much faster. :) [00:25] tjholowaychuk has joined the channel [00:26] Tekerson has joined the channel [00:30] rauchg has joined the channel [00:33] technoweenie: hey has anyone had any issues w/ downloading binary data from node apps? sometimes i get 'Received problem 3 in the chunky parser' from curl [00:34] Tim_Smart: technoweenie: Nope :/ [00:34] shajith has joined the channel [00:34] Tim_Smart: technoweenie: I serve everything on http://fostle.com/ with node [00:34] technoweenie: that error message makes it sound like something im doing or node is doing is not rfc compliant (or curl is picky) [00:36] ryah: technoweenie: hm [00:36] ryah: technoweenie: maybe you can tcpdump that? [00:36] ryah: let's have a look at the headers [00:37] creationix has joined the channel [00:37] JimBastard: ive had some problems transferring lots of little files over and over again in node. we saw files slowly increasing in steady but strange numbers getting appended onto each other. still trying to debug, its been going on for a week or so [00:37] technoweenie: ok i'll see if i can find a smaller sample. it works great if i download a tiny git repo, but not rails [00:37] technoweenie: the rails archive is about 400k [00:38] ryah: hm [00:38] technoweenie: oh nodes is bigger, ha [00:39] ryah: :) [00:39] ryah: it's v8 that makes node's so large [00:40] Tim_Smart: rails doesn't have to carry around the ruby vm [00:42] jedschmidt has joined the channel [00:42] technoweenie: ok streaming from a file readstream seems fine. its not streaming properly from a child process to the web response. [00:46] ryah: technoweenie: :/ [00:46] technoweenie: its writing it to the filesystem jsut fine though. a second request works [00:46] tmpvar has joined the channel [00:46] technoweenie: ok i just installed tcpdump, i'm trying to figure out how to use it [00:46] ncb000gt has joined the channel [00:50] ryah: technoweenie: sudo tcpdump -s 0 -X -i lo0 dst tcp port 80 [00:51] ryah: (well depending on where things are being sent) [00:52] BrianTheCoder has joined the channel [00:52] technoweenie: it says syntax error. well let me get a sample that runs locally. [00:53] ryah: maybe take out 'dst' [00:58] CIA-76: node: 03Mikeal Rogers 07master * rf62979d 10/ (3 files in 3 dirs): Add sys.pump - http://bit.ly/aEOet2 [01:01] Tim_Smart: ^ Hah, funny that. I just did http://github.com/biggie/biggie-router/commit/97755f25fba353a9708d6de365779900b6d2411f [01:01] ryah: it's been sitting in my queue for like 3 weeks [01:01] ryah: i think there's something wrong with it [01:01] ryah: but - well there's something wrong with everything :) [01:02] LOLWUT__: hehehe [01:02] sechrist: what's the fastest way to copy an object? It's not eval(JSON.stringify(object)) is it? [01:02] mikeal has joined the channel [01:03] sechrist: technoweenie: ngrep is the bomb [01:03] sechrist: but I admit I don't know what you're doing [01:03] sechrist: that's pretty much a tcp dump into grep [01:04] ryah: someone should write an http version of wireshark [01:04] ryah: oh [01:04] ryah: node knockout idea :D [01:04] LOLWUT__: I definitely approve of this. [01:04] Tim_Smart: Someone should serve pancakes with node [01:04] LOLWUT__: this also. [01:05] visnup: I want belgian waffles [01:05] technoweenie: i wonder if i should add pausing to the child process [01:05] LOLWUT__: I'm actually considering using nodejs for doing web app testing at work [01:05] inimino: sechrist: no, just write a recursive loop [01:05] gerad: node_pcap [01:05] technoweenie: is there a way to tell if a stream is paused [01:06] ryah: technoweenie: hm, i don't think so [01:06] gerad: http://github.com/mranney/node_pcap [01:06] sechrist: inimino: that's faster? why is there no v8 object copy [01:06] sechrist: rawr [01:06] technoweenie: one of the challenges is i'm writing to 2 streams. i wonder if it'd be more reliable to stream to the hard drive and then stream to the web request [01:07] JimBastard: ACTION says, just don't cross them. [01:07] steadicat has joined the channel [01:07] inimino: sechrist: it better be faster, because it's doing strictly less work [01:07] sechrist: ryah: are recursive loops the fastest way to copy an object? [01:07] gerad: courtesy of mjr_ [01:07] inimino: (and iterating object properties is one of the fastest things you can do in V8) [01:08] sechrist: for x in blah is really that fast? [01:08] inimino: if you want to be sure you'll probably have to benchmark it [01:08] sechrist: well yeah and I have to agree that has to be faster than parsing text [01:09] inimino: right [01:09] sechrist: process.copy plz [01:10] inimino: you could write it in C but I really doubt it'd be enough faster to matter [01:10] sechrist: or sys really [01:10] mikeal has joined the channel [01:10] sechrist: hehe yeah [01:10] ryah: sechrist: yeah i guess there's no good way to do this [01:10] ryah: sechrist: Object.clone should be joining us soon [01:10] sechrist: yay [01:10] sechrist: it's a pretty useful activity [01:11] inimino: Object.clone? [01:11] Tim_Smart: Object.clone +1 [01:12] Tim_Smart: inimino: It's in the ECMA5 spec I think [01:12] inimino: I haven't seen it [01:12] mikeal: ryah: i looked at adding the close event to http [01:12] mikeal: and it's hard :) [01:12] ryah: mikeal: hm really? [01:12] mikeal: ServerResponse specifically [01:12] mikeal: there isn't an obvious place to wedge and event where the write finally flushes [01:13] rauchg has joined the channel [01:13] ryah: why does it need the 'close' event again? [01:13] mikeal: i thought you could do it in send [01:13] mikeal: for pump [01:13] mikeal: so the callback fires when the writes flush [01:16] cloudhead has joined the channel [01:20] _announcer: Twitter: "Anyone running Hummingbird http://mnutt.github.com/hummingbird/ on @heroku? Think I might give it a crack. #nodejs" -- Xavier Shay. http://twitter.com/xshay/status/16813264904 [01:21] ryah: mikeal: looking into it [01:23] mikeal: the issue was that there are some raw connection writes and then some writes that go through send [01:23] mikeal: so you can't just stick code in send to handle it [01:23] mikeal: you'll either need to wrap write more code in every place that does a write, or wrap the connection.write method [01:23] ryah: yeah [01:23] shahbaz has joined the channel [01:23] ryah: seems a bit painful [01:24] mikeal: i can't type today [01:25] falconair: hi, are there any plans to provide an ubuntu package for node.js? it is much easier to do "apt-get install node" than to manually install it [01:25] ryah: falconair: there is already a debian package [01:26] ryah: i think you can probably just install that [01:26] ditesh|cassini has joined the channel [01:26] ryah: falconair: http://packages.debian.org/sid/nodejs [01:28] falconair: hm...doesn't show up in Synaptic Package Manager [01:29] sechrist: halorgium: you there? [01:29] halorgium: sechrist: ja [01:29] sechrist: what's your license on buftok.js, can I use it freely? [01:29] halorgium: it was stolen from eventmachine [01:29] halorgium: and ported [01:29] halorgium: so i dunno [01:29] sechrist: hm [01:29] Tim_Smart: Pumping a file stream into a gzip stream into a response stream. Just epic [01:30] sechrist: well it has a good place in websockets [01:30] ryah: licensing *headache* [01:30] sechrist: ryah: yarly [01:30] ryah: ^-- what i have [01:30] technoweenie: i'm pumping a git archive stream, to gzip, and then to the filesystem + a response stream simultaneously [01:30] technoweenie: well, i was. i'm going to try doing them separate. i suspect the response stream isnt keeping up [01:31] sechrist: I normally don't care about licenses -- but since I'm pushing to github now and because of all of that mess with JimBastard I feel required to care [01:31] JimBastard: yo sechrist [01:31] sechrist: yo [01:31] JimBastard: i keep it real [01:31] JimBastard: http://github.com/Marak/asciimo/commits/master [01:31] JimBastard: i put down the big money to get scott g to write a figlet parser [01:32] JimBastard: hes the lead dev on jquery ui [01:32] sechrist: the big monies [01:32] JimBastard: fuck those haters [01:32] JimBastard: ACTION is unstoppable [01:32] sechrist: ACTION lulz [01:32] JimBastard: fuck that dude [01:32] Tim_Smart: Until you get hit by a train [01:32] Tim_Smart: You are unstoppable [01:32] JimBastard: Tim_Smart: i try to not leave apartment jail for that exact reason [01:32] JimBastard: ahahaha [01:33] JimBastard: its really funny though [01:33] technoweenie: you could've just been more polite and there wouldnt have been any issues [01:33] JimBastard: well [01:33] sechrist: speaking of futurama JimBastard, two episodes of the new season leaked [01:33] sechrist: I should go watch them [01:33] JimBastard: it turns out patorjk had managed the FIGlet font format for god knows what reason [01:33] JimBastard: all his fonts were not to the figlet spec [01:34] sechrist: managed or mangled? [01:34] JimBastard: lol [01:34] JimBastard: mangled [01:34] JimBastard: anyway, it turns out there is a way more comprehensive / free database [01:34] JimBastard: http://www.figlet.org/figlet-man.html [01:34] sechrist: JimBastard: http://patorjk.com/images/blog-2010/wow-guy.png [01:34] JimBastard: so i just deleted all the code [01:34] sechrist: HOLY CRAP LIMECHAT EMBEDS IMAGES [01:35] JimBastard: well, his code [01:35] JimBastard: i kept all my awesome jquery code [01:35] JimBastard: reading that code makes you ninja for real [01:35] JimBastard: UI win [01:35] visnup: I've been stalled on a design for a client website; figlet has just inspired me [01:35] JimBastard: so there is a new repo now [01:35] JimBastard: all the code in the new repo is 100% legal and open source [01:35] JimBastard: protected by MIT and some GPL [01:35] JimBastard: well both [01:36] JimBastard: so lulz to that [01:36] JimBastard: scott g owned that shit [01:36] sechrist: MIT has armed guards outside the repo? [01:36] JimBastard: he turned 1300 lines of patorjk garbage into 80 lines of awesomeness [01:36] blowery: no no, MIT has cake [01:36] JimBastard: you hear that [01:36] sechrist: thriteen...hundred? [01:36] JimBastard: go to his site [01:36] JimBastard: read his code [01:36] sechrist: holy shshshshit [01:36] JimBastard: then read our new code [01:37] JimBastard: thats just the parser [01:37] sechrist: ACTION facepalm [01:37] JimBastard: i gotta go finish this, just be easy and dont go causing internet drama please [01:38] sechrist: "If you have a Jailbroken iPhone 3GS with the OLD BOOTROM and you DID NOT use Spirit to jailbreak then you can create the ipsw with PwnageTool 4.0 and restore with your jailbroken recovery mode. " bah [01:39] sechrist: screw you userland jailbreak [01:39] JimBastard: nice visnup [01:46] ncb000gt: JimBastard: i'm positive that someone has already thought up refactoring code...you...you....BASTARD! [01:46] JimBastard: >>><<< [01:47] JimBastard: its like soo fubar [01:47] JimBastard: caus im always the guy that is like [01:47] JimBastard: YO we gotta pay for that software [01:47] JimBastard: this is good shit [01:47] SamuraiJack has joined the channel [01:47] JimBastard: if someone releases like a little one off tool [01:47] JimBastard: at least back in the day [01:47] JimBastard: everything good seems OSS these days [01:48] ncb000gt: well, see, you've inspider me....I've come up with something called asciimore! there was this awesome code on github...some jquery in there too [01:48] ncb000gt: ... [01:48] JimBastard: ahahaha doo ittt [01:48] ncb000gt: >=D [01:48] JimBastard: +10 if you buy the domain [01:48] JimBastard: ill link to you [01:48] ncb000gt: haha [01:48] JimBastard: check out the new repo [01:48] JimBastard: its 10x better [01:48] JimBastard: http://github.com/marak/asciimo/ [01:49] JimBastard: well, mathematically speaking that is....about the figlet parser [01:51] sechrist: brew install axel [01:51] sechrist: awesomesoft [01:51] technoweenie: fuck you chunky parser [01:51] sechrist: technoweenie: which one [01:53] grahamalot has joined the channel [01:54] jsilver has joined the channel [01:54] _announcer: Twitter: "pdf.js - PDF generation from the browser (or node.js): http://is.gd/cZNKC" -- Coder I/O. http://twitter.com/coderIO/status/16815416197 [01:55] Tim_Smart: cloudhead: I'll try using an EventEmitter now. [01:55] ncb000gt: JimBastard: nice. [01:56] JimBastard: im working on wrapping it up all nicely in a dual-sided library [01:56] JimBastard: you know how i roll [01:56] JimBastard: you include asciimo.js your page as a script or in node.js as a commonjs. same file. all magic. [01:58] tjholowaychuk has joined the channel [01:58] WALoeIII has joined the channel [02:01] visnup has joined the channel [02:02] kurisu has joined the channel [02:07] gf3 has joined the channel [02:07] pavelz has joined the channel [02:08] WALoeIII has joined the channel [02:13] technoweenie: ryah: good news, if i wait to stream the file after `git archive` is done, it seems to work great [02:15] technoweenie: i might need to just pause the git archive stdout if the web response.write() returns false [02:16] ryah: yes, you probably should do that [02:16] ryah: but it doesn't seem like htat would give you the chunked error [02:17] ryah: it would only drive up your memory [02:18] technoweenie: hmm, ok. well i'll play around with it some more. [02:20] jsilver has joined the channel [02:27] derferman has joined the channel [02:27] pnewhook has joined the channel [02:29] jsilver has joined the channel [02:29] jsilver has joined the channel [02:33] CIA-76: node: 03Ryan Dahl 07master * rfc175a0 10/ (src/node.cc lib/mjsunit.js): Remove mjsunit from repo - http://bit.ly/apEnoT [02:37] CIA-76: node: 03Ryan Dahl 07master * rf541043 10/ (src/node.cc lib/ini.js test/simple/test-ini.js): Remove ini.js - http://bit.ly/bpnLix [02:41] micheil: ryah: probably ping isaacs and make sure he knows about that last commit [02:41] micheil: currently npm uses ini.js or something [02:42] tjholowaychuk: ACTION works on haml killer [02:43] Tim_Smart: Poor haml. [02:46] teemow has joined the channel [02:49] isaacs has joined the channel [02:50] ryah: oops [02:50] ryah: really? [02:51] ryah: oh, he's got it in there [02:52] cloudhead: Tim_Smart: how's that working out for you? [02:53] Tim_Smart: Good thanks. Starting to add tests for http://github.com/biggie/biggie-router now [02:54] cloudhead: Tim_Smart: I think I'm going to look into making `this.callback` more flexible [02:54] Tim_Smart: cloudhead: Good idea :p [02:54] cloudhead: so it can be used like in your gist [02:54] Tim_Smart: Maybe force it to be used like: this.callback() [02:55] jakehow has joined the channel [02:55] Tim_Smart: so you can register it as a non-returning test [02:55] Tim_Smart: or make callback a getter [02:55] cloudhead: Tim_Smart: it is a getter [02:55] Tim_Smart: oic [02:55] cloudhead: Tim_Smart: the problem is you called it from inside a function [02:55] cloudhead: so when the topic returned, it wasn't called yet [02:56] cloudhead: so it didn't know whether to expect it to be called or not [02:56] Tim_Smart: Ah [02:56] cloudhead: yea [02:57] cloudhead: So what I might have to do is if you return undefined, it expects it to be called [02:57] cloudhead: and then it doesn't need to be a getter [02:58] cloudhead: it's sort of an edge case anyway [02:58] _announcer: Twitter: "Thank you or somebody Node.js CommonJS # shibuyajs like to hear about it" [ja] -- nazoking. http://twitter.com/nazoking/status/16819392309 [02:59] BrianTheCoder has joined the channel [02:59] Tim_Smart: cloudhead: Not so much a case in async testing [02:59] Tim_Smart: *edge case [03:03] MarkHansen has joined the channel [03:04] cloudhead: Tim_Smart: no I mean wanting to return undefined explicitly [03:04] cloudhead: like, function () { return undefined } [03:04] Tim_Smart: Ah yes I defiantly agree there [03:04] cloudhead: I wouldn't be able to distinguish [03:05] cloudhead: but you can always do `topic: undefined` ie without the function [03:05] cloudhead: and that should still work [03:05] piratepenguin has joined the channel [03:08] piratepenguin: so node.js is, basically, server-side javascript, which is pretty damn neat (i've been looking for this for a while). I'm about to embark on creating some prototype webapps, the possibility of using just the one language is intriguing :) [03:08] tjholowaychuk: :D [03:08] MarkHansen: :D [03:08] tjholowaychuk: it is nice [03:08] mde: piratepenguin: It is nice being able to share code back and forth between client and server. [03:09] Tim_Smart: Hmm a spider just hid in my keyboard [03:10] MarkHansen: o_O [03:11] piratepenguin: mde: indeed. By share do you mean, copy and paste type sharing? Or how about the idea of (if the app developer allows), being able to 'transfer' serverside code to run locally - has this been thought of? [03:12] mde: piratepenguin: Not copy-paste, but doing it in a systematic way. [03:12] mde: So, two good examples are templating, and model/input-validation code. [03:13] _announcer: Twitter: "@donohoe what are the best resources to learn css3 transforms and animations? Btw, you should have a look at Node.js and @expressjs" -- Xavier Damman. http://twitter.com/xdamman/status/16820323613 [03:13] mde: I'm working on a web framework that does a lot of that kind of code-sharing. [03:14] mde: The model code for the framework runs in all the major browsers, plus Node, plus TheRubyRacer, which is V8 embedded in Ruby: http://github.com/mde/geddy/tree/master/geddy-model/ [03:16] piratepenguin: sounds very cool mde. Gotta start exploring this stuff! [03:16] mde: It's a nice change from having to code everything twice. [03:17] LOLWUT__: piratepenguin, I've just been getting started too [03:17] LOLWUT__: I'm about a week in or so [03:17] LOLWUT__: :) [03:17] piratepenguin: cool :) [03:17] tjholowaychuk: mde: I dont mind the idea of sharing that stuff, infact it would be great. but that puts some limitations on what you can do within the orm realm [03:17] LOLWUT__: it's giving me a reason to learn more than just DOM programming and jquery, tbh :P [03:17] tjholowaychuk: unless most of your code is client side friendly as well [03:17] LOLWUT__: and the scalability is crucial imo [03:18] tjholowaychuk: in which case it would be nicer to have a build i guess, so you dont slow down node lots with extra crap [03:18] piratepenguin: tjholowaychuk: It would I suppose require running a local node.js server, probably easily installed as a browser extension [03:18] mde: tjholowaychuk: The sharing back and forth does force you to avoid Node-specific code, yes. [03:18] tmpvar: or atleast abstract away from it [03:18] tjholowaychuk: mde: in the future that wont be such a big hurdle. will be nice [03:19] mde: But if you've done a lot of X-browser, it's no worse, treating Node as yet another platform. [03:19] tjholowaychuk: for sure [03:19] mde: The biggest hurldle with ORM is SQL vs. NoSQL, so far. :) [03:20] mde: Developers should mostly not have to care which they use. [03:20] marshall_law: has anyone built TheRubyRacer as a module for node? (embed ruby into node?) ;) [03:20] LOLWUT__: I know no such magicks [03:21] tjholowaychuk: mde: yeah ideally not. DM was great for that you could use yaml and you wouldnt even really know its something else [03:21] mde: marshall_law: So, embedding V8 in Ruby in Node? :) [03:21] marshall_law: i'd like to port our kroll binding layer to node, that would be a fun project [03:22] tjholowaychuk: mde: recursive embedding! haha [03:22] mde: tjholowaychuk: Exactly. geddy-model is just a JS port of DM. It's a nice, simple API. [03:22] sechrist has joined the channel [03:22] marshall_law: mde: they already do the data marshalling part between v8 and ruby, so it'd just be a matter of controlling it from node rather than a ruby interpreter :) [03:22] mde: Heheh, exactly. [03:22] mde: marshall_law: Sounds like a nice Science Fair project. :) [03:22] jxson has joined the channel [03:22] marshall_law: hehe [03:23] marshall_law: mde: kroll (the microkernel we wrote for titanium) does dynamic data marshalling [03:23] marshall_law: it can marshall between JS , Ruby, Python, PHP [03:23] marshall_law: any and all [03:23] mde: tjholowaychuk: I think it's going to be possible with Couch to generate views on the fly and cache them to approximate most of the stuff you can do with an ORM. [03:23] marshall_law: right now it's built against JavaScriptCore though [03:23] marshall_law: porting to v8 wouldn't be terribly difficult i don't think [03:23] mde: marshall_law: That sounds pretty interesting. I know there's going to be a lot of mixing and matching going on. [03:24] piratepenguin: are there any big web apps being made with node or is there more work to be done before that happens? it looks like there's been a surprising lot of interest [03:24] mde: I met with some engineers from Twitter who are trying to do JS-in-Ruby stuff. [03:24] marshall_law: mde: :) [03:24] mde: piratepenguin: We're still building the frameworks, I think. :) [03:25] LOLWUT__: seems to me one could build their own rudimentary framework [03:25] LOLWUT__: with minimal effort [03:25] mde: Yeah, that's what I thought too. :) [03:25] piratepenguin: I suppose thats the more important thing right now. Looks like a good effort is being made! [03:25] LOLWUT__: the http stuff is pretty straightforward [03:25] mde: It's easy to get sucked in. [03:25] LOLWUT__: what I've been contemplating [03:26] LOLWUT__: and I'm not exactly sure how it'd be done in javascript/node [03:26] LOLWUT__: but taking video files [03:26] LOLWUT__: and packing them in a nodejs buffer [03:26] LOLWUT__: to play as bitstreams to clients [03:27] marshall_law: LOLWUT_: definitely possible, binary data in node is pretty straightforward [03:27] marshall_law: the streaming / async APIs make it really simple to do binary streaming as well [03:27] LOLWUT__: yeah, I just don't know how I'd read the file in as binary data in js [03:27] marshall_law: LOLWUT_: node also has file APIs :) [03:27] LOLWUT__: I'm a HUGE streaming video guy [03:27] LOLWUT__: never gone as far as actually writing the streaming server [03:27] LOLWUT__: but I've implemented my own solutions before [03:27] LOLWUT__: and it's really fun [03:28] marshall_law: LOLWUT_: take a look at the docs, specifically the Buffer type.. you probably don't want to do much binary manipulation if you can avoid it though.. just pass it on through ;) [03:28] LOLWUT__: how would one go about packing the file as binary data? [03:28] ajpiano has joined the channel [03:28] LOLWUT__: like in straight js, not necessarily nodejs [03:28] marshall_law: the problem is javascript has UTF-16 encoding in it's strings, so getting at / manipulating bytes is expensive in JS unfortunately [03:28] mjr_: node has a Buffer class that makes this easy, but isn't "straight" js. [03:28] technoweenie: if you're streaming files, look at file.readstream and file.writestream [03:29] piratepenguin: LOLWUT_: interesting. I'm interested in spending this summer becoming a video codec guy :) and I'd like for that to involve creating webapps to demonstrate effective/ineffective compression techniques etc [03:29] LOLWUT__: well I'd basically be adopting the Whatever Works (tm) strategy [03:29] tjholowaychuk: and the new pump method :D [03:29] LOLWUT__: piratepenguin, I'm actually developing a few custom video solutions atm [03:29] LOLWUT__: trying to break away from livestream [03:30] LOLWUT__: but bw is taxing and traditionally scaling streaming video is expensive [03:30] ryah: LOLWUT__: you can encode arbitrary binary data in a string [03:30] ryah: but it's not fast [03:30] ryah: "encode" [03:30] LOLWUT__: ryah: basically I'm thinking the server would take it's sweet time [03:30] LOLWUT__: packing binary data into a buffer [03:30] LOLWUT__: when a client connects [03:30] LOLWUT__: or say, views the