While working on moving BSF4Rexx to the 4.0 APIs and at the same time
keeping it backwardly compatible with Rexx scripts using it, I have been
running into problems for which the cause is not clear to me (and
debugging doesn't really help as the JVM takes over the debugging and I
cannot get into rexx.exe or BSF4Rexx.dll when exceptions occur, just a
log-file created by the JVM).
For backward compatibilty it is important to have the functions
RxFuncQuery(), RxFuncLoad() remaining operational (at least not causing
runtime errors) such that the following code can get executed:
if rxFuncQuery("BSF") = 1 then /* BSF() support not loaded yet ? */
do
call rxFuncAdd "BsfLoadFuncs", "BSF4Rexx", "BsfLoadFuncs"
call BsfLoadFuncs
call BsfLoadJava
end
There is a list of thirteen such functions.
Question 1: Is there a way to get to the RexxInterpreter instance
pointer or RexxThreadContext pointer (which would allow for finding its
RexxInterpreter instance) from within an external classic Rexx function?
If there was such a function, then it would be possible to let
"BsfLoadFuncs" be implemented in the classic style, but load from
the code there the library containing the new typed REXX_ROUTINE
functions. This would allow replacing the rest of the external
functions by new REXX_TYPEDROUTINEs, which I would prefer over the
classic style seeing how easy it is to use the new 4.0 APIs.
---
Currently, the classic external functions are in place and the behaviour
is the same as with the non-4.00 version, using RexxStart() to run the
programs.
Trying to take advantage of the new RexxCreateInterpreter() to later let
scripts be executed by that instance, the following phenomenon occurs:
Calling an external classic Rexx function
BsfQueryRegisteredFunctions() will return a stem with the registered
external functions. This external function uses RexxVariablePool()
to create the stem entries, but has no effect anymore. Removing an
unrelated "RexxCreateInterpreter()" call, "fixes" the behaviour,
i.e. the stem values are created in the caller's context using the
RexxVariablePool, as it did before.
Question 2: Is this an expected behaviour or a bug? If a bug, is this
information already sufficient to research the cause?
---
While implementing the RexxCreateInterpreter() and using the options
with either LOAD_REQUIRED_LIBRARY or REIGSTER_LIBRARY will cause a crash
(again, unfortunately without being able to get there with the VS
debugger).
The context of this crash is as follows: Java loads BSF4Rexx (so the DLL
is loaded already that contains the classic external functions), a Java
engine uses a new jni function which calls into the DLL where
RexxCreateInterpreter() is executed with either one of the above options
in place.
Question 3: Is this an expected behaviour or a bug?
Question 4: If in one RexxInterpreter instance a library is loaded, are
its routines visible to other RexxInstance instances as well ?
---
Question 5: Is it possible to call a REXX_TYPED_ROUTINE from another
REXX_TYPED_ROUTINE or from a REXX_TYPED_METHOD in native code? If so, how?
---rony
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
