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

[David T. Lewis]

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
> >
> >
> >
> >