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
Hi Stef --
5)- beAllFont:
Did the commentary in #font: help you understand the relationship between fonts, text attributes, and text style? The most basic usage is to set a #textStyle: and then use #contents: maybe just with a string, not text. If it is a text, text attributes will override the defaults coming from the current text style. #font: is expected to work very similar to what #beAllFont: did. Hmm....
The scale factor was by default initialized to 0.75 which made everything tiny; in 5.3 it was 1.0.
Hmm... What's the platform you are working on? This should never happen in 6.0. 75% is a special case that must be selected by the user. It is never used automatically...
Best, Marcel Am 25.08.2022 12:27:59 schrieb Stéphane Rollandin lecteur@zogotounga.net: 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
The scale factor was by default initialized to 0.75 which made everything tiny; in 5.3 it was 1.0.
Hmm... What's the platform you are working on? This should never happen in 6.0. 75% is a special case that must be selected by the user. It is never used automatically...
Windows 8.1.
Yes, I can see it is 1.0 in a fresh image. And maybe it was 1.75, not 0.75 - in fact I do not remember the exact circonstances in which that came up, just that I wrote it down for reference, and also for a while had hardcoded its value to 1.0, but then reverted that change back.
I'm afraid my way of coding and debugging is very, very messy:)
So I guess you can just ignore that. That's a problem I had, that I do not have any more, and that may be very specific to the various hacks in muO.
Stef
5)- beAllFont:
Did the commentary in #font: help you understand the relationship between fonts, text attributes, and text style? The most basic usage is to set a #textStyle: and then use #contents: maybe just with a string, not text. If it is a text, text attributes will override the defaults coming from the current text style. #font: is expected to work very similar to what #beAllFont: did. Hmm....
No, I do not have a clear picture of this all - only that #beAllFont: does not do what it did previously, and that I restored its previous implementation in muO.
Stef
BTW for info about the scope of muO:
(PackageInfo named: 'MuO') classes size 998 (PackageInfo named: 'MuO') methods size 25253 (PackageInfo named: 'MuO') linesOfCode 135870
vs, for example,
(PackageInfo named: 'Etoys') classes size 455 (PackageInfo named: 'Etoys') methods size 9957 (PackageInfo named: 'Etoys') linesOfCode 73860
(PackageInfo named: 'Morphic') classes size 210 (PackageInfo named: 'Morphic') methods size 8499 (PackageInfo named: 'Morphic') linesOfCode 56500
Stef
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@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.
- 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
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@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@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.
- 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
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@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@gmail.com [mailto:asqueaker@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@zogotounga.net [mailto:lecteur@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.
- 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
squeak-dev@lists.squeakfoundation.org