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