If I were to sketch out a high level project plan for "make Etoys separable" it might look like this:
(X) Figure out how to make a trunk-without-etoys image from existing trunk (Marcel) - Recode methods and some classes - Remove Etoys related preferences - Remove Etoys related globals - Remove as many methods and classes as possible (X) Separate all methods and classes that do not require refactoring (Dave) - Identify differences between trunk and trunk-without-etoys (using Montecello packages) - Move Etoys only classes and methods to Etoys package extensions (committed to trunk) - Move Etoys things to base packages if used in the trunk-without-etoys image (committed to trunk) (_) Refactor the hard stuff (methods and classes that differ between trunk and trunk-without-etoys) - Identify classes and methods requiring refactoring (done by Dave but not published to list) - Refactor methods (lots of them, many may be easy, some will be hard) - Refactor classes that have Etoys only instance variables - If class shapes change, make image segments and project imports work (_) Clean up preferences and globals (probably from Marcel's script) (_) Make Etoys unloading work (without ongoing support as trunk changes) - Make unloading script (possibly a much simpler version of Marcel's original) - Make the tests pass after unloading (_) Extra credit - make Etoys reloading work - Verify that package(s) can be loaded - Figure out how to restore state (non-code things lost in the removal) - Make tests pass again - Worlds of Squeak, Etoys return to life
If this makes sense maybe we can put it on a swiki page and let people check the boxes as we make progress.
Dave
On Sat, Dec 30 2023 at 04:44:50 PM +0100, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave,
thank you for this clarification! Now I can better understand your changes. I was just confused by the process in which these changes are integrated into the trunk, but I guess this is fine since it could mean that we are committing to making trunk-without-etoys reality before the next release. :-)
Best, Christoph
/Sent from//_Squeak Inbox Talk_ https://github.com/hpi-swa-lab/squeak-inbox-talk/
On 2023-12-26T18:57:06+00:00, lewis@mail.msen.com wrote:
Hi Christoph,
When I said "trunk-without-etoys" I meant a trunk image after
running
Marcel's unload-etoys script. This is quite different from what
you will
see if you just remove the Etoys package from trunk.
For the example of #wantsHalo, here are the steps to reproduce:
- Start with trunk image Squeak6.1alpha-22743-64bit.zip
https://files.squeak.org/trunk/Squeak6.1alpha-22743-64bit/
- In that image, run the unload-etoys.33.cs change set
(attachment to
Marcel's email of 29-Aug-2023):
https://lists.squeakfoundation.org/archives/list/squeak-dev(a)lists.squeakfo...
This is now a "trunk-without-etoys" image.
Look for senders of #wantsHalo. There are none.
Look at Morph>>handleMouseEnter: to confirm that it no longer
sends
#wantsHalo. The method history shows that this is one of many refactorings that Marcel did to clean up the separation of Etoys.
Dave
On 2023-12-26 17:41, christoph.thiede(a)student.hpi.uni-potsdam.de
wrote:
Hi Dave, Hi Marcel,
On 2023-12-17T10:08:27-05:00, lewis(a)mail.msen.com wrote:
Hi Christoph,
The idea is to compare the trunk image to the
trunk-without-etoys
image, where trunk-without-etoys is the result of running Marcel's
script.
Methods that exist only in the trunk image are assumed to be
used only
by Etoys, and are categorized under *Etoys.
Methods that are identical in both images are assumed to belong
in
trunk, and are moved out of Etoys.
Methods (and class definitions) that exist in both images but
are
different are set aside for future refactoring.
thanks for the context!
For example, #wantsHalo may or may not be a method of general
interest
for trunk, but since it is never used in trunk-without-etoys, we assume that it is somehow related to Etoys usage and does not need to
be in
trunk.
No, #wantsHalo is indeed used in the Trunk-without-etoys. See Morph>>#handleMouseEnter:. :-)
Certainly many of these category changes will turn out to be
wrong,
but it's a start.
So we could just move back the methods I mentioned in my previous message under point 1 to the Trunk? Who has classified them as "Etoys-only" - you or Marcel? I'm still trying to understand how
this
classification has been decided. :-)
Dave
On 2023-12-16T21:44:42+01:00, christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
Hi Dave, hi Marcel, hi all,
first, thank you a lot for working on this important
refactoring!
I have finally found some time to take a briefly look at these changes (dtl's commits from 2023-11-25f.) and are confused by many of
them.
Maybe you can help me understand the overall goal? :-) These
changes
move many methods from other packages into the Trunk despite
they are
still used in these other packages. I have made a
non-exhaustive list
that fills about three workspaces, I will just briefly sketch
two
categorizes:
- Logic that IMHO belongs into a base package indeed: Morphic
halo
invocation (#wantsHalo, #triggerHaloFor:after:, #removePendingHaloFor:), Morphic halo's duplicate handles, Morph>>#addMorphNearBack:, Morphic undo (MenuMorph>>#undoGrabCommand), annotation setup (docking bar > extras), ProjectLauncher
startUp
(afaik currently responsible for running changesets provided via
command
line). I am unsure about uniclasses: Should they belong into
the
trunk? I like to use a quick #newSubclass in different
scripting/testing
situations. 2. Logic that does belong to Etoys but is still intertwined
with the
original package. If we unload the Etoys package today, this
will
lead to DNUs in the trunk. Many of them might require better hooks
(e.g.,
pragmas or registries) in the base packages. This is probably expected at the current state of making Etoys optional, but I'm listing
them
here for later reference anyway: Menu items in
inspector/explorer
(use menu pragmas consistently, introduce pragmas for keyboard
shortcuts),
CodeHolder>>#restoreTextualCodingPane,
DeepCopier>>#mapUniClasses
(generic global fixup hook*), NativeImageSegment>>#rootsIncludingPlayers, several preferences (haloTransitions, captializedReferences, ...), ReleaseBuilder ebautifyEtoys, ObjectlandMorph etoysProject 2b. Logic that belongs to Etoys but abuses an unused internal
hook of
a base package class: MorphicModel>>#addModelYellowButtonMenuItemsTo:forMorph:hand:, PasteUpMorph>>#drawOn: - this will conflict once we decide
that these
classes want to use these hooks themselves, so they also would require an explicit hook in the long term.
Again, thank you a lot, and I am looking forward to talk about
these
questions again, in particular about the first category. :-)
Best, Christoph
Best, Christoph
_Sent from __Squeak Inbox Talk [1]_
Links: