Actually, I was informed on the commonjs list that there's a new set of compliance tests at <http://github.com/kriskowal/commonjs/tree/master/tests/modules/1.0/> and the one on interoperablejs is obsolete.
Also, just this morning i put out a new patch at <https://bugzilla.mozilla.org/show_bug.cgi?id=540724> that already has all the tests I wrote in it - this likely makes your work unnecessary; I'm sorry I didn't wait on you, but I have scarce spare time to work on this, so when I do have, I take advantage of it... By all means though, give it a review. I did end up taking your approach and including the files, as the new set of files wasn't available through command line SVN... Anyway, others might want to take the opportunity to check the current patch - it's now tested with 60% coverage; the untested stuff is mostly to do with cache revalidation. It passes all the compliance tests + my additional implementation tests. Also, a big improvement compared to the previous patch is that I made require() threadsafe, with good concurrent use properties, while not sacrificing performance for single threaded use. So it can now be used to load modules on demand into a shared top-level scope (which is something many server-side JS embeddings do). Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com On 2010.02.10., at 12:31, Jarosław Pałka wrote: > Ok, > > I will include it in my patch, > > Jarek > > W dniu 8 lutego 2010 10:52 użytkownik Attila Szegedi > <[email protected]> napisał: >> I don't have a problem with depending on external SVN repo. It's unlikely >> that a googlecode SVN will go anywhere. The Rhino build already pulls >> libraries from Maven repositories. I actually started by adding: >> >> <target name="get-interoperablejs"> >> <exec executable="svn" dir="build/test"> >> <arg value="checkout"/> >> <arg value="http://interoperablejs.googlecode.com/svn/trunk/"/> >> <arg value="interoperablejs-read-only"/> >> </exec> >> </target> >> >> to testsrc/build.xml and making junit depend on it: >> >> <target name="junit" >> depends="junit-compile,coverage-instrument,get-interoperablejs"> >> ... >> >> This makes it reside in build/test/interoperablejs-read-only. Alternatively, >> we could have it go under testsrc/org/mozilla/javascript/commonjs/module. >> But I'm really not a fan of hosting 3rd party code in Mozilla CVS, for legal >> reasons. Yes, I know InteroperableJS is MIT licensed, but still. >> >> Attila. >> >> On 2010.02.08., at 9:48, Jarosław Pałka wrote: >> >>> Before I prepare my patch we need to decide where to put >>> interoperablejs. I don't think that having dependencies to external >>> SVN repo is a good solution. I think the best way is to simply commit >>> content of http://interoperablejs.googlecode.com/svn/trunk into >>> mozilla/js/rhino/testsrc/interoperablejs. This way we can also do a >>> changes in tests itself. >>> >>> Let me know what do you think about it. >>> >>> Regards, >>> Jarek >>> >>> W dniu 8 lutego 2010 08:59 użytkownik Attila Szegedi >>> <[email protected]> napisał: >>>> >>>> Hi >>>> >>>> yes, please. I did start working on a JUnit driver for them myself, but if >>>> you already have it completed, I'll be happy to accept your patch and save >>>> me some work. >>>> >>>> Thanks, >>>> Attila. >>>> >>>> On 2010.02.08., at 8:57, Jarosław Pałka wrote: >>>> >>>>> Attila, >>>>> >>>>> I have finished tests with interoperablejs. I wonder how should I share >>>>> it with you. Should I attach tests suite to bugzilla issue? >>>>> >>>>> Jarek >>>>> >>>>> W dniu 8 lutego 2010 08:14 użytkownik Attila Szegedi <[email protected]> >>>>> napisał: >>>>> On 2010.02.07., at 20:33, Jarosław Pałka wrote: >>>>> >>>>>> Attila, >>>>>> >>>>>> I was playing with your patch for few days, and one thing I found is >>>>>> annoying NullPointerException when module is not found :), I believe we >>>>>> should have more meaningful exception message. >>>>>> >>>>>> I am also working on tests, using >>>>>> http://code.google.com/p/interoperablejs/. Were you trying to run your >>>>>> patch against these tests? >>>>> >>>>> Hi, >>>>> >>>>> No, I haven't, but I definitely will now. I'm writing JUnit tests. I just >>>>> recently discovered that there's an EMMA plugin for Eclipse, it greatly >>>>> improves my progress towards good coverage. I have found few bugs myself. >>>>> >>>>> Also, I have found a way to make Require thread-safe for use with shared >>>>> top level scopes. And by "found a way" I mean "found a more efficient way >>>>> than using a coarse synchronized block on it" :-) >>>>> >>>>> Attila. >>>>> >>>>> -- >>>>> home: http://www.szegedi.org >>>>> twitter: http://twitter.com/szegedi >>>>> weblog: http://constc.blogspot.com >>>>> >>>>>> >>>>>> So far code looks good, >>>>>> Regards, >>>>>> Jarek >>>>>> >>>>>> W dniu 31 stycznia 2010 20:15 użytkownik Attila Szegedi >>>>>> <[email protected]> napisał: >>>>>> Hi all, >>>>>> >>>>>> I just put out the second implementation patch at >>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=540724>, against current >>>>>> CVS HEAD. Check it out if you're interested. I have worked on this for I >>>>>> most of my free time I can have for coding in the last 12 days, and have >>>>>> arrived at a much better design than what was in the first attempt. I >>>>>> attached a comment to the Bugzilla issue describing the design decisions >>>>>> I took. It all feels round to me at the moment. I took care to document >>>>>> all classes and interfaces in great detail. I'll proceed with writing >>>>>> tests for it, but if you don't mind reviewing and trying bleeding-edge >>>>>> stuff, go for it. >>>>>> >>>>>> Attila. >>>>>> >>>>>> On 2010.01.19., at 23:45, Attila Szegedi wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I created a Bugzilla issue to track this work: >>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=540724> >>>>>>> I already attached a patch with the implementation to the above issue, >>>>>>> so feel free to check it out and provide feedback. I believe that the >>>>>>> JavaDocs I provided are sufficiently comprehensive so that no one >>>>>>> should have trouble understanding how's it used. >>>>>>> >>>>>>> Be warned it's quite untested - I'll proceed with writing some tests >>>>>>> tomorrow. >>>>>>> >>>>>>> Attila. >>>>>>> >>>>>>> -- >>>>>>> home: http://www.szegedi.org >>>>>>> twitter: http://twitter.com/szegedi >>>>>>> weblog: http://constc.blogspot.com >>>>>>> >>>>>>> On 2010.01.18., at 14:54, Jarosław Pałka wrote: >>>>>>> >>>>>>>> Count me in as well. >>>>>>>> >>>>>>>> Jarek >>>>>>>> >>>>>>>> 2010/1/18 Rapha <[email protected]> >>>>>>>> >>>>>>>>> I like the idea. Are you thinking of the 1.1 spec ( >>>>>>>>> http://wiki.commonjs.org/wiki/Modules/1.1 ) ? >>>>>>>>> >>>>>>>>> Raphael >>>>>>>>> >>>>>>>>> On Jan 17, 1:35 pm, Attila Szegedi <[email protected]> wrote: >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> I'm contemplating adding CommonJS Modules implementation to Rhino >>>>>>>>> codebase proper. I'd create org.mozilla.javascript.commonjs package >>>>>>>>> to hold >>>>>>>>> it, and we could have a method similar to initStandardObjects(), i.e. >>>>>>>>> initCommonJs() that'd initialize it - basically install a require() >>>>>>>>> function >>>>>>>>> with the expected semantics in the top-level scope. I want leave some >>>>>>>>> of its >>>>>>>>> aspects - most notably lookup of the module script - pluggable, >>>>>>>>> defined by >>>>>>>>> interfaces in the org.mozilla.javascript.commonjs package, so that >>>>>>>>> specific >>>>>>>>> embeddings of Rhino (JS app servers) can install their own module >>>>>>>>> resolver >>>>>>>>> logic. I'd provide a default implementation for the shell too. >>>>>>>>>> >>>>>>>>>> As I foresee that several Rhino-based JS products will adopt >>>>>>>>>> CommonJS in >>>>>>>>> the near future, it seems desirable to not have all of them reinvent >>>>>>>>> the >>>>>>>>> wheel (even though some already did, I'm guilty of coding my own >>>>>>>>> require() >>>>>>>>> too in the next-gen version of my company's server-side JS >>>>>>>>> enviroment...). >>>>>>>>>> >>>>>>>>>> Opinions? >>>>>>>>>> >>>>>>>>>> Attila. >> > > > > -- > Bloguje się tutaj http://primitive.jogger.pl > A czatuje tutaj [email protected] _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
