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

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 12 22:50:55 UTC 2013


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

>
> On Tue, Mar 12, 2013 at 04:45:40PM -0400, David T. Lewis 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".
> >
> >
> > > > 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.
> >
>
> ... but perhaps I am just misunderstanding what you are saying. Are you
> suggesting that we come up with some way to generate a version string
> automatically based on the Monticello file name, such as '272' in the
> example above?
>

I'm saying that a version needs to reflect commits and be updated
automatically.  That happens with the Cog/Pharo branch.  The VMMaker
class>>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's porting, not new work.  It's been done both
for CMake by the Pharo folks and for Cog by me.
But I can see this isn't going to go anywhere unless someone finds the
time.  So excuse the noise :)


>
> confused,
> Dave
>
>
> > 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.
> >
> > Dave
>



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


More information about the Vm-dev mailing list