|anonym | Anmelden | Neues Konto anmelden||2020-07-15 07:40 UTC|
|Startseite | Übersicht | Probleme anzeigen | Änderungsprotokoll | Roadmap | Dokumentation | Konto|
|Einfache Problemansicht anzeigen|
|0000015||[OCamlScripting] general||schwerer Fehler||immer||2008-07-05 08:48||2008-11-02 19:06|
|Zusammenfassung||0000015: The OCaml-Java JSR-223 engine won't work with external ScriptContexts|
The OCamlScriptEngine and friends depend on the engine-specific ScriptContext OCamlContext. That is not a proper implementation because the implementation of the ScriptContext is up to the application/environment that is loading the ScriptEngine.
The consequence is that this JSR-223 engine won't work in any but the simplest environments (those that simply use the default ScriptEngine constructor thus allowing OCamlScriptEngine to use it's special OCamlContext).
That breaks my application (IFCX Wings at http://www.ifcx.org) [^] and so I've come with a quicky patch to get OCaml-Java working for it. I didn't worry about performance (there is some obvious extra overhead in binding access in particular), but I'm submitting this patch (diffed to the 1.0 source I downloaded May 26th) so you can see what sort of change is needed.
My current version is in IFCX SVN (along with other JSR-223 engines):
I'm working on installing darcs (a bit involved on PPC Leopard it seems) so I can track these changes better.
There is a Wings example with OCaml working also in SVN:
|Tags||Keine Tags zugeordnet.|
|Angehängte Dateien||diff-ocamlscripting-1.0-to-ifcx-r101 [^] (21,315 bytes) 2008-07-05 08:48|
Well, I am not a JSR-223 expert, and OCamlScripting is probably not the best designed part of OCaml-Java.
However, I am afraid I do not understand the practical limitation you point out.
It appears to me that a script engine may decide to provide its own "context"; what do you mean by
"the implementation of the ScriptContext is up to the application/environment that is loading the ScriptEngine" ?
I was under the impression (maybe wrong) that the script engine should only provide a "context" suiting its needs
as well as the ones from any user (this may be were the current implementation of OCamlScripting exhibits some
Could you also elaborate in which way this breaks your application, by precisely stating what you are trying
to achieve using OCamlScripting, and why the current implementation cannot be used to fulfill this task ?
bearbeitet am: 2008-07-06 20:04
The JSR-223 API is an "embedding" scheme in which the scripting engine operates within the context of some other application. The way I understand it ScriptContext is an interface to an object that the hosting application uses to maintain it's state. The ScriptEngines access it generically through that interface.
For some references:
The interface whose implementing classes are used to connect Script Engines with objects, such as scoped Bindings, in hosting applications.
From the JSR-223 Specification (p40):
The ScriptContext is meant to represent a view of the hosting application.
To further reinforce this idea there is also a Web Scripting Framework specified in JSR-223 which has javax.script.http.HttpScriptContext:
HttpScriptContext, a subinterface of ScriptContext, providing additional methods related to Web functionality
For very simple script engine uses there is a default constructor in which the engine creates it's own ScriptContext (for which there is SimpleScriptContext), but for environments with more complex needs the engine must support ScriptEngine.setContext(ScriptContext) and that is where the OCaml-Java JSR-223 implementation fails because it tries to down-cast to OCamlScriptContext.
IFCX Wings is just such a hosting application and supports many JSR-223 scripting languages but it can't function with the OCaml-Java JSR-223 implementation the way it was, and so that is why I fixed it. I'm interested in promoting inter-language tools using JSR-223 (I applaud your support for it as few language implementors do so far) and OCaml in particular because I'd like to be able to run Harmony on the JVM.
Thanks to the references provided by Jim White, it is now quite clear that my previous understanding
of the ScriptContext interface was erroneous. This problem will be fixed in the next (1.1) version of
OCaml-Java that should be available at the end of the summer (2008). One may notice that it is highly
probable that this version of OCaml-Java will see the merge of OCamlScripting into the Cadmium base.
The main reason of having two separate subprojects was that OCamlScripting was relying on Java
1.6-specific elements while the base project was only Java 1.5 compliant (with no dependencies).
The next OCaml-Java version will support Java 1.6, and likely drop support for Java 1.5.
|2008-07-05 08:48||jimwhite||Neues Problem|
|2008-07-05 08:48||jimwhite||Datei hinzugefügt:: diff-ocamlscripting-1.0-to-ifcx-r101|
|2008-07-06 12:10||xclerc||Problemnotiz hinzugefügt: 0000011|
|2008-07-06 12:10||xclerc||Bearbeitung durch||=> xclerc|
|2008-07-06 12:10||xclerc||Status||neu => anerkannt|
|2008-07-06 20:03||jimwhite||Problemnotiz hinzugefügt: 0000012|
|2008-07-06 20:04||jimwhite||Problemnotiz bearbeitet: 0000012|
|2008-07-13 09:20||xclerc||Problemnotiz hinzugefügt: 0000013|
|2008-11-02 19:06||xclerc||Status||anerkannt => erledigt|
|2008-11-02 19:06||xclerc||Behoben in Version||=> Cadmium 1.1 (after merge)|
|2008-11-02 19:06||xclerc||Lösung||offen => erledigt|
|Mantis 1.1.7[^] Copyright © 2000 - 2008 Mantis Group|