Re: [Oorexx-devel] Ad unloader
Although rev. 4734 indeed fixes the unloader problem with the test case, unfortunately, I still am experiencing it in the "real thing": the unloader runs, if the Rexx script is invoked via rexx.exe, but does not run if invoked via Java. As having gone through the code-path a couple of times, I will let a day or two go by, before looking at this again (that sometimes helps me to get enough distance and change assumptions to go through new paths). Just wanted to communicate this, in case there might be also things I am doing at the native side that would block the unloader to run. (Currently, I am able to verify, that all RexxInterpreter instances that are started via the native layer are indeed terminated in that layer, and to the best of my knowledge no Rexx threads are possibly running, as the test scripts do not employ any multithreading at all.). ---rony Rony G. Flatscher wrote: > Rick McGuire wrote: >> The unloader gets called when all interpreter instances have been >> terminated and the global Rexx environment is going to be shut down. >> Any active instance, regardless of how it is created, is enough to >> keep these active. If the process terminates while there are still >> active instances, then these are not going to get called. >> > O.K., I just *tried* to upload a zip-archive that exhibits the problem. > > Unfortunately, I got thrown out twice: > > * the first time, because the upload file limit must not exceed 256KB > * then, after having created chunks of 256KB and a script to > recreate the original file I was moved to an error page, because > I forgot to log-in. This caused the loss of my description, such > that I just will briefly wirte up another one. > > Can't Sourceforge be configured to check the login-state *before* one > opens an artefact item to help loosing entered data? (I really wonder, > whether people who experienced that usability problem with Sourceforge > whether they gave in in reporting problems.) > > In this particular case the file-size is large, because I would like > to supply the compiled versions and all files created in the > compilation step to ease debugging for you, because then the example > can be run "right out of the box". This size-limit (seems to be new, > maybe introduced the last time Sourceforge changed their appearance?) > for these kinds of archives is definitely too small. > > --- > > O.K. added a "readme.txt" to the archive that briefly describes the > problem and how to run the "showcase". > > Will take a while before all chunks are uploaded. > > ---rony > >> On Wed, May 27, 2009 at 8:38 AM, Rony G. Flatscher >> wrote: >> >>> Under what conditions would a defined unloader function be run by the >>> runtime? What could be reasons that it does not get invoked? >>> >>> Reason: when running a test-program via rexx.exe, the unloader runs at >>> the end of the program. When running via Java, the unloader does not run >>> (I seem to remember that a couple of weeks ago it did run nevertheless), >>> even though all Rexx interpreter instances should be terminated at that >>> point. >>> >>> ---rony >>> -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad unloader
Rick McGuire wrote: > The unloader gets called when all interpreter instances have been > terminated and the global Rexx environment is going to be shut down. > Any active instance, regardless of how it is created, is enough to > keep these active. If the process terminates while there are still > active instances, then these are not going to get called. > O.K., I just *tried* to upload a zip-archive that exhibits the problem. Unfortunately, I got thrown out twice: * the first time, because the upload file limit must not exceed 256KB * then, after having created chunks of 256KB and a script to recreate the original file I was moved to an error page, because I forgot to log-in. This caused the loss of my description, such that I just will briefly wirte up another one. Can't Sourceforge be configured to check the login-state *before* one opens an artefact item to help loosing entered data? (I really wonder, whether people who experienced that usability problem with Sourceforge whether they gave in in reporting problems.) In this particular case the file-size is large, because I would like to supply the compiled versions and all files created in the compilation step to ease debugging for you, because then the example can be run "right out of the box". This size-limit (seems to be new, maybe introduced the last time Sourceforge changed their appearance?) for these kinds of archives is definitely too small. --- O.K. added a "readme.txt" to the archive that briefly describes the problem and how to run the "showcase". Will take a while before all chunks are uploaded. ---rony > On Wed, May 27, 2009 at 8:38 AM, Rony G. Flatscher > wrote: > >> Under what conditions would a defined unloader function be run by the >> runtime? What could be reasons that it does not get invoked? >> >> Reason: when running a test-program via rexx.exe, the unloader runs at >> the end of the program. When running via Java, the unloader does not run >> (I seem to remember that a couple of weeks ago it did run nevertheless), >> even though all Rexx interpreter instances should be terminated at that >> point. >> >> ---rony >> >> -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad unloader
The unloader gets called when all interpreter instances have been terminated and the global Rexx environment is going to be shut down. Any active instance, regardless of how it is created, is enough to keep these active. If the process terminates while there are still active instances, then these are not going to get called. Rick On Wed, May 27, 2009 at 8:38 AM, Rony G. Flatscher wrote: > Under what conditions would a defined unloader function be run by the > runtime? What could be reasons that it does not get invoked? > > Reason: when running a test-program via rexx.exe, the unloader runs at > the end of the program. When running via Java, the unloader does not run > (I seem to remember that a couple of weeks ago it did run nevertheless), > even though all Rexx interpreter instances should be terminated at that > point. > > ---rony > > > > > -- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
