dynamic schedule update bug

[rmb]

A couple weeks ago, Ho-Sheng Hsiao (address@hidden) wrote:

> The way I coded my model, I have a two schedules under one ModelSwarm. One
> is the regular repeating schedule, and the other holds a discrete event
> "scratch schedule" a la mousetraps.
>  
> The repeating schedule controls the model's interval -- and since I'm
> using multiple model swarms, I can produce different interval ratios. But
> I still require a discrete event portion of the model, so I used a
> seperate (non-repeating, autodropping) schedule to handle that. 
>  
> The repeating schedule works fine; however, the scratch schedule doesn't.
>  
> Specifically, I defined a function,
>  
> -(void) modelDeliverRouterMessage: (RouterMessage *) msg To: (id) target {
>  
> [modelScratchSchedule at: (getCurrentTime() + 1
> createActionTo: target
> message: M(eventReceiveMessage:):msg];
> }
[...]

There were discussions after this message on argument passing questions that
I think were separately resolved.

The original, basic problem, however, could have been caused by a known bug
in updating of dynamic schedules:

If a dynamic schedule has an action inserted at a time sooner than any
of its currently scheduled times, and this insert is not performed by the
dynamic schedule itself (for example, from another schedule, such as the
repeating schedule in this example, or from some other code location),
this inserted action may never be performed by the swarm in which the
dynamic schedule has been activated.

The mousetraps example of a dynamic schedule does not suffer from this
problem because it is the mousetrap's own schedule that inserts actions
at new times.  The problem occurs only when it is another schedule that
tries to insert actions in the separate dynamic schedule, and the
dynamic schedule is not the one currently being executed.

A fix for this problem is expected in a Swarm 1.0.1 release coming up soon.

Roger Burkhart