swarm-support
[Top][All Lists]
Advanced

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

Re: Problem with Object2dDisplay


From: Paul E. Johnson
Subject: Re: Problem with Object2dDisplay
Date: Wed, 29 Sep 1999 09:19:48 -0500

>From looking at your code, I think you and I have some common
experience.  If you are looking for a way to have model swarms be "born"
"run" and "dropped", with their graphics being displayed each time, I
have had the same interest.  In my project RepeatingHeatbugs, I have
this working so the heatbugs model runs over and over again. I put a
copy in the sfi anarchy directory and also i think you can get it on my
page (below).

What troubles me about your code is that you are ignoring the scheduling
hierarchy ideas that underlie swarm.  It seems nonsensical to me to
allow the model swarm to schedule activites of the higher level swarm,
for example.  I can't find your runModel code in this snip, but I'm
afraid you've got a mismatch between what is going on in the observer
and the model levels.  You want new models to activate graphical
displays for themselves, when the usual notion in Swarm is that the
graphical displays are created and models are created to populate them.

It is hard to tell from a code snippet how this all fits together.  I
can't understand the TkSuperObject reference in your code, either, but
that's just me, maybe.  If you need to refer to observerSwarm in the
Model swarm, which seems weird to me, you have to have a
setObserverSwarm: method in ModelSwarm, and then when the ModelSwarm is
created, have the observer execute [modelSwarm setObserverSwarm: self]. 
That would mean you could call the observer from within methods in the
ModelSwarm.  Perhaps you did that...

It is more within the Swarm paradigm (is that word too 1970s?) to have a
higher level swarm object, which some people call "experimentSwarm",
which can spawn new observers, which in turn spawn new models, and then
when the model finishes you drop all that and regenerate a new observer,
and thus a new model.  

I think your code in the Observer is close to being correct,but instead
of putting the other part in ModelSwarm, it needs to be in a higher
level class, such as experSwarm (or in my RepeatingHeatbugs code,
"managerSwarm").

I hope I've not totally misunderstood your problem.
pj

Konrad Lang wrote:
> 
> >>>>> "KL" == Konrad Lang <address@hidden> writes:
> >>>>> "MG" == Marcus G. Daniels <address@hidden> writes:

> The Grid2d is destroyed but recreated and reassigned to a new
> Object2dDisplay within the ActivityGroup.
> 
> KL> function: _i_Object_s__doesNotRecognize_(), file: DefObject.m,
> KL> line: 635 ObjectX does not recognize drawX:Y:*** execution
> KL> terminating due to error
> 
> MG> What is an "ObjectX"?  Does it belong in the lattice?
> MG> Does it make sense to send drawX:Y: to it?
> 
> ObjectX normaly points to some agent that implements a drawX:Y: method,
> but after the first ciycle this points to some other object out of the
> model swarm that does not implement the drawX:Y: method.
> 
> I provide some sample code:
> This is the Schedule of the Observer Swarm:
> 
> // Creation of the ActionGroup & Schedule:
> experActions = [ActionGroup create: self];
> // The model is built ( with all the objects created)
> [experActions createActionTo: self    message: M(buildModel)];
> // The worldRaster & Object2dDisplay are created
> [experActions createActionTo: self message: M(build2DModelOutput)];
> // Run the model
> [experActions createActionTo: self    message: M(runModel)];
> // Do the Tk Events
> [experActions createActionTo: actionCache message: M(doTkEvents)];
> // Drop the worldRaster & Object2dDisplay
> [experActions createActionTo: self    message: M(drop2DModelOutput)];
> // Drop the model
> [experActions createActionTo: self    message: M(dropModel)];
> 
> // And the schedule for the whole thing
>  experSchedule = [Schedule createBegin: self];
>   [experSchedule setRepeatInterval: 1];
>   experSchedule = [experSchedule createEnd];
>   [experSchedule at: 0 createAction: experActions];
> 
> The significant methods are:
> - build2DModelOutput
> {
>  ...
>   worldRaster = [ZoomRaster createBegin: self];
>   SET_WINDOW_GEOMETRY_RECORD_NAME (worldRaster);
>   worldRaster = [worldRaster createEnd];
>   [worldRaster enableDestroyNotification: self
>                notificationMethod: @selector (_worldRasterDeath_:)];
>   [worldRaster setColormap: colormap];
>   [worldRaster setZoomFactor: 4];
>   [worldRaster setWidth: [[theModel getWorld] getSizeX]
>                  Height: [[theModel getWorld] getSizeY]];
>   [worldRaster setWindowTitle: "Agent World"];
>   [worldRaster pack];                             // draw the window.
> 
>   agentDisplay = [Object2dDisplay createBegin: self];
>   [agentDisplay setDisplayWidget: worldRaster];
>   [agentDisplay setDiscrete2dToDisplay: [theModel getWorld]];
>   [agentDisplay setObjectCollection: [theModel getAgentList]];
>   [agentDisplay setDisplayMessage: M(drawSelfOn:)];
>   agentDisplay = [agentDisplay createEnd];
> 
>   return self;
> }
> 
> - display2dModelOutput
> {
> 
>   [agentDisplay display];
>   [worldRaster drawSelf];
> 
>   return self;
> }
> 
> - drop2DModelOutput
> {
>   [worldRaster drop];
>   worldRaster = nil;
>   [agentDisplay drop];
>   agentDisplay = nil;
>   return self;
> }
> 
> And from the ModelSwarm Object some of the methods in the observer swarm
> are called:
> 
>   modelActions = [ActionGroup create: self];
>   [modelActions createActionForEach: agentList    message: M(step)];
>   [modelActions createActionTo:      self       message: M(checkToStop)];
> 
>   // XXX Only for update of 2dObjectDisplay
>   [modelActions createActionTo:  TkSuperObject message: 
> M(display2dModelOutput)];
>   [modelActions createActionTo:  TkActionCache message: M(doTkEvents)];
>   }
> 
>   // TkSuperObject is the id of the ObserverSwarm
>   // TkActionCache is the id of the ObserverSwarm actionCache
>   // So that TkEvents are triggerd within the ModelSwarm
> 
>   modelSchedule = [Schedule createBegin: self];
>   [modelSchedule setRepeatInterval: 1];
>   modelSchedule = [modelSchedule createEnd];
>   [modelSchedule at: 0 createAction: modelActions];A
> 
> 

-- 
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]