[Vm-beginners] last furlong

Sun Dec 12 19:00:14 UTC 2010

Thanks David for teaching us and sharing your knoweldege. I hope a lot of
people is reading this mailing list and  learing like me.

Thanks again for your nice answers.

Mariano

On Fri, Dec 10, 2010 at 5:04 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> 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
> VM-beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-beginners/attachments/20101212/04a0d569/attachment.htm