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