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

2010-02-18:

[21:17] <Wes--> ash: ping
[21:34] <kriskowal> Wes--, ash: ping
[21:35] <kriskowal> ashb^
[21:35] <Wes--> kriskowal: think of the devil
[21:35] <kriskowal> hah, speaking
[21:35] <Wes--> kriskowal: I believe I have solved the riddle of making useful sandboxes in spidermonkey
[21:35] <kriskowal> oh, good. i've made progress on getting narwhal on node
[21:36] <kriskowal> and we have some sandboxing experiments in narwhal now?
[21:36] <kriskowal> tom wrote up an "interpreter" module that works for rhino.
[21:36] <Wes--> kriskowal: I just re-implemented modules (more JIT friendly) - part of my technique is a C-level proxy between module-scope and global-scope: global is not actually on module's scope chain, but it acts like it
[21:36] <kriskowal> new Context() creates a new context object, and context.{eval,Function,Module} construct objects that execute therein
[21:36] <Wes--> neat!
[21:36] <tlrobinson> kriskowal: "works" for JavaScriptCore except for native modules
[21:37] <kriskowal> cool. prolly'll do a version for node too, which has the potential of being much cleaner under the hood
[21:37] <tlrobinson> kriskowal: cleaner how?
[21:37] <kriskowal> Wes-- that's very similar to what hannes is doing in rhino
[21:38] <kriskowal> tlrobinson: the Module constructor could reuse complied code, possibly
[21:38] <kriskowal> which is the intent from the beginning; scope injection "with"out
[21:38] <Wes--> My big hassle was keeping instanceof working properly, the interpret plays games with class pointers when you use array or object literals
[21:38] <kriskowal> aye
[21:39] <Wes--> An interesting side effect, though, is that un-vared decls now stay in module
[21:39] <kriskowal> i'd like to run some thoughts by you and ashb, and open it up as a broader discussion?about conventions for commonjs module names
[21:39] <Wes--> I suspect you may have missed ash for the day, it's 8:45 pm where he's at
[21:40] <kriskowal> ah, well, that's alright; we'll pick him up later
[21:40] <Wes--> but I'm open
[21:40] <kriskowal> ryah_away would prefer synchronous APIs to be "second class" generally
[21:40] <kriskowal> presently we have sync api's squatting in prime real-estate of the module namespace
[21:41] <Wes--> you mean "require" ?
[21:41] <kriskowal> require("fs-base") particularly
[21:41] <Wes--> Hmm
[21:41] <kriskowal> i think ryah's ideal world would have "fs" be async and have something like "sfs" or "fs-sync"
[21:42] <Wes--> FWIW I Have production code using fs-base, but I'm not too tied to names ATM
[21:42] <kriskowal> narwhal isn't tied to the name yet either
[21:42] <kriskowal> we have a "file" module that's not going anywhere any time soon; it's my intent to deprecate it and move things over to "fs" when we've converged on that layer
[21:42] <tlrobinson> fs-base seems like an odd name for a public api
[21:43] <kriskowal> summarily, i think we might consider "sfs-base" for the name
[21:43] <kriskowal> fs-base is like the file-engine in narwhal
[21:43] <Wes--> I wouldn't object to that
[21:43] <kriskowal> it's not really intended to be public, but it establishes the intent to have a public "fs" module
[21:43] <tlrobinson> oh ok
[21:43] <Wes--> BTW, have any of you guys got narwhal running on a hotspot java jit?
[21:44] <kriskowal> tlrobinson, we might consider moving -engine to -base to remain consistent, since i wasn't able to sell these folks on fs-engine
[21:44] <kriskowal> i think we did at one time try that out, Wes--
[21:44] <tlrobinson> Wes--: is that different than the hotspot included in java w/ OS X?
[21:45] <tlrobinson> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
[21:45] <Wes--> tlrobinson: honestly, I don't know. I just know that rhino is slow as hell on my solaris box -- prompting a port of a jsdoc-toolkit from rhino to fs-base and friends so I could run it on spidermonkey
[21:45] <tlrobinson> its slow as hell everywhere
[21:46] <kriskowal> Wes-- i'll run the idea of fs (async) sfs (sync) sfs-base (sfs engine-specific subset) by the list at some point. i've gotta do a presentation here in a few minutes. ttyl
[21:46] <Wes--> kriskowal: roger that -- no alarm bells from here fwiw
[22:16] <Wes--> kriskowal: ryah_away: Second thought: 1st class vs. 2nd class not something I endorse, though. Implies direction-dictating. I prefer the idea that CommonJS makes proposals and lets implementors take up what they wish.
[22:30] <tlrobinson> Wes--: i think there needs to be a core set of things you should implement to be able to call yourself a CommonJS implementation
[22:31] <tlrobinson> modules, obviously
[22:31] <tlrobinson> probably binary data
[22:31] <tlrobinson> ...data types
[22:31] <Wes--> tlrobinson: past require, you should be able to feature-test everything to determine level of compliance
[22:31] <Wes--> but that is a little .. unsavoury
[23:49] <kriskowal> Wes-- i agree that some implementations may want to only have either sync popen or async popen and we should not dictate here which; it should be the option of the implementor. it should be possible to do both. it should also be possible for an application to depend on one or the other reliably, so they need different names.

 

 

Logs by date :