About unloading of packages in the most recent Squeak 4.1 trunk

> The comment of class MCMUpdater is currently
>
> <citation>
> MCMcmUpdater provides utility methods for updating Monticello packages
> from Monticello configurations.
>
> When Monticello configurations are stored in a repository,
> MCMcmUpdater acts as an update stream. It first ensures that each
> configuration map has been loaded in sequence, then updates the last
> configuration map to the most recent version for each specified
> package, and finally loads these versions to produce a fully updated
> configuration.
> </citation>
>
>
> This class went through a small though important change (see
> discussion in this thread). It  should inform people who have not
> followed it.
>
> In addition I'd like to have the class comment to give more details so
> that a non-specialist in version control / update mechanism issues can
> understand it.
>
> My two questions:
>
> 1) Is it correct to say that MCMUpdater  handles each Monticello
> package so-to-say as having its own update stream? I mean the
> succession of Monticello mcz files?

> On 8/24/2010 1:16 AM, Bert Freudenberg wrote:
>> Manually re-ordering the update map is just a work-around for not being able to update multiple packages together. If we could, the order would not matter for moving classes/methods around.
>
> You know there's a funny thing there: I actually think it may be possible to load multiple packages together these days as long as we're incrementally updating. We've fixed so many things in MC loading that I believe it *may* just be safe to do that.
>
> Except that ... if you would then use that to load all the unloaded packages back in you'd may try to load the traits package together with a package using traits or the FFI package together with a package using the FFI etc. and that can't possibly work because in order to load the second package the first must be *installed*. Which requires loading them sequentially :-)
>
> So there you have it. It's kind of a tricky situation.
>
> Cheers,
>  - Andreas

> It is now more comprehensive and answers many of the
> question. However some new come up. See below.
>
> --Hannes
>
> On 8/26/10, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 26.08.2010, at 08:13, Hannes Hirzel wrote:
>>
> .....
>>> 2) Which object is meant here by 'configuration map'?
>>
>> The update configuration loaded from the repository (e.g.
>> "update-xy.42.mcm")
>
> Could you give an actual example of a configuration map with packages
> in the unloaded packages list? (I.e name config map xy uses packages
> p1, p2, p3)

> ==================================
> The current class comment of MCMcmUpdater
> ==================================
>
>
> MCMcmUpdater provides utility methods for updating Monticello packages
> from Monticello configurations.
>
> When Monticello configurations are stored in a repository (or
> repositories), MCMcmUpdater acts as an update stream. It first ensures
> that each configuration map has been loaded in sequence, then updates
> the last configuration map to the most recent version for each
> specified package, and finally loads these versions to produce a fully
> updated configuration.
>
> Currently if a set of packages are unloaded from the image, using this
> class to reload them may cause problems, depending on what
> dependencies those classes have.  Success is not assured.  Removing
> packages via SmalltalkImage>>unloadAllKnownPackages will be
> successful, it flags the packages removed so that they are not loaded
> by this utility.
>
> If you wish to not have MCMcmUpdater update packages, there are two
> ways to handle this:
>
> 1) To have MCMcmUpdater not update any packages not currently in the
> image set the UpdateMissingPackages preference to false:
> MCMcmUpdater updateMissingPackages: false
> Note that any new packages added to the repositories will not be
> picked up when this is turned off.
> 2) To have MCMcmUpdater not update a specific package, evaluate
> MCMcmUpdater disableUpdatesOfPackage: <packageName>
>
> Class Variables definitions:
>
> DefaultUpdateURL - String: the URL that will be checked by default for
> updates.  This would be set for a common standard location to check.
>
> LastUpdateMap - Dictionary of Integer: version number of the last
> loaded update map per repository.  Keeps track of the last
> configuration map, so that the utility will not have to run through
> the full history in the repositories each time you ask to update.
>
> SkipPackages - Set of Strings: names of packages to not update in
> MCMcmUpdater (empty by default).
>
> UpdateMissingPackages - Boolean: if true (default), new packages in
> the update config map will be loaded unless they are in SkipPackages.
> If false, packages not currently loaded in the image will not be
> loaded by MCMcmUpdater.  (This can be dangerous if packages are split
> - use at your own risk).
>

>
> On 27.08.2010, at 19:26, Hannes Hirzel wrote:
>
>> Bert,
>> Somebody (you, Bert?) updated the class comment of MCMcmUpdater  one
>> or two day ago.
>
> It was Chris, I just committed his package to Trunk.
>
>> It is now more comprehensive and answers many of the
>> question. However some new come up. See below.
>>
>> --Hannes
>>
>> On 8/26/10, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 26.08.2010, at 08:13, Hannes Hirzel wrote:
>>>
>> .....
>>>> 2) Which object is meant here by 'configuration map'?
>>>
>>> The update configuration loaded from the repository (e.g.
>>> "update-xy.42.mcm")
>>
>> Could you give an actual example of a configuration map with packages
>> in the unloaded packages list? (I.e name config map xy uses packages
>> p1, p2, p3)
>
> Just open the trunk repo, scroll to the bottom in the left list, and click
> the "update" entry. There you see all the configs. Click "Browse" top open
> an mcconfig browser on any of them.
>
>> I assume  it is a file in the repository?
>
> Yes.
>
>> And loaded into the image is it an instance of MCConfiguration?
>
> Yes.
>
>> Is the Monticello Configuration browser used to create them?
>
> Yes.
>
>> Why do I not see any of the configuration maps there?
>
> Because they are in the repository. There is no config map in the image. It
> is only loaded from the repository when updating.
>
> - Bert -
>
>> ==================================
>> The current class comment of MCMcmUpdater
>> ==================================
>>
>>
>> MCMcmUpdater provides utility methods for updating Monticello packages
>> from Monticello configurations.
>>
>> When Monticello configurations are stored in a repository (or
>> repositories), MCMcmUpdater acts as an update stream. It first ensures
>> that each configuration map has been loaded in sequence, then updates
>> the last configuration map to the most recent version for each
>> specified package, and finally loads these versions to produce a fully
>> updated configuration.
>>
>> Currently if a set of packages are unloaded from the image, using this
>> class to reload them may cause problems, depending on what
>> dependencies those classes have.  Success is not assured.  Removing
>> packages via SmalltalkImage>>unloadAllKnownPackages will be
>> successful, it flags the packages removed so that they are not loaded
>> by this utility.
>>
>> If you wish to not have MCMcmUpdater update packages, there are two
>> ways to handle this:
>>
>> 1) To have MCMcmUpdater not update any packages not currently in the
>> image set the UpdateMissingPackages preference to false:
>> MCMcmUpdater updateMissingPackages: false
>> Note that any new packages added to the repositories will not be
>> picked up when this is turned off.
>> 2) To have MCMcmUpdater not update a specific package, evaluate
>> MCMcmUpdater disableUpdatesOfPackage: <packageName>
>>
>> Class Variables definitions:
>>
>> DefaultUpdateURL - String: the URL that will be checked by default for
>> updates.  This would be set for a common standard location to check.
>>
>> LastUpdateMap - Dictionary of Integer: version number of the last
>> loaded update map per repository.  Keeps track of the last
>> configuration map, so that the utility will not have to run through
>> the full history in the repositories each time you ask to update.
>>
>> SkipPackages - Set of Strings: names of packages to not update in
>> MCMcmUpdater (empty by default).
>>
>> UpdateMissingPackages - Boolean: if true (default), new packages in
>> the update config map will be loaded unless they are in SkipPackages.
>> If false, packages not currently loaded in the image will not be
>> loaded by MCMcmUpdater.  (This can be dangerous if packages are split
>> - use at your own risk).
>>
>
>
>

> On 31.08.2010, at 14:19, Hannes Hirzel wrote:
>
>> SmalltalkImage current unloadAllKnownPackages
>>
>> a reduced image like the one I got with this process should take trunk
>> updates properly in most cases?
>
> Well, hopefully. Try and let us know ;)
>
> - Bert -
>

> On 8/31/10, Bert Freudenberg <[hidden email]> wrote:
>> On 31.08.2010, at 14:19, Hannes Hirzel wrote:
>>
>>> SmalltalkImage current unloadAllKnownPackages
>>>
>>> a reduced image like the one I got with this process should take trunk
>>> updates properly in most cases?
>>
>> Well, hopefully. Try and let us know ;)
>>
>> - Bert -
>>
>
> I updated image which had been through
>    SmalltalkImage current unloadAllKnownPackages
> and was in the version 10437.
>
> The update process went through. No walkbacks.
>
> Problems:
>
> 1) The feedback given is
>         Update completed. Current update number: 8546.
>      This number appears now in the 'About Squeak' menu.
>
>
> 2) If I right-click on the background I get
>     PasteUpMorph doesNotunderstand:  #isStackBackgroundMorph
>
>
> Conclusion: It does not work proplery yet. However as Andreas, Eliot
> and Nicolas currently are doing a lot of refactoring I do not mind. I
> will conduct this test later taking an updated regular trunk image, do
> the unloading, wait two weeks and then the update.
>
> --Hannes
>