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