Sylvain, On Wed, 10 Apr 2002 10:14:24 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote: > > <snip/> > > >Please do a cvs update and check out the calculator sample again. I've > >reverted back to using callCC in JavaScript instead of a new API, a > >Continuation object, provided by Christopher Oliver in his modified > >Rhino engine. I need to test the later a bit more before using it. > > > > Ovidiu, can you tell us the status of the work of Christopher Oliver, as > the continutation-enabled Rhino becomes a critical part of the flow engine : > - are sources available ? > - under which licence (same MPL as Rhino) > - is it/will it be integrated into the main Rhino code base ? Christopher's work is available in source form from: ftp://ftp.primaryinterface.com/pub/rhino/rhino1_5R4pre-callCC.zip The package also contains a pre-built, ready to use, jar file. The license is still MPL, and I don't think is possible to change it. At this point, the primary maintainers of Rhino seem to be concerned with two things: - the performance implications of the continuations code has on the interpreted engine. - the fact that continuations are available in interpreted mode only. Rhino has two ways of running JavaScript scripts. The first one is translating the script in a structure of internal objects, which are then "executed". The second approach, a lot faster that the first one, translates the JavaScript scripts in internal Java classes, which are compiled to bytecodes on-the-fly and executed as normal Java code. Adding support for continuations in the compiler mode is not possible, due to the impossibility to manipulate the Java stack frame. I believe at this point, Norris Boyd and other Rhino maintainers are waiting for the continuations code to stabilize, and have all the bugs removed. In the past month Christopher came up with new versions every other day almost ;-). Some of them had major bugs, and unless somebody like us tests the code extensively it may be difficult to remove them. One of the implications for us is that once Schecoon is merged onto the main trunk, we'll have to use this engine instead of the 1.5R3 version we currently use. I certainly hope Christopher's work will get into the main trunk, so that we're not stuck with an unsupported version. Another alternative, which I still need to explore, is to continue the development on the language I proposed a while ago. This will give us much more control over what features we need, and we can possibly have more optimizations implemented. Rhino is much slower when it comes to continuations than SISC, the Scheme interpreter I was initially used in Schecoon. And there are certain optimizations which can be done to minimize the size of the captured continuations, which are simply not possible in Rhino without major changes. Controlling what gets captured in a continuation at the language level would also help developers a lot. For example it would be nice to have language constructs that tell that a variable's value should not be captured in a continuation, and how its value could be restored after the continuation is resurrected. At this point this is just some food for thought, I need to look more closely into these issues. Greetings, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
