Christopher Oliver wrote:
export CVSROOT=:pserver:[EMAIL PROTECTED]:/var/cvs/rhino cvs co rhino1_5Rpre
Here's what I get at that point:
cvs server: cannot find module `rhino1_5Rpre' - ignored cvs [checkout aborted]: cannot expand modules
Sorry, try:
cvs co rhino1_5R4pre
Permit me to inquire about this version of rhino? I'm gathering that this is an incompatible fork of the Mozilla codebase... one that doesn't even rename the Java package name.
Is this a good idea?
- Sam Ruby
No, it's not a good idea but unfortunately it is unavoidable at this point. I've attached an email that summarizes the current situation. But what do you mean by "rename the Java package name"? Why would _that_ be a good idea?
Regards,
Chris
--- Begin Message --- Hi Chris,
On Tuesday, Jan 21, 2003, at 10:27 US/Pacific, Christopher Oliver wrote:
Thanks for that information, Igor.
Ovidiu, as of right now my thinking is that it is better to retain the forked version of Rhino used by Cocoon for the time being. In my opinion, in order to properly integrate another interpreter with the Rhino core, the Rhino core will require a major refactoring to eliminate the use of implementation inheritance The reason that it is virtually impossible to merge my changes now is due to the fact that implementation inheritance doesn't provide a stable contract for derived classes. Igor has changed virtually every base class my code depended on (as he should be allowed to) in incompatible ways. This will continue to happen as he fixes bugs, etc.
In addition, if you look through the list of fixes, none of them seem particularly significant, so there is little gain in value for Cocoon users by doing this merge.
Well, so there you go. I'm open to suggestions on what action to take next.
For the Cocoon project I think we can live for the time being with the current version of the modified Rhino engine.
I'm not sure what is the best strategy moving forward. Unfortunately I'm not too familiar with Rhino's internals, so I cannot speak intelligently on this subject. Let me know if you think I can help you with anything though.
Best regards, Ovidiu
Igor Bukanov wrote:
Christopher Oliver wrote:
Hi Igor,
I intended to attempt to merge the rhino snapshot I modified last year to support the Apache Cocoon project with the current Rhino cvs, but I now notice that you have made very extensive changes to the base interpreter and debugger. Can you offer any suggestions on how to merge my code with what you've done? There seem to be few comments explaining the nature of your changes or what problems they are intended to solve.
Few reasons for changes:
1. Fixing http://bugzilla.mozilla.org/show_bug.cgi?id=61579 http://bugzilla.mozilla.org/show_bug.cgi?id=83051 http://bugzilla.mozilla.org/show_bug.cgi?id=114583 http://bugzilla.mozilla.org/show_bug.cgi?id=154693 http://bugzilla.mozilla.org/show_bug.cgi?id=159334 http://bugzilla.mozilla.org/show_bug.cgi?id=173906 http://bugzilla.mozilla.org/show_bug.cgi?id=181834 http://bugzilla.mozilla.org/show_bug.cgi?id=184107
Note although 173906 is related to the optimizer, the final fix touched the interpreter as well to ensure that the interpreter and compiler calls the same code for function initialization.
2. Making possible to debug functions that where defined prior a debugger load.
3. Extending limits on code size. Part of it is related to fixing 159334, and the other items are related to number of elements in array literals [] and making sure that interpreter does not create different slots for the same strings.
4. Inlining of calls to interpreted functions to avoid creation of the argument array and wrapping of double values into Double objects.
I believe it would be easy to make custom interpreters now as is would require to extend only Interpreter/InterpreterData as InterpretedFunction/InterpretedScripts methods currently just calls static methods in Interpreter with passing InterpreterData to them. It would be trivial to change them to call non-final methods in InterpreterData.
Regards, Igor
The snapshot I modified is here ftp://ftp.primaryinterface.com/pub/rhino/ rhino1_5R4pre_sharedlocals.zip.
Regards,
Chris
-------- Original Message --------
Subject: Re: continuations in Rhino
Date: Mon, 20 Jan 2003 19:52:39 -0800
From: Christopher Oliver <[EMAIL PROTECTED]>
To: Norris Boyd <[EMAIL PROTECTED]>
CC: Marcus Crafter <[EMAIL PROTECTED]>, Ovidiu Predescu <[EMAIL PROTECTED]>, Stefano Mazzocchi <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Hi Norris,
Norris Boyd wrote:
Adding the continuations code to Rhino certainly seems desirable. There was a good deal of work and discussion done a while ago and I never was aware of a final conclusion, although it sounds like one was reached.
Do you have a version that works for you that you'd like to submit? Is the interpreter separate from the current Rhino one? What other changes are needed to the existing Rhino code? Are the changes derived from a Rhino release or from the CVS source?
The interpreter with continuations is separate from the current Rhino interpreter, and is parallel to the optimizer package. The existing rhino code simply needs to be changed to select the proper interpreter based on some user-settable option (currently that is implemented by selecting an optimization level - but you and Igor suggested there might be a better way). In addition, I made some changes to Interpreter.java, InterpretedScript.java, InterpretedFunction.java, and Parser.java to allow the derived interpreter to override certain behavior. Meanwhile, Igor has made a lot of changes to the interpreter and debugger since I wrote the continuations code. In addition, Marcus has fixed some problems with the debugger. I can merge these changes with the latest cvs and give you a snapshot or diff to consider committing if that is OK with >>> you.
Regards,
Chris
--- End Message ---
