[Swarm-Support] Re: List problem: many bugs accessing a single list

[Jurgen van der Pol]

Dear Paul,

> like this, one of which is creating an Exterminator to kill bugs. Look
> in this folder under Exterminator or something like that.

Yes, found them, thanks. Think that's it: I'll go over them in detail 
next week (whilst on vacation in France)!

> comments I can't tell exactly what is going wrong. Here's what I would

simply said, the (de)allocation of cargo goes astray, most likely as 
all bugs have the same local copy of the cargo list.

> First, you have the Cargo objects and when they are created (say, in
> ModelSwarm), you add them to a cargoList.  Then inside each agent, 
> there's
>
> - (void)setCargoList: aList
> {
>      cargoList = aList;
> }

I do this now in - buildobjects in modelswarm:

- buildObjects

//[SNIP]

        cargoList = [List create: self];
        for (y = 0; y < numberOfCargo; y++)
        {
                aCargo = [Cargo createBegin: self];
                [aCargo setWorld: world];
                aCargo = [aCargo createEnd];
		[aCargo setX: [uniformIntRand getIntegerWithMin: 0 withMax: 
worldXSize]

//[SNIP]

                [aCargo deAllocate]; // make sure it's 'accessible'

                [cargoList addLast: aCargo];
        }

Also, I build an index of that list in - buildobjects in modelswarm:

        cargoIndex = [cargoList begin: [self getZone]];


> And in the ModelSwarm, when the truck/bugs are created, one of the
> commands will be
>
>    [aBug setCargoList: cargoList];

Yes, I do this too in - buildobjects in modelswarm on the creation of 
the bugs:

		// now pass the cargolist to the bug. Each bug will now have the 
-same- list.
                [aBug setMyCargoList: cargoList];


> Note I use the same name "cargoList" for the IVAR in the ModelSwarm and
> in the Cargo class, because it makes my life simpler.

Wait a minute, my cargoList is defined in modelswarm.h:

        id <List> cargoList;
        id <Index> cargoIndex;

Are you suggesting to do this also in cargo.h/m? Or am I not following 
you?


> That way, each agent has access to the list.

I think I'm already doing exactly what you propose? Modelswarm builds 
the list of cargo agents, then on creation of the bugs, they get the 
list via

                [aBug setMyCargoList: cargoList];


> Now, in the cargo object, add a variable "blocked" or something like
> that.   In what you have below, I don't see such a thing.  Just a YES 
> or

Yes, it is there but I didn't include it in the code snippets. From 
cargo.m:

//***********************
- Allocate
{
        allocated = 1;
        
        return self;
}

//***********************
- deAllocate
{
        allocated = 0;
        
        return self;
}

//***********************
- (int) getAllocationState
{
        return allocated;
}

Yours is more elegant, of course :-|

> Now, when some agent wants to grab a piece of cargo, it looks at one
> from the cargo list, and then asks that object if it is taken.

And this I don't seem to be able to get going. At least, it 'breaks' 
with indication that the bugs cannot somehow access the list. I must 
rummage through older versions to see If I can still reproduce the 
exact error. So what I did was the go-between I hinted at, by doing 
this in bug.h/m:

//we're now in bug.h

        id myCargoList;                                         // the list of 
cargo's from modelswarm
	id myCargoIndex;					// the index of the list of cargo's from 
modelswarm

- (void) setMyCargoList: aList;
- setMyCargo;

//we're now in bug.m:

- (void) setMyCargoList: aList	// this gets the cargolist from 
modelswarm
{
                myCargoList = aList;    // make bug's local list
		myCargoIndex = [myCargoList begin: [self getZone]]; // make local 
index of list
}


//*********************
- setMyCargo                    // to get variables from cargo object into bug
{
        myCargo = [myCargoIndex next];          // get next cargo object on list
        if ([myCargoIndex getLoc]==End)         // are we at the end of the 
list?
                [myCargoIndex setLoc: Start];   // then go back to the beginning
        
	if ([myCargo getAllocationState] == 0)  // is it NOT already allocated 
(by another truck)?
                {
			[myCargo Allocate]; // this is important, it effectively 'blocks' 
other truck's access to this specific cargo object
                }
                else
                {
                        myCargo = [myCargoIndex next]; // get next cargo object 
on list
                                if ([myCargoIndex getLoc]==End) // EOL check
                                [myCargoIndex setLoc: Start];   // if so, go 
back to front
                }

	xDest = [myCargo getXDest]; // ok, got a cargo object, now read the x 
destination from it
	yDest = [myCargo getYDest]; // ok, got a cargo object, now read the y 
destination from it

        return self;
}

> If you still have this "blocked" idea in mind, then I suppose an agent
> would have to iterate through the list until it finds a nonTaken item. 
> I
> don't have the C manual in front of me, but I'd use a while loop to
> iterate like this in order to grab the first one:

Yes, much cleaner that is. Thanks.

> The other approach, which I think would be more realistic, would be to
> have a list of "notTakenCargo" and then put things on and off of it.  
> An

Aaargh! More lists! :-< And here I am having trouble with just one...

> agent could interact with the cargoList and remove items when they are
> in its possession.  Or you could have an ObjectGrid2d and place
> unblocked objects on it (like food for bugs).

Er, yes. That's another possibility. Oh dear. More study ahead...

Thank, Paul, Much obliged.

Cheers,
Jurgen.