[squeak-dev] what's the plan for Etoys in trunk?
timfelgentreff at gmail.com
timfelgentreff at gmail.com
Wed Jun 6 09:09:16 UTC 2018
making sure we get the deprecated sends out of the Etoys code and renaming and/or moving some of the
classes is surely necessary. Etoys should also, I guess, be split into multiple packages so that not
all games and extras are mashed together with the core functionality.
However, during the merge we took extreme care not to replace classes or methods outright and we
manually went through hundreds of methods to manually categorize and merge them in a way that would
keep unloading working as much as it did before.
Etoys unload works in a 5.2 image exactly as well as it did in 5.0, before the merge. Even in a 5.0
image before the merge, unloading Etoys removes some important methods (e.g.
Morph>>#rotationCenter:) that are send to all morphs from code in Morphic-Kernel and thus (unless
you are *extremely* careful), you'll end up in the emergency evaluator after a while.
Just reverting the merge won't help you, even then you'll have to go through and actually fix all
those arguably mis-categorized methods and classes to get Etoys to unload cleanly.
Just for the heck of it, I went ahead and moved *only* Morph>>rotationCenter and
Morph>>rotationCenter: into the `geometry` category (from *Etoys-geometry). After that, and unload
of the Etoys packages leaves you with a mostly working image. If you open the PartsBin, you'll get a
few more DNUs, but after moving a few more methods (scale, positionInWorld), the PartsBin also
works, now without all the Etoys stuff.
From: marcel.taeumel <Marcel.Taeumel at hpi.de>
Reply-to: The general-purpose Squeak developers list
<squeak-dev at lists.squeakfoundation.org>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [squeak-dev] what's the plan for Etoys in trunk?
Date: Wed, 6 Jun 2018 01:06:18 -0700 (MST)
Etoys is one of the reasons we do not go for 6.0 but keep it 5.2. Too much
work ahead to improve modularization for Etoys, which was also not good
before the merger.
What we could do is to scan those deprecated messages and make sure they do
not get sent in the Trunk. Meaning all *Deprecated packages. The Etoys
merger introduced some again.
The Etoys merger added some nice games, which can be played via the Objects
catalog. :-) Including Chess.
Plain unloading of packages or classes that have not been there in 5.1 is
not a good way to move forward. We have to understand the concepts and
mechanics first and then propose some useful refactorings of the code. Etoys
is a great chance to discover valuable extension points in our tools and
code base. Yet, this takes more time than we seem to have available for the
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
More information about the Squeak-dev