On Thu, Sep 1, 2016 at 12:33 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> The copy is not completely clean because this assertion then fails:
>
> (SystemProgressMorph superclass subclasses detect: [:e | e name =
> #SystemProgressMorph]) == SystemProgressMorph
>
> IOW, the superclass is still pointing to the old class, so any change to
> superclass layout won't propagate to the new subclass... Bad.
>
> But there's also this possibility:
>
> | oldClass |
> oldClass := SystemProgressMorph copy become: SystemProgressMorph.
> SystemProgressMorph allInstancesDo: [:e | oldClass adoptInstance: e].
>
> We mutate all the instances to a class detached from Smalltalk and immune
> to some changes...
> Beware: don't you modify the layout of one superclass...
>

+1


>
> 2016-09-01 1:17 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> 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 gmai
>> l.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. :)
>>>>
>>>
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.

Can we not put the progress morph in its own process, making it easier to
tear down and restart?



>
>>>> 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.
>>>>
>>>
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160901/d29daefc/attachment.htm