VM_VERSION triplet

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

VM_VERSION triplet

stes
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


An interesting side-effect of David Lewis's update of the subversion repo,
was that I observed that the new VM is called :

4.19.2-3790    and 4.19.2-3790_64bit

The subversion source code seems to be generated from the VMMaker 4.19.2,
and this automatically sets VM_VERSION to 4.19.2 :

The code in the configure script that is doing this:

vmmversion="`tr '\015 ' '\012\012' < \"${interp_h}\" | sed '1,/VMMaker/d;q'`"

VM_VERSION="${vmmversion}-${svnversion}${RELEASE_TAG}"

So it automatically creates a 3 digit version with the subversion 3790 suffix,
based on the SVN version and the VMMaker version.

The subversion version number is 3790 so far is clear, but the VM version
seems to be set by the above code now to "4.19.2".

For the Solaris IPS COMPONENT_VERSION I had a number 4.16.7
and I updated it to the new COMPONENT_VERSION= 4.19.2 .

For the squeak-5 Git OpenSmalltalk VM I would also like to use a 3 digit
version number that makes some sense.

Currently I create 3 digit numbers myself (without any relationship to squeak).

However I was thinking that maybe I can use:

   5.0.x  where x is the VMMaker version number.

It appears that nowadays the VMmaker is called VMMaker.oscog-eem.2887

So I could use the number 2887 in 5.0.2887 where 2887 is the VMMaker number.

This relates to my question a few months ago as to the #define

platforms/Cross/vm/sqVirtualMachine.h:# define VM_VERSION "5.0"

which in my understanding sets the VM_VERSION of all  VM's to "5.0".

An issue could be that the "stack" VM and the "cog" VM actually seem to use,
different VMmaker numbers.

For example currently for the "stack" VM the VMmaker number is 2885.

For the "cog" VM the VMmaker number is 2891.

So they are slightly different.

I guess that what I wonder is whether it makes sense to use version numbers,

        5.0.x
        5.0.2885
        5.0.2891

where x= VMmaker release number following Eliot Miranda's VMmaker release.

Is there an established triplet 3digit release number for OpenSmalltalk ??

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJft9m+AAoJEAwpOKXMq1MaNnEIALdzkb00VEQ/XHn+F/8G37tE
EteNRCQtIawigsUn+aSh+OLX0NbTOyyzCbHh2ihqWFMyIvdisT9SP9FlRUzXryBR
gW14p3xgHoLot2sGChXDro6ZLYsaRVDsnJVuzFTBuyClwlK4HwJXvJdOsEP3TMo4
Nr8w0ldX4hDpoNvil0d/K/uxJ8Cg1XENQ4ECv0DEUv3qMgJeOynDyqRbOWRqym9e
Gc+Bya71kKYrWLHI7/ekxO0I99p6YGYXMb+sjxM+xCY9IIxm0Lcq5IjLNEPwvvpX
nHp1U4n9BUYc40P+Cja9m2+olI0uTix/+FzmGM3G/biqbIIf3u+B5qg97gr3z5g=
=eFQV
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: VM_VERSION triplet

Eliot Miranda-2
 
Hi David,

On Fri, Nov 20, 2020 at 7:00 AM [hidden email] <[hidden email]> wrote:
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


An interesting side-effect of David Lewis's update of the subversion repo,
was that I observed that the new VM is called :

4.19.2-3790    and      4.19.2-3790_64bit

The subversion source code seems to be generated from the VMMaker 4.19.2,
and this automatically sets VM_VERSION to 4.19.2 :

The code in the configure script that is doing this:

vmmversion="`tr '\015 ' '\012\012' < \"${interp_h}\" | sed '1,/VMMaker/d;q'`"

VM_VERSION="${vmmversion}-${svnversion}${RELEASE_TAG}"

So it automatically creates a 3 digit version with the subversion 3790 suffix,
based on the SVN version and the VMMaker version.

The subversion version number is 3790 so far is clear, but the VM version
seems to be set by the above code now to "4.19.2".

For the Solaris IPS COMPONENT_VERSION I had a number 4.16.7
and I updated it to the new COMPONENT_VERSION= 4.19.2 .

For the squeak-5 Git OpenSmalltalk VM I would also like to use a 3 digit
version number that makes some sense.

Currently I create 3 digit numbers myself (without any relationship to squeak).

However I was thinking that maybe I can use:

   5.0.x  where x is the VMMaker version number.

It appears that nowadays the VMmaker is called VMMaker.oscog-eem.2887

So I could use the number 2887 in 5.0.2887 where 2887 is the VMMaker number.

This relates to my question a few months ago as to the #define

platforms/Cross/vm/sqVirtualMachine.h:# define VM_VERSION "5.0"

which in my understanding sets the VM_VERSION of all  VM's to "5.0".

An issue could be that the "stack" VM and the "cog" VM actually seem to use,
different VMmaker numbers.

For example currently for the "stack" VM the VMmaker number is 2885.

For the "cog" VM the VMmaker number is 2891.

That's right.  The sources are generated from a particular version of VMMaker and not all sources change.  So if I make a change that only affects the Cog VM's interpreter the StackInterperteer VMs will not get generated.  The situation is more varied in src/plugins.  Look at the range of version numbers in there and you'll see a broad spread.  We don't want to regenerate code every time if it doesn't change.

So they are slightly different.

I guess that what I wonder is whether it makes sense to use version numbers,

        5.0.x
        5.0.2885
        5.0.2891

where x= VMmaker release number following Eliot Miranda's VMmaker release.

Well, that would be nice.  But the effort of incrementing the version number is very hard.  I prefer to leave it as vm -version providing the full verison info, the VMMaker versions for interpreter and cogit (and for all plugins), and the git commit for opensmalltalk-vm.  The basic version number could be incremented if the build system did it automatically but I would forget all the time.


Is there an established triplet 3digit release number for OpenSmalltalk ??

No.

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJft9m+AAoJEAwpOKXMq1MaNnEIALdzkb00VEQ/XHn+F/8G37tE
EteNRCQtIawigsUn+aSh+OLX0NbTOyyzCbHh2ihqWFMyIvdisT9SP9FlRUzXryBR
gW14p3xgHoLot2sGChXDro6ZLYsaRVDsnJVuzFTBuyClwlK4HwJXvJdOsEP3TMo4
Nr8w0ldX4hDpoNvil0d/K/uxJ8Cg1XENQ4ECv0DEUv3qMgJeOynDyqRbOWRqym9e
Gc+Bya71kKYrWLHI7/ekxO0I99p6YGYXMb+sjxM+xCY9IIxm0Lcq5IjLNEPwvvpX
nHp1U4n9BUYc40P+Cja9m2+olI0uTix/+FzmGM3G/biqbIIf3u+B5qg97gr3z5g=
=eFQV
-----END PGP SIGNATURE-----


--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: VM_VERSION triplet

David T. Lewis
In reply to this post by stes
 
Hi David,

Eliot replied with respect to the oscog VMs, so let me just add a note
regarding the older "interpreter VM" virtual machines.

On Fri, Nov 20, 2020 at 04:00:26PM +0100, [hidden email] wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> An interesting side-effect of David Lewis's update of the subversion repo,
> was that I observed that the new VM is called :
>
> 4.19.2-3790    and 4.19.2-3790_64bit

The "64bit" here refers to the 64-bit image format, and is unrelated to
the 32/64 bit-ness of the VM executable. The 64-bit image was never in
wide circulation, but the VM for running that image format is available
and is installed with "_64bit" suffix to distinguish it from the executable
VM (32 or 64 bit) for the standard 32-bit V3 images.

>
> The subversion source code seems to be generated from the VMMaker 4.19.2,
> and this automatically sets VM_VERSION to 4.19.2 :
>
> The code in the configure script that is doing this:
>
> vmmversion="`tr '\015 ' '\012\012' < \"${interp_h}\" | sed '1,/VMMaker/d;q'`"
>
> VM_VERSION="${vmmversion}-${svnversion}${RELEASE_TAG}"
>
> So it automatically creates a 3 digit version with the subversion 3790 suffix,
> based on the SVN version and the VMMaker version.
>
> The subversion version number is 3790 so far is clear, but the VM version
> seems to be set by the above code now to "4.19.2".
>

This is just a naming convention to identify the VM executable. It is not
intended to be exact, but it shows you the version level of the Smalltalk
VM sources (VMMaker versionString ==> '4.19.2') and it shows you the revision
level of the platforms sources (svn info | grep Revision).

In practice this works well as an identifier for the VM, but it is important
to recognize that it has nothing to do with the version of the Squeak image.
One version of a VM is expected to be able to run many versions of the image,
and one image should be able to run on many different VMs.

As an example, suppose that you have a 4.19.2-3790 VM installed on your
computer, and suppose that you are running an application based on the
Squeak1.23.image (which was released back in October 1997). If you wanted
to provide a version identifier for your application, you might want to
base it on the 1.23 image version number, but you would not want to base
it on the version number of a VM that was built over 20 years later.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: VM_VERSION triplet

stes
In reply to this post by stes
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


I understand that the VM version has no relation to the Squeak image
(the version of the Smalltalk image file).

However there is a relation between the VM version and the VMmaker used to
generate the files in the OpenSmalltalk repository.

If I understand correctly it is in fact good style to use VMmaker yourself,
to create one's own set of sources.

For the moment I just checkout the Git sources but those are created by VMmaker
(the output of VMmaker) so it makes sense to use VMmaker instead yourself.

Anyway sorry for the noise on this list ...

Regards,
David Stes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJfuOlaAAoJEAwpOKXMq1MagXkIAJECTigop3kerEXpZznvPbQX
H3QrlUn+RChcWBOegShfO1qVAD273UMGhvgI6y2bJb36kOWx+KTsGdhE8JF1yHjM
lL5+k24xDekEjl/HGtyhhA5YagqdLJo4H+BD/GfFe/IQqur698+duS2ACtRuCQpa
U/H59nJbYO9kWNxZg4lq1jXUEyv26DPczk+gYufDFGFpL3cNudRpdqngnUiCQBnj
b04JL0TuJUcfaB7L+MBp66tSOd3HsAxHHrvkqEdWqM22OkwqqHIRW12xqFlGnYr5
P5Jzo/NHrXjutrMnVm5+1gxO1LipdY98I7Q5UtKz/oPsomkS67aF7J8ETXUYb+c=
=LM/2
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: VM_VERSION triplet

David T. Lewis
 
Hi David,

On Sat, Nov 21, 2020 at 11:18:46AM +0100, [hidden email] wrote:
>
> I understand that the VM version has no relation to the Squeak image
> (the version of the Smalltalk image file).
>
> However there is a relation between the VM version and the VMmaker used to
> generate the files in the OpenSmalltalk repository.
>

Yes. And just to be clear, in the case of the interpreter VM it would
be the squeakvm.org Subversion repository. There is a very out date copy
of those sources in the OpenSmalltalk repository, which is useful as
a convenient reference, but please don't use it to build a VM.

> If I understand correctly it is in fact good style to use VMmaker yourself,
> to create one's own set of sources.
>

I don't know if it's any better or worse as a policy, but I would
certainly encourage you to do it if you have an interest.

For an opensmalltalk to use with the latest Squeak images, follow
the instructions and use the scripts in opensmalltalk-vm/image/ to
make an up to date VMMaker image. That image will have open workspaces
that explain how to generate the code (and many other things of
interest, well worth a look).

For an interpreter VM, follow the instructions for "How to build a
standard VM with Squeak on Linux" at http://wiki.squeak.org/squeak/6177.
This gives step by step instructions for the process.

> For the moment I just checkout the Git sources but those are created by VMmaker
> (the output of VMmaker) so it makes sense to use VMmaker instead yourself.
>

Either way is fine. The advantage of checking out the sources
from git or subversion is that it is easy, and you are working with
a known good set of sources. But if you are interested in doing
the code generation yourself I would certainly encourage you to
give it a try.

> Anyway sorry for the noise on this list ...
>

Not at all!!! Thanks for asking.

Dave