On 07.08.2020 00:02, Rick McGuire wrote: > Been without power here since Tuesday and probably won’t have power until the > weekend, so I won’t > be able to review anything.
Wow, sorry to hear that! All the best! --- In the process of updating the patch (missed createProgram(), simplifying code a little bit more). ---rony > > On Thu, Aug 6, 2020 at 1:51 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at > <mailto:rony.flatsc...@wu.ac.at>> wrote: > > Please review the fixes. > > If there are no objections I will apply the patch of #1716 (it also > includes the patch for bug > #1715) together with test units to test for them. > > ---rony > > > On 06.08.2020 19:47, Rony G. Flatscher wrote: >> >> The bug report in <https://sourceforge.net/p/oorexx/bugs/1716/> >> <https://sourceforge.net/p/oorexx/bugs/1716/> includes a patch that >> fixes this. >> >> ---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
