On 14.08.2020 17:54, Rick McGuire wrote: > I don't see anything I'd object too. It looks pretty straight forward.
Thank you very much! ---rony > > On Fri, Aug 14, 2020 at 11:04 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at > <mailto:rony.flatsc...@wu.ac.at>> wrote: > > Rick, hoping that electricity and everything else has been restored by > now, hence the question > whether you have had time already to look at the patch > > <https://sourceforge.net/p/oorexx/bugs/_discuss/thread/3374511d18/a4d6/attachment/patch-new-newfile-from-encoded.txt> > > <https://sourceforge.net/p/oorexx/bugs/_discuss/thread/3374511d18/a4d6/attachment/patch-new-newfile-from-encoded.txt> > from <https://sourceforge.net/p/oorexx/bugs/1716/> > <https://sourceforge.net/p/oorexx/bugs/1716/>? > > ---rony > > > On 07.08.2020 13:23, Rony G. Flatscher wrote: >> >> Just updated <https://sourceforge.net/p/oorexx/bugs/1716/> >> <https://sourceforge.net/p/oorexx/bugs/1716/> with a new patch (adds >> support in >> LanguageParser::createProgram(), simplifies code a little bit more) and >> test files going with >> it. >> >> ---rony >> >> >> On 07.08.2020 12:21, Rony G. Flatscher wrote: >>> 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
