<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        > <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">or maybe other edge cases...</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">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.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 26.08.2022 00:59:57 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr"><div>Hi Stephane,</div><div>concerning FloatArray, yes it is abstract, but with backward compatibility in mind, creation is redirected to Float32Array automagically (see FloatArray class>>#basicNew).</div><div>So if you write (FloatArray new: 2), it will instantiate a Float32Array in Squeak 6.0.</div><div>If you want a single code base for both 5.x and 6.x you could stick to FloatArray.</div><div><br></div><div>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...</div><div><br></div><div>Nicolas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 25 août 2022 à 23:27, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px">Thank you!  Please disregard my request in the other email, as I read<br>
chronologically, I hadn't seen this yet.  :)<br>
<br>
On Thu, Aug 25, 2022 at 5:27 AM Stéphane Rollandin<br>
<<a href="mailto:lecteur@zogotounga.net" target="_blank">lecteur@zogotounga.net</a>> wrote:<br>
><br>
> Some notes about porting muO to 6.0<br>
><br>
><br>
> Context:<br>
><br>
> I always develop on a stable release, that may be several versions<br>
> behind the current trunk. This makes updating everything to work on a<br>
> newer stable release a non-trivial task, always.<br>
><br>
> muO started around 2002/2003, when Squeak was at 3. something (later and<br>
> for a long time I worked on 3.8). I remember 3.8 to 3.9 being quite bad,<br>
> but it was always nice to discover the new features and play with them.<br>
> And now after twenty years muO has gone all the way to 6.0, which shows<br>
> a real concern about backward compatibility from the trunk developers -<br>
> so, thanks everybody!<br>
><br>
> Now all is not smooth and this time, moving from 5.1/5.3 to 6.0, I had<br>
> the feeling it was more bumpy because of a few actual non-compatible<br>
> changes. Their nature also made the corresponding porting issues<br>
> particularly difficult to pinpoint, leading at times to the wrong but<br>
> unsettling impression that something was deeply broken.<br>
><br>
><br>
> So here they are:<br>
><br>
><br>
> 1)- becomeForward:<br>
><br>
> A lot of the intricate live dependency of interactive objects in muO was<br>
> just gone - living things were now dead; it seems things were broken all<br>
> over the place.<br>
><br>
> In fact it was just that #becomeForward: semantics had changed.<br>
><br>
> All my #becomeForward: calls had to be replaced with<br>
> #becomeForward:copyHash: with second argument true.<br>
><br>
> This one is quite nasty.<br>
><br>
><br>
> 2)- setProperty:toValue:<br>
><br>
> Debuggers showed me all kind of objects receiving messages they had<br>
> nothing to do with. It seemed that object composition was scrambled, but<br>
> in fact...<br>
><br>
> #setProperty:toValue: semantics had changed<br>
><br>
> It now returns its second argument, so I had to add cascaded #yourself<br>
> calls in many places.<br>
><br>
> This one is nasty too.<br>
><br>
><br>
> 3)- immutable arrays<br>
><br>
> In a couple of places I did use arrays written in their now immutable<br>
> form to store data that would later be updated. I had to use other ways<br>
> to instanciate the arrays.<br>
><br>
> This one is bad IMO. Not the fact that arrays can (and should most<br>
> often) be immutable, but the fact the default way to write an #(array)<br>
> or a 'string' now has a different semantics. Assuming as before that we<br>
> get mutable objects leads to bugs that are easy to catch, but I am<br>
> afraid there may be old code laying around in SqueakMap or other<br>
> repositories that will now break. Well maybe I'm wrong about that.<br>
><br>
><br>
> 4)- FloatArray<br>
><br>
> FloatArray is now abstract; it must now be replaced with Float32Array.<br>
><br>
> Because I want muO to load and work both in 5.3 and 6.0 (which it does),<br>
> I had to to have the pre-installer create a dummy Float32Array class<br>
> before loading the muO code in 5.3.<br>
><br>
> No big deal, but again if some older forgotten packages are using<br>
> FloatArray, they will break.<br>
><br>
><br>
> 5)- beAllFont:<br>
><br>
> This one is minor but still, #beAllFont: semantics changed. In 5.3 it<br>
> used to update the font of an existing text morph, now it is the same as<br>
> #font: and cannot be used that way - it must be sent before the text is set.<br>
><br>
> I just reverted it to its 5.3 behavior for muO.<br>
><br>
><br>
> 6)- font sizes<br>
><br>
> In MuOTheme#addFonts: I had to give different font sizes numbers in 5.3<br>
> and 6.0 in order to get the same actual font sizes on screen. Not sure<br>
> what happened there, I guess a bug was fixed (because the font support<br>
> is much nicer now in 6.0) but still that's an incompatible change.<br>
><br>
><br>
> 7)- RealEstateAgent scaleFactor<br>
><br>
> The scale factor was by default initialized to 0.75 which made<br>
> everything tiny; in 5.3 it was 1.0.<br>
><br>
><br>
> 8) minor stuff now fixed<br>
><br>
> There where other minor issues that were fixed in the update stream<br>
> after I signaled them on squeak-dev. I'll just mention them for<br>
> completeness sake:<br>
><br>
>         - rehash was needed in SmartRefStream>>#next<br>
>         - #encompassing:, #merging: did not accept a Set anymore<br>
>         - a one-character wide TextMorph would not resize properly<br>
><br>
> All of this is now fine in 6.0, as of version 22110<br>
><br>
><br>
> All in all it was an interesting ride, and kudos to the developers for<br>
> all the work that went into 6.0!<br>
><br>
><br>
><br>
> Stef<br>
><br>
><br>
><br>
<br>
</blockquote></div>
</div></blockquote></div>