[Glass] Unloading Monticello packages: what's the best practice?

[Richard Sargent]

It's not the answer to your question, but it might help going forward.

I install Seaside, GLASS, Metacello, etc. in their own symbol dictionary, so I can upgrade by dropping the old dictionary and loading fresh into a new one.

That makes it easier to find all methods referencing the old classes so they can be recompiled. Likewise for application subclasses of Seaside classes, and so on.
It also makes it easier to find old classes which remain in the system and track down what's keeping them from being GCed.


-----Original Message-----
From: Glass <glass-bounces at lists.gemtalksystems.com> On Behalf Of Johan Brichau via Glass
Sent: June 14, 2023 05:38
To: GLASS Mailing List <glass at lists.gemtalksystems.com>
Subject: [Glass] Unloading Monticello packages: what's the best practice?

Hi,

I am preparing an upgrade of the Seaside version in existing GemStone repositories where it is more practical to unload the current (old) Seaside version and load the current one afterwards rather than loading the new one over the old one.
However, the code snippet below I currently came up with is terribly slow and does not work because not everything got remove. Probably because the unload requires a certain order… 

So, has anyone done this in a GemStone Glass/GsDevKit setup? What is the best way to do this?

Johan

| packages gofer |
packages := (MetacelloProjectRegistration registrationForClassNamed: 'ConfigurationOfSeaside3' ifAbsent: [ nil ])  configurationProjectSpec loadPackageList.

packages do:[:p |
	Transcript show: 'Unload ', p; cr.
	gofer := Gofer new package: p; unload].


_______________________________________________
Glass mailing list
Glass at lists.gemtalksystems.com
https://lists.gemtalksystems.com/mailman/listinfo/glass