Smalltalk › Pharo › Pharo Smalltalk Developers

Epicea: Revert the removal of a class

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

CyrilFerlicot

Epicea: Revert the removal of a class

Hi,

Today I tried to remove a class, go in Epicea and revert the removal of
the class.

At the end the class was here but with no methods. Is that the normal
behaviour? I think it is a bug but since I don't really use Epicea a lot
for know I am not sure.

Have a nice day.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (836 bytes) Download Attachment

tinchodias

Re: Epicea: Revert the removal of a class

Hi Cyril,

This behavior comes from a lack of information in the system announcement. When Epicea recieves a ClassRemoved announcement, it comes with an "obsolete class" (whose method dictionary has been emptied before).

I agree with you. So, the first step to announce a class removal with the required information.

Solution 1: Announce ClassRemoved before converting the class in obsolete. One objection: then, the announcement's classname will be wrong because, when announced, the class wasn't removed yet. Another objection but less important is that it my be inconsistent with other related system announcements (e.g. ClassModifiedClassDefinition) because they are announced after the action was performed. Other objection also not very important is that is can have impact with current users of ClassRemoved, which already expect the class converted in obsolete.

Solution 2: do not change anything in ClassRemoved but add a new announcement like ClassWillBeRemoved (or RemovingClass).

Solution 3: add to ClassRemoved something like "nonMetaClassMethods" and "metaClassMethods" instance variables. This is kind of workaround but has no impact in users of ClassRemoved.

Solution 4: before making the class obsolete, do self methodsDo: [:each | each removeFromSystem ]. Then a MethodRemoved will be announced for each method. I think this will have performance impact since Nautilus and other subscriptors to MethodRemoved will refresh their UI many times (for each method). But subscriptors can be adapted... or should... a similar scenario with many changes announced in a small time window occurs when Monticello loads a version (and I guess Iceberg too): each method loaded triggers UI refresh in tools. However, I can say the Epicea changes browser is prepared to this scenario because it delays its UI refresh some milliseconds after a change announcement happened.

Sorry if too long. Cheers.

Martin

On Fri, Jul 28, 2017 at 1:14 PM, Cyril Ferlicot D. <[hidden email]> wrote:

Hi,

Today I tried to remove a class, go in Epicea and revert the removal of
the class.

At the end the class was here but with no methods. Is that the normal
behaviour? I think it is a bug but since I don't really use Epicea a lot
for know I am not sure.

Have a nice day.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Henrik Sperre Johansen

Re: Epicea: Revert the removal of a class

tinchodias wrote

However, I can say the Epicea changes browser is prepared
to this scenario because it delays its UI refresh some milliseconds after a
change announcement happened.

Can verify this really helps, having loaded large batches in a 6.1 image (with no other browsers open, for obvious reasons...)
Though, it would be nice if the UI/change flushing updates were sent by signals to corresponding threads, instead of being forked off each time.
That way, they doesn't clutter up a "start profiling all processes" with 5 - 20 ms entries for 999 different processes, so finding other slowdowns is less of a hassle...

I assume its done the current way to avoid requiring explicit closing in order to not leak memory (running deferrer process referencing receiver, etc), but that can be avoided using a WeakMessageSend, see attached for example changes:
OmDeferrerThreaded.cs

Cheers,
Henry