[00:04] aconran has joined the channel
[00:24] eddanger has joined the channel
[00:25] RayMorgan has joined the channel
[00:43] rtomayko has joined the channel
[01:12] kriskowal has joined the channel
[01:14] jtaby_ has joined the channel
[01:19] edds has left the channel
[01:36] rtomayko_ has joined the channel
[01:57] PowerToExt has joined the channel
[02:00] shfx has joined the channel
[02:13] Micheil: inimino: I hate to tell you, but I really hate your coding style ;P
[02:14] malkomalko: lol
[02:14] Micheil: brb
[02:19] Micheil has joined the channel
[02:28] dnolen has joined the channel
[02:31] Micheil has joined the channel
[02:35] soveran has joined the channel
[03:00] inimino: Micheil: I think it grows on you :)
[03:00] ciju__ has joined the channel
[03:05] malkomalko_ has joined the channel
[03:07] dnolen has joined the channel
[03:16] malkomalko_ has joined the channel
[03:41] jed has joined the channel
[04:06] Micheil: inimino: never! mwahahaha
[04:06] inimino: hehe
[04:07] jed has joined the channel
[04:24] Micheil: hmm.. http://nodejs.tweetwally.com/
[04:35] jtaby_ has joined the channel
[04:37] tlrobinson_ has joined the channel
[04:41] Micheil: moin tlrobinson
[04:48] jtaby_: hello world
[04:48] alexiskander: jtaby_: foo bar
[04:48] Micheil: jtaby_: hello
[04:48] jtaby_: baz quux?
[04:48] jtaby_: hi Micheil
[04:48] Micheil: quux unois?
[04:49] jtaby_: zot.
[04:50] jtaby_: 
ACTION is gonna try to implement a super rudimentary push server in node.js

[04:51] alexiskander: my dev computer is a Mac but my company's production servers are (unfortunately) Windows...
[04:52] alexiskander: should I forget about trying to use node.js, or, since I have C++ experience and experience with V8, should I try to port it?
[04:52] alexiskander: because I really, really like node.js
[04:52] alexiskander: :)
[04:52] inimino: alexiskander: sure, port it
[04:53] alexiskander: will it be very tricky, do you think? anything I should be aware of ahead of time?
[04:53] inimino: be a hero to all those poor troubled masses of Windows users out there
[04:54] inimino: ryah would be the one to ask about that
[04:54] alexiskander: I'll ask :)
[04:57] jtaby_: has anyone implemented a json push server in node.js?
[04:58] inimino: what's a push server?
[05:00] jtaby_: inimino: one client sends a message to the node.js server, it pushes it down automatically to another subscribed client
[05:01] inimino: jtaby_: ah
[05:01] jtaby_: inimino: know anything I can build off of/use?
[05:02] inimino: jtaby_: nothing comes to mind, but if you want to write something, the chat demo probably would get you started
[05:02] inimino: I haven't actually looked at the chat demo myself but I believe that's the sort of thing it does
[05:03] inimino: there may be something existing that's more full-featured, too
[05:03] jtaby_: the chat one would work...
[05:03] JoePeck has joined the channel
[05:04] inimino: jtaby_: also: http://wiki.github.com/ry/node
[05:04] jtaby_: inimino: thanks, trying it out
[05:11] Micheil: that's shameful.. ubuntu has gnutls of version 2.4.1, archlinux has 2.8
[05:11] Micheil: and node requires 2.5 >=
[05:18] mcarter has joined the channel
[05:21] alexiskander: I just realized that the design of my push server (that I will port to node.js, even if I _don't_ manage to get node.js on Windows)...
[05:21] alexiskander: would allow using _just_ the long polling portion or _just_ the dispatch portion or all of it together
[05:22] ryah: morning
[05:22] jtaby_: hey ryah
[05:22] jtaby_: you responsible for node.js?
[05:22] alexiskander: still got 40 minutes until morning here :)
[05:22] ryah: "responsible"? sounds so negative ;)
[05:22] jtaby_: haha
[05:23] jtaby_: just wanted to say, awesome job!
[05:23] alexiskander: indeed
[05:23] ryah: thanks
[05:23] jtaby_: i've been watching too much stargate. I feel like alexiskander and I came here from #sproutcore to forge an alliance
[05:23] alexiskander: jtaby_: :)
[05:24] ryah: :)
[05:24] alexiskander: ryah: I still can't figure out how to do things in bloody Twisted, but I figured out how to write a simple tester for my push server in node.js in a minute or two
[05:24] alexiskander: that means node.js is super cool.
[05:24] alexiskander: :)
[05:24] Micheil: moin ryah, and all others :)
[05:26] ryah: yeah, completely abstracting the event loop makes things easier to think about esp for js programmers
[05:26] ryah: s/makes/away makes/
[05:27] alexiskander: ryah: I was wondering, what might be involved in me porting node.js to Windows? At quick glance it seems like it could be pretty challenging (I have some experience with v8 and C++, but it seems like it needs more than that)
[05:27] Micheil: ryah: is session / cookie management on the wishlist for node's community?
[05:27] alexiskander: (our production servers are, unfortunately, Windows)
[05:28] Micheil: alexiskander: I could guess and say that POSIX is the only thing stopping node from working on windows
[05:29] ryah: alexiskander: definitely you will need some c++ - probably not v8. "challenging" would depend on your experience porting software from linux to windows. there arn't any *massive* hurdles to jump, but it will not be trivial.
[05:29] alexiskander: no experience porting linux->windows; mostly experience creating things to run _both_ on Unix (Mac) and Windows
[05:29] alexiskander: probably a bit beyond what I have experience with, I would guess...
[05:30] alexiskander: I'll use node.js anyway; maybe we can even run it in production on our one linux server...
[05:30] ryah: so, i think if i had a windows machine and a real desire to do this immediately it would take myself 40-80 hours
[05:31] alexiskander: ryah: I'll see... I might give it a shot, but I kinda think it might be "above my pay-grade," so-to-speak :)
[05:32] alexiskander: things like threads, etc., I've never used from C/C++ before
[05:32] ryah: that sort of thing won't be the problem - i've been careful not to put anything really unix-y in there
[05:32] alexiskander: what might be the issue?
[05:32] ryah: process.memoryUsage() would be the one really platform dependent function
[05:33] alexiskander: what about the dependencies? Do they all have versions for Windows?
[05:33] ryah: well - all the libraries i use, yes. my own code no - but that also shouldn't be so hard to port.
[05:34] ryah: i think it might be better to wait on this for a few weeks. i'm going to be refactoring some parts which will present a smaller c++ code base
[05:34] alexiskander: ok
[05:34] alexiskander: no problem
[05:34] alexiskander: I should probably get used to node first anyway :)
[05:35] kriskowal has joined the channel
[05:36] alexiskander: I'm getting all excited. Going to try to port Dobby (my messaging system w/a long polling server) tomorrow
[05:50] ryah: can you use "arguments" with call() ?
[05:50] ryah: myfunc.call(arguments) 
[05:50] alexiskander: myfunc.call(context, arg1, arg2, arg3)
[05:50] alexiskander: myfunc.apply(context, arguments)
[05:50] alexiskander: ?
[05:50] ryah: "arguments" being the special variable 
[05:50] alexiskander: ah. Good question.
[05:51] jed: ryah: yes, you can.
[05:51] alexiskander: No idea :(
[05:51] jed: people do this all the time with Array.prototype.slice.call( arguments )
[05:51] ryah: jed: with call() or only with apply()?
[05:51] jed: to make it a normal array.
[05:51] jed: with call.
[05:51] jed: it doesn't really matter.
[05:51] jed: "this" is just another argument, really.
[05:51] ryah: okay
[05:51] jed: ryah: you can use it with both.
[05:53] ryah: jed: ah, that's how you make an array from arguments - cool
[05:53] jed: yep. you can use all of the array methods on any object with a numeric length property.
[05:54] jed: jQuery makes extensive use of that for their custom object.
[05:55] alexiskander: 
ACTION files that away for future reference

[05:56] erikg: i'm writing a secure module loader which treats any javascript source file as a module.  it uses an iframe for sandboxing.
[05:56] erikg: i figure out which objects the source file creates in the new iframe, then pull out references to these.
[05:57] erikg: i want to cleanup the iframe (perhaps it's not necassary, but i feel i don't understand what's going on unless i can clean it up)
[05:57] inimino: spidermonkey also supports Array.slice
[05:58] inimino: (v8 doesn't however)
[05:58] erikg: but destroying the iframe seems to destroy the lookup chain that lets objects in that context refer to each other.  i was curious if anyone here had experience with this.
[05:58] erikg: s/objects in that context/objects created in that context/
[06:03] erikg: the goal is to integrate this into something like run.js for async, secure (as in non-polluting) script loading.
[06:07] inimino: hm
[06:07] erikg: i haven't tested but my guess is that the iframes are heavyweight objects
[06:08] inimino: well, it contains a Document, so yes, pretty heavy
[06:09] inimino: and a window
[06:09] erikg: inimino: i'll show you the code, one second
[06:10] inimino: but the behavior you describe seems odd
[06:10] inimino: ok
[06:11] erikg: inimino: i think you need to see what i'm doing, it's not a lot but it might explain the oddity
[06:11] erikg: http://hypervolu.me/~erik/iload/iload.js
[06:12] Bluebie has joined the channel
[06:12] erikg: you can run it @ http://hypervolu.me/~erik/iload/iload.html
[06:12] erikg: using something like firebug to debug it
[06:13] erikg: it will work fine unless you uncomment the line: document.body.removeChild(iframe);
[06:14] erikg: it just feels like i'm missing something very obvious about the language
[06:16] kriskowal has joined the channel
[06:16] jed: it makes sense to me that you'd lose the context if you remove the iframe.
[06:17] jed: why do you need to remove it? would it make sense to keep it around until you "unload" the module?
[06:18] erikg: jed: right, maybe i just need to check how heavyweight the approach is before worrying about it
[06:19] inimino: hm
[06:19] inimino: it doesn't actually make sense to me that that would happen
[06:19] erikg: it seems strange, but it's also a strange thing to do
[06:20] erikg: jed: there could be some benefits to leaving the context.  if a called function of the module modifies builtin methods or global scope the effects remain sandboxed but the code also remains usable.
[06:20] inimino: but there are many subtleties in how browsers deal with global objects that I don't know
[06:20] erikg: jed:  i haven't tested that tho
[06:21] erikg: inimino: i know... my goal was to only deal with these subtleties at load time
[06:21] erikg: none of the examples of this kind of sandboxing i've found handle the migration of objects.  they just keep the sandbox around until it's not needed anymore.
[06:22] inimino: well, unless you know it's a problem I would not destroy the window while the code is in use
[06:22] erikg: yeah
[06:22] inimino: the thing that's surprising to me is that it would be removed, and not kept around by the remaining references to it
[06:22] erikg: the more i think about it the more there seem to be benefits to retaining the sandbox
[06:22] erikg: inimino: ahh, i see
[06:23] inimino: in other words, I'd expect that line to have no effect on memory usage or functionality
[06:23] jed: erikg: (also, one thing i've found is that you can simplify the special case load issues across browsers by putting another inline script in your document.write() that calls your init function)
[06:23] erikg: jed: right on
[06:23] erikg: i'll try that out
[06:23] erikg: i'm actually setting up a virtual machine to run window$ browsers now
[06:24] jed: erikg: safari in particular ignores onload for written frames sometimes, IIRC.
[06:24] erikg: jed: hm.. okay maybe i'm not understanding.
[06:25] inimino: the onload event as you're using it now isn't very reliable
[06:25] erikg: jed: well, i get that part.  but what exactly would the init function refer to?
[06:25] jed: erikg: onScriptLoad, in this case.
[06:25] jed: erikg: basically, <body><script>parent.init()</script><body> is more reliable than load events.
[06:25] erikg: interesting
[06:26] erikg: so parent.onScriptLoad or however i access it
[06:26] jed: erikg: right.
[06:26] erikg: i found that creating the script object and setting attributes on it worked within the main document but failed within iframes
[06:27] erikg: (again i've only been testing on ff)
[06:27] erikg: this annoys the hell out of me because i can't set the object up first, *then* register the callback to handle the load event, and *then* appendChild it into the iframe's document
[06:27] erikg: so i had to use write
[06:27] jed: i think you'd need to use importNode for that anyway.
[06:28] jed: you can't appendChild across documents reliably, i think.
[06:28] erikg: ahhh...
[06:28] jed: but as long as your serializing for document write anyway, you can just write it anyway.
[06:29] erikg: well, it seemed to not work even when i created the node via iframe.document.createElement('script')
[06:29] erikg: so i'm not sure.  this is murky territory
[06:29] jed: erikg: well, that wouldn't work because you're missing some stuff.
[06:30] erikg: jed: such as?
[06:30] jed: you'd need: iframe.contentWindow.document.createElement("script")
[06:30] jed: the iframe itself is in the parent window.
[06:30] jed: the contentWindow property refers to its window.
[06:30] jed: erikg: does that make sense?
[06:30] erikg: ah
[06:31] erikg: 
ACTION pokes around

[06:31] jed: reading the source code for jQuery or other frameworks is a good place to learn about this stuff.
[06:32] erikg: jed: thanks for the tip, that's a good idea
[06:32] erikg: i'd been meaning to do exactly that for some time
[06:32] jed: erikg: np. i know how much of a PITA this is.
[06:32] ciju has joined the channel
[06:34] jed: erikg: one more trick i like: if you need to run an init function in the child frame, define the function in the parent frame, and then write your doc like this: "<body><script>(" + myFunc + ")()</script></body>"
[06:34] jed: since toString on a function returns its source.
[06:34] erikg: that is a good trick!
[06:35] jed: i've wasted days of my life on iframe hackery, alas.
[06:36] erikg: and i have wasted at least one, thanks again for the tips
[06:36] erikg: maybe i'll not waste too many more
[06:37] jed: erikg: ha ha, np. good luck on your sandbox. don't forget to check the dean edwards approach too.
[06:37] erikg: jed: that's been my start
[06:37] jed: erikg: i figgered as much.
[06:37] erikg: running into his first blog posts about it triggered an 'aha'
[06:37] jed: erikg: it's a good start.
[06:37] erikg: jed: yup.
[06:38] erikg: jed: i don't know why this avenue hasn't been explored very deeply as a foundation for module loading, because it seems ideal to be able to work within a clean context...
[06:38] jed: erikg: also this: http://webreflection.blogspot.com/2009/07/elsewhere-sandboxes-have-never-been.html
[06:38] jed: erikg: i think it feels to hacky for a lot of people.
[06:39] erikg: jed: it is and will be until people start using it and the runtimes clarify it
[06:40] jed: erikg: true that.
[06:40] inimino: it is rather hacky
[06:40] inimino: more likely the runtimes are going to tell you to use Web Workers instead :)
[06:40] erikg: inimino: any sandbox that works will be sufficient
[06:41] inimino: iframe behavior is incredibly baroque and lots of it is locked down because of legacy reasons and security concerns
[06:41] erikg: yup...
[06:42] erikg: i want to set the precendent that code can be secured by the runtime instead of forcing code to be secured by programmers.
[06:43] inimino: hm...
[06:43] erikg: i guess that could be confusing
[06:44] alexiskander has joined the channel
[06:44] erikg: reusable code should be secure and bug-free.  i'm talking about namespaces.
[06:45] inimino: ok
[06:45] inimino: I don't think iframes will ever be a great solution to that because of things like instanceof breakage
[06:45] erikg: inimino: i don't understand that case
[06:46] inimino: but it is one approach
[06:46] erikg: oh, i see what you mean...
[06:47] erikg: gah
[06:47] inimino: all the top-level objects are different, so indexof doesn't work any more
[06:48] erikg: instanceof
[06:48] inimino: if your module returns myFoo.array = [], now myFoo.array instanceof Array == false
[06:48] inimino: of course if it's only tested by the module that created it it's fine
[06:49] inimino: er, yeah, instanceof
[06:50] inimino: fortunately instanceof is rarely used
[06:50] erikg: inimino: thanks for pointing that out
[06:51] ryah: inimino: how do you test if something is an exception?
[06:52] ryah: i was thinking "x instanceof Error" ?
[06:52] ryah: or is that fragile?
[06:52] inimino: it's not really fragile
[06:53] inimino: actually I use instanceof quite a bit with Error and Promise and such things
[06:53] inimino: things like cross-iframe stuff will break it but I think it's the cross-iframe stuff that is the problem in that case
[06:55] erikg: yup...
[06:56] inimino: though I tend to prefer a more explicit approach; there are very few cases where I'm writing code that doesn't already know the type of its arguments
[07:13] jtaby__ has joined the channel
[07:13] Micheil: ryah: do you know of any work to bring sqlite to node?
[07:14] Micheil: ryah: also, do you know of anywork on an ORM for node?
[07:16] ryah: no. i think fictorial is working on a redis-object mapping
[07:17] Micheil: hmm..
[07:18] Micheil: it'd be good if we could consilidate efforts into producing one ORM library which supports backends to multiple databases, eg, sqlite, progres, and mysql
[07:20] ryah: it's too early for that, imo
[07:20] ryah: at the moment there is only very primitive support for postgres
[07:20] Bluebie: yup :)
[07:21] Micheil: hmm..
[07:21] Bluebie: still, if you can be bothered, a lot of situations can be adequately or even superiorly served via the use of flat files
[07:21] Bluebie: and there are some kinds of databases which can be accessed and controlled via restful http requests
[07:21] Micheil: Bluebie: true that, although, flatfiles I think may require more disk I/O then databases
[07:22] Micheil: Bluebie: yeah, like couchdb
[07:22] Bluebie: well, all databases in the end do store their content in a flat file
[07:22] Bluebie: and node is just as persistent as any database software
[07:23] Bluebie: hence the if you can be bothered qualifier. Some apps benefit a lot from caches, and some benefit more from custom designed app specific caches
[07:23] Bluebie: some applications, like one i'm working on, gains nothing from caching anything, except perhaps some static images and html files
[07:26] Micheil: Bluebie: I'm mainly just looking for a stable database for an app I'm wanting to work on
[07:26] Bluebie: what would it benefit from? :)
[07:26] Micheil: just for the ease of storage and searching
[07:26] Bluebie: ah
[07:27] Micheil: if I used flat-file, I couldn't easily have things that are relational
[07:27] Micheil: I was looking at redis, but then realised that the amount of overhead to make it relational wasn't really worth it
[07:27] ryah: Micheil: well, support is coming- it's just going to take me some weeks
[07:28] Micheil: ryah: okay
[07:28] Bluebie: yeah, sounds like a job for sql :)
[07:28] ryah: maybe not sqlite - but mysql and better postgres
[07:29] Micheil: ryah: I would've thought sqlite would be fairly easy to implement, as there's already implementations in platforms like the mozilla platform
[07:29] Bluebie: I'd like to have sqlite present
[07:29] ryah: Micheil: maybe - i haven't looked into it
[07:29] Micheil: plus sqlite is a lot more portable then mysql or postgres
[07:29] ryah: apparently there is an async interface
[07:30] Bluebie: I believe webkit also makes use of it to back the web databases implementation
[07:30] Micheil: Bluebie: that's true
[07:30] Bluebie: sqlite is great for lots of things, from prototyping to small apps, making it really easy to pull down a copy of your live database and investigate bugs locally and the likes
[07:31] rakeshpai has joined the channel
[07:31] Bluebie: with node being such a great platform for screwing about with exotic kinds of http, and other tcp-based protocols, sqlite really would serve the needs of a lot of experimentation, and if everything uses a common interface (web databases html5 spec?) we could just switch over to some big networked stand alone database if we need the scalability later
[07:33] Micheil: Bluebie: that's sorta where I'm coming at when I said the introduction of some form of ORM
[07:33] ryah: Bluebie: you should try to write a binding
[07:33] Micheil: if you make a standard way for interacting with a database now, then you can easily swap in and out databases
[07:33] Micheil: I'd happily try and write such an ORM, but I've not do heaps as far as databases go
[07:34] inimino: ryah: any plans on getting other methods back in the HTTP parser?
[07:34] Micheil: Bluebie: if it's of any help, I can do a bit of mozilla hacking
[07:35] Bluebie: ryah: I'm hopeless in C/C++
[07:36] Micheil: 
ACTION can only just read C/C++

[07:36] Bluebie: if I were any good at it, I would have tried to make something like node ages ago :P
[07:36] inimino: Bluebie: I agree that SQLite would be a nice fit with node for those who want some kind of SQL database
[07:37] Micheil: this might help out anyone wanting to write a SQLite binding: http://mxr.mozilla.org/firefox/source/extensions/sql/sqlite/src/mozSqlConnectionSqlite.cpp
[07:37] Bluebie: I'd like to see a simple key/value db included too, with an api such that you could set 'sessionStorage = thingo.blah.beep.foo' and have compatibility with the html5 implementation
[07:37] Micheil: Bluebie: hmm.. why do you use sessionStorage there?
[07:38] Bluebie: I imagine the sqlite bindings in chromium or webkit would be far more relevant than mozilla cruft
[07:38] Micheil: Bluebie: probably
[07:38] Bluebie: sessionStorage is the name of one of the key/value databases available in modern browsers
[07:38] Micheil: Bluebie: although, sqlite is the internal storage engine for the mozilla platform
[07:38] Bluebie: makes for code compatibility with stuff designed for the browser
[07:39] Micheil: inimino: based on what Bluebie just said, we should probably make sessionStorage as a reserved word not to use in the sessionManager stuff
[07:39] Bluebie: it's a lovely little place to shove data. In the browser it can easily handle millions of entries, and gives you 5mb to use without user prompting to increase the store size
[07:39] Bluebie: someone's been naming random junk sessionStorage? :S
[07:39] Micheil: http://github.com/mediacoder/node-sessions/commit/a37fb49b7494d7d434e51518045bd15fd3d45e28
[07:40] inimino: Micheil: I don't think it's exposed in the API I have
[07:40] Micheil: Bluebie: yes, sorta, for Session Management
[07:40] inimino: (or indeed used anywhere)
[07:40] Bluebie: yes, sessionStorage and localStorage mean very specific _local_ things in the browser..
[07:40] Micheil: inimino: I'm going to do a little more working on it
[07:40] Micheil: inimino: I'm not sure I'm keen on the direction mediacoder's taking some parts
[07:41] Bluebie: might make sense if you back the sessions with some sort of crude key/value database (rather than just marshalled objects..) but really i'd prefer that to be an app specific database than a user specific database, as it just feels most correct to me
[07:41] inimino: oh, mediacoder has it I see
[07:41] inimino: but not as a top-level name, so that's probably fine
[07:41] Micheil: although, he does show some interesting stuff
[07:41] Bluebie: ah yes, so long as things are namespaced away :)
[07:41] Micheil: Bluebie: currently mine is key/value in that: key == SID, value == {sid, data, expires}
[07:42] inimino: Micheil: haven't looked at his in a few days
[07:42] Micheil: inimino: same
[07:42] Bluebie: oh, is this a signed cookie based session storage?
[07:42] Micheil: Bluebie: yeah
[07:42] Micheil: Bluebie: mainly for auth purposes
[07:43] Bluebie: I think those sorts of things should always be off by default too, so users need to go read some docs, and understand quite deeply that data they put in there will not remain secret to the user
[07:43] Micheil: inimino: mediacoder has also proposed that the Session instance manages it's cleanup
[07:43] jed has joined the channel
[07:43] Bluebie: But otherwise, yeah, it's a great way to do auth. It's how Yahoo handles it. Scales well. :)
[07:43] isaacs has joined the channel
[07:44] Micheil: Bluebie: umm.. it's a randomly generated key, and then we just look up the key in an object, to retrieve or set data
[07:44] inimino: yeah I saw something about that... don't really understand why, though
[07:44] inimino: Micheil: the single timeout running at a time approach I have seems to work fine for me
[07:44] Micheil: Bluebie: anything like auth you'd need to write, this just handles the CRUD part of sessions
[07:44] Micheil: inimino: I'm wondering whether an interval timer would be better?
[07:45] Bluebie: well, if you're just, say, JSON.stringify()ing your session object, and signing it, and maybe base64 encoding it, nothing stops the user from looking at their document.cookie and decoding it, and seeing all it's innards
[07:45] inimino: 
ACTION will probably do some light auth next

[07:45] ryah: inimino: will you be satisfied if i add webdav methods?:
[07:45] Bluebie: it is not at all cryptographically hidden, it's only cryptographically signed, which are very very different things
[07:45] Bluebie: the user can't change the data in the session, but they can certainly see it
[07:45] Micheil: Bluebie: nup, different stuff here, all the data stays on the server, the only thing that goes out is the session key
[07:45] Bluebie: oh, right, okay
[07:46] inimino: ryah: it would help, but I wouldn't really be happy
[07:46] inimino: ryah: for example I was considering adding a BRANCH which isn't in WebDAV either
[07:46] ryah: http shouldn't be extended like that
[07:46] inimino: ryah: (and I don't really like lots of WebDAV)
[07:46] Micheil: ryah: is there any news on setHeader or addCookie methods?
[07:46] ryah: webdav methods should never have been added
[07:47] Micheil: or something?
[07:47] inimino: ryah: maybe, matter of opinion I suppose
[07:47] ryah: Micheil: no?
[07:47] Micheil: ryah: okay
[07:47] Bluebie: why shouldn't http be extended arbitrarily? we do it with everything else..
[07:48] inimino: heh
[07:48] Bluebie: if some custom method ends up conflicting with webdav, well, that website can't use webdav, doesn't really affect the rest of the world?
[07:48] ryah: Bluebie: because it makes people who write parsers mad
[07:48] inimino: hehe
[07:48] Bluebie: how hard is it to parse 'everything till the first space'?
[07:49] inimino: ryah: as it stands now you can't even implement a compliant HTTP 1.1 server since the request is just dropped on the floor
[07:49] ryah: not hard - but adds a few unnessary extra instructions
[07:49] Micheil: inimino: do you have a working cleanup routine for session storage?
[07:50] inimino: ryah: I spent at least a half hour scratching my head over Wireshark dumps before I figured out what was going on...
[07:50] inimino: Micheil: yes, the one in my current repo seems to work fine
[07:50] Micheil: okay
[07:50] inimino: Micheil: http://boshi.inimino.org/3box/sessions/
[07:50] ryah: inimino: okay - well i guess that's not good. 
[07:51] ryah: inimino: but what method was it dieing on?
[07:51] inimino: ryah: MOVE, which is one of the WebDAV methods, but...
[07:51] ryah: i'm willing to add real life methods - but i really don't want to add arbitrary methods
[07:52] ryah: (even though http allows extension methods)
[07:52] inimino: right
[07:52] inimino: and it says if the server and client both agree on what they mean, then it can use them
[07:52] Bluebie: 
ACTION 's mind is boggled that 'everything till the first space' is more compuationally intensive than matching against a list of possibilities

[07:53] inimino: Bluebie: well, you can get a little bit of extra efficiency out of it, because you know which character to test for first and stuff
[07:53] ryah: Bluebie: there is no avoiding matching against a list of possibilities - if not in the parser then at some point you do method == "GET"
[07:53] ryah: which checks each char
[07:54] Bluebie: != ' ' doesn't work just as well?
[07:54] Bluebie: why's that? Many apps don't care if you get or post..
[07:54] Micheil: ...ATB is definitely some music I could listen to while coding...
[07:54] ryah: Bluebie: "many" ?
[07:54] Bluebie: are we actually required to support stuff like 'head'?
[07:54] Bluebie: just about everything built on PHP for example..
[07:55] inimino: heh
[07:55] inimino: Bluebie: yes, HEAD is required
[07:55] inimino: well, lots of PHP apps are a little broken, I don't know how many are /that/ broken
[07:55] ryah: node's http server is missing support for head
[07:55] Micheil: inimino: also, I'm probably going to change the SID = an MD5 of the creation time + session number
[07:55] Micheil: inimino: or something
[07:56] inimino: yeah HEAD needs to be dealt with eventually too, I'm not sure it requires any special support from node though
[07:56] ryah: node needs to not send the body :)
[07:56] inimino: it could just be something that a webserver package/module/whatever deals with
[07:56] ryah: it could - i think the server can just ignore sendBody() 
[07:56] ryah: it's easy enough and insures the proper behavior
[07:57] inimino: Micheil: hm, what for?
[07:57] ryah: ensures even
[07:57] inimino: ryah: true
[07:58] inimino: ryah: so you'd just send HEAD to the app and ignore resp.sendBody() calls?
[07:58] inimino: erm
[07:58] inimino: set GET to the app
[07:59] inimino: s/set/send/
[07:59] inimino: 
ACTION sighs

[07:59] inimino: I don't remember what Apache does...
[07:59] ryah: what?
[07:59] ryah: no, i'd send HEAD to the app - maybe they can cut processing
[08:00] inimino: ok, good, that's better
[08:01] jtaby__: omfg
[08:01] jtaby__: node.js is the shit!
[08:02] inimino: and if someone is in a hurry, HEAD can just be "do what you would do for GET" and the sendBody() calls will be ignored?
[08:03] ryah: right
[08:03] ryah: want to implemnt it?
[08:03] ryah: :)
[08:03] ryah: i'll do you webdav today if you do the head thing :)
[08:03] jtaby__: what does "fu" stand for in the chat demo?
[08:04] jtaby__: is it an acronymn or a ninja term?
[08:04] inimino: with WebDAV I can get on HEAD again, which would be nice ;)
[08:04] ryah: jtaby__: it's my super crappy "framework"
[08:04] jtaby__: hah
[08:04] ryah: jtaby__: i couldn't think of another name
[08:04] inimino: heh
[08:04] jtaby__: ryah: the fu.get lines basically setup responders to GET requests, am I correct?
[08:04] ryah: yes
[08:04] jtaby__: sweet
[08:05] inimino: alright, I'll do the HEAD thing tomorrow
[08:06] inimino: 
ACTION looks at clock

[08:06] inimino: correction: later today
[08:07] inimino: nn
[08:07] ryah: ^^
[08:08] Micheil: is there anything like sys.puts which places the current time + data to command line?
[08:08] Micheil: or SDOUT
[08:10] ryah: no 
[08:10] Micheil: okay
[08:10] Micheil: 
ACTION writes something to do that

[08:27] Micheil: hmm.. whoops: 06/11/2009 19:26:16:0082	--- Checking: QYIYIUIUc0s8sE4oQAEUswAA: -102024
[08:27] Micheil: the last value is the time until it should be removed
[08:47] cmlenz has joined the channel
[08:50] the_undefined has joined the channel
[08:51] ryah: europe is waking up
[08:52] malkomalko: maybe
[08:53] Bluebie: we need to take their euros
[08:53] Bluebie: why, if I had a euro, I could buy a house!
[08:53] Bluebie: 
ACTION slightly exaggerates

[08:54] malkomalko: heh
[08:57] malkomalko: I love passing out on the couch
[09:00] Yuffster has joined the channel
[09:06] dnolen has joined the channel
[09:10] Micheil: O.o
[09:10] Micheil: I have an object with undefined length..
[09:23] keeto has joined the channel
[09:30] the_undefined has joined the channel
[09:40] ryah: getting closer to removing a big chunk of c++
[09:44] the_undefined: ryah: nice : )
[09:45] Bluebie: Ryah The Exorcist :P
[09:47] ryah: sync file i/o too :O
[09:48] Bluebie: it seems amazing to me that modern unix operating systems don't have good ways to do file/network IO in async ways
[09:49] Bluebie: from a very uneducated outsider point of view, it seems like it wouldn't have to be any more complex than letting you disable blocking in exchange for getting a signal sent to your process whenever something new happens, to trigger a select on the stuff you've got
[09:50] Bluebie: especially for linux, used on so many servers..
[09:52] CIA-28: node: 03Ryan Dahl 07master * r4845283 10/ src/node.cc : Clean up context creation - http://bit.ly/80rKE6
[09:52] CIA-28: node: 03Ryan Dahl 07master * r90ab079 10/ (Makefile configure): 
[09:52] CIA-28: node: Use --jobs=1 with WAF
[09:52] CIA-28: node: Some people were reporting waf erroring with
[09:52] CIA-28: node:  thread.error: can't start new thread
[09:52] CIA-28: node: this seems to fix that problem. - http://bit.ly/88j0r6
[09:52] CIA-28: node: 03Ryan Dahl 07master * r8141448 10/ (4 files in 3 dirs): Don't use promises internally in DNS module - http://bit.ly/4MS7wH
[09:52] CIA-28: node: 03Ryan Dahl 07master * r3414eab 10/ (src/node.js src/node_file.cc src/node_file.h lib/posix.js): (log message trimmed)
[09:53] CIA-28: node: Refactor node_file.cc to not use Promises.
[09:53] CIA-28: node: At the same time implement synchronous wrappers of the POSIX functions.
[09:53] CIA-28: node: These will be undocumented until we settle on an API. Works like this
[09:53] CIA-28: node:  // returns promise as before
[09:53] CIA-28: node:  posix.mkdir("test").addCallback(function () {
[09:53] CIA-28: node:  sys.puts("done");
[09:56] the_undefined: ryah: looks cool
[09:57] the_undefined: very nice to see the posix stuff in JS
[09:58] ryah: yeah, so that was the last c++ usage of promise
[09:59] ryah: the next step is to implement promise in js now
[10:00] ryah: then getting better binary, then implementing evcom in js too
[10:04] malkomalko: should the speed of the posix stuff be comparable to the c++ implementation?
[10:04] malkomalko: won't really change it much I don't think
[10:05] ryah: no, i don't think it will change much
[10:05] malkomalko: I'm going to release my filesystem database for node sometime today
[10:06] malkomalko: gonna need to update it soon I guess heh :)
[10:06] ryah: malkomalko: api didn't change in these updates
[10:07] jtaby_ has joined the channel
[10:07] malkomalko: right, I imagine they will somewhat, not really worried about it
[10:07] malkomalko: why am I up right now?
[10:07] jtaby_: hey, so far my experience with node.js has been a breeze...but, I can't figure out how to "hold" a connection until data is available..
[10:08] jtaby_: I'm looking at the chat demo
[10:09] Bluebie: well you need to keep a reference to it somewhere, I expect
[10:09] jtaby_: ah one sec, I misread the demo
[10:09] Bluebie: put it in some sort of object or variable or something for safe keeping..
[10:35] CIA-28: node: 03Ryan Dahl 07master * r4d818f1 10/ (5 files in 2 dirs): Implement promises entirely in JS - http://bit.ly/8owgHo
[10:45] Micheil: ryah: isn't promise pretty much a pub/sub event queue or something?
[10:45] ryah: em.. 
[10:45] ryah: no?
[10:45] Bluebie: O_o
[10:45] Micheil: erm, true, misread / misexplained
[10:46] ryah: git diff --shortstat $(git rev-list -1 --until="5 hours ago" HEAD) 14 files changed, 647 insertions(+), 595 deletions(-)
[10:46] rakeshpai: ryah: Congrats on moving to JS for promises
[10:46] pdelgallego has joined the channel
[10:48] ryah: cloth 0 ~/projects/node > git diff --shortstat $(git rev-list -1 --until="5 hours ago" HEAD) -- src/*.{cc,h} 6 files changed, 288 insertions(+), 454 deletions(-)
[10:48] rakeshpai: ryah: can we start implementing deferreds on top of promises now? ;)
[10:48] ryah: shit
[10:48] ryah: i want promises changed to act like deferreds :)
[10:49] rakeshpai: ryah: ah... now that I like :)
[10:50] rakeshpai: there was some concern in the room yesterday that it might a little expensive, because of the book-keeping we have to do on both adding handlers and triggering the event
[10:50] ryah: http://gist.github.com/250158
[10:50] rakeshpai: what do you think?
[10:50] ryah: i think it won't be noticable
[10:51] rakeshpai: then there was the thought that it's still too high-level for node, and that node should just give a CPS api
[10:51] Micheil: ryah: what's cloth do?
[10:52] ryah: it's the name of my computer
[10:52] ryah: that's just the prompt
[10:52] kriskowal has joined the channel
[10:52] Micheil: oh
[10:52] Micheil: ryah: it looks like a unix pipe command
[10:54] Micheil: ryah: btw, have you thought of using the dojo mixin over the jquery one?
[10:54] ryah: no whats the difference?
[10:55] johan-s has joined the channel
[10:56] Micheil: erm, it was a little lighter I thought
[10:58] ryah: well if it's lighter and mit-licensed then sure 
[10:59] Micheil: ryah: I think I have a better mixin used in a siude project of mine though, although, I don't have heaps of testcases for it
[11:03] Micheil: mixin({test: "test", b:"b"}, {a: "a", b: "c"}) => {test: "test", b: "b", a: "a"};
[11:03] Micheil: yeah?
[11:04] Micheil: no
[11:06] rakeshpai: ryah: where can I look at code for the promises... it should be in js now, right? let me try seeing how easy/hard it'll be to implement deferreds
[11:06] rakeshpai: lib doesn't seem to have it
[11:08] Micheil: ryah: I bit of a lighter mixin (which auto recurses), http://gist.github.com/250165
[11:10] rakeshpai: hmm... never come across a mixin that recurses
[11:10] Micheil: rakeshpai: technically it's an extend, but for namesake, will call it mixin
[11:10] Micheil: traditionally mixin doesn't recurse
[11:12] rakeshpai: ryah: you there? where's the code for promises? I can look at it if it's all js, and try to make it behave like deferreds
[11:14] Micheil: rakeshpai:  it's all in js, I've just been looking at it
[11:14] Micheil: src/node.js
[11:14] ryah: rakeshpai: http://github.com/ry/node/blob/4d818f1fd3454f972ef6e0a4f32ed26585804dd5/src/node.js#L192-338
[11:14] rakeshpai: ah... thanks
[11:19] Micheil: ryah: yeah, pretty much the only thing mine lacks is the test suites
[11:19] Micheil: although, a lot of jquery stuff is written to be using the absolute lowest possible use case
[11:20] Micheil: as far as basic object mixing goes, it'd be fine.
[11:22] CIA-28: node: 03Xavier Shay 07master * r34c0235 10/ (lib/sys.js test/mjsunit/test-sys.js): 
[11:22] CIA-28: node: sys.inspect is totally more awesome now
[11:22] CIA-28: node: - No longer relies on JSON.stringify, so it can output nulls and functions
[11:22] CIA-28: node: - Handles circular references better
[11:22] CIA-28: node: - Has tests - http://bit.ly/7wAhkF
[11:24] ryah: almost ready for a new release
[11:24] ryah: i'll wait to see if anyone complains about the most recent changes
[11:25] Micheil: ryah: nice stuff
[11:25] Micheil: ryah: I'll have to run another build soon then
[11:26] malkomalko: lol
[11:26] Micheil: ryah: btw, dojo doc comments are way better then the jsdoc or phpdoc ones ;P
[11:27] ryah: Micheil: i'm hardly doing comments anywhere - just copied those out of v8
[11:27] Micheil: heh
[11:27] ryah: mostly because the doc parsers can't understand my code
[11:27] rakeshpai: 
ACTION wonders that with all the dojo love here, should we just port dojo over to node ;)

[11:27] Micheil: ryah: not only that, but Uxebu consulting have made a pretty awesome doc viewer for the dojo docs
[11:28] Micheil: rakeshpai: why would you want to port dojo to node, there's not much gain
[11:28] Micheil: node has similar to what dojo already has
[11:28] rakeshpai: I guess... I was just kidding anyway
[11:28] Micheil: :P
[11:29] Micheil: rakeshpai: then again, I'm an odd ball. past jquery UI dev, now a dojo dev
[11:30] Micheil: (well, wannabe dojo dev, anyway)
[11:30] rakeshpai: actually, on second thoughts, I think dojo is higher level than node... node is definitely lower level
[11:30] Micheil: not really
[11:31] rakeshpai: Micheil: interesting - why did you move away from jquery UI dev work?
[11:31] Micheil: ryah: also, supposedly switch/case/default's are slow.
[11:31] Micheil: rakeshpai: purely because they'd change API's and then you'd have to rewrite code heaps
[11:32] Micheil: rakeshpai: by jquery UI dev, I mean, prior to the first release
[11:32] ryah: Micheil: shurg. i wait for things to show up in profiles
[11:32] rakeshpai: Micheil: ah... ok... have the apis stabilized now? do you know?
[11:32] Micheil: rakeshpai: yeah, they stabilized a while back, but I still think jquery UI is a rather unpolished solution, but that's just me
[11:33] Micheil: rakeshpai: I prefer the require/provide/declare nature of dojo, it feels much nicer
[11:33] rakeshpai: I know... I'm in love with dojo anyway :)
[11:38] jtaby__ has joined the channel
[11:38] Micheil: that is terribly odd.. one of my sys.puts doesn't fire, but it carries out the other functions in the loop
[11:38] the_undefined: ryah: the new promise implementation is very very interesting, cool stuff
[11:39] Bluebie: what's the new implementation do?
[11:40] the_undefined: Bluebie: promises are now entirely in JS, even the co-routine / wait stuff
[11:41] Bluebie: ooh neat
[11:41] Bluebie: I didn't know the wait thing could be done in pure js?
[11:42] Micheil: okay, that makes no sense.
[11:42] the_undefined: Bluebie: it uses process.loop() / unloop() which until now I wasn't quite sure what those were doing. 
[11:42] Micheil: at no point am I deleting an item out of an object, yet the items are disappearing
[11:43] Bluebie: ooh o_o
[11:43] the_undefined: Micheil: can you whip up a test case?
[11:44] Micheil: the_undefined: sorta
[11:44] Micheil: http://gist.github.com/250176
[11:44] the_undefined: I have to do some work in windows right now so I'm looking for a good procrastination opportunity
[11:44] jtaby__: Hey, I'm trying to make a single object through with I interact
[11:44] jtaby__: http://pastie.org/730182
[11:45] Micheil: nowhere in that code do I call an external function, other then size() and nowhere do I call a delete style method
[11:45] jtaby__: when I do var SN = require('./sprout_node'); SN.createServer().listen(); and try to run, it says: TypeError: Object #<an Object> has no method 'createServer'
[11:45] the_undefined: Micheil: uh, I was hoping for something more decoupled
[11:46] Micheil: the_undefined: heh
[11:46] Micheil: the_undefined: try reloading the gist, I've put in the shell output
[11:46] Micheil: it's just confusing
[11:51] Micheil: I might update node and retry with sys.inspect
[11:59] Micheil: woah./
[12:03] Micheil: some stuff is trippy
[12:06] Micheil: inimino: I think I've worked out my problems with the session cleanups
[12:12] Micheil: just cleaning and testing the code a little
[12:12] Micheil: I had a few issues with annoying scopes
[12:13] Micheil: because you can't pass this as an argument to setTimeout, eg, setTimeout(func, 1000, this);
[12:22] Micheil: woot. just integrated node into gedit... sorta.
[12:24] michaelk^ has joined the channel
[12:26] dam has joined the channel
[12:36] Micheil: does node support colouring of command line output?
[12:38] Bluebie: that's really more a matter of if your terminal supports it or not
[12:38] Bluebie: the colours are just ansi commands
[12:41] Micheil: hmm..
[13:08] soveran has joined the channel
[13:35] shfx has joined the channel
[14:02] Micheil: hmm..
[14:21] rakeshpai: wow... what happened here!
[14:22] [i]chuck has joined the channel
[14:22] onar has joined the channel
[14:22] rbranson has joined the channel
[14:22] jspiros has joined the channel
[14:22] Nailor has joined the channel
[14:22] m1631_ has joined the channel
[14:22] rudebwoy has joined the channel
[14:22] mburns has joined the channel
[14:23] shfx has joined the channel
[14:23] soveran has joined the channel
[14:23] pdelgallego has joined the channel
[14:23] keeto has joined the channel
[14:23] Yuffster has joined the channel
[14:23] ciju has joined the channel
[14:23] mcarter has joined the channel
[14:23] JoePeck has joined the channel
[14:23] tlrobinson has joined the channel
[14:23] Micheil has joined the channel
[14:23] PowerToExt has joined the channel
[14:23] rbranson_ has joined the channel
[14:23] Wes- has joined the channel
[14:23] hassox has joined the channel
[14:23] gwoo has joined the channel
[14:23] nefD has joined the channel
[14:23] sifi has joined the channel
[14:23] skampler has joined the channel
[14:23] nebopolis has joined the channel
[14:23] tlockney has joined the channel
[14:23] erikg has joined the channel
[14:23] sztanpet has joined the channel
[14:23] apgwoz has joined the channel
[14:23] rektide has joined the channel
[14:23] jarib has joined the channel
[14:23] [k2] has joined the channel
[14:23] intellectronica has joined the channel
[14:23] Atmoz has joined the channel
[14:23] ashb has joined the channel
[14:27] Micheil: 
ACTION just pushed a new version of his session manager

[14:39] erikcorry has joined the channel
[14:44] freenode-connect: 
VERSION

[15:10] alexiskander has joined the channel
[15:13] mies has joined the channel
[15:25] Micheil: ryah: hey, where's the JSON module stored?
[15:33] Biscuits: Micheil: It's in V8, check the V8 source
[15:33] alexiskander: Micheil: I thought JSON.(whatever) was a built-in feature of V8?
[15:33] alexiskander: heh :)
[15:33] Micheil: okay
[15:33] Micheil: thanks
[15:34] Micheil: I was just trying to find what the reverse of stringify was, so guessed it would be the js json standard
[15:34] alexiskander: JSON.parse ?
[15:42] ashb: JSON is part of ES5
[15:43] ashb: which is as of 3..4 days ago a ratified spec
[15:43] ashb: alexiskander: http://flusspferd.org/docs/js/language/json.html
[15:43] ashb: (for a different project, but thats documenting the behaviour of the core JSON)
[15:49] jan____: ashb: totally missed the ratification. this is good news!
[15:49] ashb: 2 days ago infact
[15:50] ashb: and IBM were still being cocks about the deciamal spec
[15:51] ashb: and it doesn't really solve the underlying problem
[15:54] jan____: yeah, but we don't have their half-baked solution, right?
[15:54] jan____: hm, the spec mentions IEEE 754
[15:54] ashb: no. no decimal at all
[15:54] jan____: right
[15:54] ashb: IEE754r is the decimal spec
[15:55] jan____: ah right
[15:55] jan____: so we're better off that with 754r
[15:55] ashb: but decimal flaoting point will still suffer the same sorts of computation 'issues'
[15:55] jan____: but we still wait for a solution
[15:55] jan____: right
[15:55] ashb: its just it can more accurately represetn common decimal numbers
[15:55] jan____: hope doug get's his ideas into EC6 then
[15:55] ashb: er, decimal fractions
[15:55] jan____: yeah, but it still sucks and it is hard to implement and slow
[15:56] ashb: yeah. fixed point is the best bet
[15:56] ashb: since its largely a domain specific problem anyway
[15:56] jan____: yeah.
[15:56] ashb: and fixed point isn't that hard to implment iuf oyu have operator overlaoding >_>
[15:56] jan____: :D
[15:56] ashb: -typos
[15:56] jan____: ok, back to parsing this text protocol
[15:57] ashb: http://wiki.ecmascript.org/doku.php?id=harmony:proposals
[15:57] ashb: is all thats looking likely to be included so far
[15:57] ashb: a few more things will likely be added
[15:57] ashb: but i'm really happy to see those
[15:57] ashb: let, const, destructuring and spread/rest are awesome
[15:58] jan____: :)
[16:00] ashb: i'd love to see catchall, op overloading and yield/generators/list-comps in that list too
[16:03] ashb: (in about that order)
[16:32] curious_ has joined the channel
[16:34] curious_: hi, i'm trying redis-node-client
[16:34] curious_: with this code: client.get("user:username:" + username).addCallback(function(id){
[16:35] curious_: now id is inside the inner function
[16:35] curious_: how can i do return to use it?
[16:35] curious_: look at this paste please: http://pastie.org/730438
[16:36] curious_: i'm getting ReferenceError: id is not defined on the return id
[16:37] mediacoder: curious_: you could return a promise, and inside your redis-callback function emit success
[16:37] curious_: it's certainly my lack of understanding of callbacks
[16:37] curious_: hi mediacoder thanks for responding
[16:38] curious_: do you have any example of this somewhere?
[16:38] curious_: sorry to ask :)
[16:38] curious_: can i just do a return from the function with the retrieved id
[16:39] curious_: please also take a look at my pastie
[16:39] curious_: it shows my intent
[16:39] ryah: curious_: http://pastie.org/730442
[16:40] ryah: does that make sense?
[16:40] ryah: somehow whenever you do i/o there has to be a callback
[16:40] curious_: oh thanks that was fast!!!
[16:40] curious_: i'm currently learning about all this
[16:41] ryah: so it's not possible to pull the "id" out of the callbacks and just return it
[16:41] curious_: i have three books to read :)
[16:41] the_undefined has joined the channel
[16:41] ryah: the_undefined: re
[16:41] curious_: ryah: as long as your solution works it's fine with me
[16:41] curious_: thanks
[16:45] the_undefined: ryah: re
[16:46] ryah: any objections to doing a release righ tnow?
[16:47] the_undefined: ryah: nope, looks like it would be cool
[16:51] mediacoder: hm
[16:51] mediacoder: im using sys.p() much which used to work like a charm, and printent "\r\n", for example .. now it just prints "" ..but it might be me using deprecated stuff :-)
[16:52] ryah: mediacoder: hmm. inspect() was just changed.
[16:53] mediacoder: yea, since then it doesnt print "\r\n" :-)
[16:53] ryah: mediacoder: can you reply to Xavier Shay's message on the mailing list
[16:53] ryah: and complain?
[16:53] mediacoder: sure
[16:59] the_undefined: mediacoder: I think all it would take is to use JSON.stringify to inspect strings
[16:59] ryah: mediacoder: are you aware of you "flash-mike" nickname?
[16:59] ryah: s/of you/of your/
[16:59] mediacoder: on google you mean?
[17:00] ryah: no in rl
[17:00] ryah: that's what urban calls you :)
[17:00] mediacoder: ah, yea :-D we used to work on a team where like 2 or 3 mikes were :-)
[17:00] mediacoder: so i was flash-mike cause im actually coming from the flash world :-X
[17:02] mediacoder: and now im mediacoder, to gain some internet fame :-D
[17:02] mediacoder: ryah: other than that little issue, i also havent come across other problems
[17:03] mediacoder: (this relates to the release, not my name :-D)
[17:04] ryah: good cause i just released 0.1.21
[17:04] mediacoder: heh
[17:05] CIA-28: node: 03Ryan Dahl 07master * rc6affb6 10/ (ChangeLog doc/api.txt doc/index.html wscript): bump version - http://bit.ly/54XTiT
[17:07] ryah: i hope for speedy adoption of es5 by v8
[17:07] ryah: i want "use strict"
[17:07] frodenius: i want to use defineProperties
[17:08] ryah: the_undefined: can we get the log bot to eval js, like they do in ##javascript ?
[17:08] ryah: would be cool
[17:09] frodenius: i am working on a bot that does that
[17:09] the_undefined: ryah: any JS?
[17:11] ryah: the_undefined: i guess it needs to be sandboxed
[17:12] the_undefined: ryah: not doo afraid of somebody doing something stupid since it's all in public here
[17:12] the_undefined: * too
[17:12] the_undefined: so yeah, I could add that
[17:13] inimino: frodenius: could start from the buubot source code
[17:13] mediacoder: i have a simple twitter streaming client .. the bot could post #nodejs tweets in realtime here ;-)
[17:14] the_undefined: mediacoder: that'd be fun
[17:14] the_undefined: but it seems like the tag has not caught on yet
[17:14] inimino: frodenius: hm. I guess I could run a new buubot in ##javascript since I already have the source...
[17:14] the_undefined: I find 10x more tweets with just 'node.js' without any tag
[17:14] mediacoder: well, it uses twitters streaming api, where yu can specify multiple tags,words, whatever
[17:14] ryah: mediacoder: that'd be rad
[17:15] mediacoder: the_undefined: i dont like the . which breaks the tag :-(
[17:15] inimino: and here I guess
[17:15] mediacoder: otherwise id use it too
[17:15] ryah: mediacoder: i search for "node js" "node v8" "#nodejs" and "nodejs"
[17:15] ryah: that seems to catch most things
[17:16] mediacoder: i can push the client to github.. gotta clean it up a bit from my framework stuff
[17:17] ryah: node is great for irc bots
[17:17] mediacoder: yea, defenitely
[17:24] frodenius: inimino: yeah, except buubot is perl
[17:24] frodenius: i only see gibbereish
[17:25] inimino: frodenius: it's Perl, yeah
[17:25] frodenius: i am working on a node based evalserver
[17:25] inimino: that would be nice
[17:26] ryah: does anyone want an account on nodejs.org for setting up the master build bot? (i seem to keep putting it off, maybe someone else can actually do it?)
[17:27] the_undefined: ryah: I might find some time next week, are you settled on build bot as the CI server?
[17:27] ryah: yes, i think so
[17:28] the_undefined: There are a few ones out there that look much simpler
[17:28] the_undefined: like CiJoe
[17:28] the_undefined: but of course those lack a lot of features
[17:28] sr: what features do you need?
[17:29] ryah: generally i try to use what chrome/v8 uses
[17:31] the_undefined: does anybody know if its considered a back practice to define a variable twice?
[17:32] the_undefined: I'm asking because in unit tests its kind of tempting to do var expected = ''; over and over
[17:32] inimino: the_undefined: generally yes
[17:32] the_undefined: ok
[17:32] inimino: the_undefined: function(){var expected
[17:32] inimino: ...
[17:32] inimino: expected = '';
[17:32] the_undefined: ok
[17:32] the_undefined: but that's just a style thing
[17:32] the_undefined: or are there any actual side effects?
[17:34] the_undefined: btw. process.mixin is really ugly JS, resig has done too much perl :)
[17:34] the_undefined: (fixing some bugs with the port of it right now, not actual bugs just bugs in the porting of it to node)
[17:35] inimino: the_undefined: since adding extra 'var ' statements has no effect I'd say it's rather bad style, but no there are no side effects
[17:35] the_undefined: k
[17:35] CIA-28: node: 03Christopher Lenz 07master * rf8ba9c3 10/ (9 files in 4 dirs): 
[17:35] CIA-28: node: Add http.Client.prototype.request()
[17:35] CIA-28: node: Change the http.Client API so that it provides a single request() method
[17:35] CIA-28: node: taking an optional parameter to specify the HTTP method (defaulting to
[17:35] CIA-28: node: "GET"), instead of the five methods get(), head(), post(), del() and put(). - http://bit.ly/5QDyCr
[17:36] inimino: the_undefined: I do recommend one var statement per function though
[17:36] inimino: one of those rare style points Crockford and I agree on
[17:37] inimino: 
ACTION notes that the HTTP client can now generate requests that the HTTP server can't recieve :P

[17:37] frodenius: hehe
[17:43] curious_ has joined the channel
[17:47] cloudhead has joined the channel
[18:01] malkomalko_ has joined the channel
[18:07] the_undefined: ryah: Got 2 process.mixin bug fixes for you here: http://github.com/felixge/node/commits/process-mixin
[18:07] the_undefined: also got an additional patch which I do not feel strongly about, but it struck me as odd that process.mixin is currently behaving this way
[18:22] ryah: inimino: http://github.com/ry/http-parser/commit/12808fe1e695f3db0bdd56a157ff4a6030ef0e09
[18:22] ryah: the agony...
[18:23] ashb: ryah: um do a strcmp at the end.
[18:24] ashb: what if you want ot support a custom method?
[18:24] ryah: then you're fucked :)
[18:25] frodenius: man i want BUTTSEKS /ladyinred
[18:26] dnolen has joined the channel
[18:26] ashb: ryah: why not just allow any method name?
[18:26] ryah: don't want the overhead of a callback
[18:26] ryah: i guess i could add a few bytes and buffer the method
[18:28] ryah: yeah, maybe i'll do that - add 11 bytes per stream in exchange for much easier code?
[18:29] ashb: seems like a win :)
[18:29] ryah: currently at 124 bytes - 135 hm
[18:29] ryah: puts its over 128
[18:30] ryah: oh wait - proppatch is the longest with 9
[18:30] ryah: 133 bytes i guess
[18:32] ashb: a static "char x[y]" in the struct?
[18:33] inimino: doesn't sound too bad
[18:33] ryah: yeah char method[9]
[18:33] ashb: i'd make it a bit larget than 9 if it takes you over 128 anyway
[18:34] ryah: 
ACTION hates http extension methods

[18:34] ryah: lots of drunk people wandering around cologne tonight
[18:34] mediacoder: welcome back to germany :-)
[18:35] inimino: I don't expect to need more than 9, but don't know what others might want
[18:35] inimino: I think 9 is reasonable
[18:35] mediacoder: ryah: it will get even worse .. you survived carnival in cologne yet?
[18:35] inimino: supports WebDAV and anything shorter than it
[18:36] ryah: mediacoder: yeah, i've been here for 3 years
[18:36] mediacoder: ryah:  ah okey :-)
[18:36] mediacoder: then you are prepared :-)
[18:36] ryah: carnival is okay because i'm drunk too :)
[18:36] mediacoder: hehe
[18:36] mediacoder: i hate it like hell
[18:36] mediacoder: i can get drunk anytime :-X
[18:37] ryah: do they have it in your city?
[18:37] ryah: (where are you again?)
[18:37] mediacoder: well.we have it allover germany.. but there are like 2 big carnival metropoles, which is cologne and mainz
[18:37] mediacoder: Darmstadt, south of frankfurt/main
[18:37] ryah: do you have 11.11 ?
[18:38] mediacoder: yea ..in every city that has a carnival-club :-)
[18:38] mediacoder: there the drama starts, until february
[18:40] frodenius: what are kreppl in darmstadt?
[18:41] mediacoder: kreppel :-)
[18:41] mediacoder: i think 
[18:41] frodenius: :) k
[18:41] mediacoder: or maybe krapfen ..well.. i dunno..i avoid carnival :-)
[18:42] the_undefined: ryah: what do you think about the mixin patch?
[18:43] mediacoder: anyone wants to maintain nodejs twitter user? i regged it some weeks ago, but im kinda lazy twitterer ususally
[18:44] ashb: for those of you who missed my rant in #commonjs: assert.deepEqual(/a/, /a/g) passes
[18:44] the_undefined: ashb: lol, that's shocking :D
[18:45] the_undefined: why did you need to rant about it?
[18:45] the_undefined: seems like a clear bug to me
[18:45] ashb: what's worse is that i said this 3 times during the process
[18:45] the_undefined: hm
[18:45] ashb: also krisk's test does deepEqual(['a'], {0: 'a'})
[18:46] the_undefined: ashb: hm, that's questionable
[18:46] ashb: or "Wrong" as i like to call it
[18:46] ashb: its how the spec is worded, but its wrong. they are two different classes of object
[18:46] the_undefined: ashb: afaik our implementation is fairly different, did you test it for these things?
[18:46] CIA-28: node: 03Felix Geisendörfer 07master * rf080de5 10/ (src/node.js test/mjsunit/test-process-mixin.js): (log message trimmed)
[18:46] CIA-28: node: Two bug fixes for process.mixin
[18:46] CIA-28: node: Bug #1 occurred when trying to use process.mixin on a function and
[18:46] CIA-28: node: produced a fatal exception.
[18:46] CIA-28: node: Bug #2 occurred when trying to do a deep merge with an object containing
[18:46] the_undefined: I'm pretty sure ryah would consider patching this
[18:46] CIA-28: node: one or more objects with a nodeType property. In those cases the deep
[18:46] CIA-28: node: copy for this part of the object was not performed and a shallow one was
[18:46] CIA-28: node: 03Felix Geisendörfer 07master * r876b6d2 10/ (src/node.js test/mjsunit/test-process-mixin.js): 
[18:46] CIA-28: node: Make process.mixin copy over undefined values
[18:46] CIA-28: node: This is not a bug in process.mixin, but I think it is undesirable
[18:46] CIA-28: node: behavior. Right now process.mixin will not copy over keys with undefined
[18:46] ashb: the_undefined: you've got basically the same deepEqual impl
[18:46] CIA-28: node: values. To me that is an unexpected filtering that should not happen
[18:46] CIA-28: node: unless specifically called for. - http://bit.ly/8fgIg6
[18:46] ryah: the_undefined: yeah looks good
[18:47] ashb: someone needs shorter commit messages :)
[18:47] ashb: the_undefined: so that does follow the spec. the spec is jsut wrong
[18:47] the_undefined: ryah: cool, thanks. I'm not 100% sure about the 2nd patch. By that I mean that I think its the right behavior, but I don't know why jQuery.extend was doing it different
[18:49] kriskowal has joined the channel
[18:49] ryah: the_undefined: someone will complain if it's not right
[18:49] kriskowal: the_undefined, what's your github user name?
[18:49] kriskowal: real name Karl?
[18:49] the_undefined: kriskowal: no, I'm Felix Geisendörfer
[18:50] kriskowal: oh.  felixge.
[18:50] the_undefined: kriskowal: but Karl did the assert port
[18:50] the_undefined: yeah
[18:50] kriskowal: what's karl's github then?
[18:50] ashb: http://github.com/grayrest
[18:50] ryah: kriskowal: greyrest
[18:50] kriskowal: thanks.
[18:51] kriskowal: i'm in the process of crediting and providing contact info in narwhal's modules
[18:55] inimino: ryah: could you have your existing approach for GET PUT POST DELETE HEAD TRACE and OPTIONS, and for anything else, stick it in the buffer you use for header fields and fire a method callback when you see a space?
[18:55] ryah: inimino: i'll put it in the buffer and you can get the callback on headers_complete
[18:56] ryah: i don't want a ton of callbacks for things that 99.9% of the time all lay within the same buffer
[18:57] inimino: ok
[19:09] the_undefined: my deferred port is done: http://github.com/felixge/node-deferred
[19:19] fictorial has joined the channel
[19:19] fictorial: anyone have a working mmap binding for node.js?  I'm not sure how feasible that is really.  I just have an application where it would be handy.
[19:24] the_undefined_ has joined the channel
[19:40] kriskowal_ has joined the channel
[19:40] isaacs has joined the channel
[19:48] ryah: the_undefined_: what do you think about replacing promises with those deferreds?
[19:48] the_undefined_: ryah: I think it would be awesome :)
[19:49] the_undefined_: ryah: not with the current version of them so, I'd like to do some unit tests first
[19:49] the_undefined_: I basically just took dojo.Deferred and stripped out all dojo dependencies, but maybe I missed some issues
[19:49] ryah: the_undefined_: can you add wait() ?
[19:49] the_undefined_: ryah: you mean in theory or do you want me to do it?
[19:50] ryah: i mean, what do you think about adding it?
[19:50] fictorial: What's different b/w Promises and Deferreds?  Are Deferred's auto-chainable?
[19:52] the_undefined_: ryah: well, if Deferreds replace Promise I think we should add it
[19:52] the_undefined_: fictorial: yes, they make it very easy to chain them
[19:52] the_undefined_: fictorial: and I'm working on a syntax to make it 10x more easy
[19:53] the_undefined_: inspired by fab
[19:53] fictorial: great then I can get rid of my PromiseChain implementation
[19:53] ryah: the_undefined_: i think we should aim to replace promises with deffereds
[19:54] ryah: the_undefined_: maybe we can have some overlap time
[19:54] the_undefined_: fictorial: https://gist.github.com/64514aa1e4bdad308a32
[19:54] the_undefined_: ryah: how could we have overlap time?
[19:54] ryah: the_undefined_: just have both 
[19:54] the_undefined_: ryah: hm, we could do that.
[19:55] the_undefined_: just add them to the core so people will play with them
[19:55] the_undefined_: and replace their internal Promise usage
[19:55] the_undefined_: and then replace the promises node returns with Deferreds
[19:55] the_undefined_: so at some point we would have Promise and Deferred point to the same implementation
[19:55] the_undefined_: but which one are we going to remove?
[19:58] the_undefined_: fictorial: what do you think about the syntax in my paste?
[19:58] fictorial: sorry, let me look
[19:58] kriskowal has joined the channel
[20:00] fictorial: the_undefined_: it is cute but I tend to like explicit interfaces.  instead of (group)('a', a)('b', b) I would personally prefer group.push('a',a).push('a',a)
[20:00] fictorial: fab is certainly interesting but as the default syntax for Deferred groups it might confuse a lot of people
[20:01] the_undefined_: fictorial: there will be an explicit interface as well
[20:01] jed: the_undefined_: i'm refactoring fab right now so that the function chaining is just sugar for discrete methods.
[20:01] fictorial: but that's just my $0.02
[20:01] jed: the_undefined_: yeah, that's a good idea.
[20:01] the_undefined_: fictorial: https://gist.github.com/41e7293fc20eca76304a
[20:01] jed: the_undefined_: (and has the benefit of allowing people to choose sugar or speed)
[20:01] the_undefined_: jed: cool
[20:01] the_undefined_: jed: I really think we should find a generic way to do this sugar so other people can easily add it to their APIs
[20:02] fictorial: jed: choices are good; awesome
[20:02] fictorial: the_undefined_: neat idea
[20:02] jed: the_undefined_: i was thinking of that too.
[20:02] fictorial: the_undefined_: re: your last gist, do you need (group)() or just group()
[20:02] jed: i actually had a bit of a prototype, but gave it up when i felt like my problem solving was getting too meta.
[20:02] the_undefined_: jed: let me see how my implementation ends up, I'm still working on it
[20:03] the_undefined_: fictorial: forget the laste paste, this is how the explicit way would look like: https://gist.github.com/41e7293fc20eca76304a
[20:03] fictorial: that syntax (group)('a',a)('b',b) makes JS look like lisp a bit ... funny
[20:04] fictorial: the_undefined_: that looks great
[20:04] the_undefined_: jed: I'm starting out with an explicit api and I'm trying to make the chaining somewhat of a curry function
[20:04] fictorial: very clear semantics
[20:05] jed: the_undefined_: i was thinking of a similar strategy to fab.
[20:05] the_undefined_: fictorial: btw. I'm not proposing any of this for node core at all yet, I'm merely playing with it to justify a later proposal :)
[20:05] jed: the_undefined_: but instead of binding functions to paths,
[20:05] fictorial: 
ACTION accepts the hand-waving

[20:05] jed: the_undefined_: you bind functions to argument signatures.
[20:05] the_undefined_: jed: that sounds very meta :)
[20:06] the_undefined_: jed: especially when you go for nestings
[20:06] the_undefined_: :)
[20:06] the_undefined_: but hey, I'd be the first to use it
[20:06] jed: the_undefined_: gosh i hadn't even thought of nesting.
[20:06] nefariousd_ has joined the channel
[20:06] the_undefined_: jed: yeah, the evil stuff shows up when you least expect it
[20:06] the_undefined_: :)
[20:06] the_undefined_: luckily I won't need nesting for what I'm doing righ tnow
[20:06] the_undefined_: * right now
[20:07] jed: but yeah, something like this: ( dispatcher )( myFunc )( [ String ], Function )
[20:07] jed: where the array is a hack to allow optionals.
[20:08] jed: the_undefined_: if this is something you think you'd use, i'll try to hack it up today.
[20:08] jed: the_undefined_: would make the fab code easier to read, i think.
[20:09] jed: the_undefined_: i just wonder about the overhead of all those function calls.
[20:09] the_undefined_: jed: don't wonder, just benchmark when time is ready
[20:10] the_undefined_: jed: I would suggest a benchmark of req / sec for a trivial fab app vs a non-fab counterpart
[20:10] jed: the_undefined_: good point. and if it's all optional, i guess it doesn't really matter.
[20:10] the_undefined_: My forecast is ~2-3% overhead
[20:10] the_undefined_: but that is just a gut feeling
[20:10] jed: the_undefined_: unfortunately, i've never done any benchmarking on anything. will take a while to put that together for me.
[20:11] the_undefined_: Generally I'm not very worried about overhead of my code in v8
[20:11] the_undefined_: :)
[20:11] the_undefined_: jed: lol
[20:11] the_undefined_: jed: I can help
[20:11] jed: the_undefined_: but having something like that would make javascript a lot more comfortable for folks that are used to static types.
[20:11] the_undefined_: jed: it's really easy, you install apache bench and run: ab -c 10 -n 1000 "http://localhost:8000/my_app"
[20:11] jed: the_undefined_: nice to write functions when you KNOW that your args are what you think they are.
[20:12] jed: the_undefined_: aight, i may ping you when the time comes.
[20:12] the_undefined_: jed: cool
[20:12] jed: the_undefined_: i'm still getting my head around deferreds.
[20:12] the_undefined_: jed: 
[20:12] the_undefined_: y
[20:12] the_undefined_: took me a while as well
[20:13] the_undefined_: but its not that hard
[20:13] the_undefined_: I'd recommend playing with my port
[20:13] the_undefined_: I usually learn more from playing with something than reading the docs
[20:13] jed: the_undefined_: perhaps you could put some examples in the README?
[20:13] alexiskander_ has joined the channel
[20:14] the_undefined_: jed: yeah, will do
[20:14] jed: the_undefined_: that would be awesome.
[20:17] jed: the_undefined_: okay, i'm going to head out and write this function chaining thing, and hopefully see how i can work your deferreds into fab.
[20:17] the_undefined_: jed: Oh, I'm not sure you have to work the deferreds into fab
[20:18] rakeshpai has joined the channel
[20:18] jed: the_undefined_: well, i'd like to support async better.
[20:18] the_undefined_: I'm also not sure if the chaining sugar should be a module of its own or rather a pattern to follow
[20:18] jed: the_undefined_: otherwise it's just a toy.
[20:19] the_undefined_: jed: ah ok, I thought you were talking about making DeferredGroup's a fab construct
[20:19] the_undefined_: I'll have to see how complex my implementation gets to decide whether it needs a "framework"
[20:20] jed: the_undefined_: i'm thinking of just allowing fab( "/", func1, func2, func3 )
[20:20] jed: the_undefined_: each one is the callback for the next.
[20:20] jed: the_undefined_: and the http statuses are used as errbacks.
[20:20] jed: the_undefined_: but haven't really thought it through.
[20:21] the_undefined_: jed: hm, not sure why you would pass multiple functions in like this
[20:21] jed: the_undefined_: maybe func1 would be authentication, func2 would be authorization, and func3 would be render.
[20:22] jed: the_undefined_: each one modifying the "this" context.
[20:22] the_undefined_: jed: sounds lame :)
[20:22] jed: the_undefined_: ha, really?
[20:22] the_undefined_: I'd much rather have one callback and then a neat syntax to work within that
[20:23] the_undefined_: I wouldn't try to enforce a chain like that on the user
[20:23] jed: the_undefined_: the goal is to chain small reusable functions instead of building big monolithic ones.
[20:23] jed: the_undefined_: oh, i see. they shouldn't be serial?
[20:25] the_undefined_: jed: oh, I see
[20:26] the_undefined_: jed: well I still think it should be done within the callback
[20:26] the_undefined_: jed: it could use Deferred.group for that
[20:26] sztanphet has joined the channel
[20:26] jed: the_undefined_: i see. so build it outside of the framework.
[20:26] the_undefined_: jed: or better: Deferred.sequence (something else I'm working on, same thing just sequential)
[20:26] the_undefined_: jed: y, I think
[20:26] jed: the_undefined_: and once you're done, stick it in there.
[20:26] the_undefined_: jed: yes
[20:27] jed: the_undefined_: good advice. i'll have to give it a noodle once i have more chance to play with deferreds.
[20:27] the_undefined_: jed: you might want to wait until I finish my DeferredGroup / DeferredSequence work
[20:27] the_undefined_: then it will make more sense to discuss this
[20:28] jed: the_undefined_: i think i might do that. there's plenty of other stuff to work on now anyhoo, like adding http method convenience functions, etc.
[20:28] jed: the_undefined_: looking forward to seeing your group/sequence stuff.
[20:33] malkomalko has joined the channel
[20:38] erikg: inimino: you mentioned that iframe sandboxing could break instanceof... but would it theoretically be possible to make all the builtin objects in the window subclass the equivalent builtins in the parent window?
[20:39] inimino: erikg: no
[20:40] inimino: erikg: many of them are going to be host objects which you can't do anything with in many browsers
[20:40] inimino: erikg: and besides, doing that would break things even worse in many cases
[20:41] erikg: inimino: that all explains what happened when i tried it :)
[20:41] erikg: inimino: thanks
[20:41] inimino: sure :)
[20:43] erikg: inimino: are there any other things which would likely break in the sandboxing case besides instanceof?
[20:43] erikg: rather, instanceof between types from different sandboxes
[20:44] inimino: hm...
[20:44] erikcorry|away: Instead of instanceof you can use (typeof(x) === 'Array')
[20:44] the_undefined_: ok, got an initial DefferedGroup implementation working, including the sugar
[20:44] the_undefined_: implemtnation: http://github.com/felixge/node-deferred/blob/master/lib/group.js
[20:44] the_undefined_: usage: http://github.com/felixge/node-deferred/blob/master/test/test-group.js
[20:44] erikcorry|away: That should work across iframes.
[20:44] erikcorry|away: And it's very optimized by V8.
[20:44] erikcorry|away: There's no string comparison involved at lal.
[20:44] erikg: erikcorry|away: as opposed to instanceof?
[20:44] erikcorry|away: Yeah.
[20:44] erikcorry|away: If you have to ask for the class of an object
[20:45] erikcorry|away: Which is bad OO style IMHO
[20:45] erikg: i wish i had a big lib of millions of lines of js to check what's most commonly used
[20:45] inimino: erikcorry|away: well probably not too many things that people are terribly likely to do
[20:45] erikg: erikcorry|away: thanks for that info, very interesting that the typeof case is optimized
[20:46] inimino: erikcorry|away: uh, when did typeof([]) become 'Array'?
[20:46] erikcorry|really: Oh, I can't be called erikcorry|reallyaway
[20:46] erikg: hmm..
[20:46] erikcorry: Oh
[20:47] erikg: inimino: yeah, that's right...
[20:47] erikg: it only distinguishes between string, object, number, boolean
[20:47] erikcorry: Good point.
[20:47] erikcorry: it's just an object.
[20:47] inimino: string, number, boolean, object, undefined, null, and function IIRC
[20:47] erikcorry: So not so useful..
[20:47] erikg: 
ACTION -> out

[20:48] erikcorry: It works for typeof("") === 'string'
[20:48] erikcorry: (lower case)
[20:48] erikcorry: not for arrays.
[20:48] inimino: I agree that asking for the class is bad JavaScript style though
[20:48] erikcorry: I should test before mouthing off!
[20:48] inimino: duck-typing is best :)
[20:48] erikcorry: I think it's more in the spirit of the language, yes.
[20:49] inimino: unfortunately some stuff is exposed that really shouldn't be... like instanceof
[20:50] inimino: but so be it :)
[20:52] dnolen has joined the channel
[20:56] jed_away has joined the channel
[20:58] jed_away_ has joined the channel
[20:59] fictorial: the_undefined_: try not to benchmark on the same host you are benchmarking, in general
[20:59] the_undefined_: fictorial: depends on what you are trying to benchmark
[20:59] fictorial: yes indeed
[20:59] the_undefined_: fictorial: I think if you try to make relative comparisions its ok
[21:00] fictorial: probably
[21:08] jed_ has joined the channel
[21:16] alexiskander: I'm really slow on the uptake. I just realized that if I implement Dobby—my messaging/push system—in node.js, I can use some of the same code on the client and the server
[21:16] alexiskander: like the message dispatch code that decides who gets what message
[21:16] alexiskander: neat. as. heck.
[21:28] the_undefined has joined the channel
[21:30] Micheil: mediacoder: did you see that tweetwally thing I posted yesterday? http://nodejs.tweetwally.com/
[21:32] Micheil: ryah: hmm.. I'll have to try writing an irc client in node sometime, it shouldn't be too hard, I've written similar on the mozilla libraries before.
[21:33] ryah:  there should be a irc client library floating around somewhere
[21:33] Micheil: the_undefined: I proposed a possible new process.mixin based on dojo's mixin.
[21:34] the_undefined: Micheil: on the mailing list?
[21:34] frodenius: Micheil: i'm currently working on a irc lib/bot, maybe i'll release 0.1 this evening, might be interesting
[21:34] mediacoder: Micheil: ah kool. you can use my node streaming-api client to make such a project :-P
[21:39] Micheil: the_undefined: uh, no, in chat, my bad ;P
[21:39] the_undefined: Micheil: post to the mailing list, explain how dojo.mixin works better. I think the current mixin function is really messy, but it does the job
[21:40] Micheil: http://gist.github.com/250165
[21:40] Micheil: mine isn't exactly dojo.mixin, but it's similar.
[21:40] Micheil: iirc, the jquery extend actually has heaps of redundant loops because IE fails to copy over some prototype methods or something
[21:41] the_undefined: Micheil: No, I don't think that's the reason
[21:41] Micheil: the_undefined: if anything my version might be faster
[21:42] the_undefined: it supports to mixin multiple objects at the same time
[21:42] the_undefined: and it also supports shallow copies as well as deep copies
[21:42] Micheil: the_undefined: true
[21:42] the_undefined: I can't say it does so in an elegant fashion, but it explains the loops
[21:42] the_undefined: :)
[21:42] Micheil: I can implement those, but the project that that mixin was taken from always needed deep and two object based mixins
[21:44] malkomalko: hot dayam, just figured out one of the last things before pushing up my filesystem database, hope to have it up tonight/tomorrow
[21:44] malkomalko: can now do conditional finds on numerical fields :)
[21:45] ryah: hm. maybe i should make a FUSE binding to node..
[21:45] ryah: would be rad, or?
[21:45] malkomalko: free music downloads ? :)
[21:46] Micheil: FUSE as in fusermount?
[21:46] malkomalko: or filesystem in userspace?
[21:46] ryah: user space file systems
[21:46] ryah: then i could do something disgusting like a file system with built in irc server
[21:47] malkomalko: will go well with my filesystem database :)
[21:47] malkomalko: findAll('projects', {name_bw:"foo", age_gt:35}, function(result) {
[21:51] isaacs has joined the channel
[21:51] inimino: ryah: FUSE bindings would be cool
[21:52] inimino: would go really well with my revstore stuff too
[21:53] jtaby_ has joined the channel
[21:53] inimino: could have the same revision store exported over HTTP and mounted locally
[22:02] ryah: i guess i should get mysql first 
[22:04] alexiskander_ has joined the channel
[22:04] malkomalko: I wonder if it would be quicker on the filesystem to do searches in more smaller files then one large file
[22:05] malkomalko: awesome grammar by me!
[22:07] sudoer has joined the channel
[22:07] inimino: yeah FUSE seems like a not-essential thing
[22:07] ryah: i actually came up with the idea for node while writing a FUSE fs
[22:08] inimino: oh, what for?
[22:08] ryah: fuse has this really nice low-level api that you can do evented
[22:08] inimino: oh, cool
[22:08] ryah: just some contract - using a nosql backend
[22:09] tlockney: ryah: have you thought about some sort of FFI for node?
[22:09] inimino: ah
[22:09] inimino: 
ACTION hasn't done any fuse hacking but it does sound fun

[22:09] inimino: plan9 lives!
[22:09] tlockney: is FFI even possible with the v8 engine? I haven't dug deeply into it yet.
[22:09] ryah: tlockney: not so much - but i saw http://github.com/rbranson/node-ffi
[22:09] fictorial: yeah I'm excited by that :)
[22:10] jtaby_: Has anyone written a database interface for use in node.js servers?
[22:10] tlockney: ryah: ah, interesting. the thought popped in my head a few days ago, guess it was before this was pushed up
[22:10] fictorial: jtaby_: define database
[22:10] jtaby_: umm, mysql/sqlite3/postgresql
[22:11] jtaby_: with crud support
[22:11] malkomalko: I'll have one utilizing the filesystem up on github tomorrow
[22:11] fictorial: jtaby_: ah, rdbms - ryah has postgres bindings I think
[22:11] tlockney: http://github.com/ry/node_postgres
[22:12] fictorial: fwiw I'm writing an object database in node
[22:12] tlockney: ^ for jtaby_
[22:12] jtaby_: thanks
[22:12] rbranson_: FYI -- the FFI stuff should be in a somewhat usable state by the end of this week
[22:12] ryah: very hacky though - the node_postgres
[22:12] fictorial: rbranson_: rock
[22:12] malkomalko: I'd be interested to hear what you're doing fictorial
[22:12] tlockney: rbranson_: very cool. I'll have to dig into this later tonight
[22:12] ryah: rbranson_: rad- i'm glad you're working on it
[22:13] rbranson_: thanks... the API i'm considering is something like this:
[22:13] rbranson_: var libc = new FFI.Library("libc", {"atoi": [ "int32", [ "string" ] ]});
[22:13] rbranson_: libc.atoi("1234"); // 1234
[22:13] ryah: nice
[22:13] fictorial: malkomalko: think a mix of Ohm's interface (Ruby), data types from Redis, replication from Tokyo Tyrant, and append-only journaling from CouchDB and YDB et al.
[22:13] tlockney: rbranson_: that seems reasonable
[22:13] rbranson_: it's going to be pretty "unsafe" at first
[22:14] tlockney: rbranson_: have you looked at the ruby ffi lib at all? 
[22:14] rbranson_: yeah, it's a good source of inspiration
[22:14] rbranson_: also, Python's ctypes library
[22:14] malkomalko: where are you planning to store the objects fictorial ?
[22:14] tlockney: rbranson_: cool, sounds like you're on a good path, then ;)
[22:14] fictorial: malkomalko: it's called NODS (Nodejs Object Data Store) which is based on 2 subprojects, NOSE (NODS Server), and NOPE (NODS' Persistence Engine)... 
[22:15] rbranson_: the only thing I differ with the Ruby FFI stuff is I'd like to implement as much of this as possible in JavaScript
[22:15] mediacoder: hehe
[22:15] rbranson_: there's a ton of C code in the Ruby FFI implementation
[22:16] fictorial: Rufus-Lua does its thing via FFI ... Call Lua from Ruby. Neat.
[22:16] jtaby_: what does "res" stand for in the chat demo?
[22:16] jtaby_: i haven't been able to figure that out..
[22:16] jtaby_: result?
[22:17] fictorial: Occam says yes
[22:17] jtaby_: 
ACTION doesn't like 3 letter variable names :(

[22:21] jtaby_: if it was response, that would make more sense...
[22:22] mattly has joined the channel
[22:27] fictorial: if you squint enough a result and a response are pretty similar :)
[22:34] inimino: is there a URI parser in node already somewhere?
[22:34] inimino: say I get a URI in a request header and I want to parse it...
[22:34] LordMetroid has joined the channel
[22:39] ryah: inimino: lib/http.js search for parseUri
[22:40] inimino: ah, I just wrote a regex to do it
[22:40] inimino: but I will look
[22:41] ryah: there is a bug with it - it needs some tests
[22:41] ryah: (in case you're feeling contribute-y)
[22:42] Biscuits: Has anyone written a router that allows you to split up a HttpServer by path into two equal ones ? e.g. allows me to write one callback function and place that at any path in the http server, or just as the root handler ?
[22:42] Biscuits: Most frameworks seem to make up their own way to handle incoming requests :/
[22:43] inimino: m=/(https?):\/\/([^:/?#]+)(?::(\d+))?([^?#]+)(?:\?([^#]+))?(?:#(.*))?/
[22:43] inimino: yay, regex
[22:44] ryah: okay http extension methods: http://github.com/ry/http-parser/commit/9c059ec60dc564edc54c8967cc31710d754da6c1
[22:45] inimino: yay!
[22:47] tlockney: rbranson_: I haven't dug into the ruby ffi innards, but I'd be curious to compare the various impls (c/c++/java/etc.)
[22:47] tlockney: rbranson_: but I agree, keeping most of it in JS would be good
[22:51] rbranson_: it's going to be slow and unsafe at first, for sure
[22:51] inimino: ryah: s/OPTIONS/PROPFIND/ on line 540
[22:51] rbranson_: but we'll see as time goes on
[22:51] inimino: ryah: line 548 too
[22:51] rbranson_: i'd like to get a full, correct implementation done before I get too caught up in safety / performance 
[22:53] Biscuits: rbranson: Be sure to have some kind of threadpool implementation in it too, so you can use blocking functions as non-blocking :)
[22:53] tlockney: rbranson_: what platform are you building on? I had to change '#include <ffi/ffi.h>' to '#include <ffi.h>' to build on ubuntu 9.10
[22:53] ryah: inimino: thanks
[22:53] ryah: inimino: i guess i need tests for those
[22:53] rbranson_: MacOS X for now
[22:54] ryah: inimino: if you see any real life webdav requests send them to me, i'll add them to the test suite
[22:54] inimino: ryah: ok
[22:54] rbranson_: I've basicaly only got ~16 hours into this thing, so it's rough
[22:54] tlockney: rbranson_: looks great for 16 hours ;) 
[22:55] rbranson_: thanks, i was trying to gauge interest before getting too deeply involved
[22:55] tlockney: rbranson_: in the time it will take you to finish this, I would probably just be getting my c++ chops up to speed
[22:55] tlockney: rbranson_: well, I think there would be a lot of interest given the number of c/c++ libs out there that people would like to bind to
[22:55] mediacoder: defenitely
[22:56] rbranson_: yeah, I figured since there aren't a ton of bindings for V8 in general, it would be good to at least get started
[22:56] rbranson_: FFI is not really a substitute for well-written native bindings, but it provides a bridge point
[22:57] tlockney: rbranson_: exactly - bridge building is the name of the game
[23:03] RayMorgan has joined the channel
[23:05] CIA-28: node: 03Ryan Dahl 07master * rc3e0a4b 10/ (4 files in 2 dirs): Upgrade http-parser; supports webdav extension methods now - http://bit.ly/8X3Wh7
[23:10] dnolen has joined the channel
[23:16] malkomalko has joined the channel
[23:30] damien_ has joined the channel
[23:33] jed has joined the channel