swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No bug in autoDrop


From: rmb
Subject: Re: No bug in autoDrop
Date: Wed, 16 Jul 1997 10:30:49 -0600

> What happend was that  actions that were occuring at the same timestep
> were treated as an Actiongroup. Each timestep, only the actionGroup as a
> whole was dropped but not every single action it contained. So we changed the
> type of the actionGroup used in the schedule by using SetConcurrentGroupType,
> so that actions were automatically dropped.
> And indeed the memory leak was gone.
> 
> Afterwards, I discovered in swarm-support that Doug has met the same
> problem a few months ago (subject: Concurrent Schedule).

Yes, it was noted before, but in the case where Doug was using a second-
level schedule as his concurrent group.  The fact is, AutoDrop on a schedule
is currently broken using the default concurrent group, so for the time
being you have to create a concurrent group type yourself and set your
schedule to use it, with code like the following:

  concGroupType = [ConcurrentGroup customizeBegin: aZone];
  [concGroupType setAutoDrop: 1];
  concGroupType = [concGroupType customizeEnd];
  
  schedule = [Schedule createBegin: aZone];
  [schedule setAutoDrop: 1];
  [schedule setConcurrentGroupType: concGroupType];
  schedule = [schedule createBegin: aZone];
 
This is a bug and will be fixed, but there's been no release of the
activity library since the earlier report.  I'll try to get this included
with some other fixes whenever we make our next general release.

> I've three more notes:
> 1. In the documentation, in Schedule.html, an example of concurrentGroup is
> mentioned. There may be a  mistake in the line:
>  [concurrentGroupType setDefaultOrder: Random];

(already noted in note yesterday; it is incorrect and should be Randomized,
but the option currently has no effect.)

> 2. Another thing from the example that didn't work was:
>  concurrentGroupType = [ActionGroup customizeBegin: [self getZone]];
> Where "ActionGroup" should be "ConcurrentGroup" to let it work.
> Does anybody know why?

I haven't been able to reproduce any problem with customizeBegin:/End on
either ActionGroup or ConcurrentGroup.  Was it used in a whole
customizeBegin:/End sequence like the above?  If so, I need a specific case
to test that doesn't work.

> 3. Furthermore we still wonder why
>  printf("autoDrop = %d\n", [modelSchedule getAutoDrop]);
> returns 0 if you have set it to 1.

This is a bug, caused by an implicit cast to the (BOOL) (same as unsigned
char) return type that dropped the high-order bits of a non-zero value.
I'll change it to return 0 or 1 as it should have been.  The option only
returns the value you've already set, so it doesn't cripple any function,
but certainly is confusing.  Thanks for the bug report; this is one that's
easy to fix!

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]