<div dir="ltr">Okay. I moved it to trunk.<div><br></div><div>With this, we should be able to load most old Etoys projects. If something doesn't work, speak up :)</div><div><br></div><div>- Bert -</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 3:40 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 14-09-2016, at 12:56 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
><br>
> The original purpose of ImageSegments was to leverage the<br>
> garbage-collector in order to have a performant serialization<br>
> mechanism, is that right?<br>
><br>
> Now with Cog/Spur, its performance is probably not as advantageous,<br>
> and so the relative cost of its magical implementation, code size,<br>
> number of serializers confusion, seems unlikely it will be used by any<br>
> new code.<br>
<br>
</span>Given that Spur is somewhat different memory model I doubt that using the original idea of the image segment is of any real advantage. And given that the detail of the memory model is different we’d have to do assorted fiddling in both directions. Seems like a bit of a loser to me. Being able to stop keeping compatibility code working in the vm would save some hassles. I say ‘just dolt'<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Brain fried; core dumped.<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>