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)
* 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 )
* 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
