A good exercise (and very useful) would be just to build a new (and much 
better) Etoys in your new Morphic. There is nothing sacred in the current 
version of Etoys.

Cheers,

Alan

----------

At 04:36 AM 5/23/2006, Juan Vuletich wrote:
>Hi Daniel,
>
>I used MudPie for splitting Morphic. As I said in another message, I 
>failed at making Etoys and MorphicExtras easy to unload and load back. 
>This is because for fixing the bad dependencies without needing two 
>versions of many core methods (i.e. methods not in the package we are 
>removing). Doing this carefully is way too much for me (and for anybody, I 
>guess). Squeak is too big!
>
>My experience with MudPie was excellent. It is great for spotting those 
>dependencies. It works great, and when I needed some help, or new 
>features, Daniel helped me a lot, and implemented many of my suggestions. 
>Thanks, Daniel! And I can say: MudPie does work in 3.9.
>
>The problem was not lack of tools like MudPie. I could think of a tool 
>that could automate the generation of some of the code needed for removing 
>dependencies. But I don't think that would be a good solution. The only 
>way to clean code is by understanding it. So, to me the problem is: too 
>much work, too little time.
>
>Cheers,
>Juan Vuletich
>
>----- Original Message ----- From: "Daniel Vainsencher" 
><danielv at tx.technion.ac.il>
>To: "The general-purpose Squeak developers list" 
><squeak-dev at lists.squeakfoundation.org>
>Sent: Saturday, May 20, 2006 7:42 AM
>Subject: Re: Whither Squeak?
>
>
>>Hi Ralph
>>
>>Improving design:
>>------------------------------
>>One of the problems is that Squeak did much of its growth without any 
>>explicit package system. As a side effect, these systems usually enforce 
>>a-cyclic dependencies. Cyclic dependencies (considering just 
>>compilation-time-obvious dependencies, like a method in one class 
>>refering to a parent) are rampant in Squeak (see references to Morph), 
>>making it difficult to decompose.
>>
>>I wrote some code to aid finding, reducing and keeping down the incidence 
>>of such dependencies, called MudPie[1] (available from SqueakMap, I don't 
>>guarantee it works 3.9, but will if there's interest). DanI wrote some 
>>other modularization aid code. Some people have looked at these efforts, 
>>for example Juan, and tried to use them - I'll let them speak about their 
>>usefulness and/or problems. I would call neither tools, since they didn't 
>>include a real UI and such, which is sufficient cause for them to never 
>>have become widely used.
>>
>>Package system:
>>--------------------------
>>I believe that the management of the code of Squeak in tool supported 
>>packages is a critical component of any solution - this is the only way 
>>to keep the boundaries up to date. So the existance of MC exists makes 
>>this task somewhat feasible, but there have been various problems with 
>>its use to manage the whole image.
>>
>>- Performance (loading updates to the image using MC is much slower than 
>>loading changesets).
>>- System changes (like introducing Traits) require going through various 
>>intermediate stages, but MC itself only model merging the code in order 
>>to reach the final stage to be loaded.
>>- Workflow:
>>-- Support for cherry picking is very basic in current MC (which MC2 
>>should improve).
>>-- MC is quite workflow agnostic, but maintaining Squeak does require 
>>some workflow (people write fixes, other people merge them), and 
>>maintaining it as a set of packages requires even more of it 
>>(coordination of entry of package changes into the official release). 
>>Right now we use a combination of SqueakSource, Mantis, and email, glued 
>>together by (what seems to me like) lots of overhead.
>>
>>
>>Daniel Vainsencher
>>[1] listed in 
>>http://www.informatik.uni-trier.de/~ley/db/journals/cl/cl30.html
>>>On 5/19/06, Cees De Groot <cdegroot at gmail.com> wrote:
>>>>  the tools have
>>>>performance problems when trying to manage the whole image.
>>>
>>>Can you be specific?  What tools?  Can you give stories of how tools 
>>>failed you?
>>>
>>>>On a more philosophical stance, Squeak has grown organically. And
>>>>anything organic tends to get fuzzy, maybe even almost fractal,
>>>>borders between the various parts. Try separating a leaf from its
>>>>stem, on the cell level, for starters...
>>>
>>>Squeak is a bit more extreme than others, but not a lot.  As Fred
>>>Brooks said, all successful large systems started as successful small
>>>systems.  Organic growth is typical, not atypical.  Refactoring is a
>>>lot of hard work and Squeak doesn't have people being paid to do this
>>>kind of work.  But I find it hard to believe that Squeak is worse than
>>>Word, or Gnu EMACS, or any other large system that has been around for
>>>a long time.  The difference is that Microsoft pays people a lot of
>>>money to modularize Word.  It goes though periods of organic growth,
>>>and then periods of modularization as they try to reuse code across
>>>projects or within Word.  Most software does this.
>>>
>>>This is why I think modularizing Squeak is an interesting project,
>>>because we can learn lessons from it that will apply to all software.
>>>So, we need to write about what we are doing, the problems we
>>>discover, and the lessons we learn.
>>>
>>>Squeak hasn't needed to be modular enough for people to do the work to
>>>make it so.  Now it does.  (Well, it probably has for several years,
>>>so "now" means "the last few years".)
>>>
>>>-Ralph Johnson
>>
>>
>>
>>
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Free Edition.
>>Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date: 5/19/2006
>>
>