About VM version string
Locked
 
|
Hello, i'd like to know what we can do to clean up the mess with Cog VM versioning, so people could identify it more easily. Currently , what Smalltalk vmVersion shows is: Smalltalk vmVersion 'Croquet Closure Stack VM [StackInterpreter VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' but it doesn't says anything about which version of platform sources are used to build it. Also, a version number VM 4.0.0 makes no sense.. I'd really like to see what we can do to improve it. -- Best regards, Igor Stasenko AKA sig. |
Re: About VM version string
|
|
I think this depends on who is the #vmVersion inteded for. For example, if it is for users, then I would expect to get something like Cog 1.4 Cog 2.5 I mean...who care what VMMaker/PlatformCode was used? The user may not even be aware of that. Now, if it is intended for VM developers, where they need such information for a bug for example, then I think that yes, both things are important: VMMaker version and platoform code. For me, just version of VMMaker is not enough. I'd rather put the COnfigutaionOfCog version...which has no only the VMMaker version, but also the version of all its dependencies. In addition, I would put the SVN version (in case the platform code come from SVN) or GIT commit hash. Cheers Mariano On Tue, Apr 12, 2011 at 12:53 PM, Igor Stasenko <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Igor Stasenko
On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: > > Hello, > > i'd like to know what we can do to clean up the mess with Cog VM > versioning, so people could identify it more easily. > > Currently , what > > Smalltalk vmVersion shows is: > > Smalltalk vmVersion > > 'Croquet Closure Stack VM [StackInterpreter > VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' > > but it doesn't says anything about which version of platform sources > are used to build it. > Also, a version number VM 4.0.0 makes no sense.. > > I'd really like to see what we can do to improve it. VMMaker class>>versionString is an ad-hoc identifier that I (and hopefully others) update whenever making a functional update to the VMMaker package. It is intended for two purposes: 1) Provide an approximate identification of the Smalltalk sources (VMMaker plus plugins) used to create a VM. 2) Supply an identifier that becomes part of the VM name. On a unix installation, this forms part of the name of the subdirectory in which the VM in installed. My recommendation: In the oscog branch now, and ultimately in the merged code base whenever we get there, adopt a similar #versionString convention and get in the habit of updating it somewhat regularly. In the near term, the names should not conflict with those used for the VMMaker trunk (to avoid confusion especially in the installation directory targets). It may be helpful for clarity to add a one-character suffix to the version string to identify a cog interpreter. Thus if the version string for a standard interpreter is '1.2.3' then a cog VM could identify itself as '1.2.3c' for example. Note that this is also important for 64 bit versus 32 bit interpreter VMs (i.e. interpreter for 64 bit object memory), so IMO it is a good thing to waste some disk space on installation directories such that different flavors of VM can clearly live in their own subdirectories. The other half of the equation is the version number for the platform sources. For the standard unix build, Ian has incorporated the current Subversion number (derived at compile time) with the VMMaker version string (generated at slang generation time) into a version identifier for the VM, which in turn is used to create the subdirectory name for the installation. Hopefully there is some similar mechanism that could be done for the git mirror and CMMakeVMMaker builds (although I do not know enough to suggest how to do it). The mechanism I am describing here is not very sophisticated, but it's simple and has worked well in practice, so if there is a way to do something similar with oscog VMMaker and the git/CMake builds, I think that would be quite helpful. Dave |
|
|
In reply to this post by Igor Stasenko
On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: > > Hello, > > i'd like to know what we can do to clean up the mess with Cog VM > versioning, so people could identify it more easily. > > Currently , what > > Smalltalk vmVersion shows is: > > Smalltalk vmVersion > > 'Croquet Closure Stack VM [StackInterpreter > VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' > > but it doesn't says anything about which version of platform sources > are used to build it. > Also, a version number VM 4.0.0 makes no sense.. > > I'd really like to see what we can do to improve it. (this may be a duplicate response, I'm having mail problems today) The mechanism used in the standard VMMaker and Unix platform sources works well in practice. This uses VMMaker class>>versionString to identify the (approximate) version of Smalltalk sources, combined with the Subversion revision number identified at compile time. For the VMMaker side, I'd suggest adopting a similar (manually maintained) convention for #versionString, but also add a suffix to identify a cog VM versus interpreter VM. Thus if the versionString is '1.2.3' the Cog VM might use '1.2.3c'. The suffix identifier is helpful in the near term for maintaining separate installation directories on unix, and possibly becomes irrelevant whenever we get the code bases merged. For the platforms sources on the git mirror with CMMakerVMMaker build, some mechanism would be needed to identify version level. Ian's build procedure on unix with Subversion works well for this, but I don't know how to do the equivalent on the git mirror. But I'm not really familiar with git, so hopefully someone can suggest something here. Dave |
|
|
In reply to this post by David T. Lewis
Thanks for information, David. Indeed, the version numbers like 'x.y.z' are mainly for users, but not for developers. As a developer, you may want to uniquely identify the exact build environment, including platform sources, vmmaker (and dependencies) and configuration used to build it. What are primitives in VM , which could give a wide information about what VM is used. The problem here is that i could build different flavors of VM , based on configuration used for instance here, what i put into CMakeLists.txt file header: # This is automatically generated file using CogMacOSConfig on 12 April 2011 1:30:26 pm So, for instance, if i build debug version of VM, how we can reflect that somewhere, so people could see what VM is running. This thing gets complicated. Git are not using numeric revision numbers , since it makes no sense in distributed development model. Git using hashes to identify commits. So, i wonder what would be good approach to organize this mess. What i thinking that might be, we should have two (or maybe 3) different version infos in VM. The most short one is 'versionString' , which are just x.y.z version number and VM name (and maybe build date). Another is 'versionInfo' which could contain a more detailed information about VM, like MC package versions etc etc. I am not sure about it, that's why i asking. On 12 April 2011 13:34, David T. Lewis <[hidden email]> wrote: > > On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: >> >> Hello, >> >> i'd like to know what we can do to clean up the mess with Cog VM >> versioning, so people could identify it more easily. >> >> Currently , what >> >> Smalltalk vmVersion shows is: >> >> Smalltalk vmVersion >> >> 'Croquet Closure Stack VM [StackInterpreter >> VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' >> >> but it doesn't says anything about which version of platform sources >> are used to build it. >> Also, a version number VM 4.0.0 makes no sense.. >> >> I'd really like to see what we can do to improve it. > > VMMaker class>>versionString is an ad-hoc identifier that I (and > hopefully others) update whenever making a functional update to > the VMMaker package. It is intended for two purposes: > > 1) Provide an approximate identification of the Smalltalk sources > (VMMaker plus plugins) used to create a VM. > > 2) Supply an identifier that becomes part of the VM name. On a > unix installation, this forms part of the name of the subdirectory > in which the VM in installed. > > My recommendation: > > In the oscog branch now, and ultimately in the merged code base > whenever we get there, adopt a similar #versionString convention > and get in the habit of updating it somewhat regularly. In the > near term, the names should not conflict with those used for the > VMMaker trunk (to avoid confusion especially in the installation > directory targets). > > It may be helpful for clarity to add a one-character suffix to the > version string to identify a cog interpreter. Thus if the version > string for a standard interpreter is '1.2.3' then a cog VM could > identify itself as '1.2.3c' for example. Note that this is also > important for 64 bit versus 32 bit interpreter VMs (i.e. interpreter > for 64 bit object memory), so IMO it is a good thing to waste > some disk space on installation directories such that different > flavors of VM can clearly live in their own subdirectories. > > The other half of the equation is the version number for the > platform sources. For the standard unix build, Ian has incorporated > the current Subversion number (derived at compile time) with > the VMMaker version string (generated at slang generation time) > into a version identifier for the VM, which in turn is used > to create the subdirectory name for the installation. Hopefully > there is some similar mechanism that could be done for the > git mirror and CMMakeVMMaker builds (although I do not know > enough to suggest how to do it). > > The mechanism I am describing here is not very sophisticated, > but it's simple and has worked well in practice, so if there > is a way to do something similar with oscog VMMaker and the > git/CMake builds, I think that would be quite helpful. > > Dave > > -- Best regards, Igor Stasenko AKA sig. |
Re: About VM version string
|
|
In reply to this post by David T. Lewis
On Tue, Apr 12, 2011 at 1:58 PM, David T. Lewis <[hidden email]> wrote:
For SVN you have the versions. Let say 2023. In Git, each commit has a commit hash, which looks something like: f3fe94c828f66cd0e7c37cfa3434e384ff65915e You can look at them throught gitorious or by doing "git log". Example: ;-) /usr/local/git/bin/git log commit f3fe94c828f66cd0e7c37cfa3434e384ff65915e Merge: 1af7478 f123973 Author: Esteban Lorenzano <[hidden email]> Date: Mon Apr 4 08:46:21 2011 -0300 Merge branch 'master' of gitorious.org:cogvm/blessed into integration commit f1239738a1f14f6f067465e71dc24fd84f5a041e Author: Igor Stasenko <[hidden email]> Date: Mon Apr 4 12:49:55 2011 +0200 Merge branch 'master' of gitorious.org:cogvm/blessed into svn-merge Conflicts: image/VMMaker-Squeak4.1.changes platforms/iOS/vm/iPhone/iPhone.image platforms/unix/vm/sqUnixMain.c platforms/win32/vm/sqWin32Window.c src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c src/plugins/HostWindowPlugin/HostWindowPlugin.c src/plugins/SoundGenerationPlugin/SoundGenerationPlugin.c src/plugins/SoundPlugin/SoundPlugin.c src/plugins/SqueakFFIPrims/SqueakFFIPrims.c src/vm/cointerp.c src/vm/cointerp.h src/vm/gcc3x-cointerp.c commit 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 Author: Esteban Lorenzano <[hidden email]> Date: Sun Apr 3 09:09:20 2011 -0300 added LocalePlugin However, only the 4 first characters are usually enough to specify a version. So for example in Git you can do: git checkout 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 or git checkout 1af7 So...we can have the same as the SVN if we want. Cheers -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Igor Stasenko
Yes, I agree the detailed information needs to be something separate from the version string. I think that Eliot added some useful hooks to identify detailed version of sources with UUID strings (sorry I am away and cannot check on where I saw this). Possible this will be of some help. I'd like to keep the VMMaker class>>versionString restricted to answering strings of the form '1.2.3' or '1.2.3x' for consistency with existing practice. Note that the implementation in oscog is something left over from ancient history, so this should be changed, maybe starting fresh with '5.1.1c' and start incrementing it to '5.1.2c', '5.1.3c' ... where the 'c' implies cog? I don't know how to come up with a short "platform version" number for git similar to the Subversion revision number, but perhaps just adopting manual process (i.e. edit a text file) would be good enough for starters. $0.02, Dave On Tue, Apr 12, 2011 at 02:20:15PM +0200, Igor Stasenko wrote: > > Thanks for information, David. > > Indeed, the version numbers like 'x.y.z' are mainly for users, > but not for developers. > As a developer, you may want to uniquely identify the exact build > environment, including > platform sources, vmmaker (and dependencies) and configuration used to build it. > > What are primitives in VM , which could give a wide information about > what VM is used. > > The problem here is that i could build different flavors of VM , based > on configuration used > > for instance here, what i put into CMakeLists.txt file header: > > # This is automatically generated file using CogMacOSConfig on 12 > April 2011 1:30:26 pm > > So, for instance, if i build debug version of VM, how we can reflect > that somewhere, > so people could see what VM is running. > > This thing gets complicated. > > Git are not using numeric revision numbers , since it makes no sense > in distributed development model. > Git using hashes to identify commits. > > So, i wonder what would be good approach to organize this mess. > What i thinking that might be, we should have two (or maybe 3) > different version infos in VM. > > The most short one is 'versionString' , which are just x.y.z version > number and VM name (and maybe build date). > > Another is 'versionInfo' which could contain a more detailed > information about VM, like MC package versions etc etc. > > I am not sure about it, that's why i asking. > > > On 12 April 2011 13:34, David T. Lewis <[hidden email]> wrote: > > > > On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: > >> > >> Hello, > >> > >> i'd like to know what we can do to clean up the mess with Cog VM > >> versioning, so people could identify it more easily. > >> > >> Currently , what > >> > >> Smalltalk vmVersion shows is: > >> > >> Smalltalk vmVersion > >> > >> ??'Croquet Closure Stack VM [StackInterpreter > >> VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' > >> > >> but it doesn't says anything about which version of platform sources > >> are used to build it. > >> Also, a version number VM 4.0.0 makes no sense.. > >> > >> I'd really like to see what we can do to improve it. > > > > VMMaker class>>versionString is an ad-hoc identifier that I (and > > hopefully others) update whenever making a functional update to > > the VMMaker package. It is intended for two purposes: > > > > 1) Provide an approximate identification of the Smalltalk sources > > (VMMaker plus plugins) used to create a VM. > > > > 2) Supply an identifier that becomes part of the VM name. On a > > unix installation, this forms part of the name of the subdirectory > > in which the VM in installed. > > > > My recommendation: > > > > In the oscog branch now, and ultimately in the merged code base > > whenever we get there, adopt a similar #versionString convention > > and get in the habit of updating it somewhat regularly. In the > > near term, the names should not conflict with those used for the > > VMMaker trunk (to avoid confusion especially in the installation > > directory targets). > > > > It may be helpful for clarity to add a one-character suffix to the > > version string to identify a cog interpreter. Thus if the version > > string for a standard interpreter is '1.2.3' then a cog VM could > > identify itself as '1.2.3c' for example. Note that this is also > > important for 64 bit versus 32 bit interpreter VMs (i.e. interpreter > > for 64 bit object memory), so IMO it is a good thing to waste > > some disk space on installation directories such that different > > flavors of VM can clearly live in their own subdirectories. > > > > The other half of the equation is the version number for the > > platform sources. For the standard unix build, Ian has incorporated > > the current Subversion number (derived at compile time) with > > the VMMaker version string (generated at slang generation time) > > into a version identifier for the VM, which in turn is used > > to create the subdirectory name for the installation. Hopefully > > there is some similar mechanism that could be done for the > > git mirror and CMMakeVMMaker builds (although I do not know > > enough to suggest how to do it). > > > > The mechanism I am describing here is not very sophisticated, > > but it's simple and has worked well in practice, so if there > > is a way to do something similar with oscog VMMaker and the > > git/CMake builds, I think that would be quite helpful. > > > > Dave > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. |
|
|
In reply to this post by Mariano Martinez Peck
On Tue, Apr 12, 2011 at 05:32:17PM +0200, Mariano Martinez Peck wrote: > > On Tue, Apr 12, 2011 at 1:58 PM, David T. Lewis <[hidden email]> wrote: > > > > For the platforms sources on the git mirror with CMMakerVMMaker > > build, some mechanism would be needed to identify version level. > > Ian's build procedure on unix with Subversion works well for > > this, but I don't know how to do the equivalent on the git > > mirror. But I'm not really familiar with git, so hopefully > > someone can suggest something here. > > > > > For SVN you have the versions. Let say 2023. In Git, each commit has a > commit hash, which looks something like: > f3fe94c828f66cd0e7c37cfa3434e384ff65915e > You can look at them throught gitorious or by doing "git log". Example: > > ;-) /usr/local/git/bin/git log > commit f3fe94c828f66cd0e7c37cfa3434e384ff65915e > Merge: 1af7478 f123973 > Author: Esteban Lorenzano <[hidden email]> > Date: Mon Apr 4 08:46:21 2011 -0300 > > Merge branch 'master' of gitorious.org:cogvm/blessed into integration > > commit f1239738a1f14f6f067465e71dc24fd84f5a041e > Author: Igor Stasenko <[hidden email]> > Date: Mon Apr 4 12:49:55 2011 +0200 > > Merge branch 'master' of gitorious.org:cogvm/blessed into svn-merge > > Conflicts: > image/VMMaker-Squeak4.1.changes > platforms/iOS/vm/iPhone/iPhone.image > platforms/unix/vm/sqUnixMain.c > platforms/win32/vm/sqWin32Window.c > src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c > src/plugins/HostWindowPlugin/HostWindowPlugin.c > src/plugins/SoundGenerationPlugin/SoundGenerationPlugin.c > src/plugins/SoundPlugin/SoundPlugin.c > src/plugins/SqueakFFIPrims/SqueakFFIPrims.c > src/vm/cointerp.c > src/vm/cointerp.h > src/vm/gcc3x-cointerp.c > > commit 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 > Author: Esteban Lorenzano <[hidden email]> > Date: Sun Apr 3 09:09:20 2011 -0300 > > added LocalePlugin > > > > > However, only the 4 first characters are usually enough to specify a > version. So for example in Git you can do: > > git checkout 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 > > or > > git checkout 1af7 > > So...we can have the same as the SVN if we want. > Great - thank you! I was hoping somebody would know how to do this. Dave |
Re: About VM version string
|
|
On Tue, Apr 12, 2011 at 5:47 PM, David T. Lewis <[hidden email]> wrote:
hehehehe I have to learn it this weekend for my blog post...I wanted the post instructions to be totally reproducible and I didn't know how to do this in Git...after googling for a long time, I understood that ;) -- Mariano http://marianopeck.wordpress.com |
Re: About VM version string
|
|
In reply to this post by Igor Stasenko
On Tue, Apr 12, 2011 at 2:20 PM, Igor Stasenko <[hidden email]> wrote:
Yes, this make sense for me. I would put: MetacelloConfiguration version + git commit hash + the CMake Configuation class name used. Example: CMakeVMMaker class: MTCocoaIOSCogJitDebugConfig. ConfigurationOfCog version: '1.6'. Gitorious CogVM blessed commit hash: f3fe94c828f66cd0e7c37cfa3434e384ff65915e Image where sources where generated: PharoCore.xxx And I think that's is even more than what you need :) Cheers Mariano I am not sure about it, that's why i asking. -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by David T. Lewis
On 12.04.2011, at 17:47, David T. Lewis wrote: > On Tue, Apr 12, 2011 at 05:32:17PM +0200, Mariano Martinez Peck wrote: >> >> On Tue, Apr 12, 2011 at 1:58 PM, David T. Lewis <[hidden email]> wrote: >>> >>> For the platforms sources on the git mirror with CMMakerVMMaker >>> build, some mechanism would be needed to identify version level. >>> Ian's build procedure on unix with Subversion works well for >>> this, but I don't know how to do the equivalent on the git >>> mirror. But I'm not really familiar with git, so hopefully >>> someone can suggest something here. >>> >>> >> For SVN you have the versions. Let say 2023. In Git, each commit has a >> commit hash, which looks something like: >> f3fe94c828f66cd0e7c37cfa3434e384ff65915e >> >> However, only the 4 first characters are usually enough to specify a >> version. So for example in Git you can do: >> >> git checkout 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 >> >> or >> >> git checkout 1af7 >> >> So...we can have the same as the SVN if we want. >> > > Great - thank you! I was hoping somebody would know how to do this. > > Dave While a few digits work fine interactively, you would have to use the full hash to uniquely identify a version. - Bert - |
|
|
In reply to this post by David T. Lewis
Hi: On 12 Apr 2011, at 17:45, David T. Lewis wrote: > > Yes, I agree the detailed information needs to be something separate > from the version string. I think that Eliot added some useful hooks > to identify detailed version of sources with UUID strings (sorry I > am away and cannot check on where I saw this). Possible this will > be of some help. Including meta infos is indeed very helpful, especially when I need to identify a binary after a few weeks and remember what the compilation settings were back then. The RoarVM uses the following, which works quite good for my purposes: https://github.com/smarr/RoarVM/commit/44c9669bc919937e9bdd26daf06b992be24e3189 That includes the git id of the current checkout, the path, compiler version, compilation host, and whether the code was compiled optimized. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
|
|
In reply to this post by Mariano Martinez Peck
On Tue, Apr 12, 2011 at 05:54:29PM +0200, Mariano Martinez Peck wrote: > On Tue, Apr 12, 2011 at 5:47 PM, David T. Lewis <[hidden email]> wrote: > > > > On Tue, Apr 12, 2011 at 05:32:17PM +0200, Mariano Martinez Peck wrote: > > > > > > However, only the 4 first characters are usually enough to specify a > > > version. So for example in Git you can do: > > > > > > git checkout 1af7478875b2d534c3b6cdc89d8244ff3ea4ec65 > > > > > > or > > > > > > git checkout 1af7 > > > > > > So...we can have the same as the SVN if we want. > > > > > > > Great - thank you! I was hoping somebody would know how to do this. > > > > > > hehehehe I have to learn it this weekend for my blog post...I wanted the > post instructions to be totally reproducible and I didn't know how to do > this in Git...after googling for a long time, I understood that ;) Very nice blog post by the way :) Dave |
|
|
In reply to this post by David T. Lewis
On Tue, Apr 12, 2011 at 4:58 AM, David T. Lewis <[hidden email]> wrote:
I disagree. I think its terrible. It requires manual updating and hence is essentially meaningless. The solution in Cog is to include the VMMaker version along with its UUID, prefixed with an asterisk if the package is modified (matching the Monticello UI's display of dirty packages). This tells one exactly which sources were used to generate the VM. Here's an extract from oscog's src/vm/cointerp.c:
/* Automatically generated by CCodeGeneratorGlobalStructure VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 from CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7
*/ static char __buildInfo[] = "CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 " __DATE__ ; char *__interpBuildInfo = __buildInfo;
And hence (1000 to: 1100) select: [:i| (Smalltalk getSystemAttribute: i) notNil] thenCollect: [:i| i -> (Smalltalk getSystemAttribute: i)] { 1001->'Mac OS' .
1002->'1067' . 1003->'intel' . 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54] Croquet Cog 3.0.0' .
1005->'Aqua' . 1006->'Mac OS X built on Mar 31 2011 17:23:52 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)' .
1007->'CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011' . 1008->'StackToRegisterMappingCogit VMMaker-oscog.51 uuid: d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr 1 2011'}
Now this could be improved upon by also including the uuid for the VMMaker package in parameter 1004.
This is useless. Manual versioning is essentially arbitrary and very easy to overlook. We have accurate version information in the Monticello package version and, given the UUID and the dirty mark convention, provides concise and precise info. IMO its the obvious solution.
However, the platform sources are more problematic. One huge irritation with svn is that it doesn't provide a way of including the revision number in source since revision numbers are allocated after check-out. Instead one has to derive the revision number y running a command, e.g.
McStalker.oscogvm$ svnversion 2219:2378M McStalker.oscogvm$ svnversion | sed 's/^.*://' 2378M McStalker.oscogvm$ Which might work on unix systems but is a nightmare on Windows, and requires builders to use an up-to-date svn, and forces everyone to use svn.
I don't know what the conventions are in git, mercurial, cvs etc. I think we need to develop some convention which is along the lines of the platform build requiring the inclusion of some file that contains some precise version info, and providing e.g. options in the makefiles for generating there.
e.g. make platverforsvnunix svnversion ../platforms | sed 's/^.*:/#define PLATREV /' >platver.h svn info ../platforms | grep URL: | sed 's/^URL: \(.*\)$/#define PLAT_REP_URL "\1"/' >>platver.h
to produce #define PLATREV 2376 #define PLAT_REP_URL "http://www.squeakvm.org/svn/squeak/branches/Cog/platforms"
and then derive some system attribute from that, or include it in 1004, e.g. 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011, platform: 2376 http://www.squeakvm.org/svn/squeak/branches/Cog/platforms] Croquet Cog 3.0.0' .
We can then provide VMMaker and platforms info for any source code control system with a little bit of effort on the builder's behalf, semi-automated in that the makefiles can prompt (and provide help for) the builder to create e.g. platver.h correctly.
This kind of version info gives precise location for the sources and allows reproducible builds. The manually maintained version info is, frankly, a joke. HTH, Eliot
|
|
|
On Tue, Apr 12, 2011 at 10:14:07AM -0700, Eliot Miranda wrote: > > On Tue, Apr 12, 2011 at 4:58 AM, David T. Lewis <[hidden email]> wrote: > > > > > On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: > > > > > > Hello, > > > > > > i'd like to know what we can do to clean up the mess with Cog VM > > > versioning, so people could identify it more easily. > > > > > > Currently , what > > > > > > Smalltalk vmVersion shows is: > > > > > > Smalltalk vmVersion > > > > > > 'Croquet Closure Stack VM [StackInterpreter > > > VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' > > > > > > but it doesn't says anything about which version of platform sources > > > are used to build it. > > > Also, a version number VM 4.0.0 makes no sense.. > > > > > > I'd really like to see what we can do to improve it. > > > > (this may be a duplicate response, I'm having mail problems today) > > > > The mechanism used in the standard VMMaker and Unix platform sources > > works well in practice. This uses VMMaker class>>versionString to > > identify the (approximate) version of Smalltalk sources, combined > > with the Subversion revision number identified at compile time. > > > > I disagree. I think its terrible. It requires manual updating and hence is > essentially meaningless. We are talking about two different problems here. The purpose of the versionString and SVN tag is to give a simple label that can be used for "squeakvm -version" and to provide a name for the installation directory on unix systems. It is *not* intended to provide detailed version identification, and certainly would be a terrible approach if that had been the intent. Currently Cog on unix installs in a directory named for some three or four year old version of the standard interpreter VM, which is not a good thing (but maybe Igor has addressed this separately in CMakeVMMaker, I'm not sure). The UUID based identifications below are great, that was what I was trying to point Igor to in my separate email. I think that is an excellent way to make the detailed version information available. Dave > The solution in Cog is to include the VMMaker > version along with its UUID, prefixed with an asterisk if the package is > modified (matching the Monticello UI's display of dirty packages). This > tells one exactly which sources were used to generate the VM. Here's an > extract from oscog's src/vm/cointerp.c: > > /* Automatically generated by > CCodeGeneratorGlobalStructure VMMaker-oscog.54 uuid: > 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 > from > CoInterpreter VMMaker-oscog.54 uuid: > 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 > */ > static char __buildInfo[] = "CoInterpreter VMMaker-oscog.54 uuid: > 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 " __DATE__ ; > char *__interpBuildInfo = __buildInfo; > > And hence > (1000 to: 1100) select: [:i| (Smalltalk getSystemAttribute: i) notNil] > thenCollect: [:i| i -> (Smalltalk getSystemAttribute: i)] > { 1001->'Mac OS' . > 1002->'1067' . 1003->'intel' . > 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54] Croquet Cog > 3.0.0' . > 1005->'Aqua' . > 1006->'Mac OS X built on Mar 31 2011 17:23:52 Compiler: 4.2.1 (Apple Inc. > build 5666) (dot 3)' . > 1007->'CoInterpreter VMMaker-oscog.54 uuid: > 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011' . > 1008->'StackToRegisterMappingCogit VMMaker-oscog.51 uuid: > d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr 1 2011'} > > > Now this could be improved upon by also including the uuid for the VMMaker > package in parameter 1004. > > > > For the VMMaker side, I'd suggest adopting a similar (manually > > maintained) convention for #versionString, but also add a > > suffix to identify a cog VM versus interpreter VM. Thus if > > the versionString is '1.2.3' the Cog VM might use '1.2.3c'. > > The suffix identifier is helpful in the near term for maintaining > > separate installation directories on unix, and possibly becomes > > irrelevant whenever we get the code bases merged. > > > > This is useless. Manual versioning is essentially arbitrary and very easy > to overlook. We have accurate version information in the Monticello package > version and, given the UUID and the dirty mark convention, provides concise > and precise info. IMO its the obvious solution. > > However, the platform sources are more problematic. One huge irritation > with svn is that it doesn't provide a way of including the revision number > in source since revision numbers are allocated after check-out. Instead one > has to derive the revision number y running a command, e.g. > > McStalker.oscogvm$ svnversion > 2219:2378M > McStalker.oscogvm$ svnversion | sed 's/^.*://' > 2378M > McStalker.oscogvm$ > > Which might work on unix systems but is a nightmare on Windows, and requires > builders to use an up-to-date svn, and forces everyone to use svn. > > I don't know what the conventions are in git, mercurial, cvs etc. > > I think we need to develop some convention which is along the lines of the > platform build requiring the inclusion of some file that contains some > precise version info, and providing e.g. options in the makefiles for > generating there. > > e.g. make platverforsvnunix > svnversion ../platforms | sed 's/^.*:/#define PLATREV /' >platver.h > svn info ../platforms | grep URL: | sed 's/^URL: \(.*\)$/#define > PLAT_REP_URL "\1"/' >>platver.h > > to produce > #define PLATREV 2376 > #define PLAT_REP_URL " > http://www.squeakvm.org/svn/squeak/branches/Cog/platforms" > > and then derive some system attribute from that, or include it in 1004, e.g. > > 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54 > uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011, platform: 2376 > http://www.squeakvm.org/svn/squeak/branches/Cog/platforms] Croquet Cog > 3.0.0' . > > We can then provide VMMaker and platforms info for any source code control > system with a little bit of effort on the builder's behalf, semi-automated > in that the makefiles can prompt (and provide help for) the builder to > create e.g. platver.h correctly. > > This kind of version info gives precise location for the sources and allows > reproducible builds. The manually maintained version info is, frankly, a > joke. > > HTH, > Eliot > > > > For the platforms sources on the git mirror with CMMakerVMMaker > > build, some mechanism would be needed to identify version level. > > Ian's build procedure on unix with Subversion works well for > > this, but I don't know how to do the equivalent on the git > > mirror. But I'm not really familiar with git, so hopefully > > someone can suggest something here. > > > > Dave > > > > |
|
|
On 12 April 2011 20:27, David T. Lewis <[hidden email]> wrote: > > On Tue, Apr 12, 2011 at 10:14:07AM -0700, Eliot Miranda wrote: >> >> On Tue, Apr 12, 2011 at 4:58 AM, David T. Lewis <[hidden email]> wrote: >> >> > >> > On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote: >> > > >> > > Hello, >> > > >> > > i'd like to know what we can do to clean up the mess with Cog VM >> > > versioning, so people could identify it more easily. >> > > >> > > Currently , what >> > > >> > > Smalltalk vmVersion shows is: >> > > >> > > Smalltalk vmVersion >> > > >> > > 'Croquet Closure Stack VM [StackInterpreter >> > > VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0' >> > > >> > > but it doesn't says anything about which version of platform sources >> > > are used to build it. >> > > Also, a version number VM 4.0.0 makes no sense.. >> > > >> > > I'd really like to see what we can do to improve it. >> > >> > (this may be a duplicate response, I'm having mail problems today) >> > >> > The mechanism used in the standard VMMaker and Unix platform sources >> > works well in practice. This uses VMMaker class>>versionString to >> > identify the (approximate) version of Smalltalk sources, combined >> > with the Subversion revision number identified at compile time. >> > >> >> I disagree. I think its terrible. It requires manual updating and hence is >> essentially meaningless. > > We are talking about two different problems here. The purpose of the versionString > and SVN tag is to give a simple label that can be used for "squeakvm -version" > and to provide a name for the installation directory on unix systems. It > is *not* intended to provide detailed version identification, and certainly > would be a terrible approach if that had been the intent. > > Currently Cog on unix installs in a directory named for some three or four > year old version of the standard interpreter VM, which is not a good thing > (but maybe Igor has addressed this separately in CMakeVMMaker, I'm not sure). > No, i'm not addressed that, since i didn't added an steps in configuration to install built artifacts. I know that most *nix users would expect to be able to do make install after 'make' , but i think that it would be better to do proper packaging separately (like 1-click package where you including VM for different platforms , and hence simple 'make install' won't go anyways), rather than messing with cmake.. Or perhaps i'm too lazy to do that :) so if anyone wants to include that, give it a try. > The UUID based identifications below are great, that was what I was > trying to point Igor to in my separate email. I think that is an excellent > way to make the detailed version information available. > Yes, indeed. (Now i wondering where i could append a lil info, which could tell which exactly config is used to build VM) > Dave > >> The solution in Cog is to include the VMMaker >> version along with its UUID, prefixed with an asterisk if the package is >> modified (matching the Monticello UI's display of dirty packages). This >> tells one exactly which sources were used to generate the VM. Here's an >> extract from oscog's src/vm/cointerp.c: >> >> /* Automatically generated by >> CCodeGeneratorGlobalStructure VMMaker-oscog.54 uuid: >> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 >> from >> CoInterpreter VMMaker-oscog.54 uuid: >> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 >> */ >> static char __buildInfo[] = "CoInterpreter VMMaker-oscog.54 uuid: >> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 " __DATE__ ; >> char *__interpBuildInfo = __buildInfo; >> >> And hence >> (1000 to: 1100) select: [:i| (Smalltalk getSystemAttribute: i) notNil] >> thenCollect: [:i| i -> (Smalltalk getSystemAttribute: i)] >> { 1001->'Mac OS' . >> 1002->'1067' . 1003->'intel' . >> 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54] Croquet Cog >> 3.0.0' . >> 1005->'Aqua' . >> 1006->'Mac OS X built on Mar 31 2011 17:23:52 Compiler: 4.2.1 (Apple Inc. >> build 5666) (dot 3)' . >> 1007->'CoInterpreter VMMaker-oscog.54 uuid: >> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011' . >> 1008->'StackToRegisterMappingCogit VMMaker-oscog.51 uuid: >> d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr 1 2011'} >> >> >> Now this could be improved upon by also including the uuid for the VMMaker >> package in parameter 1004. >> >> >> > For the VMMaker side, I'd suggest adopting a similar (manually >> > maintained) convention for #versionString, but also add a >> > suffix to identify a cog VM versus interpreter VM. Thus if >> > the versionString is '1.2.3' the Cog VM might use '1.2.3c'. >> > The suffix identifier is helpful in the near term for maintaining >> > separate installation directories on unix, and possibly becomes >> > irrelevant whenever we get the code bases merged. >> > >> >> This is useless. Manual versioning is essentially arbitrary and very easy >> to overlook. We have accurate version information in the Monticello package >> version and, given the UUID and the dirty mark convention, provides concise >> and precise info. IMO its the obvious solution. >> >> However, the platform sources are more problematic. One huge irritation >> with svn is that it doesn't provide a way of including the revision number >> in source since revision numbers are allocated after check-out. Instead one >> has to derive the revision number y running a command, e.g. >> >> McStalker.oscogvm$ svnversion >> 2219:2378M >> McStalker.oscogvm$ svnversion | sed 's/^.*://' >> 2378M >> McStalker.oscogvm$ >> >> Which might work on unix systems but is a nightmare on Windows, and requires >> builders to use an up-to-date svn, and forces everyone to use svn. >> >> I don't know what the conventions are in git, mercurial, cvs etc. >> >> I think we need to develop some convention which is along the lines of the >> platform build requiring the inclusion of some file that contains some >> precise version info, and providing e.g. options in the makefiles for >> generating there. >> >> e.g. make platverforsvnunix >> svnversion ../platforms | sed 's/^.*:/#define PLATREV /' >platver.h >> svn info ../platforms | grep URL: | sed 's/^URL: \(.*\)$/#define >> PLAT_REP_URL "\1"/' >>platver.h >> >> to produce >> #define PLATREV 2376 >> #define PLAT_REP_URL " >> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms" >> >> and then derive some system attribute from that, or include it in 1004, e.g. >> >> 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54 >> uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011, platform: 2376 >> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms] Croquet Cog >> 3.0.0' . >> >> We can then provide VMMaker and platforms info for any source code control >> system with a little bit of effort on the builder's behalf, semi-automated >> in that the makefiles can prompt (and provide help for) the builder to >> create e.g. platver.h correctly. >> >> This kind of version info gives precise location for the sources and allows >> reproducible builds. The manually maintained version info is, frankly, a >> joke. >> >> HTH, >> Eliot >> >> >> > For the platforms sources on the git mirror with CMMakerVMMaker >> > build, some mechanism would be needed to identify version level. >> > Ian's build procedure on unix with Subversion works well for >> > this, but I don't know how to do the equivalent on the git >> > mirror. But I'm not really familiar with git, so hopefully >> > someone can suggest something here. >> > >> > Dave >> > >> > > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |