While looking into it, there is also a difference in the behaviour of the
"newFile" class method in
.routine and .method, where the latter cannot process compiled and encoded Rexx
code.
Here a rexxtry session to demonstrate:
F:\work\svn\bsf4oorexx\trunk\samples\Java\javax.script>rexxtry
REXX-ooRexx_5.0.0(MT)_32-bit 6.05 29 Jul 2020
rexxtry.rex lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
Go on - try a few... Enter 'exit' to end.
r=.routine~newFile("nutshell_01.rex-compiled")
........................................... rexxtry.rex on WindowsNT
r[]
parse source: WindowsNT SUBROUTINE nutshell_01.rex-compiled
received 0 arguments:
........................................... rexxtry.rex on WindowsNT
r[1,2,3]
parse source: WindowsNT SUBROUTINE nutshell_01.rex-compiled
received 3 arguments:
arg(1)=[1] [The String class]
arg(2)=[2] [The String class]
arg(3)=[3] [The String class]
the last argument is a Rexx directory containing the ScriptContext of this
invocation:
Oooops ! ... try again. Object method not found.
Object "3" does not understand message
"SCRIPTCONTEXT".
rc = 97.1 ................................. rexxtry.rex on WindowsNT
m=.method~newFile("nutshell_01.rex-compiled") Oooops ! ... try again.
Invalid character in
program. Incorrect character in program "@" ('40'X).
rc = 13.1 ................................. rexxtry.rex on WindowsNT
m=.method~newFile("nutshell_01.rex-source")
........................................... rexxtry.rex on WindowsNT
say m
a Method
........................................... rexxtry.rex on WindowsNT
---rony
On 05.08.2020 15:16, Rony G. Flatscher wrote:
>
> Having received error reports from users of BSF4ooRexx like
>
> 2 *-* /**/@
> Error 13 running
> rexx_invoked_via_[fxml_01.fxml]_at_2020_08_05T12_33_24_17Z.rex line 2:
> Invalid character in program.
> Error 13.1: Incorrect character in program "@" ('40'X).
>
> and looking up the execution paths in those cases, it turns out that the
> ooRexx .routine class
> gets used to create the executable in those cases with a string array
> representing the compiled
> and encoded Rexx program.
>
> So the "new" method of the .routine class gets the compiled and encoded
> source supplied as an
> array of strings, e.g.:
>
> #!/usr/bin/env rexx
> /**/@REXX@
> LyoqL0BSRVhYAAAAAAAAAGcrKgAgAAAAVOwAAAAAAABwEgAAVPq7VhgAAAACAAAAAAAAAAAA
> AAAAAAAAgB68ViAAAAACAAAAKAAAAAAAAABwAAAAOAAAAAAAAADkSrxWOAAAAAIAAAAFAACA
> ... cut ...
>
> Supplying the compiled and encoded data as a single string to the .routine
> class does not work as
> this issues the error "13.1, Invalid character in program" caused by the
> presence of a LF ('0A'x)
> character, here a rexxtry example:
>
> infile=.stream~new("nutshell_01.rex-compiled")~~open("read")
> ........................................... rexxtry.rex on WindowsNT
> pgm=infile~charin(infile~chars)
> ........................................... rexxtry.rex on WindowsNT
> infile~close
> ........................................... rexxtry.rex on WindowsNT
> r1=.routine~new("aha",pgm)
> Oooops ! ... try again. Invalid character in program.
> Incorrect character in program "
> " ('0A'X).
> rc = 13.1 ................................. rexxtry.rex on WindowsNT
>
> As a compiled and encoded form of a Rexx program always has the string
> "/**/@REXX@" as the value
> for its second line it would be possible to determine that the String array
> comes from a compiled
> and encoded Rexx program. Rather than creating an error in this case, the
> routine object could get
> created successfully from the String array representing a compiled and
> encoded Rexx program.
>
> Are there any objections to try to enhance the "new" method of the .routine
> (and the .method)
> class such that the string array can represent a compiled and encoded Rexx
> program?
>
> ---rony
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
