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. > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
