[Vm-dev] Closure bytecodes added to VM (was: [squeak-dev] Status of 4.0)

[David T. Lewis]

FYI, Eliot's closure bytecode support is now included in VMMaker on SqueakSource
as VMMaker-eem.114. A couple of updates were required to get this to load into
a vanilla Squeak image; these are in VMMaker-dtl.115.

The changes are backward compatible, and it is safe to use this for general
purpose VM building. There are a number of new numbered primitives, and I
can't say if these might cause conflicts with other VM projects (Exupery?).

Dave

On Wed, Feb 18, 2009 at 11:03:17PM -0500, David T. Lewis wrote:
>  
> Eliot,
> 
> Excellent, thanks for committing this directly to the SqueakSource project.
> I'm short of time now but look forward to building a VM with closure
> bytecodes this weekend.
> 
> (subject line changed, and CC to vm-dev list)
> 
> Dave
> 
> On Wed, Feb 18, 2009 at 05:50:33PM -0800, Eliot Miranda wrote:
> > On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > > On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
> > > >
> > > > On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
> > > > >Works for me.  When and if the VM is no longer backwards-compatible
> > > > >(e.g. the Stack VM) one can move to 5.0.
> > > > >However, I would recommend getting the VM changes into the 4.0 VM as
> > > > >this will make migrating to image-level closures much easier.  I
> > > > >believe (John, can you confirm) that John's latest Mac 3.8 beta VMs
> > > > >have included the closure bytecodes.
> > > >
> > > > Well I've not done that (yet) was waiting on Eliot for the latest VM
> > > > changes before christmas. Then I've been
> > > > distracted by an iPhone application.
> > > >
> > > > I recall David T and I last discussed the issues around the source
> > > > code changes and how it cheerfully
> > > > upgrades your image, which then makes it un-run-able  on the raft of
> > > > VMs one has on one's machine, but
> > > > I recall we thought we could tie the image version change on save to
> > > > only happen if in fact the image
> > > > *uses* the closure bytes code.
> > >
> > > Right, Eliot's bytecode changes are fully backward compatible, so they
> > > can be added to VMMaker without breaking anything. The image version
> > > numbering change needs to be left out for now, but that's a small issue
> > > that can be the subject of separate discussion.
> > 
> > 
> > I've fixed the image numbering version issue.  The VM has a variable holding
> > the version number which is initialized to teh standard version.  If the
> > create-closure bytecode is evaluated it changes to the new version.  Hence
> > the VM can safely be used for both old and new and will not change the image
> > version unless it should be changed.
> > 
> > Eliot, if you can confirm that the bytecode changes are ready for
> > > release, and that the license is <whatever>, then I'll volunteer to
> > > add your bytecode bootstrap changes to the Squeaksource VMMaker project
> > > and make whatever minor changes are needed to avoid the image numbering
> > > glitch.
> > 
> > 
> > They're ready for your and John's review.  See
> >     Name: VMMaker-eem.114
> >     Author: eem
> >     Time: 18 February 2009, 5:42:18 pm
> >     UUID: 169887e2-d54c-43a6-9042-eabfcaa08146
> >     Ancestors: VMMaker-dtl.113
> > in http://squeaksource.com/VMMaker.  There's a verbose version comment
> > describing the changes.  It omitted to mention that in the version of
> > Monticello I'm using class variables appear in alphabetical order and hence
> > there are some artificial changes in class definitions.
> > 
> > The license is the new Squeak license because I am the author of these
> > changes and have informed Yoshiki that I assent to the new Squeak licencing
> > scheme.  Sorry for being so inarticulate; I'm not sure what the right form
> > of words  is for this :/
> > 
> > Best
> > Eliot
> > 
> > P.S.  John and David, thanks for your help today, and apologies for the
> > delay.
> > 
> > >
> > >
> > > Dave
> > >
> > >
> > >
> > >