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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto: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