last furlong

On Thu, Dec 09, 2010 at 01:56:13PM -0500, Chris Cunnington wrote:
> That was a great tour through the pieces. I can see how the Slang
> becomes the actual C code.
>
> The difference between sq.h and gnu-interp.c is the letter "u", as
> mentioned in that great post. I suppose, though, that's not really the
> problem, and my playing with C files or Slang methods I don't understand
> will be unproductive.
>
> I took sources from squeakvm.org and compiled them successfully using
> Adrian's blog. No problem. I started an image with that vm.
>
> Then I started to play with the VMMaker and a taint in the process was
> introduced. The only way I could imagine introducing a taint was in
> putting in/leaving out a plugin contrary to the arrangement Adrian
> specified. But that's not the problem, because I've seen plugins
> compiled that weren't supposed to be and such.
>
> The problem is the VMMaker itself, I suppose. It's not generic. It's
> keyed - unwittingly, it seems - to specific sets of source files. And so
> we have drift that can't be accounted for in Adrian's blog. All the
> pieces of this process are like stars that keep moving and you can only
> take a picture of a certain period in time.
>
> It's this drift that drove Igor to write NativeBoost, I'd guess. When he
> writes code with NativeBoost he knows that the image, vm, and plugins
> may all drift, but the memory won't, so he doesn't have to recompile
> every time something changes.
>
> The logical question to ask the VMMaker is "What versions are you good
> for, O VMMaker?" which - I'm willing to bet - is not a question it can
> readily answer.

This is a good question, and it is not easy to answer precisely.
But if you are willing to live with a "pretty good" answer, then
things are not so bad after all.

First, I should say that the VMMaker we are talking about here
is nothing more or less than a package name. The VMMaker package
is managed with the Monticello version control system on the
SqueakSource archive, and in that package you will find the VM
source code itself (Interpreter, ObjectMemory, plugins, and other
things that are written in Smalltalk and translated to C). You
will also find a C code generator, a tool (called "VMMaker")
for managing the code generation, and a user interface for the
VMMaker tool.

This means that we have a bunch of stuff in the VMMaker package,
some of which is VM source code (written in Smalltalk), that is
version controlled in Monticello. And there is another bunch of
stuff for the platform support code that is version controlled
and saved over in the squeakvm.org Subversion repository. It
would be nice if the Smalltalk source code in the SqueakSource
repository was neatly versioned and coordinated with the source
code in the squeakvm.org repository, but alas this is not the
case, and we are left to take a more pragmatic approach: keep
the two repositories more or less in sync with each other.

This all sounds a bit messy, but in practice it turns out
that the latest bleeding edge versions of the platform code
is usually kept in line with the corresponding bleeding edge
versions in the SqueakSource VMMaker repository. So if you are
using the most up to date version of both VMMaker and the platforms
code to generate your VM, there is usually no problem at all.

In addition, the VM builders (mainly Ian, Eliot, Andreas, John
and Esteban at the moment) will typically provide a copy of all
the source code that goes into any VM that they release, including
the platform support code and the C code that they generated from
the Smalltalk classes in VMMaker. This provides a point in time
snapshot of the source for a specific VM for folks who may want
to rebuild it from original source code. This is important,
for example, for people who want to provide a Linux package
distribution in which the VM can be compiled from a known set
of C source files.

To return to your original question, which I'll paraphrase as
"which versions of the platform source go with which versions of
the Smalltalk source in the SqueakSource VMMaker package?", there
actually is a way to figure it out. Because of the very question
you are asking, we have a convention of maintaining the method
VMMaker class>>versionString with a version label, and we update
that version label with each new version added to the VMMaker
Montecillo repository. That means you can look at the Monticello
change history with #versionString updates to see when some
particular version of the VMMaker package was saved, as well
as to see the things that were added or changed in that version.

Likewise, the Subversion repository has version level numbers
that identify the time stamp of each update, and all the files
associated with that version level. That means you can compare
the version level of the platforms code in Subversion with the
version level of the Smalltalk code in Monticello, and if they
are reasonably close, then the two will almost always work
together.

<side note>
You may have noticed some of the VMs labeled with identifiers
such as "4.3.19-2329". This identifies the two version labels
discussed above; in this case "4.3.19" comes from the identifier
in VMMaker class>>versionString, and "2329" is the Subversion
revision number of the platform source code. The two identifiers
tell you the version level of the code from Monticello and
Subversion that was used to build this VM executable.
</side note>

However, as a practical matter, this is a lot of work just to
figure out what versions go together. The easy way out is just
to use the latest versions of all the Smalltalk code and platforms
code. This works fine most of the time, and in my opinion is
the easiest way to handle it.

The only down side (if you can call it that) is that you
will need to generate the C code from VMMaker yourself in
order to obtain the latest version of the VM code. Personally
I consider this to be a real advantage, and much more enjoyable
than digging through version labels to figure out what matches
up with what. But you'll just have to try it yourself and see
if you agree with me :)

Dave

_______________________________________________
VM-beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners