Have you ever seen a compiler error message like this?

[glen e. p. ropella]

Paul Johnson writes:
 > It's not easy figuring out compiler errors. 

You can say that again.

 > I've been adding code in ModelSwarm.m to add functionality in a
 > project. I've tried to build the code inside the buildObjects
 > section, just to debug and make sure calculations are correct.  I
 > put in lots of printf commands to monitor the stages.
 > 
 >  Now I want to move that code
 > out to a different file/object and integrate into a Swarm-style project.

I'm afraid I don't quite understand that at all... [grin]  Are
you saying that you have code that works and some changes that
break that code?  If so, it might be handy to see both the code
that works and the code that doesn't work.

 > That new object is in Setter.h and Setter.m, and in ModelSwarm.h
 > I've added a import statement for Setter.h and a new variable type 
 >         Setter * aSetter

Benedikt's advice is good, using the "id" instead of the "Setter *";
but, I'm not sure it's the cause of the problem, here.  If you've
imported the class interface via "Setter.h", then it should be 
available.

 > Now here is what puzzles me.  Here is ModelSwarm up through line 18:
 > 
 > 
 > // ModelSwarm.m                                      simpleSwarmBug2
 > 
 > #import "ModelSwarm.h"
 > #import <simtools.h>
 > #import "CountHeads.h"
 > #import <collections.h>
 > #import "dimarray.h"
 > #import "Setter.h"
 > 
 > 
 > 
 > @implementation ModelSwarm  
 > 
 > +createBegin: (id) aZone {
 >   ModelSwarm * obj;
 > 
 > 
 >   obj = [super createBegin: aZone];
 > 
[...]
 > 
 >  ModelSwarm.o: In function `_c_ModelSwarm__createBegin_':
 > /swarm/swarmapps/majority03/ModelSwarm.m:18: undefined reference to
 > `__objc_class_name_Setter'
 > make: *** [Voter] Error 1
 > 
[...]
 > The 18th line is the call to the super class to createBegin. Go figure.
 > Then Please explain.
 > 
 > I've tried to recode this many times and I keep ending up back 
 > at the same point.  I'm able to write the code to do what I want
 > and put it in the middle of ModelSwarm, but when I try to put it
 > out, under the control of the Setter object, I get this one. 

The compiler is telling you that line 18, which I presume is:

obj = [super createBegin: aZone];

is referring to a class called "Setter".  My first guess would be that,
somehow, the compiler thinks that Setter is the superclass of ModelSwarm.
And that's clearly silly, right?  You're not trying to subclass the
modelSwarm from Setter, are you?

So, the further diagnosis is that somewhere your interfaces are screwed
up.

So, a) did you recompile *everything* after making the code changes?
b) if not, then do so; if so, then you're going to have to examine 
your inheritance path for Setter and ModelSwarm.

If you still don't get it fixed, then I'd suggest you post the source
code that works and the source code that doesn't.  Sometimes code 
fragments don't tell the whole story.

 > Maybe, while I'm at it, I'll ask one more coding question.  I'm following
 > the standard heatbugs/tutorial approach where the build objects creates
 > a list of agents.  I'm wanting then to pass that list to the Setter
 > object.  There's no reason I can't do that, is there?  WHen the list
 > gets passed, it takes all the information about the individual agents 
 > with it, doesn't it, so that inside Setter.m, one can access the
 > information inside each object by the appropriate message. Right?

Hmmm.  "Does the list carry all the information about the individual
agents with it when it gets passed from one object to the next?"

Short answer, No.  Long answer, you don't need it.  The list only
contains id's.  When the receiver of the list pointer accesses the
list, it pulls out an id.  It can then send any *message* it knows
how to send to that id.  So, if the receiver object knows how to 
send the message "bar" to on object of class "foo", and the
objects on the list are of type "foo", then the receiver can send
"bar" to the id's it pulls off the list.

In fact, even if the objects on the list are NOT of class "foo", the
receiver object can still send the message "bar" to the id's it pulls
off the list; but, the runtime system will exit with the message:
Object "xyz" does not respond to "bar".

What this means is that the receiver object must have the list element
objects' interface or protocol imported.  There is some level of testing
the receiver object can do, though, by using methods like "respondsTo:"
to test if the elements on the list have the right interface.

Benedikt Stefansson writes:
 > I don't think that it makes a difference whether you create agents in a class
 > method or an instance method, but it doesn't hurt to try.

There *is* a difference between creating agents inside a class method
versus doing so inside an instance method; but, that difference only
lies in what info is needed for the agent creation.  For instance,
if the creation of a list of agents depends on an IVar of ModelSwarm,
say, numberOfBugs, and you try this in "+createBegin", which is a class
method, you can't use the modelSwarm's IVar, numberOfBugs, because it
hasn't been allocated or set, yet.  When you're inside a class method,
the only variables you can deal with are either locally declared ones
or static ones.

The only other possible difference between creating agents in a class
method versus an instance method is where, in memory, the agent ends
up.  This is one of the arenas where using explicit Zones is good
hygiene.  If you create a modelZone in the "+createBegin" for you
ModelSwarm and expect to put all your model-resident agents in that
zone, then the placement of the creation of those agents becomes
critical if you want to do that creation in a class method of the 
ModelSwarm.  I.e. you can't use modelZone until it's been declared
either locally or statically, if you're inside a class method.  But,
if you're in an instance method of modelSwarm, then modelZone should
be available through an IVar of the modelSwarm.

I hope some of this helps. [grin]
glen
-- 
{glen e. p. ropella <address@hidden> |  Send lawyers, guns, and money!  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }

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