On 15.10.2025 18:17, Josep Maria Blasco wrote:
Maybe using the same name for a class method and
for instance methods can end up by confuse some users.
Why not using another name for the class method,
for instance "globalOptions"? It's a little redundant,
yes, but it's also very clear, and it avoids confusions.
Thank you for this suggestion, which will improve intuitive understanding and therefore cut down
mix-ups!
---
There is a new suboption added on the options instance method: "InitialPackageSettings". When using
overrides it may be interesting and even important at times to be able to get at the initial package
settings when the program/package got called/required. For this option it is an error to supply a
newValue as no changes can be allowed on that value. (There is an additional option - "Options" |
"PackageOptions" | "SetPackageOptions" - planned for setting a package using an ::OPTIONS directive
string.)
---rony
Missatge de Rony G. Flatscher <[email protected]> del dia dc., 15 d’oct.
2025 a les 15:46:
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/>
<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
<http://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
