From senatorzergling at gmail.com Tue Nov 13 06:02:42 2007 From: senatorzergling at gmail.com (szergling) Date: Tue, 13 Nov 2007 19:02:42 +1300 Subject: [cl-store-devel] ABCL tests Message-ID: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> Hi all, I'm trying to get cl-store to run on ABCL, and it required the following patches. These are for CL-STORE> (lisp-implementation-version) "0.0.9" --- /cygdrive/c/home/code/lisp/cl-store_0.7/utils.lisp 2006-08-05 02:40:02.000000000 +1200 +++ /cygdrive/c/home/temp/utils.lisp 2007-11-13 18:53:12.432977500 +1300 @@ -51,8 +51,8 @@ (:documentation "Return a list of slot details which can be used as an argument to ensure-class") - (:method ((slot-definition #+(or ecl (and clisp (not mop))) t - #-(or ecl (and clisp (not mop))) slot-definition)) + (:method ((slot-definition #+(or ecl abcl (and clisp (not mop))) t + #-(or ecl abcl (and clisp (not mop))) slot-definition)) (list :name (slot-definition-name slot-definition) :allocation (slot-definition-allocation slot-definition) :initargs (slot-definition-initargs slot-definition) Note that in ABCL, we have a good example of CL-STORE> (eq 4 4) NIL so although most of cl-store has been careful about this, were there any more slips? --- /cygdrive/c/home/code/lisp/cl-store_0.7/circularities.lisp 2006-08-05 02:40:02.000000000 +1200 +++ /cygdrive/c/home/temp/circularities.lisp 2007-11-13 18:53:30.684495900 +1300 @@ -105,7 +105,7 @@ (declare (optimize speed (safety 1) (debug 0))) (let ((*stored-counter* 0) (*stored-values* (and *check-for-circs* - (make-hash-table :test #'eq :size *store-hash-size*)))) + (make-hash-table :test #'eql :size *store-hash-size*)))) (store-backend-code backend place) (backend-store-object backend obj place) obj)) @@ -167,7 +167,7 @@ (let ((*restore-counter* 0) (*need-to-fix* nil) (*restored-values* (and *check-for-circs* - (make-hash-table :test #'eq + (make-hash-table :test #'eql :size *restore-hash-size*)))) (check-magic-number backend place) (prog1 Perhaps the test should be even more general? #'equal? At the moment, there were quite a few failed tests, and I cannot even finish large.1 so these two patches are by no means complete. I probably won't have the time to play on this, so it's semi-workable for now. This is a regexp search of the test log. Presumably all the other ones passed. 3:Test CL-STORE-TESTS::PACKAGE.1 failed 7:Test CL-STORE-TESTS::PACKAGE.2 failed 11:Test CL-STORE-TESTS::STANDARD-OBJECT.1 failed 15:Test CL-STORE-TESTS::STANDARD-OBJECT.2 failed 19:Test CL-STORE-TESTS::STANDARD-OBJECT.3 failed 23:Test CL-STORE-TESTS::STANDARD-OBJECT.4 failed 27:Test CL-STORE-TESTS::STANDARD-CLASS.1 failed 31:Test CL-STORE-TESTS::STANDARD-CLASS.2 failed 35:Test CL-STORE-TESTS::STANDARD-CLASS.3 failed 39:Test CL-STORE-TESTS::CONDITION.1 failed 43:Test CL-STORE-TESTS::CONDITION.2 failed 48:Test CL-STORE-TESTS::CIRC.5 failed 53:Test CL-STORE-TESTS::CIRC.13 failed large.1 caused evaluation to be aborted. From rosssd at gmail.com Fri Nov 16 17:30:21 2007 From: rosssd at gmail.com (Sean Ross) Date: Fri, 16 Nov 2007 17:30:21 +0000 Subject: [cl-store-devel] ABCL tests In-Reply-To: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> Message-ID: <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> Hi there, sorry for the late reply. > I'm trying to get cl-store to run on ABCL, and it required the > following patches. 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). > 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. > 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. 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..... Sean. From senatorzergling at gmail.com Sat Nov 17 13:56:12 2007 From: senatorzergling at gmail.com (szergling) Date: Sun, 18 Nov 2007 02:56:12 +1300 Subject: [cl-store-devel] ABCL tests In-Reply-To: <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> Message-ID: <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> On Nov 17, 2007 6:30 AM, Sean Ross 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)) From senatorzergling at gmail.com Tue Nov 20 01:19:43 2007 From: senatorzergling at gmail.com (szergling) Date: Tue, 20 Nov 2007 14:19:43 +1300 Subject: [cl-store-devel] ABCL tests In-Reply-To: <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> Message-ID: <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> On Nov 18, 2007 2:56 AM, szergling wrote: > On Nov 17, 2007 6:30 AM, Sean Ross wrote: [[...]] > > 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). Thousand apologies! There has been some confusion here. I have been looking at cl-store_0.7, so my patches were really outdated. Indeed, in cl-store_0.8, the #'eql test for the store/restore hash-tables has been implemented, and I begin to see #+abcl sprinkled about the code, so my patches were not required. > > > 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. It looks like a scalability issue, but aside from that, it runs correctly. CL-USER> (time (let ((list (make-list 10))) (setf (cdr (last list)) list) (cl-store:store list cl-store-tests::*test-file*) (let ((ret (cl-store:restore cl-store-tests::*test-file*))) (eq (nthcdr 10 ret) ret)))) 0.11 seconds real time 42220 cons cells T CL-USER> (time (let ((list (make-list 100))) (setf (cdr (last list)) list) (cl-store:store list cl-store-tests::*test-file*) (let ((ret (cl-store:restore cl-store-tests::*test-file*))) (eq (nthcdr 100 ret) ret)))) 0.547 seconds real time 219689 cons cells T CL-USER> (time (let ((list (make-list 1000))) (setf (cdr (last list)) list) (cl-store:store list cl-store-tests::*test-file*) (let ((ret (cl-store:restore cl-store-tests::*test-file*))) (eq (nthcdr 1000 ret) ret)))) 5.078 seconds real time 1993699 cons cells T CL-USER> (time (let ((list (make-list 10000))) (setf (cdr (last list)) list) (cl-store:store list cl-store-tests::*test-file*) (let ((ret (cl-store:restore cl-store-tests::*test-file*))) (eq (nthcdr 10000 ret) ret)))) 53.547 seconds real time 19735041 cons cells T CL-USER> As of now, most tests seem to pass, with the exception of packages, CLOS objects, conditions (they seem to be CLOS objects) and large objects. However, because I'm using ABCL 0.0.9, I had to workaround an issue with file compilation and had to load default-backend.lisp manually. This seems to be related to ABCL's (at least for my version) lack of support for compilation of certain types of closures. Cheers, and apologies again. Final issue: this looks like I got confused with yet another version of cl-store. cl-store_0.8 seems to ignore the pathname-host. > 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)) From senatorzergling at gmail.com Tue Nov 20 04:03:22 2007 From: senatorzergling at gmail.com (szergling) Date: Tue, 20 Nov 2007 17:03:22 +1300 Subject: [cl-store-devel] Closure serialisation Message-ID: <8a4b88390711192003h5b0dc37fre9f238b8b5615856@mail.gmail.com> Following on from my previous email at http://common-lisp.net/pipermail/cl-store-devel/2007-November/000077.html I hope the following might be useful so someone. > 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 Some notes on how this may be done: ;; ffi::foreign-function not done ;; Initial clisp prototype (trying to find all the relevant objects in ;; a closure, and list them) (defstore-cl-store (obj function stream) (output-type-code +function-code+ stream) (flet ((so (object) (store-object object stream))) (mapc #'so (multiple-value-list (function-lambda-expression obj))) (if (compiled-function-p obj) (flet ((es (func) ;; extract-and-store (store-object (funcall func obj) stream))) (mapc #'es (list #'sys::closure-consts #'sys::closure-codevec #'sys::closure-documentation #'sys::closure-lambda-list))) (dotimes (i 4) (so nil))))) (defrestore-cl-store (function stream) (flet ((ro () (restore-object stream))) (let ((lambda-exp (ro)) (closure-p (ro)) (name (ro)) (consts (ro)) (codevec (ro)) (doc (ro)) (lambda-list (ro))) (if codevec ;; compiled ;; TODO What is a suitable default seclass? Currently () (sys::%make-closure name codevec consts () lambda-list doc) ;; TODO Any functions to do this programmatically? How to ;; store/restore dynamic, lexical, etc environment. (eval lambda-exp) )))) ;; Other alternatives include using the custom extensions to the clisp ;; printer/reader. ;; CL-USER> (let ((custom:*print-closure* t)) (format t "~s" (lambda () 3))) ;; # NIL) ;; NIL NIL NIL ((DECLARATION OPTIMIZE DECLARATION)) #() #() 0 0 0 NIL 0 0 NIL ;; NIL NIL 0 NIL> ;; NIL ;; CL-USER> (let ((custom:*print-closure* t)) (format t "~s" (compile nil (lambda () 3)))) ;; #Y(NIL #13Y(00 00 00 00 00 00 00 00 00 01 C5 19 01) (3) NIL) ;; NIL ;; CL-USER> #Y(NIL #13Y(00 00 00 00 00 00 00 00 00 01 C5 19 01) (3) NIL) ;; # ;; CL-USER> (funcall *) ;; 3 From senatorzergling at gmail.com Tue Nov 20 04:13:45 2007 From: senatorzergling at gmail.com (szergling) Date: Tue, 20 Nov 2007 17:13:45 +1300 Subject: [cl-store-devel] Circularity bug Message-ID: <8a4b88390711192013w54e8d817k69213b2337b71633@mail.gmail.com> Hello, It seems the dump-list function (cl-store_0.8) has been written to be fast, by cdring down a list, and storing only the car. Assuming that 'circularity', like *print-circle*, actually means "check for shared structure", then I don't think the code is correct, since we have to check for seen cons cells as well as their contents. As an example, CL-USER 12 > (defparameter *temp* '(1 2 (a b . #1=(c d e)) 3 4 . #1#)) *TEMP* CL-USER 13 > (cl-store:store *temp* "c:/home/temp/delme.out") (1 2 (A B . #1=(C D E)) 3 4 . #1#) CL-USER 14 > (cl-store:restore "c:/home/temp/delme.out") (1 2 (A B C D E) 3 4 C D E) I think a user that is concerned with speed will have to either turn off circularity checking, and/or use arrays for the sort of performance dump-list is currently trying to achieve. Thank you. From senatorzergling at gmail.com Tue Nov 20 05:30:12 2007 From: senatorzergling at gmail.com (szergling) Date: Tue, 20 Nov 2007 18:30:12 +1300 Subject: [cl-store-devel] ABCL tests In-Reply-To: <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> Message-ID: <8a4b88390711192130p3815da9el17a80de71de803f3@mail.gmail.com> Hi all, These patches to the 0.8 release allow us to pass all tests with a few exceptions. These may only apply to my ABCL 0.9.9: default-backend.lisp had to be reloaded (or just re-evaluate dump-list) package.1 failed due to ABCL's buggy handling of vector-push-extend couldn't run the large tests unless the length of lists were reduced. Aside from that, I've removed redundant slot-definition-name symbol imports, and added wrappers to the ABCL clos introspection code. Cheers, please critique (abcl/custom.lisp especially). It looks like serialising of structures should be possible in ABCL. -------------- next part -------------- A non-text attachment was scrubbed... Name: custom.lisp Type: text/x-lisp-source Size: 726 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: package-diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: utils-diff.txt URL: From rosssd at gmail.com Tue Nov 20 16:44:23 2007 From: rosssd at gmail.com (Sean Ross) Date: Tue, 20 Nov 2007 16:44:23 +0000 Subject: Fwd: [cl-store-devel] ABCL tests In-Reply-To: <5bef28df0711200844x6c903cfvcbc70fdbc64645d9@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> <8a4b88390711192130p3815da9el17a80de71de803f3@mail.gmail.com> <5bef28df0711200844x6c903cfvcbc70fdbc64645d9@mail.gmail.com> Message-ID: <5bef28df0711200844n46a8808dy552302c628883508@mail.gmail.com> ---------- Forwarded message ---------- From: Sean Ross Date: Nov 20, 2007 4:44 PM Subject: Re: [cl-store-devel] ABCL tests To: szergling On 11/20/07, szergling wrote: > Hi all, > > These patches to the 0.8 release allow us to pass all tests with a few > exceptions. Thank you very much, I'll take a look at the patches and apply them shortly. Sean From rosssd at gmail.com Tue Nov 20 16:48:10 2007 From: rosssd at gmail.com (Sean Ross) Date: Tue, 20 Nov 2007 16:48:10 +0000 Subject: [cl-store-devel] Closure serialisation In-Reply-To: <8a4b88390711192003h5b0dc37fre9f238b8b5615856@mail.gmail.com> References: <8a4b88390711192003h5b0dc37fre9f238b8b5615856@mail.gmail.com> Message-ID: <5bef28df0711200848h6890b720yd7beaa3d859050ec@mail.gmail.com> On 11/20/07, szergling wrote: > Following on from my previous email at > I hope the following might be useful so someone. Very nice indeed. I don't know how anyone else feels but i quite like the idea of being able to `properly` serialize functions and am quite willing for it to be implementation specific and fail horribly (well, maybe not horribly but it definitely wont work) in other implementations. If no one complains too loudly then I'll go about getting some sort of custom function serialization for clisp added to cl-store. sean. From rosssd at gmail.com Tue Nov 20 16:48:31 2007 From: rosssd at gmail.com (Sean Ross) Date: Tue, 20 Nov 2007 16:48:31 +0000 Subject: [cl-store-devel] Circularity bug In-Reply-To: <8a4b88390711192013w54e8d817k69213b2337b71633@mail.gmail.com> References: <8a4b88390711192013w54e8d817k69213b2337b71633@mail.gmail.com> Message-ID: <5bef28df0711200848m53413d81n330e3470d6821c41@mail.gmail.com> > It seems the dump-list function (cl-store_0.8) has been written to be > fast, by cdring down a list, and storing only the car. Thanks for that, I'll take a look at it and fix the bug. Sean. From rosssd at gmail.com Tue Nov 20 17:51:55 2007 From: rosssd at gmail.com (Sean Ross) Date: Tue, 20 Nov 2007 17:51:55 +0000 Subject: [cl-store-devel] ABCL tests In-Reply-To: <8a4b88390711192130p3815da9el17a80de71de803f3@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> <8a4b88390711192130p3815da9el17a80de71de803f3@mail.gmail.com> Message-ID: <5bef28df0711200951j77c51318ja8f12e3216fc9a2d@mail.gmail.com> On 11/20/07, szergling wrote: > These patches to the 0.8 release allow us to pass all tests with a few > exceptions. > > These may only apply to my ABCL 0.9.9: 0.9.9? ABCL CVS seems to be 0.0.10.10. Are you running custom abcl patches at all? > couldn't run the large tests unless the length of lists were reduced. I have hashed large.1 and large.2 out for abcl. > Aside from that, I've removed redundant slot-definition-name symbol imports, > and added wrappers to the ABCL clos introspection code. Cheers, please > critique (abcl/custom.lisp especially). > looks fine. I had to change one thing thought, It seems like CLASS-SLOTS wasn't present in MOP in the ABCL I am using. Is it there in yours? Apart from that it is all looking great, I have 7 out of 109 tests failing (package.1 being one of them) All standard-object, condition and standard-class tests are now passing. The final failing tests for ABCL are (in no particulare order). PACKAGE.1, CIRC.2, CIRC.5, CIRC.6, CIRC.9, CIRC.12, CIRC.13. I've taken a brief look at the circularity test failuresand I suspect it is a subtle scoping bug. Wether this is an 'undefined behaviour' issue or a bug in ABCL remains to be seen but I'll try take a look at it when I get a chance. sean. From rosssd at gmail.com Tue Nov 20 17:52:37 2007 From: rosssd at gmail.com (Sean Ross) Date: Tue, 20 Nov 2007 17:52:37 +0000 Subject: [cl-store-devel] Move from CVS to darcs Message-ID: <5bef28df0711200952h7ea2537epbec1df8caa2412d9@mail.gmail.com> Hi all, I'm quite keen to move CL-STORE from CVS to darcs. Does anyone have any particular issues with this? sean. From elliottslaughter at gmail.com Tue Nov 20 17:53:15 2007 From: elliottslaughter at gmail.com (Elliott Slaughter) Date: Tue, 20 Nov 2007 09:53:15 -0800 Subject: [cl-store-devel] Closure serialisation In-Reply-To: <5bef28df0711200848h6890b720yd7beaa3d859050ec@mail.gmail.com> References: <8a4b88390711192003h5b0dc37fre9f238b8b5615856@mail.gmail.com> <5bef28df0711200848h6890b720yd7beaa3d859050ec@mail.gmail.com> Message-ID: <42c0ab790711200953n517b196dqc7eb0c56495f1837@mail.gmail.com> On Nov 20, 2007 8:48 AM, Sean Ross wrote: > I don't know how anyone else feels but i quite like the idea of being > able to `properly` serialize functions and am quite willing for it to > be implementation specific and fail horribly (well, maybe not horribly > but it definitely wont work) in other implementations. > > If no one complains too loudly then I'll go about getting some sort of > custom function serialization for clisp added to cl-store. Function serialization would be pretty cool. (And I happen to use CLISP so I wouldn't complain if it didn't work under other implementations for the time being.) -- Elliott Slaughter "Any road followed precisely to its end leads precisely nowhere." - Frank Herbert From senatorzergling at gmail.com Wed Nov 21 03:05:58 2007 From: senatorzergling at gmail.com (szergling) Date: Wed, 21 Nov 2007 16:05:58 +1300 Subject: [cl-store-devel] ABCL tests In-Reply-To: <5bef28df0711200951j77c51318ja8f12e3216fc9a2d@mail.gmail.com> References: <8a4b88390711122202j191c7723mab004a31d8bd6a98@mail.gmail.com> <5bef28df0711160930l6ad37f9cof619996c5e4e486b@mail.gmail.com> <8a4b88390711170556s5bd706bfp44b59be187c0d383@mail.gmail.com> <8a4b88390711191719t676e732m231b4a9616bb7ea4@mail.gmail.com> <8a4b88390711192130p3815da9el17a80de71de803f3@mail.gmail.com> <5bef28df0711200951j77c51318ja8f12e3216fc9a2d@mail.gmail.com> Message-ID: <8a4b88390711201905y5cb4a40oaddf9f86491c4091@mail.gmail.com> On 11/21/07, Sean Ross wrote: > On 11/20/07, szergling wrote: > > These patches to the 0.8 release allow us to pass all tests with a few > > exceptions. > > > > These may only apply to my ABCL 0.9.9: > > 0.9.9? ABCL CVS seems to be 0.0.10.10. > Are you running custom abcl patches at all? Doh! Typo: it's 0.0.9, as given in a previous email. > > > couldn't run the large tests unless the length of lists were reduced. > I have hashed large.1 and large.2 out for abcl. > > > > Aside from that, I've removed redundant slot-definition-name symbol imports, > > and added wrappers to the ABCL clos introspection code. Cheers, please > > critique (abcl/custom.lisp especially). > > > > looks fine. I had to change one thing thought, It seems like > CLASS-SLOTS wasn't present in MOP in the ABCL I am using. Is it there > in yours? Sorry can't check that at the moment... what about in the package SYSTEM? > Apart from that it is all looking great, > > I have 7 out of 109 tests failing (package.1 being one of them) > All standard-object, condition and standard-class tests are now passing. > > The final failing tests for ABCL are (in no particulare order). > PACKAGE.1, CIRC.2, CIRC.5, CIRC.6, CIRC.9, CIRC.12, CIRC.13. If I re-evaluate dump-list, or just re-load the whole file, it starts to work for me. Also, after that you can remove #-abcl from all of the circ tests which has been commented out (they run). > I've taken a brief look at the circularity test failuresand I suspect > it is a subtle scoping bug. Wether this is an 'undefined behaviour' > issue or a bug in ABCL remains to be seen but I'll try take a look at > it when I get a chance. I tend to feel it's an ABCL bug. In my ABCL, (compile x) where x is a function object doesn't work. So maybe this impacts on compile-file.