Hi Bernat, Until Pharo sorts our how they are going to fix it, we fixed it by overriding two methods. Also see this emial to the Pharo mailing list (that went nowhere): http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051094.html AnnouncementSubscription>>deliver: anAnnouncement " Overridden code has a fork in here. Not good." ^ (self handles: anAnnouncement class) ifTrue: [ action cull: anAnnouncement cull: announcer ] SubscriptionRegistry>>deliver: anAnnouncement to: subs subs do: [ :each | each deliver: anAnnouncement ] On Mon, Jul 18, 2011 at 11:13 AM, Bernat Romagosa < tibabenfortlapalanca@gmail.com> wrote:
Hi,
I am having the exact same problem with an Iliad app, which stopped working in 1.3 because it loses the context when catching an announcement. I'd really love to know the solution to this, in the Iliad list we didn't manage to fix it.
Cheers,
2011/7/18 Norbert Hartl <norbert@hartl.name>
Am 17.07.2011 um 22:06 schrieb Stéphane Ducasse:
It is just that everybody should be aware of the problem and have its own "simple" announcements when using any of the frameworks above.
you know that this is not the good solution. So probably it was a bad idea to catch everything and probably UnhandledError is a better choice. Now again without feedback we will just progress but much slower.
Why is the usage of on:fork: not an option of the Announcer? We don't have one single Announcer in the system so I don't see the need why they should behave all the same. Over time I think there will be multiple announcers in the system that have different impact in case something goes wrong. For the core announcers on:fork: is probably a good idea to preserve consistency in the system. For the rest it may be better to preserve stack to be able to debug and to reduce side effects. I think on:fork is targetted to an edge case so it should not be the default.
my 2 cents,
Norbert
-- Bernat Romagosa.
-- Danie Roux *shuffle* Adore Unix - http://danieroux.com Email / Google Talk / Jabber - danie@danieroux.com