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...
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@ 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@hpi.de:
marcel.taeumel wrote
Bert Freudenberg wrote
On Tue, Aug 23, 2016 at 11:21 AM, marcel.taeumel <
Marcel.Taeumel@
> 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.