In order to systematically try to implement this feature, I would suggest implementing the method
"options" for Package first and then analyzing whether everything works as expected. If that works
out, the next step would be to define the specs for the environment variable and command line
switches (this includes whether, and if so, how to define options/fileContent that should be used
for the initial program/package, or globally from that moment on for all programs/packages that get
loaded).
So here is a suggestion for the description of the suggested OPTIONS method for
the Package class:
OPTIONS( [optionName [, newValue]])
Returns a directory with the values of all currently set options for the
package. If the
optional argument "optionName" is supplied, it returns the current setting.
If the optional
argument "newValue" is supplied for "optionName", then "newValue" replaces
the current value for
the package.
"optionName" can be one of (only the first signifcant letters need to be
supplied as argument,
depicted in uppercase):
* Digits
returns the current number of digits (default: 9)
* FOrm
returns "ENGINEERING" or "SCIENTIFIC" (default: "SCIENTIFIC")
* FUzz
returns the current number of FUZZ digits (default: 0)
* Handlecondition (default: "ERROR CONDITION FAILURE CONDITION
LOSTDIGITS CONDITION
NOSTRING CONDITION NOTREADY CONDITION NOVALUE CONDITION")
returns a string denoting how conditions get handled
* Prolog (default: "PROLOG")
returns "PROLOG" or "NOPROLOG"
* Trace (default: "NORMAL")
returns "NORMAL | ALL | COMMANDS | ERROR | FAILURE | INTERMEDIATES |
LABELS | OFF | RESULTS"
Changing "optionName" to "newValue" (only the first significant letters need
to be supplied as
argument, depicted in uppercase)
* Digits, nrDigits
nrDigits>0
* FOrm, "Engineering" | "Scientific"
* FUzz, nrDigigs
nrDigits>=0
* Handlecondition, (All | Error | Failure | Lostdigits | NOString |
NOTReady | NOValue
"Condition" | "Syntax")+
Note 1: using ALL will set ERROR, FAILURE, LOSTDIGITS, NOSTRING,
NOTREADY, NOVALUE to
"CONDITION" | "SYNTAX"
Note 2: it is possible to have multiple definitions such that one
could use ALL for the
default handling, and define specific handling options for ERROR,
FAILURE, LOSTDIGITS,
NOSTRING, NOTREADY, NOVALUE if need be; in case of conflict, the
last definition prevails
Note 3: the settings of the conditions HALT, NOMETHOD, SYNTAX, and
USE cannot be changed
* Prolog, "Prolog" | "Noprolog"
* Trace, Normal | All | Commands | Error | Failure | Intermediates |
Labels | Off | Results
How about protecting this method such that a security manager can be used to protect access to this
method, if need be?
Are there any stumbling blocks, side effects one needs to be aware of?
Any thoughts, comments, ideas?
---rony
On 02.10.2025 14:36, Josep Maria Blasco wrote:
Missatge de Rony G. Flatscher <[email protected]> del dia dj., 2 d’oct.
2025 a les 13:59:
Thanks to everyone who gave feedback and hinted at being able to help
(kudos to Gil)!
Before going further, we should first agree on the specifications:
* ad environment variable's name: REXX_OPTIONS; if it has a value, it may
denote anything
one can denote with the ::options directive on a single line
* ad command line arguments: not yet clear which ones are needed and what
their name should
be; there are suggestions for "-o" for options (suggesting alias "--options") and
"-go"
for global options (suggestion alias "--global-options"); it is
followed by a blank and a
quoted string that may denote anything one can denote with the
::options directive on a
single line. Should we allow options to be stored in a file, and a) if
so, what option
should be used for indicating that the options are defined in a file,
and b) what should
the content of the file be (even if it is a properties file, what keys
should be defined,
what values are allowed)
Maybe "-fo" or "--file-options"? And also, maybe the keys should be the same as the option names
below, to avoid confusions.
*
* ad runtime inspection and setting: how about allowing a method
"options" on the package
class with the following arguments:
o no argument: return a StringTable with the package's (program's)
options
o a single argument: the argument denotes the name of an option for
which the package's
value should be returned
o two arguments: the first argument denotes an option, the second
argument denotes the
option's value
Here are suggestions for the option names:
* DIGITS (number)
* FORM (Engineering | Scientific)
* FUZZ (number)
* HANDLE_CONDITION subkeywords: ALL, ERROR, FAILURE, LOSTDIGITS,
NOSTRING, NOTREADY, NOVALUE
(Condition | Signal )
I would try not to use names with underscores, if at all possible (no, I don't have a good
candidate). And it's "Syntax", not "Signal" :)
Josep Maria
* PROLOG (.true | .false) ... .false means NOPROLOG, makes sense only if
one can define this
before loading a program/package
* TRACE subkeyword (All | Intermediates | Normal | Off | Results)
Any comments, ideas?
---rony
On 01.10.2025 12:55, Josep Maria Blasco wrote:
Maybe the global case could also be handled at the command line level.
For example, assuming that
rexx -o "options" program
would pass options "options" to "program" and to "program" alone,
rexx -go "options" program
(""go" for "global options") would pass options "options" to "program", and
to all the packages required by "program" or loaded via loadPackage.
Josep Maria
Missatge de Rony G. Flatscher <[email protected]> del dia dc., 1
d’oct. 2025 a les 12:07:
On 30.09.2025 19:57, Gilbert Barmwater via Oorexx-devel wrote:
Having had some time to think about this, I have the following proposed
design for
discussion.
1) I very much like the idea of an environment variable - I would call
it REXX_OPTIONS
to be consistent with the other one, REXX_PATH. This has the advantage
of allowing a
one-time setting, if desired, and removal of the need to type the value
for every
execution of a program with the possibility of mis-typing it. I would
propose that the
entire "line" to be appended be specified in rexx_options, i.e.
'::options all syntax'
for example. This would then allow addition of a ::requires directive
instead should
one need to "add" multiple lines to the end of the target program. (The
multiple lines
would be placed in a separate file and the ::requires would name that
file.)
2) Specifying a switch ( /O or -O ) on the rexx command gives the user
control on every
execution if the "line" is to be added (or not). I would not consider
it an error if
the "O" switch was specified but rexx_path was undefined; this would be
equivalent to
execution without the "O" switch.
One might argue that this design requires a two step process as
compared to specifying
"everything" on the command which is a single step. While true, I
believe the potential
usage for this feature would be multiple executions of the command with
the same
"options" so being able to specify those "options" once would be
beneficial.
I do not think the implementation should be too difficult (I have
experience adding a
switch to rexx.exe) with the more challenging part being locating and
getting the target
program source into a buffer where the "line" can be appended. The
buffer would then be
executed by RexxStart just as is done when the "E" switch is present
with a program string.
It would be possible to "blindly" append an ::options statement to the
end as ::option
directives can be given multiple times and the last one wins. This is
done by
tracetool.rex (cf. net-oo-rexx package) which appends an ::option
statement to denote the
desired global trace option for creating a tracelog.
There is one case where this is not possible: if a program is compiled
with rexxc one
cannot tamper with the source code as it is not available.
---
AFAICT the options are registered against the package which can be used
to query all set
options. What is missing there are (protected) setters which would
allow for changing the
initial settings at runtime which sometimes would be more than helpful
as the case of
Walter shows. Studying the fundamental Package class one could use
importedPackages to
analyze (and if made possible) and to change the global options
settings there as well,
if one wrote such an ooRexx program (e.g. processing all available
packages in the prolog
and setting the options there).
So a question in this context would be whether it was o.k. to add
setters to the
package's option attributes "digits", "form", "fuzz", "trace"? And add some
"condition"
method to set/reset the condition related settings (like "all syntax" or
"all
condition"), if that is possible to have immediate effect at runtime.
---
If one wishes to set the options to be used for programs that are to be
required/called,
all of the options (including "prolog" or "noprolog") should become
settable. Maybe
having a runtime "options" object in addition that defines the defaults
for
loading/requiring programs could be used, such that the defaults for
loading new programs
could be changed by changing such a default "options" object?
---rony
On 9/29/2025 8:02 AM, Rony G. Flatscher wrote:
One more idea: as ooRexx starts out with predefined options values (like
"digits 9",
"trace normal", ...) which currently can be changed statically per
program/package by
adding ::options statements, it should be possible to define those
"predefined options"
at startup. E.g., something like (borrowing from Regina)
* rexx someRexxProgram -o "options string" somePgm args ... somePgm
and each program
executed will get its options changed to "options string"
* rexx someRexxProgram --options="options string" somePgm args ...
somePgm and each
program executed will get its options changed to "options string"
* rexx someRexxProgram -op somePgmWithOptionsSet.cls somePgm args ...
somePgm and
each program executed will get its options changed to all ::OPTIONS
in
"somePgmWithOptionsSet.cls"
or an environment variable like OOREXX_OPTIONS, where each program
executed will get
its options changed to OOREXX_OPTIONS.
This would allow Walter's requirement to be easily applied without the
need to change
any program, something like 'rexx -o "ALL SYNTAX" somePgm [args]'
---rony
On 28.09.2025 21:46, Rony G. Flatscher wrote:
On 28.09.2025 15:04, Hobart Spitz wrote:
IMHO, yes. It keeps with the philosophy of general flexibility and
"letting the
programmer do what they want when they want" even if we can't think of
a reason right
now.
Thank you for your feedback, Hobart!
Any other thoughts?
---rony
OREXXMan
Q: What do you call the residence of the ungulate with the largest
antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via
disk (JCL)? Why do you think you rarely see *nix commands with more
than a dozen
filters, while Pipelines specifications are commonly over 100s of
stages, and 1000s
of stages are not uncommon.
REXX is the new C.
On Sun, Sep 28, 2025, 05:49 Rony G. Flatscher <[email protected]>
wrote:
ooRexx being a dynamic language usually allows for defining, e.g.
classes
statically with
directives, but also dynamically at runtime instantiating .class
(and creating
and assigning methods
and the like).
The ::options directive has become quite powerful and it would be
helpful to be
able to a) query all
package's current settings and b) allowing to change the (::options
related)
package settings at
runtime ("dynamic"). (Maybe a proper Options class may be helpful
which allows
for interrogating and
setting options.)
This may help in situations like using (maybe older) Rexx programs
for which some
settings should be
changed (like "any syntax", but also "trace ..." comes to mind,
etc.).
Would that be seen as a desired improvement?
---rony
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
