[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