[cl-store-devel] ABCL tests

[szergling]

On Nov 17, 2007 6:30 AM, Sean Ross <rosssd at gmail.com> wrote:
> Thanks for the patches, unfortunately ABCL support isn't quite up
> there with the other implementations. This manifests itself as a lack
> of support for storing instances of CLOS objects and conditions so
> while the tests fail it's more due to lack of support rather than bugs
> in CL-STORE (i'll take a look at the failures of the other tests).

Oh, I was aware of that. I just wanted to see how far it could go. It
actually seems quite promising, and for a subset of data types,
there's no reason why it won't work as is.

> > so although most of cl-store has been careful about this, were there
> > any more slips?
> > Perhaps the test should be even more general? #'equal?
>
> Both of these hash-tables are used to track objects that have already
> been restored (or stored as the case may be) and integers (and IIRC
> characters) are not checked for this. Using #'eql for these two tests
> shouldn't hurt but I feel that using #'eq it makes it clear that it is
> testing for the `same` object.

Ok, I probably should look at more cases. I had only observed, and
assumed that keys to the store/restore hash-tables are always integers
(and hence require hash-table tests to be #'eql). If that were the
case (that keys are integers), the best test to communicate the
program's intent would be to make-hash-table with :test #'=, except
hash tables only portably support :test for "eq, eql, equal, or
equalp" (default eql).

Re-reading your reply, let me clarify also that I was not referring to
the test for object identity (values (as opposed to keys) of the
store/restore hash table).

> > At the moment, there were quite a few failed tests, and I cannot even
> > finish large.1
>
> I'm not too sure what causes this but I'm assuming that it's some form
> of unhappiness between ABCL and CL-STORE.

I think it's just because ABCL runs out of memory, so please don't
read too much into that. I will try a larger heap the next time I get
around to it.

> On a side note it is probably possible to get instance and condition
> storing working since (at a quick glance) ABCL does have
> SYSTEM:%SLOT-DEFINITION-NAME and SYSTEM:%CLASS-SLOTS (among others)
> which appear to be the MOP function necessary to serialize CLOS
> instances. I'm assuming that they are a work in progress but it
> doesn't mean they couldn't, in theory, be used.
>
> Patches welcome.....

Thanks for this tip. Will come in handy.

I have also been keen on some sort of closure serialization. There
were hints of this in past chatter on this list. What is the
functionality envisioned for this feature? I have been thinking a bit,
and there just isn't any way to support portably closure
serialisation.

When desperate, we can of course always fall back to sexps. However,
for real closures, we need to know if a closure object represents an
interpreted or compiled closure (implementation dependent).
Interpreted closures may often be reproduced using their sexp or
source form, and can be portably serialised. If an implementation uses
bytecode interpretation however, it's effectively a compilation
process, since no trace of the original sexp may remain, so we can
consider that a compiled closure. Compiled closures can be serialised
while preserving compiled-function-p tests, but are not portable. Is
that the best one can do?

I have code (but not right now, can send this later if you are
interested) for serialising clisp closures, but of course, we can only
restore back into another clisp image. Some way to flag this in other
implementation would be required, so it fails gracefully and then
continues deserialising objects. Streams containing closures in a
different Lisp implementation should not cause a drastic failure when
deserialised. Perhaps a portable internal struct or class can be used
for this purpose (my clisp closure serialisation code tasted like it
needed this).

(defclass portable-closure ()
  ((compiled-bytes :initform nil)
   (sexp           :initform nil)
   (compiled-p)
   (name)
   (source-file) ;; ??
   ... etc))

Just some random thoughts.


PS: I haven't tested this, but is it a bug? Need to swap pathname to
obj in host-namestring and change (serialize ... to (store-object ...

(defstore-cl-store (obj pathname stream)
  ;; pathname-host code stolen from serialize.lisp in Rucksack.
  ;; Copyright (c) 2006 Arthur Lemmens

  ;; PORTABILITY NOTE: This is not necessarily portable. If an implementation
  ;; uses non-serializable objects to represent host or device or directory
  ;; or name or type or version, this will break.
  (output-type-code +pathname-code+ stream)
  #-sbcl(serialize (pathname-host pathname) stream)
  #+sbcl(serialize (host-namestring pathname) stream)
  (store-object (pathname-device obj) stream)
  (store-object (pathname-directory obj) stream)
  (store-object (pathname-name obj) stream)
  (store-object (pathname-type obj) stream)
  (store-object (pathname-version obj) stream))