Re: Help!: of Swarm, Objective-C and gdb

[Marcus G. Daniels]

>>>>> "WS" == William S Shu <address@hidden> writes:

WS> A) Swarm: 1) I want a swarmObject to "self-destruct" under certain
WS> conditions, but sending the message: [self drop]; causes
WS> segmentation violation.  (It would seem execution path is lost!)
WS> I do not have any problem if another object sends the message, but
WS> it makes my code unduly complicated and not self-contained.  Can
WS> anyone explain to me how to achieve self-destruct elegantly?

Could it be that you are not truly finished using the object after the drop?
You would get a segmentation fault, for example, if the calls to
`life' and `death' in `lifeAndDeath' below were reversed...

#import <simtools.h>
#import <objectbase/SwarmObject.h>

@interface Foo: SwarmObject
{
}
- life;
- (void)lifeAndDeath;
- (void)death;
@end

@implementation Foo
- life
{
  printf ("Happy Happy, Joy Joy!\n");
  return self;
}
- (void)lifeAndDeath
{
  [self life];
  [self death];
}

- (void)death
{
  printf ("Nice knowing you..\n");
  [super drop];
}
@end

main (int argc, const char **argv)
{
  id foo;

  initSwarm (argc, argv);

  foo = [Foo create: globalZone];
  [foo lifeAndDeath];
}

/*
Local Variables:
compile-command: "/opt/egcs/bin/gcc -o x -g -Wno-import -L/opt/SUNWtcl/sun4/lib 
-R/opt/SUNWtcl/sun4/lib -L/opt/SDGblt/2.4g/lib -R/opt/SDGblt/2.4g/lib 
-L/opt/SDGlibffi/1.20/lib -R/opt/SDGlibffi/1.20/lib -L/opt/SDGswarm/1.4.1/lib 
-L/opt/SDGzlib/1.1.3/lib -L/opt/SDGhdf5/1.0.1/lib -R/opt/SDGhdf5/1.0.1/lib 
-L/usr/local/X11/lib -R/usr/local/X11/lib -L/usr/openwin/lib -R/usr/openwin/lib 
-L/usr/local/lib -I/opt/SDGhdf5/1.0.1/lib -I/opt/SDGswarm/1.4.1/include x.m  
-lsimtools -lsimtoolsgui -lactivity -ltkobjc -lrandom -lobjectbase  -ldefobj 
-lcollections -lmisc  -ltclobjc -ltk8.0 -ltcl8.0 -lBLT -lsocket -ldl -lnsl 
-L/usr/openwin/lib -lhdf5 -lpng -lz -lXpm -lX11 -lffi -lm -lobjc -lposix4"
End:
*/


WS> 2) Related to (1) above, will I face any problems with parallel
WS> access to objects when deleted? or when not in the same group acti

If multiple objects expect that an object exists, and it commits suicide, 
yes, it could cause disorder.  The method addRef:withArgument: can
be used to handle these deaths.

WS> 3) How are the protocols (??) CREATABLE etc used in object
WS> (declarations?).  I recall seeing some example usage/explanation
WS> somewhere, but can't trace it.  (Variant in Swarm documentation
WS> *not* informative enough.)

Do you mean protocol compliance checking?  That syntax is:

@interface MyObject: SwarmObject <MyProtocol>

WS> B) Objective-C 1) I try to define a category, but Objective-C
WS> complains (warns) that certain methods are not seen, unless I
WS> define them in the initial object!  The program seems to run OKAY.
WS> But what am I doing wrong?

Well, all the category headers would need to be included. 
(We don't really advocate or use categories, for no particular reason
except that it is One More Thing.)

WS> 2) In C, I use typedefs to preserve/defer design decisions,
WS> especially with prototype implementations and shared code.
WS> Objective C will not allow things like: typedef id <List> Cluster
WS> // clusters are of type id with List protocol id <int> x; //
WS> restrict values of id to those of type int

"typedef id <MyProtocol> myid" works fine for me.  Can you provide
a self-contained example?

WS> C) using gdb on Objective-C: 1) How do I: * make command aliases
WS> (so as to avoid lengthy typing). 

What you want is the `command' command.
(This is in the GDB manual.)

WS> * display the the fields of
WS> objects, but without having to type-cast each field in
WS> substructures, or being displayed fields you do NOT want.  (The
WS> document by Martin Cracauer does not cover this!)  * have/access a
WS> history of gdb commands typed in current session.

The Objective C support is not a standard part of GDB.  I personally
use the stock version of GDB, and "print *self". 

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