<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 11:04 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
2013/3/12 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
<div><div class="h5">> 2013/3/12 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
>><br>
>> Hi Dave,<br>
>><br>
>> thanks, but...<br>
>><br>
>> On Sat, Mar 9, 2013 at 7:06 AM, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
>>><br>
>>><br>
>>> Item was changed:<br>
>>> ----- Method: VMMaker class>>versionString (in category 'version testing') -----<br>
>>> versionString<br>
>>><br>
>>> "VMMaker versionString"<br>
>>><br>
>>> + ^'4.10.13'!<br>
>>> - ^'4.10.12'!<br>
>><br>
>><br>
>> I *hate* the above. It is busy work (it must be done manually before each commit). It is really easy to forget to do. It is meaningless (because it is easy to forget it makes no guarantee that it identifies a unique version). It is not a good search key. Mapping the version number into the software configuration that produced the C code is hard (you have to trawl through Monticello packages searching for the version with the relevant version string; you can script this but fer christ's sake...).<br>
>><br>
>> Using the Monticello package name and version (with the dirty marker) on the other hand is automatic, is a really good key, and is meaningful. So please can we discard VMMaker versionString and move to using the Monticello package? Please? Please.<br>
>> --<br>
>> best,<br>
>> Eliot<br>
>><br>
><br>
> +1, the two requirements are<br>
> - automatic<br>
> - meaningful<br>
<br>
</div></div>However, there is also a dependency on external source (platform...),<br>
and I think it is also included in COG id no?<br></blockquote><div><br></div><div>Yes. To mark the generated sources, the Cog VMMaker does this:</div><div><br></div><div>For each source file generated, the Cog CCodeGenerator adds a comment containing the Smalltalk class and its VMMaker version that is translated to C and the Slang class and its version, e.g. from src/vm/gcc3x-cointerp,c:</div>
<div><br></div><div><div>/* Automatically generated by</div><div> CCodeGeneratorGlobalStructure VMMaker.oscog-eem.272 uuid: 8f4167f2-5bf0-4d90-9b7f-5355c741c68f</div><div> from</div><div> CoInterpreter VMMaker.oscog-eem.272 uuid: 8f4167f2-5bf0-4d90-9b7f-5355c741c68f</div>
<div> */</div></div><div><br></div><div>and from src/plugins/AsynchFilePlugin/AsynchFilePlugin.c</div><div><br></div><div><div>/* Automatically generated by</div><div> SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.235 uuid: 954df856-3f83-498c-9735-6cd3777ba9c7</div>
<div> from</div><div> AsynchFilePlugin VMMaker.oscog-eem.235 uuid: 954df856-3f83-498c-9735-6cd3777ba9c7</div><div> */</div></div></div><br clear="all"><div>and for the misc primitives you'll also get the class contributing the primitive implementation (which in this case has a dirty package) so from src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c</div>
<div><br></div><div><div>/* Automatically generated by</div><div> VMPluginCodeGenerator VMMaker.oscog-eem.248 uuid: 325b96ad-3c25-438e-af36-04a93839f195</div><div> from</div><div> ADPCMCodecPlugin VMMaker.oscog-eem.248 uuid: 325b96ad-3c25-438e-af36-04a93839f195</div>
<div> ADPCMCodec * Sound-ar.30 uuid: c0c6133c-73b7-7b47-9858-99b64868d35c</div><div> */</div></div><div><br></div><div>Then each file has a static string containing the source class(es), e.g.</div><div><br></div><div><div>
static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.272 uuid: 8f4167f2-5bf0-4d90-9b7f-5355c741c68f " __DATE__ ;</div><div>char *__interpBuildInfo = __buildInfo;</div></div><div><br></div><div><br></div>
<div><div>static char __buildInfo[] = "ADPCMCodecPlugin VMMaker.oscog-eem.248 uuid: 325b96ad-3c25-438e-af36-04a93839f195\n\</div><div>ADPCMCodec * Sound-ar.30 uuid: c0c6133c-73b7-7b47-9858-99b64868d35c " __DATE__ ;</div>
</div><div><br></div><div>So you'd think you can grep for these in the VM binary, via e.g. strings - Fast.app/Contents/MacOS/Croquet | grep ADPCMCodecPlugin. But the optimizer removes the strings. This needs to be fixed.</div>
<div><br></div><div>Then the build info for the interpreter, and the cogit (if there is one), is exported for Smalltalk getSystemAttribute: 1007 and 1008.</div><div>Then the C repository version info for the root and Cross/plugins is exported for attribute 1009. And as always the C compiler build info is attribute 1006.</div>
<div><br></div><div>e.g.</div><div>(1006 to: 1009) collect: [:i| Smalltalk getSystemAttribute: i]</div><div>#('Mac OS X built on Mar 11 2013 14:06:19 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)'</div><div>'CoInterpreter VMMaker.oscog-eem.272 uuid: 8f4167f2-5bf0-4d90-9b7f-5355c741c68f Mar 11 2013'</div>
<div>'StackToRegisterMappingCogit VMMaker.oscog-eem.270 uuid: 014f0153-bb02-49b7-b544-d8f3ac2deef6 Mar 11 2013'</div><div> 'VM: r2701 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog">http://www.squeakvm.org/svn/squeak/branches/Cog</a> Plugins: r2545 <a href="http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins">http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins</a>')</div>
<div><br></div><div>With the uuid there's no need to specify repository name, and anyway repositories are neither permanent institutions, nor unique to packages.</div><div><br></div><div>So IMO the Cog branch (and I think the Pharo branch) has the right info. From the binary one can map back to both C and Slang/VMMaker. From the C one can map back to Slang/VMMaker.</div>
-- <br>best,<div>Eliot</div>