<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 1, 2016 at 12:33 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>The copy is not completely clean because this assertion then fails:<br><br>(SystemProgressMorph superclass subclasses detect: [:e | e name = #SystemProgressMorph]) == SystemProgressMorph<br><br></div>IOW, the superclass is still pointing to the old class, so any change to superclass layout won't propagate to the new subclass... Bad.<br><br></div>But there's also this possibility:<br><br>| oldClass |<br>oldClass := SystemProgressMorph copy become: SystemProgressMorph.<br>SystemProgressMorph allInstancesDo: [:e | oldClass adoptInstance: e].<br><br></div>We mutate all the instances to a class detached from Smalltalk and immune to some changes...<br></div>Beware: don't you modify the layout of one superclass...<br></div></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-09-01 1:17 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<wbr>gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Due to read only ClassBinding it would be just a little bit more hackish:<br><br>(Smalltalk globals associationAt: #SystemProgressMorph) instVarAt: 2 put: SystemProgressMorph copy.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-01 1:12 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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>><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></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Putting more brittle stuff into he VM is not the solution. We have all that we need above the VM that can be dynamically tailored to suit our needs.</div><div><br></div><div>Can we not put the progress morph in its own process, making it easier to tear down and restart?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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-i<wbr>n-our-trunk-update-processing-<wbr>was-Vm-dev-buildspurtrunkvmmak<wbr>er-tp4912130p4912403.html</a><br>
<div><div>Sent from the Squeak - Dev mailing list archive at Nabble.com.<br></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote><div> </div></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>