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

2010-04-01:

[16:22] <Wes-mac> kriszyp: ping
[16:23] <kriszyp> hi
[16:24] <kriszyp> hi Wes-mac
[16:24] <Wes-mac> kriszyp: You mentioned on the list today the anti-benefits of source transform + eval
[16:25] <kriszyp> yeah
[16:25] <kriszyp> and the drawbacks too
[16:25] <Wes-mac> kriszyp: I got to thinking -- what GPSEE does is almost exactly analogous to loading modules in separate IFRAMEs -- is that doable in the browsers of today?
[16:26] <kriszyp> well, kind of
[16:26] <kriszyp> if you load a script in a separate iframe from the same domain it still has access to everything in the original frame
[16:26] <Wes-mac> I honestly can't remember if they've added security restrictions since the 4 days -- and also don't know how expensive pushing that DOM node is
[16:26] <kriszyp> but if it is in a different domain, it can't access the original domain
[16:27] <Wes-mac> Okay, that's sounds pretty similar, drawback is that forces same origin policy
[19:45] <konobi> so... have a new commonjs implementation to report
[19:46] <deanlandolt> konobi?
[19:46] <konobi> http://commonjstests.smartly.be/
[19:46] <konobi> Joyent Smart platform
[19:47] <deanlandolt> awesome
[19:48] <deanlandolt> konobi: that wouldn't happen to be testing node, would it? :D
[19:48] <konobi> nope
[19:48] <konobi> smart != node
[19:49] <deanlandolt> yeah, i wasn't sure if it was something new
[19:49] <deanlandolt> that's spectacular
[19:49] <ashb> cloud platform
[19:49] <ashb> and i've made a start on writing a (sync) JSGI wrapper
[19:50] <konobi> ashb: I probably need to add stuff on the backend to pass through more information
[19:50] <ashb> probably. but it's enough for simple cases right now
[19:50] <konobi> =0)
[19:50] <konobi> so yar... someone was bugging me to bug someone about adding it to the wiki
[19:55] <konobi> no idea who to bug
[19:55] <konobi> =0)
[19:56] <ashb> it be a wiki ;)
[19:57] <deanlandolt> konobi: definitely announce it on the ML too
[19:57] <ashb> wow thats quite a thread on the mailing list
[20:00] <ashb> oh fuck of you and your static analsysis.
[20:00] <ashb> *off
[20:00] <ashb> </nerd-rage>
[20:00] <konobi> deanlandolt: *blink*
[20:06] <ashb> deanlandolt: fwiw flusspferd has build in moudles too. fs-base or binary modules for instane. and these (top-level-ids) are checked before going to files on disc
[20:07] <ashb> we could do the check afterwards quite easily instead
[20:07] <deanlandolt> ashb: well, your modules are actually commonjs-compliant so it's not a huge issue :)
[20:07] <ashb> heh
[20:22] <Wes-mac> konobi: that was me, bug dantman
[20:22] <Wes-mac> deanlandolt: GPSEE is somewhere in the middle
[20:22] <Wes-mac> deanlandolt: We have "internal" modules which are statically linked. Those /always/ win
[20:22] <Dantman> Should I add a note to the footer of the wiki like I did to the website?
[20:23] <Wes-mac> deanlandolt: Then we have a system module path with .js or .so in it
[20:23] <Wes-mac> deanlandolt: THEN we search require.paths
[20:23] <Wes-mac> 'system module path' is overrideable with an environment variable
[20:24] <Wes-mac> have you ever had one of those days?
[20:24] <deanlandolt> Wes-mac: are your system modules largely commonjs modules or does it have a bunch of stuff in there?
[20:24] <Wes-mac> where you make 100 trivial changes
[20:25] <Wes-mac> but it turns out, one of them isn't
[20:25] <Wes-mac> (and you don't know which one? ;) )
[20:25] <Dantman> Ooooh, adding an implementation to the wiki
[20:25] <deanlandolt> Wes-mac: well, just start over...one...at...a...time ;)
[20:25] <Wes-mac> deanlandolt: A bit of both. Careful to avoid namespace conflicts, but got bit by 'system' already (I predate commonjs)
[20:26] <deanlandolt> great
[20:26] <Wes-mac> deanlandolt: I have been trying to think of how to partition a bit better -- for example, when adopting node or rhino APIs
[20:26] <Wes-mac> My current thought is quickie package manager so that I can
[20:26] <Wes-mac> require("rhino").require('blah')
[20:27] <Wes-mac> Then blah gets a different require so that rhino code just works
[20:27] <Wes-mac> 'package manager' in the loosest sense of the word, BTW
[20:27] <deanlandolt> that seems like it would work, at least for your internal code
[20:27] <Wes-mac> OTOH, if rhino code is all written with RELATIVE includes, problem just magically goes away
[20:27] <deanlandolt> the argument that peppering "common" code with those required package managers sways me though
[20:28] <Wes-mac> and I think that maybe that is the largest part of the problem
[20:28] <deanlandolt> Wes-mac: well, there's a reason you don't /always/ want to use relative includes -- and this hasn't gotten any love on the list, perhaps i should right it up...
[20:28] <Wes-mac> -- lack of use of relative identififies
[20:28] <konobi> ditto on the "system" stuff
[20:29] <deanlandolt> skipping relatively identifiers and going with top-level requires is effectively like requiring an implemention of an interface
[20:29] <deanlandolt> (without all the javasuck)
[20:29] <Wes-mac> Hmm.
[20:29] <Wes-mac> There is a good solution here. I wish I could just brush away enough cruft to see it.
[20:30] <deanlandolt> but for instance, on the persevere list we were just talking about how one could go about overriding query parsing...the most elegant thing to do would be to something like require("persevere/query-parser") in persevere instead of require("./persevere/query-parser") ...
[20:30] <deanlandolt> then, you can use require.paths overlays to implement your own query parser and actually override the functionality of the lower-level lib
[20:30] <Dantman> konobi, http://wiki.commonjs.org/wiki/Special:AddData/Implementation/Implementations/Smart
[20:30] <deanlandolt> thus, persevere is just requiring the "persevere/query-parser" interface, not the concrete implementation (of which it just provides one)
[20:31] <Dantman> Add "Smart" to the comma separated |implementations= list in any spec it implements.
[20:31] <Wes-mac> Hmm. But now we have non-deterministic require() behaviour, which I /abhor/
[20:31] <Wes-mac> I would be happier with a require.replace() frankly
[20:31] <Wes-mac> for that use case
[20:32] <deanlandolt> how is it non-determinstic?
[20:32] <deanlandolt> it depends on your reuqire.paths, but it does anyway
[20:32] <Wes-mac> deanlandolt: let's say I have the following tree
[20:32] <deanlandolt> it's deterministic for a given value of require.paths
[20:32] <Wes-mac> deanlandolt: right - but changing require.paths changes it for /everything/
[20:32] <Wes-mac> what if it now conflicts with something completely unrelated?
[20:32] <deanlandolt> sure, but that's always the case unless you use rel paths
[20:33] <deanlandolt> well, Don't Do That? ;)
[20:33] <deanlandolt> yeah, i see
[20:33] <Wes-mac> No, relative paths are deterministic if they are implemented right*
[20:33] <Wes-mac> *imho
[20:33] <deanlandolt> i agree, relative paths are...
[20:33] <deanlandolt> but they're not always the right solution
[20:33] <deanlandolt> what about system level modules?
[20:33] <Wes-mac> what about them?
[20:34] <deanlandolt> you can't require system-level modules with relative paths, can you?
[20:34] <deanlandolt> what about /interpackage/ requires?
[20:35] <deanlandolt> would you want to couple the dependency based on filesystem layout?
[20:35] <deanlandolt> i guess i'm just not sure how you can use relatively paths outside of intrapackage requires
[20:36] <Wes-mac> deanlandolt: A system-level module can require other system-level modules with relative paths
[20:36] <Wes-mac> basically, they have a common provider so they're good to go
[20:37] <konobi> Dantman: k... I don't see it on the Implementations page now though
[20:37] <Dantman> refresh tab
[20:38] <deanlandolt> Wes-mac: sure, but a package can't require a system level module with relative paths...
[20:38] <deanlandolt> is there any way to use relative paths between packages? not that i'm aware at least
[20:39] <konobi> voila
[20:39] <Dantman> konobi, C or C++?
[20:39] <Wes-mac> Hmm. I'm not convinced that replacing system modules is a CommonJS reasonable goal anyhow
[20:39] <konobi> Dantman: check the github project
[20:39] <konobi> =0)
[20:39] <konobi> oh... it's Spidermonkey/C
[20:39] <Wes-mac> I mean, how could you possibly do that portabiy?
[20:40] <Dantman> *sigh* There goes my workstation...
[20:40] <deanlandolt> Wes-mac: not replacing -- but specifying their interfaces...that's what i thought at least
[20:41] <Wes-mac> deanlandolt: Hmm: so what you are pointing out is that we need a
[20:41] <deanlandolt> you can have your own sys-level modules too, but it'd be great if we could come up with a convention to prevent collisions
[20:41] <Wes-mac> exports.system.require = function(arg) { require("./" + arg) }
[20:41] <deanlandolt> kriskowal has been refactoring narwhal to take all non-commonjs modules out of the root system namespace and put into a narwhal namespace
[20:41] <Wes-mac> deanlandolt: That's a wise goal which I should be doing too
[20:42] <deanlandolt> Wes-mac: that's not really what i'm suggesting but i don't actually see the problem with that if the require is relative to the system and not to the module
[20:42] <konobi> "impl"
[20:42] <deanlandolt> what i'm suggesting is the stuff in the "top level" be specified interfaces if at all possible
[20:43] <Wes-mac> deanlandolt: Er, I meant for that function to be part of the system module
[20:43] <deanlandolt> commonjs or otherwise
[20:43] <Wes-mac> deanlandolt: I can't really read the writing on this computer :(
[20:43] <deanlandolt> heh :)
[20:43] <Wes-mac> stupid macs stuck at 96dpi
[20:43] <Wes-mac> I always have a headache by the end of the day
[20:44] <konobi> if someone wants to announce the smart implementation on the mailing list... feel free to go nuts
[20:44] <Wes-mac> I wonder if I can lower the screen resolution..
[20:44] <Wes-mac> konobi: that's your job :)
[20:44] * konobi will not sign up to yet another mailing list
[20:44] <konobi> =0P
[20:45] <konobi> ah... $cow_orker is gonna do it
[20:45] <Wes-mac> konobi: so read it on the web

 

 

Logs by date :