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 list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
