Re: ordering events in a swarm ....

[Paul E. Johnson]

xueyue wrote:
> 
> > does this mean the following will work?
> >
> >  - start
> >  {
> >    count = 0;
> >    schedule = [Schedule create: globalZone];
> >    [self schedule: 3];
> >     [[schedule activateIn: nil] run];
> >     [schedule at: 7 createActionTo: objecta message: M(actiona)];
> >     [schedule at: 5 createActionTo: objectb message: M(actionb)];
> >
> >    // ...more new schedule for 'schedule' object
> >    // ...
> >    [[schedule activateIn: nil] run];
> >    // create more objects and actions to schedule, ...
> >    [[schedule activateIn: nil] run];
> >     return self;
> >  }
> 
> I just tested, this will work, but a new problem arise:
> the actions inserted after [[schedule activateIn: nil] run]
> will start to be excuted only if those before [[schedule activateIn:
> nil] run] has been completed.

I don't understand what behavior you want and why you don't manage the
schedule in the standard swarm way, with buildActions and activeIn as
separate methods.   I have a feeling you are not getting answers to the
right questions because we don't understand your purpose in using these
"run" commands.  The activateIn: returns an activity, and when you tell
that to run, it will go until it is told to stop.  That's what run is
all about.  Run doesn't mean step, so it seems logical that the activity
that comes back from [schedule activateIn:nil] would run to its
conclusion.  Then the next commands you have create more actions, and
the "run" will make them go until they stop and then move onto the next
one.

If you need the actions at the top of your schedule to "stop
themselves", you can write methods inside them that will make them stop
after one step or such.  That would force the processing to the next
stage.

The only examples of Swarm code I know of which use run are ones that
run repeated exeriments.  If that is your aim, I've got some experience
with that when I worked on making Heatbugs repeat itself.  But in those
examples I've never seen a need/use to have several run commands in the
middle of a class like you have. 


> In other words,
> each [[schedule activateIn: nil] run] reset the schedule to
> currentTime=0 and excuted actions inserted till no actions exists.
Do you mean this is a problem in your view?  If you need the things
scheduled later to be "mixed in" with the others, then you can't have a
run comand to the Activity where you have it. 

As Marcus mentioned, you can use run commands in this way to get a sort
of "repetition" exercise going, but as you also must have noted, it
doesn't necessarily work the way you expect.



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