<div dir="ltr"><div><div>Or would this even more simple hack work? Put in the preamble something like:<br><br></div>Smalltalk at: SystemProgressMorph put: SystemProgressMorph copy.<br><br></div>This way, the old instances should not be mutated...<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-24 7:06 GMT+02:00 marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">marcel.taeumel wrote<br>
<div><div class="h5">><br>
> Bert Freudenberg wrote<br>
>> On Tue, Aug 23, 2016 at 11:21 AM, marcel.taeumel &lt;<br>
<br>
>> Marcel.Taeumel@<br>
<br>
>> &gt;<br>
>> wrote:<br>
>><br>
>>><br>
>>> Hi, there.<br>
>>><br>
>>> It is, unfortunately, not possible to turn back time and rewrite<br>
>>> history.<br>
>>> ;-)<br>
>>><br>
>><br>
>> ... unless we're dealing with software. Oh wait, we are ;)<br>
>><br>
>> There is several important code that makes excessive use of instVar<br>
>>> accesses such as in SystemProgressMorph or HandMorph. Making any change<br>
>>> in<br>
>>> their class layout while using some of their methods will provoke a<br>
>>> strange<br>
>>> error. This could only be changed by a VM that keeps old class<br>
>>> layouts/schemata around for some longer time until there is no old<br>
>>> compiled<br>
>>> method on any stack anymore.<br>
>><br>
>><br>
>> Class layout changes and instance migration is handled fully in the image<br>
>> by class ClassBuilder. The VM is not at fault here.<br>
>><br>
>><br>
>>> Usually, restarting the update process helps here. There is no way to<br>
>>> fix<br>
>>> that in order to interactively update from 5.0 to 5.1 without any<br>
>>> errors.<br>
>>><br>
>><br>
>> We can retroactively change the config map that introduced the problem.<br>
>> I'm<br>
>> certain it would be possible to fix, but I am not entirely sure it's<br>
>> worth<br>
>> the trouble.<br>
>><br>
>> - Bert -<br>
> Hi Bert,<br>
><br>
> the config map will not help, we would have to change numerous MCZs since<br>
> point X in time to rewrite history. :) "Oh, would we have always been<br>
> using accessors here instead of instVar accessess..."<br>
><br>
> Best,<br>
> Marcel<br>
<br>
</div></div>...even then, how do you update the code in image Y, which is going to be<br>
updated before it is updated? This is not even possible for every user's<br>
images out there... :-/<br>
<br>
The Java Hotspot VM has a mapping table for changed instVar accesses. Maybe<br>
we could use this trick, too? Still, would only applies to future versions.<br>
We cannot rewrite history because it is not only one piece of software in a<br>
single version control system with a single version checked out. :)<br>
<br>
Best,<br>
Marcel<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/Re-Does-anyone-recognize-this-glitch-in-our-trunk-update-processing-was-Vm-dev-buildspurtrunkvmmaker-tp4912130p4912403.html" rel="noreferrer" target="_blank">http://forum.world.st/Re-Does-<wbr>anyone-recognize-this-glitch-<wbr>in-our-trunk-update-<wbr>processing-was-Vm-dev-<wbr>buildspurtrunkvmmaker-<wbr>tp4912130p4912403.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</div></div></blockquote></div><br></div>