Re: getCurrentActivity()

[Roger M. Burkhart]

>    If you remember, you had me use getCurrentActivity()
> as a way to get the current system time when using the 
> two level version of the time schedule.  Particularly,
> I use the the main schedule tiem as the integer part of my time
> and the subschedule time as the decimal part.  When executing
> an event, I am in the time subschedule so I use the code
> 
>   eventTime=getCurrentTime();  
>   activity=getCurrentActivity();  
>   if( activity != nil )  
>   {
>      ownerActivity = [activity getOwnerActivity];     
>      while ( ! [ownerActivity respondsTo: M(getCurrentTime)] )        
>      ownerActivity = [ownerActivity getOwner];     
>      superTime = [ownerActivity getCurrentTime];     
>      time=superTime+ eventTime*precison; //precison right shifts eventTime
>   }
> 
> so that I have 'superTime.eventTime' as my system time.
> 
> Please tell me that there is another procedure that takes the place
> of getCurrentActivity!  If there isn't and there isn't another way
> to do this same thing then I'm shut down.
> 
> Cheers?
> 
>    Doug Donalson

Hi Doug -- I actually wondered if you were still out there doing the
two-level schedules while I was working on the activity code, because
I'm trying to fold a design for multi-level time resolution into swarms
themselves, which I think we may be able to get into future releases.

I didn't realize I'd broken your use of getCurrentActivity(), however.
(We have only a few uses ourselves.)  But it needn't shut you down.

What we're in the process of doing is adding an extra level of subactivity
for the currently running action, so get "current activity" actually will
return a different level of activity than before.  The same macro that was
getCurrentActivity() is now available as getOwnerActivity(); if you
replace it by that it should work as before.

However, one more thing is that if you try to execute the macro and
there's not actually a running activity (if you probe when stopped, for
example) we now raise an error rather than let the code go on and do
unpredictable things.  The macro to check if there is a running activity
(so you can guard against this error) is still getCurrentActivity(),
except that's not available while we make the switch.  Sort of a
catch-22.

As a work-around for now, just replace your "if ( activity != nil )" with
"if ( _activity_current != nil )".  (You're normally supposed to use one
of the macros to reference this global variable, but it's usable for now.
In future releases the way we handle the current activity may change, so
be sure to change it back to the macro as soon as that's available again.)

I'll try to complete the changeover to the new macro levels in the next
full code release, but I wanted a bit of interruption just to make sure
that no one was using the old macro at the current activity level.  Thanks
for showing me I was wrong.  I think you are still the only person doing a
two-level schedule (anyone else pleae let me know if I'm wrong).

Two-level schedules should still work, though if you're creating the
subschedule as a concurrent group of the coarser schedule you may have to
change the setConcurrentGroupType: argument to ConcurrentSchedule (a new
name) to get deallocation to work properly.  (If anyone else is using a
custom ConcurrentGroupType, please let me know.)  See mousetraps2 in
swarmdocs/src/grid for an example I specifically converted just to make
sure I hadn't broken two-level schedules.

Sorry about the scare, but as far as we know we haven't broken any
capability that was there before, just cleaning things up and fixing some
interface conventions while there was still time.

-Roger