[Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

The intent of this feature is to gather up all of the disparate pieces of information that might effect the interpretation of a program and put them in one place. This will be a combination of Rexx language information and some platform-specific information. The object will be available in the en

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Decided to also add majorVersion, release, and revision values to this to return the pieces of the version number. Rick On Sun, Sep 28, 2014 at 7:35 AM, Rick McGuire wrote: > The intent of this feature is to gather up all of the disparate pieces of > information that might effect the interpreta

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

> > directoryseparator -- same value returned by .File~separator Rick, above isn't yet implemented (REXX-ooRexx_5.0.0(MT)_64-bit 6.05 9 Oct 2014) On Sun, Sep 28, 2014 at 3:18 PM, Rick McGuire wrote: > Decided to also add majorVersion, release, and revision values to this to > return the pieces

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Oops, the method was implemented but I missed adding to the method table. Its in now. Rick On Thu, Oct 9, 2014 at 5:39 AM, Erich Steinböck wrote: > directoryseparator -- same value returned by .File~separator > > > Rick, above isn't yet implemented (REXX-ooRexx_5.0.0(MT)_64-bit 6.05 9 Oct > 2

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Just committed RexxRef documentation for RexxInfo class (and environment variable). A local RexxRef build is available in sandbox/erich/docs/build for anyone interested. Two questions: 1. > Also not sure I like the "ar

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

On Wed, May 27, 2015 at 5:58 PM, Erich Steinböck wrote: > Just committed RexxRef documentation for RexxInfo class (and environment > variable). > A local RexxRef build is available in sandbox/erich/docs/build > > for an

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Hi Erich, The Docs look good. I also think 'architecture' is not intuitive. I'm happy with 'wordsize', although I often hear 'bitness'. On the same subject, I think the 'date' attribute needs qualifying. I think that replacing .rexxInfo~date with .rexxInfo~buildDate would read a lot more clear

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

I also think 'architecture' is not intuitive. I'm happy with 'wordsize', although I often hear 'bitness'. On the same subject, I think the 'date' attribute needs qualifying. I think that replacing .rexxInfo~date with .rexxInfo~buildDate would read a lot more clearly. I'd advise against

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

> > 2) Also not sure I like the "architecture" name, since this is not really a > hardware architecture. Address size? Another possibility is memory model, there could be different operand sizes than address sizes, like some JVMs do. > > 3) An actual hardware architecture one might be nice

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Big Endian is also known as network order in some contexts, but the network order usage does seem to include a term for "non-network order". Rick On Fri, May 29, 2015 at 7:06 AM, René Jansen wrote: > > > > 2) Also not sure I like the "architecture" name, since this is not > really a hardware

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

But network order does not ring as relevant in my ears for this particular usage. Thinking along lines of memory model, you once faced the decision of having a 64 or 32 bit size for Rexx objects, and I remember the discussion on the list in which we (iirc) all were in favor of 64 bitness and di

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

On Thu, Jun 4, 2015 at 10:34 AM, René Jansen wrote: > But network order does not ring as relevant in my ears for this particular > usage. > > Thinking along lines of memory model, you once faced the decision of > having a 64 or 32 bit size for Rexx objects, and I remember the discussion > on the

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

> > majorVersion, release, and revision value > As far as I can see IBM terminology is version.release.modification (plus fix). I propose - changing the current "revision" to "modification" and - use "revision" for the source-control revision (currently SVN revision) On Sun, Sep 28, 2014

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

Strongly agree ! Enrico > On 21 Dec 2018, at 23:15, Erich Steinböck wrote: > > majorVersion, release, and revision value > As far as I can see IBM terminology is version.release.modification (plus > fix). > I propose > changing the current "revision" to "modification" and > use "revision" for

Re: [Oorexx-devel] DISCUSS: #618 Add a class that contains methods for retrieving interpreter information.

I think I agree too. In the CMake files, we consistently refer to the third digit as the "MOD_LVL". Rick On Fri, Dec 21, 2018 at 5:16 PM Erich Steinböck wrote: > majorVersion, release, and revision value >> > As far as I can see IBM terminology is version.release.modification (plus > fix). > I