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 |
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 |
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 > > > |
Hi Hannes, Hi All, On Mon, Jan 25, 2021 at 2:36 AM H. Hirzel <[hidden email]> wrote: Hi Arjen 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?
_,,,^..^,,,_ best, Eliot |
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 |
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.
|
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 |
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
|
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: -1000!!!
_,,,^..^,,,_ best, Eliot |
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 |
Free forum by Nabble | Edit this page |