[00:00] kriskowal: it's just a matter of separating the ability to resolve and reject from the ability to observe resolution and rejection
[00:00] felixge: kriskowal: that distinction is purely based on prior art, nothing else gives those words the meaning you describe
[00:00] bentomas: bentomas: I think it is ugly, but definitely gives you more flexibility with what you can return
[00:00] tmpvar: alright, 2 hours of jsdom then im going to make some music!
[00:00] bentomas: guan: I see now why inimino went with arrays, sorry it took me a little while
[00:01] kriskowal: perhaps i should be making the point that the problem can be solved either by a different name or by a different behavior.  the latter would be better, the former would be very decent, and doing nothing would be unacceptable
[00:01] [k2] has joined the channel
[00:01] guan: kriskowal: so what behavior would you prefer?
[00:02] bentomas: felixge: it seems like if you are going to go with the array approach then separate functions for emitSuccess and emitError wouldn't be necessary, just fulfill([val, 1])
[00:02] felixge: kriskowal: well, promises have big "Wanted: Dead or Alive" printed right now. So the name and behavior is likely to change
[00:02] kriskowal: so, in E, there's a defer() function that returns a [promise, resolver] pair
[00:02] guan: kriskowal: i mean, what are you advocating as the default mechanism?
[00:02] felixge: bentomas: oh, you wouldn't pass in the array
[00:03] felixge: bentomas: you'd only use the array for returning.
[00:03] kriskowal: in javascript it makes more sense to use named-key objects than positional-value arrays, so i recommend that there's a way to create an object that has promise and resolver components, perhaps additional methods for convenience
[00:04] kriskowal: var deferred = new Deferred(); deferred.promise, deferred.resolve(moreResolvedValue)
[00:04] kriskowal: sec…i will gist an example
[00:05] kriszyp: seriously, crockford named E? I thought crockford didn't get excited about ocap until 2006-7-ish
[00:06] kriskowal: E ain't old
[00:06] kriszyp: 97?
[00:06] kriszyp: hasn't miller been working on it for over a decade? the wikipedia article says 97
[00:07] kriskowal: he and doug worked together at xanadu
[00:08] binary42 has joined the channel
[00:08] kriszyp: huh, interesting. Anyway, I guess this is just silly trivia, feel free to resume useful discussion :)
[00:10] kriskowal: guan fleixge http://gist.github.com/305128
[00:12] kriskowal: the important point to take home is that if you give two, mutually suspicious fellows (say, an advertisement and a login widget) the same promise, they should not be able to use it to communicate with each other
[00:13] kriskowal: another important thing to take home is that, in practice, it will never be necessary to create a promise object directly, and rarely necessary to create a deferred object (only necessary in callbacks that don't have a backward communication channel, like setTimeout)
[00:14] kriskowal: because "then" and "when" take care of that for you
[00:14] tmpvar: isaacs, yo
[00:14] isaacs: yo
[00:14] guan: kriskowal: still parsing…
[00:15] guan: kriskowal: could you spell this out for me or point me to some background reading? for example, what does the last invocation of when do?
[00:16] tmpvar: isaacs, how you feelin man?
[00:16] isaacs: tmpvar: quite good.
[00:16] kriskowal: in any case, my abject inability to communicate these ideas isn't sufficient reason to dismiss them.  i highly recommend mark's thesis, which is very readable http://www.erights.org/talks/thesis/
[00:16] tmpvar: good!
[00:16] tmpvar: im looking at sax.js to implement innerHTML in jsdom
[00:16] tmpvar: (setter)
[00:17] kriskowal: "when/then" are like addCallback/addErrback
[00:17] guan: kriskowal: another idea: could you just a few examples of how, say, normal i/o would work?
[00:17] isaacs: tmpvar: interesting.
[00:17] guan: (i'm a n00b at all this, including javascript, sorry)
[00:18] isaacs: tmpvar: so, you'd have to implement the HTML wacky stuff to do that, right?
[00:18] kriskowal: the neat thing about promises is that you can use them to construct APIs that look like synchronous APIs, by being very explicit that what you once thought was a return value is now a promise
[00:18] tmpvar: isaacs, im assuming the user is not a complete retard ;)
[00:18] isaacs: tmpvar: !!!
[00:18] isaacs: tmpvar: you can't do that!
[00:18] tmpvar: hey
[00:18] isaacs: tmpvar: haven't you leared anything? we're idiots!
[00:18] tmpvar: haha
[00:18] kriskowal: so, supposing that you had an FS API that would accumulate all of the contents of, say, a file.  FS.read(path)
[00:19] tmpvar: isaacs, well.. as soon as you land it, i'll be sure to follow suit
[00:19] tmpvar: ^_^
[00:19] isaacs: tmpvar: kewl, nicely played.
[00:19] tmpvar: but yeah, i summoned you to ask a question.. but noticed that there are docs (AMAZING)
[00:19] kriskowal: the analogous promise-oriented API would be FS.read(path).then(function (content) {…})
[00:20] isaacs: tmpvar: i usually try to keep the README.md up to date.
[00:20] tmpvar: cool cool, i should have this in a few
[00:20] isaacs: if you see a discrepancy feel free to send a patch. or post an issue, and i'll do it.
[00:20] tmpvar: oh, i will
[00:20] kriskowal: which is *interesting* because, if you wanted to write a function that worked with any higher order function that *may* return a promise, *or* return an immediate value, you can use "when"
[00:20] guan: kriskowal: i like that; what about errors?
[00:20] kriskowal: when(FS.read(), function (content) {…})
[00:21] kriskowal: in that case, FS.read() can be either sync or async and it doesn't matter.
[00:21] kriskowal: and if it's sync, when doesn't have to enqueue an event; it can call immediately
[00:21] kriskowal: which is great for performance.
[00:21] kriskowal: when(value, ok, error, progress)  and  promise.then(ok, error, progress) are the full signatures
[00:22] tmpvar: oh noez!  innerHTML will have to be async
[00:23] isaacs: tmpvar: oh noez?
[00:23] tmpvar: heh, i can't provide a callback with a setter
[00:23] kriskowal: and, alas, kriszyp, apologetically my only reference is that markm told me so once
[00:23] bentomas has left the channel
[00:24] isaacs: oic
[00:24] kriszyp: thats good enough for me :)
[00:24] tmpvar: isaacs, i know its horrible, but can i .wait() on parser.write() ?
[00:24] isaacs: tmpvar: actually, parser.write() isn't async
[00:24] isaacs: it doesn't return a promise.
[00:24] bentomas has joined the channel
[00:25] isaacs: it just processes the entire string you give it.
[00:25] tmpvar: how about that
[00:25] isaacs: the idea is that it's up to you to decide how much is enough, and when to parse it, and so on
[00:25] bentomas: guan: this thread on the node mailing list has a lot about the different Promise implementations and suggestions http://groups.google.com/group/nodejs/browse_thread/thread/4a1ce27a1f588a7f/cc472954284b9c63
[00:25] guan: kriskowal: progress does what? does it just receive report on progress or does it receive data? (in the i/o example)
[00:25] tmpvar: isaacs, perfect
[00:25] kriskowal: isaacs, tmpvar: aye, it's sync but in-memory, so there's no latency
[00:25] bentomas has left the channel
[00:25] kriskowal: progress is an augmentation on the original idea that kriszyp proposed
[00:25] isaacs: tmpvar: so, it'll be slow if you dump a big file in it, but you can give it however much of whatever you have.
[00:26] isaacs: and it'll return after calling all the attached callbacks.
[00:26] tmpvar: i like
[00:26] guan: bentomas: thanks, i'll read that first
[00:26] kriskowal: the idea is that some kinds of promises can periodically emit notifications when progress toward resolution is made, in the form of a value of 0-1 or undefined for indefinite
[00:28] kriskowal: there's a lot of good prior art on promises, even in javascript http://waterken.sourceforge.net/web_send/#API
[00:30] kriskowal: like, in high latency interactions like RPC, implementations can be tuned to "pipeline" promises to decrease the number of round trips.
[00:30] guan: kriskowal: is what you've just described somewhere in that huge long thread from mid december?
[00:30] kriskowal: i don't think so; i think people have been proceeding without looking into the origins of the term
[00:31] kriskowal: so, in that context you might as well read the word "promise" as "fancy callbacks"
[00:32] kriskowal: which is understandable; "promise" is such a wonderful metaphor that it's easy to assume that you know what is meant by it just by the name.
[00:32] brosner has joined the channel
[00:33] kriskowal: like "html5" means "html4 + ponies"
[00:33] guan: ponies?! :)
[00:33] kriskowal: yeah, i want a pony.  html5 is going to give me a pony.
[00:33] kriskowal: clearly that means <holodek> tags
[00:33] guan: stupid/silly question: if I need to invoke things in sequence - like a posix api where i need to run open(), write(), close(), rename() in that order - i would still need to nest these calls in repeated function arguments to then(), correct?
[00:34] mattly has joined the channel
[00:34] kriskowal: ah, .then and when return new promises that resolve to the value returned by the callback
[00:34] guan: aaaaaaah
[00:34] guan: that's my pony
[00:34] kriskowal: which means they can be both nested and chained
[00:34] kriskowal: the callback can also return a new promise
[00:35] kriskowal: to further defer
[00:35] brosner has left the channel
[00:36] kriskowal: open(path).then(function (stream) {return stream.read()}).then(function (content) {…})
[00:37] kriskowal: more importantly, since the first then call did not register an errback, the rejected value gets forwarded to the next then
[00:37] kriskowal: which means you can model try/catch asyncly; not every function has to deal with the exception; it can percolate to future turns, just like they can percolate up the call stack
[00:38] guan: in your example three lines up, what if you need to close the stream after that?
[00:38] guan: you'd have to return [content, stream] or something like that?
[00:38] kriskowal: or nest, yeah
[00:39] guan: works for me
[00:39] guan: bentomas: what do you think of all this?
[00:41] kriskowal: so, the trick is that, if node decides that doing proper promises is undesirable for performance/style reasons, it's entirely possible to build this on top of a callback system.
[00:41] kriskowal: so, if ryan would prefer to redact these things, and make some room in the first-class module namespace, i'd be just as happy
[00:42] guan: so you'd a low-level i/o api that just uses callbacks or something simple, and we could implement this on top
[00:42] davidjrice: gwoo: ping!
[00:42] gwoo: yo dude
[00:42] davidjrice: good news
[00:43] davidjrice: http://github.com/brainfucker/hashlib < working c based hashing library
[00:43] gwoo: no way
[00:43] gwoo: great name
[00:43] gwoo: haha
[00:43] davidjrice: though it may need some variants (base64,binary,hex) it now has a hmac_sha1 function
[00:44] gwoo: awesome!
[00:44] davidjrice: felixge just fixed the wee bug in http://github.com/davidjrice/node-twitter-oauth
[00:44] davidjrice: it's now generating http headers the right way.
[00:45] gwoo: nice!
[00:45] davidjrice: just, unauthorised ones :)
[00:45] gwoo: hehe
[00:45] gwoo: even with the new hashlib?
[00:45] felixge: the hash libs are *not* the problem
[00:46] felixge: at least it's very unlikely
[00:46] felixge: the mistakes seem to be within the construction of the data to sign
[00:46] felixge: but oauth is a bitch of a spec
[00:46] gwoo: felixge: i compared it to the out of php hash lib
[00:46] davidjrice: possibly, need to extract and test a bunch of that
[00:47] gwoo: with the same exact keys etc
[00:47] mikeal has joined the channel
[00:47] felixge: gwoo: should produce the same , no?
[00:47] gwoo: it should
[00:47] felixge: at least for base64
[00:47] gwoo: but it doesnt
[00:48] gwoo: in other words i took all the necessary data we generated before passing to the hash lib
[00:48] gwoo: put that into my php script and got a different output
[00:48] felixge: show me
[00:49] cloudhead has joined the channel
[00:50] gwoo: maybe davidjrice can give you some data to test
[00:50] gwoo: i can't work on it right now
[00:50] gwoo: but i did spend several hours trying to verify that it was indeed the hashlib
[00:50] gwoo: believe me i thought it was our generation of the signature data
[00:51] gwoo: but ultimately more tests proved otherwise
[00:51] gwoo: especially since i could compare it to the oauth lib i wrote
[00:51] felixge: gwoo: I think you guys went wrong about the way you were using the JS lib
[00:51] felixge: anyway
[00:52] gwoo: ok that is possible
[00:52] gwoo: how would you use it?
[00:52] gwoo: it seemed pretty straight forward to me
[00:52] felixge: the hash lib actually does fuck up base64 padding
[00:52] davidjrice: felixge: the js libs in dep are actually ones I just made up
[00:52] gwoo: felixge: i added a =
[00:52] gwoo: is that wrong?
[00:52] gwoo: probably
[00:52] felixge: gwoo: yes. But for fixed size key it should work
[00:53] felixge: * fixed sized signature
[00:53] ryah: I'm going to s/sendBody/send/ soon
[00:54] ryah: also change the 'body' event to 'data' and 'complete' to 'end'
[00:54] guan: kriskowal: i'm trying to understand how errors are passed on; does this look right? http://gist.github.com/305163
[00:55] gwoo: ryah: nice and simple
[00:56] davidjrice: felixge: okay, so I cleaned up some things in the node-twitter-oauth example to avoid confusion
[00:56] konobi: ryah: don't you just love making a 4 line change to a file and dramatically increasing speed?
[00:56] davidjrice: do you think it is likely an issue with base64 encoding hex instead of binary?
[00:56] ryah: konobi: yes
[00:56] ryah: :)
[00:56] ryah: what change was that ?
[00:57] felixge: ryah: you got the two promise patches I linked you?
[00:57] gwoo: davidjrice: yeah that's possible though i did try to compare it before the base64 too
[00:57] ryah: felixge: yeah.. let me do those now
[00:57] konobi: ryah: change to the RSP codebase
[00:58] felixge: davidjrice: I gotta go now, but I have to say oauth uses a freaking insanely error-prone signature mechanism. And signature problems aren't exactly easy to debug. I'd have to sit down with a working client and spend a few hours, unlikely to happen anytime soon :(
[00:59] davidjrice: yeah, it's not that fun :)
[00:59] davidjrice: no worries, thanks for looking. I think I have a direction here
[00:59] felixge: davidjrice: one more bug for the go: http://github.com/davidjrice/node-twitter-oauth/blob/master/bin/twitter-oauth-http.js#L45
[00:59] felixge: davidjrice: encodeURIComponent("") should probably be encodeURIComponent(url)
[00:59] davidjrice: fuck!
[01:00] felixge: davidjrice: you're still using the wrong signature so
[01:00] felixge: davidjrice: use the hashlib.b64_hmac_sha1() function without any surrounding base64 call, append an '=' if it doesn't do that for you
[01:01] felixge: after that I'd sit down with a working client in a language you know well and compare your output step by step. Use fixed time stamps (hack the client if neccesary) until you get the same output and signatures
[01:02] gwoo: felixge: that's exactly what i did :)
[01:02] davidjrice: felixge: cool, sorted the url one easy
[01:02] davidjrice: I don't see a b64_hmac_sha1 function...
[01:02] davidjrice: one sec
[01:03] gwoo: well i want to try with hashlib
[01:03] gwoo: cause we didnt have that before
[01:04] felixge: davidjrice: http://github.com/davidjrice/node-twitter-oauth/blob/master/dep/node-crypto/sha1.js#L26
[01:04] gwoo: felixge: http://github.com/davidjrice/node-twitter-oauth/blob/master/dep/node-crypto/sha1.js#L15
[01:04] gwoo: can we add the = there?
[01:04] gwoo: that is actually what i did for my tests
[01:04] felixge: gwoo: yes, that's much better
[01:05] felixge: gwoo: didn't see that :)
[01:05] gwoo: ok cool
[01:05] gwoo: too bad it didnt work :)
[01:05] felixge: gwoo: let me make sure this function is right before I leave
[01:05] gwoo: ok cool
[01:06] tmpvar: isaacs, so there are a couple cases in which sax.js is not suited for innerHTML heheh.. brb
[01:07] isaacs: <br>
[01:07] felixge: gwoo: yes, it is working. This: base64_encode(hash_hmac('sha1', 'my-value', 'my-key', true))
[01:07] felixge: gwoo: is identical to this: crypto.b64_hmac_sha1('my-key', 'my-value')
[01:07] felixge: gwoo: (after the modification with the padding)
[01:07] davidjrice: gwoo: felixge: okay, pushed changes for all of the previous issues. (cheers)
[01:08] felixge: good luck guys, but its certainly the vodoo associated with the signing, not the hmac that is causing issues now
[01:09] gwoo: felixge: try these http://pastium.org/view/a868f0fb215364ad1d90710617002f60
[01:09] davidjrice: felixge: deadly, I'll work on with both
[01:09] davidjrice: thanks a bunch! g'night. 
[01:10] felixge: gwoo: getting identical signatures
[01:10] gwoo: ok cool
[01:10] CIA-77: node: 03Mark Hansen 07master * r98e61db 10/ (lib/sys.js test/mjsunit/test-sys.js): sys.inspect(Date) now shows the date value - http://bit.ly/9PAKAi
[01:10] felixge: have fun, or at least try to survive :)
[01:10] gwoo: thanks i thought i was going crazy
[01:11] gwoo: but it was 4am so i probably was 
[01:11] felixge: crazy is trying the same thing over and over again while expecting different results :)
[01:11] gwoo: hehe, i remember someone said that before :P
[01:14] felixge: gwoo: well, people have come up with new forms of crazy - but this is a good sanity check I use sometimes :)
[01:14] felixge: anyway, gn8
[01:15] tmpvar: isaacs, <a href='#something'/>
[01:15] tmpvar: isaacs, <span>Welcome,</span> to monkey land
[01:15] isaacs: tmpvar: that should work, no?
[01:16] tmpvar: it was complaining due to the /
[01:16] tmpvar: but, i have a feeling its the '
[01:16] isaacs: hrm.  seems like a bug
[01:16] CIA-77: node: 03Yuichiro MASUI 07master * r1793ee1 10/ (src/node.js test/mjsunit/test-promise.js): Fixed: promise late chain - http://bit.ly/a47DdH
[01:16] CIA-77: node: 03Ryan Dahl 07master * r95fd370 10/ src/node.cc : Remove unused variable - http://bit.ly/9LCgfB
[01:16] tmpvar: and the second example is sort of "known" because im guessing you expect a full <start>asdfasfd</end> type structure
[01:17] tmpvar: well, <start>..</start> hehe
[01:17] tmpvar: an outer wrapping of text nodes
[01:20] isaacs: tmpvar: in strict mode, yeah, but in loose mode, that should be fine
[01:20] kriskowal: guan yeah, that should work fine
[01:22] tmpvar: ill simplify
[01:27] CIA-77: node: 03Jonas Pfenniger 07master * r80ace36 10/ test/mjsunit/test-promise-wait.js : Added failing test: promise.wait() after promise.emitXXX() - http://bit.ly/cMF1xo
[01:27] CIA-77: node: 03Felix Geisendörfer 07master * r490cac0 10/ src/node.js : 
[01:27] CIA-77: node: Fix Promise.wait() for fired promises
[01:27] CIA-77: node: Failure introduced in 80ace36e4cb287c36b44c6b986c5e5dea2b1c825 - http://bit.ly/aR51J3
[01:28] ryah: felixge: --^
[01:28] ryah: thanks
[01:33] tmpvar: isaacs, http://gist.github.com/305190 -- am I doing something wrong?
[01:33] kriskowal: guan: and here's an example of error recovery http://gist.github.com/305189
[01:34] isaacs: tmpvar: you need to do .close() when you're done writing
[01:34] isaacs: otherwise it doesn't know that the text node is done with.
[01:34] isaacs: since that might be the first chunk, and there may be another chunk coming
[01:34] tmpvar: i see
[01:35] tmpvar: isaacs, looks like its stripping out all the non-whitespace :: http://pastie.org/826495
[01:36] isaacs: ok, that's odd.
[01:36] tmpvar: same test, with a .close() btw
[01:37] isaacs: yep
[01:37] isaacs: reproducing: http://gist.github.com/305195
[01:37] isaacs: not sure why it's seeing 3 spaces.
[01:37] isaacs: that's bizarre.
[01:38] tmpvar: fun!
[01:39] masuidrive has joined the channel
[01:40] guan: kriskowal: on line 8, do you mean then() ?
[01:40] kriskowal: yes
[01:41] guan: i'm getting the hang of this! ;-)
[01:41] guan: is this what's implemented in events.js in your fork of narwhal?
[01:42] kriskowal: it's implemented by both kris zyp's "promise" and my "events".  i recommend using kriszyp's
[01:42] kriskowal: and i intend to make this work in node, even if just in a fork
[01:42] davidjrice: gwoo: and just about to fade for the night. 
[01:42] isaacs: tmpvar: ah, i see it.
[01:42] tmpvar: nice
[01:42] kriskowal: i think kriszyp has made promises work as such in a node library
[01:42] guan: great
[01:42] gwoo: davidjrice: ok, im gonna give it another swing later
[01:42] davidjrice: gwoo: just to let you know, I think you're right re: invalid hasing / signature http://gist.github.com/305197
[01:43] gwoo: davidjrice: ok we'll hunt it down
[01:43] davidjrice: I cleaned up a bunch of other bits and pieces, it's now generating the base string exactly as expected ( i think)
[01:44] davidjrice: I also made the requests goto the term.ie oauth test server. Gives nicer debugging output
[01:44] isaacs: tmpvar: fixed in my master.
[01:44] tmpvar: wooord
[01:44] tmpvar: thanks man
[01:44] isaacs: np
[01:44] isaacs: nice find
[01:44] davidjrice: gwoo: deadly, we'll have an oauth library at some point :)
[01:44] gwoo: darn right :)
[01:45] tmpvar: wow, its already the end of the node world? heh heh
[01:45] tmpvar: oauth, hotness
[01:46] mattly has joined the channel
[01:46] sudoer has joined the channel
[01:46] tmpvar: isaacs, perfect
[01:46] tmpvar: i am experiencing some other weirdness.. but I think its my fault haha
[01:47] tmpvar: that definitely fixed the whitespace issue though
[01:47] tmpvar: thx
[01:48] kriskowal: guan here's one api design http://gist.github.com/305202
[01:48] kriskowal: felixge ^
[01:49] masuidrive has joined the channel
[01:54] masuidrive has joined the channel
[01:58] randomekek: isnt node's fs.read already async?
[01:58] guan: kriskowal:  WIN
[01:59] cloudhead: inimino: around?
[02:02] masuidrive has joined the channel
[02:17] masuidrive has joined the channel
[02:18] brandon_beacher has joined the channel
[02:24] tmpvar: kriskowal, interesting
[02:25] kriskowal: aye
[02:28] tmpvar: music time! peace
[02:33] joshbuddy has joined the channel
[02:33] joshbuddy has joined the channel
[02:41] felixge has joined the channel
[02:41] felixge has joined the channel
[02:45] kriskowal has joined the channel
[02:47] binary42 has joined the channel
[02:48] rektide: binary42: my last 99 red balloons cover was first thing this morning, AFI.
[02:48] rektide: y tu?
[02:48] binary42: rektide: ?
[02:49] rektide: "It's been far too long since I listened to some "99 Red Balloons" covers."
[02:49] binary42: Ah.
[02:49] binary42: Yeah.
[02:49] binary42: It was awhile. So I hit one on shuffle mode.
[02:49] binary42: And then decided to listen to a few in a row.
[02:50] binary42: And by awhile I mean something like 6 mo's.
[02:50] rektide: cant really recommend the AFI one.  its not awful, just... unremarkably.
[02:50] binary42: Just so much music to hear that I have a hard time visiting it all.
[02:50] rektide: s/y//
[02:50] binary42: Hmm. The song itself is quite resilient.
[02:51] binary42: It takes it's abuse in stride. 
[02:51] binary42: There are songs that lend themselves to it... and others that don't like anything from the Beatles.
[02:51] guan: Did they ever make a single of Homer Simpsons singing it in that episode with the German backpackers?
[02:52] binary42: Uhm... never saw that but I guess I soon will.
[02:53] Connorhd_ has joined the channel
[02:54] joshbuddy has joined the channel
[02:54] joshbuddy has joined the channel
[02:54] binary42: 
ACTION can't seem to find footage. Oh well. Homer is enough for the imagination alone.

[02:55] guan: 
ACTION thinks this is the episode: http://en.wikipedia.org/wiki/The_Heartbroke_Kid

[02:58] inimino: cloudhead: I'm around
[02:59] sudoer has joined the channel
[03:07] bronson has joined the channel
[03:10] steadicat has joined the channel
[03:20] joshthecoder has joined the channel
[03:25] joshbuddy has joined the channel
[03:25] joshbuddy has joined the channel
[03:27] kriskowal has joined the channel
[03:32] sztanpet has joined the channel
[03:33] joshbuddy has joined the channel
[03:33] joshbuddy has joined the channel
[03:37] malkomalko has joined the channel
[03:38] tmpvar has joined the channel
[03:44] stephenlb: node v8 question: setTimeout with timeout less than 10ms --> does this honor the less than 10ms timeout or is the floor always 10ms?
[03:46] cdorn has joined the channel
[03:49] stepheneb has joined the channel
[03:49] tmpvar: stephenlb, i dont know offhand, but I'd guess its the same as chrome
[03:53] bpot has joined the channel
[03:53] stephenlb: tmpvar: makes sense.
[03:54] tmpvar: sort of silly if you ask me heh
[03:55] tmpvar: http://www.gamedev.net/community/forums/topic.asp?topic_id=127700 -- ding
[03:55] tmpvar: high perf timers exist.. must be missing something fundamental..
[03:56] creationix has joined the channel
[03:56] dnolen has joined the channel
[03:56] tmpvar: wut wut, just got (slightly modified) pure + sizzle running on jsdom!
[03:56] tmpvar: wow, this is quite a milestone here
[03:59] creationix: congrats
[03:59] tmpvar: thanks!
[03:59] tmpvar: http://gist.github.com/305272
[04:00] tmpvar: lots to change if im going to run sizzle/pure natively
[04:00] tmpvar: 
ACTION = pissed at the lack of operator overrides in js

[04:03] creationix: if it does help we're getting the ability to define non-enumerable properties soon (as soon as ryan pulls latest v8)
[04:04] creationix: and v8 does have magic getter and setters
[04:04] tmpvar: like { get aprop() { return 1; } } ?
[04:04] creationix: yep, not sure if it helps any
[04:05] tmpvar: haha, i've already been using that :X
[04:05] tmpvar: works fine
[04:05] creationix: I'm excited about Object.defineProperty, we can finally stop deciding between breaking for ... in and not extending Object.prototype
[04:06] tmpvar: i probably should keep up with that :P
[04:06] tmpvar: been nose to the grind stone for a few weeks now
[04:06] creationix: understandable
[04:06] tmpvar: a dom level 1 in js, cmon ;)
[04:12] JimBastard: level 1 dom ninja
[04:14] tmpvar: haha, i feel like i've gone to hell and back, no lie
[04:16] tmpvar: now I just need sizzle/pure to run un-modified as to no kill my upgrade path (aka social life)
[04:16] tmpvar: s/no/not
[04:17] tmpvar: victory smoke
[04:17] JimBastard: woot
[04:17] JimBastard: you gotta optimize your social life. thats why i always rage out when i actually leave the bat cave
[04:22] arlolra has joined the channel
[04:24] arlolra: anybody using the redis client w/ v0.1.28?
[04:32] gwoo has joined the channel
[04:57] guan: kriskowal: just looked at kriszyp promise.js - so there's not currently an implementation of this that runs on node?
[04:57] kriskowal: working on it
[04:57] kriskowal: i think there might be
[04:58] kriskowal: you'd have to ask him about it though; i think he uses it for pintura and perstore
[04:58] kriskowal: oh, http://github.com/kriszyp/node-promise
[04:59] kriskowal: guan ^
[04:59] guan: aha!
[04:59] sveisvei has joined the channel
[05:50] creationix has left the channel
[05:53] jashkenas has joined the channel
[06:04] kennethkalmer has joined the channel
[06:07] masuidrive has joined the channel
[06:11] edspencer has joined the channel
[06:21] creationix has joined the channel
[06:25] jspiros has joined the channel
[06:30] eck has joined the channel
[06:32] eck: does anyone have any logging libraries that they'd recommend? i'm specifically looking for something that can do file logging w/ node
[06:36] tmpvar: i dont think there is such a library
[06:36] tmpvar: it should be fairly easy to build up though
[06:36] tmpvar: using posix
[06:36] tmpvar: er.. the posix module
[06:41] steadicat has joined the channel
[06:48] stepheneb has joined the channel
[06:49] eck: the other question i had is -- what's the best way to write a daemon using node? the posix module seems to be missing a lot of the required functions, and I can easily write a C program that does the whole fork/setsid/close fds/etc. dance and then exec the node program, but it seems a bit silly
[07:05] steadicat has joined the channel
[07:22] edspencer has joined the channel
[07:23] cadorn has joined the channel
[07:28] dnolen has joined the channel
[07:42] felixge has joined the channel
[07:42] felixge has joined the channel
[07:45] mAritz has joined the channel
[07:46] mAritz: good morning node.js :)
[07:47] piranha has joined the channel
[07:53] felixge: mAritz: happy birthday you mean?
[07:53] felixge: :)
[07:58] gwoo: felixge: arent you supposed to be sleeping?
[07:58] felixge: gwoo: and rising
[07:58] felixge: :)
[07:58] felixge: its 9am here
[07:58] gwoo: must be those dreams of forkmaster again
[07:58] zmoog has joined the channel
[08:00] edspencer has joined the channel
[08:09] mAritz: oh, right. HAPPY BIRTHDAY! wooooo! :)
[08:11] creationix has joined the channel
[08:12] felixge: mAritz: I'm wondering what would be a good birthday present
[08:12] mAritz: a good framework :P
[08:14] mAritz: i'm not quite getting how middleware works.
[08:14] mAritz: when are those promised examples coming? :P
[08:15] mAritz: (talking about (fab))
[08:15] ryah: hi
[08:17] mAritz: happy birthday ryan :)
[08:17] mAritz: (node.js === ryan) right?
[08:17] felixge: mAritz: no, node.js = node.js :)
[08:18] mAritz: heretic, burn him!
[08:18] felixge: first commit in git is: "Date:   Mon Feb 16 01:02:00 2009 +0100"
[08:18] ryah: check this out
[08:18] ryah: http://github.com/ry/node/tree/0e9e927fcb71d44524340ae4f0392bd1dcced7fb
[08:18] ryah: hehe
[08:18] ryah: crazy readme
[08:19] mAritz: yep :D
[08:19] mAritz: reminds me of the way nationstates.org writes the world assembly decisions
[08:19] felixge: ryah: what happened to Tim Becker?
[08:20] ryah: we spent some late nights discussing it, but he never did any programming
[08:21] ryah: do you know him? my friend from cologne
[08:21] ryah: i think he knows you
[08:21] felixge: ryah: no, but you mentioned him before I think
[08:21] felixge: ryah: maybe he does, but he only could through CakePHP I think
[08:22] ryah: maybe he met you through timo?
[08:22] ryah: well whatev:)
[08:22] felixge: ah, I know timo
[08:22] felixge: so maybe that's the connection
[08:23] felixge: ryah: so what's the deal with the net2 branch? Do you know where the performance problems are?
[08:24] ryah: no
[08:24] felixge: good, so here is hope they can be overcome :)
[08:24] ryah: it's seeming like it's just the VM overhead.
[08:24] ryah: i haven't got to spend a great deal of time looking at it
[08:25] ryah: put i have spent multiple days trying to make it faster without luck
[08:25] felixge: ryah: what's keeping ya busy? The message queue stuff?
[08:25] ryah: yeah. node-amqp is almost usable 
[08:25] ryah: so i think this week i'll have another look at net2
[08:25] ryah: node-amqp, btw, uses net2
[08:26] felixge: oh good :)
[08:27] ryah: but i'm going to start changing interfaces before i merge net2 - because i don't want to wait any longer
[08:27] felixge: ryah: cool
[08:27] ryah: posix -> fs, receive -> data, eof -> end
[08:27] ryah: sendBody -> write
[08:27] ryah: i think send -> write too
[08:27] felixge: btw. bentomas is doing some cool work on continuables
[08:27] felixge: The main points being: Single callback, single value
[08:27] felixge: makes things a lot easier
[08:28] ryah: so this next release is going to break the api majorly
[08:28] felixge: cool :)
[08:29] felixge: anyway, it would suck if net2 couldn't be made fast due to the VM :(
[08:29] ryah: yeah. i need to push some things forward. it's becoming more and more difficult to change stuff
[08:30] ryah: yes, it would suck
[08:30] felixge: would you be willing to buy the bullet for the advantages net2 gives? Or maybe see how much needs to be internal to be fast enough?
[08:30] ryah: i don't know.
[08:30] felixge: ok
[08:31] ryah: so one thing is, it's not just for tcp servers. i want to use this interface to, do stdio, for example
[08:31] felixge: but stdio is probably not a performance critical?
[08:31] ryah: which there isn't any obvious benchmark for, and i wouldn't feel so bad about a 10% hit
[08:32] ryah: basically http2 is fast enough for any real purpose
[08:32] felixge: right
[08:32] felixge: and -c 50k is not a common use case
[08:32] ryah: it's just that everyone starts up "hello world" servers and hits it with ab and makes decisions based on that result
[08:32] ryah: which, like it or not, is important
[08:32] felixge: especially since response time variation is already terrible at 5-10k clients waiting for the same mssage
[08:33] felixge: so you wouldn't want to handle more with a single box for realtime stuff
[08:33] felixge: right, that's because benchmarking is hard
[08:33] felixge: and most people do not understand it
[08:33] felixge: :|
[08:34] ryah: but you look at v8 and they'll go way out of their way to hit certain benchmarks
[08:34] ryah: even if they arn't very realistic
[08:34] ryah: so - it might just be that we'll have to have a web server implemented in c
[08:35] felixge: which would suck
[08:35] felixge: but oh well :)
[08:35] felixge: it may just be worth it
[08:35] ryah: yeah - but i think it's too early to throw in the towel 
[08:35] ryah: i'm going to poke at net2 some more
[08:36] ryah: i'm also not totally sold on the Buffer class...
[08:36] ryah: it's pretty hrad to work with 
[08:36] felixge: ok
[08:36] ryah: the strings with "binary" encoding arn't bad.
[08:36] ryah: they're super fast, they have all these nice string ops
[08:36] felixge: well I think the sooner net2 is the main branch, the more you'll be motivated to optimize it : ).
[08:37] felixge: I'm ok if the initial merge has a performance hit
[08:37] ryah: on the other side of things, i think net2 is massively more maintainable
[08:37] ryah: so in the long run that is perhaps more valuable than 10% improvement in "hello world" requests
[08:38] ryah: shrug
[08:38] ryah: net2 also is missing SSL
[08:38] ryah: which is going to be a bit of work
[08:38] ryah: meh.
[08:38] ryah: :)
[08:38] felixge: : )
[08:38] felixge: who did that initially?
[08:39] ryah: net2? 
[08:39] felixge: ssl support
[08:39] felixge: maybe he could put it in net2 :)?
[08:39] ryah: or ssl - well it's been in evcom for a long time - rhys did the bindings to js
[08:40] ryah: i think i will switch to openssl though
[08:40] felixge: yeah, that should be more portable and on more system
[08:40] ryah: mostly because it's more available and not LGPL
[08:40] felixge: (i think)
[08:41] ryah: gnutls has a better api, imo
[08:41] gwoo has joined the channel
[08:43] ryah: yeah. so. node at one year.
[08:43] ryah: i told tim this was going to be huge. he didn't really believe me:)
[08:43] felixge: ryah: tim didn't?
[08:43] gwoo: ryah: congrats!
[08:44] ryah: he's a skeptical bank guy
[08:44] felixge: :)
[08:44] felixge: ryah: yeah, big congratz on what you have done with node so far
[08:44] felixge: it's amazing
[08:46] ryah: yeah - i'm happy people are using it. I'm happy you started using it, back in, like, september when i told you not to
[08:46] felixge: :)
[08:46] felixge: ryah: I think it was June
[08:47] ryah: oh really? wow
[08:47] felixge: ryah: git log says so :)
[08:47] felixge: ryah: btw. it also says there were ~50  contributors
[08:47] felixge: which I think is really really cool
[08:48] ryah: 2009.09.26 is the first email i have from you
[08:48] ryah: :)
[08:49] felixge: ryah: http://groups.google.com/group/nodejs/browse_thread/thread/efbae1ec1e67786c
[08:49] ryah: er
[08:49] ryah: 2009.06.26
[08:49] felixge: is my first message to the mailing list I think
[08:50] felixge: initially I was just planning node for the upload
[08:50] felixge: but then I liked it so much I rewrote all my PHP :)
[08:50] felixge: turned out less code and easier to maintain
[08:50] felixge: so I was happy from day 1
[08:50] felixge: :)
[08:51] ryah: 
ACTION needs to come up with something to talk about at jsconf

[08:51] ryah: voodootikigod wants mroe than "something about node"
[08:52] felixge: heh
[08:54] gwoo_ has joined the channel
[08:56] ivan has joined the channel
[08:56] ryah: i think i want to work on an 'end game' in mind
[08:56] ryah: like - in 4 months, say, node is going to be done.
[08:56] ryah: like TeX
[08:56] ryah: some set of goals that define what it means to be done
[08:57] ryah: something like - bugless http, dns, tcp, workers, and a moduler module system
[08:57] felixge: that'd be nice
[08:59] felixge: even so I wouldn't mind see node to continue evolving
[08:59] felixge: so 1.0 shouldn't be the end I think : )
[08:59] felixge: but maybe it should, and new stuff should be addons
[08:59] felixge: not sure
[08:59] ryah: well. in any case i guess it's far away
[09:01] Connorhd has joined the channel
[09:03] ryah: there are bots of my chat.nodejs.org
[09:03] ryah: or something at least.
[09:04] ryah: s/of/on/
[09:06] mAritz: btw: what's the status of hot code loading? :D
[09:08] ryah: mAritz: i need to review it - and i haven't got around to it yet
[09:10] ryah: i think we need to have a sync require before - and the sync require patch was somehow changing behavior of timers
[09:11] mAritz: hmkay :/
[09:13] ryah: we could merge that anyway - i don't think it's a big deal
[09:13] ryah: but i'd kind of like to understand what's happening
[09:16] teemow has joined the channel
[09:18] felixge: ryah: zimbatm is working on refactoring the module system I bit right now. Maybe you should wait for his patch as well, could make it even easier to build sync on top - or maybe he'll do that himself
[09:18] felixge: adding hot reloading is like a 3-5 line patch at this point, so anybody who really needs it can do it
[09:20] micheil: ryah: I don't suppose you'd be interested in writing a very short article for howtonode.org on the first year of node?
[09:24] ryah: micheil: i'm going to write a roadmap email - maybe that's good enough?
[09:36] eck: on the off chance that you folks are still around; do you know if it's safe to fork in v8? is that something that could be added to the posix module, or would it break things?
[09:37] ryah: eck: one problem is that ATM all the file descriptors will be duplicated in the forked process
[09:38] eck: that's true
[09:38] eck: you couldn't just close 'em right after forking, because of the event loop
[09:38] ryah: there isn't anything fundementally wrong with it though
[09:38] eck: ok
[09:38] eck: i'm trying to think about how to daemonize my program
[09:39] eck: i've been thinking about just having a helper process in C that sets things up
[09:39] eck: and then execs node when the time is right
[09:40] felixge: eck: do you need to run on a privileged port?
[09:40] eck: no, i just want to be parented to init, be a session leader, etc.
[09:40] ryah: in new code i'm trying to set FD_CLOEXEC on the fds
[09:42] eck: so if i tried to add fork(2) support to the posix module, and then did the forking nonsense at the beginning before doing any i/o, it would probably work?
[09:42] eck: (assuming i added the other helper functions like flock and setsid as well)
[09:45] ryah: probably - i don't think i'm ready to add that at the moment though...
[09:45] ryah: it should probably be done as process.fork() isntead of posix
[09:46] eck: ok, i might take a stab at it this week
[09:46] eck: i looked at some of the other simple posix wrapper functions and it looks fairly simple
[09:46] ryah: but if you have a use for it - and you do it - i'd be interested to see it :)
[09:46] ryah: i think the main problem with having it currently is the fds. it'd be nice if they were closed automatically
[09:47] eck: well it sounds like using FD_CLOEXEC is the way to go then
[09:47] ryah: it wouldn't be too hard to throw some CLOSEXEC flags in evcom
[09:50] eck: heh, it would be nice if you could just pass it in as an option to exec
[09:50] ryah: yeah totally
[09:50] eck: since doing getdtablesize() and closing all of the file descriptors is really common when you're execing anyway
[09:50] jdee has joined the channel
[09:51] jdee: hi, is it possible to add a listener that fires when a variable changes?
[09:52] eck: i'm out, i'll report back if i get the fork thing working
[09:52] eck has left the channel
[09:57] ryah: jdee: no
[09:58] ryah: jdee: you can easily wrap up an object though, which does that
[09:59] mAritz: thanks to getters and setters. wooohooo :)
[10:00] mAritz: (but, you actually could do an interval that checks the variable for changes every second or so. i highly suggest not to do that, though)
[10:02] jdee: thanks chaps. much appreciated.
[10:08] ryah: night
[10:14] jdee has joined the channel
[10:32] micheil: ryah_away: maybe, I'll have to talk to creationix 
[10:44] markwubben has joined the channel
[11:09] lifo has joined the channel
[11:11] mAritz: micheil: while your at it: beat him with something large. haml-js is cool. haml-jquery is cool. topcloud is cool. but havign 3 different syntaxes for the templates in each? fuck no, not cool.
[11:12] micheil: hmm?
[11:12] mAritz: creationix
[11:12] micheil: tim didn't write haml for node, as far as I know
[11:12] mAritz: :D
[11:12] mAritz: yes he did
[11:12] micheil: visionmedia did.
[11:12] mAritz: http://github.com/creationix/haml-js#
[11:12] micheil: or not
[11:12] mAritz: no, tj wrote sass
[11:13] mAritz: node-sass anyways.
[11:13] micheil: but then again, jquery has to be different.
[11:13] micheil: I'm pretty sure haml-js conforms with ruby's haml syntax
[11:13] micheil: if not, fork the project, write the tests to the haml spec, and contribute them back
[11:14] micheil: then, with time (and failing tests) the implementation should catch up.
[11:14] micheil: mAritz: personally, I just use something simple.
[11:14] mAritz: haml-js is absolutely fine. haml-jquery, meh... as you say it has to be different. but topcloud? i don't see it. and i don't have the time to do anything sadly... :(
[11:15] mAritz: i think i'll just stick with jquery-pure
[11:16] mAritz: complicated syntax but more powerful for now
[11:17] mAritz: </rant>
[11:32] jed has joined the channel
[11:41] kjeldahl has joined the channel
[11:48] jdee_ has joined the channel
[11:58] pdelgallego has joined the channel
[12:13] micheil: mAritz: I think I'll stick with javascript pure, it's far nicer then jquery-pure
[12:14] micheil: like, srsly. (no, really though, plain javascript _has_ to be better then jquery.)
[12:16] markwubben_ has joined the channel
[12:26] eikke has joined the channel
[12:33] pdelgallego has joined the channel
[12:38] alex-desktop has joined the channel
[12:40] dekz has joined the channel
[12:40] jed: can someone clarify for me how .listen() works?
[12:41] jed: if i have a server created like this:
[12:41] jed: http.createServer( app ).listen( 4000, "jedbook.local" )
[12:41] jed: shouldn't it NOT respond to any host other than jedbook.local?
[12:42] joshbuddy has joined the channel
[12:42] joshbuddy has joined the channel
[12:42] jed: aka, shouldn't any requests from http.createClient( 4000, "localhost" ) fail?
[12:47] mAritz: could be that localhost is always allowed?! (don't know though, just an idea)
[12:48] jed: hrm, i don't really know either. shouldn't request from 127.0.0.1 fail?
[12:51] morgan has joined the channel
[12:51] micheil: jed: I think it's tyodo with you hosts file config
[12:51] frodenius: nah you can only bind to ips, not names
[12:51] micheil: or that
[12:52] frodenius: jedbook.local is 127.0.0.1 too
[12:52] micheil: jedbook.local 127.0.0.1:8080
[12:52] micheil: I think works
[12:52] micheil: as a hosts file config
[12:54] jed: so if i have 127.0.0.1 mymachine.dev in my hosts file,
[12:55] jed: shouldn't requests to localhost fail if i've specified mymachine.dev in the listen method?
[12:56] lifo has joined the channel
[13:13] felixge: jed: hey, how are you?
[13:13] jed: felixge: good, how about you?
[13:13] jed: felixge: when do we get to see ugly?
[13:14] mAritz: btw: how the fuck are we to know what exactly was changed in the github wiki of node? i always see changes, but have a hard time figuring out, what is new. am i just not seeing the history or is there really none? (except the possibility to look at old versions... wohooo -.- )
[13:15] felixge: jed: ugly will be released very soon :). But I have some bad news, I won't make it to JSConf :(
[13:15] jed: felixge: booooooo!
[13:15] felixge: jed: but on the bright side, I'm looking to make up for it with a long-distance trip sometime later this year - how long will you be in japan?
[13:15] guan has joined the channel
[13:15] jed: felixge: unclear right now, i'm still doing a trial run.
[13:16] jed: definitely thru april, perhaps beyond.
[13:16] felixge: mAritz: blame github : /. 
[13:16] felixge: jed: ah, but you probably won't be there in Oktober or something?
[13:16] jed: mAritz: yeah, i almost think we should give up on wikis and use a repo subdirectory of .md files.
[13:16] jed: felixge: if i decide to stay, than most certainly.
[13:17] felixge: jed: not an option since ryan won't want to maintain that :)
[13:17] jed: felixge: japan could use you, i'm the only noder out here apparently.
[13:17] felixge: jed: oh alright. Well it'd make for a very exciting trip, and you being there gives me a very plausible excuse to make it a "business trip" :)
[13:18] felixge: so let me know when that decision comes around :)
[13:18] jed: i make a decent tour guide by now, too: http://www.flickr.com/photos/tr4nslator/sets/72157622370017533/
[13:18] jed: yeah, keep me posted and i'll do the same.
[13:18] felixge: oh wow
[13:18] felixge: that looks awesome
[13:18] jed: so many calories, so little time.
[13:19] jed: felixge: i was getting a little bogged down in fabland, but am on the rebound.
[13:19] felixge: hah, I can handle it. I'm very happy to give up a few years of live expectancy in exchange for food that tastes good
[13:19] felixge: :)
[13:20] jed: thinking i might extend the (fab)iness to server matching too.
[13:21] jed: felixge: http://gist.github.com/305517
[13:21] jed: yeah, i ate a lot of weird stuff on that trip: whale, blowfish, etc.
[13:21] felixge: jed: not sure if you should do that
[13:22] felixge: jed: at least it looks like it cause trouble for very little gain
[13:22] jed: what kind of trouble?
[13:23] mAritz: what kind of gain?
[13:24] jed: i'm pretty sure i'd like to change the syntax to this for an app: http://gist.github.com/305517#file_app.js
[13:25] jed: mAritz: i'd like a way of specifying an entire site in one file a la sinatra, without relying on implementation specific code mixed in.
[13:26] jed: in other words, i'd like to have platform-independent app files that can be loaded easily into various server implementations.
[13:26] felixge: jed: any feature is trouble, always :)
[13:27] mAritz: i don't know ruby/sinatra. but what exactly is the gain here? you'd only save 2-3 lines and have more things to learn.
[13:27] richardb has left the channel
[13:27] jed: well, i'm not sure it's a new feature. i'd be using it instead of this magic of evaling custom fab files.
[13:27] pmuellr has joined the channel
[13:27] jed: mAritz: i'm not sure what you mean... what lines do i save?
[13:28] felixge: jed: I don't see the benfit in evaling custom fab files either
[13:28] felixge: it seems like a weird feature
[13:28] felixge: to give fab it's own binary
[13:28] felixge: * executable
[13:28] jed: i don't think i'm doing that.
[13:29] jed: the only difference is that you can either require("fab") to define an app, or require("fab/server") to define a server.
[13:30] jed: the server implementation just wraps createServer to handle (fab) apps.
[13:31] mAritz: the 2-3 lines saved from writing require('http'); http.createServer().listen();
[13:32] mAritz: then again, i don't understand (fab)... (i tried, and i'd like to. but haven't made it so far.)
[13:32] jed: mAritz: the point is less to save lines, and more to separate server and app, so the latter can be reused across platforms eventually.
[13:34] jed: mAritz: lemme know if there's anything you don't grok about (fab). i'm usually here when i have connectivity.
[13:35] micheil: felixge: ryan could create the repo, then add the people who are really active in the wiki as collaborators, and then they manage it
[13:35] mAritz: jed: the entire concept. and middleware. :D
[13:36] mAritz: i think the promised middleware examples would help a lot.
[13:36] jed: mAritz: well, i'm working on eliminating the idea of middleware right now.
[13:36] mAritz: oh, ok
[13:36] jed: middleware is confusing because it's a special case in most implementations.
[13:36] felixge: micheil: I don't know, maintaining a wiki is tons of work. We'd need to find a few really dedicated people for it
[13:36] mAritz: authentication is a very common usage though?!
[13:36] jed: in the next rev of (fab), middleware will just be another handler that takes two apps instead of one.
[13:36] felixge: probably somebody who is the main maintainer
[13:37] micheil: felixge: as it is, I've been doing it
[13:37] felixge: micheil: the current github wiki?
[13:37] micheil: yeah
[13:37] micheil: look at the drop down on say modules or the homepage
[13:37] felixge: micheil: I didn't know - github wiki sucks :)
[13:38] micheil: :P
[13:38] mAritz: btw: all changes to ry/node/wikis/node-users are listed as done by felixge. enormously helpful.... -.-
[13:38] jspiros has joined the channel
[13:38] mAritz: (i know, githubs fault :D )
[13:38] felixge: mAritz: that sucks
[13:38] felixge: :(
[13:38] micheil: node-users is new to me
[13:38] jed: and i just thought felixge was THAT good.
[13:38] mAritz: :D
[13:39] felixge: unfortunately I don't know any wiki software I actually like
[13:39] felixge: wiki's never really worked for me
[13:39] mAritz: (haha, i really did laugh at that and my collegues now think i'm looking at funny porn. (beacuse everything is porn for one of them))
[13:41] micheil: felixge: I could knock something simple up using ruby/sinatra and grit
[13:41] mAritz: the one in redmine is simple and okay, if you ask me.
[13:41] micheil: but I'd rather not
[13:41] micheil: redmine isn't simple though
[13:41] micheil: redmine is a beast
[13:41] mAritz: the wiki? compared to real wikis, it is.
[13:42] nsm has joined the channel
[13:43] micheil: felixge: do you have commit priviledges?
[13:43] micheil: felixge: because node-users should really be /users
[13:44] micheil: or /Community
[13:44] micheil: or something
[13:45] micheil: 
ACTION added himself to node-users.

[13:45] jed: felixge: what about something like this? http://gist.github.com/305517#file_server_alternative.js
[13:46] jed: felixge: a (fab) approach to subdomains, for example.
[13:47] micheil: man,.. (fab) always get's me with it's amount of ()'s
[13:47] felixge: jed: interesting
[13:47] micheil: it's almost crazy :P
[13:47] jed: nice, almost.
[13:47] felixge: jed: I don't know, if I was you I'd go step by step and get the basic path handling awesome first and then move on with more stuff :)
[13:48] felixge: micheil: no commit privileges, gotta fight for every patch I want merged :)
[13:48] jed: ha, i thought path handling was done...
[13:48] jed: ah, i see what you mean. the stuff we talked about the other day.
[13:48] felixge: micheil: again github wiki could still let me edit a page title / url if I'm the creator :(
[13:48] jed: yeah, working on that now.
[13:48] felixge: micheil: I can't even delete it
[13:48] felixge: jed: yeah
[13:49] felixge: jed: I mean its quite simple to write your own dispatcher that dispatches to several fab apps, so I'd not try to solve a problem that isn't a problem right now
[13:49] felixge: :)
[13:52] jed: felixge: good point.
[13:53] creationix has joined the channel
[13:59] r11t has joined the channel
[13:59] micheil: quick, tim!
[14:03] pdelgallego has joined the channel
[14:05] jed: felixge: did anyone win the internet beer for guessing ugly yet?
[14:06] felixge: jed: no
[14:07] olivvv: Hi. do you know if it will be soon possible to test node.js on windows ?
[14:07] jed: dirty : key/value store :: ugly : ??? ... hmmmmmm.
[14:09] joshbuddy has joined the channel
[14:09] joshbuddy has joined the channel
[14:09] brosner has joined the channel
[14:09] felixge: jed: ok, I'll give it away. It's a hack that allows you to use PHP (or any language) from within node.js
[14:10] jed: ha, ugly!
[14:10] mAritz: ugly: parses brainfuck to generate node.js apps? where's my beer? i'm at zoologischer garten. gogogo
[14:10] felixge: jed: on top I'll build a mysql client lib
[14:10] mAritz: damnit
[14:10] jed: felixge: i'm really curious to see what your approach will be.
[14:11] jed: felixge: how will it be different than dbslayer, for example.
[14:12] mAritz: function(php_code) { sys.exec('php ' + php_code);}   !!!!!111one
[14:12] davidsklar has joined the channel
[14:13] felixge: mAritz: not quite as bad :)
[14:13] felixge: jed: it will be worse than dbslayer :)
[14:14] felixge: jed: basically its just a long running PHP script that communicated via stdio
[14:14] mAritz: but: why? haven't you learned from things like hiphop? :(
[14:14] felixge: mAritz: learned what?
[14:14] jed: felixge: interesting.
[14:14] mAritz: that anyone who tries to make php useful gets all the hate there is. :D
[14:15] felixge: I'm calling this project ugly because it will never be a good solution for anything. But it should be a very practical solution to access certain libraries node does not offer yet in other languages
[14:15] felixge: until node has native implementations
[14:16] mAritz: sounds reasonable.
[14:16] jed: felixge: ah, nice.
[14:16] felixge: the main challenge is values that cannot easily be serialized into meaningful JSON
[14:16] felixge: like resource identifiers
[14:16] felixge: or complex objects
[14:16] felixge: but I think I found a workable reference system to handle those
[14:16] jed: oh, you're actually going to parse on that level?
[14:17] felixge: jed: the idea is that you can call any PHP function
[14:17] felixge: the return value will either be a JSON encoded primitive
[14:17] felixge: or a reference if JSON makes no sense
[14:17] felixge: the reference would just be a UUID
[14:17] felixge: so if you later call a PHP function using this reference as a variable, it will be susbstituted for the real thing
[14:17] felixge: within the PHP script
[14:17] jed: ah, neat.
[14:18] felixge: https://gist.github.com/9439d16dcdcf060c47a7
[14:18] felixge: that's the worker
[14:18] felixge: the idea is that you could implement this in any language
[14:19] felixge: but I know PHP extremely well and it has a *huge* set of default library unmatched by pretty much anything
[14:19] felixge: plus most interfaces are not object oriented
[14:19] felixge: which as sucky as it is, makes this hack a lot easier
[14:21] jed: that'll do an awful lot for node adoption. very clever.
[14:21] felixge: mostly ugly :) 
[14:21] jed: so the mysql library will be called "stupid"?
[14:22] felixge: jed: I like that
[14:22] felixge: dirty, ugly and stupid
[14:22] felixge: :)
[14:22] jed: or how about sickly (sqly)?
[14:22] felixge: that I like as well
[14:22] jed: makes me nauseous just thinking about it.
[14:23] felixge: I'm still debating if I should support eval or not :)
[14:23] felixge: But I probably will, since its very very ugly
[14:23] felixge: :D
[14:23] jed: masochist.
[14:24] kriszyp has joined the channel
[14:29] creationix: mAritz: are you still up?
[14:30] mattly has joined the channel
[14:34] johan-s has joined the channel
[14:36] bentomas has joined the channel
[14:43] dnolen has joined the channel
[14:43] ashb: does node generally prefer studlyCaps or under_scores ?
[14:43] ashb: failCaps it seems. hm
[14:44] bryanl has joined the channel
[14:50] mAritz: creationix: yep.
[14:50] pdelgallego has joined the channel
[14:50] mAritz: creationix: it's 15:50 here ;)
[14:51] creationix: ok, cool
[14:51] creationix: it 8:50 here
[14:51] jdee: my browser gives up after 60 seconds and timesout a long request i want to keep. any way of making the timeout longer?
[14:52] jdee: its to a http.createServer
[14:52] creationix: jdee: set the timeout to 0
[14:53] mAritz: there's a default timeout somewhere :D
[14:53] jdee: any idea where?
[14:53] jdee: will this.timeout(0) inside my createserver method do it?
[14:54] creationix: connection.setTimeout(timeout)
[14:54] jdee: isnt that just for tcp?
[14:54] creationix: hmm, not sure
[14:54] mAritz: http is tcp+stuff
[14:54] jdee: ah :/
[14:55] mAritz: creationix: what's up? why did you ask, whether i'm up? ^^
[14:55] jdee: so i'm setting up with
[14:55] jdee: var server = http.createServer(function (req, res) {
[14:55] cloudhead has joined the channel
[14:55] jdee: will server.timeout(0) do it?
[14:55] mAritz: yep
[14:55] creationix: I was reading the logs, something about a big stick
[14:55] mAritz: no
[14:55] jdee: lol
[14:55] mAritz: arg... server.setTimeout(0)
[14:55] jdee: genius. thanks bud, your a superstar
[14:56] mAritz: creationix: oh, not necessarily a stick. anything big will do.
[14:56] creationix: lol
[14:56] mAritz: :)
[14:56] jdee: bah Object #<a Server> has no method 'setTimeout'
[14:57] mAritz: i was going through the chain of looking at haml-js -> haml-jquery -> topcloud. i knew haml before, no biggy. haml-jquery is reasonably similar, not a big problem either. but then a completely different view-language for topcloud? why? :/
[14:57] sztanpet: http://nodejs.org/api.html#_tcp
[14:57] sztanpet: look for setTimeout
[14:58] creationix: mAritz: topcloud is a different beast alltogether
[14:58] creationix: it's much higher-level, than haml
[14:58] sztanpet: the tcp conenction of the http server is in the .connection member if i remember correctly
[14:58] creationix: it actually uses jquery-haml under the hood
[14:59] sztanpet: so server.connection.setTimeout(0)
[14:59] Booster has joined the channel
[14:59] mAritz: but why not just use haml then?
[15:00] mAritz: jdee: listen to sztanpet!
[15:00] jdee: im listening! im listening!!!! :) server.connection.setTimeout seems to bork but this.connection... from inside looks good so far!
[15:01] sztanpet: it might not exist yet, yea
[15:01] sztanpet: it also can happen that you need to set the connecting clients timeout
[15:02] [k2] has joined the channel
[15:02] Booster has joined the channel
[15:02] jdee: ah cool thanks!
[15:03] creationix: mAritz: jquery-haml isn't a templating language, it's a dombuilder
[15:03] mAritz: yes. but haml-js is. ;D
[15:03] mAritz: or haml
[15:03] creationix: it can bind events and create in-memory closures
[15:03] creationix: exactely, and topcloud is a component framework
[15:03] creationix: they're three distinct projects
[15:04] creationix: they arose out of real-world needs at my past jobs
[15:05] mAritz: i'd just like to have a good haml-view-based mvc. :D
[15:07] creationix: then haml-js is the one you want
[15:07] creationix: express has it included, that's probably the closest thing yet
[15:09] atcrabtree has joined the channel
[15:12] mAritz: yes, i even added the new pre-compile/optimize stuff to the express views. but tj hasn't pulled it yet and i don't see it happening right now.
[15:13] creationix: I'm focussing on mvc in the browser, so I don't plan on writing a full rails style framework for server-side node
[15:14] gf3 has joined the channel
[15:15] mAritz: yep, i know. i'd be ok with that though, if it were haml xD
[15:16] mAritz: don't take me too seriously though. i'll just use pure for now on the client side and something else (not decided yet) on server side.
[15:26] jdee: hmm im trying to call server.connection.setTimeout(0) but it seems the server is never created in time for me to do the call
[15:31] mAritz: server.createServer().listen().connect.setTimeout(0) maybe?
[15:31] mAritz: (just guessing though)
[15:33] jdee: ah got it from the request object in the server. thanks for your time maritz.
[15:34] jdee: req.connection.setTimout(0)
[15:34] inimino: happy birthday node!
[15:39] dnolen has joined the channel
[15:39] gsf has joined the channel
[15:40] jashkenas has joined the channel
[15:42] bentomas: isaacs: you around?  
[15:45] bentomas: guess not!
[15:47] steadicat has joined the channel
[15:48] kriszyp: bentomas: I'll get node-promise tested and complete so you can use it
[15:49] dnolen has joined the channel
[15:49] kriszyp: my intent is now to have node-promise consist of utility functions (most importantly when()) that work properly with Node's promises
[15:51] bentomas: kriszyp: so it wouldn't be a commonjs promise implementation?
[15:51] kriszyp: and I want to create a node-commonjs project that will include a promise monkey patch that upgrades process.Promise to commonjs compliance (.then() function support), but you won't need that to use node-promise, that's only if you want process.Promise to have a .then() function
[15:51] pdelgallego_ has joined the channel
[15:51] kriszyp: which would basically port over the patch I made for node, as a monkey patch (instead of source code patch)
[15:52] kriszyp: it is the commonjs promise implementation that you want, or just the when() function (and other utility functions)?
[15:53] bentomas: well, I guess the then function and being able to chain the then functions along
[15:53] kriszyp: ok
[15:53] bentomas: (and manipulate the result as you go)
[15:54] kriszyp: note that when() gives you that same functionality, but it just different syntax:   when(when(somePromise, function(value){ return value + 1), function(valuePlusOne){ ... });
[15:55] kriszyp: but .then() is certainly nice, at least IMO, as it reads cleaner
[15:55] kriszyp: anyway, thanks for giving me the motivation to get this done :)
[15:57] bentomas: yeah, I'm in favor of putting the inconvenience on the developer of the libraries as opposed to the users of libraries.  the "when" function the users have to require themselves, where as if the developers use a commonjs compatible promise implementation then the users get the "then" function for free.
[15:58] kriszyp: 
ACTION nods

[16:07] inimino: this is why I want to see promised pulled out of node core and put in a separate library
[16:07] inimino: bentomas: are you doing something with continuables?  I saw something in the scrollback.
[16:08] bentomas: I've been working on a library http://github.com/bentomas/node-continuables 
[16:08] bentomas: yesterday there was some discussion about how errors should be handled
[16:10] cloudhead has joined the channel
[16:10] bentomas: inimino: trying to make it as simple as possible, I just pushed another commit
[16:10] bentomas: I liked your "either" function from your fileIO module
[16:10] bentomas: well, as simple as possible while supporting chaining the callbacks
[16:12] tmpvar has joined the channel
[16:12] bentomas: inimino: but it still might be a bit more than what you are interested in.  I know you like simple
[16:13] Zoka has joined the channel
[16:16] inimino: bentomas: ah, ok
[16:17] bentomas: inimino: If you remember, I asked for your feedback on it a couple days ago.  Though, I have simplified it since then (it no longer caches the value).  
[16:19] Zoka: Simple fix to make Eclipse debugger useful http://github.com/zoka/node/commit/4beae45f3479f9556297806bda0bb3723a1a227e
[16:19] inimino: bentomas: yeah, I remember it now, sorry
[16:20] inimino: 
ACTION had to see the code to jog his memory

[16:20] ashb: i'm still not convinced by promises syntactically - i can't quite get my head around hte amount of nested fns
[16:21] inimino: node looks in ~/.node_libraries ?
[16:22] bentomas: inimino: it does!
[16:22] inimino: cool
[16:22] bentomas: asb: well checkout my continuables library, I agree with you, and I'm trying to avoid that http://github.com/bentomas/node-continuables
[16:23] deanlandolt: ashb ^^
[16:23] binary42 has joined the channel
[16:34] ashb: deanlandolt: thanks :)
[16:34] ashb: bentomas: most irc clients do tab-completion on nicks btw
[16:35] bentomas: ashb: Woah!  That's awesome! thanks!
[16:35] ashb: :)
[16:35] bentomas: (sorry about the typo)
[16:35] bpot has joined the channel
[16:36] ashb: right.
[16:36] ashb: 
ACTION attempts to parse that example

[16:37] ashb: process.nextTick is akin ot setTimeout(0) ?
[16:37] bentomas: yeah
[16:38] bentomas: here is a gist with some more real world looking examples: http://gist.github.com/305252
[16:38] ashb: you know - i'm sure a lot of my complaint with nested functions would go away if we could use 'fn' or something shorter than 'function' :)
[16:38] bentomas: the asyncWrite.js shows how it works with Node's promises 
[16:38] bentomas: yeah, but I'd still hate having lots of nested functions
[16:39] bentomas: it is harder to keep track of the flow of the program
[16:39] ashb: yeah.
[16:40] kennethkalmer has joined the channel
[16:40] ashb: hmmm that is slightly nicer i think.
[16:40] ashb: i like chaining fns anyway
[16:48] pdelgallego has joined the channel
[16:49] gsf: agreed that chaining is better than nesting
[16:50] gsf: difficulty of reading nesting demonstrated by http://howtonode.org/control-flow-part-iii, despite the clean code
[16:51] malkomalko has joined the channel
[16:55] jdee: is there any way to get the server time via node?
[16:56] jdee: or a timestamp of some sort?
[16:57] bentomas: new Date() ?
[17:01] jdee: of course, sorry :(
[17:01] jdee: forgetting the basics while learning all this new stuff
[17:05] Harrison has joined the channel
[17:07] jashkenas has joined the channel
[17:07] creationix: gsf: which part is hard to read?
[17:08] CIA-77: node: 03Zoka 07master * rfbef11b 10/ (src/node_net.cc src/node_timer.cc): 
[17:08] CIA-77: node: Use InstanceTemplate() instead of PrototypeTemplate() for accessor methods
[17:08] CIA-77: node: This fixes crash that used to happen when Eclipse debugging session hits the
[17:08] CIA-77: node: breakpoint that is set either in timer or connection callback. - http://bit.ly/aJkkpo
[17:08] mattly has joined the channel
[17:08] creationix: gsf: I'm trying real hard to find a way to make code easy on the eyes, any suggestion is welcome
[17:10] cloudhead: creationix: I think it's just the nature of async chaining, nothing wrong with your code
[17:10] creationix: I know it's the nature of async code, I'm just hoping we can ease the pain a little
[17:11] creationix: I see the ugly syntax required a real turnoff to people wanting to learn node
[17:11] creationix: I think that's why there had been so much discussion about promises on the list
[17:11] creationix: it's critical to everything
[17:11] cloudhead: yea for sure
[17:12] cloudhead: I've been looking into this too
[17:12] cloudhead: the problem is asynch is inherently more complex than synch, there's nothing we can do about that
[17:12] cloudhead: but we can ease the pain for sure
[17:12] creationix: I find the continuable style the cleanest so far, but I like the code Kris posted the other day too
[17:12] cloudhead: and find a syntax which works, and is straightforward
[17:13] ryah_away: Zoka: hey! thanks so much!
[17:13] ryah: Zoka: we've got a debugger now!
[17:13] jashkenas has left the channel
[17:13] cloudhead: continuable style, I agree, but it seems to have some limitations
[17:13] Zoka: No problem, you are welcome
[17:14] creationix: http://gist.github.com/305202 looks neat
[17:14] cloudhead: one benefit of promises is to be able to attach callbacks at arbitrary points in the code, as you pass the promise down
[17:14] bentomas: cloudhead: what limitations?
[17:14] bentomas: ahh
[17:14] creationix: I like how "when" can take either sync or async functions
[17:15] bentomas: yeah, when is nice, but there is nothing preventing it from working with the continuable style
[17:15] cloudhead: bentomas: yea, basically the ability to easily add callbacks at different code points
[17:15] creationix: cloudhead: I'm not sure that's a good thing, attaching a callback later on seems wrong to me
[17:15] bentomas: cloudhead: can you give me an example with a gist?
[17:16] bentomas: creationix: but I don't like how when puts the async responsibility on the user, not on the library writer
[17:16] cloudhead: bentomas: I got an example in a lib I'm working on actually, gimme a sec
[17:17] cloudhead: bentomas: http://github.com/cloudhead/cradle/blob/master/lib/cradle.js#L217
[17:17] cloudhead: write-through caching
[17:17] creationix: "when" isn't any harder on the user than "addCallback", it's just different style
[17:17] rektide: HAPPY BIRTHDAY
[17:17] cloudhead: you got a request() function which returns a promise, you want to return the promise to the user, but you also want to write through the cache
[17:17] jcrosby has joined the channel
[17:18] ashb: Array.prototype.slice.call <-- i can't belive the IE guys questioned the usefulness of Array.slice(arguments)
[17:18] creationix: cloudhead: continuables allow the same thing
[17:18] creationix: just don't invoke method twice
[17:19] cloudhead: creationix: maybe I didn't see an implementation which allowed that
[17:19] cloudhead: well that's the thing
[17:19] cloudhead: it gets ugly
[17:19] cloudhead: it doesn't seem like there's a natural way, with continuables, to have multiple callbacks
[17:19] creationix: the difference is that with promises, your code starts executing BEFORE you attach the callback, but with continuables, it just holds state in limbo untill you attach callbacks
[17:20] creationix: and continuables have less syntax and overhead
[17:20] cloudhead: yea but
[17:20] creationix: you can't have multiple callbacks with promises either
[17:20] creationix: you're not supposed to at least
[17:20] cloudhead: yea you can
[17:21] creationix: ahh, I think you can attach multiple callbacks, the the event only fires once
[17:21] creationix: but do you need that
[17:21] creationix: promises are the async version of functions
[17:21] creationix: functions can only return to one caller
[17:22] cloudhead: yea
[17:22] creationix: maybe we should make a distinction between async functions and full blown promise events
[17:22] cloudhead: yea
[17:22] cloudhead: when I say 'promise' I mean node's implementation
[17:23] creationix: which is somewhere inbetween
[17:23] creationix: hence the pull from both sides
[17:23] cloudhead: yea
[17:23] bentomas: well, either way, with chainable continuables, you can attach multiple callbacks
[17:23] creationix: I like how ryan is planning on making simple callback based libraries an option
[17:23] bentomas: and as long as the callbacks don't modify the result then you could do what you want to do
[17:23] cloudhead: bentomas: what does it look like?
[17:24] bentomas: http://github.com/bentomas/node-continuables
[17:25] cloudhead: so it would be group() ?
[17:25] creationix: bentomas: those look like full blown promises with continuable syntax.  Interesting mix of the two
[17:26] cloudhead: oh wait no
[17:26] bentomas: nope, look at the examples in the middle
[17:26] bentomas: (sorry, yeah, they are similar to promises, but they don't have separate callbacks for success or error, just one callback)
[17:27] creationix: well, that's a minor one, I do like that you namespaced either at least
[17:27] bentomas: anyway, gotta do actual work
[17:28] cloudhead: bentomas: so is it by not returning anything?
[17:28] creationix: me too, good work on your library, it's a bit much for me.  I like simple.  but nice
[17:28] bentomas: yeah, if you don't return anything the next callback will get the same value
[17:28] creationix: that's pretty cool
[17:28] cloudhead: yea
[17:28] bentomas: creationix: yeah, I like simple too, hence the library :)
[17:28] cloudhead: I like that idea
[17:28] cloudhead: hmmm
[17:29] cloudhead: instead of having an `either`, I'd prefer to just pass two functions
[17:29] cloudhead: first one is success, second is error
[17:29] bentomas: cloudhead, well then you'd have Promises
[17:29] cloudhead: right, cause it doesn't go through continuables
[17:29] cloudhead: hmm
[17:29] bentomas: creationix: but I acknowledge that people have different definitions of "simple"
[17:30] creationix: well, to be fair, but the time I include all my "Do" stuff mine isn't any simpler than yours
[17:30] bentomas: continuables take one callback, the either function is a way of turning 1 callback into two
[17:30] jashkenas has joined the channel
[17:30] cloudhead: yea gotcha
[17:30] bentomas: jashkenas: you changed your nick!
[17:31] jashkenas: yep -- I'm still trying to figure out IRC -- I've always been a, let's say, casual user.
[17:32] bentomas: time for real work
[17:32] bentomas has left the channel
[17:32] steadicat has joined the channel
[17:38] felixge has joined the channel
[17:38] felixge has joined the channel
[17:41] morgan: Is there a way to detect (event?) HTTPConnect Server timeout?
[17:41] morgan: Close only appears to fires if response.finish() is called
[17:42] qFox has joined the channel
[17:43] bronson has joined the channel
[17:45] guan has joined the channel
[17:47] stephenlb has joined the channel
[17:48] morgan: sorry, timeout isn't what I meant (that is emitted in end)
[17:49] maritz has joined the channel
[17:49] zimbatm: hi !
[17:49] morgan: What I cannot detect is if, during a long-pull, the client stops the connection
[17:50] maritz: morgan: http://nodejs.org/api.html tcp server emits a timeout event 
[17:51] morgan: Right, but if you load a page (or long-poll in this case) and cancel it, timeout is not fired
[17:51] morgan: close is not either
[17:53] morgan: hmm, infact, not timeout is not even firing
[17:55] eikke has joined the channel
[17:57] Zoka has left the channel
[18:05] chakrit has joined the channel
[18:11] creationix: morgan: I'm not sure if it matters, but on php you can't detect the client closing their connection until you try to send some data to them
[18:11] creationix: not sure if it's a php limitation or part of http
[18:12] pdelgallego has joined the channel
[18:13] morgan: Hmm, I will have to look into it more later
[18:13] morgan: I think Jetty/Cometd alerts of disconnects like this
[18:13] morgan: been a while since I have used it
[18:14] hesslow has joined the channel
[18:16] mikeal has joined the channel
[18:17] _wil_ has joined the channel
[18:24] joshbuddy has joined the channel
[18:24] joshbuddy has joined the channel
[18:29] maritz: yeah, they trigger the timeout from the client side via window.onUnload or something like that
[18:31] harryv has joined the channel
[18:31] ericflo has joined the channel
[18:31] _wil_ has joined the channel
[18:35] scudco has joined the channel
[18:37] ericflo has joined the channel
[18:37] mattly has joined the channel
[18:40] mikeal1 has joined the channel
[18:45] dnolen has joined the channel
[18:51] sudoer has joined the channel
[18:53] jdee has joined the channel
[18:54] fictorial has joined the channel
[18:57] jdee has joined the channel
[18:58] gsf: creationix: no specific suggestion from me yet on making the code more readable
[18:58] creationix: ok, that's fine, just wondering
[18:58] gsf: creationix: i'm just starting to follow some of the promises and callbacks conversation
[18:59] gsf: creationix: part of it is coming from python, not used to anonymous functions inside anonymous functions inside... :)
[18:59] creationix: I think it really helps to distinguish between simple callbacks and full promise-like objects.  I see a lot of pull from both preferences trying to make them be the same
[19:00] creationix: gsf: yes, it get's ugly if you're not used to it.  I have also toyed with alternative syntaxes (preprocesors) but that's not for everyone
[19:02] gsf: creationix: and i only say i'd prefer chaining to nesting because i'd hope that would mean less depth in the code
[19:02] gsf: or just fewer indents
[19:03] gsf: but i can see points on both sides of that discussion
[19:04] gsf: and on that topic, new post to the list
[19:04] creationix: of course, that's the goal, I hope to never nest more than 3 levels deep
[19:05] gsf: ditto
[19:08] edspencer has joined the channel
[19:12] alexiskander has joined the channel
[19:14] chakrit1 has joined the channel
[19:21] guan has joined the channel
[19:25] isaacs has joined the channel
[19:27] dnolen has joined the channel
[19:28] rtomayko has joined the channel
[19:31] jcrosby has joined the channel
[19:46] drostie has joined the channel
[19:47] voodootikigod: felixge: 
[19:47] felixge: voodootikigod: hey
[19:47] voodootikigod: check yer pms
[19:47] voodootikigod: :)
[19:48] felixge: voodootikigod: twitter? Nothing there
[19:48] felixge: oh irc
[19:48] drostie has joined the channel
[19:48] ryah: we have t get rid of wait()
[19:49] ryah: i just spent 8 hours debugging something just to find out require() was being called in some callback
[19:50] ryah: it really really complicates programming
[19:50] creationix: agreed
[19:50] ryah: sync file i/o - okay 
[19:51] ryah: wait - no
[19:51] creationix: I'd rather see a real sync require than one that uses wait, if course I'd really rather find an easy way to do async requires
[19:51] creationix: but sync file i/o is ok for require since it usually only happens once at the start of a server
[19:51] ryah: okay. so here's the plan. I'm going to change a bunch of API in this release
[19:51] ryah: and in the next release we're dropping wait()
[19:51] ryah: i've had it with wait() bugs
[19:52] creationix: ryah: why no do it all at once:
[19:52] ryah: because the sync require patches arn't ready yet
[19:52] creationix: fair enough
[19:53] creationix: will the callback-based fs module be in this one?
[19:53] ryah: yeah - well not exactly sure how that will look
[19:54] jdee has joined the channel
[19:54] harryv has left the channel
[19:54] mikeal1: so there won't be any way to block execution outside of a file io?
[19:54] felixge: ryah: if we're doing some major breaking, I'd like to seriously consider the continuable stuff bentomas is working on
[19:55] felixge: it's very light weight and highly simplified
[19:55] ryah: yeah maybe
[19:56] ryah: you know even if we had real coroutines
[19:56] ryah: i would have still hit the bug i just did
[19:57] inimino: I'm very glad to see wait() bite the dust
[19:57] ryah: and i realize to have wait() in callbacks one needs to seriously expand thier mental model of how the program is running
[19:57] creationix: so you could say is caused "unexpected behavior"
[19:57] ryah: its soo much like trheads
[19:58] ryah: but with just simple callbacks you don't have think about anything - store state wherever you want
[19:58] inimino: yep
[19:58] ryah: s/soo/too/
[19:58] mikeal1: i'm glad to see it leave, i've definitely missused it
[19:58] mikeal1: of all the place i use it, only one is kind of valid
[19:58] isaacs: if we have blocking file io, there's no need for wait()
[19:58] isaacs: ever.
[19:58] isaacs: (except for laziness)
[19:59] inimino: I've never used it
[19:59] inimino: but I'm glad to see features I don't use get dropped :-)
[19:59] keeto has joined the channel
[19:59] mikeal1: i have a require() I implemented that will take require("module>=1.3") and install that version if necessary before returning the module
[20:00] mikeal1: so it needs to block on http IO
[20:00] inimino: I have a require-alike, but it's strictly async
[20:00] mikeal1: yeah, it's a hard proposition to say "it's just like require except annoying"
[20:00] inimino: hehe, yes
[20:01] zimbatm: ryah: so the http transport for require() is going away ?
[20:01] inimino: if it supported require() in what was async-require'd, it'd be easier, but it doesn't do that yet either
[20:01] zimbatm: (don't think it's bad)
[20:02] ryah: zimbatm: yes
[20:02] ryah: zimbatm: require.async() will work for http still
[20:04] mikeal1: although I like some of this things you can do with .wait() it does violate the entire principal that we should write fake blocking abstractions over things that aren't really blocking (or at least shouldn't be blocking)
[20:04] mikeal1: s/should/shouldn't
[20:04] dnolen has joined the channel
[20:04] ryah: yes. it really destroys to naive mental model 
[20:04] joshbuddy has joined the channel
[20:05] felixge: here is the sync require patch as of right now: http://github.com/felixge/node/tree/require-sync2
[20:05] felixge: would love some comments
[20:05] felixge: its not easy to write functions that work both sync and async at the same time
[20:05] felixge: :)
[20:05] creationix: I think node should just provide super low-level callback style libraries and we could build promises/continuables/something-else on top of it
[20:06] creationix: felixge: what did you think about "when" from Kris
[20:06] creationix: I thought it was a great way to allow both sync and async functions to be used the same
[20:07] creationix: http://gist.github.com/305202
[20:07] pdelgallego has joined the channel
[20:07] dnolen_ has joined the channel
[20:09] richtaur has joined the channel
[20:10] felixge: creationix: not sold on this yet, his stuff mostly seems focused on abstract problems I don't have
[20:11] creationix: I just liked "when", not sure about the rest of it
[20:13] jashkenas: I've been listening a bit, but haven't heard what the deficiency is with simple callbacks -- as opposed to promises, wait, when, continuable, etc...
[20:13] jashkenas: What don't they provide that you would need for async?
[20:13] inimino: jashkenas: composability
[20:14] creationix: I prefer simple callbacks, they just don't make chaining and other higher-level operations easy
[20:14] creationix: plus they don't work as well when you don't know how many arguments you will receive
[20:14] inimino: +1 to having super-low-level callbacks only in node, though
[20:14] creationix: but for stuff like fs.open(file, options, callback, errback), they're great
[20:15] gsf: jashkenas: did you see the post on the mailing list from michael stillwell about an hour ago? he raises some issues
[20:15] jashkenas: yeah, the arguments have to be an explicit part of the docs. 
[20:15] jashkenas: gsf: I'll take a look, thanks for the pointer.
[20:16] cloudhead has joined the channel
[20:16] creationix: continuables are just as easy to pass around as promises
[20:16] creationix: they are a small step up from regular callbacks, but add a lot of functionality
[20:16] creationix: then add a little more abstraction and you get to the level of promises, and bentomas's continuables
[20:17] creationix: fs.open(filename, option1, option2)(callback, errback)
[20:17] creationix: it's just curried till you execute it
[20:18] jacobat: what is the meaning of: var a = new function () { ... }
[20:18] creationix: (Speaking of the simple continuable style)
[20:18] jashkenas: Seems like an inversion of control that isn't strictly necessary. Wherever you're passing a promise for another object to subscribe to, that object could just be registered to listen to the appropriate event instead.
[20:18] inimino: jacobat: it's the same as new Foo() normally, only that Foo is anonymous
[20:18] creationix: jacobat: it's making a new instance of a new anonymous constructor
[20:18] pdelgallego has joined the channel
[20:19] jacobat: why would you do that instead of just: var a = { ... } ?
[20:19] atcrabtree: has anyone built mysql wrappers for node?
[20:19] inimino: jacobat: no good reason, really
[20:19] creationix: jacobat: it allows for private variables and methods to live inside the constructor
[20:20] creationix: http://www.crockford.com/javascript/private.html
[20:20] jashkenas: so, for Michael's example on the list, he would emit the event when his callback fires, instead of when its created, and life goes on from there.
[20:20] jacobat: that makes sense, thanks!
[20:20] inimino: jacobat, creationix: well, you could do that with an anonymous function call...
[20:21] inimino: var a = (function(){...})()
[20:21] gsf: atcrabtree: see the database section at http://wiki.github.com/ry/node/modules
[20:21] atcrabtree: gsf: thx
[20:21] inimino: jacobat: I don't think the version with 'new' has any advantage over that, and it's much more rarely seen
[20:21] creationix: I pretty much never use "new" unless I'm using a library that requires it
[20:21] creationix: I was just explaining what it could do
[20:22] creationix: jashkenas: still looking and trying to figure it out myself
[20:23] inimino: I think Michael is using the half of Promises that are the complement to what continuables provide
[20:23] jacobat: inimino: I'm trying to understand the node-chat code - it's used in there
[20:23] inimino: jacobat: got a link?
[20:23] inimino: in other words, I think Michael's example isn't where continuables can be used
[20:24] jacobat: inimino: http://github.com/ry/node_chat
[20:24] inimino: the Promise he's emitting has only handlers on it, but never emits any event
[20:24] jashkenas: The gist of his problem though, is an async transform of an object into an HTTP response.
[20:24] creationix: continuables don't work for regular eventemitters
[20:24] creationix: that looks like what he's trying to do here
[20:24] jashkenas: So, object.toHTTP(callback)
[20:24] jashkenas: Or object.toHTTP(callback, errback)
[20:25] inimino: what he's returning might be more of a continuation than a continuable
[20:26] inimino: but maybe not, I'm not sure what promise.timeout() is doing there
[20:28] creationix: jacobat:  he's doing "new function" so that within the scope of the function "this" is the object returned and not some other scope
[20:29] inimino: jacobat: which file?
[20:29] jacobat: inimino: server.js
[20:29] jacobat: creationix: okay
[20:29] bentomas has joined the channel
[20:30] bentomas: creationix: what would you consider the difference between simple continuables and my module?  If I can bridge the gap, I'd like to
[20:30] creationix: bentomas: I'll make a quick gist to show what I mean
[20:30] inimino: jacobat: hm, yeah, using it for this-binding...
[20:31] jacobat: thanks for the explanation
[20:32] inimino: jacobat: that could easily be rewritten as an anonymous function which returns an object literal
[20:33] jacobat: inimino: I'm not sure what you mean by that
[20:33] inimino: jacobat: var channel = (function(){ ... return {appendMessage:..., query:...})()
[20:33] jacobat: ah, right
[20:34] inimino: and it would be more idiomatic JavaScript
[20:34] jacobat: except you couldn't have messages and callbacks as "private" variables in that case, could you?
[20:34] inimino: jacobat: yes, that's the purpose of the anonymous function
[20:35] gsf: jacobat: crockford has an article on "new" where he says "The only time we should use the new operator is to invoke a pseudoclassical Constructor function. When calling a Constructor function, the use of new is mandatory."
[20:35] gsf: http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-ya/
[20:35] gsf: make of that what you will
[20:36] inimino: jacobat: the first "..." is where you can put variable declarations that represent the hidden state of the object you return...
[20:36] pdelgallego has joined the channel
[20:36] bentomas: creationix: is it that you want to make it so code isn't run until a callback is added?  because that could be easily done...
[20:36] jacobat: inimino: ah yes, of course
[20:37] jacobat: gsf: will go read
[20:39] inimino: js> a=(function(){var n=0;return {inc:function(){return ++n},dec:function(){return --n}}})(); a.inc(); a.inc(); a.inc(); a.dec()
[20:39] gbot2: inimino: 2
[20:39] inimino: hm...
[20:39] inimino: js> a=(function(){var n=0;return {inc:function(){return ++n},dec:function(){return --n}}})(); [a.inc(), a.inc(), a.inc(), a.dec()]
[20:39] gbot2: inimino: [1,2,3,2]
[20:39] pmuellr has joined the channel
[20:40] creationix: bentomas: it's not a goal, just a side effect of the syntax, still working on a gist...
[20:40] bentomas: *tries to be patient :)*
[20:41] creationix: bentomas: My work keep calling me and getting in the way (it like they think they own my time :P)
[20:42] mikeal has joined the channel
[20:44] creationix: bentomas: http://gist.github.com/305903
[20:44] creationix: my version of continuable is more of plain callbacks curried
[20:46] bentomas: ahhh, well, it wouldn't be hard to do that (but with one callback instead of two)
[20:46] bentomas: and still allow the chaining and all the other niceties
[20:46] jcrosby has joined the channel
[20:46] creationix: then I manage it externally with helpers that take care of grouping, async map, filter, and all that higher level stuff
[20:47] bentomas: I don't understand what the advantage of yours is over just taking callbacks
[20:47] bentomas: (sorry!)
[20:47] creationix: two advantages:
[20:47] creationix: arbitrary number of arguments in the base function
[20:47] creationix: and if you don't call the second time, it's mobile just like a promise object
[20:48] creationix: with very little overhead over regular callbacks
[20:48] bentomas: ahhh...
[20:48] bentomas: yeah, I see what you mean about mobility
[20:49] creationix: and so you could make a parallel method that takes any number of uncalled actions and calls them all in parallel and lets you know when they're all done
[20:49] creationix: most of my howtonode.org articles use this style
[20:49] creationix: I've been calling it my "Do" library
[20:49] bentomas: yeah, that's what my "group" library does in node-continuables
[20:50] cloudhead: creationix: you got that in module format?
[20:50] creationix: the difference is that all the functionality is built into your smart objects and mine is managed externally
[20:50] creationix: cloudhead: the Do library?
[20:50] cloudhead: yah
[20:50] creationix: not yet, but I can throw one together real quick
[20:50] creationix: want it?
[20:50] cloudhead: yeh ;p
[20:50] creationix: ok, just a sec
[20:50] cloudhead: lol
[20:51] creationix: maybe I shouldn't call mine continuables, it might confuse people
[20:51] cloudhead: I'm looking into lighter solutions to promises, for some of my projects, and I kinda stumbled upon the same realizations, but you're much further along, so I'd like to take the highway
[20:53] creationix: alright, repo made, now to put code in it http://github.com/creationix/do
[20:54] cloudhead: cool
[20:56] cloudhead: 
ACTION needs to start following node.js people on github

[20:59] inimino: creationix: actually, the way you use the term is pretty much exactly what I coined it to mean :-)
[21:00] creationix: inimino: thanks, I think the only thing I changed from the original was to get rid of "either" and take two callbacks
[21:01] inimino: creationix: yes
[21:03] creationix: bentomas: looks like it will be a couple of hours before I can get it all packaged and documented, how that will do
[21:03] creationix: errl sorry, that was for cloudhead
[21:04] bentomas: I'm curious to look at it as well
[21:04] cloudhead: awesome
[21:04] jcrosby has joined the channel
[21:04] cloudhead: take your time : )
[21:04] creationix: I've got class in a bit and laptops aren't allowed, but I promise it will be out within the next 7 hours
[21:05] cloudhead: I'll be 'watching' — literally
[21:05] cloudhead: hehe
[21:05] creationix: I saw
[21:05] creationix: (I would say tonight, but we're all in different time zones, so I had to clarify)
[21:06] cloudhead: hehe
[21:06] cloudhead: I think we're in the same time zone
[21:06] cloudhead: as per the wiki
[21:07] cloudhead: what class you got?
[21:11] creationix: Government 2 (my last undergrad class) and Advanced Operating Systems (a graduate class on distributed systems)
[21:11] creationix: the second class relates to node a lot, too bad we have to use java for homeworks
[21:12] creationix: the school I'm at lets me start my masters before I finish my undergrad, it's nice
[21:16] inimino: 
ACTION replied to the continuables email on the list

[21:17] cloudhead: nice
[21:17] inimino: hm, I thought of a better API for timeout
[21:18] inimino: timeout(cont, timeout_ms, timeout_value)
[21:18] inimino: oh well
[21:21] tlrobinson_ has joined the channel
[21:23] chakrit1: js> "hello"
[21:23] gbot2: chakrit1: "hello"
[21:26] piranha has joined the channel
[21:31] chakrit1: gsf, somehow the comments on that article just made me feel sad...
[21:32] gsf: chakrit1: the crockford article?
[21:33] chakrit1: gsf: yup
[21:33] gsf: chakrit1: must admit i didn't wade through them
[21:34] Tim_Smart has joined the channel
[21:34] chakrit1: gsf, it's mostly a series of "No, I think you're wrong" and Douglas replying "ur stupid, that's not how you should do it in JS"
[21:35] gsf: well crockford is a pedant, but not without good reason
[21:36] CIA-77: node: 03Ryan Dahl 07master * r1bf46d1 10/ (doc/api.txt src/node.js): 
[21:36] CIA-77: node: Revert "Add process.startTime"
[21:36] CIA-77: node: Unnecessary
[21:36] CIA-77: node: This reverts commit 896cef23c4a9bb1e3e4eeaef8cf101ea4e43af74. - http://bit.ly/99Y0Qy
[21:36] CIA-77: node: 03Ryan Dahl 07master * r23cf502 10/ (18 files in 4 dirs): API: connection.send() renamed to connection.write() - http://bit.ly/d3akTR
[21:36] mikeal: crockford just thinks that you have more expressive capabilities using closures and writing functionally than you do with all these OO abstractions
[21:36] mikeal: and he happens to be right :)
[21:37] chakrit1: mikeal, that's why I love JS :)
[21:37] mikeal: coming from Python i missed all these features
[21:38] mikeal: and at some point I realized that those features just pertain to their own abstractions and if you don't have them you actually don't need them if you've got good closures
[21:38] erichocean has joined the channel
[21:38] chakrit1: yah, closures = magic once you grok'em
[21:38] mikeal: they really are
[21:38] erichocean: inimino: ping
[21:39] Tim_Smart: 
ACTION just got a macbook, and coming from linux is unsure on installing node.js on Mac

[21:39] mikeal: the best part is that if you can use them without really understanding them
[21:39] mikeal: i see front end jQuery people do it all the time
[21:39] frodenius: Tim_Smart: do it
[21:39] mikeal: they just kind of magically references stuff in the parent scope, which would be amazing if they knew what scoping was
[21:40] frodenius: Tim_Smart: mac os is really just another unix, though sometimes a pretty strange one
[21:40] chakrit1: yeah... but the sad part is that more people are forced to write JS these days without really understanding most of it
[21:40] mikeal: i used to think that
[21:40] micheil: Tim_Smart: you will need a few things, like brew install libgpg-error
[21:40] Tim_Smart: frodenius: Yeah I ran node on my linux laptop for a while. Unfortunately Mac doesn't have all the apt-get awesome-sauce
[21:40] mikeal: but the more i learn about it the more i recognize the weird differences
[21:40] frodenius: there is mac ports
[21:41] micheil: but that's the only one that I've run into, asides from xcode
[21:41] mikeal: fuck mac ports
[21:41] frodenius: then you can port install almost anything
[21:41] micheil: no not mac ports.
[21:41] micheil: brew is far better for software dev
[21:41] frodenius: then use homebrew
[21:41] binary42: brew ++
[21:41] mikeal: mac ports is the best way to break you compiler for no good reason
[21:41] LordMetroid has joined the channel
[21:41] frodenius: `
[21:41] frodenius: ?
[21:41] binary42: macports is indeed a pile of crap.
[21:41] frodenius: hm i had no problems with it so far
[21:41] Tim_Smart: homebrew is something I will check out
[21:41] mikeal: i hear great things about brew, i'm just in the habit of compiling everything by hand now
[21:42] micheil: mikeal: think of the Archlinux pkgbuilds
[21:42] binary42: mikeal: I do both but I'd do it via homebrew if possible since it's easy to add your own builds.
[21:42] binary42: The plus of my new setup is I can remove almost every modification I've made painlessly since my clean install.
[21:42] micheil: Tim_Smart: if you don't want bleeding edge, there's also brew install node
[21:42] mikeal: yeah, one of these days I'll be trapped in some dependency hell and I'll sit down and invest in brew
[21:43] micheil: I think that's at latest stable
[21:43] Tim_Smart: meh I'm more of  bleeding edge person tbh
[21:43] micheil: Tim_Smart: then use git :P
[21:44] micheil: Tim_Smart: the node brew is just for people who want a stable version
[21:44] Tim_Smart: yes I shall, once I have hacked away on Mac for a bit...
[21:44] Tim_Smart: I think a dual boot linux is fast approaching :p
[21:45] Tim_Smart: 
ACTION <3's his compiz

[21:45] micheil: Tim_Smart: but then you can use textmate to edit your code.. and you won't ever use the other os.
[21:45] Tim_Smart: micheil: I are a Vim ninja
[21:45] mikeal: micheil: that's my exact problem
[21:45] micheil: 
ACTION tried that with a duel'y of ubuntu + windows

[21:45] mikeal: everytime i think about giving Linux desktop another go I remember TextMate
[21:46] Tim_Smart: pfft textmate has nothing on vim
[21:46] micheil: mikeal: textmate is awesome, even if it is the next duke nukem
[21:46] mikeal: i used vim until textmate
[21:46] binary42: I'm a editor samurai. I wander from place to place hacking things up.
[21:46] binary42: I also have multiple blades I use depending on the job.
[21:46] chakrit1: 
ACTION hides behind visual studio

[21:46] mikeal: save on application change
[21:46] mikeal: can't live without it 
[21:46] micheil: chakrit1: I don't want to know :P
[21:47] chakrit1: :)
[21:47] binary42: TextMate is pretty amazing actually. In ways I can't get vim to be (nor emacs).
[21:47] binary42: I can't say it makes me happy all the time either though.
[21:48] mikeal: and those of us in on the TextMate wagon have the infinite allure of TextMate2 vaporware
[21:48] mikeal: where is your theortically awesome next version of Vim, huh guys?
[21:48] binary42: I'm not waiting for it. Working on some web stuff instead (no, not bespin)
[21:48] micheil: code trees / folder trees right in the editor make it nice. That's the one thing I think vim lacks
[21:48] stephenlb: binary42: interesting.  what does TextMate do that makes you happy?
[21:49] binary42: stephenlb: Proper grammars which can be embedded and contextually (recursively too) customized.
[21:49] mikeal: i've messed with Bespin a lot, we're talking about creating a CouchApp IDE with BespinEmbedded
[21:49] binary42: Then build on that you have all the commands and filters you can add just for that context.
[21:49] micheil: yeah, that's the other thing, vim's syntax highlighting is shit, imo.
[21:49] stephenlb: binary42: context based on the current file(s) open?
[21:49] binary42: bespin is impressive but not as an editor (at all).
[21:49] mikeal: also, i never thought I would care, but sometimes it's nice to use a mouse
[21:50] mikeal: and highlight a bunch of code and hit the comment key
[21:50] micheil: I don't know what inspired them to go from Dojo Toolkit to jQuery though.
[21:50] isaacs: mikeal: that's why textmate rox
[21:50] Tim_Smart_ has joined the channel
[21:50] mikeal: yup
[21:50] binary42: stephenlb: No, current place in the text. i.e. my cursor is inside a string or even inside a string inside an interpolated expression written in a different language.
[21:50] isaacs: cmd / is my favorite.
[21:50] mikeal: the rest of Bespin is trying to be a big IDe
[21:51] binary42: stephenlb: vim and emacs can't do that w/o rewriting their grammar engines. I've tried and failed multiple times.
[21:51] mikeal: and I don't need an IDE, i need a kickass editor that saves when I switch applications :)
[21:51] isaacs: 
ACTION is not a fan of big IDEs.  editor, terminal, browser.

[21:51] mikeal: yup
[21:51] mikeal: also watchFile is the greatest thing ever
[21:51] isaacs: hehe
[21:51] mikeal: now I cmd+tab directly to the browser and refresh
[21:51] isaacs: mikeal: have you played with my node-supervisor at all?
[21:51] mikeal: cause my dev script updates everything automatically on file change
[21:51] stephenlb: binary42: that's neat, so if one was writting Ruby + a DSL like SQL, then all auto-complete commands (if inide the SQL DSL) will be SQL related?
[21:52] mikeal: not yet
[21:52] mikeal: where is it on github?
[21:52] isaacs: mikeal: http://github.com/isaacs/node-supervisor
[21:52] binary42: stephenlb: Yeah. It's really cool and useful. 
[21:52] stephenlb: binary42: nice
[21:52] Tim_Smart: 
ACTION uses vim with the snippets, supertab and surroundings plugins

[21:52] mikeal: oh, awesome
[21:52] isaacs: mikeal: it's still very very basic/betaish, but i've found it to be fairly useful for my purposes.
[21:52] mikeal: isaacs: i'll need this in about a week, right now all I need to do on file change is update a design document in CouchDB
[21:53] mikeal: so I don't have to hot reload anything
[21:53] isaacs: you just do node-supervisor -p my-program.js -w relevant-file-dir/=
[21:53] isaacs: er, "node-supervisor -p my-program.js -w relevant-file-dir"
[21:53] isaacs: no =
[21:53] mikeal: nice
[21:53] isaacs: it'll watch the -w, and reload the -p if anything changes
[21:53] mikeal: sweet
[21:53] mikeal: does it pick up new files?
[21:54] mikeal: in the directory
[21:54] isaacs: well, actually, it seems like watchFile is super trigger happy
[21:54] isaacs: so probably.
[21:54] jacobat: is there some clever way to get an iterator over the objects in an array? something like Ext.each?
[21:54] mikeal: do you have to do watchFile w/ interval:100 to get it to work?
[21:54] isaacs: jacobat: [1,2,3].forEach(function (num) { sys.puts(num) })
[21:54] mikeal: i was having this issue where if you run it without the options it would never fire
[21:55] jacobat: isaacs: thanks
[21:55] isaacs: jacobat: np
[21:56] isaacs: jacobat: i believe you can also do [1,2,3].forEach(function (num) { this.puts(num) }, sys)
[21:56] isaacs: ie, the second arg sets "this"
[21:56] jacobat: right
[21:56] jacobat: how about if I want to iterate over an object?
[21:57] deanlandolt: jacobat: Object.keys(obj).forEach
[21:57] isaacs: jacobat: for (var i in myObject) { blarg(myObject[i]) }
[21:57] deanlandolt: isaacs: my way's more shiney and new ;)
[21:57] chakrit1: Array.forEach.apply?
[21:57] isaacs: deanlandolt: true.  but also slower.
[21:57] mikeal: i miss jQuery's forEach
[21:57] deanlandolt: isaacs: indeed
[21:57] mikeal: it iterates over object properties/values 
[21:58] Tim_Smart_ has joined the channel
[21:58] deanlandolt: mikeal: you can easily write that
[21:58] mikeal: i know, but then i've gotta paste it everywhere i wanna use it :)
[21:58] deanlandolt: but tacking it onto Object.prototype may be dicey
[21:58] mikeal: i don't like that idea
[21:59] LordMetroid: Clients can not make JavaScript insertations as requests, can they?
[21:59] isaacs: in ES5 strict, i believe Object.prototype is frozen
[21:59] mikeal: whenever i add to Object.prototype I feel ditry
[21:59] deanlandolt: isaacs: i don't ever rememeber hearing that...hmm
[21:59] LordMetroid: I wouldn't want the client to execute their JavaScript on my server
[21:59] isaacs: maybe it's been overturned.
[21:59] isaacs: LordMetroid: then don't execute code that was passed in on the request.
[21:59] isaacs: LordMetroid: same goes for php, java, python, or ruby.
[22:07] cloudhead: can anyone comment on his 2nd point: http://twitter.com/jamesgolick/status/9204127202 ?
[22:10] binary42: cloudhead: Just told him to come join the channel.
[22:10] cloudhead: haha
[22:10] binary42: Not sure he will but if the wants help, it's usually easier here.
[22:10] fictorial: cloudhead: why do you care about someone flinging around fud? :)
[22:11] cloudhead: well, he happens to be someone I usually trust the experience of
[22:11] fictorial: bastardized mysql be damned? ok ... :)
[22:12] cloudhead: was wondering if anyone else encountered memory corruption in node, cause I haven't heard of it before
[22:12] cloudhead: hehe
[22:13] mikeal: what does that even mean
[22:13] fictorial: I'd love to see how that shakes out. It's incredibly vague.
[22:13] fictorial: ding
[22:13] LordMetroid has left the channel
[22:13] mikeal: it could mean a few things, and i don't think what he thinks is happening is what is actually happening
[22:13] cloudhead: yea, it seems odd to me
[22:14] chakrit1: cloudhead: I did a while back while toying around with siege but ryah fixed it in < 2 days.... so can't really complain :)
[22:14] cloudhead: hmm
[22:15] cloudhead: might be something else then
[22:15] mikeal: i had some issues with a crazy amount of http client
[22:15] mikeal: but then i git pull ry master and rebuilt
[22:15] mikeal: and it went away
[22:15] cloudhead: but then again, he did get redis to crash multiple times
[22:16] mikeal: i was trying to make CouchDB crash
[22:16] mikeal: but node slows down before CouchDB is under enough load to fall over
[22:16] inimino: erichocean: pong
[22:17] erichocean: hi
[22:17] erichocean: playing with your peg parser stuff again
[22:17] cloudhead: heh, I bet redis is much easier to crash than couch
[22:17] mikeal: redis doesn't handle concurrency as well as couch
[22:17] fictorial: mikeal: huh?
[22:17] mikeal: but redis is no slouch 
[22:17] mikeal: write speed is spectacular 
[22:17] erichocean: I compiled the ECMAScript_unified.peg grammar
[22:17] cloudhead: yea
[22:18] erichocean: when I run it on a JS file, it returns "true" as the first value, but the returned array is obviously wrong
[22:18] jamesgolick has joined the channel
[22:18] erichocean: http://gist.github.com/306004
[22:18] cloudhead: heya jamesgolick 
[22:19] erichocean: it looks like it gets stuck in a loop ?
[22:19] jamesgolick: hey, we've been playing with node.js for a couple of hours, and getting random double free aborts
[22:19] cloudhead: we were just talking about your tweet
[22:19] jamesgolick: heh
[22:19] mikeal: don't get the wrong impression, we don't just sit in the channel obsessing over tweets about node.js :)
[22:19] erichocean: and here is the file I was parsing: http://gist.github.com/306005
[22:20] inimino: erichocean: which javascript engine?
[22:20] erichocean: node
[22:20] erichocean: aka v8
[22:20] jamesgolick: well
[22:20] cloudhead: double free aborts, as in C's free()?
[22:20] jamesgolick: yea
[22:20] mikeal: this file references document
[22:20] jamesgolick: node(5293,0x1252d1000) malloc: *** error for object 0x100701010: double free
[22:20] jamesgolick: is this expected?
[22:21] jamesgolick: is it a bug or a feature?
[22:21] cloudhead: yikes
[22:21] jamesgolick: :P
[22:21] cloudhead: hehe
[22:21] ryah: jamesgolick: can you get a stack trace?
[22:21] inimino: erichocean: heh, yeah that's definitely not a correct-looking parse tree :-)
[22:21] mikeal: not parsing SproutCore might be a considered a feature by some people :)
[22:21] ryah: jamesgolick: ./configure --debug; gdb --args ./node_g myscript.js
[22:21] ryah: jamesgolick: oops, and 'make'
[22:21] jamesgolick: ryah: so, recompile node?
[22:22] jamesgolick: ok
[22:22] jamesgolick: sec
[22:22] erichocean: this is the parser I generated: http://gist.github.com/306008
[22:22] erichocean: I used your grammar verbatim
[22:22] mattly has joined the channel
[22:23] inimino: erichocean: thanks, I'll test it
[22:23] erichocean: inimino: thanks, much appreciated
[22:24] erichocean: I saw you had done some work on the streaming version
[22:25] inimino: erichocean: yeah, lots of work going on, but it's still slow-ish
[22:25] inimino: erichocean: I think I'm going to finish it up and release it anyway though, and just let it be slow for a while...
[22:25] pdelgallego has joined the channel
[22:25] erichocean: I think I'm going to try and use your PEG.peg grammar to convert the ECMAScript grammar to something that http://piumarta.com/software/peg/ will accept
[22:26] inimino: erichocean: streaming and resuming is a cool feature
[22:26] erichocean: since I need the streaming stuff pretty bad
[22:26] erichocean: yeah, totally agree
[22:26] cloudhead: inimino: still haven't figured out why it's slow?
[22:26] inimino: cloudhead: yeah, I pretty much figured it out
[22:26] cloudhead: oh!
[22:26] cloudhead: is it the char-by-char compares?
[22:26] inimino: cloudhead: it's a combination of things... no, not that
[22:27] bentomas has left the channel
[22:27] cloudhead: okk good
[22:27] inimino: but it requires some hard work to make it better
[22:27] lifo has joined the channel
[22:27] jamesgolick: ryah: http://gist.github.com/306017
[22:28] inimino: cloudhead: it's still faster than a naive PEG implementation... but I'm comparing to LALR-style parsers now, and there's a ways to go there
[22:28] jamesgolick: ryah: added the failure http://gist.github.com/306017
[22:28] cloudhead: ahh yea, well howbout compared to an LL type?
[22:28] ryah: jamesgolick: which version
[22:29] inimino: cloudhead: similar
[22:29] jamesgolick: ryah: v0.1.28
[22:29] erichocean: inimino: I like how you use the whole Unicode character set in your peg grammar
[22:29] erichocean: much easier to read
[22:29] inimino: cloudhead: you can do some sophisticated analysis and get up to the performance of a bottom-up parser, but... you have to do sophisticated analysis
[22:29] ryah: jamesgolick: thanks - let me think about this for a sec
[22:30] ryah: jamesgolick: are you using wait() or require() in any of your callbacks?
[22:30] jamesgolick: ryah: no
[22:31] inimino: cloudhead: so there's probably about four or five things that are each contributing a 2x or so slowdown... anyway, there's tons of API work that I want to do before I spend more time on raw speed
[22:31] jamesgolick: ryah: you want me to gist the code? it's not pretty... we're jsut fooling around with node for the first time, trying to write a duplexing memcached proxy
[22:31] jamesgolick: ryah: but it's only 60 lines
[22:31] jamesgolick: ryah: http://gist.github.com/306022
[22:33] ryah: jamesgolick: oh i think your problem is that createConnection already calls connect()
[22:34] ryah: so you're calling connect() twice?
[22:34] jamesgolick: ryah: ah ok... makes sense
[22:34] inimino: erichocean: yeah, if you can get it going in C it'll be orders of magnitude faster (even then the theoretical maximum for JavaScript)
[22:34] ryah: even if that's the problem - that's not a very friendy error :)
[22:34] jamesgolick: ryah: might want to raise an error there rather than abort'ing tho :P
[22:34] ryah: jamesgolick: can you check to see if removing that connect() fixes it? then i'll try to add a warning
[22:34] jamesgolick: ryah: it also only happens every other run... 
[22:35] jamesgolick: ryah: that does seem to fix it
[22:35] spiralout has joined the channel
[22:36] Tim_Smart has left the channel
[22:39] gwoo has joined the channel
[22:40] CIA-77: node: 03Ryan Dahl 07master * recd6174 10/ src/node_net.cc : 
[22:40] CIA-77: node: Throw from connection.connect if resolving.
[22:40] CIA-77: node: Bug reported by James Golick. - http://bit.ly/boZg9q
[22:40] ryah: jamesgolick: thanks--^
[22:41] gf3 has joined the channel
[22:41] jamesgolick: ryah: np. thanks for the help
[22:51] erichocean: inimino: in http://boshi.inimino.org/3box/PEG/peg.peg, PosLookahead and NegLookahead never appear on the right hand side
[22:51] erichocean: I assume they're meant to be part of SeqUnit ?
[22:53] inimino: erichocean: ah, you're right
[22:53] erichocean: it looks like PEG.peg is the official one?
[22:53] inimino: erichocean: PEG.peg is the one you want, peg.peg is just used in bootstrapping, yeah
[22:54] erichocean: sweet, thanks
[23:04] jcrosby has joined the channel
[23:10] dekz has joined the channel
[23:13] Tim_Smart has joined the channel
[23:15] chakrit has joined the channel
[23:17] mikeal has joined the channel
[23:22] Harrison has joined the channel
[23:27] inimino: erichocean: hey, I tested in Firefox and your parser works, so it must be a difference in engines...
[23:28] inimino: (it does take 30 seconds to run, though)
[23:28] erichocean: hmm, well that's good to know
[23:28] inimino: erichocean: I haven't done any real testing in V8 yet, there may be some issues... I've also noticed errors in Opera
[23:29] inimino: the correct output looks something like this: http://www.pastie.org/828092
[23:29] inimino: not sure what's happening in V8 yet
[23:35] creationix has joined the channel
[23:35] erichocean: time to do some delta debugging :)
[23:37] jcrosby has joined the channel
[23:39] jamesgolick has left the channel
[23:42] charlenopires has joined the channel
[23:51] ryah: meh. can't get the multipart working with the new API -_-
[23:51] adamv has joined the channel
[23:55] richtaur has left the channel
[23:57] Tim_Smart: oh noes o.O