VM_VERSION triplet
Locked
 
|
-----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----- |
|
|
Hi David,
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.
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.
No.
_,,,^..^,,,_ best, Eliot |
|
|
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 |
|
|
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----- |
|
|
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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |