swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: customized prob for heatBugs in repeatingHeatbugsParameter-2.0.1


From: Paul Johnson
Subject: Re: customized prob for heatBugs in repeatingHeatbugsParameter-2.0.1
Date: Wed, 22 Mar 2000 11:46:13 -0600

BEN SAID Lamjed thesard CNET/DTL/LAN wrote:
> 
> Hi,
> 
> I've tried to build a customized probe map for heatBugs in the Pauls'
> repeatingHeatbugsParameter-2.0.1 demo by adding the following code in the
> Heatbug.m file but a segmentation fault error occurs at runtime after the
> first run of the model. Any suggestions to do it ? I'm using swarm-2.0.1
> version.
> 
> Thanks.
> 
> + createBegin: aZone
>    {
>    Heatbug *obj;
>    id <CustomProbeMap> probeMap;
>    obj = [super createBegin: aZone];
>    probeMap =  [CustomProbeMap create: aZone
>                                forClass: [self class]
>                                withIdentifiers: "unhappiness", "x", "y",
> ":", NULL];
>    [probeLibrary setProbeMap: probeMap For: [self class]];
>    return obj;
>    }
> 

I think you have found one of the problems I had a difficult time
getting around.  The probeLibrary is a "permanant object" that exists
throughout the duration of the program.  You can't put the
CustomProbeMap into it twice.  When the second sim starts, that is what
it tries to do.  The work I did to make the parameter class "free
standing" on the same level as main was to avoid the crash you describe
that would happen when modelSwarm tried to stick the same thing into the
probeLibrary a second time. If you don't check that probe into the
probeLibrary, does it still crash and does the sim do what you want?  (I
recall asking about probeLibrary a few months ago and the response from
a few people was "that is a misbegotten son of a jackal" and don't
bother with it.  I don't recall ever getting any use out of it.  If you
need access to that probe map from another object, I think you can just
pass it over to get what you need from it. The probeLibrary just
circumbents the need to pass over that  pointer.

Incidentally, I have had some runtime crashes with that program and the
final edition of swarm -2.1 and I've not ironed them out. Specifically,
if you do stop, step, run on the control panel of the individual
simulation, (not the master control panel) everything is fine, but if
you do a quit before the sim finishes, the runtime error says there was
a merge schedule problem.  I'm looking into it.

-- 
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]