Re: Doesn't Respond

[Roger M. Burkhart]

>    I have run into a couple of problems where things that
> look like they should respond to a message don't.
> 
> When I create my initial events for my objects there is
> a case in the subschedule insert where an addLast is invoked.

If you're still following the example in mousetraps2, I think this
could occur only if you were creating actions directly in a
coarse-grain schedule that contains fine-grain schedules as its actions
at each time step.  If you're using schedules as concurrent action
groups, the only way you should create actions in the owning schedule
is by means of insertGroup:.  The stack trace at the time of the
unaccepted addLast: (gdb "where" or "bt") would be enough to confirm if
some other createAction: message was being used.  The fine-grain
schedule should have an ordinary action group for concurrent actions
(this is the default), in which case the addLast: would work fine.

It's not currently possible to mix any other actions into a coarse-grained
schedule with the schedules of fine-grained actions at each timestep.

> The message when that code is executed is Schedule_c does
> not recognize addLast.  I can get around this by having 
> a seperate list for each population object but given that
> I eventually will have 10,000+ this does not seen to be a good
> long term option.  I think the code is at Schedule.m 220.
 
All this structure for two-level schedules is still experimental and I'll
be looking for your feedback on whether current capability is enough.
You'd have to explain more about the initial events you're trying to set
up, but, no, you shouldn't have to create 10,000+ lists.

My comments about addLast: are based on a call at Schedule.m line 220.

> Also, in the code you provided me in the last message I got 
> a similar message relating Activity_c and getOwner.
> 
> Am I not including something I need to?

No, that was my mistake.  For some reason the message on activity is
not getOwner, but getOwnerActivity.  (That's also the message in the
header file and reference doc.)  I don't recall why, and maybe it
can be made consistent with the other name.  Yours may be among the
first application code that's traipsing up and down the activity stack,
which we normally treat only as part of the swarm/schedule/action group
interpreter.  But to get current times out of your two-level coarse/fine
grained schedules you currently don't have a choice.

Roger Burkhart