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

Frank Shearar frank.shearar at gmail.com
Sat Apr 13 18:46:00 UTC 2013


On 13 April 2013 19:27, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 13.04.2013, at 11:24, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> 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
>
>
> The regular Smalltalk cleanUp should be perfectly safe to call any time. So you would only need to implement the stuff specific to package unloading.

Oh, ok, so at the risk of being really slow, you're saying that this
would be sufficient to (a) cleanly remove all trace of a package and
(b) respect the rest of the image's current state:

unloadPackages: somePackageNames
    "Remove the given packages from the system, including any
registered applications, menu items, and the like."
    somePackageNames do: [:pkgName|
        (MCPackage named: pkgName) unload.
        MCMcmUpdater disableUpdatesOfPackage: pkgName].
    Smalltalk cleanUp

frank

> - Bert -
>
>
>


More information about the Squeak-dev mailing list