Unloading EToys from Squeak Image

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Unloading EToys from Squeak Image

Squeak - Dev mailing list
All,

I would like to unload the EToys packages from image.

I tried with the Monticello Browser, unloading seems to proceed. But at the end nothing is reacting anymore.

Any hint on how to successfully unload the EToys?

Should I use a workspace in an MVC project?

Kind regards,

Arjen


Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

David T. Lewis
On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via Squeak-dev wrote:

> All,
>
> I would like to unload the EToys packages from image.
>
> I tried with the Monticello Browser, unloading seems to proceed. But at the end nothing is reacting anymore.
>
> Any hint on how to successfully unload the EToys?
>
> Should I use a workspace in an MVC project?
>

Hello Arjen,

I don't think that unloading works yet, but hopefully soon. The
goal is to make Etoys reloadable, which means that it can be fully
removed from the image, and also reinstalled into an image from
which it has been removed.

A lot of good work has gone into this in the last few years, but
it is not complete. If you do any work on this yourself, any input
would be welcome either as inbox contributions or messages to
the list here.

I should mention also that this topic came up (again!) in the
last online meeting of our Squeak oversight board and it is on
our agenda for the next meeting. I think everyone agrees that
this is important to do, it's just a small matter of somebody
doing the work ;-)

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

Hannes Hirzel
Hi Arjen

The instructions in
    http://wiki.squeak.org/squeak/2848
(Squeak 5.3)
worked for me some time ago.

1.
The main point before unloading is to reclassify some methods
currently belonging to Etoys to the general Squeak as they are needed
for Squeak to work.

2.
After reclassifying unloading of Etoys works.

3.
However some more fixes need to be done in order to have the remaining
code not call Etoys methods which are no longer there.

To all: the necessary fixes are all quite simple. However the steps
need to be checked also with the current trunk image. The fixes would
also be useful to be added to Squeak 5.3

HTH

Hannes

On 1/23/21, David T. Lewis <[hidden email]> wrote:

> On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via Squeak-dev
> wrote:
>> All,
>>
>> I would like to unload the EToys packages from image.
>>
>> I tried with the Monticello Browser, unloading seems to proceed. But at
>> the end nothing is reacting anymore.
>>
>> Any hint on how to successfully unload the EToys?
>>
>> Should I use a workspace in an MVC project?
>>
>
> Hello Arjen,
>
> I don't think that unloading works yet, but hopefully soon. The
> goal is to make Etoys reloadable, which means that it can be fully
> removed from the image, and also reinstalled into an image from
> which it has been removed.
>
> A lot of good work has gone into this in the last few years, but
> it is not complete. If you do any work on this yourself, any input
> would be welcome either as inbox contributions or messages to
> the list here.
>
> I should mention also that this topic came up (again!) in the
> last online meeting of our Squeak oversight board and it is on
> our agenda for the next meeting. I think everyone agrees that
> this is important to do, it's just a small matter of somebody
> doing the work ;-)
>
> Dave
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

Eliot Miranda-2
Hi Hannes, Hi All,

On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel <[hidden email]> wrote:
Hi Arjen

The instructions in
    http://wiki.squeak.org/squeak/2848
(Squeak 5.3)
worked for me some time ago.

1.
The main point before unloading is to reclassify some methods
currently belonging to Etoys to the general Squeak as they are needed
for Squeak to work.

2.
After reclassifying unloading of Etoys works.

3.
However some more fixes need to be done in order to have the remaining
code not call Etoys methods which are no longer there.

To all: the necessary fixes are all quite simple. However the steps
need to be checked also with the current trunk image. The fixes would
also be useful to be added to Squeak 5.3
Let's do this work.  I just moved a couple of copyright methods from EToys to System in System-eem.1212.  What is preventing people from committing changes to get us to the goal of an unloadable EToys?

I also heard recently that EToys is not functional.  IIRC this isn't quite correct; it's that older ETys projects don't currently load into a Squeak trunk EToys.  But now that Vanessa has implemented the segment loader above the VM we at least have the infrastructure.  Who has the time and energy to try and get older EToys projects to load and run?  And does someone have a (hopefully short) list of older EToys projects of particular value we should focus on?


HTH

Hannes

On 1/23/21, David T. Lewis <[hidden email]> wrote:
> On Thu, Jan 21, 2021 at 12:07:06PM +0000, Arjen van Elteren via Squeak-dev
> wrote:
>> All,
>>
>> I would like to unload the EToys packages from image.
>>
>> I tried with the Monticello Browser, unloading seems to proceed. But at
>> the end nothing is reacting anymore.
>>
>> Any hint on how to successfully unload the EToys?
>>
>> Should I use a workspace in an MVC project?
>>
>
> Hello Arjen,
>
> I don't think that unloading works yet, but hopefully soon. The
> goal is to make Etoys reloadable, which means that it can be fully
> removed from the image, and also reinstalled into an image from
> which it has been removed.
>
> A lot of good work has gone into this in the last few years, but
> it is not complete. If you do any work on this yourself, any input
> would be welcome either as inbox contributions or messages to
> the list here.
>
> I should mention also that this topic came up (again!) in the
> last online meeting of our Squeak oversight board and it is on
> our agenda for the next meeting. I think everyone agrees that
> this is important to do, it's just a small matter of somebody
> doing the work ;-)
>
> Dave
>
>
>



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

David T. Lewis
On Tue, Jan 26, 2021 at 02:17:24PM -0800, Eliot Miranda wrote:

> On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel <[hidden email]> wrote:
> >
> > To all: the necessary fixes are all quite simple. However the steps
> > need to be checked also with the current trunk image. The fixes would
> > also be useful to be added to Squeak 5.3
> >
> Let's do this work.  I just moved a couple of copyright methods from EToys
> to System in System-eem.1212.  What is preventing people from committing
> changes to get us to the goal of an unloadable EToys?
>

I followed the instructions at http://wiki.squeak.org/squeak/2848 and
completed the steps in paragraph 2.1.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

marcel.taeumel
Hi all!

Note that having the Etoys package as part of Trunk helps us very much to untangle Etoys-specific stuff not labeled "Etoys" at category or class level. In particular, it makes the "senders" and "implementors" tools more useful.

Some examples:

Morph >> #player in "Morphic-Kernel" / "accessing"
BookMorph >> #goto: in "MorphicExtras-Books" / "navigation"
HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer"
Morph >> #isTileMorph in "Morphic-Kernel" / "classification"
HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles"

So, it's good that the system keeps running after trying to unload the Etoys package. Let's not do this in Trunk (for now).

:-)

Best,
Marcel

P.S.: Etoys is basically working in Squeak 5.3 and Trunk. Yes, there are many bugs or regressions because only very few people are "using" it these days.

Am 29.01.2021 03:40:05 schrieb David T. Lewis <[hidden email]>:

On Tue, Jan 26, 2021 at 02:17:24PM -0800, Eliot Miranda wrote:

> On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel wrote:
> >
> > To all: the necessary fixes are all quite simple. However the steps
> > need to be checked also with the current trunk image. The fixes would
> > also be useful to be added to Squeak 5.3
> >
> Let's do this work. I just moved a couple of copyright methods from EToys
> to System in System-eem.1212. What is preventing people from committing
> changes to get us to the goal of an unloadable EToys?
>

I followed the instructions at http://wiki.squeak.org/squeak/2848 and
completed the steps in paragraph 2.1.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

K K Subbu
On 29/01/21 2:54 pm, Marcel Taeumel wrote:
>
> Morph >> #player in "Morphic-Kernel" / "accessing"
> BookMorph >> #goto: in "MorphicExtras-Books" / "navigation"
> HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer"
> Morph >> #isTileMorph in "Morphic-Kernel" / "classification"
> HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles"

IIRC, Etoys was an experiment in visual programming for children too
young to program via text but made fairly (hindsight!) intrusive changes
to Morphic. Etoys was organically bound into Squeak; like conjoint twins.

But that was then and this is now. Instead of shooting for a reloadable
Etoys, what if the next Squeak release makes a clean break from Etoys?

I propose that we slim down Squeak by removing all Etoys-related code by
without trying to ensure that existing Etoys package successfully loads
back into the image. This will slim down Squeak significantly and ease
its maintenance.

The largest user base for Etoys was on XO laptop. Those users are
unlikely to upgrade to new Squeak. Also, porting Etoys package to load
into slimmer Squeak may be an easier and better way to continue research
than striving to maintain both in the released image.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

marcel.taeumel
Hi Subbu.

But that was then and this is now. Instead of shooting for a reloadable
> Etoys, what if the next Squeak release makes a clean break from Etoys?

That's not what I was going for. Etoys includes hints for userful extension points in the base system. Instead of just deleting code, one could take a look at it and rewrite it to present a less invasive extension. ;-) This takes some effort, of course.

Best,
Marcel

Am 29.01.2021 13:22:54 schrieb K K Subbu <[hidden email]>:

On 29/01/21 2:54 pm, Marcel Taeumel wrote:
>
> Morph >> #player in "Morphic-Kernel" / "accessing"
> BookMorph >> #goto: in "MorphicExtras-Books" / "navigation"
> HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer"
> Morph >> #isTileMorph in "Morphic-Kernel" / "classification"
> HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles"

IIRC, Etoys was an experiment in visual programming for children too
young to program via text but made fairly (hindsight!) intrusive changes
to Morphic. Etoys was organically bound into Squeak; like conjoint twins.

But that was then and this is now. Instead of shooting for a reloadable
Etoys, what if the next Squeak release makes a clean break from Etoys?

I propose that we slim down Squeak by removing all Etoys-related code by
without trying to ensure that existing Etoys package successfully loads
back into the image. This will slim down Squeak significantly and ease
its maintenance.

The largest user base for Etoys was on XO laptop. Those users are
unlikely to upgrade to new Squeak. Also, porting Etoys package to load
into slimmer Squeak may be an easier and better way to continue research
than striving to maintain both in the released image.

Regards .. Subbu



Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

Eliot Miranda-2
In reply to this post by K K Subbu


On Fri, Jan 29, 2021 at 4:22 AM K K Subbu <[hidden email]> wrote:
On 29/01/21 2:54 pm, Marcel Taeumel wrote:
>
> Morph >> #player in "Morphic-Kernel" / "accessing"
> BookMorph >> #goto: in "MorphicExtras-Books" / "navigation"
> HandMorph >> #pasteMorph in "Morphic-Kernel" / "paste buffer"
> Morph >> #isTileMorph in "Morphic-Kernel" / "classification"
> HaloMorph >> #addTileHandle: in "Morphic-Widgets" / "handles"

IIRC, Etoys was an experiment in visual programming for children too
young to program via text but made fairly (hindsight!) intrusive changes
to Morphic. Etoys was organically bound into Squeak; like conjoint twins.

But that was then and this is now. Instead of shooting for a reloadable
Etoys, what if the next Squeak release makes a clean break from Etoys?

I propose that we slim down Squeak by removing all Etoys-related code by
without trying to ensure that existing Etoys package successfully loads
back into the image. This will slim down Squeak significantly and ease
its maintenance.

-1000!!!

The largest user base for Etoys was on XO laptop. Those users are
unlikely to upgrade to new Squeak. Also, porting Etoys package to load
into slimmer Squeak may be an easier and better way to continue research
than striving to maintain both in the released image.

Regards .. Subbu



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Unloading EToys from Squeak Image

K K Subbu
In reply to this post by marcel.taeumel
On 29/01/21 6:01 pm, Marcel Taeumel wrote:
>  > But that was then and this is now. Instead of shooting for a reloadable
>> Etoys, what if the next Squeak release makes a clean break from Etoys?
>
> That's not what I was going for. Etoys includes hints for userful
> extension points in the base system. Instead of just deleting code, one
> could take a look at it and rewrite it to present a less invasive
> extension. ;-) This takes some effort, of course.

I did mean to delete only Etoys-specific code like player, costumers,
tiles etc. My initial draft included these qualifications but got elided
while editing for brevity.

I am glad you pointed them out. Yes, Morphic extensions and enhancements
introduced by Etoys can be retained in Squeak image.

BTW, I do like Etoys and have helped school teachers and children use
it. It is important for Etoys to retain backward compatibility with all
its projects. I believe it will be better off as a separate loadable
package than organically conjoined to Squeak.

Regards .. Subbu