On Sun, Mar 8, 2020 at 6:23 PM P.O. Jonsson <oor...@jonases.se> wrote:
> 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? > There are no such features yet because we are still at the 5.0 level. With future releases, we'll start documenting what language levels are required for new features. > > 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. > It might be a good idea for rexxc to indicate the minimum language level required. > > 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> 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> 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> 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 >>> >> _______________________________________________ > 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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
