[Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :) I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe). I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete. SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete. But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted? Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Two comments: (1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional. If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements I really like Announcements! It's so much easier to update complex GUIs when you can pass state :) I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe). I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete. SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete. But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted? Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Two comments: (1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional. If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements I really like Announcements! It's so much easier to update complex GUIs when you can pass state :) I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe). I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete. SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete. But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted? Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Yes but having good weakstructure will not arrive by accident. On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements Yes but having good weakstructure will not arrive by accident. On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote:
Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements
Yes but having good weakstructure will not arrive by accident.
On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow."
Tudor Girba wrote:
The WeakAnnouncement are already on the agenda for 1.3.
Ah, very good! Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3223939.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Tudor Girba wrote:
The WeakAnnouncement are already on the agenda for 1.3.
Bump... What is the status of this? Also, what are people doing in the mean time? I don't see a way to safely use Announcements without automatic unsubscribing. I have not found a hook in Morphic that's guaranteed to be called. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4078804.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 November 2011 05:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba wrote:
The WeakAnnouncement are already on the agenda for 1.3.
Bump... What is the status of this? Also, what are people doing in the mean time? I don't see a way to safely use Announcements without automatic unsubscribing. I have not found a hook in Morphic that's guaranteed to be called.
annoucer weak on: Announcement send: #foo to: self. when self will die, so its subscription.
Sean
-- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4078804.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 17 Nov 2011, at 05:46, Igor Stasenko wrote:
On 17 November 2011 05:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba wrote:
The WeakAnnouncement are already on the agenda for 1.3.
Bump... What is the status of this? Also, what are people doing in the mean time? I don't see a way to safely use Announcements without automatic unsubscribing. I have not found a hook in Morphic that's guaranteed to be called.
annoucer weak on: Announcement send: #foo to: self.
when self will die, so its subscription.
This works since quite a while. I use it in Glamour extensively. Cheers, Doru
Sean
-- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4078804.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Tudor Girba-2 wrote:
This works since quite a while. I use it in Glamour extensively.
Cool! Is it working well in 1.3 rc? Also, why do we still have the non-weak version? When would that be preferred? Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4081871.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 18 November 2011 04:06, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote:
This works since quite a while. I use it in Glamour extensively.
Cool! Is it working well in 1.3 rc?
Also, why do we still have the non-weak version? When would that be preferred?
virtually nowhere :)
Sean
-- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4081871.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote:
virtually nowhere :)
Should the non-weak version be removed and replaced by the weak version (renamed to remove the weak specification)? Or some other consolidation... -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 18 November 2011 06:32, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote:
virtually nowhere :)
Should the non-weak version be removed and replaced by the weak version (renamed to remove the weak specification)? Or some other consolidation...
Why? Strong subscriptions may be desirable at some point. I imagine, that some models may need to not let subsribers die, even if the only reference to subscriber is strong subscription itself. IMO, it is unusual, since Announcements framework serves as a nice decoupling scheme, which means that in most cases, you want subscription to live as long as subscriber lives and not a bit longer.
-- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote:
virtually nowhere :) Why? Strong subscriptions may be desirable at some point.
So it sounds like weak is the vast majority, so maybe have "announcer on:..." which gives you weak subscriptions and "announcer strong on:..." following "Make common things easy, rare things possible"? -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083086.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 18.11.2011 05:32, Sean P. DeNigris wrote:
Igor Stasenko wrote:
virtually nowhere :)
Should the non-weak version be removed and replaced by the weak version (renamed to remove the weak specification)? Or some other consolidation...
-- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
No. It is valuable whenever you need to deterministically unsubscribe a subscriber at some point. If using weak subscribers, bugs related to not doing so can be hard to track down. (mainly when that point somewhat coincides to when the object also loses its last reference) Second, if you do need to unsubscribe them at some set point in the programs execution, also having it registered for weak cleanup only introduces additional overhead. Third, for the moment at least, when:do: anActionBlock subscription does not work weakly, you are constrained to when:send:to. Cheers, Henry
Henrik Sperre Johansen wrote:
Third, for the moment at least, when:do: anActionBlock subscription does not work weakly, you are constrained to when:send:to.
Should I file a bug? There are no open issues matching "weak announcement" and WeakSubscriptionBuilder has the method. Is it a hard problem to solve? Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083094.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 18.11.2011 13:49, Sean P. DeNigris wrote:
Henrik Sperre Johansen wrote:
Third, for the moment at least, when:do: anActionBlock subscription does not work weakly, you are constrained to when:send:to.
Should I file a bug? There are no open issues matching "weak announcement" and WeakSubscriptionBuilder has the method.
Is it a hard problem to solve?
Sean It needs ephemeron support in the VM. There should (at least it used to) be an error raised, as per the class comment.
Cheers, Henry
Take a look in this thread: http://thread.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/15001/focus=15... ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba@gmail.com] Sent: Tuesday, January 18, 2011 2:52 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote:
Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements
Yes but having good weakstructure will not arrive by accident.
On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow."
Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote:
Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements
Yes but having good weakstructure will not arrive by accident.
On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote:
Two comments:
(1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional.
If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- www.tudorgirba.com "Every thing has its own flow."
Den 17.01.2011 07:18, skrev Sean P. DeNigris:
I really like Announcements! It's so much easier to update complex GUIs when you can pass state :)
I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe).
I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete.
SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete.
But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted?
Thanks. Sean AFAICT, #outOfWorld: might be the one you're looking for, it's called on self and submorphs as part of #removeMorph: So I THINK you'd get away with:
SubmorphMentionedAbove>>outOfWorld: aWorld self inventory announcer unsubscribe: self. super outOfWorld: aWorld . Cheers, Henry
Henrik Sperre Johansen wrote:
AFAICT, #outOfWorld: might be the one you're looking for, it's called on self and submorphs as part of #removeMorph: So I THINK you'd get away with:
:) Good thought, and thanks for looking into it! However, that was my idea too; and it doesn't work. #outOfWorld: is also called when you embed a Morph in another Morph, for instance. So, even if the Morph is still open in the world, the subscriber list is hosed. Also, when #outOfWorld: is called, there is not enough context to tell whether it is being deleted or embedded, because the actual move happens after. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3223934.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (7)
-
Henrik Sperre Johansen -
Igor Stasenko -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse -
Tudor Girba -
Tudor Girba