[squeak-dev] Some notes about porting muO to 6.0

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Aug 25 22:59:36 UTC 2022


Hi Stephane,
concerning FloatArray, yes it is abstract, but with backward compatibility
in mind, creation is redirected to Float32Array automagically (see
FloatArray class>>#basicNew).
So if you write (FloatArray new: 2), it will instantiate a Float32Array in
Squeak 6.0.
If you want a single code base for both 5.x and 6.x you could stick to
FloatArray.

Portability problems would still appear if testing object class =
FloatArray, or isMemberOf: FloatArray, or if importing FloatArray from a
segment, or maybe other edge cases... We have not enough brain power to
support all those tricky compatibility cases...

Nicolas

Le jeu. 25 août 2022 à 23:27, Chris Muller <asqueaker at gmail.com> a écrit :

> Thank you!  Please disregard my request in the other email, as I read
> chronologically, I hadn't seen this yet.  :)
>
> On Thu, Aug 25, 2022 at 5:27 AM Stéphane Rollandin
> <lecteur at zogotounga.net> wrote:
> >
> > 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
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220826/b58a46a8/attachment.html>


More information about the Squeak-dev mailing list