[00:00] isaacs: i also support "main" to specify the primary entry point for the package.
[00:00] tlrobinson: isaacs: hm we need to figure out how to make sure our catalogs are compatible
[00:00] isaacs: where require("foo") will be like requiring foo's "main" module
[00:00] isaacs: tlrobinson: i'd suggest that tusk read from npm's catalog ;)
[00:00] isaacs: maybe even mirror it
[00:01] jed: what a lark: http://middlehere.com
[00:01] tlrobinson: tusk will support it if it complies with commonjs' packages :)
[00:02] isaacs: tlrobinson: http://github.com/isaacs/npm/blob/master/doc/registry.md
[00:02] hassox: what's tusk?
[00:02] tlrobinson: narwhal's package manager
[00:02] isaacs: so, this is sort of orthogonal to the commonjs packages spec.
[00:02] tlrobinson: isaacs: hm then perhaps it's under specified
[00:02] isaacs: it's a way to manage different versions of packages, not packages themselves.
[00:03] isaacs: it's essentially a very simple key/value store where users can create packages, bump versions, etc.
[00:03] isaacs: but /foo/v1.0.2 is just a redirection to some tarball.
[00:04] tlrobinson: oh, i don't care about how you manage the packages in the catalog/registry/whatever
[00:04] hassox: tlrobinson: does narwal run on rhino?
[00:04] tlrobinson: hassox: rhino, javascriptcore, xulrunner, sorta v8
[00:04] tlrobinson: hopefully node soonish ;)
[00:05] hassox: isaacs: rather than a pointer, it could stream the tarball
[00:06] isaacs: hassox: no. that would not be ideal.
[00:06] isaacs: it'd just double the network throughput
[00:06] isaacs: (well, double it overall, but much *more* than double it for the registry server)
[00:06] isaacs: as it stands, this thing can run with almost no overhead.
[00:07] isaacs: of course, depending on hwo the database works
[00:14] hassox: tru
[00:30] Jed has joined the channel
[00:31] technoweenie has joined the channel
[00:34] Jed has joined the channel
[00:37] tlrobinson__ has joined the channel
[00:45] Jed has joined the channel
[00:54] r11t has joined the channel
[00:55] sudoer has joined the channel
[01:07] Tim_Smart: Does anyone here know much about C++ libev and working with threads?
[01:13] jubos has joined the channel
[01:20] isaacs has joined the channel
[01:24] Jed has joined the channel
[01:32] technoweenie: hey jed, what do you think about making this.url.query default to {} ? it seems like its nil if the url has no ?params
[01:34] Jed: technoweenie: well, i'm just passing the object from node.js... perhaps it should be changed there?
[01:34] technoweenie: yea thats true
[01:35] Jed: but we can definitely make it easier in middleware for sure.
[01:36] Jed: ( fab )( parseQueryString )( ...
[01:38] RayMorgan has joined the channel
[01:40] achew22: can jslint be run in node?
[01:42] Jed has joined the channel
[01:53] technoweenie: i think i want these fab callbacks to return soemthing other then that respond function
[01:55] Jed: technoweenie: like what?
[01:56] technoweenie: well the problem is the callbacks change 'this', so i ahve to do "fab=this" so i can access this.url inside the callback
[01:56] Jed: (btw, i wonder if it would make sense to set up a fab channel to keep the noise down here...))
[01:56] technoweenie: heh
[01:56] technoweenie: https://gist.github.com/bc4c08a6e828eb752ace
[01:57] technoweenie: yea that might not be that big of a deal. i'm still figuring out how to write javascript
[02:14] _Ray_ has left the channel
[02:17] isaacs: technoweenie: what's this about url.query?
[02:17] isaacs: it should be missing if there's no ?params.
[02:17] isaacs: javascript doesn't have a nil ;P
[02:20] technoweenie: right i dont want it to be missing
[02:21] technoweenie: and null == nil?
[02:23] hassox: technoweenie: yeah but 0 is also falsey and so is ""
[02:23] technoweenie: i want url.query to be {} when its empty
[02:23] hassox: url.query = url.query || {}
[02:23] hassox: ?
[02:23] technoweenie: yes
[02:24] technoweenie: theres a lot of dumb boiler plate in writing js apps
[02:24] hassox: technoweenie: you can write getters and setters that do that for you
[02:30] technoweenie: http://github.com/technoweenie/wheres-waldo/compare/master...fab
[02:31] hassox: what does it do mat?
[02:31] hassox: mate
[02:32] technoweenie: see the readme: http://github.com/technoweenie/wheres-waldo
[02:32] technoweenie: it tracks what page users of your system are on
[02:32] hassox: oh nice :D
[02:32] hassox: that's cool
[02:33] chewbranca has joined the channel
[02:35] technoweenie: yea that compare url shows the move to fab
[02:51] mikeal has joined the channel
[02:53] mikeal1 has joined the channel
[03:01] Jed has joined the channel
[03:12] unomi has joined the channel
[03:13] JoePeck has joined the channel
[03:14] FoxFurry has joined the channel
[03:18] jed has joined the channel
[03:21] isaacs: technoweenie: the problem with having url.query be {} when it's missing is that it's unclear whether you requested /foo? or /foo
[03:22] technoweenie: whats the difference?
[03:22] isaacs: the question mark
[03:22] technoweenie: is there ever a case where you care?
[03:23] isaacs: well, not me, no. but at that low level, it's good to not make assumptions.
[03:23] isaacs: of course, url.href is going to have the original proper request anyhow
[03:23] technoweenie: it just makes it easier to work with
[03:23] isaacs: sure
[03:23] technoweenie: if(url.query.foo) vs if(url.query && url.query.foo)
[03:23] technoweenie: i guess at that point you're already pushing the demeter law
[03:23] isaacs: imo, the fact that undefined toStrings as "undefined" is retarded.
[03:24] isaacs: but url.parse could attach a __proto__ that defaults everything to "", and that'd be pretty cheap.
[03:24] isaacs: but the thing is, sometimes you want to say if ("query" in url) or if (url.hasOwnProperty("query"))
[03:25] isaacs: the way it is now, "missing" == "not there at all"
[03:25] chewbranca has joined the channel
[03:25] technoweenie: sure
[03:25] mikeal has joined the channel
[03:28] Tim_Smart: isaacs: You can use the === comparison?
[03:28] deanlandolt: isaacs: re: undefined toStrings to "undefined" is insane...but we can't fix that :-/
[03:28] isaacs: deanlandolt: true that
[03:28] isaacs: Tim_Smart: true
[03:29] jed: question: is it too magical to pass different params to a function based on its .length?
[03:29] isaacs: Jed: nah. it's magical enough for (fab)
[03:29] loktar has joined the channel
[03:29] isaacs: beware that function.length isn't a guarantee of how many args the function cares about.
[03:30] jed: ha ha, okay. so if your handler has one param, it's respond, but two params, it's request, respond
[03:30] deanlandolt: isaacs: when is it important to disambiguate between /foo? and /foo
[03:31] Tim_Smart: technoweenie: What are those function calls that have no 'name'?
[03:31] isaacs: deanlandolt: i'm not sure, but i want the url lib to be able to behave predictably in both directions, so that if anyone ever does care, it's clear how to tell that.
[03:31] Tim_Smart: was looking at your gist before
[03:31] jed: technoweenie: ^^ should solve your fab = this closure issues.
[03:31] technoweenie: ah, so request is 'this' ?
[03:31] deanlandolt: isaacs: a useful goal for a url lib no doubt
[03:32] deanlandolt: still, trailing slashes are one thing, but to my knowledge there's nothing relevant about the ?...so by some measure "predictable" could be if a url ends in ? it's like it wasn't there at all
[03:32] isaacs: but, i guess, i mean, if its __proto__ had all the keys set to "", then you could still use hasOwnProperty to detect has-ness
[03:32] isaacs: deanlandolt: also, ther'es url.href, which is the original url that was parsed.
[03:33] jed: technoweenie: right now, yeah. it's just url, method, and headers.
[03:33] jed: i've tried to avoid naming things wherever possible.
[03:33] isaacs: but i'd have to tweak url.format to not put a ? there if search is a "", unless it hasOwnProperty and it's a "", and that gets hairier than i'd like.
[03:34] technoweenie: jed: thanks, that should help
[03:35] deanlandolt: why can't someone fall back on url.href where necessary and use the url lib to give them a more canonical url?
[03:35] jed: technoweenie: i'll take a look, not sure if it's possible... if it means i have to propagate the function length, it might not be easy.
[03:35] deanlandolt: perhaps it's unwise to just invent "canonical" when talking about the querystring...there's more to it i suppose
[03:36] deanlandolt: isaacs: what kinds of stuff is your urllib doing?
[03:36] kriszyp has joined the channel
[03:36] isaacs: deanlandolt: it just parses it like the browser does.
[03:37] isaacs: ie, like window.location
[03:37] deanlandolt: oh...well then...just parse it like the browser does then
[03:37] isaacs: that's what i do :)
[03:37] deanlandolt: is that consistent?
[03:37] isaacs: window.location.search is missing if there's no ?
[03:37] deanlandolt: thought it was undefined...checking now
[03:37] isaacs: oh, actually, it's missing, but still shows as "" in firefox.
[03:37] isaacs: grr...
[03:37] deanlandolt: ha!
[03:38] isaacs: alright, i'm convinced.
[03:38] deanlandolt: i love user-agents...they never cease to surprise me :)
[03:38] isaacs: hehe
[03:38] technoweenie: wait it's a string? in fab its a hash
[03:38] isaacs: they're like a party every day.
[03:38] isaacs: technoweenie: i'm talking about window.location.search
[03:38] technoweenie: oh
[03:39] isaacs: ok, this is wonky... it's "" when the search is "?", but "?asdf" when it's "?asdf"
[03:39] deanlandolt: actually not /that/ wonky (in that it's kinda what i was talking about -- which probably /makes/ it wonky)
[03:40] deanlandolt: if a url ends in ? it's like it was never there
[03:40] deanlandolt: IIRC there's something in 2616 that says that in no uncertain terms so that caches don't treat /? and / any differently
[03:42] jed: technoweenie: i'm using url.parse( str, true ), which parses the string into a hash.
[03:42] jed: technoweenie: i'll probably make this false and have it done in middleware eventually.
[03:44] technoweenie: ah ok
[03:47] hassox: I hate my timezone
[03:47] hassox: all the fun things happen while I'm at work!'
[03:49] bpot has joined the channel
[03:49] Tim_Smart: hassox: :p
[03:50] jed: hassox: i'll be one hour off from you by wednesday, see ya then!
[03:50] hassox: Jed: oh sweet... where you going?
[03:50] jed: hassox: TYO.
[03:50] hassox: nice
[03:50] hassox: how long will you be there for?
[03:50] jed: until just before jsconf!
[03:51] hassox: which is...
[03:51] hassox: how far away
[03:51] jed: 4/16
[03:51] hassox: nice
[03:56] Tim_Smart: anyone here competent in developing node add-ons?
[03:56] Tim_Smart: with C / C++?
[04:05] eck has joined the channel
[04:06] eck: this isn't really specific to node, but does anyone know what the plans are for v8 to support js 1.6+ (if any)?
[04:10] Tim_Smart: google should have a roadmap somewhere for v8...
[04:12] eck: the google code page isn't very useful, it doesn't give a lot of visibility into the project
[04:19] loktar: if anyones interested check out my game (with node of course) few quirks, need to add respawn, obstacles, and a controllable objective, but its getting there :)
[04:19] loktar:
[04:20] loktar: although with Chrome, it increases its cache by a ton,
[04:21] Tim_Smart: firefox lagged when I opened it, so I'm opening chrome p
[04:22] loktar: ah ok
[04:22] loktar: woah
[04:22] loktar: lol a bug I see
[04:22] mrd`: loktar: Nice.
[04:22] loktar: ty
[04:22] mrd`: loktar: What are the graphics? Canvas?
[04:22] loktar: yeah
[04:22] loktar: its all JS
[04:22] jed: technoweenie: okay, i've updated it. handlers with one arg will get respond, all others will get request, respond.
[04:22] loktar: well except the sound
[04:22] mrd`: Nice.
[04:22] mrd`: No sound for me. :/
[04:23] mrd`: Oh, only when *I* shoot.
[04:23] loktar: yeah
[04:23] loktar: I need to add when others shoot
[04:23] loktar: and pan it depending on position from you
[04:23] loktar: I need a better server too :?
[04:24] jed: ha ha, you got me.
[04:24] loktar: lol
[04:24] loktar: yeah once respawns are in itll be funner
[04:26] mrd`: loktar: You need the ability to use wasd to move around.
[04:26] loktar: yeah :?
[04:26] loktar: lol im old school
[04:26] loktar: I plan on adding it though
[04:27] loktar: im working on a single player zombie game as well. Surprised how many things I can have on the canvas at one time with minimal slowdown
[04:27] loktar: anyway thanks for checking it out
[04:57] kennethkalmer has joined the channel
[05:01] jed: isaacs: noble work. encoding does nothing but give me a headache.
[05:04] isaacs: ha
[05:12] hassox: isaacs: agreed
[05:12] hassox: but can you hurry up please? I need some flexible encoding! :P
[05:16] jed: i had an idea a few years ago to create a utf encoding that wasn't btye-count specific: basically, you take the four possible states for two bits: 10, 01, and 11 were balanced ternary specifying the codepoint, and 00 was the null separator.
[05:16] jed: (actually, unbalanced ternary... wonder if something like that would be practical at all?)
[05:17] mrd`: jed: What's the advantage to that?
[05:18] jed: mrd`: it's not a huge hack like utf8, and there's no upper limit on the number of codepoints you can support.
[05:19] jed: basically, there's no idea of a byte: just pairs of bits. you keep reading pairs until you get 00, flush, and repeat until you have an array of codepoints.
[05:23] tlrobinson1: Jed: interesting. what's the tradeoff
[05:23] tlrobinson1: implementation complexity?
[05:23] jed: the algorithm is dead simple, and looks a lot like DNA.
[05:24] jed: aka, like codons.
[05:24] jed: but it would require reading bits and padding, and i don't know much at that level.
[05:24] jed: also, you get to use ternary, which is really cool.
[05:24] tlrobinson1: one very nice thing about utf-8 is iit's compatibility with ASCII
[05:25] jed: of course of course. and for that alone it wins.
[05:25] jed: mine was more of a "what if we could start over" kind of thing.
[05:26] tlrobinson1: ah. maybe you could team up with the google wave team to replace email and ascii together ;)
[05:26] mikeal has joined the channel
[05:26] jed: ha, done! does this mean i get to move to sydney?
[05:26] tlrobinson1: segway too, while you're at it
[05:27] tlrobinson1: neat idea though
[05:29] jed: yeah, there's so much that programmers take for granted. i really dislike the idea that the next meaningful thing after a bit is so arbitrarily set at 8.
[05:29] mrd`: I don't.
[05:29] mrd`: :P
[05:31] jed: well, if it hadn't been so arbitrary, isaacs wouldn't need to sweat encoding issues!
[05:31] isaacs: haha
[05:34] mikeal: just wait until you have to deal with japanese emojicons
[05:34] mikeal: they aren't even part of unicode :
[05:34] mikeal: :)
[05:36] jed: yeah, i died a little inside when apple added emoji to the iphone. some of my friends send 100% emoji email. BOX BOX BOX.
[05:37] mikeal: it's awesome
[05:37] mikeal: i get txt's with smiling piles of poop now
[05:39] jubos has joined the channel
[05:42] scudco has joined the channel
[05:59] hassox: hahaha
[06:10] kennethkalmer has joined the channel
[06:16] cloudhead has joined the channel
[06:18] sahnlam has joined the channel
[06:45] mikeal has joined the channel
[07:03] hassox has joined the channel
[07:06] micheil: Anyone played with NodeJuice?
[07:10] chakrit: what is that?
[07:11] chakrit: mmm nodejuice.com seems to be down
[07:13] micheil_mbp has joined the channel
[07:15] Tim_Smart: chakrit:
[07:29] zmoog has joined the channel
[07:29] micheil has joined the channel
[07:30] micheil_mbp has joined the channel
[07:31] micheil_mbp has joined the channel
[07:32] micheil_mbp has joined the channel
[07:32] micheil_mbp: chakrit: it constantly is
[07:33] Tim_Smart: micheil_mbp: Looking at his first video, I could understand why
[07:33] Tim_Smart: "node... juice... node... juice... node... juice......."
[07:35] micheil has joined the channel
[07:43] rtomayko has joined the channel
[07:54] micheil: mon rtomayko
[07:54] micheil: *moin
[07:55] rtomayko: hello
[07:55] rtomayko: (had to look that one up: http://en.wikipedia.org/wiki/Moin)
[07:58] micheil: heh heh
[07:58] micheil: that's just the times spent talking in #dojo and to german colleagues coming out.. :P
[08:08] micheil: hmm.. I suppose I should do some work on node-protocol.. time to learn how the net2 buffer works
[08:08] micheil: ryah_away: what's the estimated release timeline for net2? days, weeks, months?
[08:17] felixge has joined the channel
[08:17] felixge has joined the channel
[08:21] sudoer has joined the channel
[08:43] hassox has joined the channel
[08:48] micheil: Updated: http://wiki.github.com/ry/node/
[08:48] micheil: Updated: http://wiki.github.com/ry/node/modules
[08:48] zmoog has joined the channel
[08:48] micheil: check them out, give feed back on the thread in the Mailing List.
[08:52] hassox has joined the channel
[08:52] Tim_Smart: atm I'm coding a few bindings to v8 itself, for a IRC bot :p
[08:52] Tim_Smart: haven't done much C++ so it's a bunch of fun learning this stuff
[08:55] Tim_Smart: micheil: Looks good
[09:04] markwubben has joined the channel
[09:06] mikeal has joined the channel
[09:13] kennethk_ has joined the channel
[09:25] paulca has joined the channel
[09:36] micheil: Tim_Smart: feel free to add the bindings in (if need be create a section for it, and make sure to state it's in C++)
[09:37] Tim_Smart: Well it is more of a learning exercise for me, so depending on the code quality I guess
[09:43] micheil: even so, doesn't hurt :)
[09:47] felixge: Tim_Smart: why do you need C++ for IRC?
[09:48] Tim_Smart: felixge: I am making a v8 evaluator
[09:48] felixge: Tim_Smart: ?
[09:48] Tim_Smart: need to make some bindings to the v8 library
[09:49] Tim_Smart: so I type this in a channel:
[09:49] Tim_Smart: v8> 1+1
[09:49] Tim_Smart: and it returns "2"
[09:49] Tim_Smart: just an experiment to learn the node.js add-on platform
[09:50] micheil: Tim_Smart: probably stick that on the frontpage, and create a subheading under projects: experiments
[09:51] Tim_Smart: Right, I'll push it to github at some time
[09:54] Tim_Smart: I might create some more useful bindings later on when I have a handle on things
[09:55] micheil: Tim_Smart: the way I see things is this: even if it fails, it marks a learning point, a point where another developer can come along and see how you did it, and possible what was wrong with it, and learn from it.
[09:57] Tim_Smart: yeah definitely, but I don't see it failing, as I just more determined if it goes bad
[09:59] unomi has joined the channel
[10:11] kennethkalmer has joined the channel
[10:13] kennethkalmer has joined the channel
[10:35] ithinkihaveacat has joined the channel
[11:19] aho has joined the channel
[11:21] hassox: guys anyone know how to get a tempfile in node?
[11:22] mahemoff has joined the channel
[11:26] felixge: hassox: there is no built-in support afaik
[11:26] hassox: felixge: any clues?
[11:27] felixge: hassox: mktemp if you're on linux: http://linux.die.net/man/1/mktemp
[11:28] hassox: felixge: kk
[11:28] hassox: can't assure that that's the case
[11:28] felixge: it doesn't behave the same on osx
[11:29] felixge: for better portability you might want to write your own function
[11:29] felixge: use a uuid as the file name
[11:29] felixge: anyway, there might be even better *nix tricks I'm not aware of
[11:31] Tim_Smart: felixge: Are you familiar with C++?
[11:34] hassox: wondering how to get the tmp dir :\
[11:35] felixge: Tim_Smart: I can copy & paste it reasonably well at this point : ). That and a tiny bit of experience with the v8 API is all I got at this point ;)
[11:36] felixge: hassox: '/tmp' is not an unreasonable first guess. Otherwise mkdir ~/.tmp if it doesn't exist maybe?
[11:36] hassox: yeah
[11:36] hassox: was thinking something like that
[11:36] hassox: maybe ~/.tmp is a good one
[11:52] tlrobinson_ has joined the channel
[11:54] ithinkihaveacat has joined the channel
[11:55] blackdog` has joined the channel
[11:59] mahemoff has joined the channel
[12:11] matthijs has joined the channel
[12:43] alex-desktop has joined the channel
[13:19] bryanl has joined the channel
[13:34] matthijs: hi, when looking at some examples I see a gets(function(x) {}); but this was removed?
[13:36] micheil: link to them?
[13:38] micheil: matthijs: as far as I know, node has never had anything that is gets(fn) nor has v8, so it must be a framework to which this is belonging.
[13:44] matthijs: ah ok, I saw it in a presentation linked on the nodejs page
[13:55] mies has joined the channel
[14:07] micheil: more then likely a framework was in use.
[14:08] Tim_Smart: gah my addon segfaults >.>
[14:08] Tim_Smart: after all that time trying to get it to compile
[14:10] kriszyp has joined the channel
[14:16] micheil: ouch
[14:17] micheil: Tim_Smart: time to work out where it segfaults then
[14:17] Tim_Smart: that is the hard part
[14:17] micheil: (I was getting segfaults without using c++ in node, so, yeah)
[14:17] micheil: things like unhandled / continuously firing / looping code can cause a segfault as far as I know
[14:19] micheil: anyway, it's 1am, G'night chaps.
[14:31] alexiskander has joined the channel
[14:39] Booster has joined the channel
[14:41] matthijs: I'm probably doing something wrong, but when I try the example on the frontpage (http server with a setTimeout hello world example), It can only handle one client at a time?
[14:47] joshbuddy has joined the channel
[14:47] joshbuddy has joined the channel
[14:48] alexiskander has joined the channel
[14:57] chewbranca has joined the channel
[14:58] cloudhead has joined the channel
[15:04] r11t has joined the channel
[15:06] jed_ has joined the channel
[15:09] ithinkihaveacat: matthijs: that doesn't sound right. how do you know it can only handle one client?
[15:10] matthijs: when I connect 2 clients it waits till the settimeout is finished before accepting the second one (and starting the settimeout for that one)
[15:11] matthijs: is instead of seeing "connect connect timout timout" I see "connect timeout connect timeout"
[15:20] davidsklar has joined the channel
[15:25] ithinkihaveacat: matthijs: strange, that works fine for me. your client is not a browser, is it? (could be restricting the number of outgoing connections)
[15:25] inimino: hassox: TMP should be in the environment
[15:28] inimino: hassox: actually it's TMPDIR
[15:30] inimino: hassox: so you should read that first, and then if it's not set, probably just use /tmp
[15:33] matthijs: ithinkihaveacat: ahh I found it, forgot to comment out some of the code i used to test it
[15:35] Booster has joined the channel
[15:40] brosner has joined the channel
[15:44] Yuffster has joined the channel
[15:45] joshbuddy has joined the channel
[15:45] joshbuddy has joined the channel
[15:51] Tim_Smart: micheil: Ends up node.js doesn't work too nicely with threads >.>
[15:52] charlenopires has joined the channel
[16:01] ithinkihaveacat has joined the channel
[16:11] matthijs: thanks for the help :)
[16:16] chakrit has joined the channel
[16:20] lifo has joined the channel
[16:21] nodejs_bot has joined the channel
[16:21] Tim_Smart: v8> test
[16:23] nodejs_bot has joined the channel
[16:23] Tim_Smart: v8> test
[16:25] nodejs_bot has joined the channel
[16:27] nodejs_bot has joined the channel
[16:29] technoweenie: i thought that was the point of node.js
[16:29] technoweenie: no threads!
[16:29] nodejs_bot has joined the channel
[16:30] Tim_Smart: technoweenie: I mean in the c++ backend
[16:30] technoweenie: ah
[16:45] RayMorgan has joined the channel
[16:45] jed_ has joined the channel
[16:55] nodejs_bot has joined the channel
[16:56] nodejs_bot has joined the channel
[16:56] Tim_Smart: v8> test
[16:56] nodejs_bot: Tim_Smart: Error: test is not defined
[16:57] Tim_Smart: v8> "I am powered by Google V8, running on a node.js server".split("").reverse().join("")
[16:57] nodejs_bot: Tim_Smart: revres sj.edon a no gninnur ,8V elgooG yb derewop ma I
[16:58] jed_: Tim_Smart: wow, can i try?
[16:58] Tim_Smart: type "v8> stuff"
[16:59] jed_: v8> "the time is " + (new Date).toTimeString()
[16:59] nodejs_bot: jed_: the time is 05:59:08 GMT+1300 (NZDT)
[16:59] Tim_Smart: The code is quite messy at the moment
[17:00] jed_: wow, cool. always nice to know what the time is in NZ.
[17:00] jed_: Tim_Smart: how do you prevent it from misbehaving if people give you malicious code?
[17:00] Tim_Smart: I have got to that yet
[17:00] Tim_Smart: ^^
[17:01] Tim_Smart: haven't*
[17:03] jed_: Tim_Smart: so what if if put v8> "v8> 'hello!'"
[17:03] jed_: (i'll resist for now....)
[17:03] Tim_Smart: v8> "v8> 'hello!'"
[17:03] nodejs_bot: Tim_Smart: v8> 'hello!'
[17:03] jed_: heh, right. the prepending makes it safe.
[17:04] rtomayko has joined the channel
[17:05] nodejs_bot has joined the channel
[17:05] Tim_Smart: just pushed a update
[17:05] Tim_Smart: I borrowed a pretty print function from _Ray_
[17:06] Tim_Smart: v8> {"test":"test"}
[17:06] nodejs_bot: Tim_Smart: Exception: Unexpected token :
[17:06] Tim_Smart: v8> 123
[17:06] nodejs_bot: Tim_Smart: 123
[17:06] Tim_Smart: v8> ({test: "test", bam: 123})
[17:06] nodejs_bot: Tim_Smart: Exception: seen is not defined
[17:07] Tim_Smart: hmm
[17:07] Pilate: tim: link yours?
[17:07] Pilate: ive got a version of that :P
[17:07] Tim_Smart: I might take it to a test channel
[17:08] Tim_Smart: Pilate: I re-coded the v8 parser in c++
[17:08] Pilate: ah
[17:08] Pilate: v8> var a; while(1) { a++; }
[17:09] jed_: v8> while( true ){}
[17:09] jed_: ha, beat me to it.
[17:09] Pilate: thats what crashes mine ><
[17:10] Tim_Smart: v8> "test"
[17:10] Tim_Smart: yeah I need to see how I can cause the addon to terminate, without killing the server
[17:14] Tim_Smart: I might look at the v8 header file for a method...
[17:15] Tim_Smart: ryah: :o
[17:16] ryah: hi
[17:18] Tim_Smart: ryah: Is it possible to run threads in a add-on? I tried and kept on getting segfaults on the Emit method
[17:18] sudoer has joined the channel
[17:19] ryah: yes, but you can only do v8 in the main thread
[17:19] ryah: that is, you can spawn a thread to handle some i/o as long as it never calls any v8/node functions
[17:19] ryah: (that includes object creation)
[17:19] Tim_Smart: Hmm, well, I'll quickly show you why I'm curious
[17:20] nodejs_bot has joined the channel
[17:20] Tim_Smart: v8> while(true) {}
[17:20] Tim_Smart: now my bot has just got stuck
[17:20] Tim_Smart: :p
[17:21] ryah: yeah, don't do that :)
[17:21] Tim_Smart: currently I am loading another instance of v8 in the addon
[17:21] Tim_Smart: I need a way of async calling the EvalCX method and being able to kill it
[17:22] Tim_Smart: with a ev_timer
[17:22] Tim_Smart: or something
[17:22] jtoy has joined the channel
[17:24] ryah: Tim_Smart: yeah i think starting another process is a good way to do that
[17:24] ryah: send it stuff to eval
[17:24] ryah: if it doesn't respond in a while then kill it
[17:24] Tim_Smart: Better to start it in the JS or in the C++?
[17:24] ryah: js
[17:25] Tim_Smart: apparent some people were have trouble with the "output" event
[17:25] Tim_Smart: apparently*
[17:25] blackdog`: yes, childprocess isn't working too well
[17:25] ryah: yeah, i've heard
[17:25] binary42 has joined the channel
[17:25] ryah: something i'll hopefully get to soon
[17:26] blackdog`: http://gist.github.com/289384
[17:26] blackdog`: ok, i think micheil sent you a detailed report,
[17:26] Tim_Smart: well anyway I tried a few things and learnt the hard way :p I tried pthread and got owned by segfaults
[17:26] voodootikigod has joined the channel
[17:27] ryah: Tim_Smart: yeah, you can't do that
[17:27] ryah: do the childprocess thing
[17:27] Tim_Smart: so will childprocess look in the modules paths?
[17:28] kriszyp_ has joined the channel
[17:29] ryah: bug me incessantly when you find the bug, and i'll fix it :)
[17:30] ryah: Tim_Smart: the child process doesn't look in require.paths
[17:30] ryah: Tim_Smart: also - tip: have the child process send master process a message "loaded" or something
[17:30] ryah: before continuing
[17:31] ryah: people often start sending the child processes messages directly after exec
[17:31] blackdog`: ryah: i've been through that, it's not working
[17:31] blackdog`: i get the handshake, but nothing is is picked up from the client, micheil has the same problem
[17:33] qFox has joined the channel
[17:35] ryah: blackdog`: okay - will have a look at it soon
[17:36] JimBastard has joined the channel
[17:36] Tim_Smart: blackdog`: What was the issue with childprocess? I might fork node.js and have a hack at it
[17:37] Tim_Smart: ryah: Forgot to ask, but can you use fork() in a addon?
[17:37] Tim_Smart: or does it mess with the event loop...
[17:37] qFxo has joined the channel
[17:38] blackdog`: Tim_Smart: i had two probs, the first given here, http://gist.github.com/289384
[17:39] blackdog`: That was the most immediate problem, micheil has another example here http://github.com/mikeal/node/blob/master/test/mjsunit/test-stdio.js
[17:39] steadicat has joined the channel
[17:39] keeto has joined the channel
[17:39] blackdog`: Tim_Smart: even after getting an initial handshake back from the childprocess, i was unable to get an even when sending data to it, micheil has the same issue there too
[17:40] blackdog`: s/even/event
[17:40] Tim_Smart: ok
[17:40] qFox has joined the channel
[17:41] Tim_Smart: I'll just make a test case first..
[17:41] blackdog`: Tim_Smart: which seems to me that everything that relies on it must be broken in head
[17:42] blackdog`: i think the logger was down when micheil and i discussed this, there seems to be no record
[17:44] tlrobinson_ has joined the channel
[17:46] isaacs has joined the channel
[17:46] Tim_Smart: blackdog`: Does process require a module?
[17:47] blackdog`: no, you don't have to require anything
[17:47] Tim_Smart: cool
[17:47] Tim_Smart: yeah I ran your example and got no output whatsoever >.>
[17:47] Tim_Smart: duh forgot the sys module
[17:48] blackdog`: i was doing my client from the repl
[17:51] Tim_Smart: so is it a problem with stdio, or childprocess?
[17:52] blackdog`: i'm afraid i don't have the c++ chops to figure that out
[17:53] Tim_Smart: Ah well you can find out by using another program to write to stdin
[17:53] ryah: ps a test/mjsunit test would be great
[17:55] blackdog`: ryah: http://github.com/mikeal/node/blob/master/test/mjsunit/test-stdio.js
[17:55] blackdog`: that's from micheil
[17:56] RayMorgan_ has joined the channel
[17:56] aguynamedben has joined the channel
[17:57] sahnlam has joined the channel
[17:57] nodejs_bot has joined the channel
[17:59] isaacs: jed_: i don't get your tweet. did you point middlehere.com at me or something? (can't connect to the server)
[18:00] jed_: isaacs: yeah, it points to jetski. pressure's on!
[18:00] isaacs: ahh, kewl
[18:00] jed_: at least until either of us starts pumping out middleware.
[18:01] jed_: isaacs: btw, i hope your promise suggestion is what we end up using.
[18:01] isaacs: my promise suggestion?
[18:01] jed_: yeah, on the ML.
[18:04] isaacs: oh, the double-barreled thing
[18:04] isaacs: yeah, wasn't that your idea?
[18:05] eikke has joined the channel
[18:06] ryah: isaacs: http://pastie.org/804499 what do you think about this interface
[18:06] mattly has joined the channel
[18:06] jed_: isaacs: the part about throwing if no error handler is defined is much nicer than what i suggested.
[18:07] pmuellr has joined the channel
[18:08] inimino: ryah: that looks nice
[18:08] jed_: ryah: (while you're adjusting that part of the API, what would you think about standardizing http.createServer and http.createClient as new http.Server and new http.Client respectively?)
[18:08] isaacs: ryah: i like it. but why send() rather than write()?
[18:09] isaacs: it'd be nice to move towards symmetry wherever possible.
[18:09] RayMorgan: I agree, to match the future streaming api
[18:09] ryah: isaacs: shrug. i guess write is okay
[18:09] Tim_Smart: I prefer writeHeader to startResponse
[18:11] isaacs: is there any way for your code to be alerted if the client disconnects?
[18:11] isaacs: (http)
[18:11] ryah: here is another example
[18:11] ryah: http://pastie.org/804507
[18:12] ryah: Tim_Smart: yeah good point
[18:12] mahemoff has joined the channel
[18:13] ryah: isaacs: r.connection.addListener('close')
[18:13] isaacs: ryah: great! had a feeling it was simple like that.
[18:14] Tim_Smart: ryah: Why not set the method to "FILE" when uploading?
[18:15] Tim_Smart: I think that is what it is on PHP etc..
[18:15] ryah: because that's not the method
[18:15] Tim_Smart: ok
[18:16] Tim_Smart: so how do you distinguish between upload request and a normal request?
[18:16] ryah: you don't
[18:16] Tim_Smart: I see :p
[18:16] ryah: i'm just mapping http to js and trying not to get in the way
[18:18] jed_: so the response is composed of methods on the request object? i guess i'm alone here, but i think this makes the api harder to understand.
[18:18] ryah: it's a duplex stream
[18:18] ryah: why not?
[18:19] isaacs: hey, also, i was thinking the other day, why not, instead of doing r.addListener("data", callback) just do r.read(cb)
[18:20] ryah: because it doesn't follow the eventemitter pattern?
[18:20] isaacs: Stream.prototype.read = function (cb) { this.addListener("data", cb); this.addListener("end", cb(null)); }
[18:20] Tim_Smart: isaacs: Implement it in your own library
[18:20] ryah: why null?
[18:20] ryah: oh
[18:20] isaacs: eh, just throwing out ideas.
[18:20] RayMorgan: I would rather stick with the event emitter pattern
[18:20] isaacs: so that you can get an eof notification in your reader.
[18:20] jed_: basically the difference is that the request and response object are merged into one object. i'm okay with that, but don't see what we gain.
[18:20] RayMorgan: I think it is a good simple pattern that JS developers know well
[18:21] isaacs: ok, that settles it, then :)
[18:21] ryah: jed_: at least one less object per request
[18:21] isaacs: i bring it up because one common objection of streaming jsgi is "but i don't have a read method how does i reads it!!?!?!?"
[18:21] ryah: shrug. who care about them
[18:22] isaacs: ryah: you and i have different motivations, i think
[18:22] RayMorgan: jsgi can add read(), I would stick with the EE model for node core
[18:22] ryah: isaacs: what's your motivation?
[18:22] isaacs: you want to build fast servers, and i want to build web apps on top of those fast servers.
[18:22] isaacs: and i want a community of people adding stuff.
[18:22] ryah: i think a simple api is best
[18:22] isaacs: true
[18:22] ryah: people can build stuff on top of node just fine
[18:23] isaacs: it's not that our motivations don't align mostly ;)
[18:23] jed_: i agree with RayMorgan, personally. i think .read() doesn't jive with the event emitter model.
[18:23] ryah: that's a good point RayMorgan
[18:23] isaacs: true that
[18:23] ryah: read() looks cute i admit
[18:24] isaacs: thing is, i'm not completely sold on the EE model. what's so bad about callbacks?
[18:24] ryah: well, in that case why not r.onRead = function (data) {}
[18:24] jed_: (i also think "on" would be a good name for the "addListener" method.)
[18:24] isaacs: even r.ondata = fn; r.onclose = fn2
[18:24] isaacs: ryah: yeah, why not?
[18:24] ryah: i'd be fore it :)
[18:24] RayMorgan: Nothing is bad about cbs, but I rather have multiple callbacks for various events than one with if/switches
[18:24] isaacs: i mean, for the general case, it's kinda lame.
[18:25] jed_: "read" sounds like a transitive verb, which not what it is in this case.
[18:25] ryah: a lot less overhead
[18:25] isaacs: but it's perfectly possible to write a very robust event emitter pattern just in js
[18:26] ryah: it seems like you're arguing for my position - you're supposed to want things that middleware can add on to
[18:26] isaacs: hahaha, ryah i can argue any position I want, don't tell me what i'm supposed to want! ;P
[18:26] ryah: what's middleware to do with .onread
[18:26] RayMorgan: I would be ok with onData/onEOF... but chaining would mean you would have to add another layer on top of it
[18:26] Tim_Smart: ryah: Here's another way at looking at it
[18:26] Tim_Smart: http://pastie.org/804523
[18:26] isaacs: well, the thing is, that can be wrapped up at the jsgi level anyhow.
[18:27] isaacs: i mean, jsgi already specifies a bunch of things that arent' and shouldn't be in node core.
[18:27] ryah: (it used to be onData/onComplete)
[18:27] unomi: how about r.on('event' function(){}); ?
[18:27] ryah: (until people forced me to implement event emitters)
[18:27] unomi: rather than 'hardcoded' onEvent
[18:28] isaacs: otoh, an EE pattern IS more extensible and whatnot, and a symmetrical stream API that's used wherever it makes sense to stream data, that'd also be winful.
[18:28] ryah: Tim_Smart: ?
[18:28] isaacs: guessable APIs are better.
[18:28] Tim_Smart: unomi: That is very similar to how it is done now
[18:28] unomi: whats wrong with it?
[18:28] unomi: sorry, just started reading
[18:28] isaacs: unomi: nothing really. the thing is, it just uses addListener instead of "on"
[18:29] unomi: shorter is better ;)
[18:29] isaacs: we just like changin stuff
[18:29] unomi: heh
[18:29] Tim_Smart: ryah: I was just trying a different way of doing things: http://pastie.org/804523
[18:29] ryah: unomi: EventEmitter.prototype.on = EventEmitter.prototype.addListener;
[18:29] isaacs: Tim_Smart: cant' you already do basically that wiht http.createServer?
[18:29] inimino: ryah: people can easily add 'addListener' style atop onread-style
[18:29] charlenopires has joined the channel
[18:29] isaacs: also, beware of this: new http.Server
[18:29] inimino: ryah: I prefer onread too, it's simpler
[18:29] jed_: isaacs: one of the nice things about using "on" is that you can have parallen onEVENT methods.
[18:29] isaacs: that is like (new http).Server
[18:30] RayMorgan has joined the channel
[18:30] inimino: isaacs: hm?
[18:30] ryah: note that the DOM uses EE
[18:30] Tim_Smart: isaacs: Ah are you sure?
[18:30] ryah: Tim_Smart: server.addListener('data') ?
[18:30] jed_: so server.on( "request", fn ) == server.onRequest( fn )... pretty guessable IMHO
[18:31] isaacs: ah, no, nvm.
[18:31] inimino: isaacs: that parses as new (http.Server), just like it reads
[18:31] isaacs: i was thinking of new require("http").Server
[18:31] Tim_Smart: ryah: for upload? not sure
[18:31] isaacs: which tries to do a (new require("http")).Server
[18:32] unomi: the nice thing about on('event') is that for appropriate places you can do on('event1, event2, event3', function(){})
[18:32] inimino: isaacs: ah, yes, because of the ()
[18:32] isaacs: i set "wrap the ctor in parens when using new" as a rule in the brain, and it's been a red flag ever since.
[18:32] unomi: or atleast it could be possible
[18:32] ryah: ACTION closes the door on new api talks
[18:32] isaacs: hahah
[18:32] isaacs: event emitters ftw!!
[18:33] ericflo has joined the channel
[18:33] unomi: isaacs: no yuinode for us?
[18:33] inimino: ryah: so if you have onevent, frameworks can add something like...
[18:33] jed_: ryah: a good idea. just make it fast and we'll make it pretty on top, deal?
[18:33] ryah: okay
[18:33] RayMorgan: I agree with jed_ ... make it fast!
[18:34] nodejs_bot has joined the channel
[18:34] isaacs has joined the channel
[18:34] jed_: i mean, i'm already obese from (fab) syntactic sugar.
[18:35] Tim_Smart: hmm my silly vim shell isn't responding to Crtl + C
[18:35] Tim_Smart: grr
[18:35] inimino: function addListener(emitter,event,f){var on='on'+event,g; if(g=emitter[on]){emitter[on]=function(){g();f()}} else emitter[on]=f}
[18:36] inimino: ryah: ↑
[18:36] ericflo has joined the channel
[18:37] isaacs: jed_: with (fab) youer' in danger of developing diabetes
[18:37] ryah: inimino: show me it's faster
[18:37] inimino: (so we don't /need/ event emitters, people that want them can add them on top of onevent=function(){})
[18:37] ryah: ah okay
[18:38] ryah: you know i was thinking about how to do that too
[18:38] jed_: isaacs: oh, i'm already there. and node.js is the corn industry to my HFCS.
[18:38] ryah: but i always thought about doing it on 'emit'
[18:38] isaacs: hahah
[18:38] inimino: ryah: I don't know if it's faster or not, but it's definitely simpler
[18:38] ryah: which i think would be slow
[18:38] ryah: inimino: maybe i'll do that
[18:38] inimino: cool
[18:38] jubos has joined the channel
[18:38] isaacs: so then, to emit an event you just do foo.onevent()?
[18:39] inimino: isaacs: yes
[18:39] ryah: well
[18:39] jed_: that's how jQuery works, FWIW.
[18:39] inimino: (to simulate an event anyway)
[18:39] isaacs: so, basically, you're using AOP instead of event emissin
[18:39] jed_: $().click() is a trigger, $().click( fn ) is a handler.
[18:40] isaacs: that's like YUI's Y.after()
[18:40] isaacs: Y.after(obj, "foo", fn) will call fn() after any time you do obj.foo()
[18:41] isaacs: ACTION .oO( we're all piled up outside the door ryah closed a minute ago )
[18:41] inimino: hehe
[18:41] jed_: isaacs: ha ha.
[18:41] bjartek: very nice discussion though :)
[18:44] ryah: http://pastie.org/804545 <-- onbody
[18:44] ryah: there is little overhead
[18:44] ryah: oh wait
[18:45] bjartek: that code reloading post was pretty cool, erlang style
[18:45] ryah: no that doesn't work
[18:45] jed_: isaacs: so a constructor for Server would need new ( require("http").Server ) to work safely, i guess.
[18:45] isaacs: jed_: yeah, that's why i just kinda treat new as if it's a function most of the itme.
[18:46] isaacs: not always, but i try to stick to that.
[18:46] isaacs: new(Foo)
[18:46] JimBastard: today is first day of new JS job
[18:46] JimBastard: huzzaaah
[18:46] isaacs: JimBastard: w00t! whereat?
[18:46] jed_: congrats, JimBastard.
[18:46] JimBastard: a nyc startup, no name dropping for now :p
[18:46] JimBastard: thanks
[18:47] Tim_Smart: are they using node.js? haha
[18:48] JimBastard: no node
[18:49] JimBastard: i am getting paid to do node though for a side project
[18:49] JimBastard: at least im suppose to
[18:49] JimBastard: stupid clients
[18:49] Tim_Smart: haha. I should switch all my web development work over to node... will force me to write a framework for it at least
[18:50] Tim_Smart: and I'll probably end up writing some bindings here and there
[18:52] konobi: isaacs: you get all sorted on smart?
[18:53] isaacs: konobi: yeah, it's workin
[18:53] isaacs: thanks!
[18:53] konobi: gd gd
[18:53] konobi: isaacs: feel free to add issues to the github issue tracker if you discover anything
[18:53] RayMorgan: this is still the prominent API for the future stream API correct? Been using the API in all my work lately. http://pastie.org/794198
[18:56] ryah: RayMorgan: maybe 'end' instead of 'eof'
[18:56] ryah: maybe 'send' instead of 'write'
[18:59] Tim_Smart: Shoutout: Who is keen for collaborating on a framework?
[19:02] stephenlb has joined the channel
[19:02] JimBastard: Tim_Smart there are a lot out there, you should checkout the landscape first
[19:03] r11t has joined the channel
[19:03] Tim_Smart: JimBastard: Yeah I have and will continue to do so
[19:08] JimBastard: i'm down for helping though
[19:09] JimBastard: i just think it would be wiser to build on an existing project / community
[19:09] JimBastard: maybe not
[19:09] JimBastard: ive got a bunch of code laying around though and a few github projects for node
[19:09] JimBastard: http://github.com/marak
[19:10] Tim_Smart: OK I'll add you
[19:10] JimBastard: yaaa github friends
[19:10] JimBastard: id like to build a node IDE maybe
[19:10] JimBastard: ive got a pretty solid start with node_debug
[19:10] Tim_Smart: First off I'm going to look at as many database options as possible
[19:11] JimBastard: im hoping mongo is ready....
[19:11] JimBastard: theres been a few attempts, some seem promising
[19:11] Tim_Smart: OK, how does mongo perform?
[19:11] JimBastard: mongodb is apparently amazing
[19:11] JimBastard: fast and scalable
[19:11] JimBastard: highly concurrent
[19:11] JimBastard: mind you i havent actually used it yet
[19:11] JimBastard: but i hear great things
[19:11] JimBastard: and i do have it installed
[19:11] blackdog`: JimBastard: there are two sets of drivers for node now (mongo)
[19:12] blackdog`: a native, and a js version
[19:12] JimBastard: yeah, im not sure if either are close to production ready
[19:12] blackdog`: that's all you got :)
[19:12] JimBastard: its been a good month for mongo though
[19:12] JimBastard: and node
[19:12] JimBastard: its getting there
[19:15] jcrosby has joined the channel
[19:16] mikeal has joined the channel
[19:19] Tim_Smart: whoa, mongo performed better than memcached?
[19:20] JimBastard: memcached is a database?
[19:20] jfd has joined the channel
[19:20] matthijs has joined the channel
[19:20] Tim_Smart: no it isn't
[19:20] Tim_Smart: it's is a cache
[19:24] rictic has joined the channel
[19:25] stephenlb: heh
[19:26] jan____ has joined the channel
[19:26] Tim_Smart: JimBastard: I think we should rethink web framework design when it comes to node. Everyone seems to be mirroring other frameworks atm
[19:26] bpot has joined the channel
[19:26] JimBastard: Tim_Smart the problem for me when i first started a couple of months ago was lack of modules
[19:27] JimBastard: now that smtp, ftp, file, session, mime are all established
[19:27] Tim_Smart: JimBastard: Learn C++ :p
[19:27] JimBastard: i feel like it would be a lot easier
[19:27] JimBastard: i mean CommonJS modules
[19:27] JimBastard: and now there are a few
[19:27] Tim_Smart: OH ok
[19:27] JimBastard: i just dont have any interest in building a framework that no one is gonna use
[19:27] Tim_Smart: yeah they are slowly piling in
[19:27] JimBastard: caus honestly doing the documentation and collaboration will take just as much time as writing code
[19:28] JimBastard: and if there is no community id rather just write it for myself you know?
[19:28] JimBastard: like i have a custom framework in place already, just not well documented
[19:28] sudoer has joined the channel
[19:28] JimBastard: or very modular outside of my project
[19:28] Tim_Smart: JimBastard: Yeah well if you get a small strong community working on it...
[19:28] JimBastard: have you looked into express at all?
[19:29] jed_ has joined the channel
[19:29] JimBastard: visonmedia i guess? im not sure if that is mediacoder
[19:29] Tim_Smart: I had a brief look. Based on sinatra
[19:29] JimBastard: and jed_ has his framework as well fab
[19:29] JimBastard: doing a good framework requires just as much community building as it does features
[19:29] JimBastard: unless no one is gonna use it
[19:29] JimBastard: :-\
[19:29] chewbranca has joined the channel
[19:30] JimBastard has joined the channel
[19:30] JimBastard: stupid java.freenode
[19:30] JimBastard: hit the backspace
[19:30] Tim_Smart: haha
[19:32] JimBastard: so yeah Tim_Smart what is wrong with express?
[19:32] JimBastard: i mean i tried using it and stopped
[19:32] Tim_Smart: nothing, I haven't tried it
[19:33] JimBastard: so why you wanna make a framework?
[19:34] Tim_Smart: I have time, and I want to see if there is a more effeicient way of doing things with node. Like Javascript that can be used both client side and server etc
[19:35] jed_: Tim_Smart: i'm looking to port (fab) to the server eventually. would love to see something like that.
[19:35] MattJ has joined the channel
[19:35] jed_: s/server/browser/
[19:36] Tim_Smart: jed_: It is sorta python-ish
[19:36] Tim_Smart: with the blocky statements
[19:36] jed_: Tim_Smart: but the good news is that whitespace is just a convention, whew.
[19:37] Tim_Smart: well anyway, I will be thinking about this for quite a bit
[19:37] JimBastard: Tim_Smart i could handle that
[19:37] JimBastard: i think i could spec out a framework that worked client and serverside
[19:38] JimBastard: with strong routing support
[19:38] JimBastard: both location.hash style (ala sammy.js or jquery.bbq.js or my route.js)
[19:38] JimBastard: and sinatra style
[19:38] Tim_Smart: JimBastard: Well things like models and form verification and be shared
[19:38] JimBastard: jed_ i thought fab did work on the sserver?
[19:39] jed_: JimBastard: yeah, i mistyped.
[19:39] JimBastard: 10-4
[19:39] JimBastard: but yeah, id love to write a node app framework....i just dont think i could handle it when no one used it
[19:39] JimBastard: and i start begging people on hackernews to contribute
[19:40] Tim_Smart: :p
[19:40] JimBastard: also if you are gonna do a client-side / server-side framework
[19:40] JimBastard: its gonna be a little tricky for the client-side stack
[19:40] JimBastard: do you impose jquery?
[19:40] Tim_Smart: ya
[19:41] Tim_Smart: actually I'm not sure
[19:41] JimBastard: if you really wanna start up a node framework that works on both sides im in
[19:41] Tim_Smart: maybe we can make use of $ server-side
[19:41] JimBastard: only if we can call it "Biggie" i already have artwork for a notorious big js app framework
[19:41] JimBastard: Tim_Smart, that is a whole other can of worms
[19:41] JimBastard: getting sizzle to work server-side
[19:41] JimBastard: and jquery
[19:42] JimBastard: no idea the status of that
[19:42] Tim_Smart: JimBastard: Not jQuery
[19:42] Tim_Smart: JimBastard: Just making use of $ that people are used to using with jQuery
[19:44] Tim_Smart: I also want to make sure most things are re-usable, so you can drop in stuff from other projects
[19:44] mattly has joined the channel
[19:44] JimBastard: errr when i see $ and JS im thinking selector engine
[19:45] JimBastard: so you'd need to essentially get $ and sizzle working server-side
[19:45] JimBastard: might be really easy no idea
[19:45] Tim_Smart: yeah well it's just my brain churning :p
[19:48] jtoy has joined the channel
[19:52] rockstar has joined the channel
[19:52] MarkAlanEvans has joined the channel
[19:54] Tim_Smart: JimBastard: A good place to brainstorm would be Google Wave
[19:54] Tim_Smart: if you got an account that is...
[19:54] orlandov: ooh hot code reloading
[19:54] rolfb has joined the channel
[19:55] Tim_Smart: orlandov: Also check out http://www.nodejuice.com/
[19:55] felixge: orlandov: yeah!
[19:55] felixge: orlandov: hot code reloading is ... hot!
[19:56] JimBastard: Tim_Smart if you want to start up a project im in
[19:56] orlandov: ooh
[19:56] JimBastard: just point me where to write stuff
[19:56] JimBastard: ive got no patience for community building for a node framework
[19:56] Tim_Smart: JimBastard: Well before we move forward, we got to plan it a bit
[19:56] orlandov: i wish nginx didn't have such shit support for SCGI
[19:56] stephenlb: oh wow, http://nodejuice.com cool!
[19:58] JimBastard: Tim_Smart start up a doc or a wave
[19:58] JimBastard: or a email on the mailing list
[19:58] JimBastard: im still not convinced its the right move to start up another framework yet
[19:58] JimBastard: might need more modules first
[19:59] Tim_Smart: JimBastard: Yeah I will wait a little while before going head-on
[19:59] orlandov: creating web frameworks is a bit like masturbation
[19:59] konobi: orlandov: http://www.evanmiller.org/nginx-modules-guide.html http://www.evanmiller.org/nginx-modules-guide-advanced.html
[19:59] konobi: =0)
[19:59] orlandov: konobi: ugh pass ;)
[20:00] konobi: seems fairly reasonable actually
[20:00] RayMorgan: man, vroom was originally called juice.. but like a million things popped up with that name so I changed it
[20:00] RayMorgan_ has joined the channel
[20:00] orlandov: konobi: there already exists one but it's horribly unmaintained
[20:00] konobi: yar... uses a different API too
[20:01] orlandov: ACTION keeps using cherokee
[20:04] Tim_Smart: JimBastard: https://wave.google.com/wave/?pli=1#restored:wave:googlewave.com!w%252BayXwiDRMA
[20:10] brandon_beacher has joined the channel
[20:14] jed__ has joined the channel
[20:15] JimBastard: Tim_Smart that link isnt really working
[20:15] Tim_Smart: right
[20:15] JimBastard: google wave kinda sucks
[20:15] JimBastard: :-(
[20:16] Tim_Smart: yeah it does for now. It needs to be more mailing-list like
[20:20] ashb: stephenlb: you stole my project name :P
[20:21] JimBastard: cool Tim_Smart i'll try to update that file a bit
[20:21] JimBastard: (when im not at work)
[20:21] stephenlb: ashb: :P
[20:21] Tim_Smart: JimBastard: How did you find it?
[20:21] Tim_Smart: search?
[20:21] stephenlb: ashb: what was your project?
[20:21] JimBastard: and for the record, i like "Biggie" in honor of Notorious BIG
[20:21] ashb: juciejs.org
[20:22] stephenlb: ACTION looks
[20:22] JimBastard: Tim_Smart i dunno the wave worked
[20:23] stephenlb: ashb: pretty logo
[20:23] ashb: stephenlb: thanks
[20:23] ashb: stephenlb: odds of you renaming are slim i take? :)
[20:25] mikeal has joined the channel
[20:25] stephenlb: ACTION already bought the domains for 10 years :(
[20:26] ashb: figured as much. never hurts to ask tho
[20:26] stephenlb: for sure. glad you did.
[20:27] rolfb: what was the name again?
[20:27] rolfb: i missed it
[20:27] stephenlb: nodejuice.com VS juicejs.com
[20:27] stephenlb: i believe...
[20:27] rolfb: oh
[20:27] stephenlb: .org rather*
[20:27] tmpvar has joined the channel
[20:29] isaacs: stephenlb: why do you call it "wsgi"? that's a little confusing, since it's so very very different from python's wsgi
[20:30] isaacs: stephenlb: any thought to using one of the async jsgi specs instead?
[20:30] stephenlb: isaacs: okay, break my arm will ya. I agree actually.
[20:31] isaacs: stephenlb: doesn't have to be a violent thing ;P
[20:31] stephenlb: heh
[20:32] stephenlb: isaacs: so chaning it to jsgi would allow the static and js server to run, however Seeker (the File Watcher) requires epoll or some other non-blocking local file i/0
[20:32] nrstott has joined the channel
[20:33] isaacs: stephenlb: i guess what i'm suggesting is breaking out the "wsgi" portion from it, and instead plugging in anything with jsgi-hooks.
[20:33] malkomalko has joined the channel
[20:34] ashb: WSGI did confuse me, since WSGI is python's (to my mind)
[20:34] isaacs: since the seeker-server and juicy portions can work with Apache, seems like it could be done, no?
[20:34] stephenlb: isaacs: agreed.
[20:34] isaacs: ashb: same here. worst acronym ever, of course.
[20:35] matthijs: how can I add a callback to the close event of the http server? (in the createServer(request_listener,..)) because I need to remove some events if the connection is closed
[20:35] stephenlb: ashb, isaacs: yah, let's change that for sure. for now what do u recommend since it is neither WSGI nor JSGI atm?
[20:37] kennethkalmer has joined the channel
[20:37] ashb: stephenlb: er dunno.
[20:37] stephenlb: ashb: heh. how about S.G.I :)
[20:40] rolfb has joined the channel
[20:41] ashb: is it node specific?
[20:41] stephenlb: ashb: yes, it sure is!
[20:42] Hey has joined the channel
[20:42] ashb: stephenlb: not quite sure
[20:42] ashb: njgi ?
[20:42] ashb: since the api is nj specific?
[20:42] stephenlb: ashb: makes sense.
[20:42] JimBastard: this whole JSGI business seems a little too complicated
[20:43] JimBastard: needs to be a lot simplier imho
[20:43] stephenlb: JimBastard: jsgi is a nice spec cuz it's unification of all vm's for standard http.
[20:43] stephenlb: ACTION feels like elmo again :/
[20:44] orlandov: jsgi is tailored for synchrnous operations isn't it?
[20:44] JimBastard: based on the mailing list i think so yes orlandov
[20:44] orlandov: thats the impression i got too
[20:44] isaacs_mobile has joined the channel
[20:44] orlandov: sorry to spread fud if that's not the case :)
[20:45] eviltwin has joined the channel
[20:46] jan____ has joined the channel
[20:46] jan____ has joined the channel
[20:46] eviltwin has left the channel
[20:47] isaacs_mobile: Orlandov: we're working on that
[20:47] stephenlb: ashb: what about nsgi? i'll have time later this evening to make the update. let me know.
[20:47] isaacs_mobile: :)
[20:50] jan____ has joined the channel
[20:51] rolfb has joined the channel
[20:54] ithinkihaveacat has joined the channel
[20:54] paulca has joined the channel
[20:56] ashb: stephenlb: nsgi could work - check with other people
[20:56] stephenlb: ashb: will do. ty for pointing this out.
[21:05] okito has joined the channel
[21:07] jan____ has joined the channel
[21:09] ericflo has joined the channel
[21:12] felixge: ryah_away: if you are there, I'm wondering if you agree with my requirements for hot code reloading. Can't await to work on a better patch for it
[21:12] felixge: ;)
[21:20] yaroslav has joined the channel
[21:21] rockstar has joined the channel
[21:21] MattJ: felixge: was that your blog post I read about it?
[21:21] felixge: MattJ: no, that was someone else. But I've been working on hot code reloading for quite a bit and he brought the topic back to life :)
[21:22] MattJ: Ah
[21:22] MattJ: I was interested to see how similar CommonJS's require() is to Lua's require()
[21:23] MattJ: ACTION is a Lua fanatic, which is the only thing that makes that relevant
[21:24] felixge: : )
[21:24] felixge: Lua looks nice
[21:24] felixge: never had a chance to use it much so
[21:26] MattJ: Quite similar to Javascript, which is probably the only reason I like Javascript enough to use it :)
[21:27] MattJ: I wrote an XMPP server in Lua, and now I'm looking at Node.js as a way to bridge Javascript code to it (Javascript still being the more popular language among developers currently)
[21:28] mrd`: MattJ: That would be cool.
[21:29] MattJ: +1
[21:29] MattJ: Hoping to get something demo'able done by FOSDEM
[21:31] mrd`: Cool.
[21:35] jcrosby has joined the channel
[21:39] gwoo: felixge: i just noticed blaine working on hotloading too
[21:41] felixge: gwoo: yeah, this is probably the 3rd duplicate patch for this : ). So far the implementation wasn't the problem, but the whole thing falling apart under heavy load was
[21:41] felixge: but that seems to be gone now
[21:41] gwoo: too bad to see efforts duplicated
[21:46] RayMorgan has joined the channel
[21:51] ashb: how do you deal with setInterval and hot-reloading?
[21:53] mattly_ has joined the channel
[21:54] mrd`: Node.js supports hot reloading?
[21:55] konobi: it'll never be "real" hot reloading, but a decent enough approximation
[21:55] mrd`: ?
[21:59] brandon_beacher has joined the channel
[22:02] mattly has joined the channel
[22:06] okito has joined the channel
[22:15] cloudhead has joined the channel
[22:16] SlexAxton has joined the channel
[22:16] hassox has joined the channel
[22:17] SlexAxton: Hi noders!, I'm running v0.1.26-20-gfc025f8 and was just wondering if I'm doing something silly, or if requests happen twice with this code: http://pastie.org/804934
[22:17] SlexAxton: i seem to get dual requests everytime
[22:18] stephenlb: SlexAxton: are testing with a web browser? the second request may be favicon.ico
[22:18] SlexAxton: oh, why yes
[22:19] SlexAxton: is there something easy i should do for that?
[22:19] SlexAxton: block that route
[22:19] orlandov: test with curl :)
[22:19] SlexAxton: actually im checking the requests
[22:19] SlexAxton: on the sys.puts part
[22:20] SlexAxton: and both requests seem to be for the base document
[22:20] SlexAxton: no thats a lie
[22:20] SlexAxton: i was looking at host
[22:20] stephenlb: SlexAxton: try what orlandov recommends: "Test with curl", wget or netcat.
[22:23] SlexAxton: yea, with wget, it seems to be a single request
[22:23] SlexAxton: ok cool, was just trying out some database stuff and hadnt set up the router yet
[22:23] SlexAxton: thanks fellas
[22:24] SlexAxton: (or ladies)
[22:24] stephenlb: SlexAxton: np
[22:31] isaacs: for those that care, i updated ejsgi to use "end" instead of "eof", adn not to emit "drain" unless there was something to drain, and to have write return true/false depending on whether or not it will definitely be empty on the next tick.
[22:33] stephenlb: isaacs: sweet, always thought that on_drain shouldn't emit if it wasn't in a buffered state.
[22:34] isaacs: yeah, that was actually how ryah specced it initially, i just misread it.
[22:34] isaacs: it's a bit odd if you listen to "drain" and have it fire *every damn time* you write anything.
[22:34] stephenlb: heh
[22:36] isaacs: go make your voice heard: http://wiki.commonjs.org/wiki/JSGI/StreamExtension/vote
[22:36] bryanl has joined the channel
[22:39] isaacs: i *really* wish there was a way to use promises without so much typing
[22:39] cc has joined the channel
[22:39] deanlandolt: isaacs: try when
[22:40] isaacs: deanlandolt: yeah, that makes it a bit nicer.
[22:40] deanlandolt: rather try kriszyp_'s promise stuff and do a require("promise").when
[22:40] deanlandolt: 4 characters are pretty easy to type :D
[22:40] deanlandolt: plus, if you're mixing sync and async (and i /know/ nobody cares about this with node, but still...) it lets you have both
[22:41] deanlandolt: but i'm still unsure about the forEachable-returning-promise approach...still experimenting
[22:42] deanlandolt: the stream stuff makes more sense to me but kriszyp_ has some cool stuff around lazy arrays i think i really <3 ...once i can fully wrap my head around it all
[22:42] RayMorgan: isaacs: in the StreamExtension vote does #2 mean that there is no returning a promise.. but instead the headers are also sent via something like r.writeHeader
[22:43] isaacs: RayMorgan: returning a promise in place of the entire response object (which will resolve to a valid jsgi response object) is supported by all proposals.
[22:43] isaacs: as far as i'm concerned, that's already a done deal.
[22:43] isaacs: ejsgi supports that, pintura assumes it, and deanlandolt is hacking it into jack, right?
[22:43] deanlandolt: isaacs: si
[22:44] isaacs: so, really, this is a separate concerne.
[22:44] deanlandolt: actually kriszyp_ already hacked that into jack in his simple-worker handler
[22:44] deanlandolt: so that's a done deal
[22:44] isaacs: ah, ok, great.
[22:44] RayMorgan: so you return a promise, then eventually resolve that with just the headers and then start streaming the body back?
[22:45] deanlandolt: RayMorgan: yeah, with status and headers and a body stream that you can write to
[22:45] hassox: RayMorgan: yup... works a treat too
[22:45] deanlandolt: or, alternatively, with a forEachable that can also return a promise
[22:45] RayMorgan: I like streaming :)
[22:46] deanlandolt: aye, but lazy arrays are a really cool prospect
[22:46] isaacs: so, the thing is, you can turn a writable stream into a promising-foreachable pretty easily.
[22:47] isaacs: like, in a 4 line function hanging on Stream.prototype.forEach
[22:47] deanlandolt: isaacs: and vice versa
[22:47] isaacs: exactly.
[22:47] isaacs: so, we're just painting the bikeshed at this point.
[22:47] r11t has joined the channel
[22:47] jcrosby has joined the channel
[22:47] isaacs: imo, symmetry is good, and if we all go with promising foreachable, then i'll just make my streams into that
[22:47] isaacs: but i'd prefer to use the symmetrical API instead.
[22:48] isaacs: use it directly, i mean.
[22:48] deanlandolt: i like the symmetry...i think no matter which we went with we should go with the symmetrical request.body
[22:48] paulca has joined the channel
[22:48] isaacs: right. but then, if we go with a promising foreachable, should request.body be one of those, as well?
[22:48] isaacs: it gets weird.
[22:48] deanlandolt: it does...but it's really not that weird
[22:49] hassox: I think streams are more natural than a promising foreachable
[22:49] deanlandolt: both streams and promising foreachables can be naturally representative of chunked input
[22:49] hassox: sure, but I mean that it feels more natural to me ;)
[22:49] sudoer has joined the channel
[22:49] deanlandolt: hassox: i agree it may be more natural, but there /are/ some other benefits, past the bikeshedding, that foreachables give...
[22:50] hassox: such as
[22:50] RayMorgan: maybe I am missing what you mean, but wouldn't "you can turn a writable stream into a promising-foreachable pretty easily" require buffering?
[22:50] isaacs: well, basically, with a dash of light sugar, you can treat promising foreachables just like regualr foreachables transparently.
[22:50] isaacs: RayMorgan: nope.
[22:50] RayMorgan: I probably just don't understand what you mean
[22:51] deanlandolt: isaacs: exactly...and support the current jsgi api :D
[22:51] isaacs: RayMorgan: you can do it without buffering.
[22:51] isaacs: if it's a non-promise-style forEachable, like an array, then it'd require buffering.
[22:51] Booster has joined the channel
[22:51] isaacs: er, well, not really, even then
[22:51] isaacs: but it's less simple.
[22:52] deanlandolt: forEachables have some neat properties
[22:53] hassox: deanlandolt: like what... ?
[22:53] RayMorgan: Do you just push to that arrayish and it streams it until something like null is pushed? Or how do you denote the end of the stream?
[22:53] hassox: I'm not big on forcing somethign with little benefit because of a spec that was designed for sync requests
[22:53] hassox: RayMorgan: stream.close()
[22:54] RayMorgan: ok, I have no idea what a "promising foreachable" is then :)
[22:54] isaacs: RayMorgan: that's exactly why a first-class stream is a win, because you dont' have to think of it like an array
[22:54] RayMorgan: I agree
[22:55] isaacs: a "promising foreachable" is an object that returns a promise right away when you call forEach on it, and then does the iteration async, and then resolves the promise.
[22:55] RayMorgan: seems uch simpler
[22:55] RayMorgan: much*
[22:55] isaacs: i think so. but there are some use cases where it's not.
[22:55] hassox: isaacs: but aren't those use cases the exception rather than the rule?
[22:55] isaacs: i mean, to be fair to kriszyp_, promising foreachable has some definite advantages.
[22:55] hassox: like what?
[22:55] isaacs: hassox: well, depends on what you'er doing.
[22:55] isaacs: if you already have a wealth of jsgi stuff, it's less porting, for instance.
[22:56] isaacs: ^_^
[22:56] RayMorgan: so it has to branch depending on if the foreach returns a promise or not?
[22:56] hassox: bah
[22:56] hassox: that's not a good reason IMO
[22:56] isaacs: RayMorgan: but that's a solved problem.
[22:56] hassox: that's just technical debt
[22:56] RayMorgan: isaacs: the branching?
[22:56] isaacs: sure
[22:57] isaacs: function when (p, cb) { if (p instanceof Promise) p.addCallback(cb); else cb(p) }
[22:57] isaacs: when( something(), thenDoSomethingElse() )
[22:58] charlenopires has joined the channel
[23:00] ollie has joined the channel
[23:00] [k2] has joined the channel
[23:00] voodootikigod: oh i remember when this room got to a max of 20 people
[23:01] SlexAxton: the good ol days
[23:02] SlexAxton: back when these kids weren't ruining commonjs with their new fangled "APIs"
[23:02] RayMorgan: lol
[23:02] voodootikigod: hahahah
[23:02] voodootikigod: back when boys were boys and girls were boys
[23:02] voodootikigod: wait
[23:02] voodootikigod: wut
[23:03] mikeal has joined the channel
[23:03] voodootikigod: i just made everyone leave
[23:03] voodootikigod: win
[23:03] SlexAxton: back when ejsgi used "eof" instead of the spec'd "end" - ah the glory days
[23:04] SlexAxton: that may have been like 2 hours ago
[23:04] SlexAxton: but i lump it all in
[23:06] SlexAxton: all the people who are advanced have been doing jquery 3-12 months
[23:07] SlexAxton: thats actually false
[23:07] SlexAxton: but the last dude
[23:07] SlexAxton: thats true
[23:09] ericflo has joined the channel
[23:10] SlexAxton: totally wrong channel, apologies :(
[23:10] SlexAxton has left the channel
[23:22] stevestmartin has joined the channel
[23:29] devinus has joined the channel
[23:29] r11t has joined the channel
[23:31] stephenlb has joined the channel
[23:33] jfd has joined the channel
[23:33] sudoer has joined the channel
[23:33] ithinkihaveacat has joined the channel
[23:35] unomi has joined the channel
[23:39] tmpvar_ has joined the channel
[23:39] RayMorgan: deanlandolt: when you get a chance.. you mind pointing me to a simple example of an app using the promising foreachable model?
[23:40] deanlandolt: RayMorgan: gladly...porting jack now
[23:40] RayMorgan: cool, thanks
[23:40] deanlandolt: RayMorgan: but have a look at the relevant portion of jsgi-node: http://github.com/kriszyp/jsgi-node/blob/master/lib/jsgi-node.js#L153-161
[23:42] tmpvar has joined the channel
[23:45] eikke has joined the channel
[23:57] Tim_Smart has joined the channel
[23:59] konobi: ryah_away: ping