Re: setRepeatInterval [os:all swarm:all lib:activity]

[Roger M. Burkhart]

Steve Emsley writes:

> To hardwire updating say an active graph from deep within a model
> rather than at the GraphicSwarm level seems to go against swarm
> scheduling ideology.

The only ideology for the generic activity mechanisms is that everything
should be updatable from everywhere.  That's independent of any conventions
for what actions go into one kind of swarm or another.

The only exception is that the ability to dynamically update a schedule
to a new immediately pending time is not fully implemented.  It works
if the schedule itself is running an action to change its next pending
time, but not if some other action is changing the time.  See
www.santafe.edu/projects/swarm/archive/list-archive.9702/0270.html for one
of the first reports of this restriction.  However, I don't think this
is affecting your repeat interval changes, since as you've found, simply
changing the repeat interval on a schedule doesn't change its next
execution.  Perhaps it should, but that raises more complications about
whether the base time of the repeat interval should be changed as well.
For now, consider a workaround such as I suggest at the end of this message. 

> Can I access the internal counters that hourSchedule and daySchedule
> use. i.e. what is the equivalent syntax for getCurrentTime() but
> applied to those objects (I've tried [daySchedule getCurrentTime] and
> know that it doesn't work quite so simply).

There's no direct path to a current time from the schedule, because there's
no restriction to the number of swarms or other actions that might all
be traversing the same schedule at the same time, and even have different
notions of the current local time.  Even though schedules are ordinarily
used from only one place, there's nothing that imposes this restriction.

If you want to get the current time for a particular activation of the
schedule, you would have to save the activity object returned by activateIn:
where you can continue to get at it, and then request getCurrentTime from
that object.  But note that if the activity on the schedule is not
currently running, but only waiting for future execution within its swarm,
then the time it has is not the current time but the time of that next
pending execution.

> If I can do that is there an equivalent setCurrentTime or would the
> solution involve dropping the current, say, hourSchedule and
> recreating it with an amended repeatInterval and start time.

There is no setCurrentTime; the only way that times ever get set is the
time of any initial activation plus the results of running the schedule.

Something like your second option is probably the most reliable way to get
around any dynamic updating restrictions.  But rather than drop a schedule
which is still activated, you need instead to terminate the activity which
was running the schedule.  Normal schedule construction doesn't have to deal
with activity objects (which are returned by activateIn:), but that's where
you have to go to get a current time or to terminate an activation.

Once you've terminated a schedule activation, you should be able to just
change the schedule itself however you wish (no need to drop it), and then
reactivate it whereever and whenever you want.  It will pick up the new
base time of the repeat interval from the time when you activate it, and
use the new repeat interval for all subsequent execution.

This is probably a generic way to get around any dynamic update
restrictions: terminate a schedule in whatever swarm it's currently
running in (using the activity object returned by activateIn:) and then
reactivate it after making any necessary changes.  Just be aware that
the reactivation changes the base time from which all relative action
times are calculated, and that the schedule will start over from its
beginning.  Restarting from the beginning isn't ordinarily a problem
for a repeating schedule in which all the actions are scheduled at time
zero, but could be for a dynamic schedule with absolute times.

Feel free to experiment with the terminate and reactivate approach if it
seems to suit your needs.  I'm not sure where there are any specific
examples (my own tests usually just terminated at the top level), but
the technique should work, and others may have used terminate on an
individual schedule activation to get rid of scheduled actions after
agents were dropped.  I'll be out of email contact the next week or so,
but I'd be interested in results of any experiments you try.

--Roger

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