[Oorexx-devel] Another possible problem and maybe a possible solution ... (Re: Problem with prologue of ::requires file not executing
Hi there, Rick McGuire wrote: You have misunderstood what this thread was about. Mike's programs were unaffected, oodialog has already been reworked to remove an old hacky way to get around the old behavior. This really only becomes an issue for programs that stuffed things into .local to get around how ::requires used to work AND those programs are relying on the information in .local persisting between RexxStart() invocations. In addition to the .local-problem there is one more possible problem: if the external function library needs to be configured from the Rexx program for each RexxStart(), this is in the current drop not possible! E.g. in the case of BSF4Rexx the external function library gets configured by the initialization/prologue code in BSF.CLS. If the initialization/prologue code is not executed, then the Rexx programs cannot function correctly anymore! (The same is true for UNO.CLS which adds the support to script the OpenOffice.org applications, sitting on top of BSF.CLS.) --- It is impossible to say how many applications are deployed in companies which invoke Rexx via RexxStart() because they use Rexx as a scripting language for their applications. If they dispatch ooRexx programs that deploy the requires-directive, then they may depend on the current behaviour of GA-ooRexx (the behaviour has been there since the IBM Object REXX days), in that after following all directives the initialization/prologue code gets run, which indeed does also carry out all sort of initializations. In such use-cases it may not be possible to replace the requires-directive with a call being the very first statement in the initialization/prologue code, because it may be the case that the directives refer to public classes and public routines in the required programs ! Now, the current (pre 4.0) behaviour of files/programs/packages being required via the requires-directive has been a constant cause of confusion (each requires causes in the scope of that program that required public classes are scoped class object instances that are not equal to the class object instances of other programs having required the same package!), hence coming up with a solution that truly allows a required program/package to be required globally, i.e. any other requires would refer to the already globally (cached) required file/package. Skimming over the current source code of ooRexx 4.0 one can tell that a lot of effort has been invested in this desired (and very appreciated!) behaviour available only in ooRexx 4.0. --- Thinking about this particular problem from a distance of a few days, weeks, it seems that the real problem currently is that the new global behaviour is currently set out to be the default behaviour for ooRexx 4.0! This therefore may jeopardize all ooRexx programs, that have exploited the classic requires-behaviour, needing the initialization/prologue part to be run for each RexxStart(). Hence, how about the following idea? * Let the requires-directive behave as in all previous versions of ooRexx (semantics of context-CallProgram()?), e.g. ::requires someRexxPackage.rex /* executes as in all previous versions of ooRexx */ * allow /a new keyword on the requires directive/ that tells ooRexx 4.0 to use the new behaviour (semantics of PackageManager::loadRequires(...)), e.g. if the new keyword is named global (maybe there are more meaningful keywords like cache, loadonce, singleton, etc.) ::requires someRexxPackage.rex *global */* global keyword causes the package to be globally cached */ This would allow all pre-ooRexx 4.0 programs with requires-directives to execute as in the past, hence backward compatibility in this regard is ensured. It also would allow to start to use the new (preferable) behaviour if the ooRexx programmer wishes to do so (and I think, if ooRexx programmers realize how great the new behaviour is, that they will eventually adopt their programs to do so; there may be - probably rare - cases where this would not be possible, but then that would not be a problem either as the old behaviour is available as well). In addition, having seen the new C++ APIs new libraries and packages can be devised that would easily be able to exploit globally cached packages. HTH, ---rony -- ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Another possible problem and maybe a possible solution ... (Re: Problem with prologue of ::requires file not executing
Sorry, I am adamantly opposed to any effort to preserve that old behavior. It was the cause of no end of problems, including most of the hacks you're now citing as instances of the problems. At this point in the project, what you're proposing will be an incredibly disruptive change to the code base that I'm not willing to make. If you are willing to put in the time and effort to come up with a patch that demonstrates this change, we might consider it. It, however, needs to be done quickly, as I'm also not willing to delay the release of 4.0 to wait for it. Rick On Sun, Apr 5, 2009 at 8:55 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi there, Rick McGuire wrote: You have misunderstood what this thread was about. Mike's programs were unaffected, oodialog has already been reworked to remove an old hacky way to get around the old behavior. This really only becomes an issue for programs that stuffed things into .local to get around how ::requires used to work AND those programs are relying on the information in .local persisting between RexxStart() invocations. In addition to the .local-problem there is one more possible problem: if the external function library needs to be configured from the Rexx program for each RexxStart(), this is in the current drop not possible! E.g. in the case of BSF4Rexx the external function library gets configured by the initialization/prologue code in BSF.CLS. If the initialization/prologue code is not executed, then the Rexx programs cannot function correctly anymore! (The same is true for UNO.CLS which adds the support to script the OpenOffice.org applications, sitting on top of BSF.CLS.) --- It is impossible to say how many applications are deployed in companies which invoke Rexx via RexxStart() because they use Rexx as a scripting language for their applications. If they dispatch ooRexx programs that deploy the requires-directive, then they may depend on the current behaviour of GA-ooRexx (the behaviour has been there since the IBM Object REXX days), in that after following all directives the initialization/prologue code gets run, which indeed does also carry out all sort of initializations. In such use-cases it may not be possible to replace the requires-directive with a call being the very first statement in the initialization/prologue code, because it may be the case that the directives refer to public classes and public routines in the required programs ! Now, the current (pre 4.0) behaviour of files/programs/packages being required via the requires-directive has been a constant cause of confusion (each requires causes in the scope of that program that required public classes are scoped class object instances that are not equal to the class object instances of other programs having required the same package!), hence coming up with a solution that truly allows a required program/package to be required globally, i.e. any other requires would refer to the already globally (cached) required file/package. Skimming over the current source code of ooRexx 4.0 one can tell that a lot of effort has been invested in this desired (and very appreciated!) behaviour available only in ooRexx 4.0. --- Thinking about this particular problem from a distance of a few days, weeks, it seems that the real problem currently is that the new global behaviour is currently set out to be the default behaviour for ooRexx 4.0! This therefore may jeopardize all ooRexx programs, that have exploited the classic requires-behaviour, needing the initialization/prologue part to be run for each RexxStart(). Hence, how about the following idea? Let the requires-directive behave as in all previous versions of ooRexx (semantics of context-CallProgram()?), e.g. ::requires someRexxPackage.rex /* executes as in all previous versions of ooRexx */ allow a new keyword on the requires directive that tells ooRexx 4.0 to use the new behaviour (semantics of PackageManager::loadRequires(...)), e.g. if the new keyword is named global (maybe there are more meaningful keywords like cache, loadonce, singleton, etc.) ::requires someRexxPackage.rex global /* global keyword causes the package to be globally cached */ This would allow all pre-ooRexx 4.0 programs with requires-directives to execute as in the past, hence backward compatibility in this regard is ensured. It also would allow to start to use the new (preferable) behaviour if the ooRexx programmer wishes to do so (and I think, if ooRexx programmers realize how great the new behaviour is, that they will eventually adopt their programs to do so; there may be - probably rare - cases where this would not be possible, but then that would not be a problem either as the old behaviour is available as well). In addition, having seen the new C++ APIs new libraries and packages can be devised that would easily be able to exploit globally cached packages. HTH, ---rony
Re: [Oorexx-devel] Another possible problem and maybe a possible solution ... (Re: Problem with prologue of ::requires file not executing
Rick McGuire wrote: Sorry, I am adamantly opposed to any effort to preserve that old behavior. It was the cause of no end of problems, including most of the hacks you're now citing as instances of the problems. At this point in the project, what you're proposing will be an incredibly disruptive change to the code base that I'm not willing to make. If you are willing to put in the time and effort to come up with a patch that demonstrates this change, we might consider it. It, however, needs to be done quickly, as I'm also not willing to delay the release of 4.0 to wait for it. O.K., I'll do my best, but it'll take some time for me to come even close to be able to do that. ---rony On Sun, Apr 5, 2009 at 8:55 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi there, Rick McGuire wrote: You have misunderstood what this thread was about. Mike's programs were unaffected, oodialog has already been reworked to remove an old hacky way to get around the old behavior. This really only becomes an issue for programs that stuffed things into .local to get around how ::requires used to work AND those programs are relying on the information in .local persisting between RexxStart() invocations. In addition to the .local-problem there is one more possible problem: if the external function library needs to be configured from the Rexx program for each RexxStart(), this is in the current drop not possible! E.g. in the case of BSF4Rexx the external function library gets configured by the initialization/prologue code in BSF.CLS. If the initialization/prologue code is not executed, then the Rexx programs cannot function correctly anymore! (The same is true for UNO.CLS which adds the support to script the OpenOffice.org applications, sitting on top of BSF.CLS.) --- It is impossible to say how many applications are deployed in companies which invoke Rexx via RexxStart() because they use Rexx as a scripting language for their applications. If they dispatch ooRexx programs that deploy the requires-directive, then they may depend on the current behaviour of GA-ooRexx (the behaviour has been there since the IBM Object REXX days), in that after following all directives the initialization/prologue code gets run, which indeed does also carry out all sort of initializations. In such use-cases it may not be possible to replace the requires-directive with a call being the very first statement in the initialization/prologue code, because it may be the case that the directives refer to public classes and public routines in the required programs ! Now, the current (pre 4.0) behaviour of files/programs/packages being required via the requires-directive has been a constant cause of confusion (each requires causes in the scope of that program that required public classes are scoped class object instances that are not equal to the class object instances of other programs having required the same package!), hence coming up with a solution that truly allows a required program/package to be required globally, i.e. any other requires would refer to the already globally (cached) required file/package. Skimming over the current source code of ooRexx 4.0 one can tell that a lot of effort has been invested in this desired (and very appreciated!) behaviour available only in ooRexx 4.0. --- Thinking about this particular problem from a distance of a few days, weeks, it seems that the real problem currently is that the new global behaviour is currently set out to be the default behaviour for ooRexx 4.0! This therefore may jeopardize all ooRexx programs, that have exploited the classic requires-behaviour, needing the initialization/prologue part to be run for each RexxStart(). Hence, how about the following idea? Let the requires-directive behave as in all previous versions of ooRexx (semantics of context-CallProgram()?), e.g. ::requires someRexxPackage.rex /* executes as in all previous versions of ooRexx */ allow a new keyword on the requires directive that tells ooRexx 4.0 to use the new behaviour (semantics of PackageManager::loadRequires(...)), e.g. if the new keyword is named global (maybe there are more meaningful keywords like cache, loadonce, singleton, etc.) ::requires someRexxPackage.rex global /* global keyword causes the package to be globally cached */ This would allow all pre-ooRexx 4.0 programs with requires-directives to execute as in the past, hence backward compatibility in this regard is ensured. It also would allow to start to use the new (preferable) behaviour if the ooRexx programmer wishes to do so (and I think, if ooRexx programmers realize how great the new behaviour is, that they will eventually adopt their programs to do so; there may be - probably rare - cases where this would not be possible, but then that would not be a problem either as the old behaviour is available as well). In addition, having seen the
Re: [Oorexx-devel] Another possible problem and maybe a possible solution ... (Re: Problem with prologue of ::requires file not executing
Ok, I've come up with a compromise. Packages are still loaded and maintained on a process basis, but each interpreter instance will maintain a list of packages that is used by code running in the instance and will ensure that the prologue code gets run when the package is first requested by the instance. Since .local is also maintained on an instance basis, this should fix the behavioral problems you're seeing. And the code refactoring required to implement this fixed a couple of things I was not happy about in the package manager code, so this is definitely a win-win. Rick On Sun, Apr 5, 2009 at 9:22 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Rick McGuire wrote: Sorry, I am adamantly opposed to any effort to preserve that old behavior. It was the cause of no end of problems, including most of the hacks you're now citing as instances of the problems. At this point in the project, what you're proposing will be an incredibly disruptive change to the code base that I'm not willing to make. If you are willing to put in the time and effort to come up with a patch that demonstrates this change, we might consider it. It, however, needs to be done quickly, as I'm also not willing to delay the release of 4.0 to wait for it. O.K., I'll do my best, but it'll take some time for me to come even close to be able to do that. ---rony On Sun, Apr 5, 2009 at 8:55 AM, Rony G. Flatscher rony.flatsc...@wu-wien.ac.at wrote: Hi there, Rick McGuire wrote: You have misunderstood what this thread was about. Mike's programs were unaffected, oodialog has already been reworked to remove an old hacky way to get around the old behavior. This really only becomes an issue for programs that stuffed things into .local to get around how ::requires used to work AND those programs are relying on the information in .local persisting between RexxStart() invocations. In addition to the .local-problem there is one more possible problem: if the external function library needs to be configured from the Rexx program for each RexxStart(), this is in the current drop not possible! E.g. in the case of BSF4Rexx the external function library gets configured by the initialization/prologue code in BSF.CLS. If the initialization/prologue code is not executed, then the Rexx programs cannot function correctly anymore! (The same is true for UNO.CLS which adds the support to script the OpenOffice.org applications, sitting on top of BSF.CLS.) --- It is impossible to say how many applications are deployed in companies which invoke Rexx via RexxStart() because they use Rexx as a scripting language for their applications. If they dispatch ooRexx programs that deploy the requires-directive, then they may depend on the current behaviour of GA-ooRexx (the behaviour has been there since the IBM Object REXX days), in that after following all directives the initialization/prologue code gets run, which indeed does also carry out all sort of initializations. In such use-cases it may not be possible to replace the requires-directive with a call being the very first statement in the initialization/prologue code, because it may be the case that the directives refer to public classes and public routines in the required programs ! Now, the current (pre 4.0) behaviour of files/programs/packages being required via the requires-directive has been a constant cause of confusion (each requires causes in the scope of that program that required public classes are scoped class object instances that are not equal to the class object instances of other programs having required the same package!), hence coming up with a solution that truly allows a required program/package to be required globally, i.e. any other requires would refer to the already globally (cached) required file/package. Skimming over the current source code of ooRexx 4.0 one can tell that a lot of effort has been invested in this desired (and very appreciated!) behaviour available only in ooRexx 4.0. --- Thinking about this particular problem from a distance of a few days, weeks, it seems that the real problem currently is that the new global behaviour is currently set out to be the default behaviour for ooRexx 4.0! This therefore may jeopardize all ooRexx programs, that have exploited the classic requires-behaviour, needing the initialization/prologue part to be run for each RexxStart(). Hence, how about the following idea? Let the requires-directive behave as in all previous versions of ooRexx (semantics of context-CallProgram()?), e.g. ::requires someRexxPackage.rex /* executes as in all previous versions of ooRexx */ allow a new keyword on the requires directive that tells ooRexx 4.0 to use the new behaviour (semantics of PackageManager::loadRequires(...)), e.g. if the new keyword is named global (maybe there are more meaningful keywords like cache, loadonce, singleton, etc.) ::requires
Re: [Oorexx-devel] Another possible problem and maybe a possible solution ... (Re: Problem with prologue of ::requires file not executing
Rick McGuire wrote: Ok, I've come up with a compromise. Packages are still loaded and maintained on a process basis, but each interpreter instance will maintain a list of packages that is used by code running in the instance and will ensure that the prologue code gets run when the package is first requested by the instance. Since .local is also maintained on an instance basis, this should fix the behavioral problems you're seeing. And the code refactoring required to implement this fixed a couple of things I was not happy about in the package manager code, so this is definitely a win-win. That's just great, thank you very much, indeed! ---rony P.S.: Looking through the svn diff, there would be no way I could have come up with a solution like that any time soon! -- ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
