what's the plan for Etoys in trunk?

Hi all,

Does anyone know the state of Etoys in trunk?  I just noticed that it
has brought its own "HtmlDocument" into Squeak, along with some other
very-likely-to-be-in-external-packages classes like "ChessBoard" and
"PDA".

That, and looking at the number of methods by each major package
prefix in the image, I think it's begging to be unloaded from the
release image, but when I tried to do that from the MC browser, I got
an emergency evaluator.

 - Chris

 'Morphic -> 11373
EToys -> 10105
Kernel -> 4151
System -> 4143
Collections -> 3776
MorphicExtras -> 3233
Graphics -> 2880
Tools -> 2842
Monticello -> 1934
Connectors -> 1742
Network -> 1621
Tests -> 1621
ST80 -> 1539
Compiler -> 1383
OSProcess -> 1140
ToolBuilder -> 1126
Sound -> 1099
CollectionsTests -> 1030
Chronology -> 874
Multilingual -> 852
Nebraska -> 775
KernelTests -> 681
RFB -> 667
WebClient -> 611
SMBase -> 610
Files -> 541
XML -> 539
Regex -> 523
SUnit -> 503
Compression -> 468
Balloon -> 465
TrueType -> 424
Help -> 412
Installer -> 401
SMLoader -> 371
Protocols -> 361
Traits -> 349
PreferenceBrowser -> 347
GeoNames -> 334
ConnectorsShapes -> 310
HelpSystem -> 280
PlotMorph -> 267
FSM -> 257
Services -> 229
MorphicTests -> 210
51Deprecated -> 203
NetworkTests -> 188
ShoutCore -> 183
Environments -> 181
MonticelloConfigurations -> 180
ToolsTests -> 166
XMLPullParser -> 154
GetText -> 153
GraphicsTests -> 150
SystemChangeNotification -> 134
TraitsTests -> 128
SUnitGUI -> 127
CsvImporter -> 126
Squeak -> 124
SqueakSSL -> 124
PackageInfo -> 122
45Deprecated -> 92
60Deprecated -> 90
MultilingualTests -> 77
ReleaseBuilder -> 65
UpdateStream -> 65
SystemReporter -> 52
VersionNumber -> 50
46Deprecated -> 31
ST80Tests -> 27
CommandLine -> 25
SUnitTools -> 22
ST80Tools -> 16
ShoutTests -> 14
VersionNumberTests -> 13
CGPrereqs -> 8
MorphicExtrasTests -> 3
39Deprecated -> 3
MonticelloForTraits -> 2
BalloonTests -> 1
TrunkScript -> 0
'

I kinda think the latest merger with EToys was not perfect, and the
package took over some methods already present in the image.
I know for sure that it reintroduced several already obsoleted and removed
methods.
But, the previous version of EToys was not unloadable either.

Levente

On Tue, 5 Jun 2018, Chris Muller wrote:

On Tue, Jun 5, 2018 at 4:29 PM, Levente Uzonyi <[hidden email]> wrote:
> I kinda think the latest merger with EToys was not perfect, and the package
> took over some methods already present in the image.

Not only methods but in some cases, entire classes.  This has led me
to remove some of those code elements from their original standalone
package, since they now exist in the "Etoys" package in trunk.  But
now I'm second-guessing that.  Even if we _could_ unload Etoys, it'd
leave those external packages now broken and incomplete.

Some guidance from the Etoys team would be immensely helpful.  It's
feeling impossible to move forward on the 5.2 release...

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
5.2 release.

Best,
Marcel



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Hi all,

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.

cheers,
Tim

-----Original Message-----
From: marcel.taeumel <[hidden email]>
Reply-to: The general-purpose Squeak developers list
 <[hidden email]>
To: [hidden email]
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
5.2 release.

Best,
Marcel



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

At least !
For eras I beg for a Core Release, that means without several packages which
could or not be loaded later.


Edgar
@morplenauta



On 05/06/2018, 18:07, "Chris Muller" <[hidden email]> wrote:

> Hi all,

Does anyone know the state of Etoys in trunk?  I just noticed that
> it
has brought its own "HtmlDocument" into Squeak, along with some
> other
very-likely-to-be-in-external-packages classes like "ChessBoard"
> and
"PDA".

That, and looking at the number of methods by each major
> package
prefix in the image, I think it's begging to be unloaded from
> the
release image, but when I tried to do that from the MC browser, I got
an
> emergency evaluator.

 - Chris

Yes,
I do this in my own images and unload Etoys.
Do not test if Etoys could or not be loaded again and Etoys projects works.
Try to do now with up to date 5.2


On 06/06/2018, 06:09, "[hidden email]" <[hidden email]>
wrote:

> 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.

Hello Edgar
On 6/6/18, Edgar J. De Cleene <[hidden email]> wrote:
> Yes,
> I do this in my own images and unload Etoys.

Which script do you use to unload Etoys?

> Do not test if Etoys could or not be loaded again and Etoys projects works.
> Try to do now with up to date 5.2

Could you please add what you do to the test plan so that it can be
re-done easily later by somebody else?


Regards
Hannes

I'm working, sorry I was slooow :=)
Just I take Monticello and select Etoys , then unload.
Discover

addStackMenuItems: menu hand: aHandMorph
    "Add appropriate stack-related items to the given menu"

    self isStackBackground
        ifTrue:
            [menu add: 'card & stack...' target: self action:
#presentCardAndStackMenu]

IsStackBackground is not in Squeak5.2alpha-18059-32bit.changes-32bit which
is the today update.

Any idea of which user/pass I could use for access
http://ftp.squeak.org/Experiments/

Like add a ftp server to FileList


On 06/06/2018, 09:54, "H. Hirzel" <[hidden email]> wrote:

> Could you please add what you do to the test plan so that it can be
re-done
> easily later by somebody else?


Regards
Hannes

On Wednesday 06 June 2018 02:39 PM, [hidden email] wrote:
> 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.
Where can I find an image with these changes? The trunk (18059) still
shows Morph>>rotationCenter in *Etoys-geometry.

On this trunk, after I unload Etoys package, even a mouse move throws up
a emergency evaluator.

The messages in the *Etoys-geometry don't use Player, so I tried moving
them all into geometry category with:

(Morph methodsInCategory: '*Etoys-geometry')
     do: [:m | Morph organization classify: m under: 'geometry'].

Then I am able to unload Etoys package without any error and the viewer
halo opens an Inspector. But PartsBin gives a DNU. Looks like Etoys
unload is too aggressive in removing methods.

Regards .. Subbu

I update today to 18059 then move few methods to feometry instead of
*Etoys-geometry
Image works  but complains often.
I found you need move all methods out of *Etoys-geometry to Morph geometry,
no complains.

Still you have problems when try to load Etoys project like the attached.
The .pr loads fine before the upload


On 06/06/2018, 13:24, "K K Subbu" <[hidden email]> wrote:

> On this trunk, after I unload Etoys package, even a mouse move throws up
a
> emergency evaluator.

The messages in the *Etoys-geometry don't use Player, so
> I tried moving
them all into geometry category with:

(Morph
> methodsInCategory: '*Etoys-geometry')
     do: [:m | Morph organization
> classify: m under: 'geometry'].

Then I am able to unload Etoys package
> without any error and the viewer
halo opens an Inspector. But PartsBin gives
> a DNU. Looks like Etoys
unload is too aggressive in removing
> methods.

Regards .. Subbu