swarm-support
[Top][All Lists]
Advanced

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

[Swarm-Support] Lisp saving objects subclassed from Arguments_c


From: Paul Johnson
Subject: [Swarm-Support] Lisp saving objects subclassed from Arguments_c
Date: Fri, 13 Apr 2007 13:09:36 -0500
User-agent: Thunderbird 1.5.0.10 (X11/20070302)

Greetings from Beautiful Windy Chicago, Illinois, where the month of March came in like a lion, went out like a lion, and made April pretty unhappy while it went.

I have wondered about the following problem for some time. When a model is started with initSwarmArguments, and the user supplies the argument/parameter class "Parameters", there is trouble when one tries to save that argument object with lisp archiver. Here's how I try to make a shallow save:

- saveParameters: (char*)aString
{
 char dataArchiveName[100];
 id dataArchiver;
 snprintf(dataArchiveName,100,"parameters/%s.scm",aString);
dataArchiver = [LispArchiver create: [self getZone] setPath: dataArchiveName];

 [dataArchiver putShallow: "parameters" object: self];
 [dataArchiver sync];
 [dataArchiver drop];
 return self;
}

- (void)lispOutShallow: stream
{
 [stream catStartMakeInstance: "Parameters"];


  [super lispOutVars: stream deep:  NO];


 [stream catEndMakeInstance];
}

That causes a segmentation fault and the backtrace points at the lispOutVars method.

I CAN avoid that crash in saving if I create individual commands to save instance variables, like so:

- (void)lispOutShallow: stream
{
 [stream catStartMakeInstance: "Parameters"];

[self lispSaveStream: stream Integer: "numAgents" Value: numAgents];
 [stream catEndMakeInstance];
}


However, I've not succeeded in getting lisp to read in files that I save in that way. THe backtrace says the segmentation fault is caused by the "getObject" or "getWithZone:key" methods in the following example. I'm trying to allow the user to start the model with a parameter file name on the command line, or to type in a filename in the probe display and have the parameter values overwritten. My guess was that I could create a new Parameter object, and then if it has values set, I'll copy those values into the parameter object that already exists.

- loadParameters: (char*)filename
{
 Parameters * newParams = nil;
 id archiver = [LispArchiver create: globalZone setPath: filename ];
 //  newParams = [archiver getObject: "parameters"];

 newParams = [archiver getWithZone: [self getZone] key: "parameters"];
 [archiver drop];

 if ( newParams )
   {
     [self copyParameterIVARSFrom: newParams];
   }
 return self;
}


copyParameterIVARSFrom uses probes to check and see if variables exist in "newParams" and then if they do, it copies their values.



In the past, I have dealt with this by creating another parameter object subclassed from SwarmObject. But that is really hard to explain in class.

But I'm just curious enough to know what is going on in Arguments_c that I'm willing to stick my head out of the fox hole and ask what is up.




--
Paul E. Johnson                       email: address@hidden
Professor, Political Science          http://pj.freefaculty.org
1541 Lilac Lane, Rm 504 University of Kansas Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700



reply via email to

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