Internally, an IP address gets encoded into a single 4-byte quantity where each element of the of the address occupies a single nibble of of the quantity. Thus an address like 192,168.0.1 gets encoded into 0xc0a80001. Each digit of the range can be from 0-255. So, applying that logic to an ooRexx interpreter version number, 4.0.0 would become 0x00040000. As long as we never go higher than 255 for any of the codes, we're in good shape. We could decide to use 0x04000000, which would give us freedom to add one more dot level. I don't foresee that we'd ever need to do that. For the interpreter level, the first digit is the major version level, which only gets incremented for major updates. The release we're working on now is 4.0.0 because of the extent of changes involved and new function. The second digit represents a release with new function, and the third digit is for "bug fix" releases. So, two releases ago we had 3.1.2,, which was really just bug fixes. The next release was 3.2.0, and had some fairly significant enhancements.
The language level is a different quantity, and is specified by the answer standard as a major followed by two digits. This would encode easily using the same scheme. Again, it's possible to do this such that we could add additional levels. But again, I don't really see that happening. The language level, historically, has moved more slowly than the interpreter version. The language level is an indicator of the Rexx language itself, as opposed to the entire interpreter package. So our 4.1.0 interpreter release with the new orxscript support is not likely to contain any new language features. The language level for that release will remain at the 6.03 level. This proposal is not going to change the number conventions we use for either these. And for the ooRexx programmer, these pieces of information are already available via PARSE VERSION and PARSE SOURCE. All this does is make the information available to the external library programmer in a form that's more readily usable to the C programmer. Rick On Fri, Oct 10, 2008 at 12:22 PM, Tony Harminc <[EMAIL PROTECTED]> wrote: > 2008/10/9 Rick McGuire <[EMAIL PROTECTED]>: >> David's questions yesterday about RXSHV_PRIV pointed out a deficiency >> in the new APIs. On the interpreter instance APIs, we really should >> have APIs for checking the interpreter version and language level. >> Fairly easy to add, but how should the information be returned? It >> would be nice if we could come up with a binary format that allowed >> for easy level comparisons, but that might be tricky. I think both >> language level and interpreter level need to be provided because they >> don't necessarily bump together. For example, with 4.0.0, the >> language level is 6.03. Current plan is to come out with a minor >> release shortly after 4.0.0 (4.0.1 probably) that will include fixes >> and the repaired orxscript support. orxscript is not really a >> "language" feature, so the language level might stay at 6.04. >> >> For a binary format, we could do what's done with IP addresses and >> store each digit in a separate nibble. Thus the next release would >> have an interpreter version of 0x00040000 and the language level would >> be 0x00000603. These constants would allow an easy "is this level >> greater than or equal to" check to be performed. > > If an Oorexx-devel newbie may jump in for a moment (fools rush in, etc...) > > I'm not sure if the IP address analogy is right; IPV4 address are > stored as 4 octets/bytes, and traditionally written as 4 decimal > numbers (which of course can be expressed in hex or octal if desired). > Your scheme seems more of a BCD encoding. But it's not clear to me if > these are true decimal digits, and how they map to the nominal > interpreter and language levels as they might appear in documentation. > So if the interpreter level gets to 9.0.0 encoded as 0x00090000, what > is the next major version? Would it be 10.0.0 encoded as 0x00100000, > or 0x000a0000 or...? > > Also not clear to me is why interpreter level 4 point something is > 0x0004xxxx, but language level 6 point something is 0x00006xx. If > these are independent binary values, with the expectation for both > that there can be "point" levels, shouldn't they both have the same > number of places after the first point? > > Well, the bottom line seems to me to be that a program needs to be > able to do a binary comparison between what it knows is a level that > supports the features it needs, and the level of the running software. > History is chock full of failures of this sort of thing, on VM, MVS, > and many other systems, typically because the canonical compare was > just not well thought out. (Just recently I've seen the situation > where the Top Secret security product has a version string like 8SP03 > for version 8 Service Pack 3, but 120SP05 for Version 12.0 Service > Pack 5. Easy for people to parse; much trickier for a program to get > right.) Assuming there is upward compatibility "forever", then the > simple compare has to work "forever". Mostly this means making sure it > really is binary, and that there is plenty of high order room for > increasing version numbers, both of which I think you've done. But are > there endian issues here? Best to make the data type make that clear. > > The other approach is, as MVS and VM have both done over the years, to > provide feature bitmaps. But that's another can o' worms. > > Sorry for a wordy first post on a minor topic. Mostly I'm just reading > and catching up. > > Tony H. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
