[00:00] johnw: x44jdn[oo
[00:00] hassox: which is quickly happening here too
[00:00] johnw: sorry, my rat just ran across my keyboard
[00:00] hassox: a consitent base to build on is important
[00:00] hassox: if that's jsgi, chain or something else
[00:01] hassox: community support is a good thing to have
[00:01] hassox: so things become re-usable
[00:01] mikeal: this is just my opinion
[00:01] mikeal: but i don't find auth plugins helpful unless they tie in to a user system
[00:02] mikeal: which means they have to tie in to a framework or some storage layer somewhere
[00:02] mikeal: which puts them pretty far up the stack from the server connector (wsgi, jsgi, etc.)
[00:03] hassox: but your idea of what should be authenticated could be very different to mine
[00:03] hassox: you may want a user, where I may want a user, and account, a student and a staff member
[00:03] hassox: all different, yet all able to authenticate
[00:03] hassox: j
[00:03] hassox: just for eg
[00:04] mikeal: correct
[00:04] mikeal: but all those other things are still far up the stack from the server
[00:04] mikeal: the whole point of wsgi and the standards the stem from it is to seperate web frameworks/applications from the server
[00:04] hassox: what does this have to do with the server?
[00:04] hassox: ok ok
[00:04] hassox: in python and ruby
[00:05] hassox: I'm interested in node
[00:05] mikeal: i don't understand why you would want to shoehorn something so far up the application stack in to that standard
[00:05] hassox: because it becomes re-usable across frameworks
[00:06] mikeal: i think it's still useful to have one clean standard that takes raw request data and translates it into something that is server independent 
[00:06] mikeal: even if it's just in node
[00:06] mikeal: because you already have different socket server implementations in C that are getting ported to node
[00:06] hassox: but you're talking about things at a framework level
[00:07] mikeal: i think it's better to use jsgi as a standard to abstract that bit
[00:07] mikeal: and leave authentication to a standard that is further up the stack
[00:07] hassox: if you go further up the stack, then you can't share between frameworks
[00:07] hassox: whereas if you implement at this level, all frameworks can benefit
[00:07] mikeal: if you want to create a place for all this "middleware" why not put it on the application side of jsgi and leave it out of jsgi 
[00:08] mikeal: well, there aren't any frameworks yet
[00:08] hassox: there are a bunch of them already
[00:08] hassox: none of them afaik are built on an agreed standard
[00:08] mikeal: if you built something for them to sit on, that has proper extension hooks for all this stuff you're talking about
[00:08] hassox: take for example session
[00:08] hassox: sessions
[00:08] hassox: why should every framework re-implement session handling when it can be written once as middlware and shared
[00:09] mikeal: so, i basically agree with you
[00:09] mikeal: i just think it would be better to build a session system that depended on wsgi
[00:09] mikeal: rather than sticking a session system **in** wsgi "middleware"
[00:09] hassox: are you talking about jsgi -> (some as yet unkonwn layer) -> frameworks -> apps
[00:09] grantmichaels has joined the channel
[00:10] mikeal: exactly
[00:10] mikeal: and that "yet unkown layer" can be a lot smarter 
[00:10] hassox: so what does (some as yet unkonwn layer) look like?
[00:10] mikeal: so, jsgi just knows about requests and responses
[00:10] mikeal: if you build one session scheme, and someone else builds another, you're both just shoving it in to the request/response objects
[00:11] mikeal: (yet unknown layer) could know what a session is
[00:11] mikeal: it could know what auth is, and users are, and provide hooks to define and manipulate them
[00:11] mikeal: and provide some level of assurances that different extensions can play nicely together
[00:12] JimBastard: sessions can just be a module
[00:12] jed has joined the channel
[00:13] hassox: I don't think users belong there
[00:13] hassox: users are different for different apps
[00:14] mikeal: those apps define their users
[00:14] hassox: I think django has a universal idea of what a "user" is 
[00:14] mikeal: and then the auth system asks the user system for a user by name and possible password or other hash
[00:15] mikeal: you don't define a user in really granular terms
[00:15] mikeal: you just say that "somebody" does need to provide a way for me a get/set users by terms the auth system understands
[00:15] mikeal: django doesn't do this well
[00:15] mikeal: they tie it too closely to their ORM
[00:15] hassox: mikeal: have you looked at chain yet?
[00:15] hassox: mikeal: exactly
[00:15] hassox: a user could be nothing more than a json string
[00:16] mikeal: which means there is a User object and if you want to extend if you're basically creating a table relation
[00:16] mikeal: it **should** be a JSON string :)
[00:16] mikeal: hehe
[00:16] mikeal: and it should be in CouchDB
[00:16] mikeal: 
ACTION is biased

[00:16] hassox: mikeal: I disagree
[00:17] hassox: it should be whatever the application developer wants it to be
[00:17] hassox: it could be any one of many things
[00:18] mikeal: i know, i was be facetious 
[00:18] jan____: nah, it should be couch
[00:18] mikeal: 
ACTION high fives jan___

[00:18] mikeal: be/being
[00:18] hassox: :P
[00:18] jan____: :D
[00:18] jan____: *5*
[00:19] hassox: jan____: you're working with jchris right?
[00:20] rektide has joined the channel
[00:21] mikeal: i'm working with jan____ and jchris as of yesterday :)
[00:21] jan____: hassox: yea :)
[00:21] hassox: mikeal: congrats
[00:21] jan____: ah, he spoiled it.
[00:21] mikeal: before that I worked for Mozilla :)
[00:21] hassox: jan____:  congrats on the funding :)
[00:21] jan____: hassox: thanks :)
[00:21] isaacs: if you're in the sunnyvale area in the next few months, crockford is giving some lectures at yahoo about javascript: http://yuiblog.com/crockford/
[00:21] hassox: mikeal: oh great... I already feel like the dumbest person in the room
[00:21] hassox: all these big names!
[00:21] mikeal: hehe
[00:22] jan____: :)
[00:22] isaacs: hassox: you'd probably get a lot out of them, since your'e always saying how you wish you grokked js a bit more
[00:22] hassox: tbh I'd love to get you guyses feedback on chain (readme is poor)
[00:22] hassox: yeah
[00:22] mikeal: link?
[00:22] hassox: I'm trying
[00:23] hassox: http://github.com/hassox/chain
[00:23] hassox: I'm trying to find a good way to pass things aroudn inside an app that enforces async
[00:23] mikeal: Mozilla js isn't like the js the rest of the world writes :)
[00:24] hassox: it's like super samurai death js?
[00:24] mikeal: i once spent an hour debugging some js I wrote in a CouchDB view that was failing because i used an array comprehension 
[00:24] mikeal: ascher did the same thing using let
[00:25] mikeal: MozJs corrupts your brain :P
[00:25] hassox: as isaacs says... I'm a bit of a js n00b
[00:25] mikeal: node.js is a good way to learn proper js
[00:25] isaacs: mikeal: it is.  douglas's lectures are very thorough and informative, though.
[00:26] isaacs: he's actually very listenable
[00:26] binary42 has joined the channel
[00:26] mikeal: i watched some of his older lectures
[00:26] jan____: I could listen to crockford all day, on any topic
[00:26] mikeal: i saw the new ones pop up on ajaxian
[00:26] isaacs: a few of these are new
[00:27] isaacs: history of javascript is interesting, but it won't make you a better coder.
[00:27] mikeal: i'm painfully aware of js's history
[00:27] isaacs: it's not a pretty history
[00:27] hassox: everyone come and use chain
[00:27] isaacs: heheh
[00:28] isaacs: i'll play with it, hassox, i promise
[00:28] isaacs: did you look at simple-node-server?
[00:28] hassox: it's really really simple
[00:28] hassox: yeah I did
[00:28] hassox: I cloned it but I haven't had a chance to play heaps
[00:28] isaacs: i'm a bit interested in taking the best of what you've done and the best of what i've done, and then showing us both up.
[00:28] isaacs: that'll show us.
[00:28] hassox: I'm up for that
[00:29] isaacs: also, i absolutely LOVE fab's bubble syntax.  jed, that's pretty.
[00:29] jed: isaacs: awww shucks.
[00:29] mikeal: hassox: one concern I would have, is the ability to just return and subvert the other attached callbacks
[00:29] isaacs: it makes jquery syntax look bloated
[00:30] hassox: mikeal: I talked to halogrium about it last night
[00:30] jed: isaacs: did you ever see jquery^2?
[00:30] isaacs: i don't think so
[00:30] isaacs: does it have bubbles?
[00:30] jed: isaacs: resig basically created a haml-like dsl for jquery.
[00:30] jed: ha, no bubbles.
[00:30] isaacs: oh, yeah, i did see that
[00:30] hassox: mikeal: I will be adding callbacks to sendBody so that if you really really want each string on the way out, you can see it before it goes
[00:30] jed: required compilation.
[00:30] isaacs: right
[00:31] hassox: jed: do you have a link?
[00:31] jed: http://ejohn.org/apps/jquery2/
[00:31] mikeal: hassox: the problem is that some asshole will always think his code is so much more reliable than everyone else's and he just wants to make sure some other extension doesn't screw things up
[00:31] mikeal: he is usually male and a Java developer
[00:32] mikeal: and so people who install that extension have other things just stop working in extensions that were working before
[00:32] jan____: mikeal: I gonna steal that line
[00:32] r11t has joined the channel
[00:32] isaacs: mikeal: i solved that problem in sns by making every action explicitly call either this.finish() or this.next()
[00:32] hassox: mikeal: please go on
[00:32] isaacs: ie, each link determines whether or not to go to the next link in the chain
[00:32] hassox: isaacs:  yeah I think we're simliar there
[00:32] jan____: mikeal: I bet the No Country for Old Men Villain is a Java developer
[00:32] mikeal: I think you should either enforce the return of the object, which is passed to the next callback for that event
[00:33] hassox: mikeal: can you say that in more words please
[00:33] mikeal: or if undefined is returned (someone wrote bad code) you throw an exception or pass the original value to the next callback
[00:33] mikeal: so, Extension A adds a callback to event "foo"
[00:34] mikeal: Extension B also adds a callback to event "foo"
[00:34] mikeal: the object "bar" is passed to Extension A's callback
[00:34] hassox: mikeal: it's explicitly not done via events 
[00:34] hassox: on the way back out
[00:34] mikeal: Extension A needs to return "bar"
[00:34] mikeal: for Extension B to consume, if it does not then throw an exception
[00:35] hassox: there's nothing preventing you from doing that
[00:35] mikeal: i like the throw exception model because it alerts developers to bad code early
[00:35] isaacs_ has joined the channel
[00:35] hassox: the env object is a common object throughout
[00:35] mikeal: right, but you don't allow Extension A to call **anything** that makes it so taht Extension B's callback doesn't fire
[00:35] hassox: A can change it then pass it back to B
[00:35] hassox: what do you mean
[00:36] mikeal: so, your .next() .finish() stuff
[00:36] mikeal: .next() passes to the next callback, .finish() ends the chain
[00:36] isaacs: mikeal: that's exactly how i'm doing it in sns
[00:36] mikeal: ending the chain means you skip any other attached callbacks
[00:36] isaacs: there aren't "callbacks", per se
[00:36] hassox: right
[00:36] isaacs: there is an array of functions
[00:37] hassox: if you get the the end of a chain, and you respond directly, then it's done
[00:37] isaacs: the server does have events, but i'm not doing much with them.
[00:37] hassox: the "callbacks" aren't executed
[00:37] mikeal: ok, so this array of functions
[00:37] isaacs: the default last item in sns's chain is a 500 error, i believe.
[00:37] hassox: isaacs: I think we're actually quite similar in our setups
[00:37] isaacs: which is also what happens if there's any thrown error.
[00:37] mikeal: if you have multiple extension interested in the same chain they will both push to that array, correct?
[00:37] isaacs: hassox: yes, i kinda figured as much
[00:38] isaacs: when you first told me about it, i was sort of thinking "hey, that's what I'M doing!"
[00:38] isaacs: gmta and all that
[00:38] hassox: lol
[00:38] hassox: mikeal: 
[00:38] hassox: you need to use more words with me mate
[00:38] hassox: I'm multi tasking ;)
[00:38] mikeal: hehe
[00:38] mikeal: ok, so what is the array of functions unique to?
[00:38] mikeal: if it's not an event
[00:39] hassox: so when a bit of kit is done and it's not passing forward to another bit of kit
[00:40] hassox: it calls env.done() which runs the first "callback"
[00:40] hassox: that callback can do stuff, and if it wants, it can finish, or hand back to the next "callback" by calling env.done()
[00:40] hassox: so if all callbacks call env.done() all the way back, then the last one is one where the response is flushed to the client
[00:40] isaacs: so, chain: "env.done()", sns: "this.next()"
[00:41] hassox: nah
[00:41] hassox: chain : env.send(nextApp), sns "this.next()"
[00:41] hassox: I think
[00:41] isaacs: ah, i see
[00:41] isaacs: yeah, i was thinking i wanted a way to do branching request handling logic, rather than just a single list
[00:42] mikeal: ok, so how does this handle a case where two different actors (extensions, plugins, etc.) want to add to the same thing?
[00:42] hassox: what do you mean
[00:43] hassox: isaacs: when you want to branch
[00:43] hassox: you send it to the nextApp
[00:43] hassox: or you chose a "nextApp" to send it to
[00:43] isaacs: rightright
[00:43] isaacs: so the link can say "go to link A" or "go to link B"
[00:43] hassox: the links in the chain are only a "suggested" path
[00:43] hassox: right
[00:43] isaacs: whereas with sns right now, you give the server a list, and that's it
[00:43] hassox: and when an endpoint is done, it says
[00:43] hassox: env.done() and it starts to execute "callbacks"
[00:43] mikeal: this sounds like you wrote Basic in node
[00:43] mikeal: :P
[00:44] mikeal: goto linkB
[00:44] hassox: heh
[00:44] mikeal: i can see how you would use this as a single person writing and application
[00:45] mikeal: but i don't see how you could write a specific piece of reusable that used this chain system and other people could use it 
[00:45] isaacs: hassox: when you say "callbacks", you mean that it walks back up the chain to the start?
[00:46] hassox: only if the middleware cares
[00:46] hassox: if it cares
[00:46] hassox: it adds a callback
[00:46] hassox: and then it will be called
[00:46] isaacs: in original order, or in reverse order?
[00:46] isaacs: ie, is it a stack, or a queue?
[00:46] hassox: the last one to add the callback gets called first
[00:46] hassox: stack
[00:46] isaacs: gotcha
[00:47] hassox: mikeal: why not?\
[00:47] isaacs: so it traces its way back from the end ot the start of the request-processing chain of kits
[00:47] hassox: it can
[00:47] hassox: at any stage you can just do
[00:47] hassox: env.response.finish()l
[00:47] hassox: and then not call env.done()
[00:47] hassox: and the request is completed
[00:47] hassox: those callbacks are not ensuredc
[00:47] hassox: ensured
[00:47] isaacs: hm...
[00:48] isaacs: that seems like an evil temptation
[00:48] hassox: there are other callbacks that are ensured
[00:48] mikeal: which works until someone calls .done() without knowing that there were other extensions that added stuff that needs to be called
[00:48] hassox: if it's calling done
[00:48] isaacs: like, let's say i wanted to set up a "logging" middleware, which would always log when a request is completed, and how it completed.
[00:48] hassox: the it knows it's done
[00:48] hassox: yup
[00:48] hassox: so you'd set it up and add a callback to the ensured callbacks
[00:49] isaacs: i see
[00:49] hassox: these are triggered after response.finish()
[00:49] hassox: they listen to the events
[00:49] isaacs: so you separate optional and ensured callbacks
[00:49] hassox: yes
[00:49] hassox: and I will also add callbacks to headers and sendBody so that each chunck can be modified if required
[00:49] mikeal: why is this easier/better than a callback chain on events?
[00:49] isaacs: hm... my gut throws a warning on that idea.
[00:49] hassox: mikeal: because event based chaning is static
[00:50] hassox: isaacs: another idea on how to do gzipping on streaming chunks>?
[00:50] mikeal: static?
[00:50] hassox: mikeal: once you setup the listeners they're there to stay
[00:50] mikeal: no, you can remove them
[00:50] isaacs: hassox: well, my thought is "why bother having optional/ensured, why not just have either one or the other"?
[00:51] hassox: well yeah you could
[00:51] rektide has joined the channel
[00:51] hassox: isaacs: the first callback pushed onto the stack is the one that flushes the body and headers to the client
[00:51] hassox: isaacs: this doesn't have to be run though if something else decides it knows how to respond
[00:51] isaacs: hassox: i see
[00:51] hassox: mikeal: I'm not married to it yet
[00:52] mikeal: what i would do
[00:52] mikeal: is when callbacks get added, add a reference to the object they are adding to in the function itself before calling it
[00:52] mikeal: so that any function can do 
[00:52] mikeal: this.remove()
[00:52] erichocean: [ANN] fsm.js (http://pastie.org/768266) How to use (flat) finite state machines with node.js
[00:52] hassox: that sounds pretty awesome
[00:53] mikeal: so you have events
[00:53] hassox: mikeal: I originally tried it with events
[00:53] mikeal: and before you call each callback set callback._caller = this
[00:53] mikeal: and add
[00:53] hassox: I definitley want to explore this
[00:53] mikeal: callback.remove = function () {caller.removeListener(callback)}
[00:54] isaacs: erichocean: fsm will always be  ~~(-.-)~~ to me
[00:54] isaacs: all hail his noodley appendage
[00:54] elliottcable: wh—
[00:54] mikeal: definitely do it before calling, so that if you use one function as a listener on multiple events it doesn't remove it from all events when calling .remove()
[00:54] elliottcable: why would `eval("{}")` be undefined?
[00:54] elliottcable: http://cld.ly/1dzbw
[00:55] elliottcable: and yet ({}) works o_O
[00:55] elliottcable: so it parses as a block statement?
[00:55] elliottcable: wh— … why?
[00:55] kriskowal: elliottcable it's the distinction between statement and expression context
[00:56] kriskowal: same problem with anonymous function statements
[00:56] mikeal: it's better to parse stuff like that as JSON
[00:56] hassox: mikeal: I'd love to explore this and use events rather than promise callbacks
[00:56] mikeal: then it'll return an empty object
[00:56] elliottcable: mikeal: not trying to parse it, just poking around in my new repl
[00:56] mikeal: aren't promises going away in favor of defers?
[00:57] inimino: holy scrollback, batman!
[00:57] hassox: I don't think so
[00:57] mikeal: i thought i saw that on the list
[00:57] elliottcable: holy scrollback, hassox!
[00:57] elliottcable: oops… inimino. >,>
[00:57] erichocean: I'm currently reworking node.js to use more explicit event handling via http://www.state-machine.com/
[00:58] elliottcable: what’s that site? o_O
[00:58] elliottcable: wtf advertising pictures
[00:58] elliottcable: it’s … a girl lying on a washer/dryer
[00:58] erichocean: embedded programmers
[00:58] elliottcable: and then a bunch of random-ass pictures of ICs
[00:58] erichocean: but the code itself is extremely tight/small/fast
[00:59] erichocean: and has *killer* tracing
[00:59] erichocean: basically, if you've seen what Varnish cache can do, I'm hoping to bring that to node.js for all apps
[01:00] elliottcable: 
ACTION ponders having the repl eval everything inside parens

[01:00] jan____: nighto
[01:00] elliottcable: is that a bad idea, and if so, why?
[01:00] erichocean: elliottcable: that should be fine/safe
[01:00] isaacs: elliottcable: what if you have this: "1; 2"
[01:01] elliottcable: hrm
[01:01] isaacs: definitely not safe
[01:01] elliottcable: isaacs: why would you throw that in the repl?
[01:01] elliottcable: maybe wrap it in parens, unless it has a semicolon?
[01:01] erichocean: the safest way is (function() { YOUR_TUFF })()
[01:01] elliottcable: isaacs: any other examples?
[01:01] isaacs: i sometimes do stuff like this: a = [1,2,3]; a.splice(1,2,9,8); a
[01:01] hassox: mikeal: did you get my msg?
[01:02] elliottcable: erichocean: ah!
[01:02] elliottcable: I like that, isaacs, any objections?
[01:02] elliottcable: awww no )-:
[01:02] elliottcable: same scope erichocean
[01:04] isaacs: elliottcable: well, wrap in parens if there are no semicolons that are not part of a string or comment or regexp, yeah
[01:04] elliottcable: hrm
[01:04] isaacs: wrapping in a function is a bit of a pita, since then you have to return it
[01:04] elliottcable: getting complex, fast
[01:04] isaacs: srsly
[01:04] isaacs: why not just say that it's going to be evaled, so {foo:"bar"} wont' work?
[01:05] isaacs: or, try evaling it, if it throws, then try with parens, and if that also throws, then return the first error.
[01:05] elliottcable: hrm
[01:05] isaacs: s/return/print)
[01:05] elliottcable: but {foo:"bar"} won’t throw
[01:05] elliottcable: the point is to make the repl print what is expected
[01:05] isaacs: ah, right
[01:05] isaacs: won't throw
[01:05] elliottcable: 
ACTION thinks

[01:05] isaacs: well, try with parens, if that throws, try without
[01:05] isaacs: switch the order.
[01:06] isaacs: ("foo") is the same as "foo"
[01:06] elliottcable: hrm
[01:06] elliottcable: hrm
[01:06] isaacs: oh, wait, but that'll fail on this:  a = "foo"; {bar : a }
[01:06] isaacs: what you want is the repl to not be retarded with expressions like javascript is.
[01:06] elliottcable: hahahaha
[01:06] elliottcable: ugh
[01:06] elliottcable: hrm
[01:06] elliottcable: yeah
[01:07] elliottcable: which isn’t an option
[01:07] elliottcable: unless I make a JESS REPL
[01:07] elliottcable: ah well
[01:07] elliottcable: 
ACTION forgets it

[01:07] erichocean: elliottcable: you can overcome the context/scope issues in C++
[01:07] isaacs: although, the node repl fails on that too
[01:07] isaacs: node> a="bar"; {foo:a}
[01:07] isaacs: "bar"
[01:07] elliottcable: let sleeping language design flaws lie, and all that
[01:07] elliottcable: d-:
[01:07] isaacs: node> a="bar"; ({foo:a})
[01:07] isaacs: {
[01:07] isaacs:  "foo": "bar"
[01:07] isaacs: }
[01:08] isaacs: firebug does the same thing
[01:08] isaacs: i think you're fine just evaling it, and letting it fail if it fails.
[01:08] isaacs: don't try to fix the language
[01:08] isaacs: no parens
[01:08] elliottcable: yeha
[01:08] elliottcable: exactly what I just decided on lol
[01:09] isaacs: your heart is in the right place, but javascript is a little strange in that area.
[01:09] isaacs: ^_^
[01:09] erichocean: http://code.google.com/p/ecmascript-ast/
[01:10] erichocean: I'd be forever grateful if someone would write an HTML pretty-printer/cross-linker using that
[01:10] elliottcable: ooooooo
[01:11] isaacs: erichocean: hey, didn't inimino have some kind of AST experiment thingie like that?
[01:11] isaacs: inimino: you round? ^ or am i thinking of someone else?
[01:11] elliottcable: probably.
[01:11] elliottcable: he’s inimino.
[01:11] inimino: 
ACTION catches up

[01:11] elliottcable: JS Jesus, speak to us of your magical endeavours!
[01:12] inimino: ah, yes, I have something like that
[01:13] inimino: it's exactly like that, except 1) the output format is more compact, 2) it's pure JS, not built into V8, and 3) the AST is probably closer to the language spec, with less V8-isms
[01:13] isaacs: inimino: got a link?
[01:14] erichocean: inimino: can you capture comments?
[01:14] isaacs: (#1 was a given)
[01:14] inimino: isaacs: http://inimino.org/~inimino/blog/peg_first_release follow the link to the demo
[01:14] inimino: er, ES5 demo
[01:14] isaacs: "it's the same, but i've stripped all whitespace, semicolons, and comments..."
[01:14] erichocean: inimino: dude, nice!
[01:15] inimino: note that it really is an ES5 grammar, so it won't parse things that aren't ES5 (like jQuery, last time I checked)
[01:16] inimino: I have an extended grammar though
[01:16] elliottcable: anyway, inimino, isaacs, you may be interested
[01:16] isaacs: yes, i like this.  peg, that's it.
[01:16] isaacs: i can use this.
[01:17] inimino: erichocean: and yeah, it includes comment nodes, though the parse tree doesn't include any strings, just offsets into the original string
[01:17] erichocean: inimino: sweet, is the ECMAScript 5 grammar available?
[01:18] elliottcable: http://github.com/elliottcable/poopy.js/blob/new-acquire/bin/node-from-repl
[01:18] inimino: so you usually pass both the parse tree and the string to some kind of API that does whatever tree stuff you're going to do with it
[01:18] inimino: erichocean: yeah, it should be linked from the demo
[01:18] elliottcable: repl, using `from` and `eyes.js`
[01:18] elliottcable: stylizes output
[01:19] erichocean: ah, I see it now: http://boshi.inimino.org/3box/PEG/ECMAScript_unified.peg
[01:19] erichocean: 
ACTION needs to add jsDoc parsing in the comments...

[01:19] inimino: yeah
[01:20] inimino: ah, that would be great
[01:20] inimino: erichocean: if you do that, let me know, I'd find that really useful also
[01:20] erichocean: how hard is it to add actions?
[01:20] inimino: like semantic actions?
[01:20] erichocean: I've been wanting to hook up Clang to a JavaScript parser
[01:21] inimino: it doesn't use that kind of model at all, it just gives you a parse tree, then there are a couple APIs for dealing with those (not released yet)
[01:21] erichocean: is that an artifact of using PEGs?
[01:21] inimino: erichocean: there's also streaming output so if you want you could have a SAX-style API
[01:22] inimino: no, more of a design goal, to keep the grammar explitly declarative and add everything else in layers on top
[01:22] erichocean: damn that's a pretty grammar
[01:23] erichocean: inimino: does your grammar expect UTF-16 input?
[01:24] erichocean: hmm, I guess if it's in JavaScript, the answer is "yes"
[01:25] inimino: erichocean: yes, UTF-16, and it does handle supplementary characters (though there are probably lurking bugs here still)
[01:25] isaacs: inimino: you mention that things that jquery has things are not es5?
[01:25] isaacs: got a peg that includes those too ;) ?
[01:26] inimino: isaacs: yep, jQuery has blocks that include functions
[01:26] r11t has joined the channel
[01:26] isaacs: blocks like {}?
[01:26] inimino: yes
[01:27] inimino: http://boshi.inimino.org/3box/PEG/Web_compatible_JavaScript.peg
[01:27] inimino: I don't actually have a parser that's generated with that one yet, I just wrote that but haven't tested it
[01:27] isaacs: neato!
[01:27] erichocean: inimino: I'm a (former) SproutCore core developer; there are a lot of places in SC that can benefit from mild, Closure-style compilation
[01:28] inimino: (there's an API to combine to PEGs, once they're parsed, so it just overrides the existing Statement rule)
[01:28] erichocean: so this is a big help, thanks!
[01:28] inimino: erichocean: awesome, that's one of the use cases I had in mind
[01:29] erichocean: the goal is to have something like this for SC apps: http://clang-analyzer.llvm.org/
[01:29] inimino: erichocean: it'll be getting a lot more capable, please let me know about any bugs, API requests, or whatever
[01:29] erichocean: will do, I'm king of the pre-alpha code
[01:30] inimino: that looks great
[01:30] inimino: haha, alright
[01:30] inimino: just something that did some selective inlining would be a big win for a lot of code I write
[01:30] erichocean: we've been writing a ton of jsDoc type annotations so we can do static type checking, and we also need DCE *bad*
[01:31] erichocean: plus simple inlining, but SC is really dense already
[01:31] inimino: ah, I've been doing type annotations too
[01:31] erichocean: there's a guy who's got an automatic static type checker for JNS
[01:31] erichocean: JS
[01:32] inimino: the module I just wrote would have been basically impossible for me to reason my way through without it
[01:32] inimino: that would be cool
[01:32] inimino: currently I don't have anything to test my annotations, they're just documentation
[01:32] inimino: which is still a help, but... obviously not as much of one
[01:32] robrighter has joined the channel
[01:33] inimino: I'd like to have type inference where possible, editor support, and "compile time" type errors...
[01:33] erichocean: http://pubs.doc.ic.ac.uk/chrisandersonphd/
[01:34] erichocean: the main reason I want to hook your parser up to Clang is to get the normal compiler infrastructure LLVM supplies
[01:34] erichocean: it's amazing how good type inference is these days
[01:35] inimino: oh wow, this paper looks cool
[01:37] mikeal has joined the channel
[01:44] rolfb has joined the channel
[01:44] erichocean: inimino: http://www.cs.au.dk/~amoeller/papers/tajs/ 
[01:44] erichocean: that's the one I was looking for
[01:45] erichocean: if you email the guy, he'll send you the program (if it's not out already)
[01:47] inimino: erichocean: cool, thanks, going to read both of these
[01:47] pjb3_ has joined the channel
[01:47] erichocean: my sense is that the latter approach will scale better
[01:48] inimino: what's the difference?
[01:48] erichocean: there's quite a few, actually
[01:48] erichocean: I'd say the main difference is that the latter paper isn't general
[01:49] inimino: ok
[01:49] erichocean: for research, generality is good
[01:56] mikeal has joined the channel
[02:07] okito has joined the channel
[02:08] rektide has joined the channel
[02:15] inimino: erichocean: thanks again for pointing me to these, this is really fascinating work
[02:37] eddanger has joined the channel
[02:39] elliottcable: hrm
[02:39] elliottcable: odd
[02:40] elliottcable: http://gist.github.com/269955
[02:40] elliottcable: am I missing something?
[02:40] elliottcable: shouldn’t that mix anything from the passed files into the global namespace
[02:46] richtaur has joined the channel
[02:48] rednul_ has joined the channel
[02:54] cloudhead: elliottcable: did you try just doing process.mixin(false, from.absolute(file).wait()); ?
[02:54] elliottcable: woah
[02:54] elliottcable: wtf
[02:54] elliottcable: cloudhead: nah, process.mixin takes a target as the second argument
[02:54] cloudhead: it depends
[02:55] cloudhead: if the first argument is a boolean
[02:55] elliottcable: yeah, hence false
[02:55] cloudhead: in which case it should mix with GLOBAL
[02:55] cloudhead: because there is only one Object
[02:56] elliottcable: nah, the boolean is about deepcopy or shallowcopy
[02:56] cloudhead: yea
[02:56] cloudhead: if you give it only one Object, it should mix it with GLOBAL
[02:56] elliottcable: whaaaaaaaaaaatf
[02:56] elliottcable: http://gist.github.com/269965
[02:56] elliottcable: that doesn’t work either!
[02:56] elliottcable: o_O
[02:57] cloudhead: repl.scope isn't modified?
[02:57] elliottcable: http://cld.ly/88zdp
[02:57] elliottcable: if I set foo *directly on* scope, it works fine
[02:59] cloudhead: um, weird
[03:00] elliottcable: now, this: http://cld.ly/1czdu
[03:01] elliottcable: http://gist.github.com/269965
[03:03] elliottcable: )-: who wrote the repl.js code? ryah?
[03:04] eddanger has joined the channel
[03:05] cloudhead: hmm
[03:09] scudco has joined the channel
[03:13] ryah: is http://nodejs.org working for other people?
[03:13] kriszyp: yes
[03:13] jed: yes
[03:13] elliottcable: http://downforeveryoneorjustme.com/http://nodejs.org/
[03:13] ryah: hmm. shrug
[03:14] elliottcable: ryah: can you explain http://gist.github.com/269965 not working? I get http://cld.ly/1czdu
[03:14] elliottcable: ryah: i.e. the direct assignment works, but process.mixin doesn’t
[03:17] mattly has joined the channel
[03:17] ryah: elliottcable: nope
[03:18] elliottcable: ryah: hrm. Thanks
[03:18] ryah: elliottcable: :)
[03:20] jed: i think i've asked this here before to no avail, but is there any way to get the scheme from a node request?
[03:21] kriszyp: jed are you fixing my half-baked jsgi-node?
[03:22] jed: kriszyp: ha, would you like me to?
[03:22] kriszyp: sure, if you get a chance
[03:22] jed: there are only a few easy fixes.
[03:22] jed: i'll fork it and get them to you by tomorrow.
[03:22] kriszyp: I'd probably get to it eventually, but right now I am just doing what I need for my project, but it'd be nice to have a more complete impl
[03:23] kriszyp: appreciate the help, btw
[03:23] jed: kriszyp: no prob. would really like to see node and commonjs get along.
[03:23] kriszyp: yep
[03:24] ryah_away: jed: scheme? like "http" ?
[03:24] jed: ryah_away: yes.
[03:24] kriszyp: I'm trying to get my project to run on Node and Jack, so I am hoping for the same :)
[03:24] ryah_away: usually they arn't present in the request
[03:24] ryah_away: it's usually something like "GET /blah HTTP/1.1"
[03:25] jed: ryah_away: oh, so i'd just guess from the port or something?
[03:25] ryah_away: well - i guess the only possibility is http or https, right?
[03:25] kriszyp: it looks like it is in there
[03:25] ryah_away: and you should know when your server is secure or not
[03:26] isaacs has joined the channel
[03:26] jed: ryah_away: well, you might have the same site running in more than one location/scheme.
[03:28] ryah_away: so, answer: no the api doesn't provide the scheme. something higher-level should do that
[03:28] elliottcable: gah!
[03:28] elliottcable: this has to be something to do with eval and with()
[03:29] inimino: heh
[03:29] jed: ryah_away: that sounds reasonable. was wondering if i'd missed something. many thanks, and good luck with your hunting.
[03:30] bryanl has joined the channel
[03:31] ryah_away: thanks
[03:35] robrighter has joined the channel
[03:38] isaacs has joined the channel
[03:38] jed: kriszyp: just sent a pull request.
[03:39] elliottcable: gah
[03:39] elliottcable: apparently I don’t actually know how with() works
[03:39] kriszyp: jed: awesome
[03:39] elliottcable: it seems to interact weirdly with eval(), or possibly the combination of mixin() and eval()
[03:41] erichocean has left the channel
[03:41] erichocean has joined the channel
[03:42] erichocean: I've narrowed it down to this step, where a certificate of a completely wrong length is being sent over the wire
[03:43] Pilate has joined the channel
[04:16] CIA-78: node: 03Felix Geisendörfer 07master * rd9a8137 10/ (lib/multipart.js test/mjsunit/test-multipart.js): 
[04:16] CIA-78: node: Throw exception for invalid multipart streams
[04:16] CIA-78: node: When using the multipart parser with an regular http request, the
[04:16] CIA-78: node: parser did not complain and just never finished. - http://bit.ly/6wPkmJ
[04:16] CIA-78: node: 03Felix Geisendörfer 07master * raa73ed9 10/ test/mjsunit/test-multipart.js : 
[04:16] CIA-78: node: Added test case for the simple multipart API
[04:16] CIA-78: node: So far this didn't have any test coverage. - http://bit.ly/93mgv2
[04:16] CIA-78: node: 03Felix Geisendörfer 07master * rf86c178 10/ (lib/multipart.js test/mjsunit/test-multipart.js): Handle bad requests in simplified parser API - http://bit.ly/4vw6se
[04:16] CIA-78: node: 03Felix Geisendörfer 07master * r7d947f8 10/ test/mjsunit/test-multipart.js : Clean up multipart test case - http://bit.ly/56FQzh
[04:16] CIA-78: node: 03Felix Geisendörfer 07master * rd9085ea 10/ doc/api.txt : Updated docs for multipart errors - http://bit.ly/7LJ3Zj
[04:20] ryah_away: isaacs: what about ben thomas's patch?
[04:20] ryah_away: isaacs: does it look good to you?
[04:22] brosner has joined the channel
[04:30] scudco has joined the channel
[04:38] eddanger has joined the channel
[04:51] pjb3 has joined the channel
[05:12] CIA-78: node: 03Ryan Dahl 07master * r3f39772 10/ (deps/libeio/eio.c src/node.cc): 
[05:12] CIA-78: node: libeio bugfix part 2
[05:12] CIA-78: node: Reverts the change to deps/libeio/eio.c added in
[05:12] CIA-78: node: 04dd2d51be03c01d9ab259fe40e436730778bd01
[05:12] CIA-78: node: It wasn't a bug, I was just using eio incorrectly.
[05:12] CIA-78: node: See http://lists.schmorp.de/pipermail/libev/2010q1/000855.html - http://bit.ly/7K3svu
[05:25] binary42 has joined the channel
[05:25] alex-desktop has joined the channel
[05:38] scudco has joined the channel
[06:01] felixge has joined the channel
[06:03] felixge has joined the channel
[06:12] nsm has joined the channel
[06:30] micheil has joined the channel
[06:35] bentomas has joined the channel
[06:40] creationix has joined the channel
[06:46] mikeal has joined the channel
[06:51] kriskowal has joined the channel
[07:08] sudoer has joined the channel
[07:22] mcarter has joined the channel
[07:25] kriszyp has joined the channel
[07:54] michaelk^ has joined the channel
[08:09] scudco has joined the channel
[08:09] scudco has joined the channel
[08:10] mahemoff has joined the channel
[08:11] hassox has joined the channel
[08:14] rictic has joined the channel
[08:16] elliottcable: hrm
[08:16] elliottcable: would anybody be opposed to me wrapping the evalualtion in the repl in a function, and `apply()`ing it to the `scope` object?
[08:28] olivvv has joined the channel
[08:39] micheil has joined the channel
[08:40] ryah_away: grr
[08:40] ryah_away: the race condition from hell..
[08:42] elliottcable: ahhh
[08:42] elliottcable: lol
[09:21] teemow has joined the channel
[09:30] CIA-78: node: 03Ryan Dahl 07master * rf80cc69 10/ (4 files in 2 dirs): (log message trimmed)
[09:30] CIA-78: node: libeio bugfix part 3
[09:30] CIA-78: node: Finally (hopefully) fix the issue that Felix reported. It's only appearing
[09:30] CIA-78: node: on macintosh (test/mjsunit/test-eio-race3.js)
[09:30] CIA-78: node: The trick/hack is to call eio_poll() again before reentering the event loop.
[09:30] CIA-78: node: Additionally this commit implements a more complex method of calling
[09:30] CIA-78: node: eio_poll(), occasionally dropping to an ev_idle watcher.
[09:36] brosner has joined the channel
[09:41] ryah_away: damn
[09:42] ryah: felixge: nevermind it's not working yet
[09:42] felixge: ryah: : (
[09:42] felixge: ryah: you up early or late?
[09:43] ryah: late
[09:44] felixge: ryah: my stat test passes
[09:44] felixge: on HEAD now
[09:45] felixge: with either ./node or ./node_g
[09:45] ryah: but other stuff fails
[09:46] ryah: i stupidly didn't run the tests before i pushed
[09:46] felixge: oh
[09:47] ryah: but i think i fixed it
[09:47] felixge: what other stuff fails for you? All my tests are passing on head
[09:47] felixge: or do you mean libeio part 2 was broken?
[09:47] felixge: part 3 seems really nice to me :)
[09:50] ryah: probably cause your computer is fast :)
[09:51] felixge: ryah: running the suite in my VM now. 
[09:51] felixge: ah, test-stat-eio-race fails
[09:51] felixge: oh wait, didn't have the latest commit
[09:51] felixge: compiling again
[09:53] felixge: ryah: nope, all tests pass on my VM as well
[09:53] felixge: which tests are failing for you?
[09:54] ryah: test-stat-handler.js
[09:54] CIA-78: node: 03Ryan Dahl 07master * rb1e126f 10/ src/node.cc : 
[09:54] CIA-78: node: libeio bugfix part 4
[09:54] CIA-78: node: Oops. Last commit broke a few tests. Should work now! - http://bit.ly/7S06Og
[09:55] ryah: getting that fucking thread pool to respond correctly is a bitch
[09:55] ryah: 
ACTION reminds himself avoid these sorts of problems is why he is making node in the first place

[09:57] felixge: ryah: at least I feel less dumb now for being unable to figure this one out :)
[09:57] felixge: all tests passing on osx
[09:58] ryah: i had to ask marc lehmann about it
[09:58] ryah: apparently i just wasn't using eio correctly
[09:59] ryah: eio pains itself to not communicate more than the absolute necessity to its user about result availability - if you miss some notification - you're fucked
[10:00] felixge: all tests passing on ubuntu (virtual machine)
[10:00] felixge: sweet!
[10:01] felixge: ryah: yeah - I have no idea how you figured out how to use it to begin with. It's not exactly well-documented :)
[10:01] felixge: other than that demo.c file which seems to be broken 
[10:02] ryah: i read the source :)
[10:02] felixge: ryah: yeah I tried that too, I figured out how it works overall, but I'm blind to the subtle details due to my lacking c-skills :)
[10:03] felixge: btw. I'm really scared about that node presentation I'm supposed to do. I read over your slides again and you've put the expectation scale very high for such a presentation
[10:03] felixge: plus some of the people there have seen your talk and some haven't, so that's gonna make it hard as well :)
[10:04] jasondavies: ryah: btw there is a simple bug in url.parse(foo, true), it's a one-line fix: http://github.com/ry/node/issues#issue/39
[10:04] felixge: I'm considering to go for a talk a la "How to sneak node.js into your real world projects" talk
[10:04] felixge: which shows how node can be used with existing infrastructure and how to make the boss think its a rad idea
[10:04] felixge: ;)
[10:05] jasondavies: felixge: awesome, I fully applaud such a talk :)
[10:05] felixge: jasondavies: cool : )
[10:06] felixge: Another thing I'm thinking about is a key-value stored called 'dirty'. It would be a hybrid between Redis/CouchDB and really fast because you'd directly include it as a module and share memory with it, no network overhead
[10:06] ryah: felixge: oh yeah, when is that?
[10:06] felixge: ryah: tuesday
[10:07] jasondavies: back in the day I persuaded my boss to use Django instead of PHP, it took a few hours but I won him over in the end
[10:07] ryah: okay - i'll send you some notes about what i'm wroking on tomorrow or the next day (if i don't remind me)
[10:07] felixge: jasondavies: lucky you! I talked myself into becoming a CakePHP core contributor and now I have to do PHP until forever :)
[10:08] jasondavies: felixge: hehe cool
[10:08] felixge: ryah: yeah don't worry. I usually finish my presentations a few minutes before I give them ;)
[10:08] felixge: but the sooner the better, maybe I finish this one earlier
[10:10] felixge: gotta work on those damn bikeshed-promises again. I really don't like kris' event.js/Q implementation - it seems to try to do too many things at once. I'd rather get just the promise API figured out and re-consider updates to the EventEmitter afterwards
[10:10] jasondavies: 'dirty' sounds great, what kind of persistence ideas do you have for it? some kind of append-only file like CouchDB?
[10:10] felixge: jasondavies: I'm thinking append-only newline seperated JSON
[10:10] felixge: so each line would be 1 JSON document
[10:10] jasondavies: sounds good
[10:11] felixge: I looked at btree+, but since this will be a memory-based k-v store, I don't think its all that important
[10:11] felixge: at least for now
[10:11] jasondavies: nice and simple, and easy to load from other libraries
[10:11] felixge: and I gotta do some stuff to go along with the name :)
[10:11] felixge: my initial tests indicate that you might get up to 1 mio writes / sec with a store like this
[10:12] felixge: (of course it will take much longer to persist those to disk ^^)
[10:12] jasondavies: so the indexes would be built at load time, just by loading everything into a big dict?
[10:12] jasondavies: s/dict/whatever you call it in JS/
[10:12] CIA-78: node: 03Benjamin Thomas 07master * r947c577 10/ (lib/url.js test/mjsunit/test-url.js): Fix bug in the url module's url_parse method if 'parseQueryString' is true - http://bit.ly/5f9JWN
[10:12] felixge: jasondavies: yeah, essentially
[10:12] felixge: I'm also experimenting with somewhat of a structure for it
[10:12] felixge: let me show you
[10:13] ryah: jasondavies: that fixes your bug 
[10:13] jasondavies: ryah: great, thanks
[10:13] felixge: jasondavies: https://gist.github.com/7ef9f7427f3f5908b3a0
[10:13] ryah: jasondavies: he added tests so i applied his
[10:13] ryah: :)
[10:13] jasondavies: ryah: np :)
[10:14] felixge: jasondavies: defining a schema for a dirty db is optional, but it will make sure all objects you get/set on it will share a minimal schema as well as functions you can call on them
[10:14] felixge: not sure if thats a good idea, but it looks fun
[10:14] jasondavies: felixge: looks nice
[10:15] ryah: felixge: i wonder if chaining promises is even so useful
[10:15] ryah: i mean the arguments
[10:16] felixge: ryah: well I see it as function composition
[10:16] ryah: yeah, you can modify the arguments as they pass down the chain, but only if your modification is done in constant-time
[10:16] ryah: well, constant-time isn't the right term
[10:16] ryah: only if it doesn't perform i/o
[10:16] felixge: not sure I agree with that
[10:16] ryah: it's almost similar to Rack
[10:16] felixge: I mean it should be easy to chain multiple async operations
[10:17] ryah: you can't do some db query with the argument as a value and return the response of that query
[10:17] ryah: i.e have the database modify the argument
[10:18] felixge: there is really 2 problems to be addressed: Chaining promise dependencies and grouping independent promises
[10:19] felixge: I feel like I'm writing a lot of code around those 2 problems all the time when working with node
[10:19] ryah: well - we definitely need something to group x promises together and be notified when they're done
[10:19] ryah: and we need a way to do x things sequentially
[10:20] ryah: those are real-life use-case
[10:20] felixge: right. And I'd also like a way to do promise sequences without getting very deep function nestings
[10:20] ryah: what i questin is the argument modification
[10:20] felixge: ryah: oh, well the CommonJS idea is to not modify the argument of a promise
[10:20] felixge: a Promise has a single value that it is being assigned once
[10:20] felixge: over and out
[10:21] felixge: it will never change its value, and all callback listeners will get the same value from the promise
[10:21] ryah: right but when you add another callback, you get the return value of the last
[10:21] ryah: i guess you get a new promise
[10:21] felixge: no, you get the return value from the calback
[10:21] felixge: yes, in a new promise
[10:21] ryah: meh, i got to go
[10:21] felixge: it will default to the old promises value if the callback doesn't return any value
[10:21] ryah: sorry
[10:22] felixge: but the original promise doesn't change
[10:22] felixge: np
[10:22] felixge: ttyl
[10:22] ryah: yeah- ciao
[10:22] felixge: ryah: AND HUGE THX FOR FIXING THE EIO THING
[10:22] felixge: ttyl
[10:30] richtaur has joined the channel
[10:32] nsm has joined the channel
[10:42] felixge has joined the channel
[11:04] DamZ has joined the channel
[11:29] felixge has joined the channel
[11:29] jacobolus has joined the channel
[11:43] spoob has joined the channel
[12:24] kriszyp has joined the channel
[13:02] michaelk^ has joined the channel
[13:07] johan-s has joined the channel
[13:15] alex-desktop has joined the channel
[13:34] richtaur has joined the channel
[13:36] pmuellr has joined the channel
[13:57] sztanpet has joined the channel
[14:13] r11t has joined the channel
[14:33] soveran has joined the channel
[14:41] bryanl has joined the channel
[14:52] robrighter has joined the channel
[14:53] cloudhead has joined the channel
[15:05] n8o has left the channel
[15:06] davidsklar has joined the channel
[15:42] micheil has joined the channel
[15:53] binary42 has joined the channel
[16:02] erichocean: has anyone modified node.js to use OpenSSL instead of GNUTLS?
[16:12] skampler has joined the channel
[16:24] jamiew has joined the channel
[16:24] martint-t has joined the channel
[16:31] alexiskander has joined the channel
[16:43] felixge has joined the channel
[16:44] jed has joined the channel
[16:48] erichocean: I'm also looking into http://www.yassl.com/ and http://www.matrixssl.org/
[16:56] jamiew has left the channel
[17:03] RayMorgan has joined the channel
[17:04] sudoer has joined the channel
[17:10] isaacs has joined the channel
[17:12] voodootikigod_ has joined the channel
[17:19] cloudhead: anyone here with experience with websockets?
[17:22] robrighter has joined the channel
[17:24] binary42: cloudhead: Sure. Not on node.js yet though.
[17:25] cloudhead: binary42: cool, I'm wondering, how do you differentiate between a push, and a response to a pull?
[17:26] cloudhead: do you define your own protocol for that stuff?
[17:26] binary42: cloudhead: Not sure what you mean.
[17:26] binary42: It's basically raw IO.
[17:26] cloudhead: yea, so like the 'onmessage' handler
[17:26] binary42: You start with HTTP and send an upgrade header.
[17:26] binary42: Yup.
[17:26] cloudhead: gets push requests from the server, as well as responses from pull requests
[17:26] binary42: So you write when you want an read when you want.
[17:27] binary42: Yup. All event based.
[17:27] binary42: Very elegant IMO.
[17:27] cloudhead: hmmm
[17:27] cloudhead: but all messages go through a funnel
[17:27] binary42: The handshake is pretty easy to implement too so I bet you could do it in node easily.
[17:27] binary42: Well, it's like a socket.
[17:27] cloudhead: like, you don't get 'responses' per say
[17:28] binary42: Ah. Right.
[17:28] cloudhead: you just get input/output
[17:28] cloudhead: not sure how that works out
[17:28] binary42: Well, things are framed.
[17:28] binary42: There are two frame modes.
[17:28] binary42: One text based and one binary.
[17:28] cloudhead: say you request some data, you can't just have a callback for that specific request
[17:28] binary42: So you send frames which trigger the event handlers.
[17:28] cloudhead: the response will come in with all other responses
[17:28] binary42: Nope.
[17:29] binary42: Though that is easy to add with opaque markers.
[17:29] binary42: ie. some sequence of numbers works.
[17:29] cloudhead: so you tag the requests
[17:29] cloudhead: with some hash
[17:29] binary42: Yeah. And the server would have to have logic to tag the response.
[17:29] cloudhead: right
[17:29] cloudhead: interesting
[17:29] binary42: The reason it isn't built in is not all protocols need things like that.
[17:29] cloudhead: yea
[17:29] binary42: It's pretty open ended. Just enough to get something going.
[17:30] cloudhead: so potentially, the onmessage() would have a list of all the requests, and would call the appropriate callback
[17:31] cloudhead: if you wanted the sort of request/response structure
[17:31] binary42: Yes.
[17:31] cloudhead: cool
[17:31] felixge has joined the channel
[17:32] felixge has joined the channel
[17:33] cloudhead: binary42: if I'm using websockets for push stuff, it would make sense to use websockets for all data exchange right? or would it be better to use xhr for request/response (pull) and websockets for push?
[17:34] binary42: websockets is great for pulling down stuff but you forgo caches and the whole HTTP infrastructure.
[17:34] cloudhead: right right
[17:34] cloudhead: hmm
[17:34] binary42: So use HTTP when you want to take advantage of that. Otherwise... ws rocks.
[17:34] cloudhead: not that you wouldn't be able to implement a websockets cache but yea
[17:34] binary42: Right.
[17:35] cloudhead: kk
[17:35] cloudhead: makes sense
[17:35] cloudhead: thanks!
[17:35] scudco has joined the channel
[17:35] binary42: Just not supported by... say, CDNs yes.
[17:35] cloudhead: yea
[17:35] cloudhead: WS is potentially less bandwidth intensive than xhr for pull requests though, right?
[17:35] binary42: np. Let me know if you have any issues. I haven't done a whole lot with ws yet but I'm working on some of it server side right now.
[17:36] cloudhead: cool
[17:36] binary42: WS could be more efficient but there isn't any gzip support IIRC so it's hit or miss.
[17:36] cloudhead: right right
[17:42] bryanl has joined the channel
[17:44] inimino: cloudhead: note that SPDY, if it catches on, will eliminate many of the performance issues with HTTP currently
[17:45] inimino: cloudhead: so it's best to stick with HTTP for "resources" and websockets for "events"
[17:45] inimino: and SPDY is just a transparent optimization at the HTTP layer
[17:50] cloudhead: inimino: interesting, that's what I've been thinking
[17:50] cloudhead: using http for pull, and websockets for push
[17:50] cloudhead: separating the concerns, and potentially the hardware too
[17:51] cloudhead: the pull server can talk to the push server
[17:51] cloudhead: and the client talks to both
[17:52] inimino: yes
[17:54] stephenlb has joined the channel
[17:56] jcrosby has joined the channel
[17:56] jamiew_ has joined the channel
[18:08] eddanger has joined the channel
[18:09] erichocean: cloudhead: that's how I implement websockets/http as well (with node.js)
[18:10] erichocean: dang, http://www.matrixssl.org/ has the best API for node.js, but their GPLd version is neutered
[18:11] erichocean: which means I guess I'll go with OpenSSL and managed BIOs (yuck)
[18:11] isaacs has joined the channel
[18:12] cloudhead: erichocean: code?
[18:12] ericflo has joined the channel
[18:13] erichocean: I built off of http://github.com/Guille/node.websocket.js
[18:13] erichocean: and use this for browsers that don't support WebSocket natively: http://github.com/gimite/web-socket-js
[18:14] isaacs: ryah_away: looking at the patch now
[18:15] isaacs: yeah, lgtm.  an extra set of parens would've solved it, too
[18:15] erichocean: SproutCore app loads via HTTP; makes secure web socket connection to node.js server; node.js server notifies HTTP server it wants specific kinds of events (e.g. pubhubsubbub, web hooks, etc.) and from then on servers as the intermediary between browser app and servner
[18:16] erichocean: I push/pull everything through node.js mainly due to bandwidth costs
[18:16] erichocean: but latency is better too
[18:25] cloudhead: erichocean: so it's a failover thing?
[18:26] erichocean: my apps don't work without a web socket
[18:26] cloudhead: ah ok
[18:26] erichocean: well, they don't work "online" without a web socket
[18:26] erichocean: the app runs offline just fine
[18:35] bry has joined the channel
[18:38] isaacs has joined the channel
[18:43] brosner has joined the channel
[18:52] bentomas has joined the channel
[18:55] rictic has joined the channel
[19:05] mikeal has joined the channel
[19:20] kriskowal has joined the channel
[19:29] ryah: felixge: still problems, eh?
[19:30] felixge:  ryah yeah, libeio hates me :|
[19:30] ryah: hmmm...
[19:31] felixge: there is a slight chance this is co-routine related
[19:31] felixge: as there are a bunch of wait() events from the children's require() calls
[19:32] ryah: what if we rewrite require() with sync calls
[19:32] ryah: so it doesn't use wait() ?
[19:33] felixge: ryah: should be little code duplicatoin
[19:34] felixge: actually let me make double sure that this problem only shows up in combination with I/O
[19:35] dnolen has joined the channel
[19:35] felixge: ok, yeah seems to be
[19:36] felixge: it doesn't occur if I take out the other stat calls
[19:38] felixge: ryah: the sync calls wouldn't go to libeio, right?
[19:42] inimino: right
[19:47] ryah: right
[19:47] ryah: only bad thing about that would be that require.async() would need a different implementation
[19:47] felixge: ryah: would you like me to try do the patch for that?
[19:48] felixge: ryah: yeah, but not too much
[19:48] felixge: I think most logic can be shared
[19:48] felixge: ryah: do we have a sync 'stat' call as well?
[19:48] ryah: i don't think anyone is actually using require.async() right now anyway
[19:48] ryah: yeah
[19:48] ryah: posix.statSync()
[19:49] ryah: (i'm not sold on these names)
[19:49] felixge: k
[19:49] ryah: um.. yeah if you want to try and do that - sure
[19:49] ryah: i could take a hack at it tonight too if you can wait
[19:49] ryah: and by tonight, i mean tomorrow morning CET
[19:49] felixge: ryah: do you want to do it? I don't mind sharing the fun, but I feel guilty for bringing all ths mess up :)
[19:50] ryah: 
ACTION wants hot require as much as everyone else :)

[19:50] felixge: :)
[19:50] felixge: cool
[19:50] felixge: so you are thinking about doing sync require as well as require.hot ?
[19:50] felixge: do you agree with the general approach I came up with?
[19:51] ryah: i haven't looked at it, actually
[19:51] felixge: well the main idea is that each module has its own cache object which by default is a reference to the parent object
[19:51] felixge: the only thing that changes on require.hot() is that you start out with a new fresh cache for that module (and all children)
[19:52] isaacs: 
ACTION has used require.async a bit

[19:52] felixge: isaacs: I don't think we would need to get rid of require.async
[19:52] felixge: essentially require.hot() would build on it
[19:52] isaacs: ok, great
[19:53] isaacs: require.hot should be called require.hawt because it'd be hawt
[19:53] inimino: 
ACTION did his own async code loading thing

[19:53] inimino: heh
[19:53] felixge: isaacs: hah! :)
[19:54] felixge: I sort of approve
[19:54] felixge: at least as an alias
[19:54] felixge: :)
[19:54] isaacs: 
ACTION definitely does not approve, and was just kidding, and should never ever be taken seriously, fr realz

[19:55] felixge: isaacs: lame
[19:55] felixge: I need APIs I can use while I'm drunk
[19:55] isaacs: hahah
[19:55] isaacs: ryah: hey, i think we need some kind of basic "nodejs design principles" doc.
[19:56] felixge: isaacs: yeah something like a node interface guideline
[19:56] isaacs: uri/url/etc is like the third or fourth bikeshedding dead-horse-beating contest i've seen that basically seems to have stemmed from a disagreemnet about what should or should'nt belong in node/lib
[19:57] felixge: isaacs: I'm still recovering from promises, hah :)
[19:57] isaacs: tell me about it!
[19:57] dnolen has joined the channel
[19:57] felixge: isaacs: thanks for putting all the work into it
[19:57] orlandov: isaacs: you guys going for concensus? or more friendly dictator style?
[19:58] isaacs: i srsly prefer the bdfl approach
[19:58] isaacs: especially if i
[19:58] isaacs: '
[19:58] isaacs: especially if i'm not the bdfl (and if i can type)
[19:58] isaacs: 
ACTION shoves ryah forward...

[19:58] erichocean: heh
[19:58] orlandov: bfdl + lieutenants is not a bad system
[19:58] felixge: bfdl ?
[19:58] isaacs: for resolving api shape, intractable bikeshedding, etc., yeah, it's essential.
[19:59] isaacs: bdfl = benevolent dictator for life
[19:59] felixge: hah
[19:59] felixge: sounds good
[19:59] felixge: the people of singapore would approve
[19:59] felixge: ;)
[19:59] orlandov: heh
[19:59] isaacs: i believe the term was coined in reference to guido van rossum and python
[19:59] felixge: for real, they have the best dictatorship in the world
[19:59] felixge: :)
[19:59] felixge: hehe
[20:00] erichocean: ryah: are prepare/check watchers in JS on the roadmap?
[20:03] kriskowal: isaacs, in turn, the python community stole the term from a monty python sketch, the python namesake
[20:03] ryah: erichocean: no- why do you want them?
[20:03] erichocean: SproutCore has a run loop that needs to be started before any other code, and "ended" (other code runs) after any other code
[20:03] felixge: ryah: anyway. Let me know if you want to do the sync require / require.hot stuff, otherwise I'll give it a shot 
[20:06] PowerToExt has joined the channel
[20:06] ryah: felixge: give it a shot
[20:06] felixge: ryah: alright :)
[20:07] ryah: erichocean: hmm..
[20:07] erichocean: with the move to OpenSSL, the user would be required to create an ssl.Connection object from an existing ssl.Context object, and pass that ssl.Connection object to connection.setSecure()
[20:08] erichocean: does that general approach work for you?
[20:08] ryah: are you making an openssl binding?
[20:08] erichocean: I'm replacing gnutls
[20:08] erichocean: which is buggy
[20:08] ryah: hm
[20:09] ryah: which part is buggy?
[20:09] ryah: the js interface?
[20:09] erichocean: http://skitch.com/onitunes/nq8rh/untitled-5
[20:09] erichocean: it's an internal problem with their state machine
[20:09] erichocean: though node.js can't resume a connection and make it secure
[20:10] erichocean: (but that's minor, and fixable)
[20:10] ryah: so, i'm rewriting all of the networking stuff and throwing out deps/evcom
[20:11] erichocean: uh oh
[20:11] erichocean: code?
[20:11] ryah: i haven't started on a new binding to tls
[20:11] erichocean: I'd be happy to do it
[20:11] ryah: http://github.com/ry/node/tree/net2
[20:12] ryah: erichocean: http://github.com/ry/node/blob/net2/lib/net.js
[20:12] ryah: erichocean: plus http://github.com/ry/node/blob/net2/src/node_net2.cc
[20:12] ryah: erichocean: and http://github.com/ry/node/blob/net2/src/node_io_watcher.cc
[20:13] pmuellr has joined the channel
[20:13] ryah: it has better buffering.
[20:13] ryah: i'm working on a low-level binding to the http parser now - then i'll rewrite the http server stuff on top of that
[20:14] ryah: (should be mostly lib/http.js)
[20:14] ryah: then i wanted to bind gnutls at a very low level (like individual functions) and hack it into lib/net.js
[20:14] felixge: ryah: why rewrite the http stuff?
[20:14] erichocean: is udns gone too?
[20:15] inimino has joined the channel
[20:15] ryah: not yet but probably 
[20:16] ryah: felixge: it doesn't really need to be rewritten, just the parts where it touches the c++ binding
[20:16] ryah: hopefully
[20:16] felixge: k
[20:17] ryah: so the new net.js stuff, i think, is going to be a lot faster
[20:17] ryah: it allows zero memcpy networking
[20:17] felixge: ryah: I'm somewhat interested in the MySql driver, how difficult do you think integrating that ASYNC lib you found would be?
[20:17] felixge: wow, nice
[20:17] felixge: finally node won't be that slow anymore *g*
[20:17] felixge: :)
[20:17] ryah: yeah
[20:18] erichocean: so basically you're just moving the buffering in evcom to JS, and exposing the raw socket with an IOWatcher?
[20:18] ryah: erichocean: yes
[20:18] erichocean: are you benchmarking this as you go?
[20:19] ryah: i haven't yet - it's pretty primative so far
[20:19] inimino: hehe
[20:19] inimino: ryah: are you using the V8 ExternalArrayData stuff?
[20:19] ryah: inimino: yeah
[20:21] erichocean: ryah: have you used Varnish cache before?
[20:21] ryah: erichocean: so, i wouldn't mind having help on a tls binding, but i have some exact ideas about how it should be done - so if you're intersted maybe we can email back and forth a bit
[20:21] isaacs has joined the channel
[20:21] inimino: cool, was just looking at that yesterday
[20:22] erichocean: ryah: I'm happy to do "exact ideas", this is basically the current project for me until it's done
[20:24] ryah: erichocean: no, haven't used varnish
[20:25] ryah: felixge: mysql driver, probably best to wait until this net2 settles down
[20:25] felixge: ryah: k
[20:25] ryah: well. i guess it does its own networking so perhaps they don't touch
[20:26] ryah: i think the lib is new, and you might find some bugs, otherwise it should be do able in a few days
[20:26] orlandov: ryah: is the net2 branch stable enough to attempt to port things to it?
[20:26] ryah: it would be fun for understanding how libev works
[20:26] felixge: k, I might not even get very far. I'm just looking for excuses to improve my C++, even if the code ends up being thrown out
[20:27] ryah: orlandov: no
[20:27] orlandov: so hold off for now?
[20:27] ryah: orlandov: it's almost entirely the same api anyway
[20:28] ryah: felixge: if you do, look at the postgres binding that i did
[20:28] felixge: ryah: yeah, will do
[20:28] ryah: the postgres library is totally different - but they are similar in difficulty :)
[20:29] erichocean: ryah: is the http_parser going to be modified to work on process.Buffers?
[20:29] ryah: erichocean: yeah
[20:30] ryah: erichocean: well, http_parser itself will stay the same, but the binding to it will just unwrap a buffer and get the pointer to the raw byte array
[20:31] ryah: so data gets passed from the raw socket (what comes out of recv()) through js, and into the http_parser
[20:31] ryah: 
ACTION has to go

[20:31] ryah_away: erichocean: check out lib/net.js - it's very similar to evcom.c - i want to integrate tls the same way that was done in evcom.c but in net.js
[20:32] erichocean: k
[20:32] kriszyp has joined the channel
[20:33] ryah_away: (so js bindings to gnutls_record_recv() / _send() )
[20:36] evilhackerdude has joined the channel
[20:48] bentomas has left the channel
[20:49] bentomas has joined the channel
[20:51] orlandov: anyone mind if i add a link to my node-mongodb bindings on the node wiki?
[20:51] orlandov: it's pretty much ready for light use
[20:55] bentomas: orlandov: doesn't sound like it
[20:55] orlandov: :)
[20:59] n8o_ has joined the channel
[21:02] n8o__ has joined the channel
[21:11] qFox has joined the channel
[21:17] hassox has joined the channel
[21:17] jcrosby has joined the channel
[21:18] hassox: morning ppl;s
[21:18] isaacs: hassox: yo
[21:19] hassox: hey man
[21:19] hassox: what's news?
[21:19] isaacs: i've been reading your chain spec.  it's a shame you live in such a distant timezone.
[21:19] isaacs: if you must be in the southern hemisphere, could you move to argentina or something so it'd be easier to collaborate in our overlapping hours?
[21:19] hassox: yeah makes things hard sometimes
[21:19] isaacs: or be nocturnal or something?
[21:19] hassox: hehe
[21:20] hassox: 3 kids and a 2 hours commute makes it a bit difficult to be nocturnal ;)
[21:20] isaacs: yikes
[21:20] isaacs: well, i'm sure they'd love argentina.
[21:20] isaacs: they could learn to speak spanish.
[21:20] hassox: haha
[21:20] hassox: I'd like to
[21:20] hassox: learn spanish that is
[21:21] hassox: I'm updating the spec now with the beforeSendBody functions
[21:21] hassox: what's ur thoughts
[21:21] isaacs: i'm kind of brewing a spec that is not chain and not sns but might deliver the best of  both worlds.
[21:22] isaacs: i'd also like to do it in such a way that a fab-ish bubble dls could easily sit on top.
[21:22] isaacs: k, gotta run, lunch
[21:22] hassox: fab-ish
[21:22] hassox: kk
[21:22] jacobolu_ has joined the channel
[21:22] hassox: talk later then
[21:44] jacobolus has joined the channel
[21:50] n8o has joined the channel
[21:58] botanicus_ has joined the channel
[22:02] RayMorgan_ has joined the channel
[22:03] jamiew has joined the channel
[22:09] michaelk^ has joined the channel
[22:10] grantmichaels has joined the channel
[22:10] n8o has joined the channel
[22:11] richtaur has joined the channel
[22:20] LuigiMontanez has joined the channel
[22:21] hassox has joined the channel
[22:25] jed has joined the channel
[22:26] mahemoff has joined the channel
[22:53] RayMorgan has joined the channel
[23:06] bentomas has left the channel
[23:14] felixge has joined the channel
[23:14] creationix has joined the channel
[23:17] dnolen_ has joined the channel
[23:19] creationix: Has anyone here ever used CoffeeScript http://bit.ly/6h5JKO
[23:19] creationix: it's a javascript superset (compiles to pure js)
[23:20] creationix: I was thinking something like that might be useful for all the people on the mailing list who try to make node act like ruby
[23:23] jed: ha, i don't think i've observed that particular phenomenon.
[23:32] JiMBastard has joined the channel
[23:32] orlandov: oh cool, i didn't know that coffeescript would generate boilerplate for you too
[23:33] orlandov: looking at the arguments slicing
[23:39] mikeal has joined the channel
[23:39] jed: between coffeescript and underscore, jashkenas has been really prolific. both libraries are simple, concise, and really cleanly documented.
[23:42] cloudhead has joined the channel
[23:43] felixge: ryah_away: won't finish sync require tonight, its a bit more work than I thought
[23:44] jamiew has joined the channel
[23:47] robrighter has joined the channel
[23:52] isaacs: it is a shame that coffeescript is in ruby and not javascript.
[23:52] isaacs: if it was, it would be possible to write it in coffeescript
[23:56] alexiskander_ has joined the channel