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 <[hidden email]> 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 > > > > > > > > |
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 <[hidden email]> 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 > > > > > > > > > > > > |
Free forum by Nabble | Edit this page |