<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 3:51 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> It's right where we left it. Spur introduces a new object memory<br>
>> format, so we're doing the right thing: we're breaking the format and<br>
>> telling people.<br>
>><br>
>> When you load packages into a Spur image, things will just work. When<br>
>> you load changesets, things will just work. As far as I know, we've<br>
>> taken care that ImageSegments will also load into Spur, and just work.<br>
><br>
><br>
> Ah, not quite. Image segments saved in 32-bit Spur will load in 32-bit<br>
> Spur. Image segments saved in 64-bit Spur will load in 64-bit Spur. Image<br>
> segments saved in Cog will load in Cog. But no interoperability is possible<br>
> (yet!). And indeed I believe that image segments saved in the 64-bit<br>
> Interpreter VM will only load in that 64-bit VM.<br>
<br>
</span>64-bit will not be ready in time for 5.0 on 4/30 right?<br></blockquote><div><br></div><div>Right. I don't even have the optimized 64-bit Spur StackInterpreter working on Mac. The assert VM works fine, but optimized crashes on start-up. Let alone having a working 64-bit Spur StackInterpreter on Windows and Mac. And let alone having a 64-bit Spur Cog JIT.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The problem with image segments is that they are in the format of the VM's<br>
> heap objects. However, Bert and I want co co-mentor a project to implement<br>
> image-level support for loading segments from "foreign" object memories.<br>
> Alas GSoC did not approve our organization this year. Maybe soon. Or maybe<br>
> some student at one of the teaching institutions using Squeak or Pharo would<br>
> be interested in having a go.<br>
><br>
> Note that e.g. Fuel does not have this problem.<br>
<br>
</span>Nor does Ma Object Serializer. Ma Object Serializer has been updated<br>
to be transparently Spur compatible, so for 32-bit systems anyway, one<br>
could load ImageSegment file into a Cog image, save it with Ma, go<br>
into spur and load it with Ma, and then finally save it as<br>
ImageSegment. You could even stay as Ma for a while because I intend<br>
to do the same for 64-bit.<br>
<span class=""><br>
> +1. Spur has lots of advantages over the existing system but these can't be<br>
> introduced without forcing a change to a new image and a new VM.<br>
<br>
</span>Now that we've answered the troll-style question extensively, may we<br>
please talk about ideas to help users manage multiple formats?<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>