Re: [Swarm-Support] How to prevent sending a message to a droppedobject?

[Paul Johnson]

martijn cox wrote:
> Thanks for both your answers!
> After trying to implement Pauls scheme, it turned out the problem still
> existed: the id to the dropped agent didn't point to nil (from what I recall
> from gdb it pointed to 0xfffffe or something otherwise evil-looking). After
> some thought, and reading Kens answer this made sense because the pointer to
> the voided agent never got reset to nil, so it isn't detectably pointing to
> a voided object...

What if you set the object to nil after it is dropped? I was assuming 
your dropping process had

[anObj drop];
anObj=nil;

Then wouldn't that get it?

> The bullseye solution was kindly provided by Ken's 'option A'. I had
> allready noticed and thought about using the -remove operator for schedules,
> but through some miracle of denseness I figured it wasn't applicable in this
> case. Silly me, of course it *was exactly* what I was asking for in my
> original post.
>
> Thanks again for your help, much appreciated!
>
> Martijn
>
> ----- Original Message ----- 
> From: "Ken Cline" <address@hidden>
> To: "Swarm Support" <address@hidden>
> Sent: Monday, August 01, 2005 9:39 PM
> Subject: Re: [Swarm-Support] How to prevent sending a message to a
> droppedobject?
>
>
>
> > I'm not sure that will work in Martijn's situation[1]...  If the
> > 'mother' pointer is valid when it is passed as an argument to the
> > 'considerChildbirth' message then it will be non-nil when the
> > action occurs and the message is sent to the model swarm, right?
> > If so, then the 'if (mother)' test will not detect that the pointer
> > is a handle for a dropped object, correct?
> >
> > In any case, as far as I understand it, there are 2 basic ways to
> > handle the bookkeeping issue that Martijn has:
> >  A. Agents take responsibility for their actions (no passing the
> >     buck!).  That is, the agent maintains a handle to the Action
> >     objects created and returned by the Schedule and, when the
> >     agent is being dropped, all its pending actions are also
> >     dropped.  I think all you need to do is call [Schedule
> >     remove: anAction].
> >
> >  B. Agents are managed in a data structure and actions are invoked
> >     on that structure instead of directly on the agent.  The
> >     data structure could be the model swarm, as suggested, or
> >     lists or maps that it maintains.  The data structure must
> >     keep a registry of who is alive or dead and then either
> >     execute or ignore any the requested action as appropriate.
> >     That is, just what Paul has shown except that you'd test
> >     if the mother ID was in your "obituary" list.
> >
> > I think either approach is acceptable; both have pros and cons.
> > And there are hybrid designs as well, e.g. the model swarm could
> > maintain a data structure that maps agent IDs with handles to
> > their Action objects and does the schedule clean up on behalf to
> > agent and its grieving family.
> >
> > Note, there may be other reasons for maintaining agents in
> > cryostatis, e.g. for calculating statistics at the end of a
> > simulation.
> >
> > Btw, another approach, which is perhaps a little more technically
> > challenging, would be to extend the Swarm framework.  For example,
> > you could define a protocol called MortalAgent and create a subclass
> > of Schedule.   Your subclass of Schedule would understand that when
> > an Action to a MortalAgent is created that it, the subclass Schedule,
> > should store the necessary bookkeeping information to remove all of
> > that agent's actions when it dies.  There are merits to this design
> > as well, e.g. the agent code becomes much simpler and the Schedule
> > subclass may be able to implement efficiencies that the agent object
> > can not.  However, I suspect that it would take a fairly deep under-
> > standing of the Swarm libraries to implement this approach.  Maybe
> > not, though?
> >
> > My $0.02.  Hope that helps.
> > Ken
> >
> > PS: There are many things other than schedules/actions that can
> >    hold onto pointers to dropped agents, e.g. probes, UI widgets,
> >    and etc, and hence could cause segmentation faults.  It's
> >    amazing how many lives a simple agent can touch.
> > ____________
> > [1] My apologies if I'm wrong about this.  I'm not actively doing
> >    and C or Objective-C programming (not much programming at all,
> >    in fact) and so I'm a little rusty on this stuff.
> >
> > --- Paul Johnson <address@hidden> wrote:
> >
> >
> > > I think I'd redesign it so that dead mothers were never sent messages.
> > > That is, remove the dead ones from the lists being processed.
> > >
> > > But I think you can brute force fix this like so. Instead of having this
> > > message put "haveChild" with target "mother__" on schedule, have it aime
> > > the message at something you are sure exists, say model swarm.
> > >
> > > [lifeMutationSchedulw at: (time + (int) (0.25* DPY*MPD)) createActionTo:
> > > self message: M(considerChildbirth):mother];
> > >
> > >
> > > Then in that method
> > >
> > > (void)considerChildbirth: mother
> > > {
> > >    if (mother) [mother haveChild];
> > >    else fprintf(stderr,"you just tried to give birth from the dead,
> > > silly!");
> > > }
> > >
> > > If "mother" is a pointer to nil, then this will prevent the seg fault.
> > >
> > > Won't it?
> > >
> > > pj
> > >
> > > martijn cox wrote:
> > >
> > > > Hi,
> > > >
> > > > Im new here so if I break any form of etiquette, please forgive me :)
> > > >
> > > > I've been working on a (very simple) swarm-based simulation of
>
> evolution,
>
> > > > and have come accross the following problem. Female animals can have
> > >
> > > babies,
> > >
> > > > after impregnation by a male. This impregnation is a combining of the
> > >
> > > neural
> > >
> > > > networks of the parents, and this new neural network is stored in the
> > > > female. during here. During her pregnancy, the female can die, and
>
> carry
>
> > > her
> > >
> > > > unborn child with her (*sob*).
> > > >
> > > > The problem is, that I'd like to have the pregnancy scheduled by the
>
> model
>
> > > > by the following ActionCreateTo:
> > > > --------------------------------------------
> > > > -scheduleBirthFromMother: (id) mother__
> > > > {
> > > > *snip*
> > > > [lifeMutationSchedule at: (time + (int) ( 0.25 * DAYSPERYEAR *
> > > > MINUTESPERDAY ))
> > > >   createActionTo: mother__
> > > >   message: M(haveChild)];
> > > > *snip*
> > > > }
> > > > --------------------------------------------
> > > > and if the female dies somewhere between impregnation and giving
>
> birth,
>
> > > this
> > >
> > > > message is send to a voided reference (because the female has long and
>
> gone
>
> > > > been dispatched of by a reaperQueue).
> > > > The final result is that every call subsequent call to create sends my
> > > > program crashing to its segmentation faulty damnedness, I presume
>
> because a
>
> > > > method has been called on with self = nil and as a consequence, the
>
> stack
>
> > > > has become corrupt.
> > > >
> > > > A short term solution I've been using so far, is to not wipe the
> > > > reaperqueue, but keep all agents in cryostatis for the length of the
> > > > simulation (so the speak). Another solution would be to undo the
> > > > ActionCreateTo, but I see no way in all documentation I've searched
>
> through
>
> > > > how this can be done.
> > > >
> > > > If no one can help me, I will probably resort to waiting untill after
>
> the
>
> > > > message has been sent to the dead agent before I wipe it from memory,
>
> but I
>
> > > > don't think that would be a very clean solution.
> > > >
> > > > Kind regards,
> > > >
> > > > Martijn Cox
> > > >
> > > > ps: my gratitude for supplying the incredibly usefull environment to
>
> anyone
>
> > > > who has ever contributed to swarm! :)
> > > > _______________________________________________
> > > > 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
> > > _______________________________________________
> > > Support mailing list
> > > address@hidden
> > > http://www.swarm.org/mailman/listinfo/support
> >
> >
> >
> > _________________________________________________________
> > Ken Cline                             W: (443) 287-2636
> > address@hidden
>
> _______________________________________________
> 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