Re: Schedules

[Roger M. Burkhart]

Doug Donalson writes:

> Really two related questions.  First let me remind you
> that I am using the double tiered schedule as an asynchronous
> event list.
> 
> 1.)  Is there any way that I can remove an event (action) from
> the schedule.  My agents project forward in time a number of events
> in their lifetime which may be, in the case on death as an example,
> may be invalidated.  I have a hack that gets around this without 
> modifying the list but it is pretty ugly.

Yes.  One of the fixes in Swarm 1.0.0 was to make sure that removing
actions from a schedule worked correctly.  Remember that a schedule is
just a map, and an action is a member of the Map indexed by the (timeval_t)
key value.  But either a schedule or an action group also supports the
behavior of a Set consisting of all its actions.  So for any action
contained in a schedule, you can now remove it using the standard Set
remove: message:

- remove: aMember;

So you can remove the action from a schedule using:

removedAction = [aSchedule remove: anAction];

Note that the action must already belong to the schedule for this to work
correctly.  remove: from a schedule automatically takes care of removing
the action either from the schedule itself or from a concurrent group
contained at a single time value of the schedule.  If an action belongs
to a concurrent group of a schedule, you should it remove it from the schedule,
not from the concurrent group directly.

The removed action could actually be kept around and reinserted into the
schedule at some other time, but there are not yet any guarantees about
alternate ways of scheduling an action (anything besides a standard
createAction message) working in all circumstances.  So for now, you
should just drop any actions you remove, and schedule new ones whenever
you need them.  So also code the statement:

[removedAction drop];

> 2.)  Is there a way I can find the time for the next event from
> the system schedule?  I may have to create some events real time 
> and then check and see whether they would occur before the first 
> event on the list.  Could I use a version of the print event list
> that you showed me (quite a long time ago) or is there a better method?
> In this case the result is non-destructive.  (I just need to look.)

You can open up an index on the schedule and traverse all the actions
or concurrent groups contained within it, using the internal structures
you're already to some extent having to deal with to handle your two-tier
schedules.  But that doesn't tell you what event is currently being processed
by an activity.  I don't think there's any currently supported way to position
your own index to the action currently being processed by an activity, but
that's the way this capability should be provided.

For now, you could open up your index on the schedule and move it until
its member matches the current action returned by the "getAction" message
on an activity.  If you're using a dynamic schedule in which you drop
everything after it's already been processed, all your pending actions
will be near the front of the schedule or action group where you can test
if they're the current or pending action very quickly.  To get the time
value from a schedule index, using a getKey message and cast its result
to (timeval_t).

> Sorry Roger, I know I'm always doing something different than the rest
> of the hive but it at least adds to the diversity?!

Thank you for your boldness in trying to use capabilities that other
applications haven't tried to test yet!  Diversity after all is the
hallmark of any real or artificial life that Swarm needs to simulate.

-Roger