swarm-support
[Top][All Lists]
Advanced

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

Re: Serialization: where eagles dare! Or, what about arguments?


From: Marcus G. Daniels
Subject: Re: Serialization: where eagles dare! Or, what about arguments?
Date: 15 Mar 2002 09:14:45 -0700
User-agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.7

>>>>> "PJ" == Paul Johnson <address@hidden> writes:

PJ> Is there any reason why one should not be able to archive
PJ> arguments and then use the archiver to read in values and create a
PJ> new arguments object?

One thing that is missing is the serialization of the argv array.  It
would be useful if the basic serialization handled C string arrays,
but that requires introducing a convention for these pointer vectors.
A convention would be to require that the preceding ivar was a count
(e.g. argc for argv), and another would be to require the const char **
array's last item was NULL.  The support for this would go in
map_objc_class_ivars in defobj/internal.m (for starters).  Alternatively,
if a convention like this was thought to be obscure, you could implement
the support in {hdf5,lisp}{In{Create},Out} methods in Arguments_c.

PJ> There are many variables saved in there that I was not aware of,
PJ> such as the app path. If I moved the saved .scm file to another
PJ> system or sent it to a coauthor and he restarted the simulation,
PJ> these path and executable names here would not cause a big fit,
PJ> would they?

About the only thing the application path is used for internally is as
one way to locate Swarm.  For running normal apps from the command line,
and from a (model) source tree, it doesn't matter.

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