<br><br><div class="gmail_quote">On Tue, Apr 12, 2011 at 4:58 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote:<br>
><br>
> Hello,<br>
><br>
> i'd like to know what we can do to clean up the mess with Cog VM<br>
> versioning, so people could identify it more easily.<br>
><br>
> Currently , what<br>
><br>
> Smalltalk vmVersion shows is:<br>
><br>
> Smalltalk vmVersion<br>
><br>
> 'Croquet Closure Stack VM [StackInterpreter<br>
> VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0'<br>
><br>
> but it doesn't says anything about which version of platform sources<br>
> are used to build it.<br>
> Also, a version number VM 4.0.0 makes no sense..<br>
><br>
> I'd really like to see what we can do to improve it.<br>
<br>
</div></div>(this may be a duplicate response, I'm having mail problems today)<br>
<br>
The mechanism used in the standard VMMaker and Unix platform sources<br>
works well in practice. This uses VMMaker class>>versionString to<br>
identify the (approximate) version of Smalltalk sources, combined<br>
with the Subversion revision number identified at compile time.<br></blockquote><div><br></div><div>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:</div>
<div><br></div><div><div>/* Automatically generated by</div><div> CCodeGeneratorGlobalStructure VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7</div><div> from</div><div> CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7</div>
<div> */</div><div>static char __buildInfo[] = "CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 " __DATE__ ;</div><div>char *__interpBuildInfo = __buildInfo;</div></div><div><br></div><div>
And hence</div><div>(1000 to: 1100) select: [:i| (Smalltalk getSystemAttribute: i) notNil] thenCollect: [:i| i -> (Smalltalk getSystemAttribute: i)]</div><div>{<span class="Apple-tab-span" style="white-space:pre"> </span>1001->'Mac OS' .</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>1002->'1067' . 1003->'intel' .</div><div><span class="Apple-style-span" style="white-space: pre; "> </span>1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54] Croquet Cog 3.0.0' .</div>
<div><span class="Apple-style-span" style="white-space: pre; "> </span>1005->'Aqua' .</div><div><span class="Apple-style-span" style="white-space: pre; "> </span>1006->'Mac OS X built on Mar 31 2011 17:23:52 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)' .</div>
<div><span class="Apple-style-span" style="white-space: pre; "> </span>1007->'CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011' .</div><div><span class="Apple-style-span" style="white-space: pre; "> </span>1008->'StackToRegisterMappingCogit VMMaker-oscog.51 uuid: d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr 1 2011'}</div>
<div><br></div><div><br></div><div>Now this could be improved upon by also including the uuid for the VMMaker package in parameter 1004.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
For the VMMaker side, I'd suggest adopting a similar (manually<br>
maintained) convention for #versionString, but also add a<br>
suffix to identify a cog VM versus interpreter VM. Thus if<br>
the versionString is '1.2.3' the Cog VM might use '1.2.3c'.<br>
The suffix identifier is helpful in the near term for maintaining<br>
separate installation directories on unix, and possibly becomes<br>
irrelevant whenever we get the code bases merged.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><div>McStalker.oscogvm$ svnversion</div><div>2219:2378M</div><div>McStalker.oscogvm$ svnversion | sed 's/^.*://'</div><div>2378M</div><div>McStalker.oscogvm$ </div><div><br></div><div>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.</div>
</div><div><br></div><div>I don't know what the conventions are in git, mercurial, cvs etc.</div><div><br></div><div>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.</div>
<div><br></div><div>e.g. make platverforsvnunix</div><div>svnversion ../platforms | sed 's/^.*:/#define PLATREV /' >platver.h</div><div>svn info ../platforms | grep URL: | sed 's/^URL: \(.*\)$/#define PLAT_REP_URL "\1"/' >>platver.h</div>
<div><br></div><div>to produce</div><div><div>#define PLATREV 2376</div><div>#define PLAT_REP_URL "<a href="http://www.squeakvm.org/svn/squeak/branches/Cog/platforms">http://www.squeakvm.org/svn/squeak/branches/Cog/platforms</a>"</div>
</div><div><br></div><div>and then derive some system attribute from that, or include it in 1004, e.g.</div><div><br></div><div><div><span class="Apple-style-span" style="white-space: pre; "> </span>1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54 uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr 1 2011, platform: 2376 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog/platforms">http://www.squeakvm.org/svn/squeak/branches/Cog/platforms</a>] Croquet Cog 3.0.0' .</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>This kind of version info gives precise location for the sources and allows reproducible builds. The manually maintained version info is, frankly, a joke.</div><div><br></div><div>HTH,</div><div>Eliot</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
For the platforms sources on the git mirror with CMMakerVMMaker<br>
build, some mechanism would be needed to identify version level.<br>
Ian's build procedure on unix with Subversion works well for<br>
this, but I don't know how to do the equivalent on the git<br>
mirror. But I'm not really familiar with git, so hopefully<br>
someone can suggest something here.<br>
<br>
Dave<br>
<br>
</blockquote></div><br>