Re: [Swarm-Support] Usage of Drop

[Paul Johnson]

It is legal to call drop on yourself  ([self drop]), but you have to be 
very cautious if you do that.  In the Swarm Sugar Scape example, they 
avoid it by having objects report themselves to a reaper so they can be 
cleaned out at the end of the step.

I have tried the immediate drop method and often run into segmentation 
faults. Here are 2 reasons why.

1. Suppose agents are in a list.  If one drops himself, but does not 
remove all traces of himself from the system, then some other agent may 
try to access that agent, and then finds nothing, and seg fault occurs. 

2. Note vitally that the drop method returns void.  Your object 
overrides drop, and must return void.  SO everything that has to happen 
to clean up that object's memory has to happen first, before its 
dropped.  Cleaning up the memory while your code control is inside the 
object itself is tough.  It is cleaner to have some other agent (a 
"reaper") tell the object "clean your memory" and then drop it  with 
[anObject drop]

I fought with this a lot in the arborgamesII code revisions last fall.  
I wanted trees to burn and die right away, to immediately remove 
themselves.  I thought I had meticulously found all references to trees 
and removed them, but it did not work.

Here's another drop related issue.  In Swarm, the List collection is 
slow at finding particular agents.  If you want to drop a particular 
agent, you go searching in that list, and it makes it slow.  On the 
other hand, if you write the model so that you are processing agents in 
a list, and when you find one that needs to die, you have it in  hand 
and don't need to search, and you can move it into a list of agents 
scheduled for death.

The only fast option is this relic, deprecated thing 
"setIndedFromMemberLoc" that you find in some old swarm models.  Its a 
very non portable thing and we were talking about banning it altogether 
in user applications, although I don't recall all of the problems with 
it.  It works by creating an instance variable in every agent that gives 
that agent's position in the list.  The arborgames code (original 
version) used that alot.  Because it was deprecated, I think I tried to 
eliminate it in arborgames II

pj

Crile Doscher wrote:

> Can an object call drop on itself, i.e. something along the lines of [self drop];?  My gut 
> feeling is no but thought it might be useful to check.  The context is that I have agents 
> that I'd like to drop once they reach a given set of coordinates - in my case, the agents 
> are water volumes that flow over and then out of simulation space and aren't needed 
> again.  Wrap around is currently enforced so I'm looking into un-enforcing that but will still 
> need to drop them in some way.  The agents are created in a ModelSwarm so I'm 
> assuming they'll have to be dropped from there, though I don't quite see the best way for 
> such an agent specific thing to bubble up to that next level.  Thanks -
> Crile
> _______________________________________________
> Support mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/support
>  


--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504                              
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700