[Oorexx-devel] A few questions in the context of RexxCreateInterpreter, LIbraries and co-existence with the classic functions ...
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
Re: [Oorexx-devel] A few questions in the context of RexxCreateInterpreter, LIbraries and co-existence with the classic functions ...
On Mon, May 4, 2009 at 11:43 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: 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? No there is not. However, if you just add BsfLoadFuncs() to the list of function defined in the BSF4Rexx() package and make it a NOP when called, then things will appear to behave the same way. This is the same approach that's been taken by packages in the interpreter itself that have been converted to the new package format. For example, see what the rxsock library is doing in the interpreter build. 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. If you implement the suggestion I made above, this will work just fine. The rxmath package is a good example. It still has a registration routine, but all the functions are defined using the typed format. There is no need to register special stubs. --- 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. There can only be one interpreter instance in control of a thread at a given time. If you call RexxCreateInterpreter in the context of one of those callouts, then all API calls will be handled by the thread context you just created that pushed all of the other stuff down. Question 2: Is this an expected behaviour or a bug? If a bug, is this information already sufficient to research the cause? This is the expected behavior. You're creating a new context associated with that thread. It is in control of all call-backs on that thread until the instance is terminated. To get the non-nested behavior you want, you'll probably need to spin off another thread to create the interpreter instance and keep it alive. Then, to access this instance in a nested fashion, you'll need to use AttachThread()/DetachThread() in pairs. --- 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? A crash is never the expected behavior. Open a bug, but you'll probably need to give me enough to recreate the problem. Question 4: If in one RexxInterpreter instance a library is loaded, are its routines visible to other RexxInstance instances as well ? Yes, the library packages are global to the process. --- 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? No, the entry points are only usable through using the Rexx runtime. If you wish to share code, then make the package routines be just stubs that forward to the appropriate routines. The stream library code in the
Re: [Oorexx-devel] A few questions in the context of RexxCreateInterpreter, LIbraries and co-existence with the classic functions ...
Rick McGuire wrote: On Mon, May 4, 2009 at 11:43 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: 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? No there is not. However, if you just add BsfLoadFuncs() to the list of function defined in the BSF4Rexx() package and make it a NOP when called, then things will appear to behave the same way. This is the same approach that's been taken by packages in the interpreter itself that have been converted to the new package format. For example, see what the rxsock library is doing in the interpreter build. 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. If you implement the suggestion I made above, this will work just fine. The rxmath package is a good example. It still has a registration routine, but all the functions are defined using the typed format. There is no need to register special stubs. Great, thanks for this pointer, will look it up! --- 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. There can only be one interpreter instance in control of a thread at a given time. If you call RexxCreateInterpreter in the context of one of those callouts, then all API calls will be handled by the thread context you just created that pushed all of the other stuff down. This problem should go away when using the new typed routine. Question: How can one create/set a variable in the context of the caller? AFAIK one can only retrieve the existing variables in the caller's context, but not create/set a new one (in this case I would need to create a stem object and set it to the callers context variable pool using the supplied name for the stem). Question 2: Is this an expected behaviour or a bug? If a bug, is this information already sufficient to research the cause? This is the expected behavior. You're creating a new context associated with that thread. It is in control of all call-backs on that thread until the instance is terminated. To get the non-nested behavior you want, you'll probably need to spin off another thread to create the interpreter instance and keep it alive. Then, to access this instance in a nested fashion, you'll need to use AttachThread()/DetachThread() in pairs. Yes, this would be the planned exploitation. Knowing the difference in the mechanics this won't be a problem anymore, thanks again for the explanation! --- 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?
Re: [Oorexx-devel] A few questions in the context of RexxCreateInterpreter, LIbraries and co-existence with the classic functions ...
On Mon, May 4, 2009 at 12:12 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Rick McGuire wrote: On Mon, May 4, 2009 at 11:43 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: 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? No there is not. However, if you just add BsfLoadFuncs() to the list of function defined in the BSF4Rexx() package and make it a NOP when called, then things will appear to behave the same way. This is the same approach that's been taken by packages in the interpreter itself that have been converted to the new package format. For example, see what the rxsock library is doing in the interpreter build. 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. If you implement the suggestion I made above, this will work just fine. The rxmath package is a good example. It still has a registration routine, but all the functions are defined using the typed format. There is no need to register special stubs. Great, thanks for this pointer, will look it up! --- 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. There can only be one interpreter instance in control of a thread at a given time. If you call RexxCreateInterpreter in the context of one of those callouts, then all API calls will be handled by the thread context you just created that pushed all of the other stuff down. This problem should go away when using the new typed routine. Question: How can one create/set a variable in the context of the caller? If called as a routine or an exit, you can use the SetContextVariable() API to set the variable. In other contexts, this is not permitted. AFAIK one can only retrieve the existing variables in the caller's context, but not create/set a new one (in this case I would need to create a stem object and set it to the callers context variable pool using the supplied name for the stem). There are Get and Set APIs for variables. These only access the top-level variables, so yes, if you wish to set a stem variable to something, you first create the stem object, populate it, then set the stem variable to the corresponding stem object. Question 2: Is this an expected behaviour or a bug? If a bug, is this information already sufficient to research the cause? This is the expected behavior. You're creating a new context associated with that thread. It is in control of all call-backs on that thread until the instance is terminated. To get the non-nested behavior you want, you'll probably need to spin off another thread to create the interpreter instance and keep it alive. Then, to access this instance in a nested fashion, you'll need to use AttachThread()/DetachThread() in pairs. Yes, this would be the planned exploitation. Knowing the difference in the mechanics this won't be a problem anymore, thanks again for the explanation! --- While implementing the RexxCreateInterpreter() and using the options with either LOAD_REQUIRED_LIBRARY or REIGSTER_LIBRARY
[Oorexx-devel] How to add a new bug at Sourceforge ?
Hi there, probably a little bit overworked, combined with a new layout: how, for God's sake, does one add a new bug at https://sourceforge.net/tracker/?atid=684730group_id=119701func=browse? I would like to submit the RexxCreateInterpreter() crash before going to bed, but am stumped at not being able to find the Add new Bug/Artefact link/button. Any help highly appreciated! ---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
[Oorexx-devel] Bug: Crash RexxCreateInstance() ...
Short of being able to file a new bug in the SF tracker, I uploaded the zip-archive http://wi.wu-wien.ac.at/rgf/rexx/misc/bugs/CrashRexxCreateInterpreter%2d20090504rgf%2ezip with a nutshell version and the readme.txt http://wi.wu-wien.ac.at/rgf/rexx/misc/bugs/readme.txt describing how to re-create the bug. If tomorrow I am able to open a new bug at SF (assuming that they are reorganizing), I will do so and upload the archive as well. ---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
Re: [Oorexx-devel] How to add a new bug at Sourceforge ?
Sourceforge appears to have rolled out the new look and feel todayand it appears to be having some problems! I don't see any way to open new items either. Rick On Mon, May 4, 2009 at 5:27 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi there, probably a little bit overworked, combined with a new layout: how, for God's sake, does one add a new bug at https://sourceforge.net/tracker/?atid=684730group_id=119701func=browse? I would like to submit the RexxCreateInterpreter() crash before going to bed, but am stumped at not being able to find the Add new Bug/Artefact link/button. Any help highly appreciated! ---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 -- 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
Re: [Oorexx-devel] Bug: Crash RexxCreateInstance() ...
Rony, Please include compiled dlls with this. I don't have the appropriate Java SDK to installed on my machine to compile this. I need at least the CRASH1 version. The CRASH2 problem is most likely the caused by the bad OOREXX_GET_PACKAGE(test); // package loader stub which should be OOREXX_GET_PACKAGE(test_package_entry); Rick On Mon, May 4, 2009 at 5:40 PM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Short of being able to file a new bug in the SF tracker, I uploaded the zip-archive http://wi.wu-wien.ac.at/rgf/rexx/misc/bugs/CrashRexxCreateInterpreter%2d20090504rgf%2ezip with a nutshell version and the readme.txt http://wi.wu-wien.ac.at/rgf/rexx/misc/bugs/readme.txt describing how to re-create the bug. If tomorrow I am able to open a new bug at SF (assuming that they are reorganizing), I will do so and upload the archive as well. ---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 -- 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
Re: [Oorexx-devel] Installing from source
On Mon, May 4, 2009 at 5:42 PM, Mark Miesfeld miesf...@gmail.com wrote: Okay, I got the correct source tar file and tested building from it. (Which works with just ./configure make) Alright, now I have it uploaded to SourceForge. The file name is the same, but if you look at the date you will see it is a recent date. -- Mark Miesfeld -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Trivial (?) difference in stream() behavior
Rick, This test: self~expectSyntax(40.0) ret = stream(fileName, 'C', open read append) self~assertSame(READY:, ret) passes under 3.2.0 but fails in 4.0.0 because 4.0.0 raises 93.0 instead of 40.0 for the error. I'm not sure if that needs to be fixed or not. Right now I have the test in the test suite failing, but it is easy enough to change it to expect 93.0. -- Mark Miesfeld -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
