Writing CLOS objects to a file portably?
George Brewster <George Brewster >
some way to write the instances to file so that they can be read back
later.
I found one solution based on compiling a file with a form something like
(setq *saved-object* '#.*saved-object*), but this is not workable for me
because I'm working with two different versions of ACL on two different
architectures, so fasl files created on one machine can't be read on the
other.
I also found some code called save-object-9x2.lisp, which was suposed to
write arbitrary LISP objects to ASCII files in a portable way, but the
code is fairly old and I couldn't get it to work with CLOS instances.
Are there other alternatives? Should I be looking into writing a
print-object method and read macros? I've never dealt with either, and
would like a more general solution if possible.
Thanks for your help,
George
Kent M Pitman
Both are very easy and might suit your purpose.
The more general solution is to write something that takes advantage of
MAKE-LOAD-FORM methods, just as the compiler does, and dumps out binary
information in a format you like. Writing a FASL dumper/loader isn't
probably as hard as it sounds. I'd be surprised if no one's done it
and then just given it away, like they do for so many other things. ;-)
user
> Are there other alternatives? Should I be looking into writing a
> print-object method and read macros? I've never dealt with either, and
> would like a more general solution if possible.
>
It might be overkill for your purposes, but you might want to look at Plob
(Persistant Lisp Objects). It is a project on Sourceforge
(www.sourceforge.net). I've never had occasion to use it but it looks
pretty slick. I know there is a version for ACL, and LW too.
Kenny Tilton
with locience to XYXOB uncertain.
kenny
clinisys
Sam Steingold
> * On the subject of "Writing CLOS objects to a file portably?"
> * Sent on Wed, 19 Dec 2001 09:54:19 GMT
> * Honorable George Brewster <George Brewster <geo...@brewster.org>> writes:
>
> I have a few CLOS classes and instances of these classes, and I would
> like some way to write the instances to file so that they can be read
> back later.
see CLOCC/CLLIB/closio.lisp
<http://www.podval.org/~sds/data/cllib.html>
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
The program isn't debugged until the last user is dead.
user
> with locience to XYXOB uncertain.
>
XYZOB :-D.
Yep it sits on the POSTORE subsystem, which was created at the University of
St. Andrews. They own the copyright, so using it in a commercial application
could be a problem. I'd say, contact the author, his address is on the
project site, plob.sourceforge.net.
It appears that it's still being developed, albeit slowly. Last release was
in Sept., 2001.
George Brewster <George Brewster >
detail: the instances I am writing have several slots which are vectors of
large arrays specialized for single-floats or bits, but when they get
written, they are written in the #nA(.....) notation, so when they get
read back in, they get read as general arrays, not specialized ones. Is
there a convenient way to deal with this?
Thanks,
George
Kevin Rosenberg
> Hmm. I took a look at closio.lisp, and it works nicely except for one
> detail: the instances I am writing have several slots which are vectors of
> large arrays specialized for single-floats or bits, but when they get
> written, they are written in the #nA(.....) notation, so when they get
> read back in, they get read as general arrays, not specialized ones. Is
> there a convenient way to deal with this?
You could you use the function array-element-type to retrieve the
specialized element type. The element-type could be stored and then
loaded to recreate the array. The only problem I see is the ANSI
standard leaves the value of array-element-type as
implementation-dependent. So, you might get some supertype of the
element-type.
--
Kevin Rosenberg
ke...@rosenberg.net
Erik Naggum
| You could you use the function array-element-type to retrieve the
| specialized element type. The element-type could be stored and then
| loaded to recreate the array. The only problem I see is the ANSI
| standard leaves the value of array-element-type as
| implementation-dependent. So, you might get some supertype of the
| element-type.
Yes, this might be little worrying. Except for the predefined types
bitvector and string, we rely on commonality of implementations, but one
could imagine a situation where implementations A and B were such that
they had no common types of specialized arrays and shipping data back and
forth between them would be like calling upgraded-array-element-type on
each implementation with the result from the other, converging on t as
the element-type. To avoid this problem, you would have to store the
intended element-type, not the actual element-type.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.