Due to read only ClassBinding it would be just a little bit more hackish:

(Smalltalk globals associationAt: #SystemProgressMorph) instVarAt: 2 put:
SystemProgressMorph copy.

2016-09-01 1:12 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

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