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

2010-04-24:

[0:01] <jbrantly> I wonder if concurrency is an issue here (running multiple tests at the same time)
[0:02] <jbrantly> or if it's acceptable to say that tests should be run serially
[0:06] <konobi> rightio... got native commonjs modules working on smart platform
[0:11] <tlrobinson> where's the definitive list of commonjs module implementations? there's a *lot* now
[0:11] <konobi> on the wiki?
[0:12] <tlrobinson> this? http://wiki.commonjs.org/wiki/CommonJS#Implementations
[0:14] <tlrobinson> i don't know if i should bother listing this super simple (probably not compliant) bundler i made http://github.com/tlrobinson/minibundler
[0:16] <jbrantly> tlrobinson: not sure if you saw my message, but I mentioned that Yabble will very soon have that functionality. Also, I took a look at your code and I think it would currently fail some unit tests. On the other hand, as you said, it is super-simple.
[0:16] <tlrobinson> jbrantly: yeah i just wanted the simplest thing that worked
[0:16] <tlrobinson> i don't plan on expanding it
[2:10] * jhuni is thinking about how to handle free variable exportation - http://gist.github.com/377393
[2:18] <jbrantly> jhuni: yea, not a fan. Transport/C and /D has similar stuff.
[2:19] <jbrantly> jhuni: plus it looks like you're getting into what I like to call configuration hell. You don't happen to come from a Java background, do you?
[2:20] <jhuni> jbrantly: perl background
[2:21] <jhuni> jbrantly: I didn't realize that Transport/D supported exports?
[2:22] <jhuni> nvm I think it handles exports with {"injects":[]}
[2:22] <jbrantly> jhuni: right, although it doesn't specify what the values really resolve to
[2:23] <jhuni> jbrantly: if a good way to handle free variables could be developed then I don't think it would be hellish
[2:24] <jbrantly> but why? I think require + package management is good enough
[2:25] <jhuni> jbrantly: some users want it I guess
[2:25] <jhuni> jbrantly: it'd probably function as like a non-standard plugin if anything
[2:26] <jhuni> BTW do you mind if I use your "determineShallowDependencies" function here ? http://github.com/jhuni/Module-Metadata/blob/master/lib/META/HandleUtils/parseCJS.js
[2:27] <jbrantly> jhuni: no, but keep in mind (like the comment says) it currently has a bug with comments
[2:29] <jhuni> jbrantly: good point, but its good to have something that works for now
[2:29] <jhuni> jbrantly: currently the only way I can handle the metadata from a file is with a bundler to bundle it into something stand-a-lone but I want to build some ways to use the transport formats as well
[2:30] <jhuni> jbrantly: It can bundle commonjs modules with that parseCJS script
[2:31] <jhuni> the point is these handlers would work for Modules/1.1.1 and for manually specified metadata scripts
[2:35] <jbrantly> jhuni: my point is any module that uses these free variables is no longer Modules/1.1.1
[2:36] <jhuni> jbrantly: which free variables, the ones from is_export?
[2:37] <jbrantly> jhuni: yea. Not saying that Modules/1.2 might not support something like that though. But it's not a direction I want to go.
[2:37] <jhuni> jbrantly: is_export may as well be a non-standard plugin for users that want it (for now)
[2:38] <jhuni> its easy to add your own keys to the metadata and handle them however you like
[12:18] <kuya_> ashb: i need a sleep function... would i need to write a whole c module?
[12:19] <ashb> to what end?
[12:19] <ashb> (i mean how/why do you want to sleep?)
[12:20] <kuya_> i quess i could just use cron actually
[12:20] <ashb> there is zest.reactor.setTimeout
[12:20] <ashb> and setInterval
[12:21] <kuya_> ah i hadnt thought to put it in the http server
[12:21] <kuya_> that works tho! thanks
[12:25] <ashb> kuya_: looked at the asnyc ideas?
[12:26] <kuya_> yes i trawled thru a load this morning
[12:27] <kuya_> unfortunatly my browser crashed since then... so ill have to dig up stuff again :|
[12:27] <ashb> :S
[12:39] <kuya_> this was the sanest thing i found http://github.com/zimbatm/nodejs-http-websocket
[12:43] <kuya_> i need to do some more looking tho
[12:44] <ashb> k
[12:47] <kuya_> i didnt find anything related to jsgi :(
[12:48] <ashb> did you check the narwhal mailing list?
[12:49] <kuya_> that is a good search... :]
[17:57] <kuya_> ashb: have you looked at this? http://wiki.commonjs.org/wiki/JSGI/ForEachStreaming
[17:58] <ashb> dont think i have, no
[17:58] <kuya_> altho i know you said you didnt like promises yesterday...
[18:00] <ashb> dont mind it so much. but that proposal seems to add 2 other unrelated things
[18:00] <ashb> specifically 'charset' and 'url' properties
[18:01] <ashb> also slightly misleading - i guess request.body would have a read callback, not a write
[18:02] <ashb> oh no - it seems you just get arbitrarty chunks of data
[18:03] <kuya_> yea
[18:03] <ashb> i wonder why body.forEach on the body is still a funciton, and not a promise directly...
[18:03] <kuya_> shame kris isnt here...
[18:03] <kuya_> :)
[18:04] <ashb> its not like it would be meaningful without handling promises (you'd just end up with [Object object] or similar as the body)
[18:04] <ashb> or infact with nothing
[18:04] <ashb> since you don't call the write function
[18:04] <ashb> oh cos there's no way to pass things to promises i guess
[18:05] <ashb> so you need a closure to get the write callback
[18:06] <ashb> oh maybe you can with the promise.put
[18:10] <kuya_> it is a little confusing
[18:10] <ashb> yeah :D
[18:11] <kuya_> http://groups.google.com/group/commonjs/browse_thread/thread/e1b5c60b9ec98c80/041018c1c0024f47
[18:11] <ashb> i think issacs had an AJSGI (or was it EJSGI) proposal too
[18:11] <kuya_> (the top post)
[18:11] <kuya_> ejsgi is also mentioned alot in that thread :)
[18:12] <ashb> but yeah - basically I'm putting the research effort on your shoulders
[18:12] <ashb> what ever you decide you like the most i will try to implement :D
[18:12] <kuya_> :]
[18:13] <kuya_> i dont know if this needs to be jsgi really
[18:14] <ashb> if you decide you like node's http api i could do that too
[18:14] <kuya_> you just want to be able to take a request and upgrade it to something that has data() and close() methods
[22:15] <tlrobinson> deanlandolt: do you recall if there were a lot of people who wanted to replace "pathInfo" with "path", "queryString" with "query", etc?
[22:15] <tlrobinson> deanlandolt: also what's your opinion?
[22:16] <tlrobinson> after letting it sit for a few months i'm not sure of my opinion any more. intially i wanted it to be derived from the *GI names, but its so different now i'm not sure i care
[22:17] <ashb> ^^ that
[22:18] <ashb> whact about scriptName?
[22:19] <tlrobinson> i don't know
[22:19] <tlrobinson> but if i was the only one clutching to the *GI derived names I'm willing to re-evaluate
[22:19] <ashb> tbh it doesn't really matter unless you are doing raw JSGI
[22:20] <ashb> which in a lot of cases i don't think many will be
[22:20] <ashb> (but of course it shouldn't be painful for anyone if they want to)
[22:20] <tlrobinson> ashb: personally i like writing JSGI apps + middleware + helpers
[22:20] <tlrobinson> so making it nicer is a good thing
[22:20] <ashb> sure, but do you use a route middelware?
[22:21] <ashb> or write it manually each time
[22:21] <tlrobinson> ashb: yeah i use Jack's URLMap... but that just multiplexes to other JSGI apps
[22:22] <tlrobinson> its JSGI all the way down
[22:22] <ashb> sure :) but you don't deal with .path(Info) very often directly do you?
[22:23] <ashb> but personally I don't care what the name is so long its there
[22:23] <tlrobinson> maybe not that one in particular
[22:23] <tlrobinson> but there's also requestMethod, which could be method, etc
[22:23] <tlrobinson> i don't care much either
[22:23] <ashb> yeah.
[22:24] <ashb> my general incliation is for shorter/one-word names where possible
[23:00] * Dantman likes .queryString over .query since when you think of a general .query you usually expect something like an object

 

 

Logs by date :