While going to bed, I realized that I totally forgot that the override-related options should be at
the .Package class object level (just used package instances for faster development). So the current
variant has two methods defined for the .Package class:
* a class method named "options" that allows querying and setting the options
"OverridePackageSettings" and "CountOverride", and
* an instance method named "options" that allows querying and setting the
options for the package
instance in hand, i.e., the options "All", "Digits", "Error", "FAilure", "FOrm",
"FUzz",
"Lostdigits", "NOString", "NOTready", "Prolog", and "Trace" (these are all
the options one can
set with the ::options directive).
Yesterday's "launch.rex" sample, therefore, needs to be changed to:
parse arg pgmName args -- parse program name and command line arguments --
override the options
of programs that get called or required from now on .package~options("Override",
"::OPTIONS ALL
SYNTAX") -- set override settings .package~options("countOverride", -1) --
override all
called/required program/package settings -- now call the program with the
overridden options
call (pgmName) args -- run the program
(Note: this "launch.rex" version will "globally" apply the overrides as the "countOverride" option
got set to a negative number, i.e., to "-1".)
Usage of "launch.rex" remains the same, i.e.,
G:\test\orx\options>*rexx launch.rex test_novalue.rex*
1 *-* say "using a variable with" novalue "which is by default fine!"
6 *-* call (pgmName) args -- run the program
Error 98 running G:\test\orx\options\test_novalue.rex line 1: Execution
error.
Error 98.986: Reference to unassigned variable "NOVALUE".
G:\test\orx\options>
Will now start testing and once if it looks stable enough, will commit this version such that
everyone interested may get their hands on it after the interpreters are re-created by Jenkins and
placed on < <https://sourceforge.net/projects/oorexx/files/oorexx/5.2.0beta/>.
---rony
On 14.10.2025 22:16, Rony G. Flatscher wrote:
Hi Jon,
Sorry for being "mum"; however, I have been trying to get the second part implemented and up and
running the way I intended (but did not know whether I would succeed). For a few minutes, it has
been working; it still needs thorough testing and tidying up before I would be ready to submit the
code.
Here are the coarse specifications:
* There is a new option named "OverridePackageSettings" (default:
packageSettings default),
which returns the current overridePackageSettings as an ::OPTIONS directive
string, or if a
second argument is supplied, it needs to be a string representing a
syntactically correct
::OPTIONS directive which then gets used to set the override
packageSettings from then on;
this can be changed at runtime dynamically at any time repeatedly
* There is a new option named "CountOverride" (default: 0), which returns the
current
"countOverride", and if a second argument is supplied, it needs to be a
number with the
following implications (can be changed at anytime repeatedly):
o 0 ... no overriding takes place (default setting)
o +n (positive number): overriding takes place exactly n times and then
halts
o -1 ... overriding takes place constantly (in previous discussion meant for
"global
override") and can only be stopped by setting the value explitly to 0
(.context~package~options("count",0))
This will allow at runtime to turn on package settings override dynamically
(e.g. for debugging).
This should e.g. allow for a little Rexx launcher, that would allow Walter et.al. to invoke any
program with something like "::options all syntax" or "::options digits 20" to override all
program option settings intentionally ("launch.rex"):
parse arg pgmName args -- parse program name and command line arguments --
override the
options of programs that get called or required from now on pkg =
.context~package -- get
package object pkg~options("Override", "::OPTIONS ALL SYNTAX") -- set
override settings
pkg~options("count", 1) -- just override settings once for the next
called/required program --
now call the program with the overridden options call (pgmName) args -- run
the program
Here a program that would run as long as the novalue condition is not set
("test_novalue.rex"):
say "using a variable with" novalue "which is by default fine!"
Running the "test_novalue.rex" program as is with its output:
G:\test\orx\options>*rexx test_novalue.rex*
using a variable with NOVALUE which is by default fine!
G:\test\orx\options>
Running "test_novalue.rex" with "launch.rex" above would look like this and generate the following
output:
G:\test\orx\options>*rexx launch.rex test_novalue.rex*
1 *-* say "using a variable with" novalue "which is by default fine!"
8 *-* call (pgmName) args -- run the program
Error 98 running G:\test\orx\options\test_novalue.rex line 1: Execution
error.
Error 98.986: Reference to unassigned variable "NOVALUE".
G:\test\orx\options>
If the "count" option was set to "-1" then all subsequently called or required programs would get
their package options overridden as well.
---
The third part (TBD, maybe Gil can lend a hand there, which would be really of great help) would
then be to implement the ability for the discussed switches for the rexx launchers (rexx[.exe],
rexxhide[.exe], rexxpaws[.exe]):
options ::= (-o | --override | -g | --global-override) ("string" |
@<filespec>)
Ad "string": this must be formatted as a single, syntactically correct "::OPTIONS" directive,
without a semi-colon (;), carriage return (CR, "0d"x) or linefeed (LF, "0a"x) to be seen acceptable.
---
After testing further and tidying up I would also try to reword the documentation, trying to avoid
the problems that Jon has thankfully pointed out, with the request to give feedback or
improvements for it, once done!
---rony
On 13.10.2025 16:57, Sahananda wrote:
Hi Rony,
It is really tricky expressing things clearly and it seems to me that this sentence describes
something that can be used several ways and thus is really complicated. I'm now not sure whether
the verb should be Set, Modify or Override, and if I have understood you correctly, then until we
see the behaviour of the finished object this will remain unclear, and it may be that even at
method invocation time, we don't know whether the operation being performed is a set, a modify or
an override as that is dependant on what follows and whether new programs or packages inherit
these options.
To me, this is the flavour of the three words
* SET - This assigns a value to the option, either an initial one or a
replacement one. The
value can subsequently changed by setting again
* MODIFY - This assigns a new value replacing an extant value. The value can
subsequently be
changed by modifying again
* OVERRIDE - This is assigning a new value whilst remembering the old (or
perhaps original)
value. The OVERRIDE can be undone somehow and either the previous or
original value will be
reinstated. I'm not clear whether this is a push/pop.
None of them seem to exactly describe the mechanism that you describe (turning
off the override)
I wonder if anyone else can take a stab at it?
Jon
On Mon, 13 Oct 2025 at 14:09, Rony G. Flatscher <[email protected]> wrote:
Hi Jon,
On 13.10.2025 14:07, Sahananda wrote:
Sorry, there was a typo. In my suggested sentence, the first 'set' is
redundant as what is
being set is called the 'package options', not the 'set package options'.
The first part of the sentence should therefore read:
*This method retrieves the current package options,*
I have difficulty with the rest of the sentence as I am not sure what you
are saying.
Perhaps it would be better as two sentences:
*This method retrieves and optionally sets the current package options.
The package options
may also be set explicitly using the ::options directive.*
I'm not sure whether the word 'modifies' should replace the word 'sets'?
If (and I think
this is the case) there will always in every circumstance be a previous
value to the package
options when this method is called, I think '*modifies*' is better here.
If there is some
circumstance where this method can be used to initialise the package
options (and I don't
think that is possible) then imho '*sets*' would be clearer.
Again, I'm still not sure how the adverb '*explicitly*' modifies the
meaning in this
context. Perhaps if you said a couple of sentences about that I could
venture an opinion.
Again, I hope this is helpful,
Yes, very much so, and thank you very much for taking the time!
Maybe a few more infos after reading your thoughts: this 'options' method
without argument
returns a string formatted as an ::OPTIONS directive showing all options in
effect for the
package. In addition it allows to query and set any option that can be
listed on the
::OPTIONS directive, whereby always the value at method invocation time
gets returned.
However, this method is also meant for allowing for defining the package
settings that should
be used to override the package settings when loading programs/packages
which then determine
the package settings that should be in effect. To make this even more
flexible there is an
idea of turning on/off the overriding behaviour not only with a switch, but
even allowing to
optionally define the number of overrides that should take place, including
"infinity". This
is still in infant stage, but eventually this should become available
(currently implementing
that part).
Not sure whether that clarifies it, as it is work in progress (WIP) and
cannot be tested yet.
(Once that part works one could use that infrastructure then to allow for
supplying override
options when starting a Rexx program.)
HTH
---rony
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
