Re: Removing probeDisplays...

[Barry McMullin]

At 11:14 11/02/97 -0600, address@hidden (Roger M. Burkhart) wrote:
>> I'm sure this is all fine and dandy; but for the
>> specific problem of not dropping probeDisplays, it
>> seems to me that it should be as easy (maybe easier) to
>> use:
>> 
>>   [probeDisplayManager removeProbeDisplayFor: self];
>
>But the problem occurs when an object is dropped unbeknownst to the display
>object that's probing it.  Objects can be dropped all the time by the
>normal running of a model, but right now a probe display goes on trying to
>keep probing it regardless.  Because an object can make no assumptions
>about the environment it's running in, batch or GUI, probed or not, it
>doesn't ordinarily have any form of access to the probeDisplayManager to
>remove itself from, assuming there even is one.

We-eel: probeDisplayManager is global (isn't it?); and if there no
such object has been created, I'm guessing (!) the global variable
will still exist, but be nil; so [object drop] *could* check this,
and send the -dropProbeDisplaysFor: to it, if it is non nil. But I
agree, this still heavily begs the performance question...

[Aside: as Glen has already mentioned, the correct message here 
*is* dropProbeDisplaysFor: and *not* "removeProbeDisplayFor:"
as I originally wrote - but that's a bug in the docs...]

[...]
>The first problem is the one I already mentioned about a SwarmObject
>knowing what probes (could be more than one) are probing it.  

This (as I understand it!) is taken care of by the probeDisplayManager 
(if it exists) - the dropProbeDisplaysFor: method is supposed to do just 
that - find and drop any and all probeDisplays on the given object.

Of course, I havn't personally tried this (;-)

>The second
>is that we don't want to build in the overhead of a whole lot of
>special-purpose probe logic into something so basic as the lifecycle of
>every object in any simulation.  Generic probe support is currently
>provided on every object at *zero* cost to the normal execution of the
>objects and model, and this remains true with the new notification
>apparatus.

Yeah, this is a fair argument; I'm guess I'm just suggesting, as
an *interim* measure (until this efficient mechanism is put in place)
that we use the crude, but inefficient, dropProbeDisplaysFor - within
the default SwarmObject -drop method. This would give us the *functionality* 
immediately, albeit with a potentially severe performance hit. But,
on reflection, Roger is right: because the potential performace hit *is*
very big, it would be a bad idea to put this in the standard Swarm
release - especially given that the "proper" mechanism can be
implemented real soon; in any case, those of us who want to, and don't
expect or mind the performance hit, can always do the crude mechanism
locally as a short term hack...

>You have suggested the right solution, which is to build probe removal
>into the standard drop message, but missed the point that the drop
>notification machinery is the very mechanism to do this in a carefully
>tuned way.  

It's not so much that I missed it, as that I was looking for
a quick(er) fix - since I'm definitely not about to try
hacking the probe machinery proper myself.  My comment
was in the context of my interpretation of the release notes 
which appeared to suggest that we (users) go ahead to exploit the 
notification mechanism to solve the probeDisplay problem.
But re-reading the release notes now, especially given Roger's
remarks, I see that I probably took this up wrongly: the release 
notes merely *anticipate* this application of the notification
mechanism, but do *not* really suggest that users do it for 
themselves...

Anyway, thanks for the clarification Roger.

- Barry.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Barry McMullin, Autonomous Systems Group,  |    address@hidden |
| School of Electronic Engineering,          |  Voice: +353-1-704-5432 |
| Dublin City University, Dublin 9, IRELAND. |  FAX:   +353-1-704-5508 |
| http://www.eeng.dcu.ie/~mcmullin/home.html |                         |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++