Hi,

Am 2010-08-23 um 11:06 schrieb Hannes Hirzel:

and tried SmalltalkImage unloadAllKnownPackages

Do Smalltalk unloadAllKnownPackages

instead, since Smalltalk is the sole instance of SmalltalkImage.

So Long, -Tobias

On 8/23/10, Tobias Pape Das.Linux@gmx.de wrote:

Am 2010-08-23 um 11:14 schrieb Tobias Pape:

...

Hi,

Am 2010-08-23 um 11:06 schrieb Hannes Hirzel:

...

and tried SmalltalkImage unloadAllKnownPackages

Do Smalltalk unloadAllKnownPackages

instead, since Smalltalk is the sole instance of SmalltalkImage.

Thank you for point this out.

In fact Smalltalk is the global variable which references SmalltalkImage current

So I can do as well

SmalltalkImage current unloadAllKnownPackages

Which I did

Squeak4.2-10382-alpha.image went from 16998KB

down to 10277kB (file sizes measured on Windows machine)

...

So Long, -Tobias

Addendum: It works. resulting file size: 10411140, about 10,4 MB. Nice.

Btw, this script probably needs updating, The Help browser, eg, does not get unloaded (same for TrueType)

Yes, I tried it for the HelpSystem

I added three more entries to the literal array in the method

"Go unloading" #( 'ReleaseBuilder' 'ScriptLoader' '311Deprecated' '39Deprecated' 'Universes' 'SMLoader' 'SMBase' 'Installer-Core' 'VersionNumberTests' 'VersionNumber' 'Services-Base' 'PreferenceBrowser' 'Nebraska' 'ToolBuilder-MVC' 'ST80' 'CollectionsTests' 'GraphicsTests' 'KernelTests' 'MorphicTests' 'MultilingualTests' 'NetworkTests' 'ToolsTests' 'TraitsTests' 'SystemChangeNotification-Tests' 'FlexibleVocabularies' 'EToys' 'Protocols' 'XML-Parser' 'Tests' 'SUnitGUI', 'HelpSystem-Core', 'HelpSystem-Tests', 'HelpSystem-Project' ) do:[:pkgName| (MCPackage named: pkgName) unload].

The image is now 10174kB (=100kB less10277kB).

Probably not worth the effort at this time.

Questions 1) Which are the packages which are big and easy to unload.....? 2) Who does an attempt to unload the TrueType?

--Hannes

Levente: totally. I mainly just wanted

a) image can start on Cog w/o segfaulting

b) doesn't need a long lengthy set of updates before being caught up with trunk

The cleanup methods will be run before we ship anyway:)

On Aug 23, 2010, at 4:29 AM, Levente Uzonyi leves@elte.hu wrote:

On Mon, 23 Aug 2010, Hannes Hirzel wrote:

...

On 8/23/10, Tobias Pape Das.Linux@gmx.de wrote:

...

Am 2010-08-23 um 11:14 schrieb Tobias Pape:

...

Hi,

Am 2010-08-23 um 11:06 schrieb Hannes Hirzel:

...

and tried SmalltalkImage unloadAllKnownPackages

Do Smalltalk unloadAllKnownPackages

instead, since Smalltalk is the sole instance of SmalltalkImage.

Thank you for point this out.

In fact Smalltalk is the global variable which references SmalltalkImage current

So I can do as well

SmalltalkImage current unloadAllKnownPackages

Which I did

Squeak4.2-10382-alpha.image went from 16998KB

Hm, I think Casey forgot to do [Smalltalk cleanUp: false] before saving the image. Doing that saves 2.8MB.

Levente

...

down to 10277kB (file sizes measured on Windows machine)

...

...

So Long, -Tobias

...

Addendum: It works. resulting file size: 10411140, about 10,4 MB. Nice.

Btw, this script probably needs updating, The Help browser, eg, does not get unloaded (same for TrueType)

Yes, I tried it for the HelpSystem

I added three more entries to the literal array in the method

"Go unloading" #( 'ReleaseBuilder' 'ScriptLoader' '311Deprecated' '39Deprecated' 'Universes' 'SMLoader' 'SMBase' 'Installer-Core' 'VersionNumberTests' 'VersionNumber' 'Services-Base' 'PreferenceBrowser' 'Nebraska' 'ToolBuilder-MVC' 'ST80' 'CollectionsTests' 'GraphicsTests' 'KernelTests' 'MorphicTests' 'MultilingualTests' 'NetworkTests' 'ToolsTests' 'TraitsTests' 'SystemChangeNotification-Tests' 'FlexibleVocabularies' 'EToys' 'Protocols' 'XML-Parser' 'Tests' 'SUnitGUI', 'HelpSystem-Core', 'HelpSystem-Tests', 'HelpSystem-Project' ) do:[:pkgName| (MCPackage named: pkgName) unload].

The image is now 10174kB (=100kB less10277kB).

Probably not worth the effort at this time.

Questions

1. Which are the packages which are big and easy to unload.....?
2. Who does an attempt to unload the TrueType?

--Hannes

On Mon, 23 Aug 2010, Tobias Pape wrote:

Hi, Am 2010-08-23 um 19:40 schrieb Casey Ransberger:

...

...

Hm, I think Casey forgot to do [Smalltalk cleanUp: false] before saving the image. Doing that saves 2.8MB.

makes no difference after unloading. wich is somewhat surprising to me.

But it's ok. [Smalltalk cleanUp: false] just releases cached objects. Some of these objects are released when the packages are unloaded, others are cleaned by SmalltalkImage >> #unloadAllKnownPackages, like: Undeclared removeUnreferencedKeys. StandardScriptingSystem initialize. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Behavior flushObsoleteSubclasses. ChangeSet current clear. etc.

Levente

so long, -Tobias

...

Smalltalk unloadAllKnownPackages

[…]

Addendum: It works. resulting file size: 10411140, about 10,4 MB. Nice.

Btw, this script probably needs updating, The Help browser, eg, does not get unloaded (same for TrueType)

So Long, -Tobias

Addendum 2:

After unload, updating Trunk no longer works, first error: trait no longer available.

just a note ;)

so long, -Tobias

On Mon, 23 Aug 2010, Edgar J. De Cleene wrote:

On 8/23/10 2:49 PM, "Tobias Pape" Das.Linux@gmx.de wrote:

...

Addendum 2:

After unload, updating Trunk no longer works, first error: trait no longer available.

just a note ;)

so long, -Tobias

It's why I modify the method. Give a try to http://ftp.squeak.org/Experiments/SqueakCore4.2-10382-alpha.zip

I did, but it's not better at all. You simply didn't unload Traits, so when the updater is trying to load 311-Deprecated it doesn't miss them.

The problem with updating after unloading is that the updater mechanism has no information of package dependencies, so it will try to load packages randomly which obviously won't work.

Levente

Edgar

On Tue, 24 Aug 2010, Bert Freudenberg wrote:

On 24.08.2010, at 00:03, Levente Uzonyi wrote:

...

The problem with updating after unloading is that the updater mechanism has no information of package dependencies, so it will try to load packages randomly which obviously won't work.

It does not load packages randomly, but in the order defined in the update config map.

That's right, but it's still random from the package dependency POV.

Since updating should not bring in the unloaded packages we would need to inform the updater to skip them.

Right.

Levente

• Bert -

On Tue, 24 Aug 2010, Bert Freudenberg wrote:

On 24.08.2010, at 00:34, Levente Uzonyi wrote:

...

On Tue, 24 Aug 2010, Bert Freudenberg wrote:

...

On 24.08.2010, at 00:03, Levente Uzonyi wrote:

...

The problem with updating after unloading is that the updater mechanism has no information of package dependencies, so it will try to load packages randomly which obviously won't work.

It does not load packages randomly, but in the order defined in the update config map.

That's right, but it's still random from the package dependency POV.

What makes you think so? The order is chosen (manually) so that dependent packages are loaded before depending packages.

If that would be the case, then updating an "unloaded" image would reload all unloaded packages. But that doesn't work. For example 311Deprecated depends on Traits, but Traits is at the end of the list while 311Deprecated is the first non-dummy package.

Levente

• Bert -

...

...

Since updating should not bring in the unloaded packages we would need to inform the updater to skip them.

Right.

Levente

...

• Bert -

On 8/23/2010 4:53 PM, Bert Freudenberg wrote:

On 24.08.2010, at 01:44, Levente Uzonyi wrote:

...

But that doesn't work. For example 311Deprecated depends on Traits, but Traits is at the end of the list while 311Deprecated is the first non-dummy package.

Then, obviously, the update map is wrong :)

No, it's not. The update map isn't ordered to allow reloading all the packages after they've been unloaded. The update is ordered to allow loading all the updates *after the previous update map*. In fact, it can and does happen that it switches the ordering of two packages between updates. For example, consider moving class Process from Kernel to System. To do this you would need the System package to be loaded before the Kernel. But if you would load these from first principles, almost certainly you would load Kernel before System.

So the order in the update map is fairly irrelevant for the order which you would use to load all these packages from first principles. The update map simply cannot be used for this purpose.

The real question here is if we should allow updating a subset of packages simply by skipping over the packages you haven't present in your image? This could be done but would come at the price that we could no longer add new "required" packages and let people fetch them automatically (because they wouldn't be present in the image they would not be loaded).

In addition, allowing to update subsets would require us to be *much* more careful with changing package dependencies - as you can see from the failing package dependency tests in the current trunk the dependencies *do* change but if we want to allow updating subsets then we have to be "dependency clean" in every single update.

The latter is really the reason why I'm not in favor of allowing this. Right now we have a solution that basically says when you update incrementally, you update an image with all the packages present which keeps it nice and simple. At the release points, we spend the additional time to make sure all the dependencies are in the right place and we can unload things but we don't have to worry about accidentally introducing a dependency in the middle and getting angry messages from people whose system we broke since they only update a subset of the packages.

Makes sense? If not, then let's discuss ways in which we can improve things.

Cheers, - Andreas

On 8/24/10, Bert Freudenberg bert@freudenbergs.de wrote:

What I'm saying is that unless one is trying to move things between the unloadable packages, I see no reason to not have them in loadable order.

You mean that you want to treat all the unloaded packages as one large image segment?

The attached drawing is intended to illustrate that we are talking about Trunk update (black arrow , the current package) and update of the image with packages unloaded (green arrow). And it seems that 'Reloading' has to be addresses as well (Red arrow).

The black and the green Trunk update could be combined in a single update which distinguishes what packages are there (that was one suggestion in this thread). The other idea is just to have two different trunk updates - one for the minimal image, one for the unloaded packages.

I read in the meeting notes that the infrastructure has to be set up for this and as the discussion in this thread has show so far

1) Unloading works actually fine 2) But there is the need for an infrastructure around it (this includes 'reloading')

--Hannes

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

On Mon, Aug 23, 2010 at 8:32 PM, Andreas Raab andreas.raab@gmx.de wrote:

On 8/23/2010 4:53 PM, Bert Freudenberg wrote:

...

On 24.08.2010, at 01:44, Levente Uzonyi wrote:

...

But that doesn't work. For example 311Deprecated depends on Traits, but Traits is at the end of the list while 311Deprecated is the first non-dummy package.

Then, obviously, the update map is wrong :)

No, it's not. The update map isn't ordered to allow reloading all the packages after they've been unloaded. The update is ordered to allow loading all the updates *after the previous update map*. In fact, it can and does happen that it switches the ordering of two packages between updates. For example, consider moving class Process from Kernel to System. To do this you would need the System package to be loaded before the Kernel. But if you would load these from first principles, almost certainly you would load Kernel before System.

So the order in the update map is fairly irrelevant for the order which you would use to load all these packages from first principles. The update map simply cannot be used for this purpose.

The real question here is if we should allow updating a subset of packages simply by skipping over the packages you haven't present in your image? This could be done but would come at the price that we could no longer add new "required" packages and let people fetch them automatically (because they wouldn't be present in the image they would not be loaded).

In addition, allowing to update subsets would require us to be *much* more careful with changing package dependencies - as you can see from the failing package dependency tests in the current trunk the dependencies *do* change but if we want to allow updating subsets then we have to be "dependency clean" in every single update.

The latter is really the reason why I'm not in favor of allowing this. Right now we have a solution that basically says when you update incrementally, you update an image with all the packages present which keeps it nice and simple. At the release points, we spend the additional time to make sure all the dependencies are in the right place and we can unload things but we don't have to worry about accidentally introducing a dependency in the middle and getting angry messages from people whose system we broke since they only update a subset of the packages.

Makes sense? If not, then let's discuss ways in which we can improve things.

I always appreciated the 95% rule, a.k.a. don't let the perfect be the enemy of the good. Right now if one removes all packages and updates one gets an ugly mess one can wade through with the debugger. If one were to simply skip the packages not in one's image one could certainly get to a point that might miss a required package, but one could also update without wading through the mess, without having to go through the remove unloadable packages step and without having to go through whatever other steps one had gone through to produce a finished image.

E.g. take my OS Cog VMMaker image which has been derived from an unload step to be nice to svn users; the image is half the size of the normal one. It's a mild pain to build, loading packages, adding workspaces and repositories etc. Yes I could automate all this but it would be much nicer to build it once and periodically update it. I don't care if it misses some required package; I can deal with that issue when I get to it. But not being able to update without wading through mud is, to put it mildly, a downer.

Cheers,

• Andreas

On Tue, Aug 24, 2010 at 3:04 PM, Andreas Raab andreas.raab@gmx.de wrote:

On 8/24/2010 2:12 PM, Eliot Miranda wrote:

...

I always appreciated the 95% rule, a.k.a. don't let the perfect be the enemy of the good. Right now if one removes all packages and updates one gets an ugly mess one can wade through with the debugger. If one were to simply skip the packages not in one's image one could certainly get to a point that might miss a required package, but one could also update without wading through the mess, without having to go through the remove unloadable packages step and without having to go through whatever other steps one had gone through to produce a finished image.

E.g. take my OS Cog VMMaker image which has been derived from an unload step to be nice to svn users; the image is half the size of the normal one. It's a mild pain to build, loading packages, adding workspaces and repositories etc. Yes I could automate all this but it would be much nicer to build it once and periodically update it. I don't care if it misses some required package; I can deal with that issue when I get to it. But not being able to update without wading through mud is, to put it mildly, a downer.

I don't think you understand what I mean by "required" package :-) Consider that we're splitting the Morphic package along the lines that Pavel proposed. We add a MorphicWidgets package that includes all the Pluggable*Morphs. The problem is that the next version of the Morphic package will show these as REMOVALS so if you update the Morphic package and leave out the MorphicWidgets your image is an instant goner. That's what I mean by "required"; not some random goodie that nobody cares if it's absent.

No, I get it, and it'll crash horribly. But it crashes horribly _now_. I don't mind rebuilding and unloading when I have to, e.g. because package structure changes force it. But I sure as sugar hate having to do it when it's not forced.

Worse, this wouldn't just happen to people who have deliberately chosen to update only a subset; it would happen to *everyone* updating their trunk images and make it pretty much impossible to perform such operations. Unless we can find a solution to this problem, I think Bert's alternative is the only reasonable one - add an explicit list of ignored packages for the updater and you can add to that list whatever you want and it won't get updated. You'll have to deal with the consequences if something goes wrong there but as you said, you can deal with that when you get to it.

Cheers,

• Andreas

On 8/24/2010 6:53 PM, Eliot Miranda wrote:

BTW, I'm not proposing relaxing this rule for trunk images, only for images in which packages have been unloaded, even packages in which all unloadable packages have been unloaded. I don't want to wreck updating, all I want is for updating to work to some acceptable degree in unload-all-unloadable-packages (UAUP) images.

I'm sorry, I thought I was being clear and wasn't. It is IMO preferrable to add a hack for UAUP images that allows them to update the packages they have available than the current situation where updating is possible only in a full trunk image.

Give it a shot; just load the latest version of MonticelloConfigurations into the image you want to update, disable the "Update missing packages" preference, press update, and let me know if it blows up or not :-)

(the change is minor and trivial to retract if it turns out to be more trouble than it's worth)

Cheers, - Andreas

On 8/24/2010 9:03 PM, Eliot Miranda wrote:

Excellent; works perfectly! The preference must be updated manually because there's no preferences browser (for others evaluate (MCMcmUpdater classPool at: #UpdateMissingPackages put: false)) but with that done update went without a hitch. Thank you!

No, no, no. This is why we have those tagged preferences. All you need to do is to evaluate:

MCMcmUpdater updateMissingPackages: false.

No need to poke in the classPool or anything :-)

Cheers, - Andreas

On Tue, Aug 24, 2010 at 10:03 PM, Hannes Hirzel hannes.hirzel@gmail.comwrote:

Eliot and Andreas,

Are you saying that the following works perfectly?

1. Take http://ftp.squeak.org/trunk/Squeak4.2-10382-alpha.zip
2. Evaluate SmalltalkImage unloadAllKnownPackages. MCMcmUpdater updateMissingPackages: false.
3. Choose 'mouse' menu, 'Update Squeak'

I haven't tried starting from Squeak 4.2-xxxxx. I started from a 4.1 image, changed the update URL to trunk, did SmalltalkImage unloadAllKnownPackages, loaded the various Cog VMMaker packages, loaded the latest MonticelloConfigurations, did the moral equivalent of MCMcmUpdater updateMissingPackages: false. and then step 3. But I would expect that the above would work provided that you insert the extra step:

1) Take http://ftp.squeak.org/trunk/Squeak4.2-10382-alpha.zip http://ftp.squeak.org/trunk/Squeak4.2-10382-alpha.zip1.5) Make sure the latest MonticelloConfigurations is loaded 2) Evaluate SmalltalkImage unloadAllKnownPackages. MCMcmUpdater updateMissingPackages: false. 3) Choose 'mouse' menu, 'Update Squeak'

--Hannes

On 8/25/10, Andreas Raab andreas.raab@gmx.de wrote:

...

On 8/24/2010 9:03 PM, Eliot Miranda wrote:

...

Excellent; works perfectly! The preference must be updated manually because there's no preferences browser (for others evaluate (MCMcmUpdater classPool at: #UpdateMissingPackages put: false)) but with that done update went without a hitch. Thank you!

No, no, no. This is why we have those tagged preferences. All you need to do is to evaluate:

  MCMcmUpdater updateMissingPackages: false.

No need to poke in the classPool or anything :-)

Cheers,

• Andreas

This has piqued my interest, so I've committed a couple packages to the inbox that should: * Automatically upon unloading a package, it will no longer try to reload this when updating from trunk * When manually reloading the package, updating from trunk will once again try to update the package

That seems to me a fuller answer to this thread.

-Chris

On Wed, Aug 25, 2010 at 3:56 AM, Hannes Hirzel hannes.hirzel@gmail.com wrote:

If I am not mistaken this has made it into the trunk by now. Is this correct? Retest needed then.

No, this isn't in trunk yet. Yes, it needs testing.

There is an issue about naming the global variable which keeps references to packages which are not supposed to be updated by the trunk update mechanism (Bert Freudenberg, I second it).

The Class Variable (not globlal) has been renamed to be, well, more obvious about what it's intent is.

-Chris

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?

2) Which object is meant here by 'configuration map'?

I'd like to add to the comment.

<proposalForAddition> MCMUpdater maintains in the variable 'SkipPackages' list of packages it no longer updates because they have been unloaded for example by Smalltalk unloadAllKnownPackages. </proposalForAddition>

And we need a description of the class variables

DefaultUpdateURL LastUpdateMap SkipPackages UpdateMissingPackages

And I'd like to have more.

Could somebody help please?

--Hannes

On 8/25/10, Chris Cunningham cunningham.cb@gmail.com wrote:

Oh, and for anyone trying this, you will need to load the MonticelloConfigurations before Monticello changes.

Bert, Somebody (you, Bert?) updated the class comment of MCMcmUpdater one or two day ago. 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 bert@freudenbergs.de 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) I assume it is a file in the repository? And loaded into the image is it an instance of MCConfiguration?

Is the Monticello Configuration browser used to create them? Why do I not see any of the configuration maps there?

================================== 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).

Thank you for your explanations, Bert. I now have a more complete view how the update process works. In particular noteworthy is the fact that we could have more than one in the future.

I was able to spot the configuration map in the trunk. The map is called 'update-...mcm" and contains the load order of the packages (see below).

I found a method #unloadablePackages in the ScriptLoader class.

^ #('OmniBrowser' 'PlusTools' 'Flash' 'FFI' 'StarSqueak' 'Speech' 'Movie' 'FlexibleVocabularies' '39Deprecated' '39Deprecated' 'PreferenceBrowser' 'ReleaseBuilder' 'SUnitUI' 'Protocols' 'Sounds')

Within the code of #unloadAllKnownPackages (class SmalltalkImage) we have #( 'ReleaseBuilder' 'ScriptLoader' '311Deprecated' '39Deprecated' 'Universes' 'SMLoader' 'SMBase' 'Installer-Core' 'VersionNumberTests' 'VersionNumber' 'Services-Base' 'PreferenceBrowser' 'Nebraska' 'ToolBuilder-MVC' 'ST80' 'CollectionsTests' 'GraphicsTests' 'KernelTests' 'MorphicTests' 'MultilingualTests' 'NetworkTests' 'ToolsTests' 'TraitsTests' 'SystemChangeNotification-Tests' 'FlexibleVocabularies' 'EToys' 'Protocols' 'XML-Parser' 'Tests' 'SUnitGUI'

There is some overlap here. Is the class ScriptLoader still used? Otherwise I would say it should be deleted to avoid confusion. It is just one class in a package of it's own and the comment says that ScriptLoader is a dummy class.

--Hannes

--------------------------------------------------------------------------------------------------------------------------------

update-nice.150.mcm (the current version of the configuration map)

Squeak-Version-ar.4662 311Deprecated-nice.2 39Deprecated-ar.19 Balloon-ar.16 Collections-nice.370 CollectionsTests-nice.170 Compression-ar.20 Monticello-ar.397 Kernel-nice.482 Compiler-nice.170 EToys-nice.73 Exceptions-sn.29 Files-ar.83 FlexibleVocabularies-ar.12 Graphics-nice.147 GraphicsTests-nice.26 Installer-Core-nice.339 KernelTests-nice.157 MonticelloConfigurations-dtl.77 System-nice.359 Morphic-eem.460 Multilingual-nice.125 MorphicExtras-nice.91 MorphicTests-ar.17 MultilingualTests-HenrikSperreJohansen.10 Nebraska-nice.31 Network-ar.78 NetworkTests-ar.17 PackageInfo-Base-ar.43 PreferenceBrowser-ar.46 Protocols-nice.31 SMBase-nice.112 SMLoader-ar.59 ST80-eem.117 SUnit-ar.80 SUnitGUI-ar.49 ScriptLoader-nice.332 Services-Base-ar.45 Sound-nice.21 SystemChangeNotification-Tests-bp.11 Tests-eem.90 ToolBuilder-Kernel-eem.36 ToolBuilder-MVC-dtl.20 ToolBuilder-Morphic-ar.66 ToolBuilder-SUnit-nice.14 Tools-nice.261 ToolsTests-tbn.5 Traits-nice.285 TraitsTests-ar.9 TrueType-nice.15 Universes-nice.45 VersionNumber-ar.2 XML-Parser-ar.32 ReleaseBuilder-nice.50 ShoutCore-laza.19 VersionNumberTests-nice.3 HelpSystem-Core-tbn.49 HelpSystem-Tests-tbn.12 Help-Squeak-Project-it.5

The Utilities class does the actual update

Utilities updateFromServer.

This is called by the menu entry.

On 8/27/10, Bert Freudenberg bert@freudenbergs.de wrote:

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 bert@freudenbergs.de 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 -

I did another test

I took an image with 10490 and the packages unloaded and upgraded it to 10502. The same result as with the last test. The version number is not correct anymore and Morphic is actually broken. If I create a Morphic project and then want to delete it it gives a walkback.

I am looking forward to a fixed MVC to continue with unloading. A candiate would then be to unload Morphic and start trying to load Juan's version of Morphic or Tweak or something else.

Thread starts with http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153360...

currently at http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153489... where David T. Lewis managed to get the debugger window in MVC as well (like Andreas and Florin)

--Hannes

On 9/6/10, Hannes Hirzel hannes.hirzel@gmail.com wrote:

On 8/31/10, Bert Freudenberg bert@freudenbergs.de 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

Yeah, which is why we currently have to work in the monolithic image. Once we've agreed on how we're going to load "community supported packages," we'll be able to move them out of the core image and out of the main trunk repository, which should solve this problem (I think, but I may not understand the issue: if I do, the problem is that we're trying to update things that aren't in the image after the unload.)

On Aug 23, 2010, at 10:49 AM, Tobias Pape Das.Linux@gmx.de wrote:

After unload, updating Trunk no longer works, first error: trait no longer available.

just a note ;)

so long, -Tobias