<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 3:03 PM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 12, 2013 at 04:45:40PM -0400, David T. Lewis wrote:<br>
&gt; On Tue, Mar 12, 2013 at 11:25:23AM -0700, Eliot Miranda wrote:<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Mar 12, 2013 at 11:04 AM, Nicolas Cellier &lt;<br>
&gt; &gt; <a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2013/3/12 Nicolas Cellier &lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt;:<br>
&gt; &gt; &gt; &gt; 2013/3/12 Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Hi Dave,<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;     thanks, but...<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; On Sat, Mar 9, 2013 at 7:06 AM, &lt;<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; Item was changed:<br>
&gt; &gt; &gt; &gt;&gt;&gt;   ----- Method: VMMaker class&gt;&gt;versionString (in category &#39;version<br>
&gt; &gt; &gt; testing&#39;) -----<br>
&gt; &gt; &gt; &gt;&gt;&gt;   versionString<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt;         &quot;VMMaker versionString&quot;<br>
&gt; &gt; &gt; &gt;&gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;&gt; +       ^&#39;4.10.13&#39;!<br>
&gt; &gt; &gt; &gt;&gt;&gt; -       ^&#39;4.10.12&#39;!<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; I *hate* the above.  It is busy work (it must be done manually before<br>
&gt; &gt; &gt; each commit).  It is really easy to forget to do.  It is meaningless<br>
&gt; &gt; &gt; (because it is easy to forget it makes no guarantee that it identifies a<br>
&gt; &gt; &gt; unique version). It is not a good search key.  Mapping the version number<br>
&gt; &gt; &gt; into the software configuration that produced the C code is hard (you have<br>
&gt; &gt; &gt; to trawl through Monticello packages searching for the version with the<br>
&gt; &gt; &gt; relevant version string; you can script this but fer christ&#39;s sake...).<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Using the Monticello package name and version (with the dirty marker)<br>
&gt; &gt; &gt; on the other hand is automatic, is a really good key, and is meaningful.<br>
&gt; &gt; &gt;  So please can we discard VMMaker versionString and move to using the<br>
&gt; &gt; &gt; Monticello package?  Please?  Please.<br>
&gt; &gt; &gt; &gt;&gt; --<br>
&gt; &gt; &gt; &gt;&gt; best,<br>
&gt; &gt; &gt; &gt;&gt; Eliot<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; +1, the two requirements are<br>
&gt; &gt; &gt; &gt; - automatic<br>
&gt; &gt; &gt; &gt; - meaningful<br>
&gt; &gt; &gt;<br>
&gt;<br>
&gt; The primary requirement is that it needs to work with Ian&#39;s cmake build<br>
&gt; procedure in trunk, such that the build automatically creates a name for<br>
&gt; the installation subdirectory, and such that the name corresponds to what<br>
&gt; you see when you do &quot;squeak -version&quot;.<br>
&gt;<br>
&gt;<br>
&gt; &gt; &gt; However, there is also a dependency on external source (platform...),<br>
&gt; &gt; &gt; and I think it is also included in COG id no?<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Yes.  To mark the generated sources, the Cog VMMaker does this:<br>
&gt; &gt;<br>
&gt; &gt; For each source file generated, the Cog CCodeGenerator adds a comment<br>
&gt; &gt; containing the Smalltalk class and its VMMaker version that is translated<br>
&gt; &gt; to C and the Slang class and its version, e.g. from src/vm/gcc3x-cointerp,c:<br>
&gt; &gt;<br>
&gt; &gt; /* Automatically generated by<br>
&gt; &gt;     CCodeGeneratorGlobalStructure VMMaker.oscog-eem.272 uuid:<br>
&gt; &gt; 8f4167f2-5bf0-4d90-9b7f-5355c741c68f<br>
&gt; &gt;    from<br>
&gt; &gt;     CoInterpreter VMMaker.oscog-eem.272 uuid:<br>
&gt; &gt; 8f4167f2-5bf0-4d90-9b7f-5355c741c68f<br>
&gt; &gt;  */<br>
&gt; &gt;<br>
&gt;<br>
&gt; This is a very good and useful thing, but unrelated to the intended use<br>
&gt; of the version string.<br>
&gt;<br>
<br>
</div></div>... but perhaps I am just misunderstanding what you are saying. Are you<br>
suggesting that we come up with some way to generate a version string<br>
automatically based on the Monticello file name, such as &#39;272&#39; in the<br>
example above?<br></blockquote><div><br></div><div>I&#39;m saying that a version needs to reflect commits and be updated automatically.  That happens with the Cog/Pharo branch.  The VMMaker class&gt;&gt;versionString approach is brittle and uninformative. I think we need to discard it and use the Cog approach which, as mentioned earlier, is a better index and is automatically updated.  Yes, there;s work to update the squeak trunk build, but that&#39;s porting, not new work.  It&#39;s been done both for CMake by the Pharo folks and for Cog by me. </div>
<div>But I can see this isn&#39;t going to go anywhere unless someone finds the time.  So excuse the noise :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
confused,<br>
Dave<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
&gt; I&#39;m sure there are better ways to generate the version string, but it&#39;s<br>
&gt; not something that I&#39;m working on. Meanwhile, no we cannot discard the<br>
&gt; versionString, and I&#39;m happy to do the updates if other folks forget to<br>
&gt; do so.<br>
&gt;<br>
&gt; Dave<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>