Some notes about porting muO to 6.0


Context:

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:


1)- becomeForward:

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.


2)- setProperty:toValue:

Debuggers showed me all kind of objects receiving messages they had 
nothing to do with. It seemed that object composition was scrambled, but 
in fact...

#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.


4)- FloatArray

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.


5)- beAllFont:

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 
completeness sake:

	- 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!



Stef