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:
> - no argument: return a StringTable with the package's (program's)
> options
> - a single argument: the argument denotes the name of an option for
> which the package's value should be returned
> - 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
>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
