[Vm-dev] About VM version string

Tue Apr 12 17:14:07 UTC 2011

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. 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110412/93bc9c3f/attachment-0001.htm