<br><br><div class="gmail_quote">On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:<br>
><br>
> On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:<br>
> >Works for me. When and if the VM is no longer backwards-compatible<br>
> >(e.g. the Stack VM) one can move to 5.0.<br>
> >However, I would recommend getting the VM changes into the 4.0 VM as<br>
> >this will make migrating to image-level closures much easier. I<br>
> >believe (John, can you confirm) that John's latest Mac 3.8 beta VMs<br>
> >have included the closure bytecodes.<br>
><br>
> Well I've not done that (yet) was waiting on Eliot for the latest VM<br>
> changes before christmas. Then I've been<br>
> distracted by an iPhone application.<br>
><br>
> I recall David T and I last discussed the issues around the source<br>
> code changes and how it cheerfully<br>
> upgrades your image, which then makes it un-run-able on the raft of<br>
> VMs one has on one's machine, but<br>
> I recall we thought we could tie the image version change on save to<br>
> only happen if in fact the image<br>
> *uses* the closure bytes code.<br>
<br>
</div>Right, Eliot's bytecode changes are fully backward compatible, so they<br>
can be added to VMMaker without breaking anything. The image version<br>
numbering change needs to be left out for now, but that's a small issue<br>
that can be the subject of separate discussion.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Eliot, if you can confirm that the bytecode changes are ready for<br>
release, and that the license is <whatever>, then I'll volunteer to<br>
add your bytecode bootstrap changes to the Squeaksource VMMaker project<br>
and make whatever minor changes are needed to avoid the image numbering<br>
glitch.</blockquote><div><br></div><div>They're ready for your and John's review. See </div><div> Name: VMMaker-eem.114</div><div> Author: eem</div><div> Time: 18 February 2009, 5:42:18 pm</div><div> UUID: 169887e2-d54c-43a6-9042-eabfcaa08146</div>
<div> Ancestors: VMMaker-dtl.113 </div><div>in <a href="http://squeaksource.com/VMMaker">http://squeaksource.com/VMMaker</a>. 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.</div>
<div><br></div><div>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 :/</div>
<div><br></div><div>Best</div><div>Eliot</div><div><br></div><div>P.S. John and David, thanks for your help today, and apologies for the delay.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Dave<br>
<br>
<br>
<br>
</blockquote></div><br>