Monticello Bug? Preamble of removal is executed too late

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Monticello Bug? Preamble of removal is executed too late

Christoph Thiede

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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Monticello Bug? Preamble of removal is executed too late

Chris Muller-3
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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Monticello Bug? Preamble of removal is executed too late

Christoph Thiede

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 <[hidden email]> im Auftrag von Chris Muller <[hidden email]>
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 <[hidden email]> 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




Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Monticello Bug? Preamble of removal is executed too late

Jakob Reschke
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 <[hidden email]>:

To me, the name "preamble of removal" indicates clearly that the script should be executed before removal.

Agreed.


Reply | Threaded
Open this post in threaded view
|

Re: Monticello Bug? Preamble of removal is executed too late

Christoph Thiede
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

Carpe Squeak!