[Vm-dev] VM Maker: VMMaker-dtl.302.mcz

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 12 22:47:36 UTC 2013


On Tue, Mar 12, 2013 at 1:45 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Tue, Mar 12, 2013 at 11:25:23AM -0700, Eliot Miranda wrote:
> >
> > On Tue, Mar 12, 2013 at 11:04 AM, Nicolas Cellier <
> > nicolas.cellier.aka.nice at gmail.com> wrote:
> >
> > >
> > > 2013/3/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> > > > 2013/3/12 Eliot Miranda <eliot.miranda at gmail.com>:
> > > >>
> > > >> Hi Dave,
> > > >>
> > > >>     thanks, but...
> > > >>
> > > >> On Sat, Mar 9, 2013 at 7:06 AM, <commits at source.squeak.org> wrote:
> > > >>>
> > > >>>
> > > >>> Item was changed:
> > > >>>   ----- Method: VMMaker class>>versionString (in category 'version
> > > testing') -----
> > > >>>   versionString
> > > >>>
> > > >>>         "VMMaker versionString"
> > > >>>
> > > >>> +       ^'4.10.13'!
> > > >>> -       ^'4.10.12'!
> > > >>
> > > >>
> > > >> 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...).
> > > >>
> > > >> 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.
> > > >> --
> > > >> best,
> > > >> Eliot
> > > >>
> > > >
> > > > +1, the two requirements are
> > > > - automatic
> > > > - meaningful
> > >
>
> The primary requirement is that it needs to work with Ian's cmake build
> procedure in trunk, such that the build automatically creates a name for
> the installation subdirectory, and such that the name corresponds to what
> you see when you do "squeak -version".
>

OK.  Here's what happens with the old automake-based linux build for Cog.

oscogvm/coglinux/squeak -version
4.0-2701 #1 Mon Mar 11 17:31:47 PDT 2013 gcc 4.1.2
CoInterpreter VMMaker.oscog-eem.272 uuid:
8f4167f2-5bf0-4d90-9b7f-5355c741c68f Mar 11 2013
StackToRegisterMappingCogit VMMaker.oscog-eem.270 uuid:
014f0153-bb02-49b7-b544-d8f3ac2deef6 Mar 11 2013
VM: r2701 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins
Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686
i386 GNU/Linux
plugin path: oscogvm/coglinux/lib/squeak/4.0-2701 [default:
/home/eliot/all/Cog/oscogvm/coglinux/lib/squeak/4.0-2701/]

i.e. you get essentially the same info that you get for system attributes
1006 through 1009.  IMO thats a lot better.

The only thing poor here is that the version number I generate is always
4.0-.  That it uses the SVN checkin id is way better.  But the .0 is not
good.  However it begs the question what changes cause the tenths to tick
up?

Summary, we can port the Cog version info and have squeak -version be
really informative.  No problem.

> > However, there is also a dependency on external source (platform...),
> > > and I think it is also included in COG id no?
> > >
> >
> > Yes.  To mark the generated sources, the Cog VMMaker does this:
> >
> > 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:
> >
> > /* Automatically generated by
> >     CCodeGeneratorGlobalStructure VMMaker.oscog-eem.272 uuid:
> > 8f4167f2-5bf0-4d90-9b7f-5355c741c68f
> >    from
> >     CoInterpreter VMMaker.oscog-eem.272 uuid:
> > 8f4167f2-5bf0-4d90-9b7f-5355c741c68f
> >  */
> >
>
> This is a very good and useful thing, but unrelated to the intended use
> of the version string.
>

I disagree.  The only uses of the version string are a) to uniquely
identify a version, and b) order versions in time.  The current version
info fails to do that because it is only unique if the VMMaker committer
remembers to update the version info.  The current version fails to order
versions in time because there's no coordination between versionString in
the trunk VMMaker, in my Cog branch or in the Pharo branch.  So its become
meaningless.  Whereas Monticello packages and svn and/or git commit ids are
ordered in time.


> I'm sure there are better ways to generate the version string, but it's
> not something that I'm working on. Meanwhile, no we cannot discard the
> versionString, and I'm happy to do the updates if other folks forget to
> do so.
>

Why not?


>
> Dave
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130312/5ce611c8/attachment.htm


More information about the Vm-dev mailing list