Having pressed send, I realise that I spoke to soon. Rick, if I understand you rightly, any module compiled with 5.0 would work with subsequent releases - unless a feature was removed.So a piece of code written for 5.0 and compiled with the 5.0 rexxc would work with 5.1 & 5.2 and so on unless features were dropped.
It would not work with 4.2, but it would be unreasonable to expect it to. If that is correct, then this is a good solid no-astonishment scenario and I don't think anything needs to appear in the manual, because there is no surprise waiting. I hope I got it right this time. Jon On Sun, 8 Mar 2020 at 21:51, Jon Wolfers <sahana...@gmail.com> wrote: > Hi, > > I'm sorry to have caused this difficulty. Rick - thanks for doing the > compatibility work. If I understand correctly, the 'feature level' is not > a number held somewhere. Just that if you use features introduced after > the rexxc program was created they won't be handled. > > Perhaps it is best to go back to Rony's serial approach and say that > compiled modules may need to be compiled when used with a different > language level interpreter or bitness. > > Jon > > On Sun, 8 Mar 2020 at 20:51, Chip Davis <c...@aresti.com> wrote: > >> OK, I understand that the limiting factor is the language *feature** >> level* employed by the program, not the *language level* of the >> interpreter. Unfortunately, many (most?) programmers are probably not >> going to be aware of that level of granularity. That leaves us with the >> more accurate but somewhat unhelpful ... >> >> "Binary programs produced by 'rexxc' can be run only on a Rexx >> interpreter of the same architecture (32/64-bit) that supports the highest >> feature level used in the program." >> >> ... because most of us won't have any idea what that "highest feature >> level" is. Are feature levels documented in the Reference? Is there a >> flag to tell the interpreter to display the highest feature level being >> employed in the program? >> >> -Chip- >> >> On 3/8/2020 3:44 PM, Rick McGuire wrote: >> >> Except for the fact it is not at all correct. The ability for a program >> to run does not depend at all on the interpreter it is compiled with, but >> just by the language features used by the program. For example, assuming >> there is a new 5.1 release available, a program that will run on 5.0 >> recompiled with the 5.1 interpreter will run just fine on either 5.0 or >> 5.1. However, if it is updated to take advantage of a new language feature >> that has been introduced by version 5.1, then the compiled image will be >> marked as requiring a 5.1 level of the interpreter. >> >> Rick >> >> On Sun, Mar 8, 2020 at 3:31 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at> >> wrote: >> >>> On 08.03.2020 19:55, Chip Davis wrote: >>> >>> Well, as a grammar-nerd I must point out the misplaced "only" and to >>> being confused by the last clause. >>> >>> My re-cast would be: >>> >>> "Binary files produced by rexxc can be run only on an interpreter of the >>> same bitness and the same (or higher) language level as that of the rexxc >>> that created them." >>> >>> Grammatically it is cleaner; I'm just not sure why the phrase "the >>> interpreter that compiling copy of rexxc was supplied with" is necessary. >>> >>> Your version simplifies it even more and thereby making it clearer it >>> seems! Not being a native English speaker I leave it for others to judge >>> whether the phrase "the interpreter ..." should remain or not. The rexxpg >>> book now reflects Chip's suggestion without the phrase. >>> >>> ---rony >>> >>> >>> >>> On 3/8/2020 1:13 PM, Rony G. Flatscher wrote: >>> >>> How about formulating Jon's suggestion then as follows: >>> >>> Binary files produced by a version of rexxc can only be run on an >>> interpreter of the same or higher language level and the same bitness as >>> the interpreter that compiling copy of rexxc was supplied with. >>> >>> Would that be understandable and correct? >>> >>> ---rony >>> >>> >>> On 08.03.2020 17:58, Rick McGuire wrote: >>> >>> >>> >>> On Sun, Mar 8, 2020 at 12:50 PM Jon Wolfers <sahana...@gmail.com> wrote: >>> >>>> Hi Rony, >>>> >>>> The created binary file is dependent on the Rexx language level and the >>>>> bitness (32 or 64 bit) of the Rexx interpreter used for creating the >>>>> binary >>>>> file. Each time the Rexx language level gets increased by a new release of >>>>> Rexx or each time you switch the bitness of the Rexx interpreter you need >>>>> to run rexxc again. >>>> >>>> >>>> I think the English in this sentence is great, but I think it >>>> approaches the situation serially. Ie through time you have one language >>>> level & bitness interpreter and then you move to another. Having used >>>> ooRexx in a production environment this is not always what is going on. >>>> For much of the time, I had my test machine on a newer release than my >>>> clients as I was testing and making changes to support the upgrade as well >>>> as stepwise improvements to the program suite and coping with changes in >>>> the business. Most of my suite was deployed uncompiled, but for security & >>>> license reasons there were some modules that needed to be compiled. When I >>>> upgraded my programs and the language levels I had to be mindful to replace >>>> not only the modules where the source had changed, but also all the >>>> compiled ones where there was a change of interpreter. >>>> >>>> I think your sentence is good enough, but wonder if it would be better >>>> to say something like >>>> >>>> Binary files produced by a version of rexxc can only be run on >>>> (?with?by?) an interpreter of the same language level and bitness as the >>>> interpreter that compiling copy of rexxc was supplied with. The language >>>> level changes with each release of ooRexx. >>>> >>> >>> This is not strictly true. One of the goals with the rewrites I did with >>> this release was to try to maintain release-to-release compatibility >>> wherever possible. The translator keeps track of the minimum level needed >>> to execute the image. New features added in releases after 5.0 will flag >>> that they need a newer release, so the language level in the compiled image >>> is tied to the features being used, not to the level of interpreter used to >>> compile it. Of course currently, the only language level is that used by >>> 5.0, but the mechanism is in place to maintain that compatibility. >>> >>> Rick >>> >>> >>> >>>> >>>> what do you think? >>>> >>>> Jon >>>> >>>> On Sun, 8 Mar 2020 at 16:13, Rony G. Flatscher <rony.flatsc...@wu.ac.at> >>>> wrote: >>>> >>>>> Hi Jon, >>>>> >>>>> thank you very much for your fast feedback! >>>>> >>>>> On 08.03.2020 17:04, Jon Wolfers wrote: >>>>> >>>>> I think it reads well, but the last paragraph on the page about >>>>> rxmigrate needs to be replaced imho. >>>>> >>>>> My understanding is that a new version of rexxc is provided with each >>>>> release and programs compiled with rexxc will only run on the release of >>>>> the interpreter that they were compiled for. That is my experience - is >>>>> it >>>>> correct? If so then I think it would be good to say so. >>>>> >>>>> Hmm, excellent point! Also, one should mention that there is a >>>>> difference between 32- and 64-bit images. >>>>> >>>>> How about some text like: >>>>> >>>>> The created binary file is dependent on the Rexx language level and >>>>> the bitness (32 or 64 bit) of the Rexx interpreter used for creating the >>>>> binary file. Each time the Rexx language level gets increased by a new >>>>> release of Rexx or each time you switch the bitness of the Rexx >>>>> interpreter >>>>> you need to run rexxc again. >>>>> >>>>> How does that sound? >>>>> >>>>> ---rony >>>>> >>>>> On Sun, 8 Mar 2020 at 15:53, Rony G. Flatscher < >>>>> rony.flatsc...@wu.ac.at> wrote: >>>>> >>>>>> "RFB" is meant to mean "request for feedback"! >>>>>> >>>>>> Changed the rexxpg book in the section "Appendix A. Distributing >>>>>> Programs without Source" (i.e. "rexxc") to reflect changes that have >>>>>> occurred: >>>>>> >>>>>> - It would be great to get brief feedback whether this is >>>>>> understandable the way it is now. >>>>>> >>>>>> >>>>>> - Also, please note that I have changed "RexxC" and "REXXC" to >>>>>> "rexxc" (all in lowercase as one has to enter it on case-dependent >>>>>> operating systems on the command line). To emphasize that one is >>>>>> supposed >>>>>> to write the name as is "rexxc" gets formatted as a >>>>>> computeroutput-element >>>>>> (monotype font, bold). Is that change o.k. with everyone? >>>>>> >>>>>> If that is o.k. I would like to change the names of the Rexx >>>>>> programs in "Appendix B. Sample Rexx Programs" accordingly, i.e. show >>>>>> the >>>>>> names in exact case and as computeroutput-elements to make them stand >>>>>> out >>>>>> in the text. >>>>>> >>>>>> Temporarily "rexxpg.pdf" can be loaded from: >>>>>> <https://www.dropbox.com/sh/gxvvgskb04gdsqf/AACRo_ZLeFOdoBXUHroPY_-Ca?dl=0> >>>>>> <https://www.dropbox.com/sh/gxvvgskb04gdsqf/AACRo_ZLeFOdoBXUHroPY_-Ca?dl=0> >>>>>> . >>>>>> >>>>>> ---rony >>>>>> >>>>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >> >> >> _______________________________________________ >> Oorexx-devel mailing >> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
