[00:06] ryah_really_away: mikeal: i think node is using select() on mac
[00:06] ryah: (strace it to check)
[00:06] ashb: strace doesn't exist on osx
[00:07] ashb: you need to use dtruss/dtrace or what ever it is
[00:07] mikeal: ok
[00:07] ashb: and its not nearly as easy to use for the simple case as strace sadly
[00:08] isaacs: ryah: hey, i think this is a problem: http://github.com/isaacs/node-playground/tree/master/http-header-overflow
[00:09] Tim_Smart has joined the channel
[00:09] ryah: isaacs: yeah thanks
[00:10] nodejs_v8 has joined the channel
[00:10] isaacs: i'm cooking a patch for just that issue.
[00:10] jubos has joined the channel
[00:11] malkomalko has joined the channel
[00:11] ashb: wonder what limit other servers put on header length
[00:11] ryah: isaacs: i'd like to put the patch in http-parser
[00:11] isaacs: ok.
[00:11] isaacs: then i'll leave it in your capable hands?
[00:11] inimino: that was a great talk: http://ssjs.pbworks.com/Communicating-Event-Loops
[00:12] isaacs: as it stands now, it does bad things.
[00:12] _Ray_ has joined the channel
[00:12] ryah: yeah, i'll fix it right now
[00:12] isaacs: it wouldn't be too hard to keep track of the number of bytes received and just kill the connection at some limit.
[00:12] Tim_Smart: ryah: Can you access a module's parent scope from the module
[00:13] malkomalko: thanks for that link inimino .. gonna take a look at that
[00:13] isaacs: ryah: thanks!
[00:16] ryah: Tim_Smart: no
[00:17] Tim_Smart: dam
[00:17] chakrit1 has joined the channel
[00:17] _Ray_ has joined the channel
[00:17] Tim_Smart: I tried passing "this" to it even, but I could add / edit properties of it
[00:18] ashb: this is only the scope objecti n the browser
[00:18] ashb: or when this === the global
[00:18] ashb: which it doesn't for a module
[00:18] joshbuddy has joined the channel
[00:19] Tim_Smart: Yeah I guess it is in a anonymous function or something
[00:19] chakrit2 has joined the channel
[00:24] stephenlb has joined the channel
[00:25] isaacs: Tim_Smart: there is no way to reference a function's context directly, no
[00:26] isaacs: you *can* get to its arguments, if you can grab a reference to the function object, and it's currently running.
[00:26] isaacs: (not sure if v8 closes that hole or not)
[00:28] Tim_Smart: Do node.js files get run inside a closure though?
[00:28] Tim_Smart: arguments.callee points to the function btw
[00:29] Tim_Smart: nodejs_v8: arguments
[00:29] nodejs_v8: Tim_Smart: Exception: ReferenceError: arguments is not defined
[00:29] Tim_Smart: nodejs_v8: (function(){return arguments.callee;})();
[00:29] nodejs_v8: Tim_Smart: function (){return arguments.callee;}
[00:30] Tim_Smart: nodejs_v8: (function(){return arguments;})();
[00:30] nodejs_v8: Tim_Smart: {}
[00:30] isaacs: ryah: woot! removed __wrap__! I like it!
[00:31] inimino: Tim_Smart: you probably already have the arguments (and the arguments object)
[00:31] inimino: Tim_Smart: what's your goal?
[00:32] Tim_Smart: From the module, inject variables in the parent's scope
[00:32] Tim_Smart: or update them
[00:32] ashb: not possible.
[00:32] Tim_Smart: but I got a alternative now
[00:33] Tim_Smart: yay and it works
[00:34] tlrobinson: ashb: "or when this === the global ... which it doesn't for a module" isn't necessarily true
[00:34] inimino: it's true in node
[00:34] ashb: tlrobinson: true. i was assuming it wasn't cos he tried it and didn't work
[00:34] Tim_Smart: except process.mixin isn't working as expected
[00:35] ashb: \o/
[00:35] ashb: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
[00:35] ashb: i do *so* love libtool
[00:36] okito: ryah: I was wondering if you could tell me your opinion on package managers for node. Will there be an official one? Do you want them to be swappable?
[00:37] okito: I saw some commits that seem to imply require() will be overload-able sometime soon
[00:38] Tim_Smart: how do you force update the require cache?
[00:40] Tim_Smart: nevermind found it :p
[00:42] isaacs: okito: i'm working on one.
[00:42] ryah: isaacs: does that crash your node server?
[00:42] stevestmartin has joined the channel
[00:42] ryah: your attack
[00:42] okito: npm?
[00:42] isaacs: okito: yeah. http://groups.google.com/group/npm-
[00:42] isaacs: ryah: well,i didn't let it. but it does keep pushing the memory and cpu ever upwards.
[00:42] okito: I was looking at your code.
[00:42] ryah: okito: i dont know yet
[00:43] hassox: isaacs: bah... that conv is missing my responses in there :\
[00:43] okito: ryah: ok thanks. So to give some context - I am converting SproutCore [http://www.sproutcore.com] to use CommonJS modules
[00:43] ryah: isaacs: when i do it it's hte attack program which is getting large
[00:43] isaacs: hassox: reply to the list! not to me!
[00:43] hassox: lols
[00:43] isaacs: ryah: interesting.
[00:43] okito: the loader I'm writing for the web browser is called Tiki [http://github.com/sproutit/tiki]
[00:43] ithinkihaveacat has joined the channel
[00:43] isaacs: ryah: is it maybe caching the writes?
[00:44] okito: I am trying to make it essentially a clone of the node.js API in the browser
[00:44] okito: since the browser is event driven, async code written for node.js should translate very well
[00:46] ryah: isaacs: yeah - the attack doesn't work on my node
[00:46] isaacs: ok, trying again hooking into drain...
[00:47] Tim_Smart: ryah: Can you implement a method to un-cache a module?
[00:47] okito: isaacs so it looks like npm is pretty early
[00:47] okito: are you using it anywhere
[00:47] isaacs: okito: yeah, it is.
[00:47] Tim_Smart: I can submit a patch if you wantt
[00:47] isaacs: okito: i'm not using it yet.
[00:47] okito: so the thing I'm trying to implement
[00:47] okito: or at least figure out
[00:47] isaacs: i'd love a use case, though!
[00:47] okito: is CommonJS packages use a format like this:
[00:47] okito: require('module', 'package')
[00:48] isaacs: ACTION is not a fan of that.
[00:48] okito: it looks like require() would have to do something totally different for npm
[00:48] okito: me neither
[00:48] ryah: okay
[00:48] ryah: isaacs: yeah hooking it into drain worked
[00:48] okito: for tiki I also implemented the alternate
[00:48] okito: require('package:module')
[00:48] isaacs: okito: npm sets it up so that you could just use regular require()
[00:48] isaacs: require("foo")
[00:48] okito: yes but you have to use a path right?
[00:48] okito: so for example, if I have package foo
[00:48] okito: and I want to include a file at foo/lib/bar.js
[00:48] mikeal has joined the channel
[00:49] cloudhead has joined the channel
[00:49] okito: [assuming "lib" is the base for the JS]
[00:49] okito: then I would have to do
[00:49] isaacs: okito: so, where i'm going (soon) is that you'd do require("foo/bar")
[00:49] okito: require('foo/lib/bar') right?
[00:49] okito: hm
[00:49] isaacs: but foo/lib/bar could be done, too
[00:49] isaacs: it's not coded yet, still talking.
[00:49] okito: so how do you disambiguate between that and a file at 'foo/bar.js'
[00:50] okito: that's why I introduced a separator to distinguish between package & module
[00:50] okito: or a better example
[00:50] CIA-78: node: 03Ryan Dahl 07net2 * r4f56d8a 10/ (lib/net.js src/node_buffer.cc src/node_buffer.h): Rename Buffer.utf8Length to Buffer.utf8ByteLength - http://bit.ly/akl4Wn
[00:50] CIA-78: node: 03Ryan Dahl 07master * r9874412 10/ (src/node.js src/node_file.cc): Callbacks from process.fs always start with error object - http://bit.ly/cNEx1T
[00:50] CIA-78: node: 03Ryan Dahl 07net2 * r33509bd 10/ (lib/http2.js lib/net.js test/mjsunit/test-net-pingpong.js): eof -> end - http://bit.ly/9Qog8e
[00:50] CIA-78: node: 03Ryan Dahl 07master * rce4204a 10/ (4 files):
[00:50] CIA-78: node: Upgrade http-parser
[00:50] CIA-78: node: Fixes, among other things, a header overflow attack. - http://bit.ly/crEVlI
[00:50] okito: if you have a nested package
[00:50] hassox: okito: if you do that you're forcing a file structure on packages yes?
[00:50] okito: do what?
[00:50] okito: require('foo:bar')
[00:51] hassox: attempt to guess what's a module
[00:51] hassox: yeah
[00:51] okito: or require('bar', 'foo')
[00:51] okito: then you are not forcing a file structure
[00:51] okito: it is abstracted
[00:51] okito: the packages can be stored anywhere
[00:51] hassox: abstracted to what?
[00:51] isaacs: ryah: check the file now. it's definitely using a lot of cpu..
[00:51] okito: how you map packageId "foo" to a file root
[00:51] okito: is up to the package manager
[00:52] isaacs: okito: what if i say, whatever is in package "foo" will be placed in the NODE_PATHS as "foo"
[00:52] isaacs: so you can do require("foo/lib/bar") to pull that in
[00:52] jcrosby has joined the channel
[00:52] hassox: no I mean where odo you find the "bar" module of package foo?
[00:52] okito: that doesn't work
[00:52] isaacs: hassox: you just know it's there already
[00:52] ryah: isaacs: http://pastie.org/806908
[00:52] okito: b/c a lot of times your root is not lib
[00:52] okito: foo/lib/bar
[00:52] hassox: isaacs: I mean with a setup like require("bar", "foo")
[00:52] hassox: or rqeuire("foo:bar")
[00:53] isaacs: okito: i was figuring that i'd look at whatever package.json says is the "lib" dir, and put that at the package name.
[00:53] okito: well I am also thinking of another case too which is not node specific
[00:53] okito: oh I see
[00:53] okito: hm
[00:53] isaacs: so, require("foo/bar") would be pulling in the "lib/bar.js" from the tarball.
[00:53] ashb: hassox: require("bar", "foo") is an abomination
[00:54] isaacs: another thought is that you may want to say that the package folder structure maps to the package name.
[00:54] isaacs: yes, require(mod, pkg) is awful
[00:54] hassox: ashb: I'm not suggestion it...
[00:54] okito: I don't want that either
[00:54] hassox: I'm trying to understand what okito is saying
[00:54] ashb: the main problem with it is the precedence order is out
[00:54] ashb: require('mod', 'pkg').exp
[00:54] hassox: I'm happy with require('foo/bar')
[00:54] okito: so here is the other problem with require('foo/bar'):
[00:54] isaacs: i'm happy with either require("foo/bar") or require("foo/lib/bar")
[00:55] okito: what if I have nested packages
[00:55] okito: so if I do require('foo/bar/baz')
[00:55] okito: do I want bar/baz in foo or baz in foo/bar ?
[00:55] isaacs: ryah: that's roughly what i'm doing.
[00:55] ashb: nested packages don't exist
[00:55] isaacs: okito: imo, "nested packages" is a terible idea.
[00:55] isaacs: i know that there are commonjs packages doing that now.
[00:55] isaacs: but it's a nightmare.
[00:56] hassox: okito: you want whatever is defined at "foo/bar/baz"
[00:56] isaacs: i'm going gobolinux on this problem.
[00:56] isaacs: we're gonna use the file system to manage files.
[00:56] isaacs: that means that nothing about node or its require function has to change, even a little.
[00:56] ryah: isaacs: try with the latest node now
[00:56] hassox: it's almost there
[00:57] okito: well nested packages exist for SproutCore
[00:57] okito: they are actually really useful
[00:57] isaacs: ryah: hah! FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory
[00:57] isaacs: eventually
[00:57] isaacs: ok, i saw you pushed some stuff, i'll update and retest
[00:57] hassox: okito: what and why?
[00:57] hassox: Not to say they're not
[00:57] hassox: or they are
[00:57] okito: we have a pretty large team here
[00:57] hassox: just wanting to understand ur point of view
[00:57] okito: let's say 100 engineers
[00:57] okito: working on lots of different projects
[00:57] okito: split into different repositories
[00:57] Tim_Smart: Anyone know if I can un-cache a module?
[00:57] isaacs: Tim_Smart: check out the "hot loading" stuff on the list.
[00:58] okito: nested packages allows a group to own an umbrella package plus some subcomponents inside of that
[00:58] Tim_Smart: isaacs: I need a modified branch according to one blog post
[00:58] okito: er nested packages inside of that
[00:58] isaacs: ryah: only getting 1 million bases pwned before i'm disconnected.
[00:58] isaacs: and the server doesn't crash. nicely done
[00:58] voodootikigod_ has joined the channel
[00:58] okito: this gives you a lot of flexibility
[00:58] hassox: okito: so how is that different to just having multiple packages differentiated by name?
[00:58] isaacs: before it was crashing around 11-12 million
[00:59] okito: because they are nested
[00:59] okito: so foo
[00:59] okito: may live in foo.git
[00:59] hassox: which require other packages that they depend on
[00:59] okito: and inside of foo is
[00:59] isaacs: okito: why not just have dependencies?
[00:59] okito: foo/bar
[00:59] okito: foo/baz
[00:59] isaacs: or naming conventions?
[00:59] isaacs: git-core, git-utils, git-completion, etc.
[00:59] hassox: exactly
[00:59] okito: well when you get down to it nested packages are really a kind of naming convention
[00:59] isaacs: with a metapackage that requires a bunch of things.
[00:59] hassox: okito: not quite
[00:59] isaacs: okito: ok, i'm gonna punt on that,then
[00:59] hassox: because in ur package... you can "nest" other packages by depending on them
[00:59] isaacs: it seems like a clever feature in search of a use.
[01:00] okito: it is very useful for us
[01:00] hassox: okito: could it not be implemented like that?
[01:00] okito: it gives developers a way to group functionality into modules
[01:00] isaacs: sure, but it's not giving you anything you couldn't do with reqs and naming conventions.
[01:00] okito: modules is bad word
[01:00] isaacs: replace / wiht -, and you've got your thing.
[01:00] okito: I mean into chunks that are easier to diagnose
[01:01] okito: except as a developer when I am trying to look at all my source it is a lot easier to look at a few top-level packages
[01:01] okito: then dive down into sub packages
[01:01] okito: to understand how the code related
[01:01] hassox: okito: I'm not sure why these aren't available using composition and dependnecies inside packages
[01:01] okito: relates
[01:01] isaacs: okito: at yahoo, i've had to solve the same problem using a single "layer" of packages.
[01:01] hassox: and one package just depends on another to create the "nested" feature
[01:01] isaacs: and you can just do it with requirements, meta packages, and convention.
[01:01] okito: I'm not saying it can't be done with a single layer
[01:01] okito: just that it is useful to have nesting
[01:01] okito: in my case we have dozens of these packages in existence already nested also
[01:01] hassox: okito: I think you can...
[01:01] okito: so I need to find a way to make them work
[01:01] isaacs: okito: i'm not meaning to shut down your suggestion so much as postpone it.
[01:02] isaacs: but it seems like your'e making a good case for not moving the lib folder around, and instead just using require("foo/lib/bar")
[01:02] okito: ok. so you're opposed to supporting it altogether?
[01:02] isaacs: then, you could (later) work something out where it installs the "bar" package *inside* the foo package dir.
[01:02] Tim_Smart: Hmm I got an idea for hotloading code :p
[01:03] Tim_Smart: with the current head branch
[01:03] tlrobinson: narwhal supports nested packages but in my experience they're only good for narwhal's virtualenv-like thing
[01:03] hassox: okito: I don't see that it gains anything that you can't already do
[01:03] tlrobinson: none of the packages in the package repo are nested
[01:03] isaacs: okito: no, i'm not opposed in theory. but i think it'd add complication without much gains, and package management is a sea of complication as it is.
[01:03] isaacs: i'm mostly trying to get to a sound core that is useful, first.
[01:03] okito has joined the channel
[01:03] tlrobinson: dependencies seem better for getting a group of packages
[01:04] isaacs: and since i probably won't use that feature, i'm not too motivated to write it ;)
[01:04] isaacs: tlrobinson: that's been my experience, as well.
[01:05] hassox: okito: say I had foo that depended on bar and in foo, it made bar available at foo.bar
[01:05] hassox: don't you have nested deps then?
[01:05] isaacs: hassox: well, as i understand it, nesting packages is a bit like a metapackage that bundles its deps inside it.
[01:06] isaacs: so you install fab, let's say, and inside fab, there's fab-utils, and fab-middleware, and whatnot.
[01:06] isaacs: but from the consumer pov, it's just "fab" and it's all one thing.
[01:06] deanlandolt: to me that can all be managed by good dependency resolution at install
[01:06] isaacs: and from a fab developer's pov, he can build and push a new fab/utils which will be included now, without having to also worry about colliding with fab/middleware.
[01:07] isaacs: deanlandolt: sure, and it's essentially a cosmetic thing. (i don't want to misrepresent your sugg, okito, feel free to correct me if you understand it differently)
[01:07] tmpvar has joined the channel
[01:08] deanlandolt: okito: i'm still trying to grep it too (just reading the logs now) but is there any prior art of package managers doing nested packages similar to what you're angling for?
[01:08] hassox: http://gist.github.com/293237
[01:08] hassox: isaacs: okito ^^
[01:08] hassox: why not that
[01:09] okito: well we do nested packages in sproutcore
[01:09] mikeal has joined the channel
[01:10] tlrobinson: deanlandolt: in narwhal it's a feature of narwhal itself rather than the package manager. it recursively looks for packages within a package's packages direction
[01:10] okito: it's nice because you can tell someone to checkout 'sproutcore' and they get all the nested packages
[01:10] hassox: okito: that would provide you with nexted packages yes?
[01:10] tlrobinson: *directory
[01:10] deanlandolt: hassox: for brevity you can do var foo = exports.Foo = {}
[01:10] hassox: deanlandolt: thanx :D
[01:10] okito: that gist?
[01:10] hassox: okito: yeah
[01:10] okito: no
[01:10] hassox: okito: you just require('foo') and you get bar along with it for free
[01:10] deanlandolt: tlrobinson: couldn't it be a feature of tusk though?
[01:11] hassox: okito: how does it differ?
[01:11] deanlandolt: e.g. tusk install sproutcore, which should resolve all deps...and in sproutcore something like exports.utils = require("sproutcore-utils")
[01:12] deanlandolt: tlrobinson: rather, couldn't it *just* be a feature of tusk (it already *is* a feature of tusk, i know)
[01:12] okito: the issues is organization on disk
[01:12] okito: tusk nested packages is fine for me
[01:12] hassox: okito: ?
[01:12] deanlandolt: okito: ah, i'll buy that
[01:13] hassox: why does it need to be nested on disk?
[01:13] hassox: having it as speerate packages on disk means that different teams can be granted access to different repos
[01:13] hassox: what am I misisng mate?
[01:13] okito: take a look at http://github.com/sproutit/sproutcore
[01:13] okito: this is what I am porting over
[01:13] okito: sub frameworks with packages
[01:14] hassox: so the frameworks part?
[01:15] okito: yes
[01:15] isaacs: okito: what if you just created packages starting with "sproutcore-" and a meta package called "sproutcore" that brought them all in?
[01:15] isaacs: okito: it would'nt look as pretty, but is there any difference besides cosmetics?
[01:15] hassox: isaacs: that's what I mean
[01:16] okito: isaacs so part of my concern there is cosmetic
[01:16] okito: but also you would have to put all of those into their own git repo
[01:16] okito: it's the reason you put your source into folders
[01:16] okito: it's easier to maintain
[01:17] hassox: okito: but you said before you wanted to control some teams having access to this part and some to that part
[01:17] hassox: if they're all just in one repo how do yo do that?
[01:18] isaacs: okito: ok, but there are ways around the git issue.
[01:18] isaacs: all that npm requires is a tarball and a name.
[01:18] okito: hassox that's not what I meant
[01:18] hassox: oh
[01:18] isaacs: and the tarball has to have a package.json inside
[01:18] okito: I meant that teams can have all their code grouped into a single repository
[01:19] pjb3 has joined the channel
[01:19] isaacs: but whether that's git submodules or what, does it really matter?
[01:19] okito: submodules don't really work well
[01:19] okito: you have to commit independently
[01:19] isaacs: ACTION doesn't love submodules...
[01:19] okito: they are fragile
[01:19] isaacs: yeah
[01:19] okito: I guess my point is just that nested packages allow you to organize very large projects
[01:19] hassox: I don't like them either
[01:19] isaacs: you could use the hack-module approach. just do git init inside a sub folder
[01:19] okito: in the same way you would organize your source code into folders
[01:19] okito: that's why it should be supported
[01:20] hassox: okito: what prevents you from requiring relative files in sproutcore?
[01:20] okito: what do you mean?
[01:20] hassox: require('../frameworks/foo')
[01:20] okito: what if I'm not in sproutcore?
[01:20] hassox: if everythign is isnide the one package
[01:20] hassox: what do you mean
[01:20] okito: like I might build an app that only depends on
[01:20] okito: sproutcore/runtime
[01:20] okito: and sproutcore/datastore
[01:20] hassox: ah i see
[01:20] okito: for example
[01:21] isaacs: okito: well, ok. you've made the strongest case i've yet heard for sub-packages. (in that, I can kinda see the sense in it, at all.)
[01:21] isaacs: nevertheless, i'm not sure it's a big enough use case to support in npm initially.
[01:21] hassox: so what about require('sproutcore/frameworks/runtime')
[01:21] isaacs: i'm not opposed to exploring it in the figure.
[01:21] tmpvar: okito, does sproutcore require a dom?
[01:22] isaacs: and, it's helped settle the foo/bar vs foo/lib/bar question.
[01:22] okito: isaacs well if I added it would you accept it?
[01:22] hassox: isaacs: foo/lib/bar sucks a bit
[01:22] okito: I just need some guidance on how require() should handle it
[01:22] isaacs: okito: if it didn't flub up everything else.
[01:22] okito: tmpvar only some parts
[01:22] isaacs: first, i need to support non-nested packages!
[01:22] hassox: isaacs: are you saying foo/bar or foo/lib/bar is the way to go?
[01:22] hassox: ACTION prefers foo/bar
[01:22] isaacs: hassox: foo/lib/bar
[01:22] hassox: booo
[01:22] deanlandolt: okito: just so you know, there was some discussion earlier about node gutting require entirely and having it (optionlly) subsumed by narwhal's implementation
[01:23] isaacs: so, structure your packages that way.
[01:23] hassox: bad
[01:23] okito: isaacs what about nested?
[01:23] hassox: that puts everything into the root of the package
[01:23] tmpvar: okito, just as an fyi: http://github.com/tmpvar/jsdom -- finishing up dom level 1 now
[01:23] isaacs: deanlandolt: do not want.
[01:23] hassox: things that aren't related to the package
[01:23] hassox: like readme's and stuff
[01:23] isaacs: hassox: ugh. true.
[01:23] hassox: if all package contents is sub dir'd to lib
[01:23] hassox: then you can have
[01:23] hassox: sproutcore/lib/frameworks
[01:23] hassox: and then do
[01:23] deanlandolt: isaacs: understood...just relaying what i read
[01:23] hassox: require('sproutcore/frameworks/foo')
[01:24] okito: oh
[01:24] okito: hm
[01:24] hassox: okito: would that work for you?
[01:24] okito: one sec...sorry someone in my office
[01:24] tmpvar: handle it!
[01:24] tmpvar: heh eh eh heh
[01:27] tlrobinson: meh i prefer package/lib being added to the search paths, so you would have package/lib/package.js package/lib/package/submodule.js etc. exactly like ruby, no?
[01:29] steadicat has joined the channel
[01:29] hassox: tlrobinson: I've fought many packages that do that
[01:29] isaacs: tlrobinson: ew.
[01:29] isaacs: foo/lib/foo/bar.js
[01:29] hassox: tlrobinson: if that happens you have to ensure that pacakages behave and don't pollute their lib dir
[01:29] hassox: tlrobinson: in ruby it's actully the foo dir that is added, where foo contains lib and foo.rb
[01:30] hassox: isn't it?
[01:30] isaacs: that leaves you with the option of a) having a big dumping ground where all packages put their stuff, or b) having a very long requrie.paths
[01:30] tlrobinson: hassox: i don't think so
[01:30] hassox: tlrobinson: I'd have to have athink about it...
[01:30] okito: hassox require('sproutcore/frameworks/foo') definitely requires a specific file structure
[01:30] hassox: but it gives packages the ability to clash
[01:30] isaacs: how many packages have a "utils.js"?
[01:30] okito: the reason CommonJS proposes require('module', 'pkg')
[01:30] tlrobinson: http://github.com/tlrobinson/rack/tree/master/lib/
[01:30] isaacs: blah/lib/utils.js
[01:30] hassox: okito: it does... but the package manager doesn't force that... it's the package that can define it
[01:30] isaacs: they all do
[01:31] tlrobinson: rack.rb and rack
[01:31] okito: is it allows the underlying system to decide pkg
[01:31] okito: and how that maps
[01:31] okito: so it is obvious
[01:31] hassox: tlrobinson: that's what I meant
[01:31] hassox: :P
[01:31] okito: I don't like the API
[01:31] tlrobinson: isn't that what i said
[01:31] hassox: you have lib that has a single file foo.rb and then a foo dir ;)
[01:31] hassox: haha
[01:31] isaacs: okito: but we can do the same thing at the package manager level.
[01:31] hassox: yeah
[01:31] okito: but to me separating packageID from moduleId is the most sane
[01:31] hassox: ACTION is multitasking a bit too much
[01:31] tlrobinson: hassox: right, it seems pretty logical to me
[01:31] isaacs: tlrobinson: i'm trying to reduce the repetition.
[01:32] okito: tlrobinson the problem is it is easy to stomp on another package
[01:32] hassox: tlrobinson: I like ruby's setup provided gems obey it (Which most do now)
[01:32] isaacs: also, not rely on sanity in the package creation structure, and not have a long require.paths
[01:32] okito: if you don't know the naming pattern
[01:32] okito: what about require('packageId:module')
[01:32] okito: and optionall require('packageId') which would map to
[01:33] tlrobinson: hassox: it's pretty obvious if a gem doesn't obey it, it will have something other than "foo.js" and "foo" directory in lib
[01:33] tlrobinson: 3
[01:33] okito: 'packageId:index'
[01:33] hassox: tlrobinson: correct.. but you have to inspect source to know..
[01:33] hassox: tlrobinson: all I'm saying is that foo could contain bar.rb as well
[01:33] okito: well I can say we all agree that everyone has a different preference. :)
[01:34] hassox: then if you install a 'bar' gem that does play by the rules, and the load path is added for foo/iib then you're buggered
[01:34] hassox: sorry foo/lib could contain bar
[01:34] deanlandolt: tlrobinson: then explain: http://github.com/tlrobinson/browserjs/tree/master/lib/browser/ ;)
[01:34] isaacs: ACTION is not convinced that "just like ruby" is a feature
[01:34] tlrobinson: deanlandolt: http://github.com/tlrobinson/browserjs/tree/master/lib
[01:34] hassox: deanlandolt: yeah you're one level too far
[01:35] deanlandolt: the package is called browserjs, right?
[01:36] tlrobinson: deanlandolt: yes there's a slight mismatch between the module names and package name
[01:36] isaacs: im thinking, you install 20 packages. now you've either dumped 20 packages' "lib" folder contents into one place (ugh) or your require.paths has to traverse over 20 folders.
[01:36] hassox: isaacs: it's not that ruby is bad... it's very good..
[01:36] tlrobinson: i didn't want a package called "browser" :)
[01:36] hassox: but having the load paths end up weird sucks
[01:36] okito: right now node.js does something really smart I think by looking for an index.js
[01:36] okito: to match a folder name
[01:36] okito: I think that is more sane than the ruby model
[01:36] sahnlam has joined the channel
[01:37] isaacs: i'm not saying ruby is bad.
[01:37] isaacs: ruby is very good.
[01:37] deanlandolt: yeah -- but the "browser" prefix has the same effect, stomping on anything else in require.paths
[01:37] hassox: okito: is sproutcore still on merb? (or was it ever?)
[01:37] okito: it was
[01:37] tlrobinson: it's just a different convention
[01:37] okito: it still used ruby
[01:37] isaacs: but that doesn't mean that everything ruby does is perfect, and if we're in a positin ot make it better, why not?
[01:37] hassox: right
[01:37] okito: just straight rack
[01:37] hassox: isaacs: agreed
[01:37] hassox: isaacs: I think removing the requirement for every package to be on the load path is a good thing
[01:37] okito: one reason I'm exploring this is I might rewrite our build tools from ruby to node
[01:38] isaacs: okito: that'd be cool.
[01:38] okito: ok so if I'm willing to make changes what if I did this:
[01:38] okito: 1. I'll modify node.js so that require() can be overloaded
[01:38] hassox: tlrobinson: but I also think that having a familiar structure with an entry point like ruby has is also a good ting
[01:39] okito: 2. I'll do a branch of some package manager and implement whatever works for me
[01:39] tlrobinson: hassox: if the packages aren't on the load path then do have to provide a custom loader?
[01:39] okito: since require() can be changed
[01:39] tlrobinson: like gem does
[01:39] okito: we can have multiple competing package mangers
[01:39] okito: until a pattern emerges
[01:39] isaacs: tlrobinson: i'm suggesting having the modules on the load path, but following a specific convention.
[01:39] okito: we need to let people create competing implementions until a good one merges
[01:39] isaacs: so i'll create a foo.js and a foo/ folder.
[01:39] hassox: tlrobinson: they need to provide some file to load...
[01:39] isaacs: foo.js will map to the "main" entry point module.
[01:40] isaacs: foo/ will map to the "libs" directory
[01:40] hassox: if that's index.js or foo.js inside foo/lib/foo.js it doesn't matter much
[01:40] konobi: ryah: so AMQP ftw?
[01:40] hassox: isaacs: yeah I like that
[01:40] hassox: just mho though
[01:40] tlrobinson: in narwhal the packages system just pushes each package's lib directory onto the load path. couldn't be simpler
[01:40] isaacs: okito: i'm all about competing package managers. that's win
[01:40] isaacs: tlrobinson: right, but it also couldn't be less efficient.
[01:40] okito: ryah: would you be interested in a patch for node.js that allows require() to be overloaded?
[01:40] okito: this way ppl could write multiple competing package managers
[01:40] isaacs: also, that opens the door for mass clobbering.
[01:40] hassox: tlrobinson: it also allows weird things to happen
[01:40] okito: so we can experiment
[01:40] isaacs: again, who's lib/utils.js gets pulled in when i require("utils")?
[01:41] hassox: lunching
[01:42] tlrobinson: if you have multiple "utils" packages who's does?
[01:42] deanlandolt: isaacs: back to tlrobinson's point, you should have to do a require("mypackage/utils"), or a require("./utils") from inside your own lib
[01:42] ryah: konobi: this weekend i'm going to write my own message queue server
[01:42] hassox: tlrobinson: misbehaving packagtes do
[01:42] konobi: lol
[01:43] hassox: tlrobinson: multiple versions of packages do
[01:43] isaacs: deanlandolt: if pkg/lib has been added to the search paths, though...
[01:43] isaacs: then what?
[01:43] isaacs: again, require("utils") brings in some random junk.
[01:43] deanlandolt: it's pkg/lib/pkg/utils.js
[01:43] isaacs: i dont' want to be open to that kind of error, since it's so easy to make, and so easy to prevent.
[01:43] okito: btw tmpvar your dom pkg looks cool!
[01:43] deanlandolt: perhaps too nested for your liking, but workable
[01:43] isaacs: deanlandolt: but let's say i didn't use that folder structure.
[01:43] ryah: okito: mmm no?
[01:43] ryah: okito: i'd rather override the entire src/node.js than just require()
[01:44] tmpvar: okito, thanks!
[01:44] tmpvar: finishing live events, if xorg would play nice
[01:44] deanlandolt: isaacs: noone says you have to...just that you're a jerk if you don't (until we have a package handling in require :)
[01:44] tmpvar: live lists rather
[01:44] isaacs: deanlandolt: we could just have good package handling in the package handler, and not have to change require() at all, and not have to worry about the jerks, either.
[01:44] okito: ryah is that possible?
[01:45] isaacs: just segregate each package's lib folder.
[01:45] okito: how would I do that?
[01:45] okito: it's fine with me
[01:45] deanlandolt: isaacs++ (Wes and ashb have been screaming from the rooftops for that for months)
[01:45] isaacs: yep.
[01:46] tlrobinson: (FWIW narwhal depends heavily on the overlaid libs behavior to support multiple platforms)
[01:46] mindware has joined the channel
[01:47] tmpvar has joined the channel
[01:47] okito: tlrobinson how close are you to having node support in narwhal?
[01:47] isaacs: tlrobinson: that could still be done, though
[01:47] deanlandolt: that could still be done *or* the package manager could do the /engines/ shuffling
[01:48] tlrobinson: okito: i'm not actually sure, kris kowal is working on it
[01:48] atcrabtree has joined the channel
[01:48] isaacs: tlrobinson: so, you could install engine specific stuff into engines/ and then other stuff into libraries/, and put engines/ ahead of libraries/ in the search paths
[01:48] isaacs: or something like that
[01:48] deanlandolt: but in order to do this cohesively there would have to be some convention for engine-specific code (narwhal's is very clear and sane)
[01:49] isaacs: deanlandolt: true.
[01:49] isaacs: i rather like only having one engine.
[01:49] tlrobinson: isaacs: so what you're discussing only applies to packages?
[01:49] isaacs: tlrobinson: yes
[01:49] deanlandolt: isaacs: yeah, makes it easy and all but what if you /really/ want your package to run on as many engines as possible (e.g. pintura)
[01:50] tlrobinson: well, narwhal's premise is to provide support for multiple engines :)
[01:50] isaacs: yep.
[01:51] deanlandolt: tlrobinson: exactly...is it the only project with that goal?
[01:51] tlrobinson: deanlandolt: yes, AFAIK
[01:51] deanlandolt: if so, there's no sense in trying to standardize the /engines/ package convention
[01:52] hassox_ has joined the channel
[01:52] tlrobinson: deanlandolt: not necessarily, it would be nice to be able to have packages which support multiple platforms
[01:52] deanlandolt: agreed...but it'd still be narwhal specific -- until someone else came along with a similar goal
[01:53] tlrobinson: deanlandolt: i mean you could have a CommonJS package which supports node, and narwhal, and flusspferd, and gpsee, and the browsers, etc
[01:53] technoweenie has joined the channel
[01:53] deanlandolt: yes, but woudln't it require narwhal...
[01:54] deanlandolt: in the sense that it needs to run in, on, or around narwhal (as in, one of the many ways you could boostrap narwhal into your code)
[01:55] isaacs: this has been very productive.
[01:55] tlrobinson: correct. as long as each platform followed the same convention
[01:55] cloudhead: inimino: how's the parser coming along?
[01:56] RayMorgan has joined the channel
[01:57] okito: isaacs - so just to finalize - I'm going to look into making npm basically own "require"
[01:57] okito: so someone could fork and experiment with it
[01:57] okito: and we can see what feels most comfortable
[01:57] isaacs: okito: rather than try to replace require(), you could hook it onto npm.require()
[01:58] okito: sure
[01:58] atcrabtree: anyone able to recommend a good couchdb node.js implementation?
[01:58] isaacs: okito: if you get too far afield, please rename npm to something else.
[01:58] okito: ok well I could just do my own thing that is fine too
[01:58] isaacs: okito: i just don't want it to be confusing. feel free to steal all my code, though
[01:58] okito: the point is to design something that makes it easy for people to fork it
[01:58] isaacs: suresure
[01:58] okito: absolutely I understand
[01:59] Yuffster has joined the channel
[01:59] isaacs: but as long as we have roughly the same goals and principles at work, i mean, that's fine. i certainly dont' wanna turn down contribution!
[01:59] okito: ok well I'll see what I come up with
[01:59] deanlandolt: atcrabtree: try xhr -- it'll go pretty far :)
[01:59] okito: whatever i build will also work in the browser so that is my other requirement
[01:59] isaacs: okito: yikes.
[02:00] isaacs: imo, the browser has a completely different set of requirements.
[02:00] okito: well not really
[02:00] okito: node.js is async
[02:00] okito: browser is async
[02:00] isaacs: should be treated as a way different platform. same language, maybe, but so strange.
[02:00] isaacs: okito: node.js also has IO and an http server and socket connections.
[02:00] isaacs: and posix and all the rest.
[02:00] isaacs: the filesystem isn't very much like the browser.
[02:01] atcrabtree: deanlandolt: thx, raw xhr =) have people ported jquery to node?
[02:02] okito: well I'm not going to port the stuff that doesn't make sense in node
[02:02] okito: but Eventemitter, Promise, etc
[02:03] isaacs: okito: but i mean, npm fetches a tarball, reads the files, moves stuff around in the folders, etc.
[02:03] isaacs: *none* of that makes sense in a browser.
[02:03] okito: no that doesn't
[02:03] isaacs: that's most of what it does...
[02:03] okito: but code written as packages
[02:03] isaacs: s/most/all/
[02:04] okito: will then be packaged into .JS files to deliver to the browser
[02:04] mattly has joined the channel
[02:06] deanlandolt: atcrabtree: wrap raw xhr with a nicer interface
[02:06] deanlandolt: i recommend jsgi-client in http://github.com/kriszyp/commonjs-utils
[02:06] atcrabtree: deanlandolt: yes. just curious if anyone... oh, thx
[02:07] rtomayko_ has joined the channel
[02:08] binary42_ has joined the channel
[02:08] deanlandolt: atcrabtree: it'll take a jsgi request and return a promise of a jsgi response...it adds a request.url prop to make it so that you don't have to dump in all the incidentals separately (scheme, host, port, blah)
[02:13] inimino: cloudhead: coming pretty well, should have a little blog post up this week... I've just got some client work to get out of the way first
[02:13] inimino: ACTION has to eat and all that stuff
[02:14] inimino: > inimino.clone()
[02:14] stephenlb: heh
[02:17] okito has joined the channel
[02:26] atcrabtree: deanlandolt: do i have to include commonjs-utils in the node/libraries folder for when I include it, or can I specify an include path?
[02:26] atcrabtree: deanlandolt: sorry, nm
[02:26] deanlandolt: atcrabtree: should be able to specify an include path
[02:28] isaacs: atcrabtree: you can put stuff in ~/.node_libraries
[02:29] atcrabtree: isaacs: sorry, i don't quite follow
[02:30] isaacs: atcrabtree: ~/.node_libraries is in the include path.
[02:30] isaacs: or you can also set an environment variable for NODE_PATHS
[02:30] deanlandolt: or require.paths.push your way into win
[02:31] atcrabtree: nice
[02:37] Yuffster has joined the channel
[02:41] jwm: anyone play with websockets ?
[02:41] jwm: I'm getting a flash error I assume
[02:41] jwm: on firefox but I don't get it on other installs of firefox
[02:42] jwm: nor safari, nor chrome
[02:42] jwm: it's killing me hehe
[02:46] CIA-78: node: 03Ryan Dahl 07master * rc723acc 10/ src/node_http.cc :
[02:46] CIA-78: node: Remove some HandleScopes from HTTP
[02:46] CIA-78: node: for a %2.5 improvement in hello world HTTP score. - http://bit.ly/b5SUce
[02:46] CIA-78: node: 03Ryan Dahl 07net2 * r7c9919f 10/ src/node_http_parser.cc : Remove some unnecessary handlescopes - http://bit.ly/cIjWx7
[02:46] CIA-78: node: 03Ryan Dahl 07net2 * rc44f0ed 10/ src/node_http.cc : Remove some HandleScopes from HTTP - http://bit.ly/agtHAj
[02:48] Tim_Smart: ryah: Is it possible to merge a un-cache method when require a module for hot-loading
[02:49] ryah: Tim_Smart: still waiting to hear back from felix and blaine on it
[02:50] jan____ has joined the channel
[02:50] Tim_Smart: ok
[02:52] jan____ has joined the channel
[02:54] deanlandolt_ has joined the channel
[02:58] sudoer has joined the channel
[03:01] JimBastard has joined the channel
[03:02] JimBastard: yeah im finally home from work doing javascript so i can go home and work on maah node project! huzaah!
[03:03] hassox: JimBastard: haha
[03:03] jan____ has joined the channel
[03:05] JimBastard: mwahahaha
[03:06] tmpvar: what a bastard
[03:08] hassox: yes.. we've got a video!
[03:09] binary42 has joined the channel
[03:09] scudco has joined the channel
[03:12] stephenlb: hassox: video of the bastard or the project?
[03:13] hassox: "what a bastard" reminded me of an episode of the young ones
[03:13] stephenlb: ah
[03:13] unomi has joined the channel
[03:20] brosner has joined the channel
[03:21] brosner has joined the channel
[03:24] markwubben has joined the channel
[03:26] teemow has joined the channel
[03:34] ryan_ has joined the channel
[03:40] Tim_Smart: JimBastard: What is your github name?
[03:41] JimBastard: http://github.com/marak
[03:42] JimBastard: ZOMG GITHUB FRIENDS
[03:43] Tim_Smart: wait, I had already added you...
[03:43] Tim_Smart: http://github.com/Tim-Smart/biggie
[03:44] Tim_Smart: you have teh collaborator access
[03:44] Tim_Smart: I might make a biggie account though, and fork it
[03:46] tmpvar has joined the channel
[03:47] tmpvar: hating xorg right now
[03:48] jwm: don't be hating
[03:48] tmpvar: i must have a driver issue.. stuff explodes on a seemingly random interval
[03:49] bryanl has joined the channel
[03:50] JimBastard: woot
[03:50] jwm: heh
[03:50] JimBastard: biggie!!!
[03:50] jwm: ati tmpvar?
[03:50] sudoer has joined the channel
[03:50] tmpvar: fortunately, no.. nvidia running closed source drivers
[03:51] tmpvar: compiz-fusion might also have something to do with it heh
[03:51] JimBastard: ive got some artwork maybe, brb
[03:52] tmpvar: http://img145.imageshack.us/img145/1756/screenshot007jf.png
[03:52] jwm: compiz was really stable for me
[03:52] tmpvar: failure land
[03:52] tmpvar: it has been for me as well.. up until yesterday
[03:52] jwm: just does 2d stuff
[03:52] jwm: anytime there is a crash they say it can't be their fault :)
[03:52] tmpvar: i managed to catch a screeny by jumping into term and back lol
[03:52] jwm: could be mesa's though
[03:52] tmpvar: hahaha, yeah.. its easy for them to punt
[03:52] jtoy has joined the channel
[03:53] tmpvar: dunno, look at the screenshot lol
[03:53] jwm: most of my problems came from mesa/graphics driver hehe
[03:53] jwm: looks like it froze
[03:53] tmpvar: yeah, but it wasnt frozen
[03:53] jwm: interesting
[03:53] jwm: :)
[03:53] tmpvar: that image became my desktop wallpaper hah
[03:54] tmpvar: fubard the borders on the windows and such
[03:54] tmpvar: ah well.
[03:54] jwm: I noticed with my video card driver I couldn't turn on one of the window effects
[03:54] jwm: or I'd have major issues
[03:54] jwm: but that was due to their usage of a specific gl for that effect
[03:54] jwm: hehe
[03:55] jwm: nothing beats the keyboard friendly effects
[03:55] jwm: I ran compiz barebones
[03:55] jwm: great windowmanager
[03:56] tmpvar: yeah
[03:56] tmpvar: what card do you have?
[04:00] jwm: well I sent it all back
[04:00] jwm: tx2 tablet
[04:00] jwm: after spending 2 weeks getting the touch working and everything
[04:00] jwm: hehe
[04:00] jwm: had an amd 3200 card in it
[04:00] jwm: actually pretty decent card
[04:03] bpot has joined the channel
[04:04] mattly has joined the channel
[04:05] tmpvar: havent heard of it heh
[04:06] jwm: it's a few steps above intel crap
[04:09] tmpvar: ah, im one of those gamer tards
[04:09] jwm: tx2 is a tablet
[04:09] jwm: try putting a gaming card on one of those
[04:09] jwm: hehe
[04:09] jwm: the thing already burnt my lap
[04:09] jwm: stupid ass amd processor
[04:09] jwm: ohh god the heat
[04:10] jwm: I don't know how it lasted the month I had it
[04:11] Tim_Smart: JimBastard: It has moved :o http://github.com/biggie/biggie
[04:11] Tim_Smart: so we can have our own forks
[04:11] JimBastard: way ahead of you
[04:11] JimBastard: ;-)
[04:11] JimBastard: (refresh page)
[04:11] Tim_Smart: lol
[04:12] JimBastard: do you know of coffee script?
[04:13] JimBastard: http://jashkenas.github.com/coffee-script/
[04:16] Tim_Smart: I do now :
[04:16] Tim_Smart: :p
[04:17] JimBastard: it might be a shame to write a huge ass js framework and not use coffeescript
[04:17] JimBastard: im not too sure
[04:18] JimBastard: if we are doing 1:1 syntax for front and back we will need to wrap a lot of methods
[04:18] Tim_Smart: Well I like too make I know what all my prototypes are doing etc
[04:18] Tim_Smart: *make sure
[04:18] JimBastard: i met the dude who built coffee and underscore, same guy
[04:18] JimBastard: hes pretty cool
[04:19] JimBastard: anyway
[04:19] JimBastard: i gotta finish this tutorial on mustache you should get some things in the repo, maybe start a wiki / directory structure
[04:21] Tim_Smart: I guess we could use coffee script
[04:22] Tim_Smart: not sure if it will affect performance any though...
[04:25] sahnlam has joined the channel
[04:26] tmpvar: wow, i keep shooting myself in the foot with this live list implementation
[04:30] JimBastard: jquery?
[04:31] JimBastard: liVE LIST?
[04:31] JimBastard: errr
[04:31] JimBastard: Tim_Smart i say fuck it on coffeescript
[04:31] JimBastard: coffeescript should techinically still work with biggie if we keep the API simple enough to follow
[04:32] JimBastard: no point using it to build biggie itself
[04:32] jubos has joined the channel
[04:33] Tim_Smart: yeah keep it in javascript I say
[04:34] testerex has joined the channel
[04:36] Tim_Smart: JimBastard: When the patch to un-cache modules lands, we have make app that never have to be restarted
[04:36] Tim_Smart: apps*
[04:36] Tim_Smart: hows that for deploying code :p
[04:37] tmpvar: JimBastard, im working on a pure js dom, level 1 currently
[04:37] tmpvar: 3 tests failing, only thing remaining is the monster that is nodelist which is live
[04:38] Tim_Smart: tmpvar: John Resig implemented DOM in JS, have you checked that out?
[04:39] tmpvar: envjs is tightly bound to rhino
[04:40] tmpvar: not to mention they start at level 2 ish
[04:40] tmpvar: they being jresig / chris thatcher
[04:40] JimBastard: yeah like
[04:40] JimBastard: can jQuery work server-side?
[04:41] tmpvar: on envjs, yes
[04:41] JimBastard: does it really work?
[04:41] tmpvar: its a simulated browser environment
[04:41] JimBastard: docs?
[04:41] tmpvar: yeah, works pretty well
[04:41] tmpvar: docs for envjs?
[04:41] JimBastard: i mean ive seen it before
[04:41] JimBastard: but not actually doing jquery things
[04:41] JimBastard: that are useful
[04:42] JimBastard: i guess it just runs the unit tests
[04:42] tmpvar: i guess you could load jquery into it as of jresigs version
[04:42] JimBastard: i should probaly try it out
[04:42] okito has joined the channel
[04:42] JimBastard: i dunno though
[04:42] tmpvar: chris thatcher has been rolling with it for a while
[04:42] JimBastard: what do you really need dom selection for on the backend
[04:42] tmpvar: my use case is templating
[04:42] JimBastard: mustache?
[04:43] tmpvar: nah, something less destructive to the templates
[04:43] tmpvar: none of this replacing of tags
[04:43] tmpvar: so the same template engine could be run on the browser
[04:43] JimBastard: can you show me the use case in like 10 lines or less?
[04:43] JimBastard: mustache works on the front
[04:43] tmpvar: doubtful, its still being spec'd hehe.
[04:43] tmpvar: something close to pure
[04:44] JimBastard: something from the ground up would probaly make sense
[04:44] bpot has joined the channel
[04:44] JimBastard: i mean, to build the $ and continious monad is very easy
[04:44] JimBastard: i have that code from JQuery
[04:45] JimBastard: so you can chain
[04:45] tmpvar: yeah, haven't arrived there yet. wanted to get level 1 done
[04:45] JimBastard: you got any code yet?
[04:45] tmpvar: parserless, just simply a dom
[04:45] tmpvar: yeah dude :)
[04:45] tmpvar: for the templating or the dom?
[04:45] tmpvar: dom: http://github.com/tmpvar/jsdom
[04:46] tmpvar: templating engine has been back-burner'd pending the dom and some design time
[04:47] JimBastard: do you explain what lvl 1 2 and 3 are?
[04:47] tmpvar: currently no
[04:47] tmpvar: ive been basing all of my work off of the dom level 1 spec / tests
[04:48] JimBastard: i see
[04:48] JimBastard: hrmmm
[04:48] JimBastard: looks like a good start
[04:48] JimBastard: but at the same time i feel like redoing all that is a bit crazy
[04:48] tmpvar: im open to criticism
[04:49] tmpvar: yeah
[04:49] JimBastard: it depends though on what you are trying to do
[04:49] tmpvar: true, i think level 1 should work perfectly for my needs
[04:49] tmpvar: but that would make my project description misleading heh
[04:50] JimBastard: i think if anything for biggie
[04:50] JimBastard: i might build in some juju magic that converted JS to jQuery
[04:50] JimBastard: for the front
[04:50] JimBastard: or create a fake jQuery object
[04:50] JimBastard: that did that
[04:51] tmpvar: hrm
[04:51] JimBastard: i should try to actually write one page that works on the front and the back
[04:51] tmpvar: interesting, im not seeing how that would work
[04:52] JimBastard: biggie does it
[04:52] JimBastard: biggie puts in the work
[04:52] tmpvar: biggie
[04:52] tmpvar: link?
[04:52] JimBastard: just an empty git repo
[04:52] JimBastard: we got a google wave doc going
[04:53] JimBastard: will merge soon
[04:53] tmpvar: ok
[04:53] tmpvar: you should write a page that works on both the front and back and share ;)
[04:54] JimBastard: i will
[04:54] pjb3: Can you specify a timeout for http.ClientRequest?
[04:54] Tim_Smart: You could write template bare bone, and biggie will parse them to DOM, and insert stuff using DOM methods. I'm guessing that is what you are thinking.
[04:54] Tim_Smart: and then do a "to html" at the end
[04:55] JimBastard: my blog is soo broken, cant wait to ditch radiant for good
[04:55] JimBastard: http://maraksquires.com/articles/2010/02/03/you-love-mustache-js-and-just-dont-know-it-yet/
[04:55] JimBastard: GUESS WHAT IM EMAILING THE DEV TEAM TOMMOROW MORNING ^^^
[04:55] JimBastard: ahahaha
[04:55] Tim_Smart: Just got a email from google saying they are dropping IE6 support :p
[04:56] Tim_Smart: for google apps anyway
[04:56] tmpvar: can i see this biggie wave?
[04:56] JimBastard: sure
[04:56] JimBastard: Tim_Smart can you send him
[04:56] tmpvar: tmpvar@gmail.com
[04:56] JimBastard: we just started talking about this last night
[04:56] tmpvar: ah
[04:57] JimBastard: and im not writing any framework code until i list everything i ever wanted first
[04:57] Tim_Smart: I have spare time atm, so I will be working on it soon
[04:57] tmpvar: Tim_Smart, i'd like to see what you guys are up to.. this is sort of a big issue (imho)
[04:57] JimBastard: tmpvar are you familiar with restful routing on the client?
[04:57] Tim_Smart: yeah I'll add you in a min
[04:58] JimBastard: using sammy.js or bbq or route.js ?
[04:58] Tim_Smart: You can be a collaborator on github if you really want
[04:58] tmpvar: JimBastard, honestly, no
[04:58] JimBastard: tmpvar thats a huge step in doing a front and back framework
[04:59] JimBastard: you should goto nyc.js at pivotal
[04:59] tmpvar: i should
[04:59] tmpvar: i can probably make thurs
[05:00] JimBastard: check out sammy.js or route.js or jquery.bbq.js
[05:00] JimBastard: sammy is a framworkjquery
[05:00] JimBastard: errr
[05:01] JimBastard: sammy is a framework, jquery.bbq.js is a plugin, and route.js is not production ready
[05:01] tmpvar: yeah, looking at sammy.js currently
[05:01] JimBastard: http://maraksquires.com/route.js/#/Why
[05:01] JimBastard: http://maraksquires.com/route.js/#/Learn/Plain_ole_routing
[05:03] tmpvar: ok, this makes sense
[05:04] Tim_Smart: tmpvar: https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BayXwiDRMA
[05:05] tmpvar: ???? libxml ????
[05:06] tmpvar: hehe
[05:06] JimBastard: so tmpvar one of the things biggie will do is route
[05:06] JimBastard: check out the syntax in doc
[05:07] tmpvar: makes sense
[05:07] tmpvar: im on the same track.. i guess i've been looking at it a bit higher level
[05:08] tmpvar: and mustache.. really?
[05:08] JimBastard: mustache is pretty awesome
[05:08] JimBastard: i really hate the idea of templates having some magic syntax
[05:09] tmpvar: i hate syntax all together
[05:09] JimBastard: or logic
[05:09] tmpvar: views are views
[05:09] tmpvar: logic belongs elsewhere
[05:09] JimBastard: mustache enforces that
[05:09] JimBastard: its impossible to put bidness logic in a mustache template
[05:09] JimBastard: i mean, really hard
[05:10] tmpvar: yeah, i hear that
[05:10] tmpvar: not sure if im sold, thats all
[05:10] JimBastard: what are you currently using for templating?
[05:14] tmpvar: nothing actually :/
[05:14] tmpvar: i come from the land of php, and I've basically sworn it off at this point
[05:14] tmpvar: but in php there are bad and then bad templating languages
[05:14] jan____: mustache ftw.
[05:15] jan____: php is a good templating language tho :)
[05:15] tmpvar: yes
[05:15] tmpvar: im talking flexy/smarty/etc
[05:15] jan____: they are just wrong
[05:15] tmpvar: beauty of js is the shared code browser/server
[05:16] tmpvar: but from what i understand, if you destroy your templates by replacing tags.. you kill half of the interoperability off.
[05:16] tmpvar: unless you are going to ship all of your templates in unmodified form to the browser
[05:16] jan____: I don't think the code sharing is such an advantage, I just like the unified language
[05:18] tmpvar: i honestly dont see how its not advantageous to write code once and use it twice ;)
[05:18] Tim_Smart: especially form models etc
[05:19] Tim_Smart: You could write the listeners and model, and the server auto generates the javascript
[05:19] jan____: not saying using code on both ends helps, but I rarely have stuff in the backend that also runs on the frontend
[05:20] tmpvar: my goal is to change that
[05:22] tmpvar: haha, I guess what I mean.. is I see things differently and I'm working towards producing code that makes it apparent
[05:24] okito has joined the channel
[05:24] hassox: tmpvar: pragmatically I think it's fine to have different code in different placdes
[05:25] hassox: trying to write code that runs in both could take a lot more time and effort for somethings
[05:25] Tim_Smart: hassox: Well obviously only SOME code will be shared
[05:25] hassox: agreed
[05:25] hassox: if it can be written to share great
[05:25] Tim_Smart: The views / templates obviously are more client side than anything
[05:26] Tim_Smart: but the way the server interacts with them is what we are re-looking
[05:26] hassox: Tim_Smart: I don't think that's even always true
[05:26] jan____: I like my frontend_md5.js and backend_md5.js to be different implementations
[05:26] jan____: wait, no.
[05:26] hassox: client side templates are good
[05:26] hassox: but how does anything index them
[05:27] tmpvar: the server based dom pushes out a full page
[05:27] tmpvar: so a full page is rendered, pushed to the client
[05:27] jan____: server dom makes me vomit, tho
[05:27] tmpvar: lol
[05:27] Tim_Smart: jan____: haha
[05:27] Tim_Smart: I just want to see how it performs
[05:27] tmpvar: same
[05:28] tmpvar: ive been meaning to proof it
[05:28] ryah: ACTION stabs amqp
[05:28] tmpvar: heh
[05:28] Tim_Smart: I'm sure regex parsing might be faster
[05:28] tmpvar: ouch!
[05:28] hassox: ryah: did you get xshay's lib working?
[05:28] Tim_Smart: but I'm not sure
[05:28] ryah: hassox: well a little bit
[05:28] hassox: lol
[05:28] ryah: it's was pretty hacky
[05:28] ryah: i've extended it a lot
[05:28] hassox: :)
[05:28] hassox: nice one
[05:29] ryah: going to be done tonight
[05:29] ryah: well first version at least
[05:29] jan____: ryah: redis > amqp
[05:29] ryah: jan____: yes
[05:29] ryah: people love amqp though
[05:29] hassox: ACTION is wondering if rabbit is a good choice over interconnected http apps
[05:29] jan____: ryah: people also love java
[05:29] hassox: jan____: what do you suggest?
[05:29] jan____: .oO(java is the hitler of IT arguments)
[05:29] hassox: jan____: what's a good couch adapter for js?
[05:30] ryah: i would *love* to have someone write a simple queue server in node
[05:30] jan____: for node?
[05:30] hassox: jan____: yeah
[05:30] ryah: in memory, with an easy protocol
[05:30] jan____: ryah: yeah, on top of awesome, port resque
[05:30] jan____: hassox: felifge is working on one
[05:30] jan____: the other one is a bit half baked
[05:30] hassox: ryah: what would it do? postbacks to other apps or emit events to the currently running app?
[05:31] hassox: jan____: is it public?
[05:31] ryah: hassox: yeah. but also have dynamic queues and topic-based routing
[05:31] jan____: hassox: yeah, it's on github, but not done yet
[05:31] ryah: like the two things that make amqp cool
[05:31] hassox: dynamic queues?
[05:31] hassox: jan____: bugger
[05:31] ryah: well like you can create them on the fly
[05:32] hassox: I'm looking for something to help me learn it
[05:32] hassox: ryah: ah
[05:32] ryah: q = server.createQueue("blah")
[05:32] hassox: gotcha
[05:32] hassox: yeah
[05:32] jan____: hassox: learn couch?
[05:32] hassox: yeah
[05:32] hassox: I'm reading the book
[05:32] ryah: q.catch("ny.*", function (message) { })
[05:32] hassox: couch makes a lot of sense
[05:33] hassox: ryah: I'm considering moving work to something like this from rabbit
[05:33] hassox: we have rabbit but it's occured to me that it's really not that awesome
[05:33] hassox: especially failover
[05:33] hassox: and the headspace required by the other devs
[05:33] ryah: yeah
[05:33] hassox: if they can just post receive postbacks then sweet
[05:34] ryah: i could totally make a better rabbitmq in, like, 2 weeks.
[05:34] Tim_Smart: mind the noobness, but what does a queue server do?
[05:34] jan____: hassox: maybe look at sixtus42's node-couch, or really at couch.js (sync) and jquery.couch.js (async) that ship with couchdb
[05:34] ryah: Tim_Smart: it hosts queues
[05:34] hassox: kk
[05:34] ryah: Tim_Smart: a bit like an smtp server
[05:35] ryah: message pass through it, get routed into queues
[05:35] hassox: ryah: we're predominatley using a headers exchange which I think would be awesome to use by registering queues and filling them via postbacks
[05:35] jan____: FWIW: https://twitter.com/janl/status/8570602107 (ryah)
[05:35] Tim_Smart: right ok
[05:35] hassox: ryah: are queues actually required?
[05:35] hassox: by us the order of the message isn't all that important (often)
[05:35] jan____: hassox: also, if you have any questions, ping me :)
[05:36] hassox: jan____: thanx :D
[05:36] hassox: that's awesome
[05:36] jan____: there's also #couchdb :)
[05:36] jan____: for when I'm off
[05:38] creationix has joined the channel
[05:46] ryah: hassox: i think that's important to us
[05:46] ryah: for example
[05:47] ryah: amqp.js 800 lines and counting :(
[05:47] JimBastard: oofa
[05:52] Tim_Smart: I loled when someone bench-marked mongodb against memcached, and mongodb was faster
[05:53] JimBastard: im still trying to figure out a structure for what im trying to do
[05:53] JimBastard: i guess it has to be in the form of a CommonJS module
[05:53] JimBastard: that will do injection when on the client
[05:53] JimBastard: hrmm i can do that
[05:54] Tim_Smart: ryah: Are you planning any changes to the module system?
[05:54] Tim_Smart: or is it going to stick with commonjs
[05:54] JimBastard: so rails people like folders called "views" right
[05:54] Tim_Smart: not sure
[05:54] jan____: Tim_Smart: memcache acks writes :)
[05:54] Tim_Smart: never used rails
[05:54] JimBastard: ahahah
[05:55] ryah: Tim_Smart: i don't know
[05:55] JimBastard: hey ryah, node has been working out great for me so far. you are awesome
[05:55] JimBastard: i have been getting paid to node
[05:55] JimBastard: a little
[05:56] jan____: JimBastard: woot
[05:56] Tim_Smart: Once this frameworks start taking shape, I shall use it for my clients
[05:56] ryah: JimBastard: cool
[05:56] Tim_Smart: *framework starts
[05:57] sahnlam has left the channel
[05:57] JimBastard: so if i dont give ryah a cut of this node money will the javascript mafia rub me out?
[05:57] JimBastard: i guess i could always escape()
[05:58] JimBastard: HIYO
[05:59] Tim_Smart: nodejs_v8: this.prototype
[05:59] nodejs_v8: Tim_Smart: undefined
[05:59] Tim_Smart: this.__proto__
[06:00] Tim_Smart: nodejs_v8: this.__proto__
[06:00] nodejs_v8: Tim_Smart: {}
[06:00] Tim_Smart: nodejs_v8 is of origin new Object() :o
[06:02] ryah: JimBastard: :)
[06:02] mikeal has joined the channel
[06:04] Tim_Smart: !log
[06:11] jubos has joined the channel
[06:17] okito has joined the channel
[06:27] Tim_Smart: JimBastard: If you want we can get the routing done first. Can expand on the routing paragraph in Google Wave whenever
[06:27] JimBastard: okay
[06:27] JimBastard: im still thinking really hard over here
[06:27] JimBastard: maybe i need more tacos or sleep
[06:28] JimBastard: the routing is easy though
[06:28] Tim_Smart: don't burn out >.>
[06:28] JimBastard: its the bigger picture thats harder
[06:28] Tim_Smart: I'm trying to load your blog post on routing, but it is failing
[06:28] JimBastard: how do you determine if something should run front or back
[06:28] JimBastard: errrr
[06:28] Tim_Smart: ah loaded
[06:28] JimBastard: yeah that blog sucks ass
[06:29] JimBastard: im gonna kill it soon and replace with node or github
[06:30] JimBastard: there are multiple implementations of onHashChange that are cross browser
[06:31] xantus_ has joined the channel
[06:32] Tim_Smart: Hmm for client side routing ('#') which requires dynamic data, we can define that in the routing
[06:33] Tim_Smart: oh wait, there is a better way
[06:33] JimBastard: huh
[06:33] Tim_Smart: I'm going to have dinner, I'll explain myself later
[06:34] JimBastard: k
[06:35] JimBastard: ohh snap
[06:35] JimBastard: i got a great idea for the styling system
[06:35] JimBastard: http://maraksquires.com/json_stylesheets/
[06:40] jan____: "CSS is not a programming language" <- this is not a problem, it's a feature
[06:40] JimBastard: i still <3 my little hackery
[06:41] JimBastard: im gonna write the server side end to output valid css
[06:41] JimBastard: right now its client-side only
[06:41] jan____: JimBastard: it is pretty slick
[06:42] JimBastard: you got any suggestions? ill try to release sometime soon
[06:42] JimBastard: its not very complicated
[06:42] creationix: Just wrote an article about Control flow patterns in Node http://howtonode.org/control_flow.html
[06:42] JimBastard: yo creationix
[06:43] JimBastard: why SOOO SERIOUS
[06:43] jan____: :)
[06:43] JimBastard: im gonna have nightmares about your smile
[06:43] creationix: which one, I just changed my gravitar
[06:43] creationix: the new one in the tree?
[06:44] tmpvar: lol
[06:44] tmpvar: yes
[06:44] creationix: sometimes I just feel like climbing a tree, and my wife will take pictures of it.
[06:45] creationix: I'll probably change it tomorrow, the picture is pretty blurry
[06:46] JimBastard has joined the channel
[06:46] JimBastard: FFFFFFFFFFUUUUUUUUU java.freenode.net
[06:46] JimBastard: unban mibbit you fuckers
[06:50] RayMorgan has joined the channel
[06:52] Tim_Smart: JimBastard: Back. I'll chuck my idea on the wave
[07:08] richtaur has joined the channel
[07:15] kennethkalmer has joined the channel
[07:18] Tim_Smart: JimBastard: Added some of my routing ideas
[07:19] JimBastard: i see yeah, thats exactly what i was thinking
[07:20] JimBastard: i was thinking in my head you might want to do partial server partial ajax
[07:20] JimBastard: but that is very abstract right now
[07:20] JimBastard: having an either or would be good
[07:20] JimBastard: either 100% client or 100% server (noscript ready)
[07:21] Tim_Smart: We *could* have a websocket always open, and we could eliminate the http overhead
[07:21] JimBastard: assuming JS is on and its html5
[07:21] Tim_Smart: yeah well...
[07:22] Tim_Smart: that would be cool though, streaming web pages
[07:22] JimBastard: perhaps
[07:23] Tim_Smart: wouldn't have to go through anymore http routing fluff
[07:23] Tim_Smart: no negotiation connections
[07:24] JimBastard: assuming html5
[07:24] Tim_Smart: *negotiating
[07:24] Tim_Smart: yeah but I wouldn't do it at this stage
[07:24] ryah: how do you change arguments into an array?
[07:24] ryah: Array.prototype.slice(arguments) ?
[07:24] JimBastard: i dunno the best way ryah...ive cheated in the past
[07:25] JimBastard: doing a for loop.....
[07:25] RayMorgan: Array.prototype.slice.call(arguments)
[07:25] Tim_Smart: ryah: jquery has some logic that it uses to do it
[07:25] Tim_Smart: ACTION looks at jquery source
[07:29] Tim_Smart: ryah: What RayMorgan said
[07:29] Tim_Smart: slice.call(arguments)
[07:31] hassox has joined the channel
[07:34] JimBastard: so Tim_Smart did you look through the jquery.trigger jquery.bind IoC thingy?
[07:34] JimBastard: evented javascript
[07:35] Tim_Smart: not sure
[07:35] JimBastard: the basic idea is that each route represents a unique state in the UI
[07:35] Tim_Smart: Yeah, and you want to navigate it
[07:36] Tim_Smart: does jQuery have a routing plugin, or was that what your blog was about?
[07:36] JimBastard: routing != IoC
[07:36] JimBastard: but with route.js it does
[07:36] Tim_Smart: IoC = ?
[07:36] JimBastard: inversion of control
[07:36] Tim_Smart: right, which enables users to use back / forward right?
[07:37] JimBastard: http://www.michaelhamrah.com/blog/2008/12/event-pooling-with-jquery-using-bind-and-trigger-managing-complex-javascript/
[07:37] JimBastard: no
[07:38] Tim_Smart: ok I'll just read
[07:38] JimBastard: using that model we can build some sweet UI events from backend js i think
[07:38] JimBastard: that pattern*
[07:41] micheil has joined the channel
[07:47] aguynamedben has joined the channel
[08:03] zmoog has joined the channel
[08:09] JimBastard has joined the channel
[08:09] JimBastard: stupid java app
[08:11] scudco has joined the channel
[08:12] JimBastard: you alive Tim_Smart
[08:12] Tim_Smart: yes
[08:12] Tim_Smart: http://github.com/Tim-Smart/biggie/blob/master/examples/forms.js
[08:12] JimBastard: so i just pushed some fake ass pseudo code
[08:13] JimBastard: reading
[08:14] Tim_Smart: emit the CSS stuff most likely, and let the designer worry about styling
[08:15] Tim_Smart: so it can used in a workplace with many people
[08:16] JimBastard: im not really i see how your form code works
[08:16] JimBastard: sure*
[08:16] JimBastard: ugh this irc client is the worst
[08:17] Tim_Smart: Well first create the Form, and pass some options to it
[08:17] Tim_Smart: route is the route you want "action" to point at
[08:18] Tim_Smart: and events will auto generate jquery code
[08:18] JimBastard: why cant it just be an html forM?
[08:18] JimBastard: with an action?
[08:18] Tim_Smart: Hmm, I think this is bad due to too tight integration
[08:19] Tim_Smart: need to keep it loose
[08:19] JimBastard: each form should be a view
[08:19] JimBastard: and then you mustache in values
[08:19] Tim_Smart: all the javascript / model stuff should go in /model/
[08:20] Tim_Smart: or controller
[08:20] Tim_Smart: actually
[08:20] Tim_Smart: model is for the data structure
[08:20] Tim_Smart: which we can look at sometime soon
[08:21] Tim_Smart: yeah well I'm going to start the routing logic now
[08:21] Tim_Smart: and the loader
[08:22] micheil: the only thing I can see is this: how do you manage autoloading?
[08:22] Tim_Smart: micheil: autoloading of what?
[08:22] micheil: models, controllers, views
[08:23] micheil: at some stage you need to work out where they exist on the filesystem so that you can load them
[08:23] Tim_Smart: biggie.load("model.stuff", callback)
[08:23] micheil: uh.
[08:24] micheil: and how's that actually mean anything?
[08:24] Tim_Smart: load stuff when you need it only
[08:25] Tim_Smart: actually, we could probably do some sort of mapping
[08:26] Tim_Smart: when page x loads, load these models
[08:26] micheil: ACTION should really do some more work on one of his projects some day.
[08:26] Tim_Smart: micheil: Your welcome to join ours
[08:26] micheil: nawh
[08:26] micheil: mine's a different approach
[08:26] Tim_Smart: we got a few people keen already
[08:26] Tim_Smart: micheil: Nothing is really decided yet
[08:27] micheil: well, for the first part, mine is similar to elements of rack, sinatra, and django
[08:27] JimBastard: that sounds about right
[08:28] micheil: rack in the sense that there's just one file, which knows how to load things.
[08:28] JimBastard: we are doing restful routing on the front and back - sinatra / sammy.js
[08:28] Tim_Smart: OK. We are doing a lot of thinking out-of-the-box... well trying anyway
[08:28] micheil: ew.. sammy. erm rather, jquery.
[08:28] JimBastard: we arent using sammy
[08:28] JimBastard: im pretty handy when it comes to doing client-side location.hash routing
[08:29] micheil: "JimBastard: we are doing restful routing on the front and back - sinatra / sammy.js"
[08:29] JimBastard: like sinatra in the back and like sammy in the front
[08:29] micheil: JimBastard: yeah, I'm a dojo guy, but I prefer things to be framework agnostic
[08:29] JimBastard: k
[08:29] JimBastard: do you have a repo up with any code?
[08:29] micheil: so I won't make anything that imposes restrictions on what you have to use on the frontend
[08:30] micheil: no
[08:30] micheil: currently it's just ideas (dating back about 3 months)
[08:30] JimBastard: so get on the wave dude
[08:30] teemow has joined the channel
[08:30] micheil: bbs.
[08:30] JimBastard: and write them down
[08:30] JimBastard: we have a google wave going
[08:31] micheil: JimBastard: I use pen&paper. and I have generally worked solo.
[08:31] JimBastard: damn, living in au must suck
[08:31] JimBastard: :p
[08:34] Tim_Smart: JimBastard: In the config file, we can have it so you specify what javascript library you are using
[08:35] Tim_Smart: if it finds a corresponding module for it, then it will load convenience methods / prototypes
[08:36] JimBastard: yeah
[08:36] JimBastard: we'll probaly have to do a lot of stubbing
[08:36] JimBastard: like
[08:36] JimBastard: what happens in node when you alert('hi')
[08:37] Tim_Smart: Well I'm thinking node will only generate some javascript scaffolding. Like the code the emits events etc
[08:38] Tim_Smart: Leave the rest up to the designer / developer
[08:38] Tim_Smart: We need *some* separation of the classes
[08:38] JimBastard: lol yeah i guess so
[08:38] JimBastard: it wont be DRY in a few places though
[08:39] JimBastard: i wanted to have a common route/request processor
[08:39] JimBastard: im gonna put this down for a bit and actually release json style sheets
[08:39] JimBastard: im gonna try to convince my boss to write a ruby parser for it
[08:39] JimBastard: shouldnt be more then 5 lines
[08:39] Tim_Smart: and we need to have it so designers can work separately from developers
[08:40] Tim_Smart: So designer hands you a template, what is the fastest method to fill it in?
[08:41] Tim_Smart: and template is CSS / HTML usually
[08:42] Tim_Smart: you don't want to re-write it in JSON
[08:43] micheil: JimBastard: how so?
[08:43] micheil: JimBastard: it's actually raining here for once.
[08:43] JimBastard: ill just show you later
[08:43] JimBastard: im kidding about au
[08:43] micheil: hmm?
[08:43] micheil: oh
[08:44] JimBastard: night
[08:53] bpot has joined the channel
[09:02] felixge has joined the channel
[09:02] felixge has joined the channel
[09:07] micheil: Tim_Smart: currently I'm drifting towards using some lightweight templating language, basic form of JSON or something ORM / Models
[09:07] micheil: and then simple controllers and routing
[09:08] Tim_Smart: Well we haven't set anything in stone yet, but a few concepts have been thrown around
[09:09] Tim_Smart: I'm doing directory structure atm
[09:10] Tim_Smart: I have "elements", which will be reusable bits of server-side logic
[09:10] Tim_Smart: "apps", which will be your main app logic
[09:10] Tim_Smart: so you can multiple apps on one instance
[09:11] Tim_Smart: "biggie" will contain core logic, and "config" for config logic. "views" for templates
[09:15] micheil: hmm.. I'm thinking in a more traditional sense I think
[09:15] felixge: morning
[09:18] micheil: http://gist.github.com/293495
[09:18] micheil: moin felixge
[09:18] paulca has joined the channel
[09:19] micheil: Tim_Smart: just updated that gist.
[09:20] Tim_Smart: felixge: What's the story with module un-caching. Need to get that in trunk soon
[09:21] Tim_Smart: micheil: Oh yeah. I want a little more separation at the highest dir level. Meaning you can get to files fast
[09:21] felixge: Tim_Smart: well ryan talked about using narwhals module system last night
[09:21] felixge: not sure how serious that was
[09:21] micheil: Tim_Smart: the idea there being that there isn't just one app
[09:22] micheil: "app" is an example name
[09:22] felixge: I should email him and see if he's still interested in a patch of hot loading
[09:22] micheil: Tim_Smart: also, I'd prefer an organised filesystem rather then an unorganised filesystem
[09:22] Tim_Smart: yeah I have a "app" directory which can contain multiple apps. I also have a "elements" directory which is shared logic
[09:23] Tim_Smart: so you could have "comment" element in several apps
[09:24] Tim_Smart: controllers etc which are relevant to the app will be in the apps/yourapp/xxx dir
[09:25] Tim_Smart: felixge: Hmm well he said he was waiting for you and blaine
[09:25] Tim_Smart: :p
[09:27] micheil: brb
[09:27] felixge: Tim_Smart: ok, I'll work on it again today
[09:28] Tim_Smart: well I'm not sure what the story is, wait till ryah is back
[09:28] Tim_Smart: ryah_away: ping
[09:40] micheil: Tim_Smart: he probably won't respond, being it's between 1-5am
[09:40] Tim_Smart: :p
[09:41] micheil: ACTION is trying to figure out a good way to define tcp servers and clients, in a common fashion
[09:41] sudoer has joined the channel
[09:42] micheil: something like: http://gist.github.com/292635
[09:42] micheil: or http://gist.github.com/293511
[09:45] felixge: micheil: probably not easy
[09:45] micheil: why so?
[09:46] felixge: well depending on your goal
[09:46] felixge: because protocols are bitches ;)
[09:46] micheil: not really
[09:46] felixge: well, depends on the protocol
[09:46] felixge: but take http ...
[09:46] felixge: writing a spec conform http client / server has almost no value
[09:46] micheil: irc, smtp, etc are all pretty decent
[09:47] felixge: I gues
[09:47] felixge: * guess
[09:47] felixge: but why add a layer of abstraction?
[09:47] micheil: it's mainly a project to unify the common elements
[09:47] micheil: equivalent to ruby's eventmachine protocols
[10:01] Tim_Smart: nodejs_v8: Exception
[10:01] nodejs_v8: Tim_Smart: Exception: ReferenceError: Exception is not defined
[10:01] Tim_Smart: nodejs_v8: Error
[10:01] nodejs_v8: Tim_Smart: function Error() { [native code] }
[10:04] geelen has joined the channel
[10:17] matthijs has joined the channel
[10:18] ithinkihaveacat has joined the channel
[10:22] micheil: nodejs_v8: throw new Error("hello");
[10:22] nodejs_v8: micheil:
[10:22] micheil: fails.
[10:27] Tim_Smart: new Error('hello')
[10:27] Tim_Smart: nodejs_v8: new Error('hello')
[10:27] nodejs_v8: Tim_Smart: {"message": "hello", "stack": "Error: hello
[10:28] Tim_Smart: lol the stack trace appear in my terminal
[10:28] Tim_Smart: should put a regex on it to remove new lines
[10:32] nodejs_v8 has joined the channel
[10:32] Tim_Smart: nodejs_v8: new Error('hello')
[10:32] nodejs_v8: Tim_Smart: {"message": "hello", "stack": "Error: hello
[10:33] micheil: .replace(/\S+/gi, " ");
[10:33] micheil: is probably what you're after
[10:33] nodejs_v8 has joined the channel
[10:33] Tim_Smart: I forgot to actually assign the replace :p
[10:33] Tim_Smart: nodejs_v8: new Error('hello')
[10:33] nodejs_v8: Tim_Smart: {"message": "hello", "stack": "Error: hello at evalcx:1:1
[10:34] Tim_Smart: hmmm
[10:34] nodejs_v8 has joined the channel
[10:34] Tim_Smart: nodejs_v8: new Error('hello')
[10:35] nodejs_v8: Tim_Smart:
[10:35] nodejs_v8 has joined the channel
[10:35] Tim_Smart: should really be doing this in the console :p
[10:35] Tim_Smart: nodejs_v8: new Error('hello')
[10:35] nodejs_v8: Tim_Smart: {"message": "hello", "stack": "Error: hello at evalcx:1:1 at Object. (/home/tim/Projects/nodejs/ircbot/lib/v8/v8evaler.js:55:26) at [object Object]. (node.js:928:23) at [object Object].emitSuccess (node.js:240:15) at [object Object]. (node.js:653:21) at [object Object].emitSuccess (node.js:240:15) at node.js:510:29 at node.js:985:9 at node.js:989:1", "name": "Error"}
[10:36] Tim_Smart: lol gives the path
[10:37] Tim_Smart: I will move it to a more anonymous directory later
[10:37] Tim_Smart: nodejs_v8: throw new Error('hello')
[10:37] nodejs_v8: Tim_Smart: Exception: Error: hello
[10:40] micheil: Tim_Smart: is this directly access v8, or is it going through node?
[10:41] Tim_Smart: directly access
[10:41] micheil: oh
[10:41] micheil: I was thinking sorta node-repl style
[10:41] Tim_Smart: I build a C++ addon for it
[10:42] Tim_Smart: reasonable simple code
[10:42] Tim_Smart: *reasonably
[10:43] micheil: that's right, I'd forgotten
[10:44] cedricv has joined the channel
[10:46] Tim_Smart: Fun to watch all the activity come through http://yfrog.com/16screenshot016bp
[10:58] Tim_Smart: micheil: And the code begins http://github.com/Tim-Smart/biggie :p
[10:58] micheil: why are you mixing in python?
[10:59] micheil: you know you can do: #!/usr/bin/env node
[11:01] Tim_Smart: python is a requirement for node
[11:02] Tim_Smart: and easier to make a admin shell with
[11:11] geelen has joined the channel
[11:20] paulca has joined the channel
[11:45] matthijs has joined the channel
[11:55] joshbuddy has joined the channel
[11:56] Tim_Smart: nodejs_v8: throw new Error("Sleep time!");
[11:56] nodejs_v8: Tim_Smart: Exception: Error: Sleep time!
[11:59] Connorhd_ has joined the channel
[12:06] paulca has joined the channel
[12:15] blackdog` has joined the channel
[12:34] alex-desktop has joined the channel
[13:24] charlenopires has joined the channel
[13:33] geelen has joined the channel
[13:51] paulca has joined the channel
[13:51] binary42 has joined the channel
[14:05] binary42 has joined the channel
[14:10] kriszyp has joined the channel
[14:40] pmuellr has joined the channel
[14:47] creationix has joined the channel
[14:50] cloudhead has joined the channel
[14:51] sktrdie has joined the channel
[14:51] sktrdie: hello
[14:51] sktrdie: how do i use C libs with node.js?
[14:51] sktrdie: C/C++ libs that is
[14:51] sktrdie: do i have to write some sort of api for it?
[14:51] sktrdie: is there any documentation?
[14:54] cloudhead: sktrdie: http://nodejs.org/api.html#_addons
[14:55] joshbuddy has joined the channel
[15:04] atcrabtree has joined the channel
[15:04] blackdog` has joined the channel
[15:09] joshbuddy has joined the channel
[15:09] joshbuddy has joined the channel
[15:23] andy_l has joined the channel
[15:25] lifo has joined the channel
[15:27] davidsklar has joined the channel
[15:30] rtomayko has joined the channel
[15:35] Booster has joined the channel
[15:43] pjb3 has joined the channel
[15:59] lifo has left the channel
[16:06] steadicat has joined the channel
[16:09] bryanl has joined the channel
[16:11] alexiskander has joined the channel
[16:14] ericflo has joined the channel
[16:17] qFox has joined the channel
[16:27] bryanl has joined the channel
[16:30] ryah_away: morning
[16:31] creationix: morning
[16:32] creationix: ryah: So are you in California now?
[16:33] ryah: yeah
[16:34] creationix: It's always interesting to me to see the diversity of time zones on this project.
[16:37] ryah: it's cause node has strong ties to germany
[16:38] creationix: yep, I will often stay up late just to wait for them to wake up in the morning (I'm in Texas)
[16:39] RayMorgan has joined the channel
[16:40] okito has joined the channel
[16:41] creationix: ryah: I noticed the other day you mentioned that node was getting too much hype for your taste. I hope I'm not causing too much trouble by promoting the howtonode.org site.
[16:42] ryah: creationix: no - of course not - docs are good. "OMG ITS FASTER THAN NGINX" is distructive
[16:42] creationix: ahh, it's the unrealistic claims that you don't like, agreed.
[16:46] sudoer has joined the channel
[16:48] ryah: 1000 github watchers
[16:48] paulca has joined the channel
[16:49] ryah: i think we should wait for 1024 before celebrating
[16:52] bryanl has joined the channel
[16:52] [k2] has joined the channel
[16:53] gwoo: ryah: haha
[16:53] felixge: ryah: hey there
[16:54] felixge: ryah: I'm wondering if we should continue with hot module reloading or if throwing out the current module system is a very likely scenario?
[16:56] pjb3: creationix: that was fast, thanx!
[16:56] ryah: i don't think it's very likely
[16:56] ryah: that was just an idea
[16:57] creationix: pjb3: no problem, it was easy (speaking of recent haml-js patch)
[16:57] felixge: ryah: alright, then I'll patch ahead ;)
[16:58] felixge: ryah: I still have this almost-done patch for making require() truly sync. But for now just queuing up all require calls is probably the way to go
[17:00] ryah: felixge: yeah - i was looking at that the other day - there was something wrong with it
[17:00] ryah: but i forget
[17:00] ryah: now :)
[17:08] bpot has joined the channel
[17:10] ryah: so, felixge, i really want to get on the net2 branch
[17:10] ryah: get rid of node_child_process.cc and node_stdio.cc and evcom
[17:10] ryah: and node_net.cc and node_htt.cc
[17:12] felixge: ryah: don't we need node_child_process.cc ?
[17:12] felixge: I kinda like child processes : )
[17:16] charlenopires has joined the channel
[17:17] inimino: ryah: how's the performance on net2?
[17:21] paulca has joined the channel
[17:22] emyller has joined the channel
[17:22] ryah has joined the channel
[17:22] Atmoz has joined the channel
[17:22] erikcorry|away has joined the channel
[17:22] rudebwoy has joined the channel
[17:22] ashb has joined the channel
[17:22] bengl has joined the channel
[17:22] er1k757 has joined the channel
[17:22] CIA-78: node: 03Ryan Dahl 07net2 * r1660db6 10/ (src/node_buffer.cc src/node_buffer.h): Inline Buffer::HasInstance - http://bit.ly/dmTYNu
[17:24] ryah has joined the channel
[17:26] Nathan__ has joined the channel
[17:27] CIA-78: node: 03Ryan Dahl 07master * rc7cb4da 10/ (213 files in 17 dirs): Upgrade V8 to 2.1.0 - http://bit.ly/aTPdQS
[17:31] aguynamedben has joined the channel
[17:32] creationix: Sweet! Object.getOwnPropertyNames works just like Object.keys, except it shows keys that are not enumerable! How hard would it be to integrate this into the repl with tab completion?
[17:33] stephenlb has joined the channel
[17:33] gwoo: creationix: node-blog is sweet
[17:34] creationix: which part, the code or the content?
[17:34] okito has joined the channel
[17:34] gwoo: code/content/concept
[17:34] gwoo: :)
[17:34] gwoo: i can't say which is sweeter
[17:34] creationix: Thanks, open source is fun, you get to build on other's ideas.
[17:35] felixge: hm
[17:35] felixge: I kind of think its a bad use case of node
[17:35] gwoo: felixge: por que?
[17:35] creationix: felixge: are you talking about the repl idea?
[17:35] felixge: creationix: no, node-blog
[17:35] felixge: I mean the concept is cool
[17:36] felixge: but just not a very good use case for node. I mean generating static HTML isn't exactly what node was written for :)
[17:36] felixge: you should serve the entire blog via node ; ).
[17:36] gwoo: it is
[17:36] gwoo: i thought
[17:36] creationix: I do plan on writing a real blog engine like wordpress someday, that's just a lot more work
[17:37] creationix: I wouldn't be able to do that in a couple of late nights
[17:37] gwoo: hehe
[17:37] felixge: :)
[17:37] felixge: np
[17:37] creationix: I wanted to get something up so people could start writing articles
[17:37] felixge: I'm glad you're doing the blog
[17:37] pjb3: creationix: If you were to do that, what would you use for data storage?
[17:37] pjb3: Postgres, Couchdb, etc.?
[17:38] creationix: depends on the traffic expected. I would probably use my node-persistence library regardless.
[17:38] creationix: I prefer sqlite when it's fast enough
[17:38] ericflo has joined the channel
[17:38] creationix: I would like to finish my jsondb driver as a nosql alternative to sqlite
[17:38] creationix: and then use mongo or couch for higher traffic sites
[17:39] inimino: my blog is generated by node to static HTML too... which is then rsync'd to a separate server which runs Apache ;)
[17:39] creationix: felixge: thanks
[17:40] inimino: actually, generated by client-side scripts, stored by node, published via rsync, served by Apache
[17:40] ithinkihaveacat: got a question about events
[17:40] inimino: I should release the entire system and call it Rube Goldblog
[17:40] creationix: inimino: that's a crazy workflow. sounds nice though.
[17:41] inimino: creationix: it's actually kind of a hassle, but I don't blog often enough to have replaced it yet...
[17:41] aguynamedben has joined the channel
[17:42] ithinkihaveacat: i'm guessing that if you do emitter.emit("foo", ...), then any subsequent callbacks registered via emitter.addListener("foo", ...) that happens before the system has finished processing the initial emit() don't get called--?
[17:42] brosner has joined the channel
[17:42] inimino: creationix: if someone writes a node-based blogging package that catches on I'll take notice though :)
[17:42] creationix: inimino: you're welcome to use the node-blog engine and help me work out the kinks.
[17:42] inimino: I'll take a look at it next time I do some blogging
[17:43] nrstott has joined the channel
[17:43] inimino: ithinkihaveacat: if it's attached on the same event turn, then that is fine
[17:43] inimino: ithinkihaveacat: otherwise, yes, you have a race condition
[17:44] ithinkihaveacat: i.e. if emitter.listener("foo") returns [fn1, fn2, fn3] at the time of the emit(), then even if i add [fn4, fn5] before all of fn1, fn2, fn3 have been called, fn4, fn5 will not be called
[17:44] ithinkihaveacat: inimino: no different event turn
[17:44] inimino: then that's fine
[17:44] inimino: event emitters have to wait until the next event turn before they emit any event
[17:44] inimino: that's the contract
[17:45] pjb3: creationix: no couch driver for node-persistence yet?
[17:45] ithinkihaveacat: so even if fn1 does emitter.addListener("foo", fn4), fn4 eventually gets called?
[17:45] ithinkihaveacat: actually i can test that easily
[17:47] creationix: pjb3: no, I've spread myself too thin and can only really actively develop on one project at a time. node-persistence only has postgres, sqlite, and memory drivers for now. I was hoping that would be enough examples for someone else to contribute more drivers.
[17:47] inimino: ithinkihaveacat: oh, if one of the callbacks adds further callbacks?
[17:47] pjb3: creationix: yeah, I'll see if I can help with that
[17:49] inimino: ithinkihaveacat: it should call them all: http://github.com/ry/node/blob/master/src/node_events.cc#L56
[17:49] eikke has joined the channel
[17:55] ithinkihaveacat: inimino: hey, it actually does, i'm surprised
[17:56] ithinkihaveacat: there is something strange happening though: http://gist.github.com/293826
[17:56] scudco has joined the channel
[17:56] ithinkihaveacat: as is, that outputs "fn1, fn2", but if you uncomment the removeListener, you only get "fn1"
[17:57] technoweenie has joined the channel
[17:59] isaacs has joined the channel
[18:02] ithinkihaveacat: does it make sense for that to happen? i was expecting "fn1, fn2" both times
[18:03] CIA-78: node: 03Ryan Dahl 07master * r173a8c9 10/ (4 files in 2 dirs): Disable dns and fs-sendfile tests. - http://bit.ly/9XhnMB
[18:04] mikeal has joined the channel
[18:07] felixge has joined the channel
[18:07] felixge has joined the channel
[18:08] ryah: felixge: http://github.com/aheckmann/node/commit/68f62318125e2b05fad781c49387b581d512f383#diff-0
[18:08] ryah: look good?
[18:09] felixge: ryah: yeah. damn JS API :)
[18:09] felixge: ryah: but that makes me wonder why it never caused a problem so far
[18:10] felixge: anyway, fix is good
[18:11] CIA-78: node: 03Aaron Heckmann 07master * r8f52142 10/ lib/multipart.js : look for -1 instead of false returned from string.indexOf - http://bit.ly/9DENN0
[18:11] eikke has joined the channel
[18:11] pjb3: Hey, can someone give me a brief synopsis of what's in the net2 branch?
[18:11] pjb3: performance improvements of some sort, I understand?
[18:12] okito has joined the channel
[18:12] nodejs_v8 has joined the channel
[18:13] Tim_Smart has joined the channel
[18:13] konobi: pjb3: binary buffer support
[18:13] konobi: nothing to do with performance
[18:13] inimino: ithinkihaveacat: yeah, it makes sense; it's reading the length each time, so if you're mutating the array you'll get unintuitive results
[18:14] Tim_Smart: ryah: Did you get in touch with felix?
[18:14] konobi: means that you can write binary TCP protocol clients/servers directly in javascript
[18:14] konobi: (not just binary... but you get the idea)
[18:14] inimino: ithinkihaveacat: in other words, once it calls fn1, i=1, but now on the next loop, length=1, and it will exit, even though the array ends with only fn2 in it
[18:14] ithinkihaveacat: inimino: the docs say that you can modify the array returned from emitter.listeners("foo")
[18:15] ithinkihaveacat: so i guess that really means "... but not within a callback itself"?
[18:15] inimino: ithinkihaveacat: so if you need fn1 to unregister itself you should do it after they have all been called
[18:15] inimino: yeah, not removed, anyway
[18:15] pjb3: konobi: Ah, very cool, thanks
[18:15] felixge has joined the channel
[18:15] felixge has joined the channel
[18:16] isaacs has joined the channel
[18:16] pjb3: so net2 will be useful for stuff like MongoDB? BSON?
[18:16] blackdog`: pjb3 there are 2 mongo drivers already
[18:16] inimino: ithinkihaveacat: you can use process.nextTick(function(){emitter.removeListener()})
[18:17] ithinkihaveacat: inimino: that'll work from within the callback?
[18:17] deanlandolt_: pjb3: i think mostly it's good for dumping huge swaths of core c++ and replacing it with js
[18:17] inimino: ithinkihaveacat: yes, it'll run after all the callbacks finished and will take effect on the next emitted event
[18:19] pjb3: deanlandolt_: Good, you can correct me when I incorrectly explain what that's for tonight ;)
[18:20] deanlandolt_: pjb3: heh...i just know what i've picked up lurking around here
[18:21] pjb3: BTW - If anyone is in the Baltimore area, I'm doing a node.js Intro talk / code demo tonight
[18:23] ithinkihaveacat: inimino: hrm, the callbacks don't seem to be removed, see http://gist.github.com/293847
[18:25] inimino: ithinkihaveacat: both events are already enqueued before you call process.nextTick
[18:25] inimino: ithinkihaveacat: try generating the events asynchronously with setTimeout or such
[18:25] mikeal has joined the channel
[18:27] technoweenie: what is net2? is it a big update to node.js?
[18:30] ryah: yes
[18:31] ithinkihaveacat: inimino: hrm yeah with a bunch of settimeouts it behaves as expected
[18:31] ryah: isaacs: why is lib/ easier to package?
[18:32] joshbuddy has joined the channel
[18:32] joshbuddy has joined the channel
[18:32] mies has joined the channel
[18:32] ithinkihaveacat: guess i don't understand the model as well as i thought i did. is there a way around the settimeouts, though? would rather avoid them ...
[18:34] felixge has joined the channel
[18:35] ithinkihaveacat: the addListener within fn1() is only there to simulate the fn2 listener being added after emit() has been fired, but before all the listening callbacks have been run, in a completely separate block (e.g. in response to a new http connection)
[18:35] mikeal has joined the channel
[18:51] nodejs_v8 has joined the channel
[18:56] richtaur has joined the channel
[18:59] richtaur has left the channel
[18:59] voxpelli-laptop has joined the channel
[19:00] mattly has joined the channel
[19:04] RayMorgan_ has joined the channel
[19:05] technoweenie has joined the channel
[19:09] tlrobinson_ has joined the channel
[19:11] isaacs: ryah: because that way, i know what's the library and what's the examples and what's the readme.
[19:12] isaacs: ryah: wanna go put in your 2ยข here? http://groups.google.com/group/commonjs/browse_thread/thread/5c1bb625b6f32562
[19:12] isaacs: http://wiki.commonjs.org/wiki/IO/C/Stream
[19:20] mikeal: ryah: you mentioned that Promise.wait() might go away
[19:20] mikeal: can you point me to the thread where that is discussed
[19:21] Tim_Smart: is wait() sync or async?
[19:21] mikeal: i'm looking at a few bits of code that I have and realizing that without Promise.wait() i'd have to double the amount of code to do an emitSuccess
[19:22] mikeal: in particular, i have some functions that create callBacks that call that function recursively
[19:22] mikeal: so I would have to keep a count of all the promises created and finished, it would be a real pain
[19:23] Tim_Smart: Well if you show us the code there might be an alternative
[19:23] mikeal: of course, if you add a blocking IO API my use cases would go away
[19:23] fictorial has joined the channel
[19:24] mikeal: http://gist.github.com/293922
[19:24] ryah: mikeal: yeah wait() is buggy fundementally
[19:24] mikeal: oh i know, i don't use it in production
[19:24] mikeal: i'm only using it for some scripting stuff that I'm doing
[19:25] mikeal: which is why a blocking file IO API would make the problem go away
[19:26] Tim_Smart: why wait() when you got a callback?
[19:26] stephenlb has joined the channel
[19:27] mikeal: because it's recursive
[19:27] mikeal: the code that calls walk() needs to know when it's finished
[19:27] felixge has joined the channel
[19:27] felixge has joined the channel
[19:29] mikeal: and since walk calls itself recusively doing an emitSuccess on the parent walk() promise is problematic since there is a loop inside it that also creates callbacks
[19:31] Tim_Smart: so what function do you call in your program?
[19:31] mikeal: http://gist.github.com/293922
[19:31] mikeal: i call walk(path, callback)
[19:31] mikeal: and then after that, i need to do other stuff when it's finished
[19:32] mikeal: and it's a serious PITA to do an emitSuccess for walk
[19:32] rednul_ has joined the channel
[19:33] RayMorgan has joined the channel
[19:36] Tim_Smart: so it just calls back on every file?
[19:36] kriszyp has joined the channel
[19:36] mikeal: yes
[19:37] Tim_Smart: I removed the wait()'s and it didn't make a difference
[19:37] mikeal: it runs, but you can't tell when it's finished in your code
[19:37] mikeal: with the waits the code after walk won't run until it's finished
[19:38] mikeal: sure, it works without wait() just fine, there is just no way to tell when it's finished
[19:43] Tim_Smart: what about http://gist.github.com/293938
[19:43] Tim_Smart: wait...
[19:43] mikeal: that won't work
[19:44] mikeal: it'll call when the farthest recursion finishes
[19:45] mikeal: i saw something on the list about groups of Promises
[19:45] mikeal: and there was some API discussion there that I think would lend itself to this problem as well
[19:46] mikeal: i mean, i have something working today, if .wait() goes away there are multiple things that could help me fix this problem, i'm just throwing this use case out there so that hopefully one of those other things happens before .wait() is deprecated
[19:48] Tim_Smart: http://gist.github.com/293938
[19:48] mikeal: same problem
[19:49] cedric_ has joined the channel
[19:49] mikeal: oh no wait
[19:49] mikeal: yeah, this is now global to the module
[19:49] mikeal: so I can't call walk twice at the same time
[19:50] mikeal: and if you take this same thing, and scope counter to walk, it'll call the callback null inside the first recursion that finishes
[19:50] Tim_Smart: Yeah I would personally make a prototype for that
[19:50] mikeal: this is where groups of promises would be helpful
[19:50] mikeal: then you could just pass the promise group in to the recusion and add more promises to it
[19:51] mikeal: and it's emitSuccess would depend on all the promises succeeding
[19:52] inimino: mikeal: why not keep a count of all outstanding promises?
[19:52] Tim_Smart: mikeal: that would have the same problem as my couter
[19:52] cedric__ has joined the channel
[19:52] Tim_Smart: *counter
[19:52] Tim_Smart: it would all be adding to the same group
[19:52] mikeal: inimino: i could, the code would just double in size :)
[19:52] inimino: I don't think it will double in size, it means adding about three lines
[19:53] mikeal: Tim_Smart: what you can do is create the promise group if one isn't passed to walk(), then pass it in the recursion, and return the promise group
[19:53] Tim_Smart: I'll create a promise group prototype for you
[19:54] mikeal: someone already has one i think
[19:54] mikeal: i saw something along those lines on the list
[19:54] Tim_Smart: yeah probably
[19:54] binary42 has joined the channel
[19:57] RayMorgan has joined the channel
[19:57] RayMorgan has joined the channel
[19:58] cedric_ has joined the channel
[20:00] ryah: anyone need a patch merged before 0.1.27?
[20:02] cedricv has joined the channel
[20:02] bentomas has joined the channel
[20:03] inimino: mikeal: http://gist.github.com/293954
[20:03] Tim_Smart: ryah: Un-cache modules?
[20:03] mikeal: inimino: what is go() ?
[20:04] Tim_Smart: felix mentioned you were looking at integrating another module system
[20:04] mikeal: oh, nm
[20:04] mikeal: sorry
[20:04] blackdog`: ryah: childprocess bug fix would be good addition for 0.1.27
[20:04] cedric__ has joined the channel
[20:05] felixge has joined the channel
[20:05] felixge has joined the channel
[20:05] blackdog`: ryah: are you thinking of leaving childprocess stuff for net2, and saw you were going to remove the files, which would not inspire me to fix it in the meantime
[20:05] blackdog`: s/and saw/i saw/
[20:06] inimino: mikeal: whoops... I made a couple errors
[20:07] inimino: mikeal: http://gist.github.com/293954
[20:07] cedric_ has joined the channel
[20:10] bentomas has left the channel
[20:11] pdelgallego has joined the channel
[20:11] cedricv has joined the channel
[20:12] ryah: blackdog`: stil have child process, it just will do the buffering in js
[20:12] ryah: instead of c++
[20:13] ryah: hopefully fix your bug at the same time
[20:13] cedric__ has joined the channel
[20:14] Tim_Smart: mikeal: If you wanted to see my approach http://gist.github.com/293938
[20:14] blackdog`: ryah: ok thanks
[20:14] rictic has joined the channel
[20:14] creationix: ryah: It's not high priority, but have you had a chance to look at my latest inspect patch?
[20:15] creationix: I think it would help people learning node to see the hidden properties of built-in prototypes
[20:17] cedric_ has joined the channel
[20:19] cedricv has joined the channel
[20:20] cloudhead_ has joined the channel
[20:20] felixge has joined the channel
[20:20] felixge has joined the channel
[20:21] cedric__ has joined the channel
[20:24] cedric_ has joined the channel
[20:26] joshbuddy has joined the channel
[20:28] cedricv has joined the channel
[20:30] cedric__ has joined the channel
[20:31] stephenlb: creationix: that sounds useful
[20:31] creationix: it would have saved me a lot of time back when I was writing up the wiki page on ecma5 implementation progress in V8
[20:32] ryah: http://s3.amazonaws.com/four.livejournal/20100203/node-v0.1.27.tar.gz
[20:32] n8o has joined the channel
[20:32] stephenlb: heh
[20:33] cedric_ has joined the channel
[20:36] CIA-78: node: 03Ryan Dahl 07master * rf3ad635 10/ (doc/api.txt src/node.cc src/node.js): Downcase process.ARGV/ENV to process.argv/env - http://bit.ly/b4mujE
[20:36] CIA-78: node: 03Ryan Dahl 07master * r0cfa789 10/ (ChangeLog doc/api.txt doc/index.html wscript): bump version - http://bit.ly/cJGZsd
[20:37] cedricv has joined the channel
[20:38] Tim_Smart: nodejs_v8: new Error('Hello')
[20:38] nodejs_v8: Tim_Smart: {"message": "Hello", "stack": "Error: Hello at evalcx:1:1 at Object. (/home/node/ircbot/lib/v8/v8evaler.js:55:26) at [object Object]. (node.js:928:23) at [object Object].emitSuccess (node.js:240:15) at [object Object]. (node.js:653:21) at [object Object].emitSuccess (node.js:240:15) at node.js:510:29 at node.js:985:9 at node.js:989:1", "name": "Error"}
[20:41] mediacoder: ryah: getting this on running the tests: http://pastie.org/808217
[20:41] noob has joined the channel
[20:44] ryah: yeah. fuck
[20:44] cedric_ has joined the channel
[20:44] ryah: ACTION annoyed
[20:46] ryah: mediacoder: git revert 704f394c6671af5b981900fc3666f1b97ef580a9
[20:46] Tim_Smart: ACTION hides
[20:46] ryah: mediacoder: does that fix it?
[20:47] mediacoder: ryah: one sec
[20:47] cedric__ has joined the channel
[20:49] mediacoder: ryah: yea, reverting to that revision fixes running tests
[20:51] cedricv has joined the channel
[20:53] cedric_ has joined the channel
[20:54] sixtus42 has joined the channel
[20:55] CIA-78: node: 03Ryan Dahl 07master * re5a41a7 10/ tools/test.py :
[20:55] CIA-78: node: Revert "Adding output of Platform information into the test runner"
[20:55] CIA-78: node: Broken on at least one platform http://pastie.org/808217
[20:55] CIA-78: node: This reverts commit 704f394c6671af5b981900fc3666f1b97ef580a9. - http://bit.ly/bCn27Q
[20:56] hassox has joined the channel
[20:57] cedric__ has joined the channel
[20:57] isaacs has joined the channel
[20:59] ericflo has joined the channel
[20:59] isaacs: so, i'm seriously considering rewriting the multipart module. could someone talk me out of that, please?
[20:59] deanlandolt_: isaacs: oh lord, don't do it...but if you do...
[21:00] ryah: isaacs: why?
[21:00] isaacs: well, it's got a few issues with headers, and doesn't stream.
[21:00] deanlandolt_: yeah -- it's the streaming part that's gonna sting :D
[21:00] mattly has joined the channel
[21:00] cedricv has joined the channel
[21:00] deanlandolt_: i'm rewriting jack's to be streaming and i think i'm going mad
[21:00] isaacs: ie, the whole message gets buffered to memory, which is an issue if you're uploading large files (which is sort of the point of multipart)
[21:01] ryah: relaly? i think you can avoid that
[21:01] isaacs: yeah, but not without significant surgery.
[21:01] ryah: i think we can probably remove it, actually
[21:01] isaacs: right now, it emits a "part" event with an object that has headers and a full body.
[21:01] isaacs: ryah: you thinking it should be a standalone thing?
[21:02] ryah: yeah, i'd rather not support it
[21:02] hassox: Morning gents
[21:02] isaacs: i dunno, it seems at least as "core" as providing http or url/qs parsing.
[21:02] ryah: and it's not really #core'
[21:02] ryah: yeah.. maybe
[21:02] ryah: :/
[21:02] deanlandolt_: isaacs: i'd say it's less core than http
[21:02] isaacs: i know you'd love to just have a javascript interface to event-based posix and tcp and call it a day ;P
[21:02] deanlandolt_: but yeah, as core as qs
[21:03] cedric_ has joined the channel
[21:03] isaacs: for better or worse, http comes along with a few wonky data-serialization styles.
[21:03] isaacs: url, query string, and multipart.
[21:03] ryah: i guess
[21:03] Tim_Smart has left the channel
[21:03] isaacs: and headers, which are in their own way a wonky data encoding thing.
[21:03] hassox: Node parses the query sting to params
[21:03] Tim_Smart has joined the channel
[21:03] hassox: Feels like thi is the same kind of thug
[21:03] hassox: Thing
[21:04] deanlandolt_: yeah, perhaps that need not be core either
[21:04] hassox: Damn autocompletr
[21:04] deanlandolt_: considering people have different interpretations of querystring parsing
[21:04] isaacs: oh, multipart and querystring are definitely both thugs.
[21:04] hassox: ;)
[21:04] isaacs: deanlandolt_: well, node's matches narwhal's and yui's.
[21:04] deanlandolt_: multipart at least has a well-specified parse
[21:04] isaacs: ACTION likes putting his code all over the place.
[21:04] deanlandolt_: oh...interesting
[21:04] deanlandolt_: definitely gut it :)
[21:04] isaacs: deanlandolt_: it only matches because i wrote all three.
[21:05] deanlandolt_: then /definitely/ gut it ;)
[21:05] isaacs: hahahah ouch!
[21:05] deanlandolt_: ACTION kids
[21:05] isaacs: yeah
[21:05] isaacs: no, srsly, maybe it makes sense to have a "node-data-utils" or something.
[21:05] deanlandolt_: it makes a few assumptions is my only problem
[21:05] nodejs_v8 has joined the channel
[21:05] isaacs: but for the data encoding mechanisms that are so widely used in http, it's kinda nice to have them out of the box.
[21:06] deanlandolt_: it assumes a content-length for both the message and the individual parts AFAICT and neither are required by the spec
[21:06] cedric__ has joined the channel
[21:06] deanlandolt_: i can see why you did it though...i'm trying the alternative (plus streaming) and it's not going well
[21:07] isaacs: deanlandolt_: i didn't write node's multipart.js
[21:07] deanlandolt_: ah, that was felixge, right?
[21:07] isaacs: yeah
[21:08] nodejs_v8 has joined the channel
[21:09] hassox: isaacs: What are you going to make it do?
[21:09] isaacs: i've pinged him about it, but it seems like he's busy with other stuff. understandable, of course, we all have day jobs.
[21:09] isaacs: hassox: just behave more like an http message.
[21:09] isaacs: i mean, that's kind of what multipart messages are, right?
[21:09] isaacs: they're a bunch of http messages inside the body.
[21:09] cedricv has joined the channel
[21:09] deanlandolt_: isaacs: sweet...that's my exact same goal
[21:10] isaacs: so it'll emit a "part" event with the Part object, which has headers and a streaming body.
[21:10] isaacs: the Part emits "data" for each chunk, and then "end" when it's done
[21:10] deanlandolt_: isaacs: what about nested multipart? :D
[21:11] hassox: You can nest them?
[21:11] isaacs: deanlandolt_: if Part.headers has a multipart/blerg content-type, then you can just feed the Part to the multipart parser again.
[21:11] isaacs: hassox: indefinitely.
[21:11] isaacs: you can attach an email to an email which has an attchment which contains an email thread and a jpeg.
[21:11] hassox: I c
[21:11] isaacs: and so on and so on
[21:11] deanlandolt_: sheer madness
[21:11] hassox: I didn't know that
[21:11] isaacs: not common in http, but very very common in email.
[21:11] isaacs: which is where multipart was developed.
[21:12] deanlandolt_: yeah, but common enough in http to presumably be useful (e.g. i could see the use case in something like multipart/alternative)
[21:12] isaacs: sure. and there's the data:uri hack that you can use for MSIE where you send a multipart message and then refer to images by their multipart content-disposition filename.
[21:13] deanlandolt_: oh, didn't know that...cool
[21:13] isaacs: a buddy of mine worked out a CSS processor that would check the user-agent and either send data: uris or multipart messages.
[21:13] hassox: WTF
[21:13] isaacs: hassox: inorite?
[21:13] isaacs: but every css file was 1 connection, and 100% cacheable, so no need for spriting.
[21:14] isaacs: and spriting is a royal PITA
[21:14] hassox: U know lots of stuff don't you :p
[21:14] okito has joined the channel
[21:14] isaacs: so, yeah, you might have some very very big things in a multipart message.
[21:14] deanlandolt_: especially multipart/form-data coming from a browser
[21:15] isaacs: right
[21:15] isaacs: that's like the classic case for why buffering the request body is a Bad Idea.
[21:16] cedric_ has joined the channel
[21:17] isaacs: ah, so there is a stream in it...
[21:17] deanlandolt_: in what?
[21:18] isaacs: in node/lib/multipart.js
[21:18] isaacs: but that's not what's actually exposed when you parse()
[21:19] deanlandolt_: ahh...perhaps some surgery wouldn't be as difficult
[21:19] cedric__ has joined the channel
[21:23] cedricv has joined the channel
[21:24] BBB has joined the channel
[21:25] cedric_ has joined the channel
[21:27] Tim_Smart: I had a nice idea for static files like CSS etc, will integrate it into the frame me and some others are working on
[21:28] Tim_Smart: *framework
[21:28] ericflo_ has joined the channel
[21:29] cedric__ has joined the channel
[21:33] cedricv has joined the channel
[21:35] cedric_ has joined the channel
[21:48] mikeal has joined the channel
[21:48] cedric__ has joined the channel
[21:48] deanlandolt_: isaacs: another use for streaming multipart -- the new riak json api implements streaming by returning json objs back as multipart...not quite sure how i feel about that but there ya go :-/
[21:48] isaacs: i see.
[21:48] isaacs: that's actually kinda cool.
[21:48] isaacs: i htink twitter's json streaming api does that, too
[21:49] deanlandolt_: i guess that solves the streaming json parsing problem but /wow/
[21:49] isaacs: not sure if it's actually multipart messages or just transfer-encoding:chunked
[21:49] isaacs: it's actually not a bad way to do it. uses existing protocols, at least.
[21:49] geelen has joined the channel
[21:49] isaacs: but yeah, you *can't* hope to buffer the whole request if it's a streaming thing.
[21:49] isaacs: it'll never end.
[21:50] deanlandolt_: i guess (though they're breaking some rules...setting accept: application/json and sending back multipart for instance
[21:50] isaacs: if you accept multipart and also something else, then you implicitly accept multipart messages containing that other thing, iiuc
[21:50] deanlandolt_: instead of a qs switch (chunked=true) they should have just switched on the accept header
[21:50] isaacs: so you could have accept: multipart/mixed, appilcation/json
[21:51] isaacs: and that would say "i accept multipart messages, and i accept json messages"
[21:51] deanlandolt_: that seems right...you could also tack a q on one or both to define your preference
[21:51] cedricv has joined the channel
[21:51] isaacs: sure
[21:52] isaacs: in practice, though, q is only relevant if it's a choice.
[21:52] isaacs: for multipart, you either accept it or you don't.
[21:52] isaacs: ie, if you're choosing between xml and json, then it matters
[21:52] deanlandolt_: but it /should/ be (e.g. send me back multipart or json, streamed)
[21:53] deanlandolt_: what's the difference between a json, xml or multiple including json (or xml)? they're just encodings of the same data
[21:53] isaacs: if you just specify multipart, but nothing else, then the server should send back an "unacceptable" header.
[21:53] isaacs: because the parts of a multipart message must be acceptable.
[21:53] felixge has joined the channel
[21:53] felixge has joined the channel
[21:53] isaacs: felixge: !
[21:53] isaacs: multipart man!
[21:53] mikeal: is there an estimate on the net2 branch getting merged?
[21:53] deanlandolt_: hmm...i'll have to go back and read some more -- but that sounds reasonable
[21:54] felixge: isaacs: yip yip yeah
[21:54] felixge: isaacs: sup?
[21:54] ryah: mikeal: soon
[21:54] mikeal: awesome
[21:54] ryah: less than 2 weeks
[21:54] ryah: :)
[21:54] isaacs: felixge: you get my message about multipart stuff? you can have first crack at it, or i can send you some code soonish.
[21:54] ryah: playing with dtrace
[21:54] ryah: it's so awesome
[21:54] mikeal: it really is
[21:55] mikeal: i hope Oracle re-licenses it
[21:55] isaacs: if you got other stuff, that's cool, i can do it. i don't want to step on any toes. i'd like a review if that's the case, though.
[21:55] ryah: linux really needs it
[21:55] mikeal: definitely, more than linux needs ZFS
[21:56] isaacs: mikeal: but ZFS means that our computers could be actually turing complete!
[21:56] felixge: isaacs: reading the backlog, you are thinking that multipart buffers the whole file?
[21:56] mikeal: haha
[21:56] isaacs: felixge: well, i see that you can use require("multipart").Stream
[21:56] isaacs: but require("multipart").parse is so tempting.
[21:56] isaacs: which definitely does buffer everything.
[21:56] felixge: isaacs: right, but parse is for idiots ;)
[21:56] cedric_ has joined the channel
[21:56] isaacs: hahaha
[21:57] mikeal: there are enough good fs engineers that work on linux that i think something competitive with zfs will come out for linux in the next few years, but nobody has anything nearly as awesome as dtrace in the works
[21:57] isaacs: also, i'd like for it to support other kinds of multipart messages.
[21:57] felixge: isaacs: sure
[21:57] isaacs: nested multipart, multipart/mixed, etc.
[21:57] mikeal: we just need to make sure that the next great linux filesystem engineer isn't a murderer
[21:58] felixge: isaacs: but I don't think the current module is fundamentally flawed for what it was designed to do
[21:58] felixge: and by that I mean dealing with HTTP multipart
[21:58] isaacs: felixge: no, but i need it to do other things, too :)
[21:58] felixge: right, it will suck for those
[21:59] felixge: the main reason I didn't make it more generic is that I had no other real-world problems to test against
[21:59] isaacs: what if parse() returned a Message stream that emits "part" events with messages that stream.
[21:59] hassox has joined the channel
[21:59] felixge: and I learned my lesson from implementing specs without actually using the implementation in the real world :
[21:59] cedric__ has joined the channel
[22:00] isaacs: felixge: i just got a job at a company that does email.
[22:00] felixge: isaacs: hah, :)
[22:00] felixge: poor you, email is terrible :)
[22:00] isaacs: haha
[22:00] isaacs: yeah, it's like HTTP's older uglier cousin.
[22:01] isaacs: but anyway, my interest here isn't strictly academic, is what i'm saying.
[22:01] felixge: Right now my main pattern for writing node modules is to have 1 API that is low level and allows you perfect streaming
[22:01] isaacs: (it's partly academic, but not entirely)
[22:01] felixge: and 1 API that is focused on ease of use
[22:01] devinus has joined the channel
[22:02] isaacs: how about 1 api that is easy to use and low level and provides perfect streaming?
[22:02] felixge: I didn't see one, but I sure want one
[22:03] felixge: I actually think the low-level part API I got right now is fairly simple
[22:03] felixge: and I use it all the time
[22:03] isaacs: yeah, it's pretty nice.
[22:03] cedricv has joined the channel
[22:03] felixge: I mainly added multipart.parse() because it allowed people to deal with simple form submits
[22:03] felixge: before we had querystring
[22:04] felixge: imho streaming is overkill there
[22:04] isaacs: just the header parsing isn't quite right, it doesn't handle any other kind of multipart, and streaming isn't the default.
[22:04] felixge: isaacs: oh the header parsing is really stupid
[22:04] isaacs: it'd be nice if the "Part" objects looked just like an http message.
[22:05] felixge: sure
[22:05] isaacs: also, parse() should construct and return a stream, rather than waiting around for the whole thing.
[22:05] jed_ has joined the channel
[22:05] cedricv has joined the channel
[22:05] isaacs: multipart.parse() just *looks* like it should be the thing to do, ya know?
[22:06] felixge: isaacs: not sure. Pretty much all other '.parse()' functions in node/JS are making a potentially streaming operation look atomic
[22:06] felixge: like JSON.parse()
[22:06] felixge: or querystring.parse()
[22:06] okito has joined the channel
[22:06] felixge: both "could" be streaming API's
[22:06] isaacs: right, but in those two cases, it's not a streaming message.
[22:06] felixge: but they are not
[22:06] isaacs: with qs, you have the whole thing already.
[22:07] felixge: isaacs: ?
[22:07] felixge: why?
[22:07] isaacs: with mp, you're kinda parsing it as you go.
[22:07] felixge: if I have a regular form with input fields
[22:07] felixge: I get a stream of urlencoded data
[22:07] felixge: querystring forces me to buffer that
[22:07] felixge: before parsing
[22:07] felixge: But I'd argue that is merely due to the buffer being very small here for most cases
[22:08] felixge: so it "seems" more natural
[22:08] isaacs: right
[22:08] devinus: RayMorgan: i really like your template engine
[22:08] felixge: but generically speaking, it's wrong
[22:08] isaacs: the vast majority of the time, qs is used for the get params.
[22:08] isaacs: url.parse(req.url, true);
[22:08] felixge: right, but even those could be split into packages
[22:08] felixge: ryan's http parser just doesn't go into the mental wankery of straming that
[22:08] felixge: :)
[22:09] cedric_ has joined the channel
[22:09] isaacs: felixge: so, you missed the bit where we talked about which HTTP data dialects belong in node and which dont.
[22:09] isaacs: qs and multipart are kinda on the edge.
[22:09] felixge: hm I agree with that
[22:09] felixge: but I believe they are common enough to justify support
[22:09] isaacs: i think one step further, you've got cookie and imap
[22:09] rednul_ has joined the channel
[22:09] isaacs: HTTP has so many data serialization dialects, it's crazy.
[22:10] felixge: I'd argue querystring is more important than multipart
[22:10] felixge: you have that everywhere
[22:10] isaacs: right.
[22:10] isaacs: multipart could be its own lib or something.
[22:10] felixge: So multipart being core is a real edge case
[22:10] isaacs: but it's a pain to parse incoming form posts otherwise.
[22:10] felixge: I told ryan I wrote a multipart parser and he asked me if I'd clean it up for the core
[22:10] isaacs: forget simple forms, i'm talking upload stuff.
[22:11] felixge: so I did
[22:11] felixge: ;)
[22:11] felixge: right
[22:11] devinus: guys... i need a name to give my web microframework so i can release it on github.... :-/
[22:11] isaacs: devinus: name it after your cat.
[22:11] felixge: and I've seen "file uploading" as a very common use case that is cited if people ask what node.js is good at ;)
[22:11] devinus: "webfw" just isnt working for me....
[22:11] isaacs: devinus: if you don't have a cat, name it after your friend's cat.
[22:11] felixge: devinus: cat /dev/rand
[22:11] RayMorgan: devinus: thanks
[22:11] felixge: :)
[22:12] cedric__ has joined the channel
[22:12] devinus: RayMorgan: i'm using it in my web fw
[22:12] devinus: RayMorgan: as the default
[22:12] isaacs: devinus: Call it freeway
[22:12] RayMorgan: cool!
[22:12] devinus: hrm....freeway
[22:12] devinus: i like that
[22:12] isaacs: (fw)
[22:13] devinus: freeway it is
[22:13] isaacs: ACTION wins at name!
[22:13] felixge: isaacs: so anyway, what would you like to discuss. Making multipart more awesome, or whether it should be core or not?
[22:13] isaacs: felixge: i want to make it awesome.
[22:13] isaacs: felixge: imo, it should be core.
[22:13] isaacs: handling POSTs are so important.
[22:14] felixge: right, and I think file uploading is very common use case why average joe might become interest in node
[22:14] felixge: * interested
[22:15] isaacs: so, how about this for a plan of attack: 1) fix the headers to make the parts look more like HTTP messages, 2) make parse() return a part-emitting thing, 3) handle more than just multipart/form-data
[22:15] konobi: multipart parsing isn't too hard until you get into nested parts
[22:15] felixge: I'd say lets throw it out once node has awesome package managment
[22:15] isaacs: agreed.
[22:15] isaacs: ACTION is working on awesome package management, and is not the only one.
[22:15] hassox: dudes if there's a vote, I vote that we keep multipart in core
[22:16] hassox: if for no other reason than all http frameworks are going to need this
[22:16] mikeal: it makes me happy that there is hardly anything in core and a bunch of good people working on packaging and distribution systems
[22:16] cedricv has joined the channel
[22:16] isaacs: once npm is working great, i'd love to bundle multipart, cookie, imap, and whatever other crazy dialects HTTP might have into a node-data-utils package.
[22:16] hassox: and this solution will be solid
[22:16] konobi: RFC2822 Parser
[22:16] mikeal: Python and Ruby jumped the gun on stdlib additions and blessing package managers way too early and now it's just ruined forever
[22:16] hassox: every web application needs it
[22:16] isaacs: konobi: sure
[22:16] isaacs: mikeal: yes, competition is winful for everyone involved.
[22:17] isaacs: mikeal: *especially* the people working on the apps that "lose"
[22:17] mikeal: definitely
[22:18] isaacs: felixge: so, how's that sound? the other question: you wanna write it, or review it? i'm cool either way.
[22:18] felixge: isaacs: I shoudn't write it, I have no real-world data to test against
[22:18] isaacs: okie dokie
[22:18] felixge: isaacs: the only thing is that we might want to wait for net2
[22:19] felixge: isaacs: as we'd use buffers instead of strings
[22:19] felixge: isaacs: so maybe you want to work with net2 right away, not sure
[22:19] charlenopires has joined the channel
[22:20] isaacs: felixge: nah, i'm thinking i'll just make the parts mock the HTTP message stream API, and then we can switch them over for net2.
[22:20] isaacs: it'll probably be a light change.
[22:20] felixge: isaacs: ok, good plan
[22:20] isaacs: ACTION is afraid of net2
[22:20] brandon_beacher has joined the channel
[22:20] felixge: isaacs: I can test your implementation against lots of real world file uploads right away with transload.it : )
[22:20] isaacs: great!
[22:20] felixge: so even if the unit tests may not catch something subtle, I will
[22:20] isaacs: that's very encouraging. i feel a lot safer with that in mind ;)
[22:21] isaacs: what email client do you use?
[22:21] felixge: isaacs: yeah - multipart might be somewhat single-minded at this point due to my motives for writing it - but it's pretty solid for that use case : )
[22:21] felixge: isaacs: gmai web interface
[22:21] felixge: * gmail
[22:21] felixge: (actually embedded in mailplane)
[22:21] cedric_ has joined the channel
[22:21] isaacs: heh, me too
[22:22] konobi: multipart is also useful for email
[22:22] isaacs: can you send a rich-text message with a file attachment to i@izs.me?
[22:22] felixge: konobi: right, isaacs wants to make it work great with email now
[22:22] isaacs: pref rich-text with some formatting.
[22:22] felixge: konobi: which I think is gonna be sweet
[22:22] felixge: isaacs: sure can
[22:22] isaacs: well, i can't guarantee that it'll be "great" with email. email is a bear.
[22:22] konobi: ACTION has had enough of mail... especially multipart parsing event-driven
[22:23] isaacs: also, not to mention that IMAP is kind of a defacto standard, and exchange just abuses it all to hell.
[22:23] felixge: isaacs: sent
[22:24] isaacs: thanks
[22:24] isaacs: (really i just wanna feel like i have friends. no one sends me email. i cry every day.)
[22:24] isaacs: lolz! unicycle.
[22:24] felixge: :)
[22:24] cedric__ has joined the channel
[22:25] felixge: isaacs: yeah I thought it was fitting - to prepare you for the challenges ahead *g*
[22:25] isaacs: nice, it got nested even.
[22:26] felixge: good :)
[22:27] cedric__ has joined the channel
[22:27] isaacs: ok, hey, another non-core data dialect: "quoted-printable"
[22:27] isaacs: jeez.
[22:28] isaacs: the web has an encoding language fetish.
[22:28] felixge: isaacs: http://groups.google.com/group/nodejs/browse_thread/thread/6e6688236e05c353 you are saying I didn't reply to you
[22:28] isaacs: oh, yeah, yo uhadn't yet at that point.
[22:28] felixge: but I think I did reply to the thread saying you're diff to multipart looks good but I'm not sure all headers should be given as an array by default
[22:28] isaacs: ohh, no,i'd emailed you directly.
[22:28] isaacs: you dind't get that?
[22:29] felixge: I did, but I responded in the group before I saw your email (I'm addicted so I surf the google group web interface all the time)
[22:29] isaacs: ahh, i see.
[22:29] felixge: so I never replied to the email itself
[22:29] isaacs: sorry for the confusion. i just figured you were otherwise occupied.
[22:30] cedric_ has joined the channel
[22:31] felixge: isaacs: np. But it's safe to assume I read most stuff on the list
[22:31] felixge: unless it's one of those big threads without content
[22:31] isaacs: ok, cool. i try to, but i miss a lot of stuf.
[22:31] felixge: where people just endlessly debate half-baked ideas
[22:31] isaacs: i definitely at least try ot scan the headlines.
[22:31] felixge: I usually post one message there and ignore the rest
[22:31] felixge: ;)
[22:32] isaacs: sure, after you've told everyone the right answer, no need to stick around, right ;)
[22:32] felixge: if there is an idea worth talking about people will bring it up again in here
[22:32] felixge: haha
[22:32] felixge: no
[22:32] felixge: my proposals suck, I just want them listed for future reference
[22:34] felixge: but I feel we need a node-core list at some point
[22:34] cedricv has joined the channel
[22:35] felixge: some problems are just best to work on in a small circle before publishing them to the general public
[22:35] creationix: yeah, the mailing list isn't the small circle it used to be.
[22:35] rictic: ok stupid question. I like using promises in node and I want to use something similar in the browser. Any recommendations of a library to use?
[22:35] felixge: For example if you or ryan post a message I'll certainly read it in full and try to understand the entire argument. But very often I do that with a new guy on the list only to find out their understanding of JS is fundamentally flawed :)
[22:36] felixge: rictic: I have a promise port for the browser
[22:36] isaacs: felixge: that does kinda happen sometimes.
[22:37] rictic: felixge: cool, is it posted anywhere?
[22:37] cedric__ has joined the channel
[22:37] felixge: rictic: no, it's not perfectly up-to-date with some new API changes either
[22:37] felixge: rictic: but I can copy & paste it to you
[22:37] devinus: TCP/IP connections from node?
[22:38] devinus: not possible?
[22:38] isaacs: devinus: sure, you can do direct tcp
[22:38] felixge: rictic: ah shoot, seems like I never ported promises, just EventEmitter
[22:38] felixge: rictic: sorry
[22:38] rictic: EventEmitter is all I need
[22:38] rictic: Promise is very minimal on top of that
[22:39] isaacs: require("tcp"). http://nodejs.org/api.html#_tcp
[22:39] felixge: rictic: try this: https://gist.github.com/c8202b1d4d8a95d90fe2
[22:39] devinus: d'oh!
[22:39] felixge: rictic: not a complete port, but it's the essence
[22:40] rictic: It's something to start with at least; BSD licensed?
[22:41] isaacs: hm, do any mailing lists still use the "multipart/digest" style?
[22:41] felixge: rictic: public domain for ya ;)
[22:42] rictic: Great, thanks
[22:44] Tim_Smart: felixge: Did you talk to ryah about the un-cache thing?
[22:45] creationix: My howtonode.org server has had over 17k requests today. (requests, not unique visitors) node sure seems to attract a lot of people.
[22:45] felixge: Tim_Smart: yeah, he's accepting patches for it
[22:45] konobi: creationix: time to get some google analytics on there =0)
[22:45] felixge: so it's just a matter of finishing the work on it
[22:45] Tim_Smart: Well I can make a patch
[22:45] creationix: konobi: I did earlier today, but we can't see it for 24 hours
[22:45] konobi: =0)
[22:45] Tim_Smart: but you are half done aren't you?
[22:46] felixge: Tim_Smart: 80%
[22:46] felixge: just trying to do too many things, as usual :)
[22:46] Tim_Smart: felixge: What needs doing? I can fork and complete it
[22:46] ryah: ACTION is pulling his hair out trying to use the mac. so annoying
[22:46] ryah: don't know how you all can do this
[22:47] Tim_Smart: ryah: I are linux user :p
[22:47] creationix: ryah: I only do it for textmate, the terminal emulator is terrible
[22:47] okito has joined the channel
[22:47] Tim_Smart: vim > textmate
[22:47] felixge: ryah: what are you doing on a mac?
[22:48] inimino: vim rules :-)
[22:48] ryah: joyent gave me one
[22:48] Tim_Smart: ACTION takes a screenshot of his sexy vim
[22:48] ryah: playing with dtrace is fun tough
[22:48] stephenlb: vim++
[22:48] creationix: well, on linux I used Gedit. the plugins are pretty powerful
[22:48] felixge: ryah: install linux :)
[22:48] ryah: felixge: i'm going to
[22:48] isaacs: ryah: but they're so pretty!
[22:48] isaacs: also, i can use hardware without getting into a spitting contest with X11
[22:48] felixge: ryah: http://www.irradiatedsoftware.com/sizeup/ is my only helper when it comes to window management
[22:48] creationix: sadly linux doesn't run quite right on the new mac book pros
[22:48] cedric_ has joined the channel
[22:48] ryah: isaacs: you haven't seen my setup :)
[22:48] isaacs: you plug in the monitor, and there ya go, it works.
[22:49] ryah: isaacs: that's true
[22:49] ryah: doing presentations on linux blows
[22:49] felixge: switching plattforms always sucks
[22:49] Tim_Smart: Tim's sexy vim http://yfrog.com/j1screenshot017dp
[22:49] felixge: took me 6 month before I was comfortable on the mac after coming from window
[22:49] felixge: * windows
[22:50] felixge: ryah: http://code.google.com/p/macvim/ try this one
[22:50] isaacs: yeah, macvim is nice. if i was more of a man, i'd use that.
[22:50] konobi: ACTION gave up on linux/bsd for desktop usage quite a while ago
[22:50] creationix: although, ubuntu is getting better about working out of the box. Presentations sometimes work on first try.
[22:50] isaacs: ACTION is a wimpy textmate user.
[22:51] ryah: but then i can't ^Z to the terminal
[22:51] ryah: ^- if i use macvim
[22:51] konobi: ryah: i just use vim from macports
[22:51] felixge: ryah: right, but using the terminal vim feels too awkward for me on the mac
[22:51] felixge: no integration with system clipboard
[22:51] creationix: you know, I programmed in the QBasic ide for 10 years when I was younger. It took a while to transition away from that interface.
[22:52] creationix: ryah: I've heard there are better terminal emulators for osx, I agree the built in one sucks for vim
[22:52] felixge: I started on a C64 with basic, but then got sucked into Visual Basic. I got so lucky I don't sit in a cubicle today
[22:52] felixge: :)
[22:52] cedricv has joined the channel
[22:53] konobi: Terminal.app with a few tweaked settings is fine for everyday use
[22:53] stephenlb: felixge: nice to have three distinct clipboards... Yanked (from vim), Buffer (from screen), and system clipboad.
[22:53] isaacs: ACTION <3 iTerm
[22:53] creationix: konobi: what do you tweak
[22:53] felixge: stephenlb: not nice if you can't bridge between them
[22:53] isaacs: i just use one clipboard, and pipe to pbcopy and pbpaste on the terminal.
[22:53] isaacs: it's nice.
[22:54] stephenlb: isaacs: nice
[22:54] felixge: pbcopy / pbpaste = <3
[22:54] felixge: :)
[22:54] konobi: creationix: term type, some key bindings, meta stuff
[22:54] cedric__ has joined the channel
[22:55] ryah: each time i turn back to linux i feel so safe
[22:55] creationix: konobi: I'd be interested in some specifics.
[22:55] ryah: then i turn back to the mac and feel scared and small
[22:55] konobi: xterm-color... make sure delete doesn't send Ctrl-H, paste newlines
[22:55] creationix: ryah: I own a high-powered system-76 ubuntu laptop, want to trade it for your macbook?
[22:56] creationix: ryah: of course, I'm sure you like the new mac, so that's probably a no :P
[22:56] isaacs: felixge: so, you accept { options: {...}, data : "..." } in multipart. anyone actually using that?
[22:57] konobi: creationix: also i've had to do some termcap changes on other machines I use
[22:58] creationix: konobi: Seems those are the defaults on my Terminal.app
[22:58] konobi: creationix: mac's are also company standard =0)
[22:58] creationix: my main problem is an inability to go to the end of a line in vim using the end key
[22:59] konobi: creationix: /me uses $
[22:59] felixge: isaacs: not me, I just didn't want to tie it to HttpRequest
[22:59] felixge: isaacs: at least not without an alternative
[22:59] isaacs: ok
[22:59] konobi: creationix: http://theandystratton.com/2009/fixing-home-end-page-up-and-page-down-in-leopards-terminal
[22:59] isaacs: well, if i'm going to parse an email message, there's still the headers/body distinction.
[23:00] jcrosby has joined the channel
[23:00] creationix: konobi: Cool, I knew there was a key for that somewhere. I just need to learn real vim commands
[23:00] konobi: and ^ for start of line
[23:00] Tim_Smart: IRC Bot framework for anyone interested http://dl.dropbox.com/u/396394/ircbot_frame.tar.gz
[23:00] cedric_ has joined the channel
[23:00] felixge: isaacs: feel free to break the entire API
[23:00] isaacs: so i think i'm gonna also change it to be { headers : {...}, body : "...." } as an option.
[23:00] isaacs: hahah
[23:00] isaacs: felixge: i don't need any encouragement!
[23:00] Tim_Smart: uses the same backend as nodelog
[23:00] konobi: Ctrl+u for page up, Ctrl+d for page down
[23:00] felixge: isaacs: I will not be mad as long as I can still get file uploads to work :)
[23:00] isaacs: great.
[23:00] Tim_Smart: slightly modified
[23:02] felixge: Tim_Smart: I kinda hope somebody would write a nicer IRC bot
[23:02] felixge: I really just wrote the IRC module to get a basic channel log bot going
[23:02] felixge: it could be much much nicer
[23:03] Tim_Smart: felixge: That framework is pretty good. I abstracts it alot more. Look at example.js
[23:03] Tim_Smart: *It
[23:04] cedricv has joined the channel
[23:06] cedric__ has joined the channel
[23:07] creationix: Hey, quick question. I plan on writing another article for the node blog in a few hours. What top should I write about?
[23:08] Tim_Smart: creationix: http://github.com/biggie/biggie - but I am biased
[23:08] felixge: creationix: node-dirty :)
[23:09] kriszyp: are you looking for us to self-nominate our node projects for coverage? :)
[23:09] felixge: creationix: I would write about scraping, doing multiple http requests at the same time
[23:09] creationix: ahh, http clients, not a bad idea
[23:09] Tim_Smart: yeah the benefits of Evented IO
[23:09] felixge: creationix: interesting topic and node really shines at making it simple
[23:09] cedric_ has joined the channel
[23:11] Tim_Smart: if anyone wants to join JimBastard, tmpvar and me with http://github.com/biggie/biggie ... let one of us know
[23:11] devinus: ACTION wonders he can use google caja to allow user scripting from node....
[23:14] cedric__ has joined the channel
[23:16] mediacoder: creationix: maybe you could clear up with ryan, whats up with net2 and the 0.3 release. i think there might be interest in a info-post (well..not really blog-article-worthy, maybe), since people are expecting the 0.3 release and api freeze (which ryan scheduled for early 2010 in soeme talk, iirc)..
[23:17] mediacoder: or maybe something about all *GI stuf which is going on at the moment
[23:18] creationix: *GI?
[23:18] mediacoder: jsgi, ejsgi, whatsoever
[23:18] kriskowal has joined the channel
[23:19] cedricv has joined the channel
[23:19] creationix: Tim_Smart: I don't really want to write an article about someone else project since I don't know much about it myself, but you're more than welcome to write one yourself.
[23:19] mediacoder: or maybe clear up some things one the recent promise, deferredes, continuables, etc discussions. or something like that maybe :-)
[23:19] Tim_Smart: I was just kidding
[23:19] Tim_Smart: :p
[23:20] isaacs: the ([ea]j|p)sgi stuff is a good blogworthy subject.
[23:20] Tim_Smart: Just talk about what node.js does well
[23:20] Tim_Smart: like target audiences etc
[23:20] Tim_Smart: why people should consider it
[23:21] devinus has left the channel
[23:21] cedric_ has joined the channel
[23:22] creationix: I do want every article to have some code and explanations of the code in it (so I can classify it as a technical blog), but yes, we should probably clear up what node is since there has been a lot of confusion and hype lately.
[23:24] RayMorgan_ has joined the channel
[23:24] cedric__ has joined the channel
[23:24] geelen has joined the channel
[23:25] technoweenie: creationix: are you the author of that node control flow article
[23:25] creationix: yep
[23:25] technoweenie: i dug that article, especially that combo object
[23:26] creationix: I'm no node expert by any means (are any of us yet?) but I have written a few libraries and am starting to see some patterns
[23:28] cedric_ has joined the channel
[23:32] cedric__ has joined the channel
[23:33] technoweenie: yea i have something i called the PromiseGroup
[23:33] technoweenie: very similar, but i like your implementatino better
[23:34] bryanl has joined the channel
[23:35] cedricv has joined the channel
[23:36] Tim_Smart: Anyone seen Facebook's HipHop PHP yet?
[23:36] Tim_Smart: compiles PHP to C++, then runs it through g++ compiler
[23:37] mediacoder: worst name ever :-D
[23:37] cedric_ has joined the channel
[23:38] Tim_Smart: Still doesn't solve the blocking call problem though >.>
[23:38] Tim_Smart: So it still has the IO weakness
[23:43] cedricv has joined the channel
[23:44] cedric_ has joined the channel
[23:45] RayMorgan has joined the channel
[23:47] isaacs: Tim_Smart: sure, but for a company with a huge pile of working PHP code, that does a lot of page views, it's pretty keen.
[23:47] Tim_Smart: yeah
[23:47] cedric__ has joined the channel
[23:49] joshbuddy has joined the channel
[23:49] joshbuddy has joined the channel
[23:50] mattly has joined the channel
[23:51] cedricv has joined the channel
[23:54] cedric_ has joined the channel
[23:55] bryanl has joined the channel
[23:57] cedric__ has joined the channel