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

2010-03-06:

[13:25] <MisterN> Wes-: haha "I know all about academia" - made me laugh
[14:15] <Wes-_> :)
[17:37] <tobie> Looking at the modules 1.0 specs http://github.com/commonjs/commonjs/tree/master/tests/modules/1.0/ (especially the monkeys spec), it seems that program.js itself should be loaded as a module or at least have an exports free variable. Can someone advise whether or not this is part of the spec?
[17:37] <Wes-_> tobie: it is
[17:38] <Wes-_> tobie: although I'm not sure how explicit it is
[17:38] <Wes-_> tobie: But programs are modules
[17:38] <Wes-_> tobie: so require("program") in fact refers to the program's exports object, if the program is named program.js
[17:40] <ashb> we have a similar thing to python modules:
[17:40] <ashb> if (require.main === module) main()
[17:40] <ashb> (equally explicit
[17:40] <ashb> tobie: you wrote pdoc, right?
[17:40] <tobie> ashb: yes.
[17:40] <ashb> cool.
[17:41] <ashb> i'm toying with re-implementing it in JS
[17:41] <tobie> I'm working on modulr right now (hence my questions)
[17:41] <ashb> we use it for our docs: http://flusspferd.org/docs/js/
[17:41] <tobie> http://github.com/codespeaks/modulr
[17:41] <tobie> ashb: nice.
[17:41] <Wes-_> Does pdoc read javadoc? or jsdoc? Or something else?
[17:42] <ashb> http://github.com/ashb/pdoc-commonjs/tree/js-port/
[17:42] <tobie> ashb: I've got some cool updates in the works for pdoc
[17:42] <ashb> tobie: such as?
[17:42] <ashb> the only change i've made so var is 'mdoule' support
[17:42] <ashb> module foo-bar
[17:42] <ashb> class foo-bar.Baz
[17:42] <ashb> etc.
[17:43] <ashb> Wes-_: http://github.com/ashb/pdoc-commonjs/tree/js-port/
[17:43] <tobie> ashb: well, lots of inside decoupling
[17:43] <ashb> ahh
[17:44] <ashb> i have to admit the relationship between treetop and pdoc itself is quite fuzzy to my mind
[17:44] <ashb> tobie: so what does modulr do?
[17:44] <tobie> ashb: which already allowed me to link each documented method to its src code on github
[17:44] <ashb> provides boilerplate for require on the client?
[17:44] <tobie> ashb: yes.
[17:44] <ashb> cool. and cool
[17:45] <tobie> does a static analysis of the JS and resolves dependencies on the server side
[17:45] <tobie> concatenates all modules in a single JS file
[17:45] <ashb> then packages them all up in a 'prelaod and register this moduel to the require' approach?
[17:45] <tobie> and provides a really small, namespace lib for providing a require function in JS
[17:46] <ashb> Wes-_: er, link i meant was http://pdoc.org/syntax.html
[17:46] <tobie> ashb: re pdoc, I'd like to get rid of the treetop parser all together
[17:46] <tobie> and make the overall syntax less Prototype-centered.
[17:46] <ashb> tobie: it seems to work reasonably well for parsing the signs themselves
[17:47] <tobie> ashb: it's awful.
[17:47] <ashb> that would be nice. the utility behaviour is certainly very $P
[17:47] <tobie> yeah.
[17:47] <ashb> i attempted to hack in a utility tag
[17:47] <ashb> but the generators weren't quite structured right
[17:47] <tobie> I think you'll prefer the upcoming changes
[17:48] <tobie> the architecture is much better
[17:48] <ashb> http://github.com/ashb/pdoc-commonjs/blob/js-port/lib/pdoc/parser/ebnf.peg
[17:48] <ashb> does is the grammar i'm using to do the parsing of (most) of the sigs.
[17:48] <ashb> oh yeah - why do you call them EBNF?
[17:48] <ashb> they aren't any form of EBNF i've seen before
[17:49] <ashb> hmm i just realised my ModulePrefix isn't quite right
[17:49] <ashb> it doesn't allow '/' separators like it should
[17:49] <tobie> ashb: It's based on a legacy sintax we used for the old doc
[17:50] <ashb> since require('foo/bar') works
[17:50] <tobie> and which was called ebnf
[17:50] <ashb> ah.
[17:50] <ashb> anyway - i really like the output and the input styles for PDoc. shame the thing is so memory hungry :(
[17:50] <tobie> Yeah, that's the treetop parser
[17:50] <ashb> tobie: back to your original question:
[17:51] <tobie> (one more reason to get rid of it)
[17:51] <ashb> http://github.com/ashb/pdoc-commonjs/blob/js-port/test/parser.t.js#L61-62
[17:51] <tobie> for the record, the decoupling I'm about to push fixes the memory issue quite a bit
[17:51] <ashb> ah good to know
[17:51] <ashb> i will update our git submodule and see if the usage goes down
[17:52] <tobie> haven't pushed thoses changes yet, btw
[17:52] <ashb> k
[17:52] <tobie> require.main is 1.1 specs, correct?
[17:52] <ashb> medium term i'd still lioke a JS port so that i can have everything JS
[17:52] <ashb> ummm. lemme check
[17:52] <tobie> I'd love for a JS port.
[17:53] <ashb> commons test suite would be super too.
[17:53] <ashb> but need to work out some way of that
[17:53] <ashb> since dependance on the exact whitespace output is a pain
[17:53] <ashb> use require.main is 1.1
[17:54] <tobie> k
[18:00] <tobie> I'm going to get 1.0 compliance first.
[18:00] <tobie> The main difference with 1.1 is the module free variable, right?
[18:01] <Wes-_> tobie: I think so, yes
[18:01] <Wes-_> tobie: And the free variable's big-deal is being able to specify the module path
[18:01] <ashb> if you are making the loader functions that is just a case of adding an extra param
[18:01] <Wes-_> tobie: "I'm going to get" - are you writing yet another server side commonjs system?
[18:01] <ashb> less of an issue in the browser tho
[18:01] <ashb> client side
[18:01] <ashb> ruby bundler/preloader
[18:02] <Wes-_> ah, makes sense!
[18:05] <tobie> Wes-_ http://github.com/codespeaks/modulr
[18:07] <Wes-_> say, that's quite interesting
[18:07] <Wes-_> I have considered doing something similar in server side javascript (replacing the ruby bits there)
[18:07] <ashb> http://github.com/codespeaks/modulr/blob/master/assets/modulr.js
[18:08] <Wes-_> But, do not have a tardis
[18:08] <ashb> tobie: your JS is written better than some 'js hackers' i know :)
[18:09] <tobie> I'm essentially a JS programmer.
[18:09] <ashb> the key difference being you know other languages
[18:10] <Wes-_> throw 'Can\'t ovewrite module "' + identifier + '".';
[18:10] <Wes-_> spelling error, fwiw
[18:10] <tobie> heh
[18:10] <tobie> ty
[18:10] <ashb> right time for more starcraft2
[18:12] <tobie> ashb: well, have fun. Thanks for the help.
[19:58] <ashb> whee fun
[21:21] <tobie> Does the module 1.0 spec say anything about the value of the `this` object?
[21:21] <tobie> I couldn't find any mention of it.
[22:58] <kriskowal> tobie: no
[22:58] <kriskowal> deliberately not defined
[22:59] <tobie> kriskowal: thanks.
[22:59] <kriskowal> tobie lengel, i presume?
[23:00] <tobie> You're presuming right (though you got the spelling wrong).
[23:00] <tobie> How are you doing?
[23:00] <kriskowal> good to see you
[23:00] * kriskowal looks up
[23:00] <tobie> Langel
[23:00] <kriskowal> ah, yeah, thanks
[23:00] <tobie> Good to see you too.
[23:00] <kriskowal> sorry 
[23:00] <tobie> np
[23:01] <kriskowal> i'm good. working on too many things, but that's not new.
[23:01] <kriskowal> and thou?
[23:03] <tobie> Doing absolutely great: my wife gave birth to a little girl just over 3 weeks ago.
[23:03] <tobie> (It's our first. Quite an adventure.)
[23:04] <kriskowal> oh, wow
[23:05] <kriskowal> i should explain that "this" was not specified because it is not possible to constrain it to any particular value in the wide variety of contexts that the system was intended to be implemented on, and the variety of implementation strategies we anticipated
[23:06] <kriskowal> we really need to write up an FAQ :P
[23:06] <tobie> heh.
[23:06] <kriskowal> with the whole story
[23:06] <kriskowal> before it fades from memory
[23:07] <tobie> Do you think you could spare the time to have a look at modulr? (http://github.com/codespeaks/modulr)
[23:07] <kriskowal> sure
[23:07] <tobie> ty
[23:08] <kriskowal> ah, neat
[23:08] <tobie> It doesn't implement 1.1 specs yet.
[23:08] <tobie> just 1.0
[23:09] <kriskowal> yeah, and strict, nice
[23:10] <tobie> strict?
[23:10] <kriskowal> validation of the identifier namespace
[23:11] <kriskowal> ah, and you're using a registrar pattern
[23:11] <kriskowal> http://wiki.commonjs.org/wiki/Modules/Transport
[23:13] <kriskowal> ah, so you have everything in place for async loading, it seems
[23:14] <tobie> How so?
[23:15] <kriskowal> it's only necessary to do dependency analysis at load time if you are expecting to implement an asynchronous require
[23:15] <kriskowal> otherwise it's sufficient for require to block
[23:16] <tobie> What this does is resolve all dependencies server-side and concatenate them into a single file.
[23:16] <kriskowal> which is to say, you're ready for modules 2.0, whatever that ends up being
[23:16] <kriskowal> aaah
[23:16] <kriskowal> then, yeah, that's all necessary; got it
[23:16] <kriskowal> your main require is async then
[23:16] <kriskowal> i did something similar in pure-js
[23:17] <tobie> No, it's bundled with the program and it's dependencies.
[23:17] <tobie> But it could be async, though.
[23:17] <kriskowal> i see.
[23:17] <ashb> async != preloading
[23:18] <ashb> different and possibly overlapping
[23:18] <kriskowal> yeah, yeah. i've done both; the strategies are similar
[23:18] <kriskowal> i've got a bundler like this for python/django at work
[23:19] <kriskowal> in any case, i'm not seeing the bits for prevent cyclic dependency resolution
[23:19] <tobie> What I suppose you meant, kriskowal, is that the initial require, the one that requires the _program_ can be async.
[23:19] <kriskowal> yes
[23:19] <kriskowal> i do see that your module factory functions are returning the exports object; if you're using that, there might be a bug
[23:20] <kriskowal> are you passing the cyclic compliance test?
[23:20] <tobie> yes.
[23:20] <tobie> for cyclic reference, I store exports objects into `emptyExports`
[23:21] <kriskowal> you could probably simplify that by just pre-memoizing the exports object
[23:22] <tobie> I can also avoid returning the exports object, you're right.
[23:22] <kriskowal> unless you're pushing for modules that return their exports, which is beyond spec
[23:23] <kriskowal> if you *do* want to support returning exports in some non-compliant modules, there is a hazard you'll need to dodge?
[23:23] <tobie> I'm not pushing for anything right now. Just want to figure out if this is usable for client-side scripting or not.
[23:23] <kriskowal> k
[23:24] <tobie> (And just trying to get my head around it all.)
[23:24] <kriskowal> looks like you've got a great grasp on it in any case
[23:24] <tobie> ty. it took me quite a while to figure out what was going on.
[23:25] <tobie> If you pre-memoize, you also need some kind of stack to prevent cyclic references, don't you?
[23:26] <kriskowal> no
[23:26] <kriskowal> you just need to short-circuit require by returning the memoized exports object if it's already there
[23:27] <kriskowal> and your dependencies have to use late binding to avoid referencing non-existent properties of a module that hasn't completed yet
[23:27] <tobie> That's already the case.
[23:28] <kriskowal> aye
[23:28] <tobie> Thanks for the tip, I'll have a second look at it tomorrow.
[23:29] <kriskowal> really, the only difference is that you can collapse _emptyExports to just _exports and not set the exports on the return value of the factory
[23:29] <tobie> Right.
[23:29] <tobie> Will look much nicer, too.
[23:31] <tobie> Definitely much nicer. Thanks a lot!

 

 

Logs by date :