Smalltalk › Squeak › Squeak - Dev

Monticello Bug? Preamble of removal is executed too late

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Christoph Thiede

Monticello Bug? Preamble of removal is executed too late

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
On its class side, add a method named #bar - just declare it.
In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to:
FooClass bar
Save a version of our #Foo package
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!

Chris Muller-3

Re: 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

In Monticello Browser, create a new package named #Foo
In the System Browser, create a new class named #FooClass in the system category #Foo
On its class side, add a method named #bar - just declare it.
In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to:
FooClass bar
Save a version of our #Foo package
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

Christoph Thiede

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

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..?

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

In Monticello Browser, create a new package named #Foo
In the System Browser, create a new class named #FooClass in the system category #Foo
On its class side, add a method named #bar - just declare it.
In Monticello Browser, edit the preambleOfRemoval for our #Foo Package and set it to:
FooClass bar
Save a version of our #Foo package
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!

Jakob Reschke

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

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.

Christoph Thiede

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

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!