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.
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
George Brewster <George Brewster <······@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.
>
> 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.
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. ;-)
>
> 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.
From: Kenny Tilton
Subject: Re: Writing CLOS objects to a file portably?
Date:
Message-ID: <3C219618.5FFCB98A@nyc.rr.com>
Where does the licensing stand on that? Last I heard PLOB sat atop XYZOB
with locience to XYXOB uncertain.
kenny
clinisys
user wrote:
>
> >
> > 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.
> Where does the licensing stand on that? Last I heard PLOB sat atop XYZOB
> 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.
From: Sam Steingold
Subject: Re: Writing CLOS objects to a file portably?
Date:
Message-ID: <u8zbx4yfp.fsf@xchange.com>
> * In message <······················@typhoon.ne.mediaone.net>
> * 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 <······@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.
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?
Thanks,
George
On Thu, 20 Dec 2001 12:02:34 -0500, Sam Steingold wrote:
>> * In message <······················@typhoon.ne.mediaone.net> * 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
>> <······@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>
>
In article <······················@typhoon.ne.mediaone.net>,
George Brewster wrote:
> 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
·····@rosenberg.net
From: Erik Naggum
Subject: Re: Writing CLOS objects to a file portably?
Date:
Message-ID: <3217992151071959@naggum.net>
* Kevin Rosenberg
| 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.