As a bystander I realize this may well cause some unpleasant surprises so it needs to be explained in detail, summing up more or less all what Rick writes I think should all go into the documentation.
Say that you are indeed developing for clients. Most likely you will always be „top-notch“ latest update of ooRexx, say 5.1. Now, when you ship to clients they are invariably at a lower version (think of how many companies are still on Windows 7) so when a *really* nice feature or improvement is introduced in 5.1 (like address with) you are bound to pick it up and start using it. Shipping to the client you will have some angry phonecalls coming. Spelling it out with examples, as Rick just did will clarify the situation. Question: is there a good place to put a list of such features that may be show-stoppers to the use of rexxc? Another question: Would it be possible to warn the user of rexxc at tokenizing time that he is using features from the latest upgrade? Or will this be a mess? Warning for 5.0 -> 5.1 or 5.1 -> 5.2 changes would imo be enough. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 08.03.2020 um 23:07 schrieb Jon Wolfers <sahana...@gmail.com>: > > Thanks Rick > > I've got it now. That is how one would want it to work. > Not sure what should go in the rexxpg but will sleep on it. > > Jon > > On Sun, 8 Mar 2020 at 22:05, Rick McGuire <object.r...@gmail.com > <mailto:object.r...@gmail.com>> wrote: > Still not right. It is actually the opposite of that. A program compiled with > 5.0 should still continue to work with 5.1, but programs compiled with 5.1 > will also work with 5.0 as long as they don't require any of the new language > features in 5.1. > > Rick > > On Sun, Mar 8, 2020 at 5:59 PM Jon Wolfers <sahana...@gmail.com > <mailto:sahana...@gmail.com>> wrote: > 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 > <mailto: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 > <mailto: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 >> <mailto: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 >>>>> <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 >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
