[Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
Rick, Please include compiled dlls with this. I don't have the appropriate Java SDK to installed on my machine to compile this. O.K. here is the link to them: http://wi.wu-wien.ac.at/rgf/rexx/misc/bugs/. The CRASH-zip archives contain the respective versions of the DLL, compiled for debugging. ---rony -- 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
Re: [Oorexx-devel] Trivial (?) difference in stream() behavior
93 is really the more correct error, so I think that behavior should stay. Rick On Mon, May 4, 2009 at 11:06 PM, Mark Miesfeld miesf...@gmail.com wrote: 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 -- 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
Re: [Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
Rick McGuire wrote: I'm not seeing a crash with either version of this dll. That's strange! In the zip-archives I have enclosed also the hs_err_pid*.log files that the JVM creates. This is using: * Windows XP, SP 3 * Sun's Java 1.4 (but also occurred on later versions, will retest this with those versions later this evening) java version 1.4.2_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) * ooRexx from trunk, revision 4594, debug version, compiled with the MS compiler: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Those two archives cause the crash: * CrashRexxCreateInterpreter-CRASH1-20090505rgf.zip * CrashRexxCreateInterpreter-CRASH2-20090505rgf.zip This archive contains a running version (by not using any options): * CrashRexxCreateInterpreter-NO-CRASH-20090505rgf.zip ---rony -- 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
Re: [Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
None of which is of any value to me for debugging this problem. I'm not getting any crashes, and the output printed to the screen is exactly what I would expect from looking at the code. Rick On Tue, May 5, 2009 at 6:36 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Rick McGuire wrote: I'm not seeing a crash with either version of this dll. That's strange! In the zip-archives I have enclosed also the hs_err_pid*.log files that the JVM creates. This is using: Windows XP, SP 3 Sun's Java 1.4 (but also occurred on later versions, will retest this with those versions later this evening) java version 1.4.2_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) ooRexx from trunk, revision 4594, debug version, compiled with the MS compiler: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Those two archives cause the crash: CrashRexxCreateInterpreter-CRASH1-20090505rgf.zip CrashRexxCreateInterpreter-CRASH2-20090505rgf.zip This archive contains a running version (by not using any options): CrashRexxCreateInterpreter-NO-CRASH-20090505rgf.zip ---rony -- 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 -- 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
Re: [Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
Ok, I was able to reproduce this using the NODEBUG version and I think I have a fix. Rick On Tue, May 5, 2009 at 6:36 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Rick McGuire wrote: I'm not seeing a crash with either version of this dll. That's strange! In the zip-archives I have enclosed also the hs_err_pid*.log files that the JVM creates. This is using: Windows XP, SP 3 Sun's Java 1.4 (but also occurred on later versions, will retest this with those versions later this evening) java version 1.4.2_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) ooRexx from trunk, revision 4594, debug version, compiled with the MS compiler: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Those two archives cause the crash: CrashRexxCreateInterpreter-CRASH1-20090505rgf.zip CrashRexxCreateInterpreter-CRASH2-20090505rgf.zip This archive contains a running version (by not using any options): CrashRexxCreateInterpreter-NO-CRASH-20090505rgf.zip ---rony -- 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 -- 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] DLL breakpoints
http://msdn.microsoft.com/en-us/library/wztycb7f.aspx -- 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
Re: [Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
Rick McGuire wrote: Ok, I was able to reproduce this using the NODEBUG version and I think I have a fix. Just got a few minutes in between and updated to rev 4598, and yes, the problem is fixed, thank you very much! ---rony P.S.: Does it make any sense to file this as a bug with Sourceforge for documentation purposes? (Although there is no bug anymore, hence I would not see too much use in opening one.) -- 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
Re: [Oorexx-devel] Compiled dlls uploaded (Re: Bug: Crash RexxCreateInstance() ...
No, I don't see any need for opening this as a bug. We don't like the beta bug fixes in the changes file anyway.. Rick On Tue, May 5, 2009 at 8:32 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Rick McGuire wrote: Ok, I was able to reproduce this using the NODEBUG version and I think I have a fix. Just got a few minutes in between and updated to rev 4598, and yes, the problem is fixed, thank you very much! ---rony P.S.: Does it make any sense to file this as a bug with Sourceforge for documentation purposes? (Although there is no bug anymore, hence I would not see too much use in opening one.) -- 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 -- 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] Question ad (automatic?) loading of external routines from a DLL (Re: 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: ... cut ... 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. Just turned to the rxmath package (learned that even the loader function could be defined to be of new type) and saw no explicit library loading, hence two little questions: * does using RxFuncAdd(...) cause ooRexx to automatically load the given DLL at that time or when the added external function gets executed the first time? * Does ooRexx load all external routines defined in the RexxPackageEntry that is used with the OOREXX_GET_PACKAGE(pkgName) automatically at the time of loading the DLL? ---rony -- 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
Re: [Oorexx-devel] Question ad (automatic?) loading of external routines from a DLL (Re: A few questions in the context of RexxCreateInterpreter, LIbraries and co-existence with the classic functio
On Tue, May 5, 2009 at 12:19 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: ... cut ... 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. Just turned to the rxmath package (learned that even the loader function could be defined to be of new type) and saw no explicit library loading, hence two little questions: There's nothing special about a loader function...it's just one other function that follows all of the conventions of any other native call. does using RxFuncAdd(...) cause ooRexx to automatically load the given DLL at that time or when the added external function gets executed the first time? Yes, the magic is performed in RxFuncAdd(). When asked to load the library, it first checks to see if it has a loader entry point created by OOREXX_GET_PACKAGE(), and if it does, then rather than register the package, it just processes it as if it were referenced on ::REQURES and if the package contains the function you're doing an RxFuncAdd() on, it returns true. So all that was necessary was to make the loader function into a NOP, since that was generally the very next step performed after the RxFuncAdd(). Doing this allows libraries to be converted into the new format without requiring any changes to the programs that use the libraries. Not one user of rxmath has noticed the change yet. Same with rxsock and and rexxutil. Does ooRexx load all external routines defined in the RexxPackageEntry that is used with the OOREXX_GET_PACKAGE(pkgName) automatically at the time of loading the DLL? yes. ---rony -- 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 -- 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] Problem with an entry of RexxErrorCodes.h
The following code does not compile: context-RaiseException1(Error_Incorrect_call_user_defined, context-String(msg)); ... error mesage: BSF4Rexx.cc(2645) : error C2065: 'Error_Incorrect_call_user_defined' : undeclared identifier The identifier 'Error_Incorrect_call_user_defined' was located in and copied directly from interpreter/messages/RexxErrorCodes.h. This statement does compile and work: context-RaiseException1(40900, context-String(msg)); What may I be doing wrongly? --- BTW: this is a *great* way to tell the user more about errors, allowing them to locate and fix their wrong code much easier than was possible before (with the old APIs)! ---rony -- 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] Unapplied patch
Mark, I was looking through the open bug list, and discovered we'd never done anything with this patch: http://sourceforge.net/tracker/?func=detailaid=2457111group_id=119701atid=684730 This looks like a good thing to apply, but unfortunately, my VMWare installation decided to start misbehaving today, and I don't have access to a Linux system to check this out on. Any chance you could take a look at this? Rick -- 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
Re: [Oorexx-devel] Unapplied patch
On Tue, May 5, 2009 at 2:43 PM, Rick McGuire object.r...@gmail.com wrote: I was looking through the open bug list, and discovered we'd never done anything with this patch: http://sourceforge.net/tracker/?func=detailaid=2457111group_id=119701atid=684730 This looks like a good thing to apply, Well, this one was on my list of minor things to resolve. When Jean-Louis submitted the similar patch for Windows, I knew it was good for Windows and applied it. (Although I think there was one minor improvement I made.) But, on the Unix side, I was not quite sure if it was a good patch. So, I was kind of hanging back to see if you or David said anything. I'll apply it and test it. -- 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
