#unload, preambleOfRemoval and Monticello

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

#unload, preambleOfRemoval and Monticello

Levente Uzonyi-2
Hi,

I'm at the final phase of pushing out a version of RFB that works with
Squeak 4.3 and 4.4, but I'm having some trouble with unloading. The
package has two classes (RFBServer and RFBClient) which implement #unload.
This method is normally sent before the class is removed from the system,
but if I unload the package with MC, then it's never sent. I think MC
removes the method before actually calling it, but that's just a guess.

In order to work around this issue I thought that adding a
preambleOfRemoval script to the package will be okay. The script was:

RFBServer unload.
RFBClient unload

But during unloading I get a debugger, because RFBServer is not in the
system anymore. If it's really the preamble of removal, then shouldn't the
script be evaluated before removing the classes?


Cheers,
Levente

Reply | Threaded
Open this post in threaded view
|

Re: #unload, preambleOfRemoval and Monticello

Chris Muller-3
> But during unloading I get a debugger, because RFBServer is not in the
> system anymore. If it's really the preamble of removal, then shouldn't the
> script be evaluated before removing the classes?

Yes, it seems like the removal of the actual code should be a final
step AFTER the app has cleaned up its own objects.

Reply | Threaded
Open this post in threaded view
|

Re: #unload, preambleOfRemoval and Monticello

Bert Freudenberg
I'm pretty sure to have fixed MC's unload behavior at some point. I.e., sending #unload first before removing all the methods. Your workaround might be good enough for a single package but we should fix the general problem too.

As for RFB, Levente said he was going to publish his new version in Ian's repository. Is this related?

- Bert -

On 14.08.2012, at 06:25, Chris Muller <[hidden email]> wrote:

>> But during unloading I get a debugger, because RFBServer is not in the
>> system anymore. If it's really the preamble of removal, then shouldn't the
>> script be evaluated before removing the classes?
>
> Yes, it seems like the removal of the actual code should be a final
> step AFTER the app has cleaned up its own objects.
>

Reply | Threaded
Open this post in threaded view
|

Re: #unload, preambleOfRemoval and Monticello

Levente Uzonyi-2
On Tue, 14 Aug 2012, Bert Freudenberg wrote:

> I'm pretty sure to have fixed MC's unload behavior at some point. I.e., sending #unload first before removing all the methods. Your workaround might be good enough for a single package but we should fix the general problem too.

The workaround is mine and neither #unload nor the workaround
(preambleOfRemoval) works.

>
> As for RFB, Levente said he was going to publish his new version in Ian's repository. Is this related?

Yes, this is one of the reasons why it's not out yet. Unloading is (and
will be) broken for all pre 4.4 images, I hope someone with better
knowledge than me will fix #unload at least, so it will work in 4.4.


Levente

>
> - Bert -
>
> On 14.08.2012, at 06:25, Chris Muller <[hidden email]> wrote:
>
>>> But during unloading I get a debugger, because RFBServer is not in the
>>> system anymore. If it's really the preamble of removal, then shouldn't the
>>> script be evaluated before removing the classes?
>>
>> Yes, it seems like the removal of the actual code should be a final
>> step AFTER the app has cleaned up its own objects.
>>
>
>