[squeak-dev] Some notes about porting muO to 6.0
lecteur at zogotounga.net
Thu Aug 25 10:27:51 UTC 2022
Some notes about porting muO to 6.0
I always develop on a stable release, that may be several versions
behind the current trunk. This makes updating everything to work on a
newer stable release a non-trivial task, always.
muO started around 2002/2003, when Squeak was at 3. something (later and
for a long time I worked on 3.8). I remember 3.8 to 3.9 being quite bad,
but it was always nice to discover the new features and play with them.
And now after twenty years muO has gone all the way to 6.0, which shows
a real concern about backward compatibility from the trunk developers -
so, thanks everybody!
Now all is not smooth and this time, moving from 5.1/5.3 to 6.0, I had
the feeling it was more bumpy because of a few actual non-compatible
changes. Their nature also made the corresponding porting issues
particularly difficult to pinpoint, leading at times to the wrong but
unsettling impression that something was deeply broken.
So here they are:
A lot of the intricate live dependency of interactive objects in muO was
just gone - living things were now dead; it seems things were broken all
over the place.
In fact it was just that #becomeForward: semantics had changed.
All my #becomeForward: calls had to be replaced with
#becomeForward:copyHash: with second argument true.
This one is quite nasty.
Debuggers showed me all kind of objects receiving messages they had
nothing to do with. It seemed that object composition was scrambled, but
#setProperty:toValue: semantics had changed
It now returns its second argument, so I had to add cascaded #yourself
calls in many places.
This one is nasty too.
3)- immutable arrays
In a couple of places I did use arrays written in their now immutable
form to store data that would later be updated. I had to use other ways
to instanciate the arrays.
This one is bad IMO. Not the fact that arrays can (and should most
often) be immutable, but the fact the default way to write an #(array)
or a 'string' now has a different semantics. Assuming as before that we
get mutable objects leads to bugs that are easy to catch, but I am
afraid there may be old code laying around in SqueakMap or other
repositories that will now break. Well maybe I'm wrong about that.
FloatArray is now abstract; it must now be replaced with Float32Array.
Because I want muO to load and work both in 5.3 and 6.0 (which it does),
I had to to have the pre-installer create a dummy Float32Array class
before loading the muO code in 5.3.
No big deal, but again if some older forgotten packages are using
FloatArray, they will break.
This one is minor but still, #beAllFont: semantics changed. In 5.3 it
used to update the font of an existing text morph, now it is the same as
#font: and cannot be used that way - it must be sent before the text is set.
I just reverted it to its 5.3 behavior for muO.
6)- font sizes
In MuOTheme#addFonts: I had to give different font sizes numbers in 5.3
and 6.0 in order to get the same actual font sizes on screen. Not sure
what happened there, I guess a bug was fixed (because the font support
is much nicer now in 6.0) but still that's an incompatible change.
7)- RealEstateAgent scaleFactor
The scale factor was by default initialized to 0.75 which made
everything tiny; in 5.3 it was 1.0.
8) minor stuff now fixed
There where other minor issues that were fixed in the update stream
after I signaled them on squeak-dev. I'll just mention them for
- rehash was needed in SmartRefStream>>#next
- #encompassing:, #merging: did not accept a Set anymore
- a one-character wide TextMorph would not resize properly
All of this is now fine in 6.0, as of version 22110
All in all it was an interesting ride, and kudos to the developers for
all the work that went into 6.0!
More information about the Squeak-dev