[00:00] mikeal: if the docs are moderately sized using a newer spidermonkey can be a 30x increase [00:02] Tim_Smart: I have xulrunner-1.9.2 installed, which version would be 'newer spidermonkey'? [00:02] mikeal: 1.8.3 or higher [00:02] mikeal: for spidermonkey [00:02] mikeal: xulrunner versioning doesn't track directly with spidermonkey [00:02] mikeal: i know, it's insane [00:03] mikeal: one of the reasons I'm going to make the view server js vm independent [00:04] Tim_Smart: Brilliant. Would be cool to chuck V8 in there or something (If that is possible?) [00:04] mikeal: yup [00:04] mikeal: we're going to [00:04] mikeal: just need a readline implementation for v8 [00:05] mikeal: but we really want to get v8 support to reduce our deps on Android [00:05] Tim_Smart: Ah portability is always welcome. [00:05] mikeal: pretty soon you'll have a CouchDB in your browser, boom! [00:06] mikeal: http://github.com/mikeal/IDBCouch [00:11] marshall_law: creationix: so we're on for Wednesday night? [00:11] creationix: marshall_law: I think so [00:11] marshall_law: sweet [00:11] creationix: node meetup Wednesday night at Sencha (was Ext.js)! [00:12] marshall_law: wewt [00:12] creationix: Palo Alto, CA, anyone in the area is welcome to come, just let me know [00:12] marshall_law: creationix: wanna send an email to the list? [00:12] creationix: I think so [00:13] _announcer: Twitter: "Twitter bot using coffeescript and nodejs http://tumblr.com/xgxcd0t0a" -- Jack Russell SC. http://twitter.com/jackhq/status/17290626855 [00:14] SteveDekorte has joined the channel [00:15] creationix: marshall_law: I'm just double checking with my ceo to make sure the office is available and he can host the meetup (last time there was free dinner and beer) [00:15] marshall_law: oh nice [00:15] marshall_law: that would be ideal :) [00:15] shimondoodkin: how do you run a coffeescript script? [00:15] Tim_Smart: With coffee! [00:15] Tim_Smart: coffee myscript.coffee [00:16] shimondoodkin: is it the same as node? [00:16] Tim_Smart: npm install coffee-script (if you have npm installed) [00:16] Tim_Smart: shimondoodkin: It runs on top of node [00:17] isaacs: ryah: well, that's interesting, but i'm not completely sold on it being necessary or bug-free. [00:18] isaacs: ryah: Tim_Smart had actually explored something very similar to that, but it caused weirdness in a lot of cases with instanceof and === [00:18] Tim_Smart: isaacs: O hai! [00:18] Tim_Smart: Is this sandboxing modules? [00:18] isaacs: hey there! [00:18] isaacs: Tim_Smart: yeah, ryah'd asked about that way up in the scrollback [00:19] Tim_Smart: I got pretty far with it, only a few cases that proved difficult [00:19] jashkenas has joined the channel [00:19] malkomalko has joined the channel [00:19] Tim_Smart: SteveDekorte: ping [00:20] SteveDekorte: Tim_Smart: pong [00:20] Tim_Smart: I saw this yesturday http://www.iolanguage.com/paste/p/f05588fa6.html [00:20] isaacs: Tim_Smart: anything that might be easier now that we have script.createContext? [00:20] Tim_Smart: SteveDekorte: Yes it can be optimized further (It was one of your questions) [00:21] charlesjolley- has joined the channel [00:21] SteveDekorte: Tim_Smart: do you mean made more elegant and easier to understand? [00:21] Tim_Smart: Yes: http://gist.github.com/456595 [00:21] Tim_Smart: Whoops wrong paste [00:22] Tim_Smart: SteveDekorte: Try http://gist.github.com/456595 again [00:23] Tim_Smart: isaacs[away]: How is that different to the old evalcx? [00:24] Tim_Smart: (That allowed to specify a context) [00:24] _announcer: Twitter: "“Even if you don’t use Node.js, you should check this page out for the design alone — it’s stunning.” http://j.mp/8ZGF6f http://vowsjs.org/" -- elliottcable. http://twitter.com/elliottcable/status/17291228428 [00:24] SteveDekorte: Tim_Smart: that's a bit better, sadly, it's still hard to read and only works for this particular case [00:25] Tim_Smart: SteveDekorte: I found it easier to read than the io version (Mainly because I work with Javascript more) [00:26] SteveDekorte: It took me a few hours to write and debug the JS version, about 10 mins to write and debug the Io one. [00:26] Tim_Smart: I would have been the opposite for me :) [00:26] Tim_Smart: *It [00:26] SteveDekorte: mostly, the contexts keep getting confused with the JS version [00:26] SteveDekorte: and I had to deal with things like one socket getting data before the other was connected [00:27] SteveDekorte: so I had to have a small state machine to deal with that case [00:27] joshbuddy has joined the channel [00:27] joshbuddy has joined the channel [00:27] Tim_Smart: My mind thinks asynchronously, and knows the Node.js API well (Well better than io-language) [00:27] SteveDekorte: which seemed particularly painful given how simple this task is - I wouldn't want to implement a complex protocol with callbacks [00:27] Tim_Smart: Callbacks reflect reality [00:28] SteveDekorte: Tim_Smart: I don't see how either is less real [00:28] Tim_Smart: Something happens after an event [00:28] Tim_Smart: callbacks specify what [00:28] SteveDekorte: you have to built state to track what is going on either way [00:28] SteveDekorte: the coro solution stores that state on the stack [00:29] SteveDekorte: actually either way often does [00:29] Tim_Smart: I don't save state anywhere in my example? Unless I'm missing something. [00:29] SteveDekorte: callbacks often rely on state within the lexical scope [00:29] SteveDekorte: so you've got a stack of scopes either way [00:29] creationix: mikeal: you around? [00:30] mikeal: yup [00:30] SteveDekorte: it's just that the pure callback way makes a mess of the code [00:30] Tim_Smart: Ah so you find the scope issue a little unbearable [00:30] creationix: mikeal: I got nstore passing my unit tests [00:30] creationix: I think it's about ready for an initial version [00:30] SteveDekorte: Tim_Smart: no, I find it to be a stack [00:30] SteveDekorte: just an ugly stack [00:30] mikeal: sweet [00:31] mikeal: does the createDB call take a callback yet? [00:31] creationix: unit tests found lots of bugs [00:31] creationix: it was fun [00:31] SteveDekorte: either way you have a stack - one way is just messier [00:31] SteveDekorte: and either way you have callbacks [00:31] richcollins has joined the channel [00:31] Tim_Smart: In terms of error reporting, yes it can be annoying. Other than that, I'm cool with it - I like callbacks. [00:31] SteveDekorte: coroutines use callbacks underneath [00:31] SteveDekorte: coros *are* callbacks [00:31] Tim_Smart: coroutines - ew. [00:31] Tim_Smart: I prefer the event model. [00:31] SteveDekorte: Tim_Smart: is that your idea of an argument? :) [00:32] bmizerany: how do I compile my binding so that the v8 profiler will include it in the report? [00:32] Tim_Smart: Yeah. As long as it is abstracted - I'm fine with it. [00:33] mikeal: i have mixed feelings on coro [00:33] mikeal: they're great in erlang and even in Python [00:33] SteveDekorte: few people who have an opinion on them even know what they are [00:33] mikeal: but i've never seen a js implementation that I couldn't use well without actually understanding the entire implementation which isn't very useful [00:34] jashkenas: SteveDekorte: every time I talk to you about them, and then to ry, I get the feeling that you're talking about two completely different implementations / underpinnings. [00:34] SteveDekorte: jashkenas: we are [00:34] SteveDekorte: jashkenas: I talked to him about how he used coros and I showed him that he was using them wrong and he agreed that the way I used them solved the problems he had with them [00:35] SteveDekorte: I guess I should put together a diagram that explains how they work [00:35] jashkenas: SteveDekorte: here's the complete conversation from yesterday afternoon: [00:35] jashkenas: http://gist.github.com/456608 [00:35] SteveDekorte: it took me a while to wrap my head around them at first as well - just like any new concept [00:36] SteveDekorte: jashkenas: this was an in-person conversation I had with him a few weeks ago [00:36] jashkenas: I remember -- you said. [00:36] ryah: coroutines = multiple executions stacks, context switches - it is not the same [00:37] ryah: but most importantly the programming model is much different [00:37] SteveDekorte: ryah: I don't agree - the same thing happens either way - the only question is how tersely it is expressed [00:37] mikeal: i think i figured out why i don't like them in javascript [00:37] WALoeIII has joined the channel [00:38] mikeal: in erlang, you're totally isolated from side effects by the language/vm [00:38] _announcer: Twitter: "moved nodejs sample. Looking at the future API" [ja] -- Tsukasa Hoki. http://twitter.com/mongorian_chop/status/17292073486 [00:38] SteveDekorte: ryah: either way can have unexpected state changes [00:38] mikeal: in javascript what you use to isolate side effects is knowing that while you block on processing nothing else can happen and that is guaranteed (so long as you don't have threads like a crazy person) [00:38] SteveDekorte: ryah: I would argue that callbacks are actually far more prone to hard to understand state changes [00:39] mikeal: coro abstractions make it harder for me to reason about when i block on processing and when something is in a callback [00:39] ryah: you can't have state changes in node callbacks - because node forces nothing to happen during any function call [00:39] ryah: you can have state changes between events [00:39] mikeal: right, you have to look at the model with the EventEmitter and callbacks being seperate [00:39] isaacs: Tim_Smart: so, the difference is that evalcx does a new context for each call. [00:39] ryah: all the i/o is done "at the bottom of the stack" [00:39] isaacs: Tim_Smart: even if you pass the same object in again later, it's actually always a new context. [00:40] isaacs: Tim_Smart: with createContext, you create a context object which can be reused multiple times. [00:40] SteveDekorte: ryah: that's nonsense - all the node.js code I've written has state changes in callbacks [00:40] SteveDekorte: that's the only way you can do anything in node.js [00:40] mikeal: by callback do you mean event handler? [00:40] Tim_Smart: isaacs: Ah. Cool. I might have a play with it later. [00:40] ryah: SteveDekorte: that said, when talking to you i became convinced that if you *only* do blocking code, you might also have no problem [00:40] mikeal: because they are seperate [00:40] ryah: SteveDekorte: or at least i became convinced that it's a possibily that there is no problem [00:41] SteveDekorte: ryah: it's not blocking code :) [00:41] ryah: "blocking" [00:41] SteveDekorte: all i/o ops are still async :) [00:41] ryah: yes, i understand how it works [00:41] mikeal: hahaha [00:41] Tim_Smart: But you write async in sync style - isn't that a confusion of interests? [00:42] _announcer: Twitter: "OH @ryah "yes, i understand how it [node.js] works"" -- Mikeal. http://twitter.com/mikeal/status/17292321372 [00:42] ryah: mikeal: it = i/o coroutines [00:42] SteveDekorte: Tim_Smart: you write machine code in a high level language - isn't that a conflict? [00:42] ryah: er Io ? [00:42] ryah: how do you spell it? [00:42] jashkenas: Io [00:42] mikeal: we can't even figure out how to spell it, we probably shouldn't use it [00:43] SteveDekorte: mikeal: or figure out the difference between capitalization and spelling [00:43] mostlygeek has joined the channel [00:44] SteveDekorte: anyways, I've made my case - take it for whatever it is or isn't worth to you [00:44] mikeal: the thing about this argument is [00:44] _announcer: Twitter: "#nodejs #bdd framework - well documented. http://tumblr.com/xgxcd2szz" -- Jack Russell SC. http://twitter.com/jackhq/status/17292464086 [00:44] mikeal: that you can build your API on top of node and then push a new distro [00:45] mikeal: the model for putting out stuff like this, or package managers, or whatever, is to create a distro not to get it in to core [00:45] ryah: i'm enamored with the idea of using callbacks - i think there are real problems with node's programming model - but the this example with the two servers in node and Io, and the Io one being much shorter [00:45] mikeal: so you don't need to convince ry or anything [00:45] ryah: that's not the problem [00:45] ryah: the problem with programming in node is losing your execution stack all the time [00:45] jashkenas: mikeal: if you want to see an Io equivalent of a simple Node server, take a look at this example: http://www.iolanguage.com/scm/io/docs/IoGuide.html#Primitives-Networking [00:46] jashkenas: ryah: amen to that. [00:46] ryah: i'm pretty convinced that programming with callbacks is easier than with "blocking" (quoted or otherwise) i/o [00:46] aho has joined the channel [00:47] SteveDekorte: ryah: and? [00:47] mikeal: is there a way to trap my local scope and send it attached to an error object? [00:47] ryah: you keep your stack with coroutines, but you are forced to program in a model that doesn't accurately describe what's happening [00:47] SteveDekorte: ryah: is that an argument? [00:47] bmizerany: Tim_Smart: I don't think either trumps the other in terms of less confusion. I have as hard of a time explaining how to handle async I/O in IO, Node, and Go. Where Node uses callbacks with a "take this data weather you're ready or not" and IO and Go use coroutines with Actors in IO and Channels in Go for interprocess communication. [00:47] ryah: while(true) { var n = read(socket); /* ... */ } [00:47] ryah: ^-- suppose this is a coroutine [00:47] ryah: everytime you come out that read, you need to check your state [00:47] ryah: has the socket be closed? [00:48] ryah: did someone else already send me a message? [00:48] isaacs: wait wait wait wait, why is this discussion happening? aren't we all in this room because we've decided that event loop > coroutines or threads? [00:48] SteveDekorte: ryah: I had to do that in node [00:48] SteveDekorte: ryah: http://www.iolanguage.com/paste/p/f05588fa6.html [00:48] Tim_Smart: bmizerany: I think callbacks are sightly easier to explain, but really it is all relative to previous experience. [00:48] ryah: brb [00:48] isaacs: ryah: also, that'd be: while (n = read(socket)) { ... } [00:48] SteveDekorte: if(this.target.isConnected) [00:49] Tim_Smart: SteveDekorte: Compare to this one: http://gist.github.com/456595 [00:49] bmizerany: ryah: with all due respect, I have to check a stream's readyState before a write, or am I doing it wrong? [00:49] bmizerany: even if I don't start writing until 'connected' [00:49] SteveDekorte: it was also very difficult to keep track of the contexts that expressions were evaled in - I kept confusing source and target [00:49] bmizerany: the other end can close the connection while I'm in a loop writing to the stream. [00:49] isaacs: bmizerany: in this case, you have two streams that you'er connecting, though [00:49] SteveDekorte: Tim_Smart: yes, I can write a pump function in Io too - that's not helpful [00:49] mikeal: that's because the thing you're passing can change state [00:50] isaacs: bmizerany: in ryan's thing above, it's a while loop, and you still have to check the state [00:50] mikeal: it's not the state of the subject of your callback [00:50] SteveDekorte: we can each write a single function that does the whole program and claim victory [00:50] isaacs: bmizerany: in other words, state changes *between* function calls (callbacks, event handlers, etc) but not *during* them [00:50] bmizerany: isaacs: for reading, I agree, callbacks seem easier. when writing, I have to check or I get an exception [00:50] mikeal: you don't have to check that source is still connected [00:50] Tim_Smart: SteveDekorte: http://github.com/ry/node/blob/master/lib/sys.js#L286-302 [00:51] SteveDekorte: Tim_Smart: yes? [00:51] isaacs: bmizerany: if i'm listening to "connect" on A, then I know that A is connected. If i'm then writing that to B, then yes, I need to check that B is connected, still, since i'm in the event handler for thing A [00:51] Tim_Smart: SteveDekorte: In case you were interested about the implementation of a pump [00:51] isaacs: bmizerany: that's more a "many moving parts" problem than a "reading vs writing" problem. [00:51] mikeal: SteveDekorte: your entire example could basically be [00:51] SteveDekorte: Tim_Smart: no, I said either system could have such a function [00:51] SteveDekorte: but it's only useful for this particular example [00:52] isaacs: bmizerany: i've got a bunch of code that writes to http streams, and you definitely can trust that the connection is connected in the "connect" event. [00:52] mikeal: addListener("connect", function (rstream) {pump(rstream, new net.Stream())} [00:52] bmizerany: isaacs: touche [00:52] mikeal: more or less [00:52] SteveDekorte: try implementing SMTP or some statefull protocol [00:52] hdon has joined the channel [00:52] jspiros has joined the channel [00:53] isaacs: it's software, right? i mean, of course, you CAN do either type of thing with callbacks or coroutines. the question is "which one is more of a pita, more likely to have bugs, harder to reason about, etc" [00:53] creationix: I think the real strength of node is that it's the same language and model as the browser [00:53] bmizerany: SteveDekorte: I have done just that: http://github.com/bmizerany/borg/blob/master/server.js [00:53] creationix: for web apps that's a huge win [00:53] ryah: SteveDekorte, bmizerany: yeah maybe that's not a good argument :) [00:53] isaacs: we don't have to agree on that, either. there will likely be coroutine proponents for a long time. personally, i prefer callbacks, and it's a huge win that node exists. [00:53] mikeal: yeah [00:53] jashkenas: Node.js: "It's just software, dammit." [00:53] bmizerany: SteveDekorte: parsing a stateful proto was rather easy with the node model [00:53] SteveDekorte: e.g. I could have written the Io example like this: http://www.iolanguage.com/paste/p/b45a2588e.html [00:54] mikeal: if callbacks are so hard how come a bunch of liberal arts majors write all this working jQuery? [00:54] isaacs: hahahaa [00:54] isaacs: HAHAHAH [00:54] kodisha has joined the channel [00:54] mikeal: i think the real problem is that callbacks are too simple for people with computer science degrees [00:54] isaacs: damn, mikeal, two in one day. yo'ure on fire. [00:54] _announcer: Twitter: "OH @mikeal: if callbacks are so hard how come a bunch of liberal arts majors write all this working jQuery? #nodejs" -- Ⓘⓢⓐⓐⓒ. http://twitter.com/izs/status/17293077071 [00:55] bmizerany: SteveDekorte: right. Go does very much the same. That example would look nearly identical. (I know IO has been around longer than go) :) [00:55] lucas-: somebody should do a portal-style video explaining callbacks - "Now you're thinking with callbacks!" [00:55] SteveDekorte: bmizerany: I didn't post that originally because it has nothing to do with the point of the post [00:55] ryah: i guess what i mean is, if you get a 'data' even, you know your socket isn't closed [00:55] SteveDekorte: the point is to compare code that actually involves callbacks vs sync reads [00:56] BlesYAHU: where should one extract fab so you won't get require errors, when requiring node modules? [00:56] ryah: *event [00:56] bmizerany: SteveDekorte: heh. understood. I jumped in late and on the argument of which is simpler, callback vs. coroutines, of which I'm indifferent on the matter. [00:57] ryah: i think someone could do a coroutine thing in V8 - and it'd be fast and probably quite usable [00:57] ryah: but it wouldn't seem very javascript-y [00:57] SteveDekorte: I'd be willing to bet that any complex protocol could be implemented in 2-10x less code with coros vs callbacks [00:57] creationix: ryah: but if you go that route, why use javascript? [00:58] SteveDekorte: and would be more understandable, maintainable, extendable and just as scalable [00:58] SteveDekorte: ryah: like coffee script isn't javascripty? [00:58] ryah: i disagree, but it's pointless in arguing it until it's actually been done [00:58] _announcer: Twitter: "Clojure-en ML Na and node.js of increasing amounts of email to register. It is evidence of active" [ja] -- Nakamura Masato. http://twitter.com/Masahito/status/17293321323 [00:59] isaacs: SteveDekorte: go do it. [00:59] bmizerany: SteveDekorte: yeah. I wish I still have the code I wrote in Go, Erlang, Node, and Ruby/EM when I benching which was more efficient at the simple act of proxying to/from redis. It was a great comparison of speed and languages/style/syntax to accomplish the same thing. [00:59] jashkenas: SteveDekorte: perhaps that stateful SMTP server would be a persuasive example. [00:59] SteveDekorte: isaacs: working on it :) [00:59] ryah: what if web browsers had coroutines [00:59] jashkenas: bmizerany: you threw it away? [00:59] ryah: while(true) { var x = button.isClicked(); if (clicked) { } ) [00:59] creationix: ryah: then node would probably have coros [00:59] mjr_: man, still with the callbacks vs. coroutines [01:00] mikeal: i just don't see coro working that well if you don't have something else that isolates you from side effects [01:00] bmizerany: I remember Erlang took the most amount of code, *with* OTP and Ruby/EM was 3 lines of code and they both were neck and neck for top speed. [01:00] isaacs: the thing is, coros suck a lot when you have LOTS of things with events. [01:00] bmizerany: Go was only a tad behind with Node. [01:00] Tim_Smart: SteveDekorte: Make sure you get the Node.js version reviewed. [01:00] Tim_Smart: :) [01:00] isaacs: in that case, objects with event handler callbacks are much better. [01:00] SteveDekorte: ryah: then you'd be advocating coros because they feel more natural :) [01:00] ryah: while(true) { var x = document.scrolled(); if (x > 0) { } ) [01:00] mikeal: but that erlang code won't ever fail and has zero bugs, it's always more work to do *anything* in erlang if you don't think about the time it takes to track down and fix bugs related to side effects [01:01] isaacs: mikeal: most of my bugs are not due to side effects. [01:01] SteveDekorte: ryah: just like people tend to assume the religion of their parents as the one true religion [01:01] isaacs: ACTION makes his bugs top priority, front and center [01:01] mikeal: hehe [01:01] isaacs: no, seriously, though [01:01] ryah: are there any GUIs that use coroutines? [01:01] isaacs: how many of your bugs are actually due to side effects, and not due to "I didn't think this all the way through right" [01:02] mikeal: you can't really do that in erlang [01:02] isaacs: personally, most of my bugs are my own damn fault, because i didn't think right. [01:02] mikeal: i mean, i'll fail way way sooner if you didn't think of something [01:02] ryah: i just find it silly to start a coroutine for each widget and loop on every possible thing it can do [01:02] visnup has joined the channel [01:02] bmizerany: jashkenas: oh. I found my Go one. https://gist.github.com/036e32d7e413f8ed6b23 it's actually simpler in Go these day. basically the slurp method is in a Go lib somewhere now. [01:02] Wandrewvious has joined the channel [01:02] isaacs: mikeal: but i mean, like "i thought i knew how this was supposed to work, but it should really work another way" [01:02] jashkenas: bmizerany: thanks. [01:02] ryah: and the only reason people advocate "threads" for servers is that they only imagine it with 1 socket [01:02] SteveDekorte: ryah: why would you do that? [01:02] isaacs: any bugs other than that are pretty easy to deal with [01:02] mikeal: right [01:03] mikeal: but how many time is that "oh yeah, i need to handle *this* case too" [01:03] SteveDekorte: ryah: is there some rule that if you use coros you have to have one for each object? [01:03] mikeal: in erlang you have to handle that up front or else it'll just fail outright really early [01:03] isaacs: mikeal: well, looking at npm, i mean, it's MOSTLY really super easy stuff. [01:03] SteveDekorte: ryah: you could take that perspective on function calls in general [01:03] ryah: i guess you can do while (true) { var event = document.getEvent(); switch (event) { ... } } [01:03] SteveDekorte: node *does* do a lot of sync calls [01:03] isaacs: mikeal: it's just a puzzle of constantly trying to figure out how people expect it to work, or what's the simplest way to make it work, etc. [01:03] SteveDekorte: most every function call in node is sync [01:03] mikeal: yup [01:04] SteveDekorte: a very tiny number of calls have callbacks [01:04] isaacs: SteveDekorte: everything except IO is synchronous in node. [01:04] mikeal: erlang isn't actually that fast [01:04] SteveDekorte: so node is almost entirely synchronous [01:04] mikeal: i mean, it's faster than all this crap that people use [01:04] isaacs: mikeal: exactly [01:04] SteveDekorte: it does very little asyn [01:04] SteveDekorte: c [01:04] BlesYAHU: where should one extract fab so you won't get require errors, when requiring node modules? [01:04] ryah: SteveDekorte: hm.. ok? [01:04] mikeal: but it's not particularly fast, it sacrifices a lot of performance for reliability [01:04] SteveDekorte: why not have node go fully async? [01:04] isaacs: mikeal: so, if i'd written npm in erlang, i'd still be only halfway done with the first version that does everything wrong. [01:04] mikeal: correct [01:04] isaacs: SteveDekorte: because that'd be dumb. [01:04] mikeal: :) [01:04] SteveDekorte: why not make every function call have a callback and have no functions that return? [01:04] ryah: SteveDekorte: i'm not sure what you mean [01:05] mikeal: only write something you *know* you *must* finish in erlang [01:05] SteveDekorte: isaacs: exactly my point [01:05] isaacs: mikeal: right. and write it in some other language first. [01:05] mikeal: because you can have something working enough in anything else [01:05] isaacs: SteveDekorte: i mean, that'd be a lot of extra overhead for no benefit. [01:05] isaacs: SteveDekorte: function calls are very fast. IO is very slow. [01:05] Tim_Smart: Why the heck would I want async computation? [01:05] SteveDekorte: isaacs: interesting, how do you determine when sync is beneficial? [01:05] Tim_Smart: That is what OS level processes are for [01:06] isaacs: SteveDekorte: if it's fast, or if the time spent waiting doesn't matter. [01:06] mikeal: OS level processes aren't cheap [01:06] isaacs: SteveDekorte: or if it goes over a network, then it should pretty much always be async [01:06] ryah: SteveDekorte: if it takes over 1 million clock cycles, it's beneficial to amek it async [01:06] mikeal: and swapping between them isn't free either [01:06] ryah: cpu things => do in the cpu [01:07] SteveDekorte: isaacs: why is that important? [01:07] isaacs: SteveDekorte: but there is this gist of something I was exploring: http://gist.github.com/313229 [01:07] ryah: things to be executed in another country => don't wait [01:07] SteveDekorte: mikeal: swaping can be done millions of times a second [01:07] isaacs: SteveDekorte: it's important because it's really really long [01:07] SteveDekorte: mikeal: how much faster does it need to be? [01:07] mikeal: if you're swapping "hello world" [01:08] SteveDekorte: mikeal: what do you think is being swapped? [01:08] mikeal: i'm not saying never [01:08] jashkenas: isaacs: you'd probably be interested in this ticket ... it's an attempt at transforming the remainder of the function into the continuation-passing style, like your gist: http://github.com/jashkenas/coffee-script/issues#issue/350 [01:10] SteveDekorte: isaacs: yes, but why is it important that it's long? [01:10] isaacs: jashkenas: there was some thing i think kriszyp did (or maybe just ported?) that was javascript that has -> as a "defer to a callback" operator [01:10] isaacs: jashkenas: it was kinda neat. [01:11] isaacs: jashkenas: i forget what it's called, though [01:11] kriszyp: yeah, we've been discussing that on the ecmascript discuss list, if thats what you mean [01:11] isaacs: kriszyp: hey, ther eyou are [01:11] _announcer: Twitter: "Vows - Asynchronous BDD Framework for Node.js http://ff.im/mQUqf" -- antest. http://twitter.com/antest/status/17294132940 [01:11] kriszyp: thought about making an impl of it for node, haven't gotten around to yet though [01:12] jashkenas: kriszyp: link? [01:12] isaacs: kriszyp: what was that to-js language called? foo (bar, baz) -> doSomething(foo, baz) [01:12] kriszyp: narrative javascript [01:12] isaacs: narrative, that was it [01:12] drobati has joined the channel [01:12] isaacs: SteveDekorte: anything super slow should be async, because tying up the process doing nothing is dumb. [01:12] kriszyp: is the original transformer that the idea for es was kind of based off of [01:13] Tim_Smart: SteveDekorte: Computation functions that use the CPU, dpm [01:13] kriszyp: jashkenas: as far as a link to the discussion, you could look for single-frame continuations in the es-discuss list [01:13] Tim_Smart: *don't waste the CPU. Network that waits however do [01:13] SteveDekorte: isaacs: but it *is* async with coros [01:13] isaacs: SteveDekorte: i'm not sure what your point is here... [01:13] SteveDekorte: the coro is removed from the scheduler until the event callback occurs [01:13] isaacs: SteveDekorte: that coros are better? [01:13] Tim_Smart: SteveDekorte: I thought you were asking why we don't have callbacks for everything [01:14] SteveDekorte: Tim_Smart: I am [01:14] creationix: mikeal: how do you do many-to-many relationships in document databases? [01:14] isaacs: SteveDekorte: but you got the answer. because that'd be silly. [01:14] mikeal: you don't do them the same way [01:14] SteveDekorte: isaacs: it sounds like you are admitting that they complicate the code [01:14] jashkenas: creationix: each side can maintain a list of the associated ids on the other side. [01:15] isaacs: SteveDekorte: they make it clear when something is async and when it is not. [01:15] mikeal: usually, you use a map phase to generate a secondardy index [01:15] hmm has joined the channel [01:15] SteveDekorte: isaacs: but that that is a necessary evil for long calls [01:15] isaacs: SteveDekorte: i want to know what my code is doing. [01:15] isaacs: SteveDekorte: i want to know when state might chnage, and when it cannot. [01:15] isaacs: SteveDekorte: with callbacks, all this is clear and obvious. [01:15] SteveDekorte: isaacs: and I'm telling you it is an evil, but not a necessary one [01:15] isaacs: SteveDekorte: i disagree. [01:15] Tim_Smart: SteveDekorte: No, the point is, is that async isn't necessary for everything. [01:15] creationix: mikeal: ok, so in one of the documents store a list of keys to another collection? [01:15] SteveDekorte: isaacs: I don't see how callbacks save you in any way [01:15] isaacs: SteveDekorte: i don't think callbacks are a necessary evil. i think callbacks are a GOOD way to clearly express when an async operation is happening, vs a sync operations. [01:16] mikeal: creationix: if you do it that way it's kind of like enforcing schema [01:16] mikeal: in couchdb you do something like [01:16] isaacs: SteveDekorte: the fact that it's going to a callback means that state might have changed in the interim. [01:16] SteveDekorte: a callback can modify an object that another callback is also messing with [01:16] isaacs: SteveDekorte: exactly. [01:16] isaacs: SteveDekorte: so you know "ok, i'm starting a new function, gotta check the state." [01:16] bradleymeck has joined the channel [01:16] isaacs: SteveDekorte: instead of having to do that on every line, or after every function call, you *only* have to do that for event handlers or callbacks. [01:16] ncb000gt has joined the channel [01:17] SteveDekorte: isaacs: if that is your concern then just name your functions accordingly [01:17] isaacs: SteveDekorte: they *look* different, which is a good thing, becasue they *are* different. [01:17] SteveDekorte: then they will *look* different [01:17] admc_ has joined the channel [01:17] mikeal: function (doc) { if (doc.type == 'some') { emit([doc.commonKey, doc.type] , 1) } else if (doc.type == 'other') { emit(doc.otherKey, doc.type], 1) } [01:17] SteveDekorte: socket ASYN_read() - if you prefer [01:17] isaacs: SteveDekorte: that's not as good. [01:18] mikeal: the emitted key, value are stored in a secondary sorted btree with the document id they came from as secondary metadata [01:18] isaacs: SteveDekorte: it helps that i've been programming in single-threaded javascript with non-blocking stuff being fired off with callbacks for a *long* time now. [01:18] SteveDekorte: isaacs: I've written a fair amount of coro based server code and haven't experienced the problem you are describing [01:18] mikeal: creationix: is there a reason you have to do this right away [01:18] isaacs: SteveDekorte: like, since the 90s [01:18] SteveDekorte: isaacs: have you written much coro server code? [01:18] isaacs: SteveDekorte: nope. callbacks, man. callbacks are nice. [01:19] mikeal: creationix: the quick and dirty way to do this, is to stick the index you care about in the document meta so that it's in memory and then just iterate over the whole db when you do a query [01:19] isaacs: SteveDekorte: like i said before, we don't have to agree. [01:19] creationix: mikeal: I'm integrating my new library with a demo app for connect [01:19] SteveDekorte: isaacs: I see, so your perceived problems are hypothetical? [01:19] isaacs: SteveDekorte: there can be a lot of different platforms doing things different. [01:19] creationix: but it's designed for relational tables [01:19] isaacs: SteveDekorte: as are yours. [01:19] mikeal: so [01:19] SteveDekorte: isaacs: I've done both [01:20] mikeal: most of the relational data you should be able to jam in to the documents, anything that is indexed you should just do another query on to resolve and make sure the info you need to query on is in the meta [01:20] mikeal: that's the quickest way to do it [01:20] Tim_Smart: SteveDekorte: If you node.js was a guide of anything, I would assume your not as confident with the node api [01:20] mikeal: and it'll be fast even iterating over the whole thing [01:20] Tim_Smart: *node.js paste [01:20] mikeal: if it's not fast enough you're gonna need a btree [01:20] isaacs: SteveDekorte: but you don't seem to think that the callback syntax is a downside. [01:21] isaacs: SteveDekorte: er, you DO, that is [01:21] bradleymeck: mmm the node v2 spec on groups is a bit odd [01:21] creationix: mikeal: for the demo I'm talking tables < 100 rows [01:21] SteveDekorte: isaacs: I don't recall saying anything about syntax [01:21] mikeal: oh yeah, just jam the indexes you want in meta and iterate over it :) [01:21] isaacs: SteveDekorte: you called callbacks a necessary evil.. [01:21] isaacs: SteveDekorte: maybe i misunderstood what you were getting at? [01:21] SteveDekorte: yes [01:21] isaacs: SteveDekorte: what's so evil about them? [01:21] mikeal: creationix: and don't write a query syntax [01:21] isaacs: SteveDekorte: that's where we disagree. i think they're a necessary *good* [01:22] SteveDekorte: isaacs: syntax and semantics are different things [01:22] mikeal: just expose a forEach [01:22] SteveDekorte: isaacs: my problem is with the semantics [01:22] mikeal: that only take the meta for every document [01:22] isaacs: SteveDekorte: but... the "semantics" are the same either way...? [01:22] isaacs: SteveDekorte: i mean, in both cases, you're saying "do this thing, and then when you'er done, do this other thing" [01:22] isaacs: SteveDekorte: with callbacks, imo, that semantic data is more clearly expressed. [01:22] isaacs: (than with coroutines) [01:22] mikeal: this argument just will not die will it [01:22] creationix: mikeal: ok, so allow people to loop over the index [01:23] Tim_Smart: mikeal: It will, eventually. [01:23] SteveDekorte: isaacs: if by clearly you mean understandably, I don't agree [01:23] mikeal: just allow yourself to iterate over the meta [01:23] mikeal: and do the demo :) [01:23] isaacs: SteveDekorte: again, i understand it just fine, and so do plenty of other people. [01:23] isaacs: SteveDekorte: so yeah, it's "understandable" [01:23] mikeal: and write something that can add info to meta [01:23] mikeal: creationix: it's surprising how much you can do with just these raw functions and no specific query system or ordered indexing [01:23] isaacs: SteveDekorte: i think that "doSomething(function () { then Do something else})" is more clearly async than "doSomething(); thenDoSomethingElse()" [01:23] SteveDekorte: isaacs: yes, this is like arguing about whether objects are more understandable or not [01:24] jashkenas: fuel for the fire: an old wikiwikiweb article on the topic: http://www.c2.com/cgi-bin/wiki?ContinuationsAndCoroutines [01:24] SteveDekorte: isaacs: then why not use it for *all* function calls? [01:24] mikeal: i'm all closures > objects [01:24] creationix: mikeal: the demo is basic crud with about 5 tables, and a few many-to-one relations with a single many-to-many relation. Also I need a real-time aspect where I'm notified of changes to any relevent data (within a specified scope) [01:24] isaacs: SteveDekorte: so, if it's a preference, then can't we just accept that people have different preferences, and decide to stop caring about each other? [01:24] isaacs: SteveDekorte: no. it's not for ALL function calls because not ALL function calls are async. [01:24] mikeal: creationix: like the _changes feed in CouchDB :) [01:24] isaacs: SteveDekorte: that's my point. [01:24] isaacs: SteveDekorte: if you made all function calls async, then you're adding a lot of overhead and bs for no gain. [01:25] mikeal: creationix: you've already got the end point for an onChange listener for the whole db [01:25] ryah: here is the question: do you do gzip inline or not? [01:25] SteveDekorte: isaacs: suppose your compile removed all overhead [01:25] ryah: i think you do it inline. [01:25] ryah: s/inline/sync/ [01:25] SteveDekorte: isaacs: then you'd get to express everything that way with no overhead [01:25] creationix: ryah: I would do it sync if I had a good c lib for it [01:26] isaacs: SteveDekorte: there's still the conceptual overhead of not knowing clearly which things are async and which things aren't. [01:26] _announcer: Twitter: "what is node.js?" -- Denny Abraham. http://twitter.com/dennyabraham/status/17295028596 [01:26] ryah: creationix: bindings are on the way [01:26] isaacs: SteveDekorte: i'm not talking about machine overhead. i'm talking about brain overhead. [01:26] ryah: creationix: we're already linking to libz - so it shouldn't be much problem [01:26] creationix: ryah: nice [01:26] isaacs: "wait, is that function async or not? has state changed between these two adjascent lines of code, or hasn't it?" [01:27] derferman has joined the channel [01:27] creationix: mikeal: thanks for all the help, btw, sorry if I bug you too much [01:27] ryah: one process, one execution stack, do i/o at the bottom. it's a good model. [01:27] mikeal: no it's good [01:27] SteveDekorte: isaacs: ok, now we are making progress [01:27] ryah: needs dtrace [01:27] mikeal: i'm working through a lot of this kind of stuff right now in IDBCouch anyway [01:27] SteveDekorte: isaacs: so you just want a visual indicator of the difference [01:27] isaacs: SteveDekorte: towards what? [01:27] isaacs: SteveDekorte: actually, i want javascript. [01:28] isaacs: SteveDekorte: and nodejs is javascript. [01:28] SteveDekorte: isaacs: ok, I can't argue with a religion [01:28] mikeal: ryah is a closet Haskell fan :) [01:28] creationix: mikeal: in couch, are you map-reduce functions written in erlang or js? [01:28] _announcer: Twitter: "if there could be a cambrian explosion in erlang web dev, like there is around node.js, everything would be awesome in my sphere ..." -- grantmichaels. http://twitter.com/grantmichaels/status/17295156829 [01:28] isaacs: it's a good model. it works well. it's easy to understand. it's the language and model that's implemented in every web browser. [01:28] mikeal: ACTION just outed someone [01:28] mikeal: creationix: javascript, nobody can write erlang :) [01:28] ryah: mikeal: sh [01:28] isaacs: SteveDekorte: my religion is using what works in the way that it works best. [01:28] mikeal: heheh [01:28] creationix: ACTION is a closet oCaml fan, yet he still gets along with ryah  [01:29] isaacs: SteveDekorte: context switches are hard on the brain. i'm getting too old to change languages over and over again. [01:29] mikeal: i always assumed i'd have to change languages every 5 years [01:30] SteveDekorte: isaacs: I had a C++ friend who said ObjC syntax was too difficult from him to understand - strangely, he had no problem with C++ templates (which are turing complete!) [01:30] mikeal: never thought i'd switch to javascript 5 years ago :) [01:30] isaacs: mikeal: every 5 years, i can manage. but every day/minute, that's too tricky [01:30] mikeal: right [01:30] SteveDekorte: isaacs: but yes, I think you are now getting at the real motivations behind your position [01:30] isaacs: SteveDekorte: i don't htink i've ever been even slightly less real about my motivations. [01:31] isaacs: or my position. [01:31] isaacs: SteveDekorte: i'm probably one of the most pro-js folks in the nodejs group, which is pretty extremely pro-js. [01:31] mikeal: the browser is a fact of life and this other model everyone has in their head isn't something we'll all be forced to use anyway regardless of what we get on the server [01:31] isaacs: not because javascript is so great, but because it's the language we've got. [01:31] isaacs: it's the web's language. [01:31] isaacs: i'm also pro-english, for largely the same reasons. they're both ugly languages, but they're working, so we're best off using them as effectively and widely as possible. [01:32] mikeal: and a lot of people just spent a whole lot of time making it absurdly fast [01:32] SteveDekorte: isaacs: I see, so the argument has moved from "model X is better", to "use model X because it's popular" [01:32] mikeal: isaacs: racist [01:32] mikeal: :P [01:32] isaacs: SteveDekorte: no, it hasn't. i also think coroutines are stupid. [01:32] mikeal: hahahahaa [01:32] Tim_Smart: haha, now we are getting dirty [01:33] isaacs: SteveDekorte: if your way of signaling asyncness is by using a naming convention, something is Deeply Wrong. [01:33] creationix: SteveDekorte: I think that's a valid argument, popular does matter [01:33] isaacs: foo(); bar(); [01:33] SteveDekorte: creationix: not to whether it is terser or easier to understand, more flexible, more maintainable, etc [01:33] isaacs: the state should not be able to change between those two statements [01:33] bradleymeck: uggg obj c [01:33] isaacs: it could change on the foo() line, or on the bar() line, but if it changes between, then the world is broken. [01:34] isaacs: callbacks are *simple*. [01:34] isaacs: and they're *fast*. and it's clear what's going on. [01:34] SteveDekorte: but I think I've said enough - I'll post my code when it's ready [01:34] Tim_Smart: Yeah. Let the examples and real world case do the talking. [01:34] creationix: SteveDekorte: yes, javascript and it's semantics aren't ideal for everyone, but it's good enough and actually quite amazing once you learn it properly [01:34] Tim_Smart: *cases [01:34] creationix: so the fact that something good enough is also popular and widely deployed does matter [01:35] isaacs: creationix: +1 [01:35] creationix: I think silverlight is technically worlds better than flash [01:35] bradleymeck: c/c++: headers + code, obj c: headers + impl + code + c++ wrapper [01:35] SteveDekorte: it's not important if it's used in node.js - the point is to show it can be useful for js server toolkits of which, I'm sure there will be many [01:35] creationix: but I'm not about to use silverlight any time soon [01:35] creationix: (thanks to html5 I don't need much flash either) [01:35] isaacs: creationix: in a similar analogy, rotten tomatoes are WAY tastier than rotten fish... [01:36] isaacs: i kid, i kid... silverlight is actually quite nice. [01:37] creationix: it is, silverlight (from what I've seen) made a lot of good decisions in the architecture, but the fact that is doesn't run most places and the tools are not freely available makes it a non-starter for me [01:37] isaacs: yeah, exactly [01:37] creationix: js is everywhere [01:37] isaacs: SteveDekorte: you really should check out narrative. [01:37] creationix: I think ryah made a good decision to follow the browser model exactely, even if it's not the absolute ideal model [01:37] isaacs: creationix: i agree. [01:38] isaacs: the thing about evolution is that sometimes it does things that don't look ideal, but are a lot better than the things that do look ideal. [01:38] jashkenas: isaacs: quote from the Narrative author: [01:38] jashkenas: "http://www.neilmix.com/narrativejs/doc/: My first open-source project, this was an attempt to build pseudo-concurrency into JavaScript through source code transformation. It works well, but never really caught on and became popular. My thinking about such things has since evolved, and I no longer think narrativejs is the best way to approach the problems I was trying to solve. As a result, I’m no longer actively developing the project." [01:39] SteveDekorte: "This library is the result of years of personal experience coding and debugging mind-warping, impossibly complicated callback-based "AJAX" applications. It is the author's hope that this library may reduce this pain for others." [01:39] jashkenas: ;) [01:39] creationix: and it's not like node never tried the coro thing either [01:39] SteveDekorte: guess he should have studied liberal arts ;) [01:39] isaacs: SteveDekorte: or kept his "AJAX" applications merely "possibly" complicated. [01:39] isaacs: rather than impossibly [01:39] SteveDekorte: or topological algebras like ryah ;) [01:40] isaacs: ok, i gotta run [01:40] creationix: well, I've got to go eat supper, have fun everyone [01:40] SteveDekorte: cya [01:40] isaacs: this has been a very stimulating evening. looking forward to your continuation thing SteveDekorte [01:40] isaacs: aww, he left. [01:41] creationix: mikeal: enjoy the quite irc room now, I'll be back on later [01:41] softdrink has joined the channel [01:42] creationix has joined the channel [01:43] Tim_Smart: mikeal: Are you helping with http://github.com/creationix/nstore ? [01:43] mikeal: Tim_Smart: yes [01:45] mde: Tim_Smart: Had a long talk with mikeal yesterday about the persistence stuff. I think I managed to convince him on having common API where applicable. [01:45] mde: Not having a lot of luck on the model thing though. :) [01:45] Tim_Smart: haha [01:46] mikeal: also [01:46] kriszyp: mde: are you interested in a common api for data stores? [01:46] mikeal: i'm not anit-model where models make sense [01:46] mikeal: i just don't think they are an optimal API for JSON stores [01:46] mde: kriszyp: Yes, where possible. There's the higher-level, DSL-style query API for end-user devs, and the middle layer for the people writing that higher layer. [01:47] mde: mikeal: Depending on what you're doing with the JSON, I actually agree. [01:47] Tim_Smart: mikeal: Definitely not optimal, most people that use models are aware of the performance trade-offs [01:47] kriszyp: cool, and have you looked at perstore at all? [01:47] mikeal: and I think models would be a terrible API for Redis [01:47] kriszyp: (based on the html5/w3c db api) [01:47] mikeal: you just don't want to use Redis like that [01:47] mde: mikeal: Yeah, I haven't looked closely enough at Redis, so I'll just have to trust you. [01:48] stevendavie has joined the channel [01:48] mikeal: Tim_Smart: i don't mean performance, i mean just a comfortable API that maps well to a particular storage solution [01:48] mde: kriszyp: I seemed to remember looking at perstore -- but I thought that spec was sort of a dead-end, wasn't it? [01:48] kriszyp: why? [01:48] kriszyp: its the web sql that is a dead end [01:48] kriszyp: the indexeddb api is the one that is alive and well [01:48] mde: Ohh ... I'm getting my specs confused, sorry. [01:48] mikeal: IDB is awesome :) [01:48] kriszyp: and what firefox and ms and others are actively working on [01:48] kriszyp: yeah, what mikeal said :) [01:48] Tim_Smart: mikeal: Ah right, also people that models don't seem to really care what happens underneath. They just want it to work. [01:49] paulwe: !j points [01:49] mde: I think it's a great idea to build on something that is a common standard and has a lot of activity. [01:49] mikeal: Chrome is planning on implmenting [01:49] mikeal: that's why jeremy orlow is so active on the list [01:49] kriszyp: the IDB store API is what perstore uses for a common data API [01:49] mde: Tim_Smart: +1 [01:49] kriszyp: right [01:49] mde: Devs don't want to write SQL, or mapreduce. [01:49] mikeal: kriszyp: how do you implement the transaction locking across all dbs? [01:49] mde: They want to store and object, and get it back out. [01:49] bmizerany: ryah: any notes on how to get my binding to compile so that is shows up in v8's profiler results? [01:50] mikeal: mde: IDB isn't sql or map/reduce [01:50] mde: The persistence stuff is going to be a very, very deep hole. [01:50] mikeal: it's much lower level than that [01:50] mde: mikeal: Right, there's two different levels. [01:50] mde: And both need to be well designed APIs. [01:50] kriszyp: well, I certainly don't try to push people to do transaction locking across all DBs :P, but I have defined a few optional functionals for 2PC if you feel it is really necessary [01:51] pedrobelo has joined the channel [01:51] ryah: bmizerany: with -g ? [01:51] kriszyp: in terms of persistence, with something like couch or mongo, there is very little (or anything) that needs to be done for the "mapping". perstore is more interested in helping out with validation, faceting (for ocap security), and store-level middleware (for adding functionality like caching, conflict resolution, etc) [01:52] bmizerany: ryah: -g? with node-waf? [01:52] kriszyp: relational dbs are where "mapping" takes effort [01:52] ryah: bmizerany: yeah, that should be default with 0.1.99 node-waf [01:52] mde: kriszyp: That's a big ball of functionality. :) [01:52] bmizerany: ryah: oh nice. cool. thx [01:52] ryah: bmizerany: not sure if that's the problem, but that's my first guess [01:53] mde: I want to figure out where the biggest amount of benefit can be gained for people who want something that works out of the box. [01:53] ryah: oh, i seem to remember some dll problems with the profiler... [01:53] bmizerany: ryah: node-waf: error: no such option: -g [01:53] kriszyp: yeah, but it fits together nicely, especially with the IDB API, it is kind of a like middleware, it is just a set of componetns that can be layered on top of each other [01:53] bmizerany: that's from 0.1.98 [01:53] mde: Not necessarily something that can scale massively, not right away. [01:53] ryah: bmizerany: er, i mean so that node-waf calls g++ with -g [01:53] ryah: bmizerany: do node-waf -v clean build [01:53] ryah: bmizerany: and output the results to me [01:54] kriszyp: right, mde, so one of the things that is really nice is to be able to start with a simple JSON/memory store to do prototyping, and later be able to move to seomthing more scalable, that's where the common API is really nice [01:54] mde: kriszyp: In-memory, and after that something that works with existing SQL stores. [01:54] kriszyp: right [01:54] webbot has joined the channel [01:54] mde: You want to get people hooked without having to install something exotic. [01:55] kriszyp: right [01:55] jashkenas: http://github.com/kriszyp/perstore/blob/master/lib/store/sql.js [01:55] mde: And I suspect that the long-term direction of all this stuff is for people to mix and match. [01:55] mde: So, something like per-model store defintions. [01:55] kriszyp: yeah, that's exactly what perstore does [01:56] bmizerany: ryah: after a `git clean -xdf && node-waf configure build` -> https://gist.github.com/db271cc9b8d2a2e828c7 [01:56] bmizerany: ryah: hrm. it's doing -g [01:57] bmizerany: ryah: here is the profiler report https://gist.github.com/00d6c957c87a846908a8 [01:57] kriszyp: anyway mde, if you are ever interested in helping out with perstore, be glad to work with you, we already have some adapters (for mongo, couch in the works), and json schema based validation, etc. Of course don't want to get in the way of whatever ideas you are wanting to do on your own... [01:57] mde: kriszyp: I'll definitely take a closer look. What I'm working on is very specifically targeted at guys who are used to your basic MVC frameworks in other languages. [01:57] mde: So whatever it is, on its face, it should look familiar to them. [01:57] mde: No matter how it's implemented under the hood. [01:58] kriszyp: ah, yeah, working with preexisting notions can definitely force you take a certain direction [01:58] mde: kriszyp: The model/validation stuff is pretty integrated and baked. [01:58] mde: But the persistence stuff below that is really just a stake in the ground. [01:58] kriszyp: perstore is definitely more of ground-up approach to models/persistence, not necessarily closely similiar to other stuff [01:58] mde: I'm not religious about anything excpept the idea that it should be easy for the average Rails guy to grok. [01:58] Tim_Smart: mde: I'm working on a ORM atm that shares models server and client side, and uses real-time communication to keep all clients in sync with server [01:59] mikeal: sorry i took off for a bit [01:59] mikeal: kriszyp: did you say how you're handling mapping the transactions? [01:59] mde: Tim_Smart: It all does sounnd remarkably similar, doesn't it. :) [01:59] kriszyp: and on the topic of sharing client and server, perstore is based on json schema, which already impls in numerous languages (not just the browser) [01:59] mde: Interesting, okay. [01:59] Tim_Smart: mde: Currently implement the non-persistence part of it. [01:59] kriszyp: so it is really easy to share validation [01:59] Tim_Smart: *implementing [02:00] mikeal: not a huge fan of schema [02:00] mde: Yes, the geddy-model stuff is already pretty well built out -- we're using it at Yammer client-side, and now with TheRubyRacer. [02:00] kriszyp: and Tim_Smart, if you are ever interested in collaborating as well, be cool to bring together some of this stuff... [02:00] mde: Yeah, we're all working on such similar stuff. :) [02:01] kriszyp: mikeal: of course, you work for couch :) (no offense) [02:01] Tim_Smart: kriszyp: mde: Yeah we should chat about where we are at, and our goals somewhere, sometime. [02:01] mikeal: hehe [02:01] mde: Seems like a silly duplication of effort. But it was pretty great to see our Rails devs sit down and start using the stuff right away. [02:01] mde: Because they already know the API. [02:01] mikeal: i work at couch because i was a big user of couch, which i started because i don't like schema :) [02:01] mikeal: it's the other way around [02:01] kriszyp: and it has been very smart to keep schemas out of storage [02:01] jashkenas: mde: you work at Yammer? did y'all ever get your document embedding figured out? (I was talking to Coda about it a bit) [02:01] mikeal: everything should go in the database [02:02] kriszyp: but that doesn't mean schemas are useful at higher layers [02:02] mikeal: for sure [02:02] mde: jashkenas: I don't interact with those guys that much yet, but I know they're trying to finish up the realtime stuff first. [02:02] jashkenas: mde: gotcha. [02:02] mikeal: i care a lot about taking the data offline for most apps [02:02] kriszyp: having to write code for every validation is a pain. schema = dsl for validation [02:02] mde: Right, and you can have validatable models without an overarching DB schema. [02:02] kriszyp: exactly, mde [02:03] mikeal: and it's really hard to handle schema changes when replicating offline changes [02:03] kriszyp: JSON schema is also about making JSON RESTful though [02:03] mikeal: it's an RFC? [02:03] kriszyp: right [02:04] mde: I'll have to take a closer look. The persistence part is really huge, and I'd love for Geddy users to be able to have something usable sooner rather than later. [02:04] mikeal: this is like properly formatted [02:04] mikeal: you should convert Modules/1.1.1 :) [02:04] kriszyp: you mean json schema is properly formatted? heh [02:04] mikeal: no, the spec [02:04] mikeal: http://tools.ietf.org/html/draft-zyp-json-schema-02 [02:04] kriszyp: yeah, that's what I meant [02:04] kriszyp: xml2rfc [02:05] kriszyp: ACTION wishes there was json2rfc :) [02:05] mikeal: json schema allows properties outside of the schema to be added without validation right? [02:05] kriszyp: yes [02:06] kriszyp: by default undefined properties are allowed [02:06] kriszyp: so the empty schema ({}) allows any value or object [02:06] kriszyp: you progressively constrain [02:06] mikeal: actually [02:06] mikeal: mde, for what you're doing, you should really use this [02:06] mikeal: then you can persist the model validation rules in to the database [02:07] mikeal: and the application code can be generative instead of static, it's a lot easier to deploy changes to the validation if it's in the db instead of the application code [02:07] mde: I'll take a look, yeah. But why would the model definition and validations not just live in code? [02:07] mde: Oh. [02:08] mikeal: the code would just read the JSON for the schema [02:08] mikeal: and do the validation [02:08] mikeal: so it's still code, it's just based on the schema [02:08] kriszyp: yeah, obviously it is easy to store a JSON schema in a DB, since it is written in JSON [02:08] mikeal: you would still write the schema initially basedon some kind of model API [02:08] malkomalko has joined the channel [02:08] mde: Yeah, I'll have to read it, but having worked with both ways of doing it, I much prefer having the SPOT for that be in code. [02:08] mikeal: but you wouldn't rely on it after it's initially generated [02:09] mikeal: mde: it is, it's just not code that runs on startup [02:09] mikeal: so, you have a bunch of generators [02:09] mikeal: and i'm sure you have one that sets up the db [02:09] mikeal: this would be in the initializer for the db [02:09] kriszyp: anyway, mde, if you do take a look at perstore and have any suggestions or things you would like to see, let me know, glad to collab... [02:09] mde: Ah, okay. Yea, I'll take a look. I mean, that's basically what I have now. Its just a DSL in code instead of a JSON structure. [02:09] mikeal: but the rest of your code would just use whats in the db for validation instead of pull that same code [02:10] mde: You could just a JSON schema to generate the same set of code. [02:10] mikeal: OMG [02:10] mde: I'd have to see stuff like how to allow a validation based on an arbitrary function, etc., but it sounds interesting. [02:10] mikeal: i David Cross' new standup really called "Bigger and Blacker" [02:10] mde: kriszyp_afk: I'll definitely take a look. Thanks. :) [02:11] mikeal: this would be like a crazy new thing [02:11] mikeal: but i think it's a better model [02:12] mde: So much of the time you have this mixing of code and data structures in JS anyhow. [02:12] mde: It might be a nice fit. [02:12] mde: Shit, geddy-model could be compatible with both approaches. [02:12] mikeal: it would make the code sharing easier too [02:13] mikeal: if for some reason you do need to branch for some browser stuff to do models you're still parsing the same schema JSON [02:14] mde: Well, that's the same if it's in code. It's all just JS. :) [02:14] itistoday has joined the channel [02:14] mde: It already works cross-browser, cross-server. Even in IE6. [02:14] itistoday has left the channel [02:15] mikeal: you know that some day you're gonna hit a issue where you really want a branch specifically for ie6 [02:15] mikeal: i don't think i can actually talk to you about this tho because you're so stoked to be writing javascript on the backend that anything I say is like "don't piss on my dreams man" [02:15] ryah: i'm thinking about how we can presever a stack trace across events. if every time an new event emitter is "enabled" [02:16] ryah: we could take a snapshort of the stack and store it on it [02:16] mikeal: most of the time, i don't get exceptions i get an error event that is unhandled [02:17] _announcer: Twitter: "can anyone provide a pointer on getting #jSpec + #jQuery going? as the rhino + env.js is currently busted, how do we get going with Node.js?" -- Steven Harman. http://twitter.com/stevenharman/status/17298217245 [02:17] ryah: yeah [02:17] mikeal: if that error event just had more it would go a long way [02:17] ryah: i'm starting to hate the 'error' event. [02:18] mikeal: i really want to find out what Brendan Eich as talking about [02:18] mikeal: once he was talking about better systems for handling errors [02:18] mikeal: and how everything that snapshots the stack kind of sucks in the long run [02:19] mikeal: it makes debugging easier but it's also useless if you want to not fail at the point where the program is running [02:19] mikeal: and how there have been systems that pass the stack to an error handler and you can actually fix it and resume the execution [02:19] ryah: i think if we just attached a stack to every event emitter it would be okay, i think [02:19] ryah: that might be slow - so we'd hav eit optional [02:19] mikeal: that sounds expensive/ [02:20] mikeal: ? [02:20] ryah: each time a new event emitter is "started" it would catch the stack and store it in the object [02:21] mikeal: that could work [02:21] ryah: plus a reference to whatever event emitter called it [02:21] mikeal: there is a lot that happens outside of event emitters tho [02:21] ryah: then you could walk back and display, say hte last 5 stacks [02:21] ryah: which i suspect will give a very good idea of how you got there [02:21] mikeal: that's usefull [02:21] ryah: in production mode you'd turn it off [02:22] ryah: so it wouldn't capture stacks [02:22] ryah: or, who knows [02:22] ryah: maybe reading out the stack isn't expensive [02:22] ryah: i suspect it is [02:22] mjr_: capture the stack when you events.EventEmitter.call(this), or when you do addListener? [02:22] mikeal: it sounds expensive [02:23] mikeal: but i would love to be surprised [02:23] ryah: mjr_: yeah something like that [02:23] mjr_: something like which? [02:23] ryah: mjr_: first [02:23] jashkenas: ryah: the stack saving sounds like an excellent idea. [02:23] mjr_: Ahh, OK. That doesn't seem tha tbad. [02:24] ryan[WIN]: http://proggit.pastebin.com/Rf7mjq7x [02:24] jashkenas: could you replace the error argument-in-callbacks with having the event emitter throw the exception inside of the stack in which the event emitter was started? [02:24] ryan[WIN]: how come the output is correct on sys.inspect [02:24] ryan[WIN]: but JSON.stringify returns "[]" [02:24] Tim_Smart: Ooo Tracemonkey looks good [02:24] ryah: so let's say you have http.createServer(function (req,res) { setTimeout(function () { throw new Error('blah'); }, 10); }); [02:25] temp01: ryah: use an object, var temp = {}; [02:25] temp01: ryan[WIN]* [02:25] ryah: yeah, that'd be cool [02:25] ryah: i think it'd lend to a lot more introspection [02:25] ryan[WIN]: ok so i have to do {} instead of [] [02:26] temp01: yeah, that's what you should use if you want to use non-numerical keys [02:26] ryah: you should be able to get a pointer to the line where the server is created though [02:26] ryah: or at least starts listening [02:26] ryan[WIN]: temp01, ok it works thanks [02:26] _announcer: Twitter: "pouring over node.js logs to get some of my questions answered.." -- A'braham Barakhyahu. http://twitter.com/BlessYahu/status/17298830103 [02:27] jashkenas: right, you'd pop back out right before the async call got deferred, ideally. [02:28] drobati has joined the channel [02:29] _announcer: Twitter: "@stevenharman node.js file in the spec/ folder created when you do a jspec init, very similar to the rhino runner to include env.js and" -- Scott Walker. http://twitter.com/pragma_tech/status/17298977938 [02:29] Tim_Smart: Nice. http://kangax.github.com/es5-compat-table/ [02:30] jashkenas: I wonder if getters/setters are in the latest IE9. [02:31] _announcer: Twitter: "@pragma_tech does env.js run in Node? from the looks of their current (1.2) release, I assumed they only support Rhino. gahhh! :)" -- Steven Harman. http://twitter.com/stevenharman/status/17299112804 [02:31] jashkenas: I presume that the presence of Object.defineProperty means that they must be. [02:31] rauchg_: _announcer bot is the best idea since node.js [02:33] _announcer: Twitter: "@stevenharman Take a look at jsdom: http://github.com/tmpvar/jsdom #node.js #javascript" -- Tim Smart. http://twitter.com/Tim_Smart/status/17299251004 [02:34] malkomalko: anybody ever do anything with soap and a wsdl ? [02:36] technoweenie: heh [02:36] bpot has joined the channel [02:44] bpot has joined the channel [02:45] ryah: i think we need to split event emitters into two kinds [02:46] ryah: ones that actually emit events off the event loop [02:46] ryah: which would be in C++ [02:46] ryah: and the ones we use in javascript [02:46] ryah: i mean the "request" event didn't come off the event loop - it originates from a TCP socket's 'data' event. [02:46] Tim_Smart: What are the +/-'s of the two? [02:47] ryah: setTimeout callbacks come rather directly off the event loop [02:47] jashkenas: would you only be saving the stacks for one of the two kinds? [02:47] ryah: AMQP "message" events are just parsed protocol [02:47] ryah: i need a good name for the two types: fundemental and pseudo ? [02:48] ryah: c++ event emitters capture stack, the others don't [02:48] Tim_Smart: new EventEmitter(true) or something [02:48] Tim_Smart: new EventEmitter({ psuedo: true }); [02:48] ryah: if someone throws during a callback from a non-c++ emitter, it propigates up through the emit() [02:48] ryah: in a c++ emitter, if someone throws you need to kill the program [02:49] ryah: does this make sense to anyone? [02:49] ryah: it's hard for me to think about too [02:49] jashkenas: ryah: makes a ton of sense. faux-emitters in JS don't have to loose their stack in the first place. [02:49] jashkenas: *lose [02:49] ryah: right [02:50] ryan[WIN]: ryah how about hard and soft [02:50] Tim_Smart: The C++ event loop is separate from the V8 one right? [02:50] ryah: real emitters are at the bottom of the stack [02:50] ryah: ryan[WIN]: that's good [02:50] ryah: hard emitters are at the bottom of the stack, always [02:50] ryah: the others are just sugar [02:50] jashkenas: ryah: the trick is going to be getting real emitters to behave like the faux-emitters, when an exception happens. And if you pull that off, you've solved Node. [02:50] ryan[WIN]: jashkenas, you can' really do that due to stack magic [02:51] ryah: i kind of think the real emitters don't need to have the same API [02:51] jashkenas: ryah's planning on doing some stack magic. [02:51] jashkenas: but what would be the harm? [02:51] ryah: like right now we have these "watchers" (which is a libev term) [02:51] Tim_Smart: performance [02:51] ryah: all you do is watcher.start() watcher.callback = function () { ...} [02:51] ryah: they just execute the .callback member [02:51] jashkenas: Tim_Smart: this is only for external IO emitters. It wouldn't be too hard on performance unless you were doing a shit-ton of simultaneous IO. [02:52] ryan[WIN]: isn't that the point of using node [02:52] ryah: basically "hard" emitters are always going to be wrapped [02:52] ryan[WIN]: to do a shit-ton of simultaneous i/o :D [02:53] jashkenas: it would be the cost of one stack-worth of memory for every simultaneous external IO op. [02:53] ryah: "hard" emitters can be a certain type of dtrace probe too [02:53] isaacs has joined the channel [02:53] ryah: in fact, we might want to only have "hard" emitters doing dtrace probes [02:53] Tim_Smart: ryah: Right. And hard emitters don't catch throws? [02:53] ryah: hard emitters have to deal with throws [02:54] ryah: either by calling the 'uncaughtException' thing [02:54] Tim_Smart: Just wrap it in a closure with a try catch :D [02:54] ryah: or by exiting the program [02:55] Tim_Smart: watcher.callback = function () { try { callback() } catch (err) { handle(err) } }; <- You do that already? [02:55] ryah: eh [02:55] ryah: in c++, kind of [02:56] ryah: Tim_Smart: http://github.com/ry/node/blob/242161bef2e3631d315f8da8a62c088bdc100c87/src/node_timer.cc#L65-90 [02:56] stepheneb has joined the channel [02:56] ryah: here's what "hard" timers emitters look like [02:56] ryah: note the try catch [02:57] Tim_Smart: Yup. [02:58] jashkenas: ryah: I'm sure I'm just being naive, but how about this ... when a hard emitter is created, capture the V8 CurrentStackTrace, and associate it. If the hard emitter ever has an exception the bubbles up to the top, resume the saved stack and restart the exception. [02:58] ryah: jashkenas: almost - you can't resume it [02:59] ryan[WIN]: v8 doesn't allow you to resume [02:59] ryah: but you can print it out [02:59] ryan[WIN]: its evaluation-based [02:59] ryah: so i'm imagining an API like this: [02:59] ryah: hardEmitter.start() // captures stack [02:59] jashkenas: Ah, so you can't catch from outside ... but you can print the full trace as if there was no loss of stack. [02:59] ryah: hardEmitter.callback = function () { }; [02:59] ryah: hardEmitter.catch = function (e) { }; [03:00] ryah: to allow for: t = setTimeout(fn, 10); t.catch = function () { }; [03:00] jashkenas: nice -- that would be much preferable to the error-argument-goes-first style. [03:00] ryah: catch is reserved, so something else [03:00] ryan[WIN]: handle? [03:01] Tim_Smart: onError or something [03:01] ryah: well the fs methods are different.. they come off the event loop [03:01] ryah: er off the thread pool [03:01] jashkenas: the api would be different for them? [03:01] ryan[WIN]: what's a synonym for catch [03:01] TS_: trap [03:01] jashkenas: rescue, in Ruby. [03:01] ryah: there isn't any hard emitter associated to the file system stuff [03:01] ryan[WIN]: ryah call it grab [03:02] ryan[WIN]: or [03:02] ryah: my main goal, though, isn't to allow people to rescue these exceptions [03:02] jashkenas: why wouldn't it be addListener('error', ...) [03:02] ryah: i'm just noting that it would be possible with this [03:02] ryah: mostly i want to display stacks on exceptions [03:03] _announcer: Twitter: "@stevenharman scratch that... Say @tjholowaychuk does env.js work with node runner for JSpec?" -- Scott Walker. http://twitter.com/pragma_tech/status/17301186731 [03:03] ryan[WIN]: snatch [03:03] ryah: :) [03:03] ryan[WIN]: i dunno what's a word that implies you handle something but not really [03:03] ryan[WIN]: like a read only catch [03:03] ryah: yeah, the fs things are annoying [03:04] ryah: probably should create a little object for each of them [03:04] ryah: a little hard emitter [03:04] ryah: (we will explicitly avoid saying 'promise') [03:04] TS_: grasp [03:05] ryan[WIN]: haha how about witness [03:05] jashkenas: iou [03:05] ryan[WIN]: like you're only going to witness this crap [03:05] ryah: var emitter = fs.readdir('/usr'); [03:05] ryan[WIN]: when a crime has been committed [03:05] ryah: emitter.callback = function ( ) { }; [03:05] jashkenas: ryah: nah, the callback is good where it is ... it's the error argument that's the problem. [03:05] jashkenas: emitter = fs.readdir('/usr', callback); [03:06] jashkenas: emitter.addListener('error', callback); [03:06] Tim_Smart: I actually quite like the first error argument, buts thats just me... [03:06] ryah: yeah me too [03:06] ryah: just kinda easy [03:06] Tim_Smart: if (err) return handle(err); [03:06] jashkenas: Tim_Smart: I have ulterior motives here. If we kill the error argument, you'll be able to write this in deferred coffee: [03:07] jashkenas: code: defer fs.readFile path [03:07] jashkenas: puts code.toString() [03:07] jashkenas: And have it actually be async, as a callback. [03:07] Tim_Smart: jashkenas: Right. I'm not a big supporter of defer though. [03:07] jashkenas: Right now, you have to do... [03:07] jashkenas: [error, code]: defer fs.readFile path [03:07] jashkenas: and that's just ugly. [03:07] ryan[WIN]: it's nodejs not nodedeferredcoffeee [03:07] ryan[WIN]: get that mess out of here [03:08] ryan[WIN]: :D [03:10] jashkenas: ryah: as one last argument, if you replace error-as-first-arg with an error event, you solve all the problems people are having with swallowed errors in callbacks failing silently. [03:10] Tim_Smart: jashkenas: I guess it does introduce some readability, but it definitely detracts from readability in the sense of 'Is this async code, or sync code?' [03:10] jashkenas: right now you don't know if someone's checking or not. [03:10] ryah: jashkenas: yeah [03:10] jashkenas: But with an 'error' listener, you can throw the uncaughtException if no-one is listening for it. [03:11] ryah: jashkenas: have you seen the chrome module api? [03:11] ryah: extensions [03:11] jashkenas: ryah: no. I'll go look. [03:11] ryah: it's really nice [03:11] ryah: i wish i could have such nice API [03:11] Tim_Smart: Then again, people that don't handle errors need to get burnt once or twice :p [03:12] jashkenas: Tim_Smart: APIs that allow exceptions to be swallowed without notice are basically error code checking, not exceptions. [03:12] jashkenas: chrome extensions link, for the interested: http://code.google.com/chrome/extensions/index.html [03:13] Tim_Smart: jashkenas: Yeah, I guess it should throw if not thrown. [03:13] Tim_Smart: Is is possible, to make error a getter? [03:13] jashkenas: not as an argument, it's not. [03:14] Tim_Smart: but: callback(my_obj.error, result) [03:14] Tim_Smart: but: callback(my_obj.error, my_obj.result) [03:14] Tim_Smart: or something. [03:14] jashkenas: right, a global error handler in that case. ugh. [03:14] jsilver has joined the channel [03:14] Tim_Smart: jashkenas: It would be per instance or something. [03:15] jashkenas: then you effectively have emitter = async() again. And we're where we started. [03:15] jashkenas: that would be great. [03:15] _announcer: Twitter: "Node.js programmers have such a great design sense http://vowsjs.org/" -- Jacques Crocker. http://twitter.com/railsjedi/status/17302021632 [03:16] jashkenas: ryah: was there a particular part of the Chrome extensions api you liked? [03:16] Tim_Smart: jashkenas: Let me write a psuedo fs.readFile [03:16] ryah: jashkenas: how they do events [03:16] jashkenas: http://code.google.com/chrome/extensions/events.html [03:16] ryah: but everything really [03:17] jashkenas: ah, this bit seems especially relevant: http://code.google.com/chrome/extensions/messaging.html [03:17] findyourownpath has joined the channel [03:18] ryah: port.onMessage.addListener(function(msg) { [03:18] ryah: :P~ [03:18] jashkenas: chrome.extension.onRequestExternal.addListener(function(request, sender, sendResponse){ ... sendResponse(obj) ... }) [03:18] jashkenas: right. [03:18] jashkenas: a bit baroque. [03:19] ryah: i felt it was more victorian [03:19] ryah: console.assert(port.name == "knockknock"); [03:19] ryah: ^--- console has assert? [03:21] jashkenas: yup. looks like that's the only Firebug assertion that made it out cross-browser: http://www.joehewitt.com/software/firebug/docs.php [03:23] nsyee has joined the channel [03:24] Tim_Smart: jashkenas: I have a feeling this won't work: https://gist.github.com/c76285be1485b0e816dc [03:24] Tim_Smart: it will call the getter I think when calling the callback [03:25] jashkenas: Tim_Smart: what is that trying to do? [03:25] jashkenas: oh, your getter as first arg. [03:25] mostlygeek has joined the channel [03:26] Tim_Smart: Whoops. Look again. I forgot to return the error in the getter [03:27] Tim_Smart: Yeah that won't work. [03:28] ryah: can you do string.replace(/re/, function () {}); in v8? [03:28] Tim_Smart: Unless... [03:28] mjijackson has joined the channel [03:29] mjijackson: OT: A while back I came across a website that was tracking consecutive daily commits to open source projects. Does this sound familiar to anyone? Can't remember what it was called... [03:29] mjijackson: If I remember right, it was just tracking GitHub projects... [03:30] kersny has joined the channel [03:30] Tim_Smart: jashkenas: https://gist.github.com/c76285be1485b0e816dc [03:30] jashkenas: mjijackson: http://calendaraboutnothing.com/ [03:30] mjijackson: jashkenas: That's it! thx [03:32] rauchg_: nice idea [03:32] rauchg_: i could set up an autocommitter :P [03:32] isaacs: ryah: i'm a much bigger fan of foo.addListener("bar", function ...) rather than foo.onBar.addListener(function...) [03:32] isaacs: even better is foo.on("bar", function....) [03:33] jashkenas: isaacs: ++ [03:33] isaacs: or even just foo.onBar = function ... [03:33] ryah: isaacs: nod [03:33] isaacs: but that doesn't let you have more than one listener to the same ev on the same obj [03:33] Tim_Smart: on('event', fn); [03:33] Tim_Smart: nice. [03:33] jashkenas: on('error', ...) would be lovely. [03:33] ryah: it's hard to pick apis [03:34] ryah: APIs x Time is harder still [03:34] isaacs: Tim_Smart: require("events").EventEmitter.prototype.on = function () { this.addListener.apply(this, arguments) } [03:34] Tim_Smart: Huh yeah. [03:35] isaacs: while you're at it: require("events").EventEmitter.prototype.fire = function () { this.emit.apply(this, arguments) } [03:35] Tim_Smart: emit is pretty well named though. [03:35] isaacs: eh [03:35] isaacs: fire, emit, trigger, whatever. [03:35] isaacs: i like "on" because it's just 2 chars [03:35] Tim_Smart: Yeah and you can read the code aloud easier. [03:35] isaacs: i'd like "do" better than "emit" for a very similar reason [03:36] jxson has joined the channel [03:36] ryah: yeah [03:36] ryah: maybe we can do 'on' [03:36] ryah: would make the examples awesomer [03:36] jashkenas: ryah: would you consider taking a patch that turned 'addListener' into 'on' ... and replaced the error argument with an on('error', ...) handler? [03:37] Tim_Smart: ryah: Have both for a while, and slowly take addListener out [03:38] ryah: jashkenas: let me think about it some more [03:39] isaacs: EventEmitter.prototype.addListener = function (ev, handler) { sys.error("use on! it's awesomer!"); return this.on(ev, handler) } [03:39] isaacs: i do like the error argument. [03:39] isaacs: npm uses that all over the place. it's a nice consistent pattern. [03:39] isaacs: jashkenas: you're referring to the cb(er, ok) pattern? [03:40] Tim_Smart: Need a way of seeing if the error argument has been used, then that would be cool. [03:40] jashkenas: isaacs: yep. if you look in the backlog we talked about it a bit. ry's got a plan for better potential error reporting. [03:40] jashkenas: So that you wouldn't have to check it and throw it most of the time yourself. [03:40] isaacs: s/addListener/on/ is a pretty straightforward change, though [03:40] isaacs: jashkenas: i almost never throw it. [03:40] Tim_Smart: Maybe make the error arg a function? [03:40] Tim_Smart: if (err()) throw err() [03:41] isaacs: jashkenas: i bubble it up to a higher level, and sometimes log something about it. [03:41] isaacs: function foo (some, args, cb) { doSomething(function (er, ok) { if (er) return cb(er) .. [03:41] jashkenas: well then your users are having to throw it, or you do at the higher level, or it gets lost. [03:42] tlrobinson_ has joined the channel [03:42] isaacs: jashkenas: i log it, and terminate with a non-zero code [03:42] isaacs: jashkenas: occasionally, i also log a few other things as it bubbles up [03:42] Linnk has left the channel [03:42] isaacs: it's actually very similar to a throw, conceptually [03:42] jashkenas: isaacs: it would in no way prevent that. It would just be safer if you didn't remember or didn't care to check for it. uncaughtException is always at the top, and you can log and exit there, and only have to write it once. [03:43] isaacs: but whatever. i could kinda use a bit of a fire under my ass to get some things done with npm. maybe if ryah changed the node api dramatically, i'd have to refactor all that code anyway, so that'd be a good stimulant. [03:43] isaacs: jashkenas: but i mean, the error might be like an ENOENT, which isn't terribly helpful, but then i know that it was while reading a package.json file, while trying to load the "Foo" package, so that you could get the dependencies, etc. [03:43] isaacs: like, many layers in, and knowing all the layers is important. [03:44] isaacs: having it trapped at the top is just the last resort failsafe. [03:44] isaacs: if anything its unhandledException, then there's a bug. [03:44] isaacs: s/its/hits/ [03:44] bradleymeck1 has joined the channel [03:44] Tim_Smart: https://gist.github.com/8cc394836b2a7323cabf jashkenas [03:45] drobati has joined the channel [03:45] isaacs: mostly, i like the fact that it's simple, and consistent, and the minute ry says "i'm gonna think about doing it a new way..." everyone starts getting into this huge debate about the One True Pattern for Callbacks [03:46] isaacs: so this line of conversation makes me fear a lot of useless bikeshedding. [03:47] isaacs: there are approximately one gillion extremely great patterns for callbacks and error handling. but switching is painful. [03:48] CIA-76: node: 03Ryan Dahl 07master * re2db605 10/ src/node.cc : Use EVBACKEND_POLL on Solaris; select() is just a wrapper anyway - http://bit.ly/avvOXX [03:48] _announcer: Twitter: "I am f'ing rocking and rolling on the NodeJS stuff... once I got over the hurdle, I've been sprinting...!" -- Clint Andrew Hall. http://twitter.com/clintandrewhall/status/17304130506 [03:48] CIA-76: node: 03Ryan Dahl 07master * r23172c5 10/ (src/node_script.cc src/node_script.h): Lint node_script.cc - http://bit.ly/azNkk0 [03:48] CIA-76: node: 03Ryan Dahl 07master * rc9e1220 10/ src/node.js : Stub out console.log format strings, info, warn, error - http://bit.ly/auQVoL [03:52] rednul has joined the channel [03:54] _announcer: Twitter: "@clintandrewhall what are you using nodejs for?" -- sambao21. http://twitter.com/sambao21/status/17304539087 [03:56] derferman has joined the channel [04:01] 15SAAGQOT has joined the channel [04:01] _announcer: Twitter: "best I can tell, jSpec + jQuery is currently only possible if you use a browser; Rhino + env.js is busted & node.js doesn't support env.js" -- Steven Harman. http://twitter.com/stevenharman/status/17305001393 [04:04] nefD has joined the channel [04:08] mikeal: is there an equivalent to "$ touch filename" that i can do without a subprocess? [04:12] marshall_law has joined the channel [04:13] marshall_law_ has joined the channel [04:13] mjr_: mikeal: I think you can almost get there [04:13] mjr_: I just learned what touch actually does: http://www.opensource.apple.com/source/file_cmds/file_cmds-202.2/touch/touch.c [04:13] admc_ has joined the channel [04:13] admc has joined the channel [04:13] mjr_: and apparently the answer is: utimes(2) [04:14] mikeal: i'm just doing an openSync('w') [04:14] mikeal: well, filename, w [04:14] bradleymeck1 has joined the channel [04:14] mjr_: does it update the times even if you don't write anything? [04:15] aho has joined the channel [04:15] liucougar has joined the channel [04:17] jashkenas: touch (c) 1993 The Regents of the University of California. [04:17] bradleymeck1: stupid internet... grumble [04:21] ryah: EventSource ? [04:21] ryah: ^-- instead of "hard event emitter" ? [04:21] ryah: or is that more confusing [04:22] ryah: HardEventEmitter EventEmitter [04:22] CIA-76: node: 03Ryan Dahl 07master * rb69c6a0 10/ src/node.js : If not string, console.log should just print it without trying to format - http://bit.ly/b1ken1 [04:22] CIA-76: node: 03Ryan Dahl 07master * r5aadeae 10/ (src/node_events.cc src/node_events.h): Simply C++ event emitter - http://bit.ly/dpNFu5 [04:24] jashkenas: would you ever instantiate a HardEventEmitter from JS? Or is this just the class name for internal Node use? [04:24] ryah: it would be the C++ base class of them [04:25] ryah: but you would instanciate subclasses of HardEventEmitter in JS [04:25] jashkenas: AsyncEventEmitter, perhaps, or AsyncEmitter ... isn't that the difference between hard and soft that we're really talking about... [04:25] ryah: jashkenas: http://github.com/ry/node/blob/242161bef2e3631d315f8da8a62c088bdc100c87/lib/net.js#L525 [04:26] jashkenas: which bit? [04:26] ryah: that's a hard emitter being instanciated [04:26] ryah: inside js [04:26] jashkenas: ioWatchers.alloc() ? ok. [04:26] ryah: extra layer of weirdness due to freelist [04:27] ryah: http://github.com/ry/node/blob/242161bef2e3631d315f8da8a62c088bdc100c87/lib/net.js#L218 [04:27] Tim_Smart: jashkenas: http://github.com/ry/node/blob/master/src/node_io_watcher.cc [04:27] jashkenas: right. [04:27] ryah: (attempt to reuse IoWatchers instead of reallocating them all the time) [04:27] _announcer: Twitter: "すげー - Node.js RPC with MessagePack - http://github.com/austinchau/msgpack-rpc-node" -- 亭主関白君 (the boss boy). http://twitter.com/kuenishi/status/17306600364 [04:28] WALoeIII has joined the channel [04:28] jashkenas: gotcha. the io pool. [04:28] ryah: but you could just replace that alloc() with new IoWatcher() [04:28] ryah: anyway.. [04:29] jashkenas: so basically IoWatcher is HardEventEmitter right now. [04:29] jashkenas: IoEmitter ... [04:30] tmpvar has joined the channel [04:30] tmpvar: Aria, you around? [04:30] tmpvar: hi all [04:30] ryah: jashkenas: yes [04:30] ryah: it just doesn;t have the C++ base class it needs [04:31] Aria: I am, off to bed shortly. What's up, tmpvar? [04:32] tmpvar: im having an interesting time finding your parser.. could you hook me up with a link? [04:32] Aria: http://github.com/aredridel/html5/ [04:32] tmpvar: thanks [04:33] Aria: sure thing! [04:33] tmpvar: how close is it to being "done"? :P [04:34] Aria: It passes more tests than html5lib does ;-) [04:34] tmpvar: haha, nice [04:34] stevendavie has joined the channel [04:34] tmpvar: last question, how good does it handle f-d up markup? [04:35] Aria: But really, it works. Anything that throws an exception is a bug. There's some edge cases that may or may not parse the same as others, but they are edge cases in broken code. [04:35] Aria: Amazingly, really. It turns out a full, sane document. [04:35] tmpvar: nice :) [04:35] tmpvar: that is exactly what i wanted to hear [04:35] _announcer: Twitter: "Just dove into node.js and wow is it fun." -- Brian Landau. http://twitter.com/brianjlandau/status/17307049008 [04:35] Aria: That's why I love the HTML5 spec so much. This is the same kind of parser Firefox uses. [04:35] Aria: (the latest one, that is.) [04:35] ryah: at some point i tried to pawn off this design decision onto the community - http://thread.gmane.org/gmane.comp.lang.javascript.nodejs/5416 [04:35] tmpvar: awesome [04:35] Aria: (3.6) [04:36] tmpvar: great, I'm going to take it for a spin [04:36] Aria: Sweet. If it goes boom, let me know. [04:36] ryah: tmpvar: finally :) [04:36] Aria: I just imported a ton more test cases, so I'm still working hard on it. [04:37] tmpvar: awesome! [04:37] tmpvar: ryah, yeah yeah [04:37] tmpvar: been busy hacking java 12 hours a day :'( [04:37] tmpvar: I don't even know/like java! [04:37] ryah: ACTION is waiting for the jsdom/html5 second coming of christ [04:38] tmpvar: lmfao [04:38] ryah: you know, where we have the API that does: jsdom.fetch("http://google.com/", function (dom) { } ) [04:38] tmpvar: store to mongodb, etc etc etc [04:39] tmpvar: ok, off to hackery [04:39] ryah: i dont know about that, i just want to be able to pull down DOMs easily :) [04:39] tmpvar: lol, well bikeshed the api then ;) [04:40] tmpvar: say, "I want it to make me coffee in the morning, and tuck me in at night" [04:46] Tim_Smart: tmpvar: naw, that should be in core. [04:46] marshall_law: tmpvar: i feel your pain [04:49] jashkenas: ryah: Exhibitionist is my only other suggested alias for EventEmitter. [04:51] steadicat has joined the channel [04:51] WALoeIII has joined the channel [04:51] Tim_Smart: Nice site: http://vowsjs.org/ [04:51] Tim_Smart: (For those interested in async testing) [04:52] tmpvar: oh wow, I didn't realize Aria had integrated jsdom already, nice :P [04:54] tmpvar: I was looking at her tests, wondering, where does these magic dom elements come from? hah [04:54] bpot has joined the channel [04:55] Scriptor has joined the channel [04:59] ryah: isaacs: ping [04:59] isaacs: ryah: yo [04:59] ryah: isaacs: does mapping in npm work? [04:59] isaacs: ryah: no. [04:59] isaacs: ryah: what are you trying to do? [04:59] ryah: isaacs: i wanted to make a package.json for html5: http://github.com/aredridel/html5 [04:59] ryah: it requires nodeunit [04:59] isaacs: requires nodeunit? [05:00] isaacs: oh, weird. [05:00] isaacs: can you create a package.json for nodeunit? [05:00] isaacs: oh, also it looks like it requires env-js [05:00] ryah: jsdom [05:00] isaacs: npm install jsdom [05:01] Tim_Smart: dependencies: { "json": ">=x.x.x" } [05:01] Tim_Smart: dependencies: { "jsdom": ">=x.x.x" } [05:02] Tim_Smart: >.< [05:02] Tim_Smart: "dependencies": { "jsdom": ">=x.x.x" } [05:02] isaacs: Tim_Smart: yeah, jsdom is hard to type [05:02] Tim_Smart: Third time lucky [05:03] isaacs: Tim_Smart: just { "jsdom":"*" } would probably work [05:03] _announcer: Twitter: ""Write some vows, execute them" http://vowsjs.org/ a behavior driven development framework for Node.js." -- Dion Almaer. http://twitter.com/dalmaer/status/17308637888 [05:03] ryah: oh [05:03] isaacs: ryah: you can get most of the way there with "link" [05:04] isaacs: ryah: "link" : { "jsdom" : "./path/where/you/want/jsdom/to/be" } [05:04] creationix has joined the channel [05:04] mjr_: isaacs: my package needs pcap.js, which in turn requires pcap_binding.node from ./build/default. How do I tell npm about both of them? [05:04] isaacs: mjr_: have pcap.js do a relative require to pcap_binding [05:04] mjr_: isaacs: it seems that the other packages that need a .node file don't actually get it linked in. [05:04] isaacs: mjr_: and make pcap.js set as the "main" module [05:04] ryah: mjr_: checkout my postgres example [05:04] _announcer: Twitter: "# FRENDS server nodeJS All I did was to compile, Wordpress server side I do not have the connections .. During =__=)`` services should not nothin '," [ko] -- A.J. http://twitter.com/andrwj/status/17308707690 [05:04] Tim_Smart: mjr_: You will need a build script, or execute the commands via preinstall and install [05:04] mjr_: ryah: how does postgres binding.node get linked/copied? [05:05] isaacs: mjr_: "main" : "./pcap", "scripts" : { "preinstall" : "node-waf configure build" } [05:05] ryah: mjr_: http://github.com/ry/node_postgres/blob/master/package.json [05:05] isaacs: ryah: so, with this html5 thing.. [05:05] creationix has joined the channel [05:05] mjr_: Yeah, I have that, and it builds pcap_binding.node, but then it gets stuck in build/default/pcap_binding.node, and nobody else ever knows about it. [05:05] isaacs: ryah: you can use link to put jsdom at a place, and then dive into its lib [05:06] jashkenas has joined the channel [05:06] isaacs: mjr_: well, yeah, but i mean, that's the binding. it probably *should* be private [05:06] isaacs: mjr_: if you really must, you can put it into whichever directory you declare as pcap's liv [05:06] isaacs: *lib [05:06] Scriptor has left the channel [05:06] mjr_: So should the preinstall script copy the .node file into .node_libraries? [05:06] _announcer: Twitter: "# FRENDS NodeJS v0.1.99-28-g5aadeae on the server version was installed and connected for a chat on the DM will be announced separately." [ko] -- A.J. http://twitter.com/andrwj/status/17308824726 [05:07] isaacs: mjr_: { "main" : "./pcap", "scripts" : { "preinstall" : "node-waf configure build" }, "directories" : { "lib" : "./build/default" } [05:07] mjr_: then requires lib/node_binding [05:07] mjr_: ? [05:07] isaacs: mjr_: ok, back up... what's your goal? [05:07] ryah: mjr_: from pcap.js do require('./build/default/binding') [05:08] isaacs: mjr_: yeah, what ryah said [05:08] isaacs: mjr_: who cares if no one else sees your binding.node file? [05:08] ryah: mjr_: http://github.com/ry/node_postgres/blob/master/postgres.js#L1 [05:08] mjr_: oh, so everybody who installs it will end up with a build/default dir that I can require through? [05:08] ryah: yeah [05:09] mjr_: Oh, OK. Lemme try that. [05:09] isaacs: mjr_: your "main" script will be in its proper dir [05:09] isaacs: mjr_: so it can pull in the binding via a relative url [05:09] mjr_: ahhh [05:09] mjr_: thwarted by magic [05:10] isaacs: hahah [05:10] creationix: meetup at sencha in palo alto wednesday night [05:10] _announcer: Twitter: "I try node.js & express. It is spectacular!" [ja] -- Tsukasa Hoki. http://twitter.com/mongorian_chop/status/17309004899 [05:10] creationix: mjr_, isaacs do you two want to come? [05:10] isaacs: creationix: sounds good to me [05:10] creationix: what did we start last time? 7:00? [05:11] mjr_: creationix: I'm in Indiana all this week to buy illegal fireworks. [05:11] mjr_: Otherwise I'd totally come. [05:11] creationix: mjr_: hmm, that's motivation [05:11] creationix: is not much legal in CA? [05:11] isaacs: creationix: pot is legal-er in CA than anywhere else in the us [05:11] mjr_: creationix: to be fair, they also have signs for strip clubs all over the freeway. [05:12] mjr_: speeding is also the most legal in CA. [05:12] mjr_: As is lane splitting on a motorbike. [05:12] isaacs: oh, yeah, i speed like crazy. [05:12] mjr_: But leave your guns and fireworks back in TX. [05:12] isaacs: ACTION only got one ticket, and has been trying to squeeze value out of it ever since [05:13] mjr_: In CA you can just make tickets go away by doing an "online traffic school" [05:13] mjr_: poof [05:13] dabreaka has joined the channel [05:13] creationix: nice [05:13] creationix: scripted with selenium no doubt [05:13] mjr_: I wouldn't know anything about that. [05:15] mjr_: But when I took mine, there was no connection from the "traffic school" website to the DMV website. I had to take a printout from my computer and hand it to a person, who typed in the values from the page into her computer. [05:15] mjr_: But nobody could change the information in a PDF file, so that's probably pretty safe. [05:16] isaacs: ryah: so, did you figure out how to do the html5 jsdom thing? [05:16] ryah: isaacs: no [05:17] ryah: well i got distracted [05:17] ryah: :) [05:17] isaacs: :) [05:17] steadicat has joined the channel [05:17] isaacs: i'd like to help you do it, so that i don't have to. i wanted to npmify html5, since it's super rad and awesome [05:17] isaacs: and also, I kind of get the impression that Aria is very smart, so if she was using npm, maybe i'd get good feedback on it. [05:18] tmpvar: ryah, what were you trying to do? [05:18] isaacs: but people see "package manager" and they think "this is gonna be hard to get started with", for some reason [05:18] ryah: isaacs: a cheat sheet would really be helpful [05:19] ryah: because, i think 99% of people will only use like 3 commands [05:19] isaacs: ryah: yeah, i agree [05:20] isaacs: i've been meaning to write up something like that for npmjs.org [05:20] _announcer: Twitter: "Vows: Asynchronous behaviour driven development for Node. #nodejs #js #bdd http://welu.se/i6" -- Pascal Hartig. http://twitter.com/passy/status/17309564704 [05:21] isaacs: ryah: there is http://github.com/isaacs/npm/blob/master/doc/developers.md#readme which is mostly that [05:21] isaacs: but it's not terribly exposed [05:21] creationix: isaacs: write a howtonode article [05:21] creationix: that will help [05:21] isaacs: creationix: yeah, planning on it [05:21] isaacs: so many things to do... [05:22] creationix: just copy paste one of your markdown file and modify it a bit to look like an article [05:22] Tim_Smart: Has anyone implemented a work queue in Node? [05:23] creationix: Tim_Smart: just little ones [05:23] creationix: what kind of queue do you need? [05:23] Tim_Smart: I don't stage. Just reading the write-up on resque [05:24] Tim_Smart: *at this stage [05:24] technoweenie: theres a node-resque project [05:25] ryah: isaacs: what's the command to upload again? "npm publish ." ? [05:25] isaacs: ryah: yeah, publish takes either a folder, a tarball, or a url to a tarball [05:26] isaacs: ryah: but yeah, "." is what to use if you're in the folder. [05:26] isaacs: i should probably make that a default or something. [05:26] isaacs: link, also [05:29] jsilver has joined the channel [05:29] isaacs: holy moly not requiring the . is AWESOME [05:29] ryah: i'm emailing the nodeunit person a package.json patch [05:30] isaacs: ryah: you are my hero [05:30] jsilver: hello all noders and ry [05:30] jsilver: i have come to read the chats [05:30] isaacs: ACTION .oO( ry isn't a noder? ) [05:30] ryah: jsilver: hi [05:30] Tim_Smart: You might have have said "everyone I don't really care about and ry" [05:31] Tim_Smart: You cold cold person. [05:31] mjr_: isaacs: I went and published myself an npm package [05:31] jsilver: lol [05:31] isaacs: mjr_: hooray! [05:31] jsilver: i care about ry [05:31] isaacs: mjr_: don't forget the last step! http://github.com/isaacs/npm/blob/master/doc/developers.md#readme [05:31] mjr_: http://github.com/mranney/node_pcap/blob/master/package.json [05:31] jsilver: he' rox my sox [05:31] isaacs: (tagging as "stable" will very soon not matter) [05:31] jsilver: right along with DHH [05:31] jsilver: and rms [05:32] mjr_: oh shit, I went right to brag [05:32] isaacs: mjr_: yeah, that doc is out of date [05:32] ryan[WIN] has joined the channel [05:32] isaacs: nothing in node is stable, so screw it [05:32] ryah: mjr_, isaacs: http://gist.github.com/456828 [05:32] mjr_: yeah, I kinda thought that part didn't matter [05:33] mjr_: uh oh, how'd my home dir leak out? [05:33] isaacs: huh. i've seen that before. [05:33] isaacs: definitely not an npm thing. [05:33] isaacs: is there like a waf lock file or something? [05:33] ryah: it's your wscript, probably [05:33] isaacs: right [05:34] isaacs: .wscript_lock or something [05:34] mjr_: It's not in my wscript [05:34] jsilver: mjr: why libpcap bindings for node? [05:35] mjr_: But that is for sure my local working dir on my computer [05:35] isaacs: yeah, it's .lock-wscript [05:35] mjr_: so npm picked that up and sent it along, and then waf on ry's machine read it? [05:35] jsilver: why should node talk to libpcap [05:35] isaacs: mjr_: echo ".lock-wscript" > .npmignore [05:35] jsilver: what is the application [05:35] jsilver: i'm not trolling [05:35] jsilver: i'm just curious [05:35] isaacs: then republish [05:36] mjr_: jsilver: one sec [05:36] jsilver: kk [05:36] isaacs: mjr_: i'll add that to the default list, so in the next version it won't be an issue. [05:36] isaacs: sorry bout that [05:36] mjr_: isaacs: that's $HOME/.npmignore, or in the package dir? [05:36] isaacs: mjr_: in the pkg dir [05:36] ryah: mjr_: probably the build dir then too [05:36] isaacs: mjr_: when in doubt, i just steal ideas from git [05:37] isaacs: ryah: it's globs, so anything you put in .npmignore will be ignored everywhere. [05:37] mjr_: isaacs: do I have to bump the version number? I get a version-sounding error [05:37] isaacs: ryah: but, unlike .gitignore, you can't change it per folder. [05:37] mjr_: Error: forbidden cannot modify existing version [05:37] isaacs: mjr_: yeah, or you could "npm unpublish pcap 0.0.2" and then do it [05:37] mjr_: oh, ok [05:38] isaacs: mjr_: but bumping the version for changes, that's a Good Thing [05:38] isaacs: mjr_: changing published versions is Less Good [05:38] mjr_: npm ! Error: not_found missing [05:38] mjr_: yeah, bump version [05:38] isaacs: hrm? [05:38] ryah: i would like to be able to do [05:38] ryah: git archive HEAD | npm publish [05:38] ryah: :) [05:38] mjr_: ryah: can you try pcap again? [05:38] isaacs: ryah: that's not far off [05:38] chrischris has joined the channel [05:39] mjr_: I added the .npmignore [05:39] mjr_: In the new and greatly improved 0.0.3! [05:39] mjr_: isaacs: I got the not_found missing from npm unpublish . [05:39] isaacs: mjr_: Binary file ./package/build/.wafpickle-7 matches [05:39] isaacs: Binary file ./package/build/default/pcap_binding.node matches [05:39] isaacs: Binary file ./package/build/default/pcap_binding_1.o matches [05:39] isaacs: mjr_: that's odd. it's totally there. [05:39] ryah: mjr_: http://gist.github.com/456831 [05:39] Tim_Smart: isaacs: What about npm publish -s for stdio publishing? [05:40] Tim_Smart: I could patch it if you want [05:40] isaacs: Tim_Smart: it can just check to see if stdin is streaming, and use that if so [05:40] mjr_: isaacs: so .npmignore build will get all fo those? [05:40] isaacs: mjr_: it gets whatever's in the folder you're building, yeah [05:41] Tim_Smart: isaacs: Right, but how would you check without a async call? Otherwise you will have to assume a directory [05:41] mape: So I just read this awsome article about coroutines, why isn't node using them? [05:41] mjr_: OK, there's a 0.0.4 with build in the ignore file [05:41] ryah: /ignore mape [05:42] Tim_Smart: !log [05:42] mape: Hehe, I kid! [05:42] mape: That is what you get for having me spend 40min backlogging :/ [05:42] mjr_: jsilver: do you have npm installed? [05:42] isaacs: Tim_Smart: there's like a isStdinBlocking somewhere, right? or maybe isATTY on something? [05:43] isaacs: Tim_Smart: even if it's async, that's cool, just take whatever's in the install function today, and move it inside a callback from that thing. [05:43] Tim_Smart: mape: Search for SteveDekorte on this log http://nodejs.debuggable.com/2010-06-29.txt [05:43] mjr_: ryah: does pcap work this time? [05:43] derferman has joined the channel [05:43] mape: Tim_Smart: I know, I was just joking (pretty bad joke at that). Like I said, spent 40min backlogging the channel [05:44] marshall_law has joined the channel [05:44] mape: But Steven never showed any code? [05:44] ryah: mjr_: yes! [05:44] mjr_: whew! [05:44] isaacs: mjr_: works for me! [05:44] mjr_: awesome [05:44] ryah: node> require('pcap') [05:44] ryah: { lib_version: 'libpcap version 1.0.0' [05:44] isaacs: would it be worthwhile to say that npm ignores all files named "build"? [05:44] mjr_: Can you guys run: sudo http_trace en0 tcp [05:44] mjr_: and see if it works? [05:44] Tim_Smart: mape: He did, but his node.js version was, well, crap. [05:44] mjr_: replace en0 with whatever your active interface name is. [05:44] ryah: sudo: http_trace: command not found [05:45] mjr_: oh, the bin linking thing didn't work. [05:45] ryah: bin linking - painful [05:45] ryah: yeah, would be cool [05:45] mape: Tim_Smart: Ah that was the gist he posted? (didn't have time to check the links) [05:45] isaacs: mjr_: "bin": { "http_trace": "./examples/http_trace" }, [05:45] isaacs: "bin": { "simple_capture": "./examples/simple_capture" }, [05:45] isaacs: "bin": { "tcp_metrics": "./examples/tcp_metrics" }, [05:45] isaacs: ^^ not valid json [05:45] mjr_: well, how do you do multiple bins? [05:46] mjr_: does it take an array also? [05:46] isaacs: should be "bin" : { "bin": { "http_trace": "./examples/http_trace" , "simple_capture": "./examples/simple_capture" , "tcp_metrics": "./examples/tcp_metrics"}, [05:46] isaacs: it's an array [05:46] isaacs: s/array/Object/ [05:46] isaacs: hash [05:46] isaacs: just have multiple items in there [05:46] Tim_Smart: mape: io: http://www.iolanguage.com/paste/p/2f7b5fce1.html his node.js: http://www.iolanguage.com/paste/p/2f7b5fce1.html my rewrite: http://gist.github.com/456595 [05:46] mape: isaacs: was thinking about nodeknockout, would it be beneficial to do a guide/example of how to get npm running/pushing a module as well as what should be in package.json? Like a best case deal. Or will it be a link to the current docs? [05:46] mape: Tim_Smart: thanks [05:47] isaacs: mape: yeah, i was just talking about that. need some public docs. [05:47] mape: Bah I'm behind on everything this morning [05:47] ryah: if i was a nerdy high school kid, i'd definitely spend the summer writing a DNS server in node.. [05:47] Tim_Smart: isaacs: Make a cool tutorial with the repl module [05:48] ryah: unfortuantely not enough time to write a dns server in node:~( [05:48] mjr_: ryah: I already have some of the basics of a DNS server [05:48] ryah: would love a dns server, irc server mash up [05:48] isaacs: ryah: yeah, seriously [05:48] Tim_Smart: npm>npm publish sjdlkjfs [05:48] Tim_Smart: npm says your doing it wrong [05:48] mjr_: can you try pcap again [05:48] jsilver: mjr I think I have NPM [05:48] mape: isaacs: But yeah, it is required to add the module to npm right if one would be in the knockout? [05:48] mjr_: jsilver: try npm install pcap [05:48] ryah: ryan@mac1234:~/src/nodeunit% sudo http_trace en0 tcp [05:48] ryah: warning: en0: no IPv4 address assigned - filtering may not work right [05:48] ryah: Listening on en0 [05:49] mjr_: ryah: en0 isn't your active interface if you are on wifi, probably en1 [05:49] jsilver: i dont have npm [05:49] jsilver: is npm the defacto now [05:49] mjr_: ryah: or if you have a data card or VPN link, ppp0 [05:49] ryah: mjr_: it's working [05:49] mape: Hopefully it will be, and looks like it is getting the most adoption [05:49] isaacs: mjr_: working for me, too [05:49] nsm has joined the channel [05:49] mjr_: nice [05:50] Tim_Smart: mjr_: You should get configure to check for pcap [05:50] ryah: mjr_: how does it know if the stream is for responses or requests? [05:50] mape: ryah: How come you aren't a judge? :) [05:50] mjr_: Tim_Smart: yeah, I know. If you don't have pcap-dev, it errors badly [05:50] ryah: mape: i am [05:50] isaacs: mjr_: you could have a preinstall script do that, and then your install script does the build. [05:50] mape: Oh k, not stated on the page [05:50] jsilver: hey guys [05:50] jsilver: is jLinq any good [05:50] mjr_: ryah: it watches which side initiated the TCP conneciton. [05:50] jsilver: it queries json arrays right? [05:51] ryah: mjr_: oh [05:51] mjr_: ryah: low level magic, for sure [05:51] ryah: the parser has a feature where it can decide of a stream is request or responses [05:51] mjr_: And it gets all bent out of shape if you somehow don't see all of the traffic, like if you have TSO going. [05:52] ryah: but it's not exposed to node yet [05:52] ryah: what's a TSO? [05:52] mjr_: Yeah, I saw that in there. It isn't any extra effort from where I'm sitting in the stack. [05:52] mjr_: sysctl net.inet.tcp.tso [05:53] mjr_: TSO === TCP Segmentation Offload, hardware acceleration for TCP large send case. [05:53] ryah: oh [05:53] mape: " a technique for increasing outbound throughput of high-bandwidth network connections" [05:53] mjr_: it only increases your throughput if you were already out of CPU. [05:53] mjr_: But whatever, it's a good thing. [05:54] mjr_: It does make capturing packets on a TSO-enabled host a bit complicated. [05:54] findyourownpath has joined the channel [05:55] mscdex has joined the channel [05:56] sr has joined the channel [05:57] TS_: [23:47] if i was a nerdy high school kid, i'd definitely spend the summer writing a DNS server in node.. / why ryah? [05:57] TS_: why dns/irc mashup? [05:57] ryah: so i could resolve while i chat [05:57] mjr_: node would make a great DNS platform [05:58] TS_: no job want to learn node [05:58] TS_: this summer [05:58] mjr_: Because many times you want to give different answers to requests based on some sort of database lookup or other logic that regular DNS servers don't do well. [05:58] ryah: would be cool to have an accessible DNS server that you could hook into [05:58] hdon has joined the channel [05:58] ryah: keep statistics, etc [05:58] mikeal: if I send fs.write a ton of writes on an append only file handler it'll batch them when there are a ton right? [05:58] isaacs: once upon a time, no job wanted applicants to learn ruby, or python. the kids that did anyway were first in line to get the cool new python and ruby jobs that came out a few years later. [05:59] mikeal: or does each fs.write call == an fsync call [05:59] TS_: cool [05:59] ryah: mikeal: i think 5 is the maximum concurrent thread pool requests [05:59] mscdex: story time ftw! [06:00] mikeal: this is all on one file handler [06:00] mikeal: so it shouldn't be concurrent [06:01] TS_: which dns server is de facto atm? [06:01] ryah: mikeal: fs.write is not smart [06:01] mscdex: i need some more coffee so i can finish this archive script in node [06:01] mikeal: hehe, ok [06:01] mscdex: blargh [06:01] ryah: TS_: bind [06:02] TS_: thumbs up! [06:02] ryah: TS_: bind is a large peice of softwrae [06:02] ryah: i would start with the RFCs [06:02] mjr_: Yeah, I like tinydns, except the code is unreadable. [06:02] mjr_: I admire djb for throwing out libc because he didn't trust it. [06:03] ryah: mjr_: nod [06:03] TS_: yes start at the rfc for sure [06:03] TS_: at the bottom ;) [06:03] ryah: i want to be free of libc [06:03] mjr_: Totally unreadable C code though. Just fucking cryptic magic. [06:04] mjr_: ryah: have you looked at his libc replacement things? They are super fast and rather cross-platform. [06:04] ryah: mjr_: only a bit [06:04] ryah: i would really like to do a libc with libev built in [06:05] ryah: i mean, you'd need to hack the crap out of libev [06:05] ryah: well [06:06] ryah: just write a new backend [06:06] ryah: for whatever polling mech you choose [06:06] mjr_: The more you talk about it, the harder it sounds. [06:06] ryah: :) [06:06] ryah: yeah, it's probably a lot of work [06:06] mjr_: I gotta get to bed. Thanks for the help isaacs and ryah. [06:06] ryah: imagine redoing all the file system stuff [06:07] isaacs: mjr_: no problem [06:07] ryah: later [06:09] isaacs: you know, defaulting to @latest means that you can't publish a bunch of beta versions, which is really a pita [06:09] isaacs: it's been handy to do "publish, publish publish, OK, that one works, tag it" [06:10] Tim_Smart: Yeah, remove @latest I guess, or have it optional and have a npm reconfigure or something [06:10] isaacs: Tim_Smart: it is configurable [06:10] isaacs: npm config set tag latest [06:11] isaacs: the thing is, no one changes that default [06:11] Tim_Smart: ok [06:11] ryah: isaacs: when is 0.1.18 coming out? [06:11] isaacs: so if it defaults to "stable" you have to put @latest on every command if you want the latest one, but if it defaults to latest, then you can't just publish betas and stuff [06:11] isaacs: like, you kind of have to make sure that the latest one works [06:11] isaacs: ryah: soon. [06:12] ryah: i'd really like to have something like 'npm link' except that it doesn't link but just downloads the whole tarball into the current directory [06:12] Tim_Smart: isaacs: Isn't it obvious which version is the latest [06:12] isaacs: ryah: i've had a busy couple of weekends haven't been able to work on npm that much [06:13] isaacs: ryah: like, "fetch and unpack"? [06:13] ryah: like, i often do this "mkdir vendor; cd vendor; (find some project;) git clone (project)" [06:13] isaacs: interesting [06:13] ryah: would be cool to just do "npm download nodeunit vendor/nodeunit" [06:13] ryah: or something [06:13] mattly has joined the channel [06:13] isaacs: that would be pretty badass [06:14] isaacs: assuming the first "nodeunit" is some kind of package identifier, like install takes [06:14] isaacs: ie, name[@tag], url, or path to a folder, or path to a tarball [06:15] isaacs: ryah: would it also run nodeunit's setup stuff, just installing it into that location instead of .node_libraries? cuz that could get complicated. [06:15] ryah: yeah [06:15] ryah: well maybe not [06:15] ryah: cause i guess i'd want to git add it without the build stuff [06:16] isaacs: ryah: why not just { "dependencies":{"nodeunit":"*"}, "link" : {"nodeunit":"./vendor/nodeunit"}}? [06:16] siculars has joined the channel [06:16] isaacs: ryah: then that'll just install nodeunit, and then link the installed one in [06:16] ryah: because i build these programs that are all self contained [06:17] ryah: even has node bundled with it [06:17] isaacs: yeah, i see [06:17] ryah: i'd rather not distribute npm with the package, but i would like to use npm to install and update it easily [06:17] isaacs: right [06:17] isaacs: as a dev tool rather than a deployment tool [06:18] ryah: basically: i'd like to specify an alternate directory for npm to use instaed of ~/.node_libraries [06:18] isaacs: ryah: that's easy [06:18] isaacs: npm --root path/you/want/to/use dosomething [06:18] ryah: but i also want all the sources there too [06:18] ryah: not just links [06:18] isaacs: right [06:18] ryah: oh [06:18] isaacs: you don't want that whole name/version folder structure with the cache and the symlinks and whatnot [06:19] ryah: npm --root ~/projects/myproject/vendor install nodeunit [06:19] isaacs: yeah.... [06:19] isaacs: but then you'll get the links and versions etc. [06:20] isaacs: but what if there was a way to do "npm download nodeunit ./vendor/nodeunit", and then if you wanted to, you could do "npm build ./vendor/nodeunit" [06:20] isaacs: ryah: that ^ would just be abstracting out stuff that's already being done. [06:21] isaacs: in fact, you could just "mkdir -P vendor/nodeunit; curl http://tarball | tar xz --strip 1 -C vendor/nodeunit" and then the build command is already implemented. [06:22] ph^ has joined the channel [06:22] isaacs: ACTION sometimes says "you" instead of "i" [06:28] kuya: 1 [06:29] kuya: sorry [06:33] mape: hehe [06:35] mscdex: reading the irc logs is fun [06:35] technoweenie has joined the channel [06:35] technoweenie has joined the channel [06:37] hdon has joined the channel [06:39] mape: Active night to say the least [06:40] technoweenie: anyone seen: crypto:3638 / return (new Hash).init(hash) when trying to load up socket.io? [06:41] mape: technoweenie: The mem leaks were the cause for the downloading being down? [06:41] technoweenie: mape: no, that bug right there is ^ [06:41] mape: Oh k [06:41] technoweenie: for some reason, hitting the websocket server kills it now, wtf [06:42] mape: can't have something to do with the new websockets protocol sending different headers breaking the server? [06:42] technoweenie: no, i think its breaking on ssl? i dont know really [06:43] jsilver: mjr_, you are a true hacka. respekt [06:43] jsilver: i didn;t see it before [06:43] jsilver: but now i do [06:43] jsilver: respekt my bruv [06:43] technoweenie: mape: and the memleak itself seems to be fixed in node master [06:44] mape: Nice [06:46] wink_ has joined the channel [06:47] technoweenie: yea i dont think crypto is being loaded right, require('crypto').createHash('md5') triggersit [06:49] mape: technoweenie: It down right dies? [06:49] technoweenie: yea, with that error [06:50] mape: It isn't something stupid like 'MD5' ? [06:51] technoweenie: nope... i think something recompiled node or something... [06:55] Tim_Smart: ryah: Did base64 make it into node? [06:59] cataska has joined the channel [07:02] Tim_Smart: gist is broke ;( [07:02] _announcer: Twitter: "@ Zziuni 5 .. Okay ... Soon, even when server hosting nodejs guess heh heh" [ko] -- Kyoungtaek Koo. http://twitter.com/boxersb/status/17314277575 [07:03] technoweenie: is it [07:03] technoweenie: oh crap, hold on. someone put a new feature into master w/ a migration [07:06] technoweenie: back in business [07:06] Tim_Smart: *Hi 5* [07:07] virtuo has joined the channel [07:13] teemow has joined the channel [07:18] SamuraiJack has joined the channel [07:18] mscdex: oh hey, that's my fork! :-D [07:20] tyfighter has joined the channel [07:21] markwubben has joined the channel [07:21] Tim_Smart: mscdex: What chu talkin bout? [07:22] mscdex: technoweenie's socket.io [07:23] technoweenie: ? [07:23] pquerna: anyone around who could help me with a little binding i'm working on? its uh, crashing when i'm trying to make a callback [07:23] pquerna: not seeing why [07:23] technoweenie: mscdex: oh i'm using LearnBoost [07:23] mscdex: the crypto line is from the websockets transport right? [07:24] mscdex: really? :S [07:24] technoweenie: yea [07:24] mscdex: weird [07:24] mscdex: what version? [07:25] benburkert has joined the channel [07:25] technoweenie: the latest i think [07:26] mscdex: and "require('crypto').createHash('md5')" is from lib/socket.io/transports/websocket.js [07:26] mscdex: ? [07:27] technoweenie: yea [07:27] technoweenie: well no, thats from deep in crypto [07:29] ryah: Tim_Smart: no, not yet [07:30] ryah: pquerna: more info? [07:30] pquerna: i figured out what. [07:30] pquerna: http://github.com/pquerna/node-archive/commit/e55116fec1cefc828f461b61754033479ee32ba8 [07:31] pquerna: i was telling it argv[0] was there.. but it was unset [07:31] pquerna: :-/ [07:31] Tim_Smart: Do you know what is hot? Array.prototype.indexOf.call(buffer, char_code); [07:31] felixge has joined the channel [07:31] Tim_Smart: IT WORKS ON BUFFERS :o [07:31] mscdex: hehe [07:33] tyfighter has joined the channel [07:34] ryah: Tim_Smart: crazy [07:34] ryah: Tim_Smart: what if you give it a string? [07:34] ceej has joined the channel [07:35] Aikar has joined the channel [07:35] Tim_Smart: ryah: It works, but you can give the actual character rather than the character code [07:35] Tim_Smart: Rather, _have to_ [07:35] ryah: can you do Array.prototype.indexOf.call(buffer, "\r\n") ? [07:36] Tim_Smart: (index = Array.prototype.indexOf.call(buffer, 13)) && buffer[index + 1] === '\n' [07:36] Tim_Smart: (index = Array.prototype.indexOf.call(buffer, 13)) && buffer[index + 1] === 10 [07:36] Tim_Smart: rather [07:37] Tim_Smart: (index = Array.prototype.indexOf.call(buffer, 13)) > -1 && buffer[index + 1] === 10 [07:37] Tim_Smart: third time lucky [07:40] Tim_Smart: ryah: Seems buffer way is a lot slower than working on normal string [07:40] mape: doesn't it toString them? [07:40] Tim_Smart: mape: Yeah, was seeing if I did have to make the toString call [07:41] Tim_Smart: The Array.prototype stuff is 2x slower than a indexOf on the string representation [07:43] Tim_Smart: But still faster than toString().indexOf() on the buffer [07:43] Tim_Smart: (2x faster) [07:46] Tim_Smart: ryah: You can do: String.prototype.indexOf.call(buffer, '\r\n'); :O [07:47] Tim_Smart: Its slow though... [07:50] dahankzter has joined the channel [07:51] isaacs has joined the channel [07:51] tyfighter has joined the channel [07:54] Tim_Smart: ryah: I wonder what would happen if you made Buffer a instance of Array [07:55] Tim_Smart: If is already very array-like [07:55] Tim_Smart: s/instance/child/ [07:59] dmcquay has joined the channel [07:59] tmpvar: remote: /data/github/current/lib/github.rb:34: undefined method `env' for Rails:Module (NoMethodError) [07:59] tmpvar: -- yikes [07:59] technoweenie: er what? [08:00] halorgium: gerv failing? [08:00] tmpvar: http://gist.github.com/456948 [08:00] technoweenie: nice [08:00] tmpvar: eh, and now im out of sync lol [08:01] dmcquay: hey all [08:01] dmcquay: i've been having a hard time finding a nice way to parse xml [08:01] dmcquay: in JS using node.js [08:01] tmpvar: oh wow [08:01] halorgium: dmcquay: libxmljs? [08:02] tmpvar: im not going to push anymore tonight lol [08:02] tmpvar: github is the broke [08:02] halorgium: tmpvar: corruptz? [08:02] dmcquay: halorgium - looking into that, thx... [08:02] tmpvar: have a good nigh [08:03] dmcquay: halorgium - perfect :) [08:03] tmpvar: night even [08:03] mscdex: i use libxmljs [08:03] mscdex: the push parser is great too :-) [08:03] xla has joined the channel [08:03] mscdex: good for streaming [08:04] xla has joined the channel [08:07] _announcer: Twitter: "@aldusM I've opened a bugtracker for Squeenote, please create a bug with the Node.js error trace :) http://www.bugtails.com/projects/326/" -- Dan Glegg. http://twitter.com/angryamoeba/status/17316934879 [08:17] _announcer: Twitter: "I think node.js has the opportunity to be huge." -- Chris@SocialTexture. http://twitter.com/communicating/status/17317348027 [08:18] MattJ has joined the channel [08:20] technoweenie: well after all the excitement tonight, node is serving downloads for all repos now :) [08:20] felixge has joined the channel [08:20] _announcer: Twitter: "Generate temporary mail aliases for throwaway purposes http://tempalias.com/ node.js and MIT licensed http://github.com/pilif/tempalias" -- jakescott. http://twitter.com/jakescott/status/17317488332 [08:24] mscdex: cool [08:28] BBB has joined the channel [08:29] Tim_Smart: ryah: Where is StringDecoded defined? [08:29] Tim_Smart: *StringDecoder [08:29] Tim_Smart: nvm got it [08:31] _announcer: Twitter: "~ 2000 # amqp roundtrips / s with # node.js node-amqp, and ~ 5000 roundtrips / s with # opposite (still sounds low) ..." [fi] -- kschzt. http://twitter.com/kschzt/status/17317917967 [08:32] N` has joined the channel [08:33] derferman has joined the channel [08:36] caolanm has joined the channel [08:36] TomY has joined the channel [08:36] caolanm: having some problems publishing a package with npm: [08:36] Tim_Smart: Whoa, buffer.slice is A LOT slower than String.prototype.slice [08:36] caolanm: "npm ! TypeError: Cannot call method 'match' of undefined" [08:36] caolanm: anyone else seen that? [08:36] caolanm: I'm running 0.1.17 [08:37] Tim_Smart: Haven't seen that one before, caolanm [08:37] caolanm: :( [08:39] caolanm: ah, looks like I'm running node 0.1.97 on this machine [08:39] caolanm: could be it [08:40] markwubben has joined the channel [08:42] _announcer: Twitter: "@arnaudsj checkout branch http://is.gd/d8CL0, then run `jake`. Then try `node test/console.js` and `firefox test/browser.js`" -- James Coglan. http://twitter.com/jcoglan/status/17318363962 [08:44] ewdafa has joined the channel [08:45] caolanm: nope, that's not it :\ [08:49] cataska has joined the channel [09:01] mAritz has joined the channel [09:01] nsyee has joined the channel [09:03] _announcer: Twitter: "Interesting Real Time Tracker with mongodb and node.js http://icio.us/dkqrws" -- dgAlien. http://twitter.com/dgAlien/status/17319213089 [09:15] caolanm: for anyone that's interested, the problem was caused by an incomplete package.json [09:20] aubergine has joined the channel [09:20] mtodd has joined the channel [09:21] hassox has joined the channel [09:27] mscdex: gah this is driving me up a wall [09:28] mscdex: is there no way to simulate synchronous child processes? [09:29] mscdex: i'm writing a little script to create gzip archives and i need to check the archive's filesize each time i add a file to see if it has surpassed a maximum file size [09:29] mscdex: so order is important [09:30] mscdex: no way to do this sequentially? [09:31] Tim_Smart: mscdex: Do it one after another, with step or parallel. [09:32] Tim_Smart: http://github.com/Tim-Smart/node-parallel or http://github.com/creationix/step <- mscdex [09:33] Tim_Smart: Both on npm [09:33] mscdex: the problem is i need to loop though [09:33] mscdex: n number of times [09:33] mscdex: depending on how many files are being added [09:33] Tim_Smart: Sure. Parallel offers dynamic task generation. [09:34] caolanm: mscdex, I have an async module with forEach, map etc but using async callbacks, if that's any use? [09:34] caolanm: not sure if that applies to your situation [09:36] mscdex: hrm, maybe i can redo some code here to make it work a different way... [09:37] aubergine has joined the channel [09:38] caolanm: mscdex: http://github.com/caolan/async [09:38] Tim_Smart: caolanm: forEach would only work if it preserved order. [09:38] caolanm: forEachSeries then ;) [09:38] caolanm: or async.series [09:39] caolanm: Tim_Smart: the parallel map function etc preserve the order of results, but execute in parallel [09:39] caolanm: I guess thats not what mscdex would want? [09:43] Tim_Smart: I guess it could work for him. I don't think he needs the extra task API's that go along with parallel. [09:44] caolanm: parallel looks well suited to really complex tasks [09:45] mscdex: is there an array size in which doing adding/removing operations causes noticeable performance hits? [09:49] Tim_Smart: mscdex: When you start getting millions of medium sized elements, yes. [09:49] mscdex: ah ok [09:49] Tim_Smart: Actually, it should affect pop, push, shift etc. much. [09:49] Tim_Smart: *shouldn't [09:49] mscdex: yeah, i was hoping it wouldn't since that's what i'm specifically wondering about [09:53] mscdex: oh well, enough of this for now. [09:54] mscdex: i shouldn't even be up at this hour [09:54] mape: When doing node modules, and I have dependencies, should I just checkout those git repos in the lib folder and have git figure out they are external? [09:54] mape: Or should I make stale copies.. [09:55] _announcer: Twitter: "@cloudhead awesome work on vowsjs - not sure which is more impressive, the library or the home page! You are l33t. #nodejs" -- Tim Hastings. http://twitter.com/timhastings/status/17321286966 [09:57] mscdex: i personally dislike git submodules because github doesn't automatically include them in tarballs [09:58] mscdex: but it does keep deps fresher [09:58] mscdex: guess it all boils down to how often the deps change and how often you need/want to update the stale copies [10:01] lianj has joined the channel [10:04] aubergine has joined the channel [10:09] fermion has joined the channel [10:14] maushu has joined the channel [10:17] keyvan has joined the channel [10:20] findyourownpath_ has joined the channel [10:22] aubergine_ has joined the channel [10:26] Tim_Smart: ryah: ping [10:31] shimondoodkin has joined the channel [10:36] shimondoodkin: how would you save an erd diagram in a n accesoble way in a javascript object [10:37] shimondoodkin: *accessible [10:40] shimondoodkin: i need to save table's children and parents some how, before i run application generator on it. [10:41] shimondoodkin: http://github.com/shimondoodkin/nodejs-mongodb-app/blob/master/module_mainpage.js [10:46] pandark_ has joined the channel [10:47] maushu: Wait, what happened to multipart. [10:48] maushu: Found it. [10:48] _announcer: Twitter: "my brain is not compatible with nodejs and callback things today... >__<" -- Nugroho Herucahyono. http://twitter.com/xinuc/status/17323519152 [10:51] aubergine has joined the channel [10:52] botanicus has joined the channel [10:55] cloudhead has joined the channel [10:56] khug has joined the channel [11:01] hellp has joined the channel [11:03] hellp has joined the channel [11:03] mpoz2 has joined the channel [11:03] keyvan has joined the channel [11:04] kodisha has joined the channel [11:08] _announcer: Twitter: "#vowsjs asynchronous behavior driven development framework for #Node.js http://vowsjs.org/" -- gdzine net. http://twitter.com/gdzinenet/status/17324388315 [11:09] _announcer: Twitter: "Get yourself a throw away, anonymous email alias with Tempalias - http://tempalias.com/#/ #iHateSpam #nodejs" -- Darren Newton. http://twitter.com/d_run/status/17324444020 [11:12] _announcer: Twitter: "people using node.js on heroku - happy with that?" -- Robert Brook. http://twitter.com/robertbrook/status/17324583213 [11:17] mies has joined the channel [11:17] mklappstuhl has joined the channel [11:20] mies has joined the channel [11:21] dabreaka has joined the channel [11:25] _announcer: Twitter: "Kayak HTTP seems to be built on the same architectural foundation as Node.js. Sweet." -- Bjarte Djuvik Næss. http://twitter.com/bjartn/status/17325092695 [11:29] blackdog_ has joined the channel [11:33] marshall_law has joined the channel [11:51] SvenDowideit_ has joined the channel [11:51] aubergine has joined the channel [12:00] tav has joined the channel [12:05] _announcer: Twitter: "thanks to @littleidea, i've discovered that my mother is nodejs" -- Denny Abraham. http://twitter.com/dennyabraham/status/17327122564 [12:09] botanicus has joined the channel [12:22] maqr has joined the channel [12:32] khug has joined the channel [12:32] javajunky has joined the channel [12:37] Tim_Smart: github is broke ;( [12:40] ewdafa has joined the channel [12:41] caolanm: Tim_Smart: your winky-sad-face confuses me [12:41] caolanm: but yes, github is broke [12:41] caolanm: ... ;( [12:42] Tim_Smart: Its me having a cry, that my life blood is being sucked from me. [12:44] javajunky: its intermittent fwiw, if you refresh you get back in , for every action ;) [12:45] JimBastard has joined the channel [12:45] JimBastard: zzzz [12:45] Tim_Smart: Yeah, intermittent is the name of the game. [12:47] kriszyp_afk has joined the channel [12:48] _announcer: Twitter: "Asked about the BDD for Chang organized to test for fans Node.js http://bit.ly/dzo94q." [th] -- Neung Poowanai. http://twitter.com/taneung/status/17329566847 [12:48] mw has joined the channel [12:48] mjijackson has joined the channel [12:51] aubergine has joined the channel [12:53] _announcer: Twitter: "Their own writing with node.js static file server, and Apache ratio, req / s to 4 times, response time is 30%, 50% memory usage, chaos and nginx open threads ...... but still can not compare a = _, =" [zh-CN] -- aki. http://twitter.com/aki_xavier/status/17329902657 [12:54] b_erb has joined the channel [12:54] _announcer: Twitter: "damn headache.. I've just made NodeJS Addon(C++) for DICOM PACS QR server. Version# is 0.01 :-) Too far to finish this code ,," -- A.J. http://twitter.com/andrwj/status/17329945453 [12:58] mAritz has joined the channel [13:01] zomgbie has joined the channel [13:02] mies has joined the channel [13:02] phiggins has joined the channel [13:02] maushu: Hmmm. I need a server naming scheme. [13:03] gerad has joined the channel [13:03] davidsklar has joined the channel [13:06] Tim_Smart: JimBastard: http://gist.github.com/457178 [13:07] mAritz has joined the channel [13:08] phiggins has joined the channel [13:12] mape: JimBastard: http://nodejs.se/ semi-has-api, stale data though, need to make it live/realtime dealy [13:12] mjijackson has left the channel [13:16] maqr has joined the channel [13:16] malkomalko has joined the channel [13:18] bpot has joined the channel [13:18] khug has joined the channel [13:21] maqr has joined the channel [13:21] Tim_Smart: Wow I have made over 4000 messages :/ [13:21] shimondoodkin: i'm even not on the list :P [13:22] mtodd has joined the channel [13:23] Clooth has joined the channel [13:23] shimondoodkin: the days ago is old [13:25] mape: shimondoodkin: ^ ", stale data though, need to make it live/realtime dealy" [13:26] Tim_Smart: socket.io :) [13:26] mape: node-irc works fine [13:26] Tim_Smart: mape: I can quickly make up a server for you, will be easy [13:26] shimondoodkin: the simple way is http client and write file and rerun [13:27] Tim_Smart: (The streaming side that is, you do the persistence stuff) [13:27] mape: not really, easier to fetch log and then start doing real live calculations [13:27] shimondoodkin: the more complicated way is irc client to do the stats in real time [13:28] mape: Not at all, its like 20 lines of coe [13:28] mape: *code [13:28] Tim_Smart: shimondoodkin: Err, huh? For streaming you just use a pre-made irc client (which uses the TCP protocol) [13:28] mape: just have to do it [13:28] Tim_Smart: + socket.io [13:28] mape: or node-irc :) [13:28] shimondoodkin: for real tme to browser it might be socket io [13:29] Tim_Smart: mape: I usually use my irc bot framework as a irc client [13:29] Tim_Smart: But take your pick I guess [13:29] mape: oh you are talking clientside? [13:29] shimondoodkin: ther realtime in browser is like an odd future [13:29] Tim_Smart: mape: No, in a node.js process [13:29] mape: It won't be realtime to the browser [13:29] Tim_Smart: mape: Oh, why not? :p [13:29] mape: If you feel like you are up to it please do :) [13:30] Tim_Smart: Well put your current server in a gist, and I'll amend it. [13:30] mape: I'll do some cleanup and post the gist when I get home from work [13:31] Tim_Smart: OK no problem. Probably better if you tar it, and send it to Tim-Smart on github as a link [13:31] mape: k [13:32] pkrumins: socket.io is the best thing ever. [13:32] tmedema has joined the channel [13:32] liucougar has joined the channel [13:32] Tim_Smart: The code is a little crude, but it works well [13:34] mape: I actually never got it working [13:34] mape: had issues with the flash thingymado [13:34] jherdman has joined the channel [13:40] mtodd has joined the channel [13:45] maushu: JimBastard: You talk too much. [13:45] creationix has joined the channel [13:45] [[zz]] has joined the channel [13:48] davidwalsh has joined the channel [13:50] kersny has joined the channel [13:51] creationix has joined the channel [13:52] tzmartin has joined the channel [13:52] softdrink has joined the channel [13:52] markwubben has joined the channel [13:53] femto has joined the channel [13:55] xircweb has joined the channel [13:59] BBBB has joined the channel [14:01] gf3 has joined the channel [14:03] mjijackson has joined the channel [14:05] stepheneb has joined the channel [14:05] markwubben_ has joined the channel [14:05] jlilly has joined the channel [14:05] markwubben_ has joined the channel [14:10] zaach has joined the channel [14:11] sanderjd has joined the channel [14:12] sanderjd has left the channel [14:12] jashkenas has joined the channel [14:13] voodootikigod_ has joined the channel [14:13] voodootikigod_: express nerds [14:13] voodootikigod_: you awake? [14:14] steadicat has joined the channel [14:14] stagas has joined the channel [14:18] javajunky: meh [14:20] liucougar has joined the channel [14:23] paul____ has joined the channel [14:23] _announcer: Twitter: "@bennadel @reybango Agreed. Feels more suited as a framework level convenience than a CommonJS standard to me. #nodejs seems to agree, fwiw" -- Jeremy Martin. http://twitter.com/jmar777/status/17336162105 [14:28] _announcer: Twitter: "@bennadel @reybango In support of my #nodejs claim: http://j.mp/8ZhX26 and http://j.mp/bWnobv" -- Jeremy Martin. http://twitter.com/jmar777/status/17336484885 [14:28] ewdafa has joined the channel [14:31] paul____ has joined the channel [14:32] _announcer: Twitter: "@jaycrossler Do you like js as much as I do? I've been working with node.js, a server-side javascript environment." -- Scott Newman. http://twitter.com/greencoder/status/17336779485 [14:32] khug has joined the channel [14:32] bradleymeck_ has joined the channel [14:34] pgriess has joined the channel [14:36] nsm has joined the channel [14:38] _announcer: Twitter: "MVC.js gets session management with pluggable session stores. http://is.gd/d8Sax #mvcjs #nodejs" -- Chandra Sekar. http://twitter.com/tuxychandru/status/17337214186 [14:38] JimBastard_ has joined the channel [14:38] x_or has joined the channel [14:39] x_or: Anyone know how to fix this? "WARNING: SSL not supported in your version of node JS" [14:39] malkomalko: are you using restler x_or? [14:39] x_or: I am using nvm, and went into the directory where nvm cached the source. [14:39] x_or: malkomalko: Yes, I am. [14:39] malkomalko: and that's when your getting the message right? [14:39] x_or: Yep, indeed. You are quite good! [14:40] malkomalko: restler is a bit out of date with the newest version of node [14:40] x_or: Oh, OK. Drat. [14:40] x_or: I like the restler interface, and am not aware of another library that allows easy posting. [14:41] x_or: Is there something else? I tried with the basic httpClient, but got some strange crashes too. [14:41] x_or: Perhaps I should downgrade to an older version of node? [14:41] malkomalko: it's ok [14:41] malkomalko: just update restler [14:41] mjr_: x_or: I'll bet you could fix restler pretty easily. [14:41] malkomalko: I'll tell you what to change [14:41] malkomalko: line 78 [14:41] malkomalko: http.createClient(port, host) [14:41] malkomalko: make that http.createClient(port, host, true) [14:41] malkomalko: then just comment out this._applySSL(); around 41 [14:42] malkomalko: I'll make a fork later on github [14:42] x_or: Awesome, trying it now. [14:43] malkomalko: ok, let me know if it works [14:43] x_or: Now my code is crashing, this is an improvement! Thanks so much. It makes the request at least. [14:43] malkomalko: :) [14:45] sveisvei has joined the channel [14:45] malkomalko: I'm trying to figure out how to make soap requests using a wsdl with restler, so I needed to update that bit of code just the other day [14:46] x_or: It is a nice looking library. [14:46] x_or: I'm building a client for RPX, openid login, which requires https. [14:46] malkomalko: yah, it's straightforward [14:51] Yuffster has joined the channel [14:51] x_or has joined the channel [14:52] ajpiano has joined the channel [15:00] Ori_P has joined the channel [15:00] bradleymeck_: /nick bradleymeck [15:00] bradleymeck_: now that is odd [15:02] jakehow has joined the channel [15:03] tlrobinson_ has joined the channel [15:03] jetienne has joined the channel [15:06] Tim_Smart: !track #worldcup [15:07] Tim_Smart: Whoops wrong channel [15:09] sanderjd has joined the channel [15:09] jlilly has left the channel [15:11] khug has joined the channel [15:12] _announcer: Twitter: "Creating an HTML5 Websocket server with NodeJS & testing ♥...." -- François-G. Ribreau. http://twitter.com/FGRibreau/status/17339685050 [15:12] MattJ has joined the channel [15:17] _announcer: Twitter: "great !! RT@ tuxychandru MVC.js gets session management with pluggable session stores. http://is.gd/d8Sax #mvcjs #nodejs" -- Abhilshit Soni. http://twitter.com/abhilshit/status/17340115755 [15:24] mtodd has joined the channel [15:26] flipsasser has joined the channel [15:26] tjholowaychuk has joined the channel [15:28] mostlygeek has joined the channel [15:28] sanderjd has joined the channel [15:28] sanderjd has left the channel [15:28] kodisha has joined the channel [15:29] felixge has joined the channel [15:29] felixge has joined the channel [15:30] felixge: ryah: It seems that node closes an incoming 'CONNECT' http requests if it sends a body after the initial handshake [15:31] felixge: ryah: trying to figure out how/where that is happening, any pointers? [15:32] kodisha has joined the channel [15:32] mattly has joined the channel [15:36] khug has joined the channel [15:36] sudoer has joined the channel [15:40] steadicat has joined the channel [15:42] mjr_: felixge: in the http parser, isn't connect a special case like upgrade? [15:43] justatwitterbot has joined the channel [15:44] Tim_Smart: !track javascript [15:44] justatwitterbot: Tim_Smart: Started tracking: javascript [15:45] justatwitterbot: TWITTER: ""Refact your C#Code: JsMeter" by @salvadorgascon #javascript #tools #tech http://j.mp/byI8hD" -- Naveen Lagadapati http://twitter.com/navin_l/status/17342148797 [15:45] justatwitterbot: TWITTER: ""Refact your C#Code: JsMeter" by @salvadorgascon #javascript #tools #tech http://j.mp/byI8hD" -- Naveen Lagadapati http://twitter.com/navin_l/status/17342148797 [15:45] felixge: mjr_: it seems like it's not handled as a special case yet [15:45] justatwitterbot: TWITTER: "Anybody used Event Spy Firefox add-on? http://bit.ly/am7qpN I need to find out which JavaScript event got fired. Have another tool?" -- Željko Filipin http://twitter.com/zeljkofilipin/status/17342200787 [15:45] justatwitterbot: TWITTER: "Anybody used Event Spy Firefox add-on? http://bit.ly/am7qpN I need to find out which JavaScript event got fired. Have another tool?" -- Željko Filipin http://twitter.com/zeljkofilipin/status/17342200787 [15:45] Tim_Smart: !untrack javascript [15:45] justatwitterbot: Tim_Smart: Stopped tracking: javascript [15:46] flipsasser has left the channel [15:49] felixge: Tim_Smart: you kids and your twitter bots [15:49] felixge: :) [15:49] Tim_Smart: :p [15:51] tjholowaychuk: felixge: jjuuuuust about to check out node-formidable :) [15:52] Tim_Smart: felixge: I got it running in ##botwar against the topic 'worldcup' haha [15:54] aubergine has joined the channel [16:00] felixge: tjholowaychuk: cool : ) [16:00] felixge: tjholowaychuk: are you thinking about integrating it into express? [16:01] tjholowaychuk: felixge: actually Connect as a contrib middleware, which express will be built on anyway so kinda yup [16:01] felixge: tjholowaychuk: sweet, let me know if you hit any problems! : ) [16:01] tjholowaychuk: will do! [16:01] indiefan has joined the channel [16:05] tjholowaychuk: multipart is kinda stupid [16:06] creationix has joined the channel [16:06] gf3: NO U [16:06] tjholowaychuk: haha [16:08] felixge: tjholowaychuk: why? [16:08] gf3: !track penis // amirite? [16:08] tjholowaychuk: felixge: just seems like a huge hack, just writing some tests for this before I implement and i forgot a few --- haha [16:08] khug has joined the channel [16:08] tjholowaychuk: an understandable hack but still a hack [16:10] felixge: tjholowaychuk: well, I think it's a poor format choice for file uploads, but generally otherwise it doesn't seem like a bad envelop for other stuff [16:10] felixge: wow, my english is degrading rapidly :) [16:10] felixge: too much code for today [16:10] malkomal_ has joined the channel [16:10] felixge: ttyl [16:10] tjholowaychuk: haha dont worry mine is brutal all the time [16:10] tjholowaychuk: later [16:11] _announcer: Twitter: "RingoJS vs NodeJS: http://bit.ly/9cKsXw" [lv] -- Boxed Ice. http://twitter.com/boxedice/status/17344056723 [16:13] caolanm: tjholowaychuk: node-formidable would be awesome as connect middleware... +1 ! [16:13] caolanm: then I only have to integrate my form helpers with connect [16:14] caolanm: was just wondering how to support both ;) [16:14] tjholowaychuk: yeah man, looks like a solid implementation. We cant really have third party stuff bundled in but it will be a contrib module [16:14] caolanm: yeah, makes sense [16:14] _announcer: Twitter: "@davidmytton Are you using Node.js for any Boxed Ice stuff?" -- Rik Lomas. http://twitter.com/riklomas/status/17344354716 [16:15] utgo has joined the channel [16:16] caolanm: tjholowaychuk: you live in BC right? [16:16] tjholowaychuk: yup [16:16] tjholowaychuk: victoria [16:17] caolanm: ah cool, I've just booked flights to vancouver over christmas [16:17] tjholowaychuk: nice! [16:17] caolanm: is victoria worth a visit? [16:17] caolanm: I don't really know much about BC [16:17] tjholowaychuk: its probably the nicest place in canada [16:17] tjholowaychuk: which does not say much haha... but i guess it depends what you like [16:17] caolanm: haha [16:18] isaacs has joined the channel [16:18] caolanm: cool, I shall have to investigate [16:18] caolanm: although since I'm a brit I always assume everything is no more than an hour or two away [16:18] caolanm: turns out that's not the case in canada ;) [16:20] kodisha_ has joined the channel [16:20] _announcer: Twitter: "@greencoder Yeah, JS is my favorite language. I'll check node.js out" -- Jay Crossler. http://twitter.com/jaycrossler/status/17344740769 [16:23] creationix: caolanm: yeah, Texas alone is twice the size of Germany [16:24] creationix: (not canada or uk, but still interesting) [16:24] mklappstuhl: in felixge's paperboy: is there a way to supress 304 ? [16:24] jashkenas has left the channel [16:24] mklappstuhl: i tried to send empty ETags with [16:25] mklappstuhl: .addHeader('ETag', '""') [16:25] isaacs: caolanm: yeah, america is about the same surface area of Europe [16:25] sh1mmer has joined the channel [16:26] isaacs: caolanm: only about half the population, though. there are a lot more empty bits. [16:26] mklappstuhl: but that didn't work as expected. there is still an etag, and therefore 304 [16:27] isaacs: mklappstuhl: why do you need to suppress the 304? [16:27] isaacs: mklappstuhl: i mean, isn't that up to the client to tell you what it has in cache? [16:28] siculars has joined the channel [16:30] tzmartin has joined the channel [16:31] mklappstuhl: isaacs: i dont want caching at all ... and i though by disabling ETags i could suppress it [16:31] peburrows has joined the channel [16:32] isaacs: mklappstuhl: no, you need to use the other cache control headers. [16:32] isaacs: mklappstuhl: if you don't want caching *at all*, that is [16:32] isaacs: mklappstuhl: sometimes browsers won't even request the thing, becasue they have it in cache [16:33] isaacs: mklappstuhl: if you want to suppress caching, you probably don't want to use paperboy. it's designed to be optimally cacheable by obeying the rules of the HTTP spec wrt modified and etags, i believe. [16:36] findyourownpath has joined the channel [16:36] marshall_law has joined the channel [16:40] khug has joined the channel [16:40] holydevil has joined the channel [16:41] JimBastard_: bradleymeck: what happened to the util bot? [16:41] JimBastard_: do you need hosting for him? [16:41] JimBastard_: i wanna yell at people on twitter [16:43] WALoeIII has joined the channel [16:43] khug has joined the channel [16:47] [[zz]] has joined the channel [16:47] creationix: JimBastard: you still have real twitter [16:47] creationix: just not as cool I guess [16:48] marshall_law_ has joined the channel [16:51] marshall_law has joined the channel [16:54] JimBastard_: creationix: i dont know how to use that [16:54] skampler: ryah: i might write a dns server in node :P [16:54] JimBastard_: for some reason i can only use twitter through 3rd party apps or when i want to announce one of my projects [16:54] JimBastard_: its strange [16:54] JimBastard_: skampler: replace BIND, do it [16:54] JimBastard_: please [16:55] JimBastard_: i need a DNS server is node [16:55] skampler: there's http://github.com/skampler/node-dnscache [16:55] skampler: need some more work on that, though [16:56] stepheneb has joined the channel [16:56] kodisha_ has joined the channel [16:57] rauchg_ has joined the channel [16:59] tlrobinson_ has joined the channel [16:59] mikeal: creationix: so, last night i finished the parser in my old db project i told you about [17:00] mikeal: eventually I'm going to convert it in to a branch of nstore [17:00] mikeal: i want to make the API identical with a different parser so that we can support Buffers and values [17:00] _announcer: Twitter: "@disktree http://groups.google.com/group/haxe-nodejs" -- BlackDog. http://twitter.com/blackdog66/status/17348341939 [17:00] mikeal: Buffers as values [17:02] skampler: do you say written in node or written with node? [17:06] mjr_: JimBastard: why do you need a DNS server in node? [17:06] mjr_: JimBastard: for recursive queries or for authoritative? [17:06] Connorhd has joined the channel [17:06] mies has joined the channel [17:07] khug has joined the channel [17:10] creationix: mikeal: sounds cool [17:10] JimBastard_: mjr_: ummmm i think authorititive [17:10] creationix: so we'll have the same api, but you're will have a different file format? [17:11] mikeal: yeah [17:11] JimBastard_: but until i link up with rackspace some more its all moot anyway [17:11] mikeal: it's using headers a bit more so that we can support buffers [17:11] mikeal: but it's still really simple because i'm doing the same meta JSON object [17:11] JimBastard_: im months away from DNS for sure [17:12] bpot has joined the channel [17:13] bradleymeck: JimBastard_ hes down due to some portage, can bring up the new kid but he doesnt have permissions so voice for all [17:14] creationix: mikeal: so what goes in meta other than the key [17:14] creationix: I'm still fuzzy on that one [17:14] creationix: just stuff you want cached in ram or is there a line based on the use of the data [17:16] technoweenie has joined the channel [17:17] mikeal: creationix: right, stuff you want cached in memory mostly [17:17] mikeal: once i support buffers [17:17] mikeal: we'll also want a "type" attribute or something so that we know whether or not we should try to convert via JSON [17:17] _utility has joined the channel [17:17] creationix: mikeal: seems there is a difference between meta data and cached data [17:18] bradleymeck: yea... gonna need to find a host that will restart him if he fails [17:18] mikeal: eventually we'll want to stream values to seperate files so that we can stream to a set of append only files for big binary values [17:18] mikeal: so we'll also need the filename in there [17:19] creationix: yeah, key, type, filename, that's all meta [17:19] creationix: I'm just not sure I want to put in stuff like cached fields in there too [17:19] mikeal: well, if you don't need it in memory, it should be in the value :) [17:20] maqr has joined the channel [17:20] mikeal: i mean, if it wasn't *called* meta i don't think you would feel like it didn't fit :) [17:20] creationix: well, I was thinking about letting the user specify application-level fields as cachable too [17:21] benburkert has joined the channel [17:21] mklappstuhl: isaacs: what would you use? and which header fields would i need to set to disable caching [17:21] mikeal: how is Zappos already delivering something i ordered last night! [17:21] isaacs: mklappstuhl: cache-control:private, i believe [17:22] mikeal: creationix: right, but that's probably just a good API for adding stuff to meta without the user mucking around with meta [17:22] isaacs: mikeal: dude, i'm telling you, they have TIME MACHINES!! [17:22] mikeal: i kind of understand why amazon bought them now [17:22] creationix: mikeal: ok, so maybe in a sub field of meta called cache or something [17:22] isaacs: mikeal: like, two guys invented a time machine, and they looked to eachother, and they were like "Are you thinking what I'M thinking!!?" and then they were both like, "I KNOW RIGHT!? We could deliver shoes SO FAST with this thing!!!!" [17:22] mikeal: if amazon use this time machine tech on a larger scale, it would be awesome! [17:23] mikeal: creationix: sure [17:23] isaacs: mikeal: i just worry that amazon will let its corporate greed get the better of it, and use it for evil, and thus destroy the entire universe. [17:23] mikeal: creationix: the thing is, i could totally see wanted the other meta info in a big filter or map function [17:24] tjholowaychuk: isaacs: any reason `npm install .` and `npm list @active` show the lib, but its not in ~/.node_libraries [17:24] tjholowaychuk: ? [17:24] mikeal: the size, key, type, are all important for stuff like that [17:24] isaacs: like, go back in time and twist fates so that lisp never had a chance, and some ugly hybrid pidgin language becomes the lingua franca of the web... [17:24] isaacs: OH NO!! they already did it!! [17:24] creationix: mikeal: true, I guess it's ok to mix it all together [17:24] creationix: just let the user specify custom meta fields [17:24] creationix: I'm already exposing the raw meta to all the api functions [17:24] isaacs: tjholowaychuk: what's "npm config get root" [17:24] mikeal: yeah [17:24] mikeal: i'll try to get this finished up today [17:25] tjholowaychuk: isaacs: its ~/.node_libraries [17:25] mikeal: i don't know if i will tho, i've got a lot of work to do on IDBCouch todya [17:25] tjholowaychuk: hmm [17:25] maqr has joined the channel [17:25] isaacs: tjholowaychuk: does it have a "main" property? [17:25] isaacs: tjholowaychuk: what's the lib? [17:25] tjholowaychuk: yeah I have ./index.js as the "main" [17:25] creationix: mikeal: so how does map-reduce work when the callback itself needs to be async [17:25] tjholowaychuk: its not published it [17:25] tjholowaychuk: yet [17:26] mikeal: i don't know what you mean, example? [17:26] creationix: mikeal: so a normal js map or filter takes a callback that "returns" the new value [17:26] admc has joined the channel [17:26] admc_ has joined the channel [17:26] creationix: what if I can't return, but need to pass the value in a callback [17:27] mikeal: i don't see why you would want to do that [17:27] creationix: "joins" [17:27] isaacs: tjholowaychuk: is it on github? or not even published in that way? [17:27] mikeal: so, that's a reduce phase or secondary map phase [17:27] mikeal: map and reduce functions defined by a user should be like event listeners, they should only block on processing [17:27] tjholowaychuk: isaacs: just pushed to http://github.com/visionmedia/connect-form [17:28] tjholowaychuk: isaacs: just sucks a bit with npm until you know what it wants because you cant delete it you have to keep bumping the version haha [17:28] isaacs: tjholowaychuk: you can unpublish [17:28] mikeal: you don't want to have them take a callback and do other IO and screw it all up and never have the maps return [17:28] isaacs: tjholowaychuk: npm unpublish foo 0.0.1 [17:29] tjholowaychuk: isaacs: oh :) [17:29] isaacs: tjholowaychuk: yeah, that's a pretty new feature. [17:29] mikeal: what you probably want is a map/filter [17:29] teemow has joined the channel [17:29] isaacs: tjholowaychuk: eventually it might be a bit more locked down, but it's a free for all hippie love fest still. [17:29] isaacs: publish, unpublish, whatever. [17:29] mikeal: take the entire result set from the map phase and pass to a single filter function [17:29] mikeal: the map phase gets everything in the db, so if you want to join you just need to pass all the thing that might be joined to the filter out of the map phase [17:29] isaacs: tjholowaychuk: you should put "connect" in the dependencies [17:30] isaacs: tjholowaychuk: { "dependencies" : { "connect" : "*" } } [17:30] maqr has joined the channel [17:30] jlilly has joined the channel [17:31] tjholowaychuk: isaacs: done. even though I would imagine you wont seek out connect-* unless you have connect installed anyways [17:31] isaacs: tjholowaychuk: true that [17:31] isaacs: $ ls ~/.node_libraries | grep connect [17:31] isaacs: connect [17:31] isaacs: connect-0.1.0 [17:31] isaacs: connect-form-0.0.1.js [17:31] isaacs: connect-form.js [17:32] tzmartin has joined the channel [17:32] isaacs: tjholowaychuk: works for me? [17:32] tjholowaychuk: hmm one sec ill rm and install again [17:32] marshall_law has joined the channel [17:33] tjholowaychuk: weird yeah works now [17:33] isaacs: tjholowaychuk: it knew i was looking. npm fears me. [17:33] tjholowaychuk: hahah [17:33] tjholowaychuk: damn straight [17:33] saikat has joined the channel [17:34] qFox has joined the channel [17:34] tjholowaychuk: isaacs: so formidable dep I can just do "formidable": ">= 0.9.3" ? [17:34] isaacs: tjholowaychuk: that should work, yeah [17:34] tjholowaychuk: k ill try that out [17:34] isaacs: in the dependencies hash [17:36] femto has joined the channel [17:36] femto: Yo momma so fat, when she used sizeof she overflowed an int64. [17:36] tjholowaychuk: isaacs: i get Error: Tag * not found for package connect for `npm install .` [17:37] tjholowaychuk: suppose i should chuck >= 0.1.0 in there [17:37] isaacs: tjholowaychuk: oh, that's weird. i think you might've found another semver regression. [17:37] isaacs: * should just be "any version allowed" [17:38] isaacs: yep. that's a bug. [17:39] isaacs: tjholowaychuk: just "connect" : "" should work the same [17:39] tjholowaychuk: sounds good [17:39] felixge has joined the channel [17:40] isaacs: ahh, is ee it. [17:40] isaacs: i was testing for !range rahter than range !== null [17:40] isaacs: and "*" is a range that gets shortened to just "" [17:40] isaacs: and !"" === true [17:41] liucougar has joined the channel [17:41] rauchg_: creationix: what time is the meetup tomorrow [17:41] creationix: rauchg_: same as last time, I think it started at 7pm [17:41] creationix: does anyone remember? [17:41] rauchg_: k [17:41] isaacs: creationix: i think it was 6, but 7 is better for me [17:42] aconran__: rauchg_, you back in town? [17:42] creationix: we wanted it to work for the people driving down from the city [17:42] rauchg_: aconran__: yes [17:42] rauchg_: =] [17:42] aconran__: rauchg_, Nice! for good? [17:42] creationix: well last time ended up being from about 5:30-12:00 I seem to remember [17:42] creationix: with people showing up as late as 7:30 [17:43] rauchg_: aconran__: looks like it [17:43] aconran__: rauchg_, grats :) [17:43] rauchg_: creationix: this one will be from 7 to 4am [17:43] rauchg_: i'm dying to try sencha touch [17:43] creationix: sweet, 4am is about the time I was going to bed in sweden (of course I was jetlagged there) [17:45] stevendavie has joined the channel [17:45] gerad has joined the channel [17:45] _announcer: Twitter: "urlencoded / multipart form parsing middleware to Connect # nodejs http://bit.ly/aq2qqP" [da] -- TJ Holowaychuk. http://twitter.com/tjholowaychuk/status/17351311701 [17:46] JimBastard_: fuuuuuuuuuuck [17:46] JimBastard_: why must require() be syncronous [17:46] ryah: JimBastard_: ? [17:46] creationix: JimBastard_: cause it's easier, remember [17:47] JimBastard_: as in, fuuuuuck how the hell am i gonna mimic this in the browser [17:47] creationix: it's got an async version [17:47] isaacs: creationix: yeah, but it is wonky. [17:47] isaacs: creationix: mixing sync and async require is nono [17:47] JimBastard_: ryah: its almost impossible for me to get node.js code to run in the browser without modification [17:47] isaacs: JimBastard: nodules? [17:47] JimBastard_: require() makes it really hard [17:47] ryah: JimBastard_: statically compile them into one script [17:47] rauchg_: transports [17:47] JimBastard_: i pretty much have to preload all my required files before require() is ever called [17:47] isaacs: JimBastard: yes, exactly [17:47] JimBastard_: ryah: then i have to know them all ahead of time [17:48] JimBastard_: i can do async loading, thats easy [17:48] JimBastard_: id rather just require('./toplevel') and have it all be magic [17:48] JimBastard_: instead i have to list out all the files, which could be a lot [17:48] tjholowaychuk: JimBastard_: you could scan the body for require()s, load them all async and eval the script when its done lol [17:48] tjholowaychuk: i dont know [17:48] richcollins has joined the channel [17:49] JimBastard_: tjholowaychuk: im refusing to use static code analysis for this [17:49] JimBastard_: at least this month >.< [17:49] tjholowaychuk: haha :D [17:49] mtodd has joined the channel [17:49] JimBastard_: but yes, thats been brought up a few times actually [17:49] JimBastard_: anything is POSSIBLE with toString() + regex + eval() its just ugly [17:49] JimBastard_: as fragile [17:49] gerad1 has joined the channel [17:49] JimBastard_: lots of edge cases, people call require a few ways [17:50] tjholowaychuk: for sure, im not suggesting you actually do that [17:50] creationix: JimBastard_: if you want it to work like node, there is always sync xhr, but don't do that [17:50] JimBastard_: >.< [17:50] JimBastard_: ive been thinking hard on this for a while [17:50] tjholowaychuk: ACTION is out of coffee... fuck [17:50] creationix: tjholowaychuk: we got good stuff in the office [17:50] creationix: (well, so I've been told, I don't drink it) [17:51] JimBastard_: creationix: im not sure thats a real option either [17:51] creationix: JimBastard_: why not write your code using async require? [17:51] JimBastard_: creationix: im trying to author a library, not solve a specific problem [17:51] tjholowaychuk: shit, async require breaks in repl [17:51] tjholowaychuk: oh wait now it doesnt [17:51] tjholowaychuk: haha [17:51] tjholowaychuk: magic [17:51] JimBastard_: i want to be like, ohh here is a node.js app, lets include gemini.js and run that bitch in the browser [17:52] _announcer: Twitter: "i don't know what it is but i call it nice docs: http://vowsjs.org/ #nodejs" -- Dylan Clendenin. http://twitter.com/deepthawtz/status/17351681908 [17:52] JimBastard_: im pretty close to imo [17:52] JimBastard_: and ive got a few great projects to use as demos [17:53] JimBastard_: i think im going to have to settle on this one, and just have people list their requirements first [17:53] aubergine has joined the channel [17:53] JimBastard_: there is a tool in RequireJS to do this, so if someone has a huge list they can automate i guess [17:53] JimBastard_: ugh i hate taking half-steps, there ain't no half-stepping! fuuuuuuuu [17:54] jlilly has joined the channel [17:54] softdrink: unless you're playing with a stepper motor. ¬¬ [17:55] JimBastard_: dont make me recycle you [17:55] x_or has joined the channel [17:56] softdrink: ACTION effervesces [17:58] joshowens has joined the channel [17:59] zomgbie has joined the channel [18:01] gerad has joined the channel [18:01] mscdex: trying to make child processes synchronous is tricky heh [18:02] creationix: mscdex: I though it was? [18:02] creationix: creating it atleast [18:02] mscdex: ? [18:02] technoweenie: mm no dont think so [18:02] technoweenie: oh creating, maybe [18:02] Wandrewvious has joined the channel [18:02] JimBastard_: mscdex: lolwut [18:02] creationix: since it's just setting up some streams [18:03] bradleymeck: anyone know if Element.insertBefore(DocumentFragment,Node) is supposed to be transactional (ie. one of the childNodes fails due to being readOnly... where is tmpvar when i need him to argue specs) [18:03] mscdex: i have processes where one depends on the previous [18:03] siculars has joined the channel [18:03] mscdex: like the result of the previous process [18:03] JimBastard_: ACTION casts summon tmpvar lvl 18 [18:03] creationix: mscdex: are you wanting to make it true blocking or just run in order? [18:03] mscdex: true blocking would be nice [18:03] mscdex: i dunno [18:03] technoweenie: that's very anti-node [18:04] JimBastard_: blocking is for fags [18:04] mscdex: i know, but i'm just writing a utility script [18:04] mscdex: it's not sockets or anything [18:04] technoweenie: use another language then :) [18:04] bradleymeck: well, why do you need it to block is a better question [18:04] mscdex: i'm about to, but i like js [18:04] JimBastard_: mscdex: been down that road >.< [18:04] technoweenie: bradleymeck: i think just for convenience [18:04] mscdex: not for convenience [18:05] mscdex: it's not really possible for what i'm trying to do in node with this unless it's synch [18:05] scott_gonzalez has joined the channel [18:05] creationix: mscdex: actually my recent experience is that blocking IO is much slower, even in utility scripts where there isn't a lot of concurrency [18:05] JimBastard_: bradleymeck: my summon spell failed, tmpvar might be by later this afternoon [18:05] JimBastard_: in an hour or two [18:05] JimBastard_: maybe 30 mins [18:05] creationix: mscdex: serial actions don't require blocking io [18:05] JimBastard_: im pretty sure hes stuck in java land [18:05] technoweenie: mscdex: then you'd just need a bunch of nested commands [18:06] creationix: mscdex: have you used Step or node-promise? [18:06] mscdex: right, but it's n nested child process creation [18:06] mscdex: with each process dependent on the result of the previous [18:06] creationix: if you can compose each process into a single async function then it's quite easy to chain them [18:06] mscdex: then i need to know for any child if it's the last to be executed or not [18:06] mscdex: not easy with async [18:06] scott_gonzalez: if I do stream.setEncoding("utf-8") does that only affect incoming data or does it also cover outgoing data? [18:07] mscdex: but easy with sync, since it's just determined by the end of the for loop [18:07] mscdex: i think i'm going to do this in php [18:08] creationix: mscdex: or if you really want blocking js, try something like spidermonkey [18:08] creationix: with rhino [18:08] mscdex: nah, we only have node as far as ssjs goes on our systems [18:08] mscdex: would rather not have to install any others [18:08] creationix: mscdex: but really, serial async functions aren't hard at all with a little utility functions [18:09] mscdex: how? [18:09] creationix: mscdex: http://github.com/creationix/step [18:09] creationix: what's your use case? [18:09] creationix: I can give a better example if I know what you're trying to do [18:10] creationix: (step isn't the only library, it's just my personal favorite) [18:10] tmpvar has joined the channel [18:10] mscdex: writing a script to create a bunch of compressed archives for backup purposes, but no archive can contain a file split between multiple archives [18:10] mscdex: so each archive only has whole files [18:10] sr: tjholowaychuk, yo just saw yer connect-multipart middleware. what's you guys policy on middleware? i've started hacking on basic auth one, should it go to my fork of Connect or a separate project? [18:11] mscdex: so i have to check the filesize after adding a file to the archive, if it's over the limit, remove it and add it to the next archive part [18:11] creationix: sr: don't fork connect, just put it on your own repo [18:11] creationix: mscdex: sounds like fun [18:11] mscdex: not really heh [18:12] tjholowaychuk: sr: yeah your own repo :D [18:12] creationix: mscdex: I'll write up a gist if you want [18:12] mscdex: so for adding and deleting files i have to spawn a process to the compressor [18:13] sr: creationix, tjholowaychuk k, thanks guys [18:13] tjholowaychuk: sr: sounds sweet though, we can link to it on our page or wiki or whatever [18:13] sr: also. it's pretty annoying there is no base64 public api in node. seems like it is common enough it should [18:13] tjholowaychuk: creationix: you guys taking july 4th off down there? [18:13] creationix: sr: I think it's coming [18:14] JimBastard_: sr: i kinda agree about base64, i think its being added? [18:14] tjholowaychuk: sr: yeah.. i hear you, i have a patch to expose it from openssl but not sure whats going on with that [18:14] creationix: tjholowaychuk: well, the 4th is Sunday, but not sure if we'll get Monday off [18:14] JimBastard_: im using base64.js like crazy already [18:14] tjholowaychuk: creationix: our stuff is on the 1st, might just head out a bit early not sure yet [18:15] bpot has joined the channel [18:15] creationix: mscdex: that's some really nasty logic sync or otherwise [18:16] JimBastard_: i just posted on the mailing list, this should degrade to a flamefest quickly [18:16] creationix: mscdex: I'd have to think on it for a while longer than I have time right now to give a proper solution [18:16] tjholowaychuk: node-formidable seems to crash alot :( [18:16] JimBastard_: mscdex: are you spanning warez onto 1.44 mb images? [18:16] mscdex: creationix: i know, i wish compression programs would do this already [18:17] JimBastard_: i can send you a few spare floppies if you want [18:17] mscdex: JimBastard_: no, for backup purposes [18:17] mscdex: automated actually [18:17] JimBastard_: mscdex: there are defintely spanning strategies for sure [18:17] JimBastard_: this has been around for a while [18:17] mscdex: right but i can't have an archive that's dependent on another [18:18] creationix: JimBastard_: I think your challenge is impossible [18:18] mscdex: and i haven't found any programs that archive whole files [18:18] mostlygeek has joined the channel [18:18] maushu has joined the channel [18:19] mscdex: not even dar [18:19] BBBB has joined the channel [18:19] creationix: JimBastard_: you're basically asking people to wrap an async api to look sync [18:19] JimBastard_: creationix: aye, without static code analysis i think it is [18:19] JimBastard_: i'd like to see if anyone has any really out of the box solutions [18:19] JimBastard_: yeah, for sure [18:19] JimBastard_: i like impossible problems though [18:20] creationix: JimBastard_: actually my sync xhr solution technically doesn't violate your requirements [18:20] JimBastard_: considering how many problems i had to solve to get to this point though, im not giving up :-D. the backup solution for me is listing the modules a head of time [18:20] creationix: we'll see if someone comes up with that [18:21] JimBastard_: creationix: i mean, how would that really work in production [18:21] JimBastard_: if you start the require chain in a