Marcus,

I apologize. You're doing a great job. It's just that I get a bit anxious to see the MorphicSplitters work in the standard image.

Cheers, Juan ----- Original Message ----- From: "Marcus Denker" denker@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, September 10, 2005 6:14 AM Subject: Re: [ANN] [RFC] MorphicSplitters phase 1 completed

Am 09.09.2005 um 15:07 schrieb Juan Vuletich:

...

Hi Folks,

I'm resending this in the hope that the lack of response was not because of lack of interest.

Definitely not. But even I somethimes have other things to do... there is a paper deadline on Sept 23, so I will not be able to work on 3.9 too much.

 Marcus

-- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 8/26/2005

Hi Stef,

Thanks for trying it. My script had a bug when preparing package prerequisites. You can download it again, from http://webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st it's fixed. But please load it in a fresh 3.9a-6690, and repeat the whole process. This is the corrected script. Alternatively you can just evaluate it and save the packages again.

| packageNames requiredPackages p | packageNames _ #('MorphicExtras' 'EToys' 'BalloonMMFlash' 'Nebraska' 'FlexibleVocabularies' 'StarSqueak' 'Movies' 'Speech'). requiredPackages _ #('Morphic' 'MorphicExtras' 'MorphicExtras' 'EToys' 'EToys' 'EToys' 'MorphicExtras' 'MorphicExtras'). packageNames with: requiredPackages do: [ :name :required | PackageInfo registerPackageName: name. p _ (MCPackage named: name) workingCopy. p requirePackage: (MCPackage named: required) ]

Now I see that the packages in the last published image should be the last ones published in source.squeakfoundation.org. I see two ways of keeping that consistency.

a) If someone publishes stuff in a .cs. Then you file that in in the master image, and then save new versions of the modified packages, and publish the new master image.

b) Someone publishes stuff in a MC package in source.squeakfoundation.org. Then you load the new packages in the master image and publish it.

For this first MorphicSplitters work, option a) is the only choice. If we try option b), well have a problem we had several months ago in the MorphicSplitters group, when using Cees' repository.

Let's suppose I (Juan) file in the MorphicSplitters cs, and publish the resulting packages. Basically what we did is to move stuff out of the Morphic package and in the MorphicExtras and EToys package.

When you (Stef) try to load those packages in the master image, because of the prerequisites, you will load Morphic first, then MorphicExtras and then EToys. When you load Morphic, MC removes all the classes that were in Morphic before and now will be loaded in MorphicExtras or EToys. But when they are loaded back in the new package, all live instances and class variables are lost.

This problem only occurs when moving stuff, modifying package boundaries, not when updating a package.

So, when setting package boundaries, it's better to do it via change sets.

Cheers, Juan ----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, September 10, 2005 10:09 AM Subject: Re: [ANN] [RFC] MorphicSplitters phase 1 completed

Juan what I did is that I cleared the dependencies and added it in the comments of the packages for now.

Stef

On 10 sept. 05, at 14:53, stéphane ducasse wrote:

Hi Juan

I loaded MorphicSplitters.1.st into the latest (non public) image of 39 and loading worked but when I wanted to publish BalloonMMFlash on source.squeakfoundation.org I got an error:

MCWorkingCopy>>needsSaving ^ self modified or: [self requiredPackages anySatisfy: [:ea | ea workingCopy needsSaving]]

ea = 'MorphicExtras'

I got the same problems with all the new packages you introduce. Can you have a look at that? I will publish the other ones.

Stef

On 9 sept. 05, at 15:07, Juan Vuletich wrote:

...

Hi Folks,

I'm resending this in the hope that the lack of response was not because of lack of interest.

This is the first MorphicSplitters change set. I prepared it for 3.9a-6690. It creates a few packages and does a massive categorization of classes and methods, to fill them. It does not modify any method or class definition. I believe this is a good moment to include it in the update stream.

It is at http://webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st (I didn't attach it to this message because there is a 100kb limit, and it is 200kb).

This work should be included in the update stream and the official 3.9a. Works on ToolBuilder get easier because there is less to look at in the Morphic package.

Next steps in the MorphicSplitters project will involve real refactoring, to allow unloading of the EToys and MorphicExtras packages. We're using MudPie and some removal scripts based on one by Dan for the analysis. I believe these will be useful for other refactoring efforts.

I'd like to thank to Cees, Edgar, Daniel, Dan and anyone else who helped in some way.

Comments welcome.

Cheers, Juan Vuletich

On 10 sept. 05, at 20:24, Juan Vuletich wrote:

Hi Stef,

I do believe we have a problem with packages and prerequisites when we are moving stuff from one package to another. Please read the message copied below.

I tried loading the EToys package and I had no problems because it doesn't have any prerequisites. This means that loading in a proper order is required. This order is the reverse of the order packages would load if prerequisites were set. For example. FlexibleVocabularies, StarSqueak, Movies, Speech, Nebraska, BalloonMMFlash, EToys, MorphicExtras, Morphic.

Exactly

But if you run the script below, to set the dependencies, then loading EToys would load Morphic first, starting the problems stated below.

But we'll need to be able to specify dependencies somehow.

I think that having configurations is the right way to go: a script that knows the order and the version

I'm waiting to see Kabungu running to see if this is ok. I think that hardcoding version in required package can be a big mess for maintainer (you want to load another version of package x but you cannot because you cannot unload version z of package x.....).

I suggest asking people to download a fresh image with the updated packages and prerequisites preloaded when this happens.

Cheers, Juan

----- Original Message ----- From: "Juan Vuletich" jmvsqueak@uolsinectis.com.ar To: "The general-purpose Squeak developers list" <squeak- dev@lists.squeakfoundation.org> Sent: Saturday, September 10, 2005 2:22 PM Subject: Re: [ANN] [RFC] MorphicSplitters phase 1 completed

...

Hi Stef,

Thanks for trying it. My script had a bug when preparing package prerequisites. You can download it again, from http:// webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st it's fixed. But please load it in a fresh 3.9a-6690, and repeat the whole process. This is the corrected script. Alternatively you can just evaluate it and save the packages again.

| packageNames requiredPackages p | packageNames _ #('MorphicExtras' 'EToys' 'BalloonMMFlash' 'Nebraska' 'FlexibleVocabularies' 'StarSqueak' 'Movies' 'Speech'). requiredPackages _ #('Morphic' 'MorphicExtras' 'MorphicExtras' 'EToys' 'EToys' 'EToys' 'MorphicExtras' 'MorphicExtras'). packageNames with: requiredPackages do: [ :name :required | PackageInfo registerPackageName: name. p _ (MCPackage named: name) workingCopy. p requirePackage: (MCPackage named: required) ]

Now I see that the packages in the last published image should be the last ones published in source.squeakfoundation.org. I see two ways of keeping that consistency.

a) If someone publishes stuff in a .cs. Then you file that in in the master image, and then save new versions of the modified packages, and publish the new master image.

b) Someone publishes stuff in a MC package in source.squeakfoundation.org. Then you load the new packages in the master image and publish it.

For this first MorphicSplitters work, option a) is the only choice. If we try option b), well have a problem we had several months ago in the MorphicSplitters group, when using Cees' repository.

Let's suppose I (Juan) file in the MorphicSplitters cs, and publish the resulting packages. Basically what we did is to move stuff out of the Morphic package and in the MorphicExtras and EToys package.

When you (Stef) try to load those packages in the master image, because of the prerequisites, you will load Morphic first, then MorphicExtras and then EToys. When you load Morphic, MC removes all the classes that were in Morphic before and now will be loaded in MorphicExtras or EToys. But when they are loaded back in the new package, all live instances and class variables are lost.

This problem only occurs when moving stuff, modifying package boundaries, not when updating a package.

So, when setting package boundaries, it's better to do it via change sets.

Cheers, Juan ----- Original Message ----- From: "stéphane ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" <squeak- dev@lists.squeakfoundation.org> Sent: Saturday, September 10, 2005 10:09 AM Subject: Re: [ANN] [RFC] MorphicSplitters phase 1 completed

Juan what I did is that I cleared the dependencies and added it in the comments of the packages for now.

Stef

On 10 sept. 05, at 14:53, stéphane ducasse wrote:

...

Hi Juan

I loaded MorphicSplitters.1.st into the latest (non public) image of 39 and loading worked but when I wanted to publish BalloonMMFlash on source.squeakfoundation.org I got an error:

MCWorkingCopy>>needsSaving ^ self modified or: [self requiredPackages anySatisfy: [:ea | ea workingCopy needsSaving]]

ea = 'MorphicExtras'

I got the same problems with all the new packages you introduce. Can you have a look at that? I will publish the other ones.

Stef

On 9 sept. 05, at 15:07, Juan Vuletich wrote:

...

Hi Folks,

I'm resending this in the hope that the lack of response was not because of lack of interest.

This is the first MorphicSplitters change set. I prepared it for 3.9a-6690. It creates a few packages and does a massive categorization of classes and methods, to fill them. It does not modify any method or class definition. I believe this is a good moment to include it in the update stream.

It is at http://webs.sinectis.com.ar/jmvuletich/ MorphicSplitters01.st (I didn't attach it to this message because there is a 100kb limit, and it is 200kb).

This work should be included in the update stream and the official 3.9a. Works on ToolBuilder get easier because there is less to look at in the Morphic package.

Next steps in the MorphicSplitters project will involve real refactoring, to allow unloading of the EToys and MorphicExtras packages. We're using MudPie and some removal scripts based on one by Dan for the analysis. I believe these will be useful for other refactoring efforts.

I'd like to thank to Cees, Edgar, Daniel, Dan and anyone else who helped in some way.

Comments welcome.

Cheers, Juan Vuletich

-- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 8/26/2005

-- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 8/26/2005