From malcolm.reynolds at gmail.com Sat May 9 17:41:11 2009 From: malcolm.reynolds at gmail.com (Malcolm Reynolds) Date: Sat, 9 May 2009 18:41:11 +0100 Subject: [cl-store-devel] "Cannot store objects of type SYSTEM-AREA-POINTER with backend cl-store" Message-ID: Hi I've been receiving this error when trying to save out a matrix of the format used inside GSLL (GNU Scientific Library for Lisp) using cl-store - this can be reproduced by doing the following: (cl-store:store (gsll:make-marray 'double-float :initial-contents '((1 2 3) (4 5 6) (7 8 9))) "blahblah") => "Cannot store objects of type SYSTEM-AREA-POINTER with backend cl-store" I googled the error message but all that turned up was various copies of the source code. I guess the error is due to GSLL doing something funky with it's data structures in order to call C functions on them.. is there any way around this problem (perhaps by using a different backend in the optional argument to store)? If not I can just convert matrices to and from gsll format as I load them, but it would be handy to avoid having to do this. Thanks in advance, Malcolm From rosssd at gmail.com Sat May 9 18:37:25 2009 From: rosssd at gmail.com (Sean Ross) Date: Sat, 9 May 2009 19:37:25 +0100 Subject: [cl-store-devel] "Cannot store objects of type SYSTEM-AREA-POINTER with backend cl-store In-Reply-To: References: Message-ID: <9AA8F600-85CA-4599-A1D6-440BF9C57E1E@gmail.com> Yes, this is caused by GSLL holding pointers to data in memory which cl-store is unable to serialise. To serialise them you would have to either extend the cl-store backend to handle these marrays in a special way or convert them to matrices. Sean On 9 May 2009, at 18:41, Malcolm Reynolds wrote: > Hi > > I've been receiving this error when trying to save out a matrix of the > format used inside GSLL (GNU Scientific Library for Lisp) using > cl-store - this can be reproduced by doing the following: > > (cl-store:store (gsll:make-marray 'double-float :initial-contents '((1 > 2 3) (4 5 6) (7 8 9))) "blahblah") > => > "Cannot store objects of type SYSTEM-AREA-POINTER with backend cl- > store" > > I googled the error message but all that turned up was various copies > of the source code. > > I guess the error is due to GSLL doing something funky with it's data > structures in order to call C functions on them.. is there any way > around this problem (perhaps by using a different backend in the > optional argument to store)? If not I can just convert matrices to and > from gsll format as I load them, but it would be handy to avoid having > to do this. > > Thanks in advance, > > Malcolm > > _______________________________________________ > cl-store-devel mailing list > cl-store-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-store-devel From rosssd at gmail.com Mon May 18 14:40:40 2009 From: rosssd at gmail.com (Sean Ross) Date: Mon, 18 May 2009 15:40:40 +0100 Subject: [cl-store-devel] hash-table serialization with custom hashing functions In-Reply-To: References: Message-ID: <3D36A006-E41B-4009-B811-AD75675EBDED@gmail.com> On 21 Apr 2009, at 23:37, Chris Dean wrote: > Hi Chris, Sorry for the late reply, somehow this slipped through my net. > How should I handle hash-tables with custom hashing functions? Some > Lisps have an extension to make-hash-table to allow for a custom > hashing > function: > > (make-hash-table :test 'my-equal :hash-function 'my-hashing) > > How should we handle serialization for these objects? Right now we > write out the hash-table-test but not the hash-function. This causes > bad behaviors (or an error) on some Lisps when I restore the hash- > table. > The problem (as I see it) is that there is no standard way to get the > hash-function. Quite, although serializing the hash-function is what is really required here, > > I was about to try and convince the Clozure folks to add a > hash-table-hash-function and then send a patch to cl-store that used > that function for Clozure, when I realized what a bad idea that is. > I'd > rather be able to fix this problem once for all CL implementations. > > So what do you think? Should we add a registry of some sort so that > we > know that restoring a hash-table with a hash-table-test of X should > always use a hash-function of Y? I would be quite happy with the addition of extra information to hash table serialization provided we can come up with reasonable behaviour across the implementations which don't have a hashing function. - sean