Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-02-03:

[1:54] <deanlandolt> kripken: came up with a way to make returning objects from a forEach promise already-compliant...the objs themselves can just have a toByteString
[1:55] <deanlandolt> of course, if someone /uses/ that it'd force each obj to be fully buffered, but that's no worse than, say, the current multipart parser
[1:57] <deanlandolt> err...sorry kripken -- you shouldn't have a name so close to kriszyp :D
[2:40] <Dantman> No name color coding in your client deanlandolt?
[2:40] <deanlandolt> Dantman: nope...in the market for a decent windows client if you have any suggestions
[2:41] <Dantman> Hmmm... I know you can get X-Chat for Windows... I can't remember if KVIrc had color coding when I was using it.
[2:41] <deanlandolt> been using leafChat -- kinda clunky...no ping facilities either, but i really like the ambient notifications...
[2:41] <Dantman> I do have a nice /hammer script for KVirc
[2:41] <Dantman> ambient?
[2:42] <deanlandolt> as in, just stupid little os-level popups
[2:42] <Dantman> ^_^ X-Chat integrates with Ubuntu's new osdnotify growl like notification system..
[2:42] <deanlandolt> but it's actually pretty nice -- as distracting as i want it to be i guess
[2:42] <deanlandolt> really? sweet
[2:43] <Dantman> My only problem is osdnotify itself...
[2:43] <Dantman> They made two decisions in creating it I don't quite like
[2:43] <deanlandolt> at home i'm almost always on ubuntu (am right now) by for irc i just rdp onto my work machine
[2:44] * Dantman needs to come up a way to sync xchat logs between two machines in a way that merges channels...
[2:44] * deanlandolt needs to come up with a replacement for irc :D
[2:44] <Dantman> ^_^ I've rolled ideas arround that in my head to
[2:44] <deanlandolt> it's not like email -- it /can/ be replaced with something w/o network splits :)
[2:45] <Dantman> The tough part was thinking of how to avoid the need for each server to maintain a list of users connected to the network...
[2:46] <deanlandolt> you drop the notion of network entirely (and now you're effectively in xmpp land)
[2:46] * Dantman will probably need to read xmpp now
[2:47] <deanlandolt> spare yourself -- the anglebracketology will make your eyes bleed
[2:54] <deanlandolt_> Dantman: heh...irony -- i keep irc up on my work box because it's up reliably...but my work network just went down :-/
[2:54] <deanlandolt_> i was just thinking...heh, it's windows...it can't be that reliable
[2:55] <Dantman> heh
[13:39] <ashb> AssertionError: ({a:4}) notDeepEqual ({a:4})
[13:39] <ashb> curious...
[22:20] <tlrobinson> isaacs: could you fork this and add the equivalent examples for ESGI: http://gist.github.com/293552
[22:20] <tlrobinson> EJSGI
[22:20] <isaacs> sure
[22:20] <tlrobinson> kriszyp: kris kowal and i were having trouble agreeing on whether the AJSGI and JSGI+Q examples in that gist are equivalent
[22:21] <tlrobinson> mind taking a look?
[22:21] <kriszyp> ok
[22:21] <ashb> all of those examples need me to stare at them to work ouw what they do
[22:22] <tlrobinson> kriszyp: i think they are equivalent, but he maintained that the AJSGI async example isn't equivalent to forEach returning undefined synchronously, while his JSGI+Q is
[22:22] <kriszyp> PSGI?
[22:22] <tlrobinson> perl's
[22:22] <kriszyp> ah, ok
[22:22] <tlrobinson> http://bulknews.typepad.com/blog/2009/10/psgiplack-streaming-is-now-complete.html
[22:23] <tlrobinson> also let me know if there's anything wrong with these. it's certainly possible
[22:25] <kriszyp> I am not sure I understand the distinction kriskowal is drawing
[22:25] <tlrobinson> kriszyp: me neither :(
[22:26] <kriszyp> JSGI+Q is equivalent to forEach returning undefined synchronously?
[22:26] <kriszyp> I don't know how to interpret that
[22:26] <tlrobinson> my terminology is probably wrong
[22:26] <tlrobinson> probably best to talk with him directly
[22:26] <kriszyp> ok
[22:27] <tlrobinson> he maintains that JSGI+Q is the correct async equivalent of the synchronous case (where forEach just returns undefined), but the AJSGI example is not equivalent
[22:27] <kriszyp> it appears that in the examples AJSGI and JSGI+Q are doing the same thing, just that the JSGI+Q examples are using the promise/Q library to do so
[22:28] <tlrobinson> kriszyp: thats what i thought but he insisted otherwise
[22:28] <kriszyp> so, it is conceptual match that he is trying to make?
[22:28] <kriszyp> is he saying that they may be behaviourly the same, but not preserving the same mechanics to get there?
[22:30] <tlrobinson> i'm not sure, i'll try to get him in here
[22:30] <kriszyp> I guess you could say that there could be an alteration in timing if then() was called by the JSGI server in a separate event turn
[22:31] <kriszyp> but that shouldn't affect the outcome of your examples
[22:31] <tlrobinson> kriszyp: do my AJSGI examples at least fit your idea of how AJSGI (what i've been calling your proposal) should work?
[22:31] <kriszyp> yes, absolutely
[22:32] <isaacs> tlrobinson: http://gist.github.com/294109
[22:32] <isaacs> that make sense?
[22:32] <kriszyp> I mean I would certainly prefer using a library than hand coding then() impls in real life :)
[22:33] <kriszyp> EJSGI includes an alternate promise format proposal?
[22:33] <kriszyp> s/format/API
[22:33] <isaacs> kriszyp: actually, i just sorta... didn't spec that.
[22:33] <isaacs> kriszyp: in EJSGI,i use node's require("events").Promise
[22:34] <isaacs> or rather, i sniff for addCallback on the response obj.
[22:34] <kriszyp> just curious, I didn't know if that was at the heart of what you were after or not
[22:34] <isaacs> not really.
[22:34] <isaacs> i've thought actually it'd be good to supply a "done" function to the app.
[22:34] <isaacs> then app calls that rather than returnign
[22:34] <isaacs> but it'd be trickier to write middlewrae.
[22:35] <isaacs> every mw would have to wrap the app and the done fn
[22:36] <tlrobinson> kriszyp: and Q would be one of those libraries?
[22:36] <kriszyp> we have Q
[22:36] <kriszyp> (in narwhal)
[22:36] <kriszyp> var Q = require("promise");
[22:36] <kriszyp> or var Q = require("events");
[22:36] <kriszyp> I think they both implement it :P
[22:37] <kriszyp> or try too anyway
[22:37] <tlrobinson> right i mean is kris k's Q example what using a library for my "then" example would look like?
[22:37] <kriszyp> so yes, Q would be one of those libraries :)
[22:37] <kriszyp> yes
[22:37] <kriszyp> sorry, I should give straight answers
[22:37] <ashb> git subtree FTW
[22:41] <ashb> http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
[22:42] <kriszyp> anyway isaacs, the point with promise thing in the EJSGI example is that promises in AJSGI are premised on promises being potentially used in other places in CommonJS, so obviously we wouldn't want to use a different promise API in JSGI than elsewhere. If you don't like the promise API, then I would think you would want to provide an alternate promise proposal. But if you don't care about...
[22:42] <kriszyp> ...the promise API, I guess it doesn't matter :)
[22:43] <isaacs> kriszyp: i could not possibly care less about the specifics of the Promise api.
[22:43] <kriszyp> heh, ok
[22:43] <isaacs> afaic, they're just "not ready yet...... ok, here you go"
[22:43] <isaacs> anything that can do that is fine by me. preferably with as little memory and cpu overhead as possible.
[22:44] <isaacs> i dont' care about chaining, nesting, mutability, scope, or any of that. a simple event emitter or callback thing is more than enough.
[22:44] <isaacs> imo, ref-send is severe overkill, and belongs at the library level, not in the spec.
[22:46] <tlrobinson> isaacs: you know, EJSGI implementation could simply be this env.jsgi.stream object implemented on top of AJSGI. it would be an object that poses as both a stream and a promise
[22:46] <isaacs> i'd be cool with that.
[22:46] <isaacs> i've pretty much decided that if we all go with AJSGI, i'm going to rejigger EJSGI to support that format, or streams.
[22:47] <isaacs> and then EJSGI will jsut be another AJSGI implementation, with a dash of sugar.
[22:47] <tlrobinson> it's a pretty simple imeplementation too, i think i actually already have something like it in jack
[22:47] <isaacs> suresure.
[22:47] <kriszyp> are you saying that we would standardize env.jsgi.stream as a stream wrapper that is available in AJSGI?
[22:47] <tlrobinson> if we want to standardize it, i guess
[22:47] <tlrobinson> http://github.com/tlrobinson/jack/blob/master/lib/jack/response.js#L164-199
[22:48] <tlrobinson> this is actually the whole response but it could be changed to be just the body
[22:48] <kriszyp> I didn't have any "want", just curious what you were thinking
[22:49] <isaacs> actually, i'd probably take the Stream implementation i alreayd have, and tack a forEach onto it, and call it compliant.
[22:52] <ashb> \o/ I've finally tamed .debs/PPAs
[22:52] <ashb> https://launchpad.net/~commonjs/+archive/ppa/+packages
[22:55] <tlrobinson> the nice thing about AJSGI is it's very easy to build a little helper "stream" like EJSGI provides
[22:56] <tlrobinson> while giving middleware convienent points to hook into
[22:57] <tlrobinson> i haven't thought about it but i suspect building the AJSGI interface on top of EJSGI would be more difficult
[23:00] <isaacs> tlrobinson: it depends on your affinity for Promises vs Streams.
[23:01] <isaacs> tlrobinson: when ryah gets done implementing a Stream API in c-land, they'll be native and all over the place.
[23:01] <kriszyp> fwiw, the most awkward part of AJSGI on top of Node was the request.input handling due to the current spec's lack of async support for reading the request body, if we following the same paradigm as the response.body for the request.body it would be better
[23:02] <isaacs> kriszyp: absolutely. whatever comes of this, request.body and response.body should be the same kind of 100% async thing.
[23:02] <kriszyp> and character encoding... which has been surprisingly absent from these conversations
[23:02] <isaacs> one for input, another for output.
[23:02] <kriszyp> yes
[23:02] <isaacs> kriszyp: hasnt' been absent from my thoughts, though.
[23:02] <kriszyp> heh, good :)
[23:02] <tlrobinson> oh... yeah i keep forgetting about input
[23:02] <isaacs> that definitely needs to be cleaned up in node.
[23:03] <kriszyp> will node always just have three encodings?
[23:03] <ashb> i spose non-seekable char streams are too hard
[23:03] <ashb> seeking on a character based stream is a *right* pain
[23:03] <isaacs> kriszyp: have to bug ryah about that.
[23:03] <isaacs> but yeah, i'd really love to be able to proxy an infinite feed or something.
[23:03] <ashb> *aren't
[23:03] <isaacs> that necessitates an async in and out.
[23:04] <isaacs> or like, something xmpp/socket-like, where you're uploading messages to the server, and pushing things back down, and it never ends.

 

 

Logs by date :