Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
In working in both Squeak and Cuis, I’m a bit shocked by the bloat in Squeak (2833 classes vs 678 in Cuis) and wondered if anyone had a script to remove all the Etoys stuff, Nebraska and the various test categories.
It’d be great if there was a procedure to start with a smaller Squeak image (1000 classes or so) and file in the packages that go beyond the basic development environment. This would also make the system much more approachable to new-comers.
stp
--------
Stephen Travis Pope Ojai, California, USA  http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
And... a test of that shows that we're almsot ther but, for example, LeafNode>>#key: exisats in both *Etoys-Squeakland-Tweak-Kedama and Compiler-ParseNodes for some reason. With it removed, we can't open a debugger. :-O
On 2023-01-01, at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
Well I guess if nobody else is bothered by the bloat and chaos in the protocols — and the impact these have on the learnability of the system -- I’m not going to take it on real soon…
stp
--------
Stephen Travis Pope Ojai, California, USA  http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 1, 2023, at 5:51 PM, tim Rowledge tim@rowledge.org wrote:
And... a test of that shows that we're almsot ther but, for example, LeafNode>>#key: exisats in both *Etoys-Squeakland-Tweak-Kedama and Compiler-ParseNodes for some reason. With it removed, we can't open a debugger. :-O
On 2023-01-01, at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser. And indeed, that might be a side-effect of the way that some of those lists are, as you mention, pretty long. Some of it is likely due to the list-filtering UI capability we have as well.
It is certainly an interesting problem as to how one might make the protocol lists simpler. Part of the problem is that we still need tools to manage the contents of packages, and to keep some compatibility. I suppose one could make the browser examine any protocols starting with * and display any contained methods in a protocol of the "same name minus package cruft", assuming that the class has one. But after that, how would we know that the method belongs in a package other than the one for the class? Tools are hard to make well.
On 2023-01-03, at 3:10 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Well I guess if nobody else is bothered by the bloat and chaos in the protocols — and the impact these have on the learnability of the system -- I’m not going to take it on real soon…
stp
Stephen Travis Pope Ojai, California, USA <pastedGraphic.tiff> http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 1, 2023, at 5:51 PM, tim Rowledge tim@rowledge.org wrote:
And... a test of that shows that we're almsot ther but, for example, LeafNode>>#key: exisats in both *Etoys-Squeakland-Tweak-Kedama and Compiler-ParseNodes for some reason. With it removed, we can't open a debugger. :-O
On 2023-01-01, at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never write software that patronizes the user.
The idea in Smalltalk-80 was that the 5 lists in the 6-paned browser (i.e., with the package pane) rarely needed scrollbars, i.e., that there would be 12 or fewer items at each level of the hierarchy of packages, categories, classes, protocols and methods (see the screen shot below from Cuis 6).

Of course, for a system with the number of packages that Squeak 6.0 has, there will certainly be packages with many more categories, and categories with more classes, but to start with 80 or so top-level items in the package pane is certainly not an invitation to poke around…
I’m sorry to be complaining, and it’s quite an impressive accomplishment what’s all in there, but a little effort to make it easier to find things would go a long way.
Flame off.
stp
--------
Stephen Travis Pope Ojai, California, USA  http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 3, 2023, at 3:23 PM, tim Rowledge tim@rowledge.org wrote:
I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser. And indeed, that might be a side-effect of the way that some of those lists are, as you mention, pretty long. Some of it is likely due to the list-filtering UI capability we have as well.
It is certainly an interesting problem as to how one might make the protocol lists simpler. Part of the problem is that we still need tools to manage the contents of packages, and to keep some compatibility. I suppose one could make the browser examine any protocols starting with * and display any contained methods in a protocol of the "same name minus package cruft", assuming that the class has one. But after that, how would we know that the method belongs in a package other than the one for the class? Tools are hard to make well.
On 2023-01-03, at 3:10 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Well I guess if nobody else is bothered by the bloat and chaos in the protocols — and the impact these have on the learnability of the system -- I’m not going to take it on real soon…
stp
Stephen Travis Pope Ojai, California, USA <pastedGraphic.tiff> http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 1, 2023, at 5:51 PM, tim Rowledge tim@rowledge.org wrote:
And... a test of that shows that we're almsot ther but, for example, LeafNode>>#key: exisats in both *Etoys-Squeakland-Tweak-Kedama and Compiler-ParseNodes for some reason. With it removed, we can't open a debugger. :-O
On 2023-01-01, at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never write software that patronizes the user.
On 2023-01-03, at 3:35 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
The idea in Smalltalk-80 was that the 5 lists in the 6-paned browser (i.e., with the package pane) rarely needed scrollbars, i.e., that there would be 12 or fewer items at each level of the hierarchy of packages, categories, classes, protocols and methods (see the screen shot below from Cuis 6).
I understand, remember, and agree with the aspiration (don't forget, I started out as a UI researcher decades ago) but I think we would need a lot of work to get close to that in a modern system.
There would need to be some package/protocol renaming etc to make the 6-pane layout work as cleanly as it might. It looks to me that some cleverer parsing of names might help.
Flame off.
Keep the flames burning. It's how we make progress
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There's a guy works down the fish shop swears he's elvish...
Re: “I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser.”
If we used them as-intended, to categorize methods according to function (e.g., accessing, printing, instance creation, etc.), it would make finding things much easier!
stp
--------
Stephen Travis Pope Ojai, California, USA  http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 3, 2023, at 3:23 PM, tim Rowledge tim@rowledge.org wrote:
I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser. And indeed, that might be a side-effect of the way that some of those lists are, as you mention, pretty long. Some of it is likely due to the list-filtering UI capability we have as well.
It is certainly an interesting problem as to how one might make the protocol lists simpler. Part of the problem is that we still need tools to manage the contents of packages, and to keep some compatibility. I suppose one could make the browser examine any protocols starting with * and display any contained methods in a protocol of the "same name minus package cruft", assuming that the class has one. But after that, how would we know that the method belongs in a package other than the one for the class? Tools are hard to make well.
On 2023-01-03, at 3:10 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Well I guess if nobody else is bothered by the bloat and chaos in the protocols — and the impact these have on the learnability of the system -- I’m not going to take it on real soon…
stp
Stephen Travis Pope Ojai, California, USA <pastedGraphic.tiff> http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 1, 2023, at 5:51 PM, tim Rowledge tim@rowledge.org wrote:
And... a test of that shows that we're almsot ther but, for example, LeafNode>>#key: exisats in both *Etoys-Squeakland-Tweak-Kedama and Compiler-ParseNodes for some reason. With it removed, we can't open a debugger. :-O
On 2023-01-01, at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
The expectation (not completely met) is that simply removing the packages will work. Last time I tried it *almost* worked to remove EToys, for example. Reducing inter-package dependencies can be time consuming and it is so very easy to accidentally (re)add one.
You can try removing packages by opening a Monticello Browser selecting the package menu 'unload' wait... hope...
On 2023-01-01, at 1:12 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Hi Squeakers!
In the olden days of ParcPlace, we had 2 tools for “pruning” images: a Stripper could be configures to remove unused classes from an image (e.g., Dev tools, PostScript output) while aWhittler identified unused methods in classes that were being kept (like the package-specific method categories in the system classes as well).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- MERCI RIEN - Thanks for nothin'.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim ..... REALITY.SYS Corrupted - Unable to recover Universe
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never write software that patronizes the user.
On 2023-01-03, at 3:52 PM, Stephen Travis Pope stephen@heaveneverywhere.com wrote:
Re: “I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser.”
If we used them as-intended, to categorize methods according to function (e.g., accessing, printing, instance creation, etc.), it would make finding things much easier!
No argument at all with that.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: APX: Apply Power and eXplode
Hi,
Re: “I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser.”
If we used them as-intended, to categorize methods according to function (e.g., accessing, printing, instance creation, etc.), it would make finding things much easier!
I don't know whether everyone is already aware of this, or whether it'd even be helpful at all -- but for the *packagename categories, it is allowed for them to be merely *prefixed* with the package name. *packagename-accessing and *packagename-testing will both be identified as belonging to the package whose prefix matches that name.
Then, it'd be possible with "Filterable Lists" enabled, to simply type "acc" in the categories pane to show all just the "accessing" protocols, albeit, broken out by package (maybe IDE enhancement could compress them into one, but then how to move extensions between packages..). Not perfect, but can be done with the IDE today.
- Chris
Great idea! In fact, many of the ‘*’ protocols have the old names appended, as in,
*Etoys-Squeakland-accessing *System-Recovery-error handling
but just as many don’t, as in,
*Morphic *monticello
It’d be a step in the right direction to have the browser merge the first group into the “base” protocol.
stp
--------
Stephen Travis Pope Ojai, California, USA  http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 3, 2023, at 7:33 PM, Chris Muller asqueaker@gmail.com wrote:
Hi,
Re: “I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser.”
If we used them as-intended, to categorize methods according to function (e.g., accessing, printing, instance creation, etc.), it would make finding things much easier!
I don't know whether everyone is already aware of this, or whether it'd even be helpful at all -- but for the *packagename categories, it is allowed for them to be merely *prefixed* with the package name. *packagename-accessing and *packagename-testing will both be identified as belonging to the package whose prefix matches that name.
Then, it'd be possible with "Filterable Lists" enabled, to simply type "acc" in the categories pane to show all just the "accessing" protocols, albeit, broken out by package (maybe IDE enhancement could compress them into one, but then how to move extensions between packages..). Not perfect, but can be done with the IDE today.
- Chris
Hi all --
It is good style to append the actual protocol name to the package name. That is, "*Etoys-Squeakland-accessing" is more organized than "*Etoys-Squeakland".
It is important for the programmer to realize that using a message from, for example, "*Etoys-Squeakland-accessing" entails a dependency to the Etoys(-Squeakland) package. Therefore, it would make things more complicated if we would (visually) merge package-specific protocols into base protocols such as "*Etoys-Squeakland-accessing" into "accessing". Take #x and #y compared to #left and #top. Two different coordinate systems (not just a different name); the former from Etoys, the latter from base Morphic.
An arbitrary metric like "not more than 1000 classes" or "no visible scroll bars" is not a good metric (or goal) to clean up the system and move forward in a meaningful way. As Tim suggested, more work needs to be done in understanding what is there from Etoys lurking in the base system and how the base system depends on Etoys-specific stuff. After untangling that stuff, we might consider unloading the Etoys package. I am still willing to invest more time into that.
@Stephen: For a more recent approach similar to Stripper/Whittler, maybe take a look at what Craig does with Caffeine: https://thiscontext.com/2019/03/25/the-big-shake-out/ --- Turns out that it is not that easy to identify unused code and keep the system as robust as it was before. When is a utility method not used anymore? If you do not need it in your workspace? If nobody does? Who decides? :-)
Best, Marcel
Am 04.01.2023 16:26:28 schrieb Stephen Travis Pope stephen@heaveneverywhere.com:
Great idea! In fact, many of the ‘*’ protocols have the old names appended, as in,
*Etoys-Squeakland-accessing *System-Recovery-error handling
but just as many don’t, as in,
*Morphic *monticello
It’d be a step in the right direction to have the browser merge the first group into the “base” protocol.
stp
--------
Stephen Travis Pope Ojai, California, USA pastedGraphic.tiffcid:55B397C7-3D20-4E60-A051-4564245235A7@sd.cox.net http://HeavenEverywhere.com http://FASTLabInc.com https://vimeo.com/user19434036/videos http://heaveneverywhere.com/Reflections
On Jan 3, 2023, at 7:33 PM, Chris Muller asqueaker@gmail.com wrote:
Hi,
Re: “I'm not sure how much attention anyone ends up paying to the message protocols lists in the browser.”
If we used them as-intended, to categorize methods according to function (e.g., accessing, printing, instance creation, etc.), it would make finding things much easier!
I don't know whether everyone is already aware of this, or whether it'd even be helpful at all -- but for the *packagename categories, it is allowed for them to be merely *prefixed* with the package name. *packagename-accessing and *packagename-testing will both be identified as belonging to the package whose prefix matches that name.
Then, it'd be possible with "Filterable Lists" enabled, to simply type "acc" in the categories pane to show all just the "accessing" protocols, albeit, broken out by package (maybe IDE enhancement could compress them into one, but then how to move extensions between packages..). Not perfect, but can be done with the IDE today.
- Chris
squeak-dev@lists.squeakfoundation.org