> or maybe other edge cases...

Or any kind of source code you store/generate in/as strings and maybe even compare against another hard-coded string. We have these kind of issues in tests with PDFtalk.

Best,
Marcel
Am 26.08.2022 00:59:57 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
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 [mailto: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 [mailto: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/e9427446/attachment.html>