[Vm-dev] About VM version string

Tue Apr 12 18:27:33 UTC 2011

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 <lewis at mail.msen.com> 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
> >
> >