[squeak-dev] The Inbox: System-fbs.523.mcz

Frank Shearar frank.shearar at gmail.com
Sat Apr 13 18:24:17 UTC 2013


On 13 April 2013 19:19, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 13 April 2013 18:25, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On 13.04.2013, at 08:05, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>>> On 12 April 2013 19:00, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>
>>>> On 12.04.2013, at 11:32, commits at source.squeak.org wrote:
>>>>
>>>>> Frank Shearar uploaded a new version of System to project The Inbox:
>>>>> http://source.squeak.org/inbox/System-fbs.523.mcz
>>> <snip>
>>>
>>>> I'd rather use "Smalltalk cleanUp" which does almost all of what you listed. This is more future-proof. If something is missing, add it to the cleanUp mechanism (that is, implement a class-side cleanUp or cleanUp: method).
>>>
>>> So just to be clear you mean unloading packages should be:
>>>
>>> unloadPackages: somePackageNames
>>>    "Go unloading"
>>>    somePackageNames do: [:pkgName|
>>>                    (MCPackage named: pkgName) unload.
>>>                    MCMcmUpdater disableUpdatesOfPackage: pkgName.
>>>                    ].
>>>    Smalltalk cleanUp: true. "Needed to trigger the MCWorkingCopy's
>>> #cleanUp: of obsolete PackageInfos; could of course change that method
>>> to always do this."
>>
>> It should *not* flush all PackageInfos, but only the ones that were actually unloaded. And possibly that should happen in #unload itself.
>>
>>> where we have another commit implementing Preferences >> #cleanUp ?
>>>
>>> frank
>>
>>
>> No, "cleanUp: true" should only be done in the release process, or manually, because it will actually modify the image beyond emptying caches. E.g., I might like keeping package infos around even if there is no associated MC package. The system should not simply discard them. Same for empty system categories: If I create a category manually, the system should not simply trash it. Etc.
>
> That sounds like exactly the _right_ thing to do, but perhaps I should
> indicate that by putting this method with the ReleaseBuilder. Because
> this _is_ about a release-making like process, in that I'm wanting to
> cut things out of the image... but at the moment the 4.5 image I use
> had things ripped out in an untidy manner.

Actually, no. I don't want to clean the world. I want to remove every
trace of a particular package, and this unloadPackages: should
aggressively clean up only that state associated with the package:
strip menu items, registered apps, and so on. So it shouldn't call
Smalltalk cleanUp at all, aggressive or otherwise, I would think.

frank

> frank
>
>> - Bert -
>>
>>
>>


More information about the Squeak-dev mailing list