Hi all, I found a possible bug in Monticello scripts. Let me try to describe the issue:
Steps to reproduce
1. In Monticello Browser, create a new package named #Foo 2. In the System Browser, create a new class named #FooClass in the system category #Foo 3. On its class side, add a method named #bar - just declare it. 4. In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to: FooClass bar 5. Save a version of our #Foo package 6. Still in Monticello Browser, unload the foo package via context menu.
Expected behavior The package is unloaded without any errors. If Foo class >> bar has a real implementation, it will have run when the package is removed.
Actual behavior In MCRemovalPreambleDefinition >> #evaluate: UndefinedObject does not understand #bar.
Reason In MCPackageLoader >> #analyze, the MCDependencySorter for removals does not return the removal preamble definition as the last item, but the class definition of FooClass. This happens somewhere in #addExternalProvisions:, because FooClass depends on Object and thus is moved to the end (?).
Questions Am I right that this is a bug? I think we really want to execute the removal preamble *before* unloading any code definitions? How could one solve this issue? Is it necessary to treat preambles/postambles separated so that they can't be messed up by dependencies? Or would know an easier way? I'm not familiar at all with this domain, so if we want a fast solution, maybe someone others could have a look at it. Otherwise, I'd be happy to hear your opinions.
Best, Christoph
Hi Christoph,
#unload is the method responsible for handling domain-specific unload actions.
I'm not sure what #preambleOfRemoval is for, unless it's for MC-specific cleanups related to a package..?
More generally, focusing effort on automated building, configuration and deployment, up from base images, is going to pay a lot more future dividends than worrying about removing previously-installed stuff.... Uninstall + Install will never be better than only Install.
Best, Chris
On Wed, Dec 18, 2019 at 4:00 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi all, I found a possible bug in Monticello scripts. Let me try to describe the issue:
*Steps to reproduce*
- In Monticello Browser, create a new package named #Foo
- In the System Browser, create a new class named #FooClass in the
system category #Foo 3. On its class side, add a method named #bar - just declare it. 4. In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to: FooClass bar 5. Save a version of our #Foo package 6. Still in Monticello Browser, unload the foo package via context menu.
*Expected behavior* The package is unloaded without any errors. If Foo class >> bar has a real implementation, it will have run when the package is removed.
*Actual behavior* In MCRemovalPreambleDefinition >> #evaluate: UndefinedObject does not understand #bar.
*Reason* In MCPackageLoader >> #analyze, the MCDependencySorter for removals does not return the removal preamble definition as the last item, but the class definition of FooClass. This happens somewhere in #addExternalProvisions:, because FooClass depends on Object and thus is moved to the end (?).
*Questions* Am I right that this is a bug? I think we really want to execute the removal preamble *before* unloading any code definitions? How could one solve this issue? Is it necessary to treat preambles/postambles separated so that they can't be messed up by dependencies? Or would know an easier way? I'm not familiar at all with this domain, so if we want a fast solution, maybe someone others could have a look at it. Otherwise, I'd be happy to hear your opinions.
Best, Christoph
Hi Chris,
(I could swear that I already replied your message, but I cannot find my answer.)
I was indeed talking about domain-specific unload actions. For example, delete a file cache or something similar ...
To me, the name "preamble of removal" indicates clearly that the script should be executed before removal. Does anyone see this differently?
And what do you mean with "removing previously-installed stuff"? I cannot see how this matches the current bug :)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com Gesendet: Donnerstag, 19. Dezember 2019 00:10 Uhr An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Monticello Bug? Preamble of removal is executed too late
Hi Christoph,
#unload is the method responsible for handling domain-specific unload actions.
I'm not sure what #preambleOfRemoval is for, unless it's for MC-specific cleanups related to a package..?
More generally, focusing effort on automated building, configuration and deployment, up from base images, is going to pay a lot more future dividends than worrying about removing previously-installed stuff.... Uninstall + Install will never be better than only Install.
Best, Chris
On Wed, Dec 18, 2019 at 4:00 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi all, I found a possible bug in Monticello scripts. Let me try to describe the issue:
Steps to reproduce
1. In Monticello Browser, create a new package named #Foo 2. In the System Browser, create a new class named #FooClass in the system category #Foo 3. On its class side, add a method named #bar - just declare it. 4. In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to: FooClass bar 5. Save a version of our #Foo package 6. Still in Monticello Browser, unload the foo package via context menu.
Expected behavior The package is unloaded without any errors. If Foo class >> bar has a real implementation, it will have run when the package is removed.
Actual behavior In MCRemovalPreambleDefinition >> #evaluate: UndefinedObject does not understand #bar.
Reason In MCPackageLoader >> #analyze, the MCDependencySorter for removals does not return the removal preamble definition as the last item, but the class definition of FooClass. This happens somewhere in #addExternalProvisions:, because FooClass depends on Object and thus is moved to the end (?).
Questions Am I right that this is a bug? I think we really want to execute the removal preamble *before* unloading any code definitions? How could one solve this issue? Is it necessary to treat preambles/postambles separated so that they can't be messed up by dependencies? Or would know an easier way? I'm not familiar at all with this domain, so if we want a fast solution, maybe someone others could have a look at it. Otherwise, I'd be happy to hear your opinions.
Best, Christoph
While Chris is right that there is also #unload for this purpose, nevertheless "Preamble of removal" should work as expected as long as it exists.
Am Do., 19. Dez. 2019 um 15:33 Uhr schrieb Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de>:
To me, the name "preamble of removal" indicates clearly that the script should be executed before removal.
Agreed.
I just uploaded a proposal to fix this bug in Monticello-ct.715. Tests are in Tests-ct.426. Please review both! :-)
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Christoph Thiede -
Jakob Reschke -
Thiede, Christoph