From eslick at csail.mit.edu Thu Feb 1 04:27:14 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 31 Jan 2007 23:27:14 -0500 Subject: [elephant-devel] 64-bit support Message-ID: <8D8A5FA3-FDB6-4D7A-A61E-32B83BF65C06@csail.mit.edu> With help from Henrik Hjelte, I'm implemented preliminary 64-bit support for Elephant 0.6.1 Features and notes: - 64-bit fixnums are read and written natively for 64-bit lisps - 32-bit systems can recognize and read 64-bit fixnums as bignums - 64-bit systems can read 32-bit fixnum quantities - I've slowed down array writing slightly by allowing arrays with dimensions > 2^32 - Persistent Object OIDs are still 32-bit on both platforms for efficiency reasons, this may change if 64-bit lisps become the dominant user platform There are some issues with mixing lisps at present that need fixing. - Big endian machines where 32-bit lisps read 64-bit serialized fixnums - Potential sign extension issue on 64-bit lisps reading 32-bit fixnums - I have not tested Henrik's SBCL support for reading/writing 64-bit entities - Storage efficiency hack by storing 64-bit fixnums < 2^32 in 4 bytes instead of 8 If anyone wants to give this a test drive, I'm sure there are other bugs to be discovered. I'll be adding some regression tests tomorrow to validate the 32/64 bit interoperability. Regards, Ian From eslick at csail.mit.edu Thu Feb 1 17:46:38 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 1 Feb 2007 12:46:38 -0500 Subject: [elephant-devel] osx 32bit testing In-Reply-To: <3A585F34-CEB3-4397-8E1C-82B1472C910B@onlinehome.de> References: <3A585F34-CEB3-4397-8E1C-82B1472C910B@onlinehome.de> Message-ID: <22D73FB7-6FD3-4293-90BF-C8DAF0AE1A0F@csail.mit.edu> FYI - ele-bdb will be automatically loaded when you open a store controller that requires that backend. I'll see if I can fix it so it works manually as well. On Jan 24, 2007, at 5:24 AM, Kilian Sprotte wrote: > Hi, > > I really like the new installation process!! :) > > First of all, I am attaching my-config.sexp that works for db44 > darwinports / macports :) > > With sbcl I have all bdb tests passed!!! > > For openmcl, I am attaching a diff, which allows it to pass some of > the tests. Actually, isn't the type of the spec only cons now? > > I am attaching the complete test dribble for openmcl as well. > Sorry, I am in a hurry right now - I might find a better way to > describe those type errors that appear in the the test results, or > possibly send diffs.... > > Thanks a lot for all the work > on elephant!! > > Kilian > > PS: One last issue, sorry. Wouldn't it be nice to specify > only :depends-on (:ele-bdb) in a project that builds on ele? Right > now, :elephant has to be loaded before :ele-bdb... > > > > > > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Fri Feb 2 09:05:12 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 2 Feb 2007 04:05:12 -0500 Subject: [elephant-devel] Versions in use? Message-ID: <57C46786-C111-4C91-89A5-B4D17E4CC500@csail.mit.edu> Is anyone still using Elephant version 0.5.0? The 0.6.1 release currently has no plans to support 0.5.0 users. The upgrade path would be to download 0.6.0, upgrade 0.5.0->0.6.0 and then run 0.6.0- >0.6.1 with the 0.6.1 release. It will upgrade 0.6.0 DBs to 0.6.1 via a migrate call (have to stop application, call migrate with new DB, and then restart application on new DB). Users of the Berkeley DB backend will need to have Berkeley DB 4.5 installed on their machines. Ian From lists at infoway.net Mon Feb 5 16:53:52 2007 From: lists at infoway.net (lists at infoway.net) Date: Mon, 5 Feb 2007 11:53:52 -0500 (EST) Subject: [elephant-devel] 0.6.1 / OpenMCL / BDB Message-ID: <39735.192.168.1.35.1170694432.webmail@192.168.1.35> Ian, Sorry for the delay. I've been way too busy lately. Anyway, I made another attempt after getting the latest CVS of Elephant and BDB 4.5. Elephant loaded just fine as you also experienced. I compiled BDB with CFLAGS="-arch x86_64" and LDFLAGS="-arch x86_64" in order to compile it for 64-bit. It compiled just fine and seems to run the Berkely test suite just fine. However, after several attempts and tweaks, when I try loading :ele-bdb, I keep getting stuck here: /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c: In function 'db_set_dup_compare': /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c:820: error: 'struct __db' has no member named 'set_dup_compare' /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c: In function 'db_set_lisp_compare': /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c:1129: error: 'struct __db' has no member named 'set_bt_compare' /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c:1131: error: 'struct __db' has no member named 'set_bt_compare' /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c: In function 'db_set_lisp_dup_compare': /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c:1138: error: 'struct __db' has no member named 'set_dup_compare' /Users/dev/lisp/elephant/src/db-bdb/libberkeley-db.c:1140: error: 'struct __db' has no member named 'set_dup_compare' erred while invoking # on # [Condition of type ASDF:OPERATION-ERROR] Restarts: 0: [RETRY] Retry performing # on #. 1: [ACCEPT] Continue, treating # on # as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [ABORT-BREAK] Reset this process 4: [ABORT] Kill this process Backtrace: 0: (# #) 1: (CCL::%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL # . 6095616)) 2: (CCL::%%STANDARD-COMBINED-METHOD-DCODE '(# #) #) 3: (ASDF:OPERATE 'ASDF:LOAD-OP ':ELE-BDB) 4: (CCL::CALL-CHECK-REGS 'ASDF:OOS) Any ideas? Thanks. Daniel On Wed, January 31, 2007 5:32 pm, Ian Eslick said: > I can get OpenMCL 1.1 to compile build and launch, but BDB cannot > open a newly created DB in open-store-controller. I'm wondering if > this is due to UFFI's handling of types such that we're getting 32- > bit instead of 64-bit pointers out of the underlying C API (int vs. > long)? > > The steps to getting this far are: > OpenMCL 1.1 for x86-64 > Configure and compile BDB 4.5 with -arch x86_64 > (something like: env LDFLAGS="-arch x86_64" CFLAGS="-arch x86_64" > configure from build_unix) > Latest Elephant 0.6.1 from CVS (as of 1/31/07) > > Daniel, want to take another crack at this? > > Thanks, > Ian > > On Jan 24, 2007, at 11:22 AM, lists at infoway.net wrote: > >> I have been trying to make 0.6.1 work under OpenMCL Version 1.1- >> pre-061231 (DarwinX8664). However, as I mentioned before, I have >> been having compilation problems. >> >> They seem to be mainly related to libmemutil. >> >> Out of the box attempt, I got the following error: >> >> ; $ /usr/bin/gcc -shared -Wall -fPIC -O3 -o /Users/dev/lisp/ >> elephant/src/memutil/libmemutil.so /Users/dev/lisp/elephant/src/ >> memutil/libmemutil.c -lm >> i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared' >> /usr/bin/ld: Undefined symbols: >> _main >> collect2: ld returned 1 exit status >> >> Upon inspection of elephant.asd, I made the following change: >> >> (defmethod compiler-options ((compiler (eql :gcc)) (c elephant-c- >> source) &key input-file output-file) >> "Default compile and link options to create a library; no -L or - >> I options included; math lib as default" >> (unless (and input-file output-file) >> (error "Must specify both input and output files")) >> (list >> #-(or openmcl darwin macosx) "-shared" >> #+(or openmcl darwin macosx) "-bundle" >> "-Wall" >> "-fPIC" >> "-O3" >> "-o" output-file >> input-file >> "-lm")) >> >> What I basically did is I added "openmcl" to the conditionalization >> #- and #+. After making this change, it successfully builds the >> libmemutil.so file. However, while the file actually exists, it >> fails to load with the following message: >> >> Error opening shared library "/Users/dev/lisp/elephant/src/memutil/ >> libmemutil.so": dlopen(/Users/dev/lisp/elephant/src/memutil/ >> libmemutil.so, 10): no suitable image found. Did find: >> /Users/dev/lisp/elephant/src/memutil/libmemutil.so: mach-o, but >> wrong architecture >> [Condition of type SIMPLE-ERROR] >> >> FYI, my *FEATURES* is: >> >> (:KMR-NORMAL-DSDC :KMR-NORMAL-CESD :KMR-MOP :ASDF :PRIMARY- >> CLASSES :COMMON-LISP :OPENMCL :CLOZURE :ANSI-CL :UNIX :OPENMCL- >> NATIVE-THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- >> MOP-2 :OPENMCL-PRIVATE-HASH-TABLES :OPENMCL-HASH- >> CONSING :X86-64 :X86-64 :X86-TARGET :X86-HOST :X8664-TARGET :X8664- >> HOST :DARWIN-HOST :DARWIN-TARGET :DARWINX86-TARGET :DARWINX8664- >> TARGET :DARWINX8664-HOST :POWEROPEN-TARGET :64-BIT-TARGET :64-BIT- >> HOST :LITTLE-ENDIAN-TARGET :LITTLE-ENDIAN-HOST :MCL) >> >> I don't really know why it cannot load the shared library. I don't >> know if the problem is basically a compat issue with this CVS >> version of OpenMCL in this architecture and/or UFFI. However, I >> thought I would share this just in case anyone has information that >> could speed this process or any suggestions of what I may try next. >> >> Thanks, >> Daniel >> >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel > > From henrik at evahjelte.com Mon Feb 5 18:21:13 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 05 Feb 2007 19:21:13 +0100 Subject: [elephant-devel] Testresult and patches for sbcl amd64 Message-ID: <1170699673.8265.448.camel@trinidad> Hello, here are some results when testing the bdb backend-tests on sbcl/amd64/linux. There were some problems with the serializer2 code, I have attached a patch (actually three changes) in diff -u format against cvs (but not last two changes). * install documentation, some references to bdb 4.4 changed to 4.5 * optimizations did not work when testing on 64 bit sbcl, removed for sbcl and cmu to be safe * bugfix serializing the value (expt 2 31) which was deserialized to a negative number * Bugfix: most-negative-fixnum on 64 bit Lisps was serialized as a 32 bit value Now no tests fail the first time (do-backend-tests) is run. When repeating the tests, prepares-bdb fails. I have also attached a bash script that downloads berkeley-db, installs it, and makes a default config file for Linux. Maybe someone finds it useful. Update: I saw that Ian had made a recent change for allegro, which I have made for sbcl/cmucl. You see it when you look at my patch, the ldb version should be the one for all lisps. /Henrik Hjelte -------------- next part -------------- A non-text attachment was scrubbed... Name: somechanges.diff Type: text/x-patch Size: 3246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: install-bdb.sh Type: application/x-shellscript Size: 1373 bytes Desc: not available URL: From eslick at csail.mit.edu Mon Feb 5 19:04:14 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 5 Feb 2007 14:04:14 -0500 Subject: [elephant-devel] Testresult and patches for sbcl amd64 In-Reply-To: <1170699673.8265.448.camel@trinidad> References: <1170699673.8265.448.camel@trinidad> Message-ID: Sounds like we're getting into much better shape, thank you! I'll look over and integrate these. What was the problem with %BIGNUM-REF for SBCL. It was in there originally to avoid the consing that SBCL/CMU does with ldb. Ian On Feb 5, 2007, at 1:21 PM, Henrik Hjelte wrote: > Hello, here are some results when testing the bdb backend-tests on > sbcl/amd64/linux. There were some problems with the serializer2 > code, I > have attached a patch (actually three changes) in diff -u format > against > cvs (but not last two changes). > > * install documentation, some references to bdb 4.4 changed to 4.5 > * optimizations did not work when testing on 64 bit sbcl, removed > for > sbcl and cmu to be safe > * bugfix serializing the value (expt 2 31) which was deserialized > to a > negative number > * Bugfix: most-negative-fixnum on 64 bit Lisps was serialized as > a 32 > bit value > > > Now no tests fail the first time (do-backend-tests) is run. > When repeating the tests, prepares-bdb fails. > > I have also attached a bash script that downloads berkeley-db, > installs > it, and makes a default config file for Linux. Maybe someone finds it > useful. > > Update: I saw that Ian had made a recent change for allegro, which I > have made for sbcl/cmucl. You see it when you look at my patch, the > ldb > version should be the one for all lisps. > > /Henrik Hjelte > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From henrik at evahjelte.com Mon Feb 5 19:33:05 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 05 Feb 2007 20:33:05 +0100 Subject: [elephant-devel] Testresult and patches for sbcl amd64 In-Reply-To: References: <1170699673.8265.448.camel@trinidad> Message-ID: <1170703985.8265.458.camel@trinidad> On Mon, 2007-02-05 at 14:04 -0500, Ian Eslick wrote: > Sounds like we're getting into much better shape, thank you! I'll > look over and integrate these. > > What was the problem with %BIGNUM-REF for SBCL. It was in there > originally to avoid the consing that SBCL/CMU does with ldb. I don't know what BIGNUM-REF actually is meant to do, but it returned the whole bignum it seems, or maybe it was a 64 bit integer. Anyway it was not a 32bit value, which was expected by buffer-write-uint. I did a quick check for consing, and I don't think it is a problem anymore, at least not on sbcl. /Henrik (time (dotimes (i 100000000)(dotimes (x 3) (ldb (byte 32 (* 32 x)) i)))) Evaluation took: 1.321 seconds of real time 1.256079 seconds of user run time 0.024001 seconds of system run time 0 calls to %EVAL 0 page faults and 0 bytes consed. > > Ian > > > On Feb 5, 2007, at 1:21 PM, Henrik Hjelte wrote: > > > Hello, here are some results when testing the bdb backend-tests on > > sbcl/amd64/linux. There were some problems with the serializer2 > > code, I > > have attached a patch (actually three changes) in diff -u format > > against > > cvs (but not last two changes). > > > > * install documentation, some references to bdb 4.4 changed to 4.5 > > * optimizations did not work when testing on 64 bit sbcl, removed > > for > > sbcl and cmu to be safe > > * bugfix serializing the value (expt 2 31) which was deserialized > > to a > > negative number > > * Bugfix: most-negative-fixnum on 64 bit Lisps was serialized as > > a 32 > > bit value > > > > > > Now no tests fail the first time (do-backend-tests) is run. > > When repeating the tests, prepares-bdb fails. > > > > I have also attached a bash script that downloads berkeley-db, > > installs > > it, and makes a default config file for Linux. Maybe someone finds it > > useful. > > > > Update: I saw that Ian had made a recent change for allegro, which I > > have made for sbcl/cmucl. You see it when you look at my patch, the > > ldb > > version should be the one for all lisps. > > > > /Henrik Hjelte > > > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > From eslick at csail.mit.edu Mon Feb 5 20:29:22 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 5 Feb 2007 15:29:22 -0500 Subject: [elephant-devel] Testresult and patches for sbcl amd64 In-Reply-To: <1170703985.8265.458.camel@trinidad> References: <1170699673.8265.448.camel@trinidad> <1170703985.8265.458.camel@trinidad> Message-ID: <5C5DE450-7F16-4493-B612-183F41AC1CCD@csail.mit.edu> I'll switch sbcl over to ldb. I think %bignum-ref returns values that fit in fixnums - so 64-bit quantities on 64-bit SBCL causing the problem... Here's an experiment on a 32-bit sbcl, fyi... ELE-TESTS> (type-of (sb-bignum:%bignum-ref 1000000000 1)) BIT ELE-TESTS> (type-of (sb-bignum:%bignum-ref 1000000000 2)) BIT ELE-TESTS> (type-of (sb-bignum:%bignum-ref 1000000000 3)) (INTEGER 0 536870911) ELE-TESTS> (type-of (sb-bignum:%bignum-ref 1000000000 4)) (INTEGER 0 536870911) Ian On Feb 5, 2007, at 2:33 PM, Henrik Hjelte wrote: > On Mon, 2007-02-05 at 14:04 -0500, Ian Eslick wrote: >> Sounds like we're getting into much better shape, thank you! I'll >> look over and integrate these. >> >> What was the problem with %BIGNUM-REF for SBCL. It was in there >> originally to avoid the consing that SBCL/CMU does with ldb. > I don't know what BIGNUM-REF actually is meant to do, but it returned > the whole bignum it seems, or maybe it was a 64 bit integer. Anyway it > was not a 32bit value, which was expected by buffer-write-uint. > I did a quick check for consing, and I don't think it is a problem > anymore, at least not on sbcl. > > /Henrik > > (time (dotimes (i 100000000)(dotimes (x 3) (ldb (byte 32 (* 32 x)) > i)))) > > Evaluation took: > 1.321 seconds of real time > 1.256079 seconds of user run time > 0.024001 seconds of system run time > 0 calls to %EVAL > 0 page faults and > 0 bytes consed. > > > >> >> Ian >> >> >> On Feb 5, 2007, at 1:21 PM, Henrik Hjelte wrote: >> >>> Hello, here are some results when testing the bdb backend-tests on >>> sbcl/amd64/linux. There were some problems with the serializer2 >>> code, I >>> have attached a patch (actually three changes) in diff -u format >>> against >>> cvs (but not last two changes). >>> >>> * install documentation, some references to bdb 4.4 changed to 4.5 >>> * optimizations did not work when testing on 64 bit sbcl, removed >>> for >>> sbcl and cmu to be safe >>> * bugfix serializing the value (expt 2 31) which was deserialized >>> to a >>> negative number >>> * Bugfix: most-negative-fixnum on 64 bit Lisps was serialized as >>> a 32 >>> bit value >>> >>> >>> Now no tests fail the first time (do-backend-tests) is run. >>> When repeating the tests, prepares-bdb fails. >>> >>> I have also attached a bash script that downloads berkeley-db, >>> installs >>> it, and makes a default config file for Linux. Maybe someone >>> finds it >>> useful. >>> >>> Update: I saw that Ian had made a recent change for allegro, which I >>> have made for sbcl/cmucl. You see it when you look at my patch, the >>> ldb >>> version should be the one for all lisps. >>> >>> /Henrik Hjelte >>> >>> >>> _______________________________________________ >>> elephant-devel site list >>> elephant-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/elephant-devel >> >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel >> >> > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From henrik at evahjelte.com Thu Feb 8 13:40:44 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Thu, 08 Feb 2007 14:40:44 +0100 Subject: [elephant-devel] linux-sbcl-64 report Message-ID: <1170942044.18582.77.camel@trinidad> I checked elephant latest (2007-02-07 22:54:12) cvs on sbcl 64 bit linux: I still need to do two changes I reported earlier to serializer2 to make the bignum, float and array tests work (I'm only running the BerkeleyDB backend tests) Remove the %bignum-ref code for sbcl (line 336) for two reasons, it doesn't work and it doesn't cons so it is probably unnecessary. Change line 177 to this: (if (< (abs frob) +2^31+) rather than check against 2 hat 32. This is because the last bit gives a negative number, since buffer-read-fixnum32 reads ints rather than uint. There are still some errors (see below), I haven't looked into yet. Does current cvs work on any other platform now, or are these just sbcl/linux/64 problems? Another change I needed to make, compiler options for gcc (line 112 of elephant.asd) needs to be like this for me on linux. #+(or :X86-64) "-march=x86-64" On the good side, I've finally been able to try elephant quite successfully for my app! /Henrik Hjelte Current errors -------------- Test INDEXING-WIPE-INDEX failed Form: (PROGN (WHEN (CLASS-INDEXEDP-BY-NAME 'IDX-FIVE-DEL) (DISABLE-CLASS-INDEXING 'IDX-FIVE-DEL :ERRORP NIL) (SETF (FIND-CLASS 'IDX-FIVE-DEL) NIL)) (DEFCLASS IDX-FIVE-DEL NIL ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR SLOT1 :INDEX T)) (:METACLASS PERSISTENT-METACLASS)) (WITH-TRANSACTION (:STORE-CONTROLLER *STORE-CONTROLLER*) (MAKE-INSTANCE 'IDX-FIVE-DEL)) (LET ((R1 (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1))) (DEFCLASS IDX-FIVE-DEL NIL ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR SLOT1)) (:METACLASS PERSISTENT-METACLASS)) (FORMAT T "r1 = ~A~%" R1) (FORMAT T "r1 = ~A~%" (GET-INDEX (GET-VALUE 'IDX-FIVE-DEL (CONTROLLER-CLASS-ROOT *STORE-CONTROLLER*)) 'SLOT1)) (VALUES (EQ (LENGTH R1) 1) (SIGNALS-ERROR (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1)) (NULL (GET-INDEX (GET-VALUE 'IDX-FIVE-DEL (CONTROLLER-CLASS-ROOT *STORE-CONTROLLER*)) 'SLOT1))))) Expected values: T T T Actual values: NIL T NIL. Test PREPARES-BDB failed Form: (PROGN (SETQ DB NIL) (IF (AND (FIND-PACKAGE :DB-BDB) (EQ (FIRST (ELEPHANT::CONTROLLER-SPEC *STORE-CONTROLLER*)) :BDB)) (FINISHES (PREPARE-BDB)) (PROGN (FORMAT T "Berkeley DB not loaded, so not runnning test prepares-bdb~%") T))) Expected value: T Actual value: NIL. Berkeley db not loaded, so not runnning test test-seq1 TEST-SEQ1BDB db not valid, so not runnning test test-seq2 TEST-SEQ2Berkeley DB not open, so not runnning test cleanup-bdb CLEANSUP-BDB 2 out of 119 total tests failed: INDEXING-WIPE-INDEX, PREPARES-BDB. ------------------------------------------------------------------------------- Errors BEFORE my patches: Test BIGNUMS failed Form: (ARE-NOT-NULL (IN-OUT-EQUAL (+ MOST-POSITIVE-FIXNUM 100)) (IN-OUT-EQUAL (- MOST-NEGATIVE-FIXNUM 100)) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (EXPT 2 I))) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (- (EXPT 2 I)))) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (- (EXPT 2 I) 1))) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (- 1 (EXPT 2 I)))) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (EXPT 3 I))) (LOOP FOR I FROM 0 TO 2000 ALWAYS (IN-OUT-EQUAL (- (EXPT 3 I))))) Expected values: T T T T T T T T Actual value: #. FLOATS Test RATIONALS failed Form: (ARE-NOT-NULL (IN-OUT-EQUAL 1/2) (IN-OUT-EQUAL -1/2) (IN-OUT-EQUAL (/ 1 MOST-POSITIVE-FIXNUM)) (IN-OUT-EQUAL (/ 1 MOST-NEGATIVE-FIXNUM)) (IN-OUT-EQUAL (/ MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM)) (IN-OUT-EQUAL (/ (EXPT 2 200) (EXPT 3 300))) (IN-OUT-EQUAL (/ (EXPT 2 200) (- (EXPT 3 300))))) Expected values: T T T T T T T Actual value: #. BASE-STRINGS STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 Test ARRAYS-2 failed Form: (LET ((ARR (MAKE-ARRAY '(3 4 5))) (VEC (MAKE-ARRAY 100 :ADJUSTABLE T :FILL-POINTER T)) (SVEC (MAKE-ARRAY 100 :ADJUSTABLE NIL :FILL-POINTER NIL))) (SETF (AREF ARR 0 0 0) 'SYMB) (SETF (AREF ARR 1 2 3) 123132) (SETF (AREF ARR 2 3 4) "this is a longish string") (VECTOR-PUSH-EXTEND 123456789101112 VEC) (VECTOR-PUSH-EXTEND "mr t" VEC) (VECTOR-PUSH-EXTEND 'SYMBOLIC VEC) (LOOP FOR I FROM 0 TO 99 DO (SETF (SVREF SVEC I) (EXPT 2 I))) (ARE-NOT-NULL (IN-OUT-EQUALP ARR) (IN-OUT-EQUALP VEC) (IN-OUT-EQUALP SVEC) (TYPEP (IN-OUT-VALUE SVEC) 'SIMPLE-VECTOR))) Expected values: T T T T Actual value: #. From eslick at csail.mit.edu Thu Feb 8 15:06:49 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 8 Feb 2007 10:06:49 -0500 Subject: [elephant-devel] linux-sbcl-64 report In-Reply-To: <1170942044.18582.77.camel@trinidad> References: <1170942044.18582.77.camel@trinidad> Message-ID: <524776E5-FDE5-4347-8A96-DDF8F99984FB@csail.mit.edu> I did make your changes, did you not see them in the latest version? I'll double check later today, thanks! Ian On Feb 8, 2007, at 8:40 AM, Henrik Hjelte wrote: > I checked elephant latest (2007-02-07 22:54:12) cvs on sbcl 64 bit > linux: I still need to do two changes I reported earlier to > serializer2 > to make the bignum, float and array tests work (I'm only running the > BerkeleyDB backend tests) > > Remove the %bignum-ref code for sbcl (line 336) for two reasons, it > doesn't work and it doesn't cons so it is probably unnecessary. > > Change line 177 to this: (if (< (abs frob) +2^31+) rather than check > against 2 hat 32. This is because the last bit gives a negative > number, > since buffer-read-fixnum32 reads ints rather than uint. > > There are still some errors (see below), I haven't looked into yet. > Does > current cvs work on any other platform now, or are these just > sbcl/linux/64 problems? > > Another change I needed to make, compiler options for gcc (line 112 of > elephant.asd) needs to be like this for me on linux. > #+(or :X86-64) "-march=x86-64" > > On the good side, I've finally been able to try elephant quite > successfully for my app! > > /Henrik Hjelte > > > Current errors > -------------- > > Test INDEXING-WIPE-INDEX failed > Form: (PROGN > (WHEN (CLASS-INDEXEDP-BY-NAME 'IDX-FIVE-DEL) > (DISABLE-CLASS-INDEXING 'IDX-FIVE-DEL :ERRORP NIL) > (SETF (FIND-CLASS 'IDX-FIVE-DEL) NIL)) > (DEFCLASS IDX-FIVE-DEL NIL > ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR SLOT1 > :INDEX T)) > (:METACLASS PERSISTENT-METACLASS)) > (WITH-TRANSACTION (:STORE-CONTROLLER *STORE-CONTROLLER*) > (MAKE-INSTANCE 'IDX-FIVE-DEL)) > (LET ((R1 (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1))) > (DEFCLASS IDX-FIVE-DEL NIL > ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR > SLOT1)) > (:METACLASS PERSISTENT-METACLASS)) > (FORMAT T "r1 = ~A~%" R1) > (FORMAT T "r1 = ~A~%" > (GET-INDEX > (GET-VALUE 'IDX-FIVE-DEL > (CONTROLLER-CLASS-ROOT *STORE- > CONTROLLER*)) > 'SLOT1)) > (VALUES (EQ (LENGTH R1) 1) > (SIGNALS-ERROR > (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1)) > (NULL > (GET-INDEX > (GET-VALUE 'IDX-FIVE-DEL > (CONTROLLER-CLASS-ROOT > *STORE-CONTROLLER*)) > 'SLOT1))))) > Expected values: T > T > T > Actual values: NIL > T > NIL. > > Test PREPARES-BDB failed > Form: (PROGN > (SETQ DB NIL) > (IF > (AND (FIND-PACKAGE :DB-BDB) > (EQ (FIRST (ELEPHANT::CONTROLLER-SPEC *STORE- > CONTROLLER*)) > :BDB)) > (FINISHES (PREPARE-BDB)) > (PROGN > (FORMAT T > "Berkeley DB not loaded, so not runnning test > prepares-bdb~%") > T))) > Expected value: T > Actual value: NIL. > Berkeley db not loaded, so not runnning test test-seq1 > TEST-SEQ1BDB db not valid, so not runnning test test-seq2 > TEST-SEQ2Berkeley DB not open, so not runnning test cleanup-bdb > CLEANSUP-BDB > 2 out of 119 total tests failed: INDEXING-WIPE-INDEX, PREPARES-BDB. > > > > ---------------------------------------------------------------------- > --------- > Errors BEFORE my patches: > > Test BIGNUMS failed > Form: (ARE-NOT-NULL (IN-OUT-EQUAL (+ MOST-POSITIVE-FIXNUM 100)) > (IN-OUT-EQUAL (- MOST-NEGATIVE-FIXNUM 100)) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (EXPT 2 I))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 2 I)))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 2 I) 1))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- 1 (EXPT 2 I)))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (EXPT 3 I))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 3 I))))) > Expected values: T > T > T > T > T > T > T > T > Actual value: #. > FLOATS > Test RATIONALS failed > Form: (ARE-NOT-NULL (IN-OUT-EQUAL 1/2) (IN-OUT-EQUAL -1/2) > (IN-OUT-EQUAL (/ 1 MOST-POSITIVE-FIXNUM)) > (IN-OUT-EQUAL (/ 1 MOST-NEGATIVE-FIXNUM)) > (IN-OUT-EQUAL > (/ MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM)) > (IN-OUT-EQUAL (/ (EXPT 2 200) (EXPT 3 300))) > (IN-OUT-EQUAL (/ (EXPT 2 200) (- (EXPT 3 300))))) > Expected values: T > T > T > T > T > T > T > Actual value: #. > BASE-STRINGS STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 > HASH-TABLES-2 ARRAYS-1 > Test ARRAYS-2 failed > Form: (LET ((ARR (MAKE-ARRAY '(3 4 5))) > (VEC (MAKE-ARRAY 100 :ADJUSTABLE T :FILL-POINTER T)) > (SVEC (MAKE-ARRAY 100 :ADJUSTABLE NIL :FILL-POINTER NIL))) > (SETF (AREF ARR 0 0 0) 'SYMB) > (SETF (AREF ARR 1 2 3) 123132) > (SETF (AREF ARR 2 3 4) "this is a longish string") > (VECTOR-PUSH-EXTEND 123456789101112 VEC) > (VECTOR-PUSH-EXTEND "mr t" VEC) > (VECTOR-PUSH-EXTEND 'SYMBOLIC VEC) > (LOOP FOR I FROM 0 TO 99 DO (SETF (SVREF SVEC I) (EXPT 2 I))) > (ARE-NOT-NULL (IN-OUT-EQUALP ARR) (IN-OUT-EQUALP VEC) > (IN-OUT-EQUALP SVEC) > (TYPEP (IN-OUT-VALUE SVEC) 'SIMPLE-VECTOR))) > Expected values: T > T > T > T > Actual value: #. > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From henrik at evahjelte.com Thu Feb 8 15:42:05 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Thu, 08 Feb 2007 16:42:05 +0100 Subject: [elephant-devel] linux-sbcl-64 report In-Reply-To: <524776E5-FDE5-4347-8A96-DDF8F99984FB@csail.mit.edu> References: <1170942044.18582.77.camel@trinidad> <524776E5-FDE5-4347-8A96-DDF8F99984FB@csail.mit.edu> Message-ID: <1170949325.18582.79.camel@trinidad> On Thu, 2007-02-08 at 10:06 -0500, Ian Eslick wrote: > I did make your changes, did you not see them in the latest version? No, I just checked with a fresh download from cvs. /Henrik From eslick at csail.mit.edu Thu Feb 8 15:55:09 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 8 Feb 2007 10:55:09 -0500 Subject: [elephant-devel] linux-sbcl-64 report In-Reply-To: <1170942044.18582.77.camel@trinidad> References: <1170942044.18582.77.camel@trinidad> Message-ID: <5260A452-9981-4070-AA40-90700E5088D4@csail.mit.edu> Ok, for some reason that %bignum fix didn't make it in. I just checked that in. I'm checking in your abs with 2 hat 31 fix now. The indexing-wipe-index is an SBCL related problem (everything passes on 32-bit allegro with my current working copy). The PREPARES-DB failure is due to not running ./delscript.sh in the tests directory prior to running tests (tests are not idempotent). We're getting close to a clean alpha, but we're not quite there yet. I'm resolving some complex 0.6.0 to 0.6.1 upgrade issues (being able to read databases from both versions concurrently) at present. I'll make sure SBCL 32-bit is clean before I ask the list for some stress testing of the new release candidate. Thanks, Ian On Feb 8, 2007, at 8:40 AM, Henrik Hjelte wrote: > I checked elephant latest (2007-02-07 22:54:12) cvs on sbcl 64 bit > linux: I still need to do two changes I reported earlier to > serializer2 > to make the bignum, float and array tests work (I'm only running the > BerkeleyDB backend tests) > > Remove the %bignum-ref code for sbcl (line 336) for two reasons, it > doesn't work and it doesn't cons so it is probably unnecessary. > > Change line 177 to this: (if (< (abs frob) +2^31+) rather than check > against 2 hat 32. This is because the last bit gives a negative > number, > since buffer-read-fixnum32 reads ints rather than uint. > > There are still some errors (see below), I haven't looked into yet. > Does > current cvs work on any other platform now, or are these just > sbcl/linux/64 problems? > > Another change I needed to make, compiler options for gcc (line 112 of > elephant.asd) needs to be like this for me on linux. > #+(or :X86-64) "-march=x86-64" > > On the good side, I've finally been able to try elephant quite > successfully for my app! > > /Henrik Hjelte > > > Current errors > -------------- > > Test INDEXING-WIPE-INDEX failed > Form: (PROGN > (WHEN (CLASS-INDEXEDP-BY-NAME 'IDX-FIVE-DEL) > (DISABLE-CLASS-INDEXING 'IDX-FIVE-DEL :ERRORP NIL) > (SETF (FIND-CLASS 'IDX-FIVE-DEL) NIL)) > (DEFCLASS IDX-FIVE-DEL NIL > ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR SLOT1 > :INDEX T)) > (:METACLASS PERSISTENT-METACLASS)) > (WITH-TRANSACTION (:STORE-CONTROLLER *STORE-CONTROLLER*) > (MAKE-INSTANCE 'IDX-FIVE-DEL)) > (LET ((R1 (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1))) > (DEFCLASS IDX-FIVE-DEL NIL > ((SLOT1 :INITARG :SLOT1 :INITFORM 1 :ACCESSOR > SLOT1)) > (:METACLASS PERSISTENT-METACLASS)) > (FORMAT T "r1 = ~A~%" R1) > (FORMAT T "r1 = ~A~%" > (GET-INDEX > (GET-VALUE 'IDX-FIVE-DEL > (CONTROLLER-CLASS-ROOT *STORE- > CONTROLLER*)) > 'SLOT1)) > (VALUES (EQ (LENGTH R1) 1) > (SIGNALS-ERROR > (GET-INSTANCES-BY-VALUE 'IDX-FIVE-DEL 'SLOT1 1)) > (NULL > (GET-INDEX > (GET-VALUE 'IDX-FIVE-DEL > (CONTROLLER-CLASS-ROOT > *STORE-CONTROLLER*)) > 'SLOT1))))) > Expected values: T > T > T > Actual values: NIL > T > NIL. > > Test PREPARES-BDB failed > Form: (PROGN > (SETQ DB NIL) > (IF > (AND (FIND-PACKAGE :DB-BDB) > (EQ (FIRST (ELEPHANT::CONTROLLER-SPEC *STORE- > CONTROLLER*)) > :BDB)) > (FINISHES (PREPARE-BDB)) > (PROGN > (FORMAT T > "Berkeley DB not loaded, so not runnning test > prepares-bdb~%") > T))) > Expected value: T > Actual value: NIL. > Berkeley db not loaded, so not runnning test test-seq1 > TEST-SEQ1BDB db not valid, so not runnning test test-seq2 > TEST-SEQ2Berkeley DB not open, so not runnning test cleanup-bdb > CLEANSUP-BDB > 2 out of 119 total tests failed: INDEXING-WIPE-INDEX, PREPARES-BDB. > > > > ---------------------------------------------------------------------- > --------- > Errors BEFORE my patches: > > Test BIGNUMS failed > Form: (ARE-NOT-NULL (IN-OUT-EQUAL (+ MOST-POSITIVE-FIXNUM 100)) > (IN-OUT-EQUAL (- MOST-NEGATIVE-FIXNUM 100)) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (EXPT 2 I))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 2 I)))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 2 I) 1))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- 1 (EXPT 2 I)))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (EXPT 3 I))) > (LOOP FOR I FROM 0 TO 2000 ALWAYS > (IN-OUT-EQUAL (- (EXPT 3 I))))) > Expected values: T > T > T > T > T > T > T > T > Actual value: #. > FLOATS > Test RATIONALS failed > Form: (ARE-NOT-NULL (IN-OUT-EQUAL 1/2) (IN-OUT-EQUAL -1/2) > (IN-OUT-EQUAL (/ 1 MOST-POSITIVE-FIXNUM)) > (IN-OUT-EQUAL (/ 1 MOST-NEGATIVE-FIXNUM)) > (IN-OUT-EQUAL > (/ MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM)) > (IN-OUT-EQUAL (/ (EXPT 2 200) (EXPT 3 300))) > (IN-OUT-EQUAL (/ (EXPT 2 200) (- (EXPT 3 300))))) > Expected values: T > T > T > T > T > T > T > Actual value: #. > BASE-STRINGS STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 > HASH-TABLES-2 ARRAYS-1 > Test ARRAYS-2 failed > Form: (LET ((ARR (MAKE-ARRAY '(3 4 5))) > (VEC (MAKE-ARRAY 100 :ADJUSTABLE T :FILL-POINTER T)) > (SVEC (MAKE-ARRAY 100 :ADJUSTABLE NIL :FILL-POINTER NIL))) > (SETF (AREF ARR 0 0 0) 'SYMB) > (SETF (AREF ARR 1 2 3) 123132) > (SETF (AREF ARR 2 3 4) "this is a longish string") > (VECTOR-PUSH-EXTEND 123456789101112 VEC) > (VECTOR-PUSH-EXTEND "mr t" VEC) > (VECTOR-PUSH-EXTEND 'SYMBOLIC VEC) > (LOOP FOR I FROM 0 TO 99 DO (SETF (SVREF SVEC I) (EXPT 2 I))) > (ARE-NOT-NULL (IN-OUT-EQUALP ARR) (IN-OUT-EQUALP VEC) > (IN-OUT-EQUALP SVEC) > (TYPEP (IN-OUT-VALUE SVEC) 'SIMPLE-VECTOR))) > Expected values: T > T > T > T > Actual value: #. > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From henrik at evahjelte.com Mon Feb 12 17:55:00 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 12 Feb 2007 18:55:00 +0100 Subject: [elephant-devel] linux-sbcl-64 report Message-ID: <1171302900.18582.228.camel@trinidad> Minor problems on 64 bit sbcl/linux . serializer2 line 174: (if (< (abs frob) +2^32+) should be (if (< (abs frob) +2^31+) :module utils in elephant.asd should have a serial :t otherwise lock may be compiled before package. A reminder about compiler switches, -arch x86_64 I think is apple specific, I have #+(or :X86-64) "-march=x86-64" on linux. Maybe a compromise is "-m64" ? http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options A bigger problem: I get out-of-memory errors after running elephant a while. I *think* (I am by no means an expert with these things) this can mean anything, not only out-of-memory. (Because of a low default error-message level) What I strongly suspect is that I run out of locks. Doing dbstat-e reveals: 999 Number of current locks 1000 Maximum number of locks at any one time 13 Number of current lockers 17 Maximum number of lockers at any one time 996 Number of current lock objects 997 Maximum number of lock objects at any one time When I am thrown to the debugger. When quiting the debugger: 0 Number of current locks 1000 Maximum number of locks at any one time I am running the deadlock detector in a shell process: db_deadlock -t 3 Oracle writes about this as point six in the common problems section: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/debug/common.html I have tried to use with-locks surrounding the get and put calls in persistent-slot-reader and writer, but it didn't help anything. Any ideas? Has no one else seen this? Have I missed something obvious? Best wishes, Henrik Hjelte From eslick at csail.mit.edu Mon Feb 12 20:10:57 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 12 Feb 2007 15:10:57 -0500 Subject: [elephant-devel] linux-sbcl-64 report In-Reply-To: <1171302900.18582.228.camel@trinidad> References: <1171302900.18582.228.camel@trinidad> Message-ID: I hope you aren't relying on the current HEAD for anything important! As you can tell we're not quite there yet! There could be several issues. I assume you are using the with- transaction macro around your transactions? (Or are you relying on auto-commit?) Are you using cursors yourself or functions like get- instances-by-value that themselves use cursors manually? I recently made some changes to several of these functions so it could be any of them. If I have some sense of what you're doing I can go inspect the changes for holes. I should also be able to reproduce this locally if it's an elephant function rather than an issue with usage. Thanks! Ian On Feb 12, 2007, at 12:55 PM, Henrik Hjelte wrote: > Minor problems on 64 bit sbcl/linux > . > serializer2 line 174: > (if (< (abs frob) +2^32+) > should be > (if (< (abs frob) +2^31+) Fixed > :module utils in elephant.asd should have a serial :t otherwise > lock may > be compiled before package. Fixed > A reminder about compiler switches, > -arch x86_64 I think is apple specific, > I have > #+(or :X86-64) "-march=x86-64" > on linux. > Maybe a compromise is > "-m64" ? > > http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64- > Options.html#i386-and-x86_002d64-Options Hmmm...I think I'll add conditionals on a per-lisp, per-platform basis as the *feature* lists are all very different. Check out the latest checkin in elephant.asd > > A bigger problem: I get out-of-memory errors after running elephant a > while. I *think* (I am by no means an expert with these things) > this can > mean anything, not only out-of-memory. (Because of a low default > error-message level) > > What I strongly suspect is that I run out of locks. > Doing dbstat-e reveals: > 999 Number of current locks > 1000 Maximum number of locks at any one time > 13 Number of current lockers > 17 Maximum number of lockers at any one time > 996 Number of current lock objects > 997 Maximum number of lock objects at any one time > When I am thrown to the debugger. > > When quiting the debugger: > 0 Number of current locks > 1000 Maximum number of locks at any one time > > I am running the deadlock detector in a shell process: db_deadlock - > t 3 > > Oracle writes about this as point six in the common problems section: > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/ > debug/common.html > > I have tried to use with-locks surrounding the get and put calls in > persistent-slot-reader and writer, but it didn't help anything. That shouldn't have an effect (where did you get with-locks anyway? Is that an elephant internal function or a threading function?) > Any ideas? Has no one else seen this? Have I missed something obvious? I haven't seen this on earlier versions, and I used Elephant 0.6.0 very heavily so it must be an artifact that was recently introduced. > Best wishes, > Henrik Hjelte > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From henrik at evahjelte.com Mon Feb 12 21:30:46 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 12 Feb 2007 22:30:46 +0100 Subject: [elephant-devel] linux-sbcl-64 report In-Reply-To: References: <1171302900.18582.228.camel@trinidad> Message-ID: <1171315846.18582.264.camel@trinidad> On Mon, 2007-02-12 at 15:10 -0500, Ian Eslick wrote: > I hope you aren't relying on the current HEAD for anything > important! Well no, I was hoping to use it but I'm affraid I don't trust it yet... > As you can tell we're not quite there yet! > > There could be several issues. I assume you are using the with- > transaction macro around your transactions? (Or are you relying on > auto-commit?) Are you using cursors yourself or functions like get- > instances-by-value that themselves use cursors manually? > > I recently made some changes to several of these functions so it > could be any of them. If I have some sense of what you're doing I > can go inspect the changes for holes. I should also be able to > reproduce this locally if it's an elephant function rather than an > issue with usage. > > Thanks! > Ian > Actually, I have just released this test as a project called grand-prix, a black-box test framework to compare persistence solutions. The idea was to save some of my test code instead of throwing it away, maybe It can grow to be something useful. http://common-lisp.net/project/grand-prix/ darcs get http://common-lisp.net/project/grand-prix/darcs/grand-prix grand-prix can probably be a little messy to set up, the actual elephant code is below, you can probably just paste it into a buffer and run it. I first run (my-test-create), which works Then (my-test-update) which show the problem. elephant works with *nr-person* set to 2000. Thanks, Henrik Hjelte (defparameter *spec* '(:bdb "/tmp/elephant-test-suite-mp")) (defparameter *names* '("David" "Jim" "Peter" "Thomas" "Arthur" "Jans" "Klaus" "James" "Martin")) (defclass person () ((name :initform (elt *names* (random (length *names*))) :accessor name :index t) ;; Actually the index t shouldn't be needed, but since elephant sometimes complained that "person is not an index class", I try if this fixes it. (age :initform (random 100) :accessor age) (made-by :initform (grand-prix::current-process-id)) (updated-by :initform nil :accessor updated-by)) (:metaclass elephant:persistent-metaclass)) (defparameter *nr-persons* 10000) ;; Should be 10000, but for me elephant can't allocate memory after 3000. ;; I think the problem it is becuase the number of locks (999) is = max 1000. see db_stat -e (defparameter +age+ 50) ;; I have tried different places for with-transaction below (defun make-persons (nr-objects) (loop for i below nr-objects do (let ((person (elephant:with-transaction () (make-instance 'person)))) (when (zerop (mod i 1000)) (format t "~D ~a" i (name person))) ))) (defun ensure-clean-store () (let ((dir (cl-fad:pathname-as-directory (second *spec*)))) (when (cl-fad:directory-exists-p dir) (cl-fad:delete-directory-and-files dir)) (ensure-directories-exist dir))) (defun my-test-create () (ensure-clean-store) (elephant:with-open-store (*spec*) (make-persons *nr-persons*))) (defun my-test-update (&key (new-age 27)) "Test updating all persons by changing their age." (elephant:with-open-store (*spec*) (elephant:with-transaction () (mapcar #'(lambda (person) (setf (age person) new-age)) (elephant:get-instances-by-class 'person))))) (defun my-test-load () "Test loading all persons by computing their average age." (let ((nr-persons 0) (total-age 0) (show-first nil)) (elephant:with-open-store (*spec*) (elephant:with-transaction () (mapcar #'(lambda (person) (incf nr-persons) (print nr-persons) (when (and show-first (> show-first)) (format t "Sample person ~a~%F" show-first) (describe person) (decf show-first)) (incf total-age (age person))) (elephant:get-instances-by-class 'person)))) (values (coerce (/ total-age nr-persons) 'float) nr-persons total-age))) (defun check-basic-setup () (my-test-update :new-age +age+) (multiple-value-bind (average nr-persons) (my-test-load) (assert (= +age+ average)) (assert (= nr-persons *nr-persons*)))) > On Feb 12, 2007, at 12:55 PM, Henrik Hjelte wrote: > > > Minor problems on 64 bit sbcl/linux > > . > > serializer2 line 174: > > (if (< (abs frob) +2^32+) > > should be > > (if (< (abs frob) +2^31+) > > Fixed > > > :module utils in elephant.asd should have a serial :t otherwise > > lock may > > be compiled before package. > > Fixed > > > A reminder about compiler switches, > > -arch x86_64 I think is apple specific, > > I have > > #+(or :X86-64) "-march=x86-64" > > on linux. > > Maybe a compromise is > > "-m64" ? > > > > http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64- > > Options.html#i386-and-x86_002d64-Options > > Hmmm...I think I'll add conditionals on a per-lisp, per-platform > basis as the *feature* lists are all very different. Check out the > latest checkin in elephant.asd > > > > > A bigger problem: I get out-of-memory errors after running elephant a > > while. I *think* (I am by no means an expert with these things) > > this can > > mean anything, not only out-of-memory. (Because of a low default > > error-message level) > > > > What I strongly suspect is that I run out of locks. > > Doing dbstat-e reveals: > > 999 Number of current locks > > 1000 Maximum number of locks at any one time > > 13 Number of current lockers > > 17 Maximum number of lockers at any one time > > 996 Number of current lock objects > > 997 Maximum number of lock objects at any one time > > When I am thrown to the debugger. > > > > When quiting the debugger: > > 0 Number of current locks > > 1000 Maximum number of locks at any one time > > > > I am running the deadlock detector in a shell process: db_deadlock - > > t 3 > > > > Oracle writes about this as point six in the common problems section: > > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/ > > debug/common.html > > > > I have tried to use with-locks surrounding the get and put calls in > > persistent-slot-reader and writer, but it didn't help anything. > > That shouldn't have an effect (where did you get with-locks anyway? > Is that an elephant internal function or a threading function?) > > > Any ideas? Has no one else seen this? Have I missed something obvious? > > I haven't seen this on earlier versions, and I used Elephant 0.6.0 > very heavily so it must be an artifact that was recently introduced. > > > Best wishes, > > Henrik Hjelte > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > From eslick at csail.mit.edu Tue Feb 13 22:57:18 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Tue, 13 Feb 2007 17:57:18 -0500 Subject: [elephant-devel] Design issue: sorting secondary cursor values Message-ID: <0621A306-AA77-4E5D-813A-8EB64A24E5C4@csail.mit.edu> Robert and I have been discussing whether we will support sorting of duplicate values when traversing secondary indices. For release 0.6.1 we will not guarantee any particular sorting order for duplicate values. Doing so makes no sense for get-instances-by-range, for example: class1/instance1: slot1 = 2 slot2 = 1 class1/instance2: slot1 = 2 slot2 = 2 class1/instance3: slot1 = 1 slot2 = 3 class1/instance4: slot1 = 1 slot2 = 4 If you declare a secondary index on slot1 (:index t in class definition) you would get the following possible lists for the query: (get-instances-by-range 'class1 'slot1 1 2) class1/instance3: slot1 = 1 slot2 = 3 class1/instance4: slot1 = 1 slot2 = 4 class1/instance1: slot1 = 2 slot2 = 1 class1/instance2: slot1 = 2 slot2 = 2 class1/instance4: slot1 = 1 slot2 = 4 class1/instance3: slot1 = 1 slot2 = 3 class1/instance2: slot1 = 2 slot2 = 2 class1/instance1: slot1 = 2 slot2 = 1 and so on. Results are partially ordered by slot1 value, but not by slot2 value or instance creation order, etc. Duplicate sorting might make sense for your own indexed-btrees where duplicate sets are sorted by the primary key order of the main index. We may look at this for future releases, but only if there is a compelling application (such as optimizing object queries). Cheers, Ian From gorbatovsky at gmail.com Wed Feb 14 13:45:59 2007 From: gorbatovsky at gmail.com (Dmitry V. Gorbatovsky) Date: Wed, 14 Feb 2007 15:45:59 +0200 Subject: [elephant-devel] 'not of type FIXNUM' type-error Message-ID: <200702141545.59988.dg@midasitech.com> Hello , here is debian testing with sbcl 1.02 and cvs version of elephant. Intel 32-bit machine with 1gb of ram. The code I am try to run is pretty straitforward, it runs with 2000x2000 array, but returns type-error with anything bigger. (let ((big-array (make-array '(5000 5000) :element-type 'float :initial-element 0.0))) (time (ele:with-open-store (*test-bdb-spec*) (ele:add-to-root 'big-array big-array)))) And here is output from the debugger: The value 1000000640 is not of type FIXNUM. [Condition of type TYPE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM #) Locals: 1: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) #) Locals: 2: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) #) Locals: 3: (ELEPHANT-SERIALIZER2::SERIALIZE #) Locals: 4: ((SB-PCL::FAST-METHOD (SETF GET-VALUE) (T T DB-BDB::BDB-BTREE)) #) Locals: 5: ((LAMBDA NIL)) Locals: 6: (SB-IMPL::%TIME #) Locals: SB-DEBUG::ARG-0 = # 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((BIG-ARRAY #)) (TIME (WITH-OPEN-STORE # #))) #) Locals: SB-DEBUG::ARG-0 = (LET ((BIG-ARRAY (MAKE-ARRAY # :ELEMENT-TYPE # :INITIAL-ELEMENT 0.0))) (TIME (WITH-OPEN-STORE (*TEST-BDB-SPEC*) (ADD-TO-ROOT # BIG-ARRAY)))) SB-DEBUG::ARG-1 = # 8: ((LAMBDA NIL)) Locals: 9: ((LAMBDA (SWANK-BACKEND::FN)) #) I would highly appreciate any help. Regards, Dmitry -- Dmitry V. Gorbatovsky From eslick at csail.mit.edu Wed Feb 14 16:05:57 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 14 Feb 2007 11:05:57 -0500 Subject: [elephant-devel] 'not of type FIXNUM' type-error In-Reply-To: <200702141545.59988.dg@midasitech.com> References: <200702141545.59988.dg@midasitech.com> Message-ID: <44BE457A-37A9-43D7-9DA4-0FEBE0975952@csail.mit.edu> Geesh...I chased this down to a design decision inside the SBCL sb- alien implementation as I couldn't reproduce this on Allegro. One design decision in Elephant was to serialize all lisp values to a foreign byte array so they can be directly submitted to the Berkeley DB internal pages as a single foreign byte array (required by BDB API). As values are serialized, the foreign array is resized to accommodate longer and longer values so the total serialized size of your object has to not violate any of the various fixnum related limits in the system. It turns out that SBCL has an internal limitation that it computes foreign array sizes by first computing the # of bits. Thus when you try to allocate a buffer of 80M bytes, it becomes 640M bytes which is greater than the SBCL positive fixnum limit of ~512MB (30-bit signed). Perhaps SBCL 64 doesn't have this same limitation, but when you allocate extremely large objects you'll eventually run into these kinds of limitations. Elephant itself is currently limited to 2 billion objects (indexes and persistent indexes) but there is no fixed limit on # of values other than the ultimate depth of the btree which will exhaust your locks on a write. If you chose to store large arrays in a special index by row you should have no problem: ;; psuedo code - you should get the idea (defun store-large-array (array index) (setf (get-value 'columns index) (num-array-columns array)) (setf (get-value 'rows index) (num-array-rows array)) (loop for i from 0 upto (num-array-rows array) do (setf (get-value i index) (array-row array i)))) (defun load-large-array (index) (let* ((columns (get-value 'columns index)) (rows (get-value 'rows index)) (array (make-array (list rows columns)))) (loop for i from 0 upto rows do (write-row (get-value i index) array)))) Cheers, Ian On Feb 14, 2007, at 8:45 AM, Dmitry V. Gorbatovsky wrote: > Hello , here is debian testing with sbcl 1.02 > and cvs version of elephant. Intel 32-bit machine with > 1gb of ram. > > The code I am try to run is pretty straitforward, > it runs with 2000x2000 array, but returns type-error > with anything bigger. > > (let ((big-array (make-array '(5000 5000) > > :element-type 'float > :initial-element 0.0))) > > (time (ele:with-open-store > (*test-bdb-spec*) > (ele:add-to-root 'big-array big-array)))) > > And here is output from the debugger: > > The value 1000000640 is not of type FIXNUM. > [Condition of type TYPE-ERROR] > > Restarts: > 0: [ABORT-REQUEST] Abort handling SLIME request. > 1: [TERMINATE-THREAD] Terminate this thread (# "worker" {B2CBE61}>) > > Backtrace: > 0: (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM # list>) > Locals: > 1: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) # lambda list>) > Locals: > 2: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) # lambda list>) > Locals: > 3: (ELEPHANT-SERIALIZER2::SERIALIZE #) > Locals: > 4: ((SB-PCL::FAST-METHOD (SETF GET-VALUE) (T T DB-BDB::BDB-BTREE)) > #) > Locals: > 5: ((LAMBDA NIL)) > Locals: > 6: (SB-IMPL::%TIME #) > Locals: > SB-DEBUG::ARG-0 = # > 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((BIG-ARRAY #)) (TIME > (WITH-OPEN-STORE # #))) #) > Locals: > SB-DEBUG::ARG-0 = (LET ((BIG-ARRAY (MAKE-ARRAY # :ELEMENT-TYPE > # :INITIAL-ELEMENT 0.0))) (TIME (WITH-OPEN-STORE (*TEST-BDB-SPEC*) > (ADD-TO-ROOT # BIG-ARRAY)))) > SB-DEBUG::ARG-1 = # > 8: ((LAMBDA NIL)) > Locals: > 9: ((LAMBDA (SWANK-BACKEND::FN)) #) > > I would highly appreciate any help. > Regards, Dmitry > > -- > Dmitry V. Gorbatovsky > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Wed Feb 14 16:16:11 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 14 Feb 2007 11:16:11 -0500 Subject: [elephant-devel] SBCL make-alien limits array size details Message-ID: From current SBCL CVS. 216 (defmacro make-alien (type &optional size &environment env) 217 #!+sb-doc 218 "Allocate an alien of type TYPE and return an alien pointer to it. If SIZE 219 is supplied, how it is interpreted depends on TYPE. If TYPE is an array type, 220 SIZE is used as the first dimension for the allocated array. If TYPE is not an 221 array, then SIZE is the number of elements to allocate. The memory is 222 allocated using ``malloc'', so it can be passed to foreign functions which use 223 ``free''." 224 (let ((alien-type (if (alien-type-p type) 225 type 226 (parse-alien-type type env)))) 227 (multiple-value-bind (size-expr element-type) 228 (if (alien-array-type-p alien-type) 229 (let ((dims (alien-array-type-dimensions alien- type))) 230 (cond 231 (size 232 (unless dims 233 (error 234 "cannot override the size of zero- dimensional arrays")) 235 (when (constantp size) 236 (setf alien-type (copy-alien-array-type alien-type)) 237 (setf (alien-array-type-dimensions alien-type) 238 (cons (constant-form-value size) (cdr dims))))) 239 (dims 240 (setf size (car dims))) 241 (t 242 (setf size 1))) 243 (values `(* ,size ,@(cdr dims)) 244 (alien-array-type-element-type alien- type))) 245 (values (or size 1) alien-type)) 246 (let ((bits (alien-type-bits element-type)) 247 (alignment (alien-type-alignment element-type))) 248 (unless bits 249 (error "The size of ~S is unknown." 250 (unparse-alien-type element-type))) 251 (unless alignment 252 (error "The alignment of ~S is unknown." 253 (unparse-alien-type element-type))) 254 ;; This is the one place where the %SAP-ALIEN note is quite 255 ;; undesirable, in most uses of MAKE-ALIEN the %SAP-ALIEN 256 ;; cannot be optimized away. 257 `(locally (declare (muffle-conditions compiler-note)) Notice that the # of bits of the primitive is multiplied by the total # of elements in the call to %make-alien 258 (%sap-alien (%make-alien (* ,(align-offset bits alignment) 259 ,size-expr)) 260 ',(make-alien-pointer-type :to alien- type))))))) 261 262 ;;; Allocate a block of memory at least BITS bits long and return a 263 ;;; system area pointer to it. 264 #!-sb-fluid (declaim (inline %make-alien)) 265 (defun %make-alien (bits) 266 (declare (type index bits)) 267 (alien-funcall (extern-alien "malloc" 268 (function system-area-pointer unsigned)) 269 (ash (the index (+ bits 7)) -3))) Not sure what type index is, but based on the error it must be a fixnum. However the + will fail as bits is not a fixnum. Just FYI... Ian From gorbatovsky at gmail.com Wed Feb 14 16:57:29 2007 From: gorbatovsky at gmail.com (Dmitry V. Gorbatovsky) Date: Wed, 14 Feb 2007 18:57:29 +0200 Subject: [elephant-devel] 'not of type FIXNUM' type-error In-Reply-To: <44BE457A-37A9-43D7-9DA4-0FEBE0975952@csail.mit.edu> References: <200702141545.59988.dg@midasitech.com> <44BE457A-37A9-43D7-9DA4-0FEBE0975952@csail.mit.edu> Message-ID: <200702141857.29758.dg@midasitech.com> Thanks a lot. I am not tried it yet, but it seems to me that your design of matrix storage by indexed rows "naturally" better. Regards, Dmitry On Wednesday 14 February 2007 18:05, Ian Eslick wrote: > Geesh...I chased this down to a design decision inside the SBCL sb- > alien implementation as I couldn't reproduce this on Allegro. > > One design decision in Elephant was to serialize all lisp values to a > foreign byte array so they can be directly submitted to the Berkeley > DB internal pages as a single foreign byte array (required by BDB > API). As values are serialized, the foreign array is resized to > accommodate longer and longer values so the total serialized size of > your object has to not violate any of the various fixnum related > limits in the system. > > It turns out that SBCL has an internal limitation that it computes > foreign array sizes by first computing the # of bits. Thus when you > try to allocate a buffer of 80M bytes, it becomes 640M bytes which is > greater than the SBCL positive fixnum limit of ~512MB (30-bit > signed). Perhaps SBCL 64 doesn't have this same limitation, but when > you allocate extremely large objects you'll eventually run into these > kinds of limitations. > > Elephant itself is currently limited to 2 billion objects (indexes > and persistent indexes) but there is no fixed limit on # of values > other than the ultimate depth of the btree which will exhaust your > locks on a write. > > If you chose to store large arrays in a special index by row you > should have no problem: > > ;; psuedo code - you should get the idea > (defun store-large-array (array index) > (setf (get-value 'columns index) (num-array-columns array)) > (setf (get-value 'rows index) (num-array-rows array)) > (loop for i from 0 upto (num-array-rows array) do > (setf (get-value i index) (array-row array i)))) > > (defun load-large-array (index) > (let* ((columns (get-value 'columns index)) > (rows (get-value 'rows index)) > (array (make-array (list rows columns)))) > (loop for i from 0 upto rows do > (write-row (get-value i index) array)))) > > Cheers, > Ian > > On Feb 14, 2007, at 8:45 AM, Dmitry V. Gorbatovsky wrote: > > Hello , here is debian testing with sbcl 1.02 > > and cvs version of elephant. Intel 32-bit machine with > > 1gb of ram. > > > > The code I am try to run is pretty straitforward, > > it runs with 2000x2000 array, but returns type-error > > with anything bigger. > > > > (let ((big-array (make-array '(5000 5000) > > > > :element-type 'float > > :initial-element 0.0))) > > > > (time (ele:with-open-store > > (*test-bdb-spec*) > > (ele:add-to-root 'big-array big-array)))) > > > > And here is output from the debugger: > > > > The value 1000000640 is not of type FIXNUM. > > [Condition of type TYPE-ERROR] > > > > Restarts: > > 0: [ABORT-REQUEST] Abort handling SLIME request. > > 1: [TERMINATE-THREAD] Terminate this thread (# > "worker" {B2CBE61}>) > > > > Backtrace: > > 0: (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM # > list>) > > Locals: > > 1: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) # > lambda list>) > > Locals: > > 2: ((LABELS ELEPHANT-SERIALIZER2::%SERIALIZE) # > lambda list>) > > Locals: > > 3: (ELEPHANT-SERIALIZER2::SERIALIZE #) > > Locals: > > 4: ((SB-PCL::FAST-METHOD (SETF GET-VALUE) (T T DB-BDB::BDB-BTREE)) > > #) > > Locals: > > 5: ((LAMBDA NIL)) > > Locals: > > 6: (SB-IMPL::%TIME #) > > Locals: > > SB-DEBUG::ARG-0 = # > > 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((BIG-ARRAY #)) (TIME > > (WITH-OPEN-STORE # #))) #) > > Locals: > > SB-DEBUG::ARG-0 = (LET ((BIG-ARRAY (MAKE-ARRAY # :ELEMENT-TYPE > > # :INITIAL-ELEMENT 0.0))) (TIME (WITH-OPEN-STORE (*TEST-BDB-SPEC*) > > (ADD-TO-ROOT # BIG-ARRAY)))) > > SB-DEBUG::ARG-1 = # > > 8: ((LAMBDA NIL)) > > Locals: > > 9: ((LAMBDA (SWANK-BACKEND::FN)) #) > > > > I would highly appreciate any help. > > Regards, Dmitry > > > > -- > > Dmitry V. Gorbatovsky > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From dabittweiler at gmail.com Fri Feb 16 04:06:18 2007 From: dabittweiler at gmail.com (Patrick X) Date: Thu, 15 Feb 2007 22:06:18 -0600 Subject: [elephant-devel] Elephant not installing via SBCL Message-ID: <99dd28530702152006r760bc7a5m4d4c16dccf03e497@mail.gmail.com> I've install Berkeley DB 4.5 and now trying to install elephant via asdf. which fetchs the 6.0 release and I keep getting this error. erred while invoking #on #ELEPHANT-until-C-Source "libmemutil" {61C3E957}> [condition of type ASDF:Operation-ERROR] I'm doing this as root, note sbcl doesn't support threads on netbsd does elephant require threads to work or install within my lisp implementation -- ================================= knot in cables caused data stream to become twisted and kinked. http://groups.google.com/group/lispstl http://www.cwelug.org/ Patrick Pippen From eslick at csail.mit.edu Fri Feb 16 06:26:38 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 16 Feb 2007 01:26:38 -0500 Subject: [elephant-devel] Elephant not installing via SBCL In-Reply-To: <99dd28530702152006r760bc7a5m4d4c16dccf03e497@mail.gmail.com> References: <99dd28530702152006r760bc7a5m4d4c16dccf03e497@mail.gmail.com> Message-ID: <29A6C206-F84B-478A-A49D-6324B2E3987D@csail.mit.edu> Hi Patrick, Welcome to elephant-devel. It's late so I'll be quick. Elephant does not require threads to work. What you are seeing is build errors in the C compilation step for src/memutil/libmemutil.c due to incompatible header files. The 0.6.0 release only works against Berkeley DB 4.3, not 4.5 (api changes and constant changes). This should be documented in the INSTALL file. The current HEAD, which is about to enter an alpha state for the next (0.6.1) release, will depend on 4.5. Good luck and let us know if you have any other problems! Ian On Feb 15, 2007, at 11:06 PM, Patrick X wrote: > I've install Berkeley DB 4.5 and now trying to install elephant via > asdf. > which fetchs the 6.0 release and I keep getting this error. > > erred while invoking #on > #ELEPHANT-until-C-Source "libmemutil" {61C3E957}> > [condition of type ASDF:Operation-ERROR] > > I'm doing this as root, note sbcl doesn't support threads on netbsd > does elephant require threads to work or install within my lisp > implementation > > -- > ================================= > knot in cables caused data stream to become twisted and kinked. > http://groups.google.com/group/lispstl > http://www.cwelug.org/ > Patrick Pippen > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Fri Feb 16 06:55:20 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 16 Feb 2007 01:55:20 -0500 Subject: [elephant-devel] working with many millions of objects In-Reply-To: <452D92EA.1030800@gmail.com> References: <452B4FB9.3010906@gmail.com> <1160484796.2473.941.camel@localhost.localdomain> <452D92EA.1030800@gmail.com> Message-ID: Some experiments performed on an old topic... On Oct 11, 2006, at 8:57 PM, Red Daly wrote: > I was importing into sleepycat using standard elephant routines. I > am not aware of an 'import mode' for sleepycat, but I will look > into that when I have a chance. Another consideration using > sleepycat is that using BTrees with a large working set demands > large amounts of memory relative to a Hash representation. I am > unfamiliar with the internals of elephant and sleepycat, but it > feels like the basic access method is restricting performance, > which seems to be described here: > http://www.sleepycat.com/docs/gsg/C/accessmethods.html#BTreeVSHash > > My problem so far has been importing the data, which goes very fast > until sleepycat requires extensive disk access. The in-memory rate > is reasonable and would complete in a few hours. However, once > disk operations begin the import speed suggests it would take many > days to complete. I have yet to perform extensive benchmarks, but > I estimate the instantiation rate shifts from 1800 persistent class > instantiations /second to 120 / s. The biggest performance factor is properly managing transaction sizes to balance contention, total locks used, etc. You can also turn off all transactional and log synchronization since if you crash, you can always restart a several hour download. I think this may avoid additional overhead, however I have not benchmarked this. i.e. (with-transaction (:txn-nosync t :dirty-read t) (create 500 objects)) > here are the two approaches that I hypothesize may help > performance. I am admittedly unaware of innards of the two systems > in question, so you expert developers will know best. If either > sounds appropriate or you envision another possibility for allowing > this kind of scaling, I will look into implementing such a system. > > 1. decreasing the size of the working set is one possibility for > decreasing run-time memory requirements and disk access. I'm not > sure how the concept of a 'working set' translates from the > sleepycat world to the elephant world, but perhaps you do. What do you mean by working set? When loading stuff into a database you are moving index pages around in the btree and allocating endless amounts of leaf nodes. The index nodes are cacheable, but the leaf nodes are definitely not! I think there are ways to add a bunch of objects and then force a btree to update all the index pages. Access to that functionality, if BDB even supports it, is not provided in elephant. > 2. using a Hash instead of a BTree in the primary database? I am > unsure what this means for elephant. I finally got around to trying this and it showed poorer performance on a large stress test (create, modify and access 10k objects). I don't have a good theory as to why it was slower other than in create where the hash table had to grow. > > In the mean time I will depart from the every-class-is-persistent > approach and also use more traditional data structures. > > Thanks again, > Red Daly > > > > Robert L. Read wrote: >> Yes, it's amusing. >> >> In my own work I use the Postgres backend; I know very little >> about SleepyCat. It seems >> to me that this is more of a SleepyCat issue, then an Elephant >> issue. Perhaps you should >> ask the SleepyCat list? >> >> Are you importing things into SleepyCat directly in the correct >> serialization format that >> they can be read by Elephant? If so, I assume it is just a >> question of solving the SleepyCat >> problems. >> >> An alternative would be to use the SQL-based backend. However, I >> doubt this will solve >> your problem, since at present we (well, I wrote it) use a very >> inefficient serialization scheme >> for the SQL-based backend that base64 encodes everything. This >> had the advantage that >> it makes it work trouble-free with different database backends, >> but could clearly be improved upon. >> However, it is more than efficient enough for all my work, and at >> present nobody is clamoring >> to have it improved. >> >> Is your problem importing the data or using it once it is >> imported? It's hard for me to imagine >> a problem so large that even the import time is a problem --- >> suppose it takes 24 hours --- can >> you not afford to pay that? >> >> A drastic measure and potentially expensive measure would be to >> switch to a 64-bit architecture >> with a huge memory. I intend to do that when forced by >> performance issues in my own work. >> >> >> >> On Tue, 2006-10-10 at 00:46 -0700, Red Daly wrote: >>> I will be running experiments in informatics and modeling in the >>> future that may contain (tens or hundreds of) millions of >>> objects. Given the ease of use of elephant so far, it would be >>> great to use it as the persistent store and avoid creating too >>> many custom data structures. >>> >>> I have recently run up against some performance bottlenecks when >>> using elephant to work with very large datasets (in the hundreds >>> of millions of objects). Using SleepyCat, I am able to import >>> data very quickly with a DB_CONFIG file with the following contents: >>> >>> set_lk_max_locks 500000 >>> set_lk_max_objects 500000 >>> set_lk_max_lockers 500000 >>> set_cachesize 1 0 0 >>> >>> I can import data very quickly until the 1 gb cache is too small >>> to allow complete in-memory access to the database. at this >>> point it seems that disk IO makes additional writes happen much >>> slower. (I have also tried increasing the 1 gb cache size, but >>> the database fails to open if it is too large--e.g. 2 gbs. I >>> have 1.25 gb physical memory and 4 gb swap, so the constraint >>> seems to be physical memory.) the max_lock, etc. lines allow >>> transactions to contain hundreds of thousands of individual >>> locks, limiting the transaction throughput bottleneck >>> >>> What are the technical restrictions on writing several million >>> objects to the datastore? Is it feasible to create a batch >>> import feature to allow large datasets to be imported using >>> reasonable amounts of memory for a desktop computer? >>> >>> I hope this email is at least amusing! >>> >>> Thanks again, >>> red daly >>> _______________________________________________ >>> elephant-devel site list >>> elephant-devel at common-lisp.net >> lisp.net> >>> http://common-lisp.net/mailman/listinfo/elephant-devel >>> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Sun Feb 18 17:10:20 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 18 Feb 2007 12:10:20 -0500 Subject: [elephant-devel] Elephant 0.6.1 Alpha Release available Message-ID: An alpha release of Elephant 0.6.1 is now available for testing. Supported platforms: - SBCL, Allegro, CMU, OpenMCL, Lispworks (build system is not automated for Windows) - CMU, OpenMCL and Lispworks have not been fully tested and may require minor bug fixes DOWNLOAD AND INSTALL: The alpha release will only be available via CVS cvs -z3 -d :pserver:anonymous:anonymous at common-lisp.net:/project/ elephant/cvsroot checkout -r ELEPHANT-0-6-1-alpha elephant This will put the elephant release into the directory: elephant. Read the INSTALL, UPGRADE and UPGRADE-BDB files for further instructions. PURPOSE OF THE ALPHA RELEASE: The primary developers do not have ready access to all supported platforms and would like to ask the community to help validate the current implementation on other platforms. We also are using the alpha to improve up our test suite. For more details please see the TODO file. If you have a favorite feature such as multi-threading, 64-bit, etc., please free to submit a test for the test suite. NEW FEATURES IN 0.6.1: Simplified build and site configuration support - See config.sexp in root directory for site customization (no more editing code files) - Linux and Mac systems should automatically build libraries when asdf is called 64-bit lisps are now supported - 64-bit and 32-bit lisps can read and run off the same database files (on the same machine) Multithreading: - Elephant should now be thread safe, including sharing a single store-controller across threads - Read comments in src/elephant/transactions.lisp and BDB users should read src/db-bdb/bdb-transactions.lisp - Improved support for mixing transactions and store-controllers Upgrading: - Elephant 0.6.1 can open and directly manipulate 0.6.0 databases - Existing 0.6.0 databases can be upgraded via the 'upgrade' function which takes - Upgrading is required for 64-bit systems - New serializer-independant metadata should enable future upgrades easier - NOTE: There may be some problems upgrading SQL databases Berkeley DB backend: - BDB 4.5 required (see UPGRADE-BDB) - *auto-commit* is no longer required. All data access methods auto- commit if there is no active transaction. - store-controller accepts :deadlock-detect keyword (t or nil) which will run db_deadlock as a background process to abort deadlocked threads - optimize-storage is a new store-controller method currently supported by BDB backend. It compacts a whole database or only a specific BTree and returns free pages to the free list or to the file system. Minor features: - Re-organization to the internal structure in this release: - Renaming including removing defunct sleepycat naming scheme, backend packages, etc. - The serializer was modularized to allow future releases to change serializer strategies or implement custom serializers and to be able to open legacy databases - Remove various warnings in SBCL build, etc. - Separated utilities into their own package and directory - Serializer improvements - 0.6.1 databases can be shared across lisps running on hardware of the same endianness (i.e. all x86 platforms or PPC/Alpha, etc) - Simplified unicode serialization support across all platforms - Performance improvements in multi-threading situations - Feature :elephant-without-optimize will disable optimization declarations simplifying debugging - Other fixes and features documented in the TODO file Thank you, Ian Eslick and Robert Read Elephant Developers From henrik at evahjelte.com Sun Feb 18 20:19:17 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 18 Feb 2007 21:19:17 +0100 Subject: [elephant-devel] Elephant 0.6.1 Alpha Release available In-Reply-To: References: Message-ID: <1171829957.18582.395.camel@trinidad> Great! Here are some results from sbcl/linux/amd64: elephant.asd line 113 should be like this: #+(and X86-64 linux) "-march=x86-64" berkeley-db tests: All tests ok, the first time. If I run do-backend-tests again, prepares-bdb fails. However, if I run delscript.sh then all tests run ok again. sql tests: (I use postgresql 8.1) 5 out of 115 total tests failed: FIXNUMS, WRITE-64-BIT-FIXNUM, BIGNUMS, RATIONALS, ARRAYS-2. That is because of a typo that in the end causes the old serializer1 to be loaded. The typo is [keyvlaue] should be [keyvalue], line 119 of sql-controller.lisp in the function create-version-table. After fixing this, everything runs ok. Migration tests: I tried: (do-migration-tests *testbdb-spec* *testbdb-spec2*) (do-migration-tests *testbdb-spec2* *testpg-spec*) Both work I guess, at least they don't show any errors. But they run awfully fast, and end with the output like this: Migrating Migrating class indexes for: IPFOO Copying the root: Fetching MIGRATE-IPCLASS MIGRATE-IPCLASS Does this mean they run ok? To summarize, it looks really good! Thanks a lot for this! /Henrik Hjelte On Sun, 2007-02-18 at 12:10 -0500, Ian Eslick wrote: > An alpha release of Elephant 0.6.1 is now available for testing. > > Supported platforms: > - SBCL, Allegro, CMU, OpenMCL, Lispworks (build system is not > automated for Windows) > - CMU, OpenMCL and Lispworks have not been fully tested and may > require minor bug fixes > > > DOWNLOAD AND INSTALL: > > The alpha release will only be available via CVS > > cvs -z3 -d :pserver:anonymous:anonymous at common-lisp.net:/project/ > elephant/cvsroot checkout -r ELEPHANT-0-6-1-alpha elephant > > This will put the elephant release into the directory: elephant. > Read the INSTALL, UPGRADE and UPGRADE-BDB files for further > instructions. > > > PURPOSE OF THE ALPHA RELEASE: > > The primary developers do not have ready access to all supported > platforms and would like to ask the community to help validate the > current implementation on other platforms. We also are using the > alpha to improve up our test suite. For more details please see the > TODO file. If you have a favorite feature such as multi-threading, > 64-bit, etc., please free to submit a test for the test suite. > > > NEW FEATURES IN 0.6.1: > > Simplified build and site configuration support > - See config.sexp in root directory for site customization (no more > editing code files) > - Linux and Mac systems should automatically build libraries when > asdf is called > > 64-bit lisps are now supported > - 64-bit and 32-bit lisps can read and run off the same database > files (on the same machine) > > Multithreading: > - Elephant should now be thread safe, including sharing a single > store-controller across threads > - Read comments in src/elephant/transactions.lisp and BDB users > should read src/db-bdb/bdb-transactions.lisp > - Improved support for mixing transactions and store-controllers > > Upgrading: > - Elephant 0.6.1 can open and directly manipulate 0.6.0 databases > - Existing 0.6.0 databases can be upgraded via the 'upgrade' function > which takes > - Upgrading is required for 64-bit systems > - New serializer-independant metadata should enable future upgrades > easier > - NOTE: There may be some problems upgrading SQL databases > > Berkeley DB backend: > - BDB 4.5 required (see UPGRADE-BDB) > - *auto-commit* is no longer required. All data access methods auto- > commit if there is no active transaction. > - store-controller accepts :deadlock-detect keyword (t or nil) which > will run db_deadlock as a background process to abort deadlocked threads > - optimize-storage is a new store-controller method currently > supported by BDB backend. It compacts a whole database or only a > specific BTree and returns free pages to the free list or to the file > system. > > Minor features: > - Re-organization to the internal structure in this release: > - Renaming including removing defunct sleepycat naming scheme, > backend packages, etc. > - The serializer was modularized to allow future releases to > change serializer > strategies or implement custom serializers and to be able to > open legacy databases > - Remove various warnings in SBCL build, etc. > - Separated utilities into their own package and directory > - Serializer improvements > - 0.6.1 databases can be shared across lisps running on hardware > of the same endianness > (i.e. all x86 platforms or PPC/Alpha, etc) > - Simplified unicode serialization support across all platforms > - Performance improvements in multi-threading situations > - Feature :elephant-without-optimize will disable optimization > declarations simplifying debugging > - Other fixes and features documented in the TODO file > > Thank you, > Ian Eslick and Robert Read > Elephant Developers > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > From read at robertlread.net Sun Feb 18 21:14:46 2007 From: read at robertlread.net (Robert L. Read) Date: Sun, 18 Feb 2007 15:14:46 -0600 Subject: [elephant-devel] Elephant 0.6.1 Alpha Release available In-Reply-To: <1171829957.18582.395.camel@trinidad> References: <1171829957.18582.395.camel@trinidad> Message-ID: <1171833286.21183.50.camel@localhost.localdomain> That's great news; a 64bit system is bound to be useful in the future. I checked in the typo you noticed. Ian and I will review streamlining the testing process/output as we work on the documentation; it is clearly confusing. I think it worked if it didn't give you an error. On Sun, 2007-02-18 at 21:19 +0100, Henrik Hjelte wrote: > Great! > Here are some results from sbcl/linux/amd64: > > elephant.asd line 113 should be like this: > #+(and X86-64 linux) "-march=x86-64" > > berkeley-db tests: > All tests ok, the first time. > If I run do-backend-tests again, prepares-bdb fails. > However, if I run delscript.sh then all tests run ok again. > > > sql tests: > (I use postgresql 8.1) > > 5 out of 115 total tests failed: FIXNUMS, WRITE-64-BIT-FIXNUM, BIGNUMS, > RATIONALS, ARRAYS-2. > > That is because of a typo that in the end causes the old serializer1 to > be loaded. > > The typo is [keyvlaue] should be [keyvalue], line 119 of > sql-controller.lisp in the function create-version-table. > > After fixing this, > everything runs ok. > > Migration tests: > I tried: > (do-migration-tests *testbdb-spec* *testbdb-spec2*) > (do-migration-tests *testbdb-spec2* *testpg-spec*) > Both work I guess, at least they don't show any errors. > But they run awfully fast, and end with the output like this: > Migrating > Migrating class indexes for: IPFOO > Copying the root: > Fetching > > MIGRATE-IPCLASS > MIGRATE-IPCLASS > > Does this mean they run ok? > > To summarize, it looks really good! Thanks a lot for this! > > /Henrik Hjelte > > > > > On Sun, 2007-02-18 at 12:10 -0500, Ian Eslick wrote: > > An alpha release of Elephant 0.6.1 is now available for testing. > > > > Supported platforms: > > - SBCL, Allegro, CMU, OpenMCL, Lispworks (build system is not > > automated for Windows) > > - CMU, OpenMCL and Lispworks have not been fully tested and may > > require minor bug fixes > > > > > > DOWNLOAD AND INSTALL: > > > > The alpha release will only be available via CVS > > > > cvs -z3 -d :pserver:anonymous:anonymous at common-lisp.net:/project/ > > elephant/cvsroot checkout -r ELEPHANT-0-6-1-alpha elephant > > > > This will put the elephant release into the directory: elephant. > > Read the INSTALL, UPGRADE and UPGRADE-BDB files for further > > instructions. > > > > > > PURPOSE OF THE ALPHA RELEASE: > > > > The primary developers do not have ready access to all supported > > platforms and would like to ask the community to help validate the > > current implementation on other platforms. We also are using the > > alpha to improve up our test suite. For more details please see the > > TODO file. If you have a favorite feature such as multi-threading, > > 64-bit, etc., please free to submit a test for the test suite. > > > > > > NEW FEATURES IN 0.6.1: > > > > Simplified build and site configuration support > > - See config.sexp in root directory for site customization (no more > > editing code files) > > - Linux and Mac systems should automatically build libraries when > > asdf is called > > > > 64-bit lisps are now supported > > - 64-bit and 32-bit lisps can read and run off the same database > > files (on the same machine) > > > > Multithreading: > > - Elephant should now be thread safe, including sharing a single > > store-controller across threads > > - Read comments in src/elephant/transactions.lisp and BDB users > > should read src/db-bdb/bdb-transactions.lisp > > - Improved support for mixing transactions and store-controllers > > > > Upgrading: > > - Elephant 0.6.1 can open and directly manipulate 0.6.0 databases > > - Existing 0.6.0 databases can be upgraded via the 'upgrade' function > > which takes > > - Upgrading is required for 64-bit systems > > - New serializer-independant metadata should enable future upgrades > > easier > > - NOTE: There may be some problems upgrading SQL databases > > > > Berkeley DB backend: > > - BDB 4.5 required (see UPGRADE-BDB) > > - *auto-commit* is no longer required. All data access methods auto- > > commit if there is no active transaction. > > - store-controller accepts :deadlock-detect keyword (t or nil) which > > will run db_deadlock as a background process to abort deadlocked threads > > - optimize-storage is a new store-controller method currently > > supported by BDB backend. It compacts a whole database or only a > > specific BTree and returns free pages to the free list or to the file > > system. > > > > Minor features: > > - Re-organization to the internal structure in this release: > > - Renaming including removing defunct sleepycat naming scheme, > > backend packages, etc. > > - The serializer was modularized to allow future releases to > > change serializer > > strategies or implement custom serializers and to be able to > > open legacy databases > > - Remove various warnings in SBCL build, etc. > > - Separated utilities into their own package and directory > > - Serializer improvements > > - 0.6.1 databases can be shared across lisps running on hardware > > of the same endianness > > (i.e. all x86 platforms or PPC/Alpha, etc) > > - Simplified unicode serialization support across all platforms > > - Performance improvements in multi-threading situations > > - Feature :elephant-without-optimize will disable optimization > > declarations simplifying debugging > > - Other fixes and features documented in the TODO file > > > > Thank you, > > Ian Eslick and Robert Read > > Elephant Developers > > > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > > > > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Mon Feb 19 13:15:15 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 19 Feb 2007 08:15:15 -0500 Subject: [elephant-devel] Testing In-Reply-To: <379713322@web.de> References: <379713322@web.de> Message-ID: Does this work for generating the DLL for libberkeley-db.c? gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll I can include the memutils .def file so this single command is easy to invoke from asdf instead of via a shell script or makefile. Ian On Jan 23, 2007, at 7:48 PM, franks-muc at web.de wrote: > > I tried the new elephant on winXP. > > 1. Allegro8 trial: > > Error: In :IMPORT list, the symbol "ARRAY-TYPE-FROM-BYTE" not found > in package # > [condition type: PACKAGE-ERROR] > > when loading > c:\lisp\binaries\allegro-a8.0-mswindows-x86\lisp\libraries\elephant > \src\elephant\serializer1.fasl > > 2. LispWorks 5 pro > > in file memutil.lisp > > This creates an error: > > (def-foreign-type array-or-pointer-char > #+allegro (:array :char) > #+(or cmu sbcl scl openmcl) (* :char)) > > changed 2nd line to: > #+(or allegro lispworks) (:array :char) > don't know whether it is the correct selection > > Then: > > Compilation aborted due to error between functions: > Package SB-KERNEL not found. > > when compiling this: > ;; A non-back-compatible change was made in SBCL 8 moving to SBCL 9, > ;; in that the function copy-from-system-area disappeared. > ;; This code is an attempt to allow compilation under bothe SBCL 8 > and SBCL 9. > ;; Thanks to Juho Snellman for this idiom. > (eval-when (:compile-toplevel) > (defun new-style-copy-p () > (if (find-symbol "COPY-UB8-FROM-SYSTEM-AREA" "SB-KERNEL") > '(:and) > '(:or))) > ) > > I then commented out all forms depending on > ;#+#.(elephant-memutil::new-style-copy-p) and > ;#-#.(elephant-memutil::new-style-copy-p) > > in file package lisp > > Compilation aborted due to error between functions: > Duplicated names in "ELEPHANT" defpackage: "ELE". > > I replaced > (:nicknames ele :ele) > with > (:nicknames :ele) > > In file metaclasses.lisp > > **++++ Error in (DEFCLASS ELEPHANT:PERSISTENT): > Defining function :DBCN-SPC-PST visible from package KEYWORD. > > The accessor function stars with colon. I deleted the colon. > > In file classes.lisp > > Error > Defining (METHOD ENSURE-CLASS-USING-CLASS :AROUND ((EQL NIL) T)) > visible from packages COMMON-LISP, CLOS. > > No idea what to do. > > > 3. I was able to use elephant 6.0 with ACL 7 trial > > wherein I used cygwin to produce the dll s, and I copied the dll, > with a newer date than the source, into the > directory with binaries to prevent recompilation started with run- > shell-command from asdf, which does not seem > to work on windows. > > This is the script for libmemutil.dll: > > gcc -mno-cygwin -mwindows -std=c99 -c libmemutil.c > dlltool -z libmeutil.def --export-all-symbols -e exports.o -l > libmemutil.lib libmemutil.o > gcc -shared -mno-cygwin -mwindows libmemutil.o exports.o -o > libmemutil.dll > > And this is the script for libsleepycat.dll: > > gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/DB/Berkeley\ DB\ > 4.4.20/lib/ -I/c/DB/Berkeley\ DB\ 4.4.20/include/ libsleepycat.c > dlltool -z libsleepycat.def --export-all-symbols -e exports.o -l > libsleepycat.lib libsleepycat.o > gcc -shared -mno-cygwin -mwindows -L/c/DB/Berkeley\ DB\ 4.4.20/bin/ > -llibdb44 libsleepycat.o exports.o -o libsleepycat.dll > > (I don't know how to use variables in shell scripts) > > > 4. I will try again > > ______________________________________________________________________ > _ > Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und > kostenlos. > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From franks-muc at web.de Mon Feb 19 19:09:49 2007 From: franks-muc at web.de (Frank Schorr) Date: Mon, 19 Feb 2007 20:09:49 +0100 Subject: [elephant-devel] Testing Message-ID: <417686433@web.de> gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll produces cc1: error: unrecognized command line option "-fexport-all-symbols" Further: gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/include/ libberkeley-db.c produces In file included from libberkeley-db.c:165: /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: conflicting types for 'ssize_t' /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/types .h:104: error: previous declaration of 'ssize_t' was here libberkeley-db.c: In function `case_cmp': libberkeley-db.c:1233: warning: implicit declaration of function `_strnicmp' Hope this can help Please let me know what to do next. Frank > Does this work for generating the DLL for libberkeley-db.c? > > gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols > libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll > > I can include the memutils .def file so this single command is easy > to invoke from asdf instead of via a shell script or makefile. > > Ian > > On Jan 23, 2007, at 7:48 PM, franks-muc at web.de wrote: > > > > > I tried the new elephant on winXP. > > > > 1. Allegro8 trial: > > > > Error: In :IMPORT list, the symbol "ARRAY-TYPE-FROM-BYTE" not found > > in package # > > [condition type: PACKAGE-ERROR] > > > > when loading > > c:\lisp\binaries\allegro-a8.0-mswindows-x86\lisp\libraries\elephant > > \src\elephant\serializer1.fasl > > > > 2. LispWorks 5 pro > > > > in file memutil.lisp > > > > This creates an error: > > > > (def-foreign-type array-or-pointer-char > > #+allegro (:array :char) > > #+(or cmu sbcl scl openmcl) (* :char)) > > > > changed 2nd line to: > > #+(or allegro lispworks) (:array :char) > > don't know whether it is the correct selection > > > > Then: > > > > Compilation aborted due to error between functions: > > Package SB-KERNEL not found. > > > > when compiling this: > > ;; A non-back-compatible change was made in SBCL 8 moving to SBCL 9, > > ;; in that the function copy-from-system-area disappeared. > > ;; This code is an attempt to allow compilation under bothe SBCL 8 > > and SBCL 9. > > ;; Thanks to Juho Snellman for this idiom. > > (eval-when (:compile-toplevel) > > (defun new-style-copy-p () > > (if (find-symbol "COPY-UB8-FROM-SYSTEM-AREA" "SB-KERNEL") > > '(:and) > > '(:or))) > > ) > > > > I then commented out all forms depending on > > ;#+#.(elephant-memutil::new-style-copy-p) and > > ;#-#.(elephant-memutil::new-style-copy-p) > > > > in file package lisp > > > > Compilation aborted due to error between functions: > > Duplicated names in "ELEPHANT" defpackage: "ELE". > > > > I replaced > > (:nicknames ele :ele) > > with > > (:nicknames :ele) > > > > In file metaclasses.lisp > > > > **++++ Error in (DEFCLASS ELEPHANT:PERSISTENT): > > Defining function :DBCN-SPC-PST visible from package KEYWORD. > > > > The accessor function stars with colon. I deleted the colon. > > > > In file classes.lisp > > > > Error > > Defining (METHOD ENSURE-CLASS-USING-CLASS :AROUND ((EQL NIL) T)) > > visible from packages COMMON-LISP, CLOS. > > > > No idea what to do. > > > > > > 3. I was able to use elephant 6.0 with ACL 7 trial > > > > wherein I used cygwin to produce the dll s, and I copied the dll, > > with a newer date than the source, into the > > directory with binaries to prevent recompilation started with run- > > shell-command from asdf, which does not seem > > to work on windows. > > > > This is the script for libmemutil.dll: > > > > gcc -mno-cygwin -mwindows -std=c99 -c libmemutil.c > > dlltool -z libmeutil.def --export-all-symbols -e exports.o -l > > libmemutil.lib libmemutil.o > > gcc -shared -mno-cygwin -mwindows libmemutil.o exports.o -o > > libmemutil.dll > > > > And this is the script for libsleepycat.dll: > > > > gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/DB/Berkeley\ DB\ > > 4.4.20/lib/ -I/c/DB/Berkeley\ DB\ 4.4.20/include/ libsleepycat.c > > dlltool -z libsleepycat.def --export-all-symbols -e exports.o -l > > libsleepycat.lib libsleepycat.o > > gcc -shared -mno-cygwin -mwindows -L/c/DB/Berkeley\ DB\ 4.4.20/bin/ > > -llibdb44 libsleepycat.o exports.o -o libsleepycat.dll > > > > (I don't know how to use variables in shell scripts) > > > > > > 4. I will try again > > > > ______________________________________________________________________ > > _ > > Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und > > kostenlos. > > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 From eslick at csail.mit.edu Mon Feb 19 20:24:30 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 19 Feb 2007 15:24:30 -0500 Subject: [elephant-devel] Testing In-Reply-To: <417686433@web.de> References: <417686433@web.de> Message-ID: Thanks for trying that. Do you know if there's a way with the cygwin gcc compiler to use a .def file instead of generating a .o with the exports? I'm pretty sure MSVC has one. We'll also need a set of build commands for MSVC... I suspect we may have broken the build of libmemutil when we included sys/types to get access to u_int64 and u_int32, etc. Without a local system to play with I'm not sure I can debug this. I guess the thing to do is look at db.h and sys/types to try to figure out what was intended and whether they're compatible. I'll see about getting access to a Windows box to try to reproduce and test these things on my side. Thanks, Ian On Feb 19, 2007, at 2:09 PM, Frank Schorr wrote: > > gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols > libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll > > produces > > cc1: error: unrecognized command line option "-fexport-all-symbols" > > Further: > > gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/ > Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ > 4.5.20/include/ libberkeley-db.c > > produces > > In file included from libberkeley-db.c:165: > /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: > conflicting types > for 'ssize_t' > /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/ > include/sys/types > .h:104: error: previous declaration of 'ssize_t' was here > libberkeley-db.c: In function `case_cmp': > libberkeley-db.c:1233: warning: implicit declaration of function > `_strnicmp' > > Hope this can help > Please let me know what to do next. > Frank > > >> Does this work for generating the DLL for libberkeley-db.c? >> >> gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols >> libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll >> >> I can include the memutils .def file so this single command is easy >> to invoke from asdf instead of via a shell script or makefile. >> >> Ian >> >> On Jan 23, 2007, at 7:48 PM, franks-muc at web.de wrote: >> >>> >>> I tried the new elephant on winXP. >>> >>> 1. Allegro8 trial: >>> >>> Error: In :IMPORT list, the symbol "ARRAY-TYPE-FROM-BYTE" not found >>> in package # >>> [condition type: PACKAGE-ERROR] >>> >>> when loading >>> c:\lisp\binaries\allegro-a8.0-mswindows-x86\lisp\libraries\elephant >>> \src\elephant\serializer1.fasl >>> >>> 2. LispWorks 5 pro >>> >>> in file memutil.lisp >>> >>> This creates an error: >>> >>> (def-foreign-type array-or-pointer-char >>> #+allegro (:array :char) >>> #+(or cmu sbcl scl openmcl) (* :char)) >>> >>> changed 2nd line to: >>> #+(or allegro lispworks) (:array :char) >>> don't know whether it is the correct selection >>> >>> Then: >>> >>> Compilation aborted due to error between functions: >>> Package SB-KERNEL not found. >>> >>> when compiling this: >>> ;; A non-back-compatible change was made in SBCL 8 moving to SBCL 9, >>> ;; in that the function copy-from-system-area disappeared. >>> ;; This code is an attempt to allow compilation under bothe SBCL 8 >>> and SBCL 9. >>> ;; Thanks to Juho Snellman for this idiom. >>> (eval-when (:compile-toplevel) >>> (defun new-style-copy-p () >>> (if (find-symbol "COPY-UB8-FROM-SYSTEM-AREA" "SB-KERNEL") >>> '(:and) >>> '(:or))) >>> ) >>> >>> I then commented out all forms depending on >>> ;#+#.(elephant-memutil::new-style-copy-p) and >>> ;#-#.(elephant-memutil::new-style-copy-p) >>> >>> in file package lisp >>> >>> Compilation aborted due to error between functions: >>> Duplicated names in "ELEPHANT" defpackage: "ELE". >>> >>> I replaced >>> (:nicknames ele :ele) >>> with >>> (:nicknames :ele) >>> >>> In file metaclasses.lisp >>> >>> **++++ Error in (DEFCLASS ELEPHANT:PERSISTENT): >>> Defining function :DBCN-SPC-PST visible from package KEYWORD. >>> >>> The accessor function stars with colon. I deleted the colon. >>> >>> In file classes.lisp >>> >>> Error >>> Defining (METHOD ENSURE-CLASS-USING-CLASS :AROUND ((EQL NIL) T)) >>> visible from packages COMMON-LISP, CLOS. >>> >>> No idea what to do. >>> >>> >>> 3. I was able to use elephant 6.0 with ACL 7 trial >>> >>> wherein I used cygwin to produce the dll s, and I copied the dll, >>> with a newer date than the source, into the >>> directory with binaries to prevent recompilation started with run- >>> shell-command from asdf, which does not seem >>> to work on windows. >>> >>> This is the script for libmemutil.dll: >>> >>> gcc -mno-cygwin -mwindows -std=c99 -c libmemutil.c >>> dlltool -z libmeutil.def --export-all-symbols -e exports.o -l >>> libmemutil.lib libmemutil.o >>> gcc -shared -mno-cygwin -mwindows libmemutil.o exports.o -o >>> libmemutil.dll >>> >>> And this is the script for libsleepycat.dll: >>> >>> gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/DB/Berkeley\ DB\ >>> 4.4.20/lib/ -I/c/DB/Berkeley\ DB\ 4.4.20/include/ libsleepycat.c >>> dlltool -z libsleepycat.def --export-all-symbols -e exports.o -l >>> libsleepycat.lib libsleepycat.o >>> gcc -shared -mno-cygwin -mwindows -L/c/DB/Berkeley\ DB\ 4.4.20/bin/ >>> -llibdb44 libsleepycat.o exports.o -o libsleepycat.dll >>> >>> (I don't know how to use variables in shell scripts) >>> >>> >>> 4. I will try again >>> >>> ____________________________________________________________________ >>> __ >>> _ >>> Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und >>> kostenlos. >>> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 >>> >>> _______________________________________________ >>> elephant-devel site list >>> elephant-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/elephant-devel >> >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel >> > > > _____________________________________________________________________ > Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From franks-muc at web.de Mon Feb 19 23:20:16 2007 From: franks-muc at web.de (Frank Schorr) Date: Tue, 20 Feb 2007 00:20:16 +0100 Subject: [elephant-devel] Testing Message-ID: <417904812@web.de> I haven't really understood what happens when a dll is built with cygwin. dlltool generates the .def file and the exports.o used in the next gcc step. See http://www.gnu.org/software/binutils/manual/html_chapter/binutils_13.html http://www.cygwin.com/cygwin-ug-net/dll.html I was able to get a libmemutil.dll without errors by: gcc -mno-cygwin -mwindows -std=c99 -c libmemutil.c dlltool -z libmeutil.def --export-all-symbols -e exports.o -l libmemutil.lib libmemutil.o gcc -shared -mno-cygwin -mwindows libmemutil.o exports.o -o libmemutil.dll A while ago, when I made the dlls for elephant 0.6.0, my first try was MSVC, guided by http://bc.tech.coop/blog/041007.html However, the available free MSVC appeared to have no preset dll-project any more. I had to try compiler switches ... and found cygwin easier. This should mean that not every lisp-on-windows-user has MSVC installed (and is able to use it. cygwin is easy to install). Best regards, Frank > -----Urspr?ngliche Nachricht----- > Von: Elephant bugs and development > Gesendet: 19.02.07 21:26:09 > An: Elephant bugs and development > Betreff: Re: [elephant-devel] Testing > Thanks for trying that. Do you know if there's a way with the cygwin > gcc compiler to use a .def file instead of generating a .o with the > exports? I'm pretty sure MSVC has one. We'll also need a set of > build commands for MSVC... > > I suspect we may have broken the build of libmemutil when we included > sys/types to get access to u_int64 and u_int32, etc. Without a > local system to play with I'm not sure I can debug this. I guess the > thing to do is look at db.h and sys/types to try to figure out what > was intended and whether they're compatible. > > I'll see about getting access to a Windows box to try to reproduce > and test these things on my side. > > Thanks, > Ian > > On Feb 19, 2007, at 2:09 PM, Frank Schorr wrote: > > > > > gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols > > libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll > > > > produces > > > > cc1: error: unrecognized command line option "-fexport-all-symbols" > > > > Further: > > > > gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/ > > Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ > > 4.5.20/include/ libberkeley-db.c > > > > produces > > > > In file included from libberkeley-db.c:165: > > /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: > > conflicting types > > for 'ssize_t' > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/ > > include/sys/types > > .h:104: error: previous declaration of 'ssize_t' was here > > libberkeley-db.c: In function `case_cmp': > > libberkeley-db.c:1233: warning: implicit declaration of function > > `_strnicmp' > > > > Hope this can help > > Please let me know what to do next. > > Frank > > __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131 From cjstuij at gmail.com Sat Feb 24 23:50:18 2007 From: cjstuij at gmail.com (Ties Stuij) Date: Sun, 25 Feb 2007 00:50:18 +0100 Subject: [elephant-devel] new elephant and unicode troubles Message-ID: with the cvs elephant on sbcl on linux with bdb, with all tests passed, the following code: (defclass crocodile () ((belly :accessor belly-of :initform "j?rv")) (:metaclass persistent-metaclass)) (defparameter *ben* (make-instance 'crocodile)) (belly-of *ben*) gives: deserialize of object tagged with 188 failed as an error, which comes from %deserialize, from deserialize in serialize2.lisp. A string with 'safe' characters though is properly recognized as utf-8. The 188 can also be 132 or another value. The 6.1 checkout renders the same result but i must say i did like the error message 'deserialize fubar!' more. Ideas? Greets, Ties From henrik at evahjelte.com Sun Feb 25 09:43:13 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 25 Feb 2007 10:43:13 +0100 Subject: [elephant-devel] new elephant and unicode troubles In-Reply-To: References: Message-ID: <1172396593.18582.525.camel@trinidad> Hi Ties! Nothing beats a sunday morning bughunt! Found the solution for you, see below. Cheers, Henrik Hjelte Add this testcase to testserializer.lisp: (Sorry the code indentation looks funny when attached to an email) (deftest hard-strings (are-not-null (in-out-equal (format nil "Mot~arhead is a hard rock band." (code-char 246))) (in-out-equal (format nil "M~atley cr~ae is a hard string and was a hard rock band." (code-char 246) (char-code 252)))) t t) Had to change serialize-string this in unicode2.lisp to look like this. Apparantly the term utf8 in this file has nothing at all to do with utf8, rather it means a string of ascii chars. So serialize-to-utf8 returns nil when it finds a code>127. Then it should continue trying with two-byte char strings, which was not done in the existing cvs version. (defun serialize-string (string bstream) "Try to write each format type and bail if code is too big" (or (serialize-to-utf8 string bstream) (serialize-to-utf16le string bstream) (serialize-to-utf32le string bstream))) Old buggy version: ;;(defun serialize-string (string bstream) ;; "Try to write each format type and bail if code is too big" ;;(declare (type buffer-stream bstream) ;; (type string string)) ;; (cond ((and (not (string= "" string)) (< (char-code (char string 0)) #x7F)) ;; (serialize-to-utf8 string bstream)) ;; ;; Accelerate the common case where a character set is not Latin-1 ;; ((and (not (string= "" string)) (< (char-code (char string 0)) #xFFFF)) ;; (serialize-to-utf16le string bstream)) ;; ;; Actually code pages > 0 are rare; so we can pay an extra cost ;; (t (or (serialize-to-utf8 string bstream) ;; (serialize-to-utf16le string bstream) ;; (serialize-to-utf32le string bstream))))) On Sun, 2007-02-25 at 00:50 +0100, Ties Stuij wrote: > with the cvs elephant on sbcl on linux with bdb, with all tests > passed, the following code: > > (defclass crocodile () > ((belly :accessor belly-of :initform "j?rv")) > (:metaclass persistent-metaclass)) > > (defparameter *ben* (make-instance 'crocodile)) > > (belly-of *ben*) > > gives: > > deserialize of object tagged with 188 failed > > as an error, which comes from %deserialize, from deserialize in > serialize2.lisp. A string with 'safe' characters though is properly > recognized as utf-8. The 188 can also be 132 or another value. The 6.1 > checkout renders the same result but i must say i did like the error > message 'deserialize fubar!' more. Ideas? > > Greets, > Ties > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > From cjstuij at gmail.com Sun Feb 25 09:50:49 2007 From: cjstuij at gmail.com (Ties Stuij) Date: Sun, 25 Feb 2007 10:50:49 +0100 Subject: [elephant-devel] Re: new elephant and unicode troubles In-Reply-To: References: Message-ID: ok, i've slept a bit and all of a sudden the problem isn't that difficult. That is to say, i understand and can solve the problem, but there seem to be 'slightly' deeper problems. Basically elephant checks the first character of a string for being over x7f, if it's not, the string is encoded as utf-8. In serialize-to-utf-8 no character can be over charcode x7f or the function will fail silently, however in utf-8 the majority of the characters are over x7f, since it covers a range of four bytes. ah, shoots, henrik beat me to it. well is there something wrong with just checking what string the underlying lisp provides and dispatch on that, kinda like the old serialize function did in 6.0? greets, Ties On 2/25/07, Ties Stuij wrote: > with the cvs elephant on sbcl on linux with bdb, with all tests > passed, the following code: > > (defclass crocodile () > ((belly :accessor belly-of :initform "j?rv")) > (:metaclass persistent-metaclass)) > > (defparameter *ben* (make-instance 'crocodile)) > > (belly-of *ben*) > > gives: > > deserialize of object tagged with 188 failed > > as an error, which comes from %deserialize, from deserialize in > serialize2.lisp. A string with 'safe' characters though is properly > recognized as utf-8. The 188 can also be 132 or another value. The 6.1 > checkout renders the same result but i must say i did like the error > message 'deserialize fubar!' more. Ideas? > > Greets, > Ties > From cjstuij at gmail.com Sun Feb 25 12:58:38 2007 From: cjstuij at gmail.com (Ties Stuij) Date: Sun, 25 Feb 2007 13:58:38 +0100 Subject: [elephant-devel] new elephant and unicode troubles In-Reply-To: <1172396593.18582.525.camel@trinidad> References: <1172396593.18582.525.camel@trinidad> Message-ID: > Hi Ties! Nothing beats a sunday morning bughunt! Aint that the truth! to clarify: as i understand it, the code just wants to circumvent the whole implementation dependent unicode troubles, by relying on char codes. This is fine, but this would mean that elephant db-ses encoded by one implementation in one character set can not be properly decoded by other implementations or the same implementation which are set to other encoding types. Also this forces a variable width format to fixed byte length, doubling strings in length if just one char is above the mean so to speak. I for one would rather reintroduce the unicode troubles by dispatching on string-type and then using something similar to, if not exactly the same as arnesi's string-to-octets and octets-to-string to encode and decode the string to bytes in stead of using char-code and code-char. This shouldn't be to hard to implement and would have the added bonus of making the code a lot cleaner. But then of course i just dont have the time atm to implement it, and it doesn't have so much priority for me, but if you wait half a year i'll send a patch. In the meantime i would in addition to henriks suggestion suggest to heighten the upper-limit for char-codes in serialize-to-utf8 from x7f to xff. E.g. this part: (etypecase string (simple-string (loop for i fixnum from 0 below characters do (let ((code (char-code (schar string i)))) (declare (type fixnum code)) (when (> code #xff) (fail)) (setf (uffi:deref-array buffer 'array-or-pointer-char (+ i size)) code)))) (string (loop for i fixnum from 0 below characters do (let ((code (char-code (char string i)))) (declare (type fixnum code)) (when (> code #xff) (fail)) (setf (uffi:deref-array buffer 'array-or-pointer-char (+ i size)) code))))) this will reduce the times you would need the two-byte encoding to almost never from where i'm sitting, and i don't see the point in having an upper limit of x7f. If your lisp doesn't support char-codes higher than x7f it won't try to encode them, and why not use all the room the byte has to offer. Or am i missing something? That's usually the case. greets, Ties From cjstuij at gmail.com Sun Feb 25 13:31:11 2007 From: cjstuij at gmail.com (Ties Stuij) Date: Sun, 25 Feb 2007 14:31:11 +0100 Subject: [elephant-devel] function move request Message-ID: i'm getting a symbol-not-available-or-something error the second-plus time i try to load elephant; specifically serializer1.lisp when it tries to intern translate-and-intern-symbol from the elephant package. This is because translate-and-intern-symbol resides in controller.lisp. which is not yet loaded and depends on serializer1.lisp. Could we perhaps move translate-and-intern-symbol to serializer.lisp for example so we circumvent this dependency problem? Greets, Ties From read at robertlread.net Sun Feb 25 15:13:19 2007 From: read at robertlread.net (Robert L. Read) Date: Sun, 25 Feb 2007 09:13:19 -0600 Subject: [elephant-devel] function move request In-Reply-To: References: Message-ID: <1172416399.18567.454.camel@localhost.localdomain> This is great work, gentlemen. I'm assuming that Ian will take care of this, as he has done most of the work for this release and did the serializer rewrite; but if for some reason he doesn't respond I'll try to take care of it. On Sun, 2007-02-25 at 14:31 +0100, Ties Stuij wrote: > i'm getting a symbol-not-available-or-something error the second-plus > time i try to load elephant; specifically serializer1.lisp when it > tries to intern translate-and-intern-symbol from the elephant package. > This is because translate-and-intern-symbol resides in > controller.lisp. which is not yet loaded and depends on > serializer1.lisp. Could we perhaps move translate-and-intern-symbol to > serializer.lisp for example so we circumvent this dependency problem? > > Greets, > Ties > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Sun Feb 25 19:28:53 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 25 Feb 2007 14:28:53 -0500 Subject: [elephant-devel] new elephant and unicode troubles In-Reply-To: References: <1172396593.18582.525.camel@trinidad> Message-ID: <9F2E5393-2955-47A5-BFE1-BF3BC6E87B07@csail.mit.edu> Character encodings and unicode give me headaches! Thanks Henrik for pointing out that bug. I should rename the UTF-8 function - to me it means UTF-8/16le/32le read-compatible, assuming that the underlying lisp is using ASCII or Unicode character codings. Ties, there was a legacy issue caused by a memutil commitment to char *'s which caused SBCL's alien package to barf on writing positive #xFF values to buffer-streams (Marco wrote about this in October or November). I recently rewrote buffer-streams and memutil so that everything was unsigned byte but forgot to propagate that to unicode2.lisp so we could encode 8-bit quantities in the 'utf-8' encoding function. I didn't think through the different code-char/char-code maps across lisps. Does someone with more familiarity want to explain that concisely to me? I'm very open to a better solution and there's no time like the present! In fact, I just put all post 0.6.1 open issues into Trac (http:// trac.common-lisp.net/elephant). Check out our new web pages too (http://www.common-lisp.net/project/elephant/). Would someone like to volunteer to write a ticket proposing what the right string encoding/decoding solution should look like and/or putting up a Wiki page so we can have a discussion there documenting all the good ideas? There are four constraints driving an encoding/decoding solution: 1) performance - every slot access, every symbol and object serialization and most cursor ops end up doing string encoding and decoding. The current approach should allow us to optimize the read path. While I haven't implemented this logic yet, for certain pairs of encodings and lisps, fixed length 8,16 or 32 bit strings can be cheaply copied into a known fixed-length internal format, (bypassing code-char) which should be very helpful for decoding-dominated cursor traversals (searching) that will be employed during querying. (That said, serialization is a small cost now compared to doing non- transactional read/writes where the sync to disk takes all the time). 2) Lisp and C - the encoded format must be parsable by the C sorting function used to compare on-disk BDB keys and values for BTree searching & insertion. Currently we use existing C library functions and some custom functions in libmemutil.c to do character by character encoding. This will get more complicated if we use variable-length encodings (proper UTF8) or other encodings that are incompatible with the C functions. I'm happy to do or support this work if it leads to a more elegant overall solution. 3) clarity - all the conditionals and complex dependencies determining a particular binary format were giving me headaches, and was the primary reason I did the rewrite. 4) compatibility - It would be useful if lisps could read other lisp's databases, but not critical. Perhaps tagging strings with the lisp version that created it and the external format would be a reasonable compromise so you'd get an incompatible-encoding condition instead of a corrupted string? Ties, I'll look into your circular dependency problem a little later today. Ian On Feb 25, 2007, at 7:58 AM, Ties Stuij wrote: >> Hi Ties! Nothing beats a sunday morning bughunt! > Aint that the truth! > > to clarify: > as i understand it, the code just wants to circumvent the whole > implementation dependent unicode troubles, by relying on char codes. > This is fine, but this would mean that elephant db-ses encoded by one > implementation in one character set can not be properly decoded by > other implementations or the same implementation which are set to > other encoding types. Also this forces a variable width format to > fixed byte length, doubling strings in length if just one char is > above the mean so to speak. > > I for one would rather reintroduce the unicode troubles by dispatching > on string-type and then using something similar to, if not exactly the > same as arnesi's string-to-octets and octets-to-string to encode and > decode the string to bytes in stead of using char-code and code-char. > This shouldn't be to hard to implement and would have the added bonus > of making the code a lot cleaner. > > But then of course i just dont have the time atm to implement it, and > it doesn't have so much priority for me, but if you wait half a year > i'll send a patch. > > In the meantime i would in addition to henriks suggestion suggest to > heighten the upper-limit for char-codes in serialize-to-utf8 from x7f > to xff. E.g. this part: > > (etypecase string > (simple-string > (loop for i fixnum from 0 below characters do > (let ((code (char-code (schar string i)))) > (declare (type fixnum code)) > (when (> code #xff) (fail)) > (setf (uffi:deref-array buffer > 'array-or-pointer-char (+ i size)) code)))) > (string > (loop for i fixnum from 0 below characters do > (let ((code (char-code (char string i)))) > (declare (type fixnum code)) > (when (> code #xff) (fail)) > (setf (uffi:deref-array buffer > 'array-or-pointer-char (+ i size)) code))))) > > this will reduce the times you would need the two-byte encoding to > almost never from where i'm sitting, and i don't see the point in > having an upper limit of x7f. If your lisp doesn't support char-codes > higher than x7f it won't try to encode them, and why not use all the > room the byte has to offer. Or am i missing something? That's usually > the case. > > greets, > Ties > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Sun Feb 25 19:53:12 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 25 Feb 2007 14:53:12 -0500 Subject: [elephant-devel] new elephant and unicode troubles In-Reply-To: <9F2E5393-2955-47A5-BFE1-BF3BC6E87B07@csail.mit.edu> References: <1172396593.18582.525.camel@trinidad> <9F2E5393-2955-47A5-BFE1-BF3BC6E87B07@csail.mit.edu> Message-ID: I should clarify - Trak has a built-in wiki. If you have a common- lisp.net account I can add you to our Trac system so you can edit the wiki pages. (Anyone can submit and comment on tickets, however) Ian On Feb 25, 2007, at 2:28 PM, Ian Eslick wrote: > Character encodings and unicode give me headaches! > > Thanks Henrik for pointing out that bug. I should rename the UTF-8 > function - to me it means UTF-8/16le/32le read-compatible, assuming > that the underlying lisp is using ASCII or Unicode character codings. > > Ties, there was a legacy issue caused by a memutil commitment to > char *'s which caused SBCL's alien package to barf on writing > positive #xFF values to buffer-streams (Marco wrote about this in > October or November). I recently rewrote buffer-streams and > memutil so that everything was unsigned byte but forgot to > propagate that to unicode2.lisp so we could encode 8-bit quantities > in the 'utf-8' encoding function. > > I didn't think through the different code-char/char-code maps > across lisps. Does someone with more familiarity want to explain > that concisely to me? I'm very open to a better solution and > there's no time like the present! > > In fact, I just put all post 0.6.1 open issues into Trac (http:// > trac.common-lisp.net/elephant). Check out our new web pages too > (http://www.common-lisp.net/project/elephant/). > > Would someone like to volunteer to write a ticket proposing what > the right string encoding/decoding solution should look like and/or > putting up a Wiki page so we can have a discussion there > documenting all the good ideas? > > There are four constraints driving an encoding/decoding solution: > > 1) performance - every slot access, every symbol and object > serialization and most cursor ops end up doing string encoding and > decoding. The current approach should allow us to optimize the > read path. While I haven't implemented this logic yet, for certain > pairs of encodings and lisps, fixed length 8,16 or 32 bit strings > can be cheaply copied into a known fixed-length internal format, > (bypassing code-char) which should be very helpful for decoding- > dominated cursor traversals (searching) that will be employed > during querying. (That said, serialization is a small cost now > compared to doing non-transactional read/writes where the sync to > disk takes all the time). > > 2) Lisp and C - the encoded format must be parsable by the C > sorting function used to compare on-disk BDB keys and values for > BTree searching & insertion. Currently we use existing C library > functions and some custom functions in libmemutil.c to do character > by character encoding. This will get more complicated if we use > variable-length encodings (proper UTF8) or other encodings that are > incompatible with the C functions. I'm happy to do or support this > work if it leads to a more elegant overall solution. > > 3) clarity - all the conditionals and complex dependencies > determining a particular binary format were giving me headaches, > and was the primary reason I did the rewrite. > > 4) compatibility - It would be useful if lisps could read other > lisp's databases, but not critical. Perhaps tagging strings with > the lisp version that created it and the external format would be a > reasonable compromise so you'd get an incompatible-encoding > condition instead of a corrupted string? > > Ties, I'll look into your circular dependency problem a little > later today. > > Ian > > On Feb 25, 2007, at 7:58 AM, Ties Stuij wrote: > >>> Hi Ties! Nothing beats a sunday morning bughunt! >> Aint that the truth! >> >> to clarify: >> as i understand it, the code just wants to circumvent the whole >> implementation dependent unicode troubles, by relying on char codes. >> This is fine, but this would mean that elephant db-ses encoded by one >> implementation in one character set can not be properly decoded by >> other implementations or the same implementation which are set to >> other encoding types. Also this forces a variable width format to >> fixed byte length, doubling strings in length if just one char is >> above the mean so to speak. >> >> I for one would rather reintroduce the unicode troubles by >> dispatching >> on string-type and then using something similar to, if not exactly >> the >> same as arnesi's string-to-octets and octets-to-string to encode and >> decode the string to bytes in stead of using char-code and code-char. >> This shouldn't be to hard to implement and would have the added bonus >> of making the code a lot cleaner. >> >> But then of course i just dont have the time atm to implement it, and >> it doesn't have so much priority for me, but if you wait half a year >> i'll send a patch. >> >> In the meantime i would in addition to henriks suggestion suggest to >> heighten the upper-limit for char-codes in serialize-to-utf8 from x7f >> to xff. E.g. this part: >> >> (etypecase string >> (simple-string >> (loop for i fixnum from 0 below characters do >> (let ((code (char-code (schar string i)))) >> (declare (type fixnum code)) >> (when (> code #xff) (fail)) >> (setf (uffi:deref-array buffer >> 'array-or-pointer-char (+ i size)) code)))) >> (string >> (loop for i fixnum from 0 below characters do >> (let ((code (char-code (char string i)))) >> (declare (type fixnum code)) >> (when (> code #xff) (fail)) >> (setf (uffi:deref-array buffer >> 'array-or-pointer-char (+ i size)) code))))) >> >> this will reduce the times you would need the two-byte encoding to >> almost never from where i'm sitting, and i don't see the point in >> having an upper limit of x7f. If your lisp doesn't support char-codes >> higher than x7f it won't try to encode them, and why not use all the >> room the byte has to offer. Or am i missing something? That's usually >> the case. >> >> greets, >> Ties >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Sun Feb 25 20:38:35 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 25 Feb 2007 15:38:35 -0500 Subject: [elephant-devel] function move request In-Reply-To: References: Message-ID: This and the prior unicode bugs should be fixed in the current HEAD. I verified this both on SBCL and on Allegro (Mac OS X) Ian On Feb 25, 2007, at 8:31 AM, Ties Stuij wrote: > i'm getting a symbol-not-available-or-something error the second-plus > time i try to load elephant; specifically serializer1.lisp when it > tries to intern translate-and-intern-symbol from the elephant package. > This is because translate-and-intern-symbol resides in > controller.lisp. which is not yet loaded and depends on > serializer1.lisp. Could we perhaps move translate-and-intern-symbol to > serializer.lisp for example so we circumvent this dependency problem? > > Greets, > Ties > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From gorbatovsky at gmail.com Mon Feb 26 00:14:02 2007 From: gorbatovsky at gmail.com (Dmitry V. Gorbatovsky) Date: Mon, 26 Feb 2007 02:14:02 +0200 Subject: [elephant-devel] current state of threading Message-ID: <200702260214.02764.dg@midasitech.com> Hello, I am doing a server side of application on linux/sbcl . May I ask an information update on current state of threading . Specifically about "simple" threaded reading from BDB . Sorry, I can't get it from "Elephant User Manual". Just a basic clue would be sufficient. Thanks beforehand. Regards, Dmitry -- Dmitry V. Gorbatovsky From eslick at csail.mit.edu Mon Feb 26 01:45:51 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 25 Feb 2007 20:45:51 -0500 Subject: [elephant-devel] current state of threading In-Reply-To: <200702260214.02764.dg@midasitech.com> References: <200702260214.02764.dg@midasitech.com> Message-ID: <0640FA0C-55C3-4138-98BD-D455B9A3FA30@csail.mit.edu> The upcoming release (0.6.1) should make multi-threading easy. The 0.6.0 release is not thread safe. We'll be updating the manuals on this shortly. In 0.6.1, as long as you are only using a single store controller and perform transactions using with-transaction you should be good to go. If you are using multiple stores, you'll need to worry about a few more things which I can document for you. Store controllers can now be safely shared across threads. The current HEAD is pretty stable, if you want to download it from CVS and give it a try. Ian On Feb 25, 2007, at 7:14 PM, Dmitry V. Gorbatovsky wrote: > Hello, > I am doing a server side of application on linux/sbcl . > May I ask an information update on current state > of threading . Specifically about "simple" threaded > reading from BDB . > Sorry, I can't get it from "Elephant User Manual". > Just a basic clue would be sufficient. > > Thanks beforehand. > Regards, Dmitry > > -- > Dmitry V. Gorbatovsky > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From eslick at csail.mit.edu Mon Feb 26 05:59:55 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 26 Feb 2007 00:59:55 -0500 Subject: [elephant-devel] Testing In-Reply-To: <417904812@web.de> References: <417904812@web.de> Message-ID: <56705235-243A-4550-803C-2C8B6264871C@csail.mit.edu> Ok, I got myself a windows installation and set it up only to get to the same point you're at. I have no idea what's going on with db.h either. I'll try looking at this again tomorrow. You know, I switched to Mac OS because I hated working with cygwin under MS Windows... :) On Feb 19, 2007, at 6:20 PM, Frank Schorr wrote: > I haven't really understood what happens when a dll is built with > cygwin. > dlltool generates the .def file and the exports.o used in the > next gcc step. See > http://www.gnu.org/software/binutils/manual/html_chapter/ > binutils_13.html > http://www.cygwin.com/cygwin-ug-net/dll.html > > > I was able to get a libmemutil.dll without errors by: > > gcc -mno-cygwin -mwindows -std=c99 -c libmemutil.c > dlltool -z libmeutil.def --export-all-symbols -e exports.o -l > libmemutil.lib libmemutil.o > gcc -shared -mno-cygwin -mwindows libmemutil.o exports.o -o > libmemutil.dll > > > A while ago, when I made the dlls for elephant 0.6.0, my first try > was MSVC, guided by > http://bc.tech.coop/blog/041007.html > However, the available free MSVC appeared to have no preset dll- > project any more. > I had to try compiler switches ... and found cygwin easier. > This should mean that not every lisp-on-windows-user has > MSVC installed (and is able to use it. cygwin is easy to install). > > Best regards, > Frank > >> -----Urspr?ngliche Nachricht----- >> Von: Elephant bugs and development >> Gesendet: 19.02.07 21:26:09 >> An: Elephant bugs and development >> Betreff: Re: [elephant-devel] Testing > > >> Thanks for trying that. Do you know if there's a way with the cygwin >> gcc compiler to use a .def file instead of generating a .o with the >> exports? I'm pretty sure MSVC has one. We'll also need a set of >> build commands for MSVC... >> >> I suspect we may have broken the build of libmemutil when we included >> sys/types to get access to u_int64 and u_int32, etc. Without a >> local system to play with I'm not sure I can debug this. I guess the >> thing to do is look at db.h and sys/types to try to figure out what >> was intended and whether they're compatible. >> >> I'll see about getting access to a Windows box to try to reproduce >> and test these things on my side. >> >> Thanks, >> Ian >> >> On Feb 19, 2007, at 2:09 PM, Frank Schorr wrote: >> >>> >>> gcc -shared -mno-cygwin -mwindows -std=c99 --export-all-symbols >>> libberkeley-db.def libberkeley-db.c -o libberkeley-db.dll >>> >>> produces >>> >>> cc1: error: unrecognized command line option "-fexport-all-symbols" >>> >>> Further: >>> >>> gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/ >>> Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ >>> 4.5.20/include/ libberkeley-db.c >>> >>> produces >>> >>> In file included from libberkeley-db.c:165: >>> /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: >>> conflicting types >>> for 'ssize_t' >>> /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/ >>> include/sys/types >>> .h:104: error: previous declaration of 'ssize_t' was here >>> libberkeley-db.c: In function `case_cmp': >>> libberkeley-db.c:1233: warning: implicit declaration of function >>> `_strnicmp' >>> >>> Hope this can help >>> Please let me know what to do next. >>> Frank >>> > ______________________________________________________________________ > ____ > Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail- > Postfach! > Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131 > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From franks-muc at web.de Mon Feb 26 21:56:44 2007 From: franks-muc at web.de (Frank Schorr) Date: Mon, 26 Feb 2007 22:56:44 +0100 Subject: [elephant-devel] Message-ID: <427761054@web.de> I saw the changes to elephant.asd directed to mswindows and had a try with ACL 8 Free Edition. run-shell-command generated an error because the output stream was the lisp listener pane what is not allowed ?? The docs say that excl.osi:command-output should be used now. It also allows to set the current working directory for gcc. This creates libmemutil.o in the same directory where .c is (correct ?): (let ((command (format nil "~A ~{~A ~}" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (format nil "\"~A\"" (namestring pathname)) :output-file nil :library nil)))) (multiple-value-bind (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory (directory-namestring pathname)) (unless (zerop exit-status) (error 'operation-error :component c :operation o)))) ,replacing: (unless (zerop (run-shell-command ... checked: If gcc reports an error exit-status is not 0, stdout-lines, stderr-lines and commandd can be inspected. excl.osi:command-output is ACL specific. LispWorks doesn't have it. I will try LW tomorrow, now it's late. Frank _______________________________________________________________________ Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 From eslick at csail.mit.edu Mon Feb 26 23:59:25 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 26 Feb 2007 18:59:25 -0500 Subject: [elephant-devel] In-Reply-To: <427761054@web.de> References: <427761054@web.de> Message-ID: <54C345A8-733A-4FC8-8671-C269D15E3278@csail.mit.edu> Yes it should. I think I got that to work but am stuck on the libberkeley-db for the db-bdb backend with cygwin. I spent a little time today looking into free msvc tools as an alternate compile path. There are some issues with building berkeley db with cygwin and now compile issues with libberkeley-db.c (lots of errors with db.h, I have no idea what that is about). I can test ACL 8.0 on Windows if you get it to work on your end. Ian On Feb 26, 2007, at 4:56 PM, Frank Schorr wrote: > I saw the changes to elephant.asd directed to mswindows and had a > try with ACL 8 Free Edition. > > run-shell-command generated an error because the output stream was > the lisp listener pane what is not allowed ?? > > The docs say that excl.osi:command-output should be used now. > It also allows to set the current working directory for gcc. > > This creates libmemutil.o in the same directory where .c is > (correct ?): > > (let ((command (format nil "~A ~{~A ~}" > (c-compiler-path c) > (compiler-options (c-compiler c) c > :input-file (format nil "\"~A > \"" (namestring pathname)) > :output-file nil > :library nil)))) > (multiple-value-bind (stdout-lines stderr-lines exit-status) > (excl.osi:command-output command :directory (directory- > namestring pathname)) > (unless (zerop exit-status) > (error 'operation-error :component c :operation o)))) > > ,replacing: (unless (zerop (run-shell-command ... > > checked: If gcc reports an error exit-status is not 0, > stdout-lines, stderr-lines and commandd can be inspected. > > excl.osi:command-output is ACL specific. LispWorks doesn't have it. > I will try LW tomorrow, now it's late. > > Frank > > > ______________________________________________________________________ > _ > Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und > kostenlos. > Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From franks-muc at web.de Tue Feb 27 12:11:33 2007 From: franks-muc at web.de (Frank Schorr) Date: Tue, 27 Feb 2007 13:11:33 +0100 Subject: [elephant-devel] windows/cygwin Message-ID: <428403249@web.de> > path. There are some issues with building berkeley db with cygwin > and now compile issues with libberkeley-db.c (lots of errors with > db.h, I have no idea what that is about). To prevent a misundestanding: I had installed bdb 4.4 (and now 4.5) under windows, after downloading the ".msi windows installer". So bdb was not built under cygwin and is a pure windows thing. I used cygwin only as a provider of the gcc compiler. The switch -mno-cygwin tells the compiler to not link to a "cygwin.dll", i.e. the resulting program/dll will not be a cygwin program. The switch -mwindows instructs to link to neccessary windows libraries. May be -mwindows can be omitted. Frank __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131 From franks-muc at web.de Tue Feb 27 23:07:30 2007 From: franks-muc at web.de (Frank Schorr) Date: Wed, 28 Feb 2007 00:07:30 +0100 Subject: [elephant-devel] Test on windows + ACL Message-ID: <429244679@web.de> On mswin and ACL 8 trial: (asdf:operate 'asdf:load-op :elephant) (asdf:operate 'asdf:load-op :ele-bdb) (asdf:operate 'asdf:load-op :elephant-tests) (do-backend-tests '(:BDB "c:/temp/testbdb/")) Doing 124 pending tests of 124 tests total. FIXNUMS FIXNUM-TYPE-1 READ-32-BIT-FIXNUM READ-64-BIT-FIXNUM WRITE-32-BIT-FIXNUM WRITE-64-BIT-FIXNUM BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS HARD-STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 ARRAYS-2 TEST-DEEP-EQUALP OBJECTS STRUCTS STRUCT-NON-STD-CONSTRUCT CIRCULAR PERSISTENT NON-TRANSIENT-CLASS-SLOT-1 NON-TRANSIENT-CLASS-SLOT-2 TRANSIENT-CLASS-SLOT CLASS-DEFINERS BAD-INHERITENCE MIXES MIXES-RIGHT-SLOTS INHERIT INHERIT-RIGHT-SLOTS INITFORM-CLASSES INITFORM-TEST INITARG-TEST NO-EVAL-INITFORM REDEFCLASS MAKUNBOUND UPDATE-CLASS CHANGE-CLASS CHANGE-CLASS3 BASICPERSISTENCE TESTOID BTREE-MAKE BTREE-PUT BTREE-GET REMOVE-KV REMOVED MAP-BTREE INDEXED-BTREE-MAKE ADD-INDICES TEST-INDICES INDEXED-PUT INDEXED-GET SIMPLE-SLOT-GET INDEXED-GET-FROM-SLOT1 INDEXED-GET-FROM-SLOT2 REMOVE-KV-INDEXED NO-KEY-NOR-INDICES REMOVE-KV-FROM-SLOT1 NO-KEY-NOR-INDICES-SLOT1 REMOVE-KV-FROM-SLOT2 NO-KEY-NOR-INDICES-SLOT2 MAP-INDEXED GET-FIRST GET-FIRST2 GET-LAST GET-LAST2 SET SET2 SET-RANGE SET-RANGE2 MAP-INDEXED-INDEX REM-KV REM-IDEXKV MAKE-INDEXED2 ADD-INDICES2 PUT-INDEXED2 GET-INDEXED2 GET-FROM-INDEX3 DUP-TEST NODUP-TEST PREV-NODUP-TEST PNODUP-TEST PPREV-NODUP-TEST CUR-DEL1 INDEXED-DELETE TEST-DELETED INDEXED-DELETE2 TEST-DELETED2 CUR-DEL2 GET-BOTH PGET-BOTH PGET-BOTH-RANGE PCURSOR NEWINDEX PCURSOR2 ADD-GET-REMOVE ADD-GET-REMOVE-SYMBOL EXISTSP Warning: Manually finalizing class IDX-ONE DISABLE-CLASS-INDEXING-TEST INDEXING-BASIC-TRIVIAL INDEXING-BASIC INDEXING-INHERIT INDEXING-RANGE INDEXING-SLOT-MAKUNBOUND Warning: Manually finalizing class IDX-FIVE-DEL INDEXING-WIPE-INDEX INDEXING-RECONNECT-DB INDEXING-CHANGE-CLASS INDEXING-REDEF-CLASS Warning: Manually finalizing class STRESS-INDEX Ranged get of 10/700 objects = Linear: 0.671 sec Indexed: 0.02 sec INDEXING-TIMING Single store mode: ignoring REMOVE-ELEMENT Single store mode: ignoring MIGRATE-BASIC Single store mode: ignoring MIGRATE-BTREE Single store mode: ignoring MIGRATE-IDX-BTREE Single store mode: ignoring MIGRATE-PCLASS Single store mode: ignoring MIGRATE-IPCLASS PREPARES-BDB TEST-SEQ1 TEST-SEQ2 CLEANSUP-BDB No tests failed. T This is what I did: in elephant.asd: the run-shell-command generated this error, which is strange since output stream was not defined. Error: stream # can't be used as output [condition type: SIMPLE-ERROR] I used excl.osi:command-output. The following perform makes libmemutil.dll in the correct directory (where memutil.fasl is) (defmethod perform ((o compile-op) (c elephant-c-source)) "Run the appropriate compiler for this platform on the source, getting the specific options from 'compiler-options method. Default options can be overridden or augmented by subclass methods" #+(or mswindows windows) (progn (let* ((pathname (component-pathname c)) (directory (directory-namestring pathname))) (let ((command (format nil "~A ~{~A ~}" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (format nil "\"~A\"" (namestring pathname)) :output-file nil :library nil)))) (multiple-value-bind (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory) (unless (zerop exit-status) (error 'operation-error :component c :operation o)))) (let ((command (format nil "dlltool -z ~A --export-all-symbols -e exports.o -l ~A ~A" (format nil "\"~A\"" (namestring (make-pathname :type "def" :defaults pathname))) (format nil "\"~A\"" (namestring (make-pathname :type "lib" :defaults pathname))) (format nil "\"~A\"" (namestring (make-pathname :type "o" :defaults pathname)))))) (multiple-value-bind (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory) (unless (zerop exit-status) (error 'operation-error :component c :operation o)))) (let ((command (format nil "~A ~{~A ~}" ;; -I~A -L~A -l~A" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (list (format nil "\"~A\"" (namestring (make-pathname :type "o" :defaults pathname))) "exports.o") :output-file (format nil "\"~A\"" (first (output-files o c))) :library t)))) (multiple-value-bind (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory) (unless (zerop exit-status) (error 'operation-error :component c :operation o)))))) #-(or mswindows windows) (unless (zerop (run-shell-command "~A ~{~A ~}" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (namestring (component-pathname c)) :output-file (namestring (first (output-files o c)))))) (error 'operation-error :component c :operation o))) The compiler options are not correct for libberkeley-db.dll. Since I did not undestand the concept, I did not try to amend the method further. I changed (defmethod compiler-options ((compiler (eql :cygwin)) (c elephant-c-source) &key input-file output-file library &allow-other-keys) (unless (or input-file output-file) (error "Must specify at least one of output and input files")) ..... Since there is no output file sometimes. This produced a correct libberkeley-db.dll: gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/include/ libberkeley-db.c dlltool -z libberkeley-db.def --export-all-symbols -e exports.o -l libberkeley-db.lib libberkeley-db.o gcc -shared -mno-cygwin -mwindows -L/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/bin/ -llibdb45 libberkeley-db.o exports.o -o libberkeley-db.dll At first, there was this error: In file included from libberkeley-db.c:165: /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: conflicting types for 'ssize_t' /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/types .h:104: error: previous declaration of 'ssize_t' was here I commented these lines out in C:\cygwin\usr\include\mingw\sys\types.h: /* *#ifndef _SSIZE_T_ *#define _SSIZE_T_ *typedef long _ssize_t; * *#ifndef _NO_OLDNAMES *typedef _ssize_t ssize_t; *#endif *#endif * Not _SSIZE_T_ * */ apparently this this did not cooperate with #ifdef _WIN64 typedef int64_t ssize_t; #else typedef int32_t ssize_t; #endif in db.h. There is one remaining warning: libberkeley-db.c: In function `case_cmp': libberkeley-db.c:1233: warning: implicit declaration of function `_strnicmp' Now, doing (do-backend-tests '(:BDB "c:/temp/testbdb/")) a second or third ... time produces this: 1 out of 124 total tests failed: INDEXING-WIPE-INDEX. NIL When I delete all files in "c:/temp/testbdb/" the first test is ok, second has 1 out of 124 failed. Elephant is nearly ready for mswin !!! Frank ______________________________________________________________________ XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130 From eslick at csail.mit.edu Wed Feb 28 22:30:43 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 28 Feb 2007 17:30:43 -0500 Subject: [elephant-devel] Querying Advice In-Reply-To: <8645F361-ABE9-4811-B550-22474804C31F@infoway.net> References: <948E9C76-5F70-4245-9697-A59E50ABF9D6@infoway.net> <1163364527.5145.244.camel@localhost.localdomain> <3D430634-748D-44BE-9B44-A8EB5AB5EBAB@infoway.net> <4558003C.2070104@csail.mit.edu> <88B23BCB-2A6C-4943-91E4-2F9CDC48C4C0@infoway.net> <4558670D.5090701@csail.mit.edu> <38E9823B-E4BD-4380-987B-8C33FFE252DE@infoway.net> <1163431348.5145.342.camel@localhost.localdomain> <20061114130803.GR12538@bateleur.arcanes.fr.eu.org> <4559CCE8.4050408@csail.mit.edu> <0A06D50B-317F-4682-8117-4482A46026B2@infoway.net> <455B00FA.6090206@csail.mit.edu> <8645F361-ABE9-4811-B550-22474804C31F@infoway.net> Message-ID: Daniel, Not sure if you're still interested, but I got motivated to start thinking about a query strategy for Elephant. I have a much more sophisticated version I'll check into contrib/eslick/queries in a day or two, but my first experimental hack can be found in the main elephant directory in query.lisp and query-example.lisp. They're not loaded by default in the .asd file so if you want to play with them load them manually and check out the queries in query- example.lisp. I'm changing the constraint syntax in the new version, but I'd be interested in any feedback that query.lisp might generate. This version does not support join constraints (the returned instances being filtered based on a constrained subset of instances of another class). The plan is to provide a little syntax language and a map interface that calls a function on each instance of the instances that satisfy the query. The goal of this approach is to avoid having to load all objects into memory by default. I'm not sure yet if this map will allow for side effects (remove all objects satisfying the query) unless we have a special header that says 'delete these' so we can use the underlying cursor-del function. The constraint language should be extensible, ultimately, but I've been fighting with syntax and semantics for awhile so am going to put that off. So the query process is: - Parse syntax into a constraint graph - Transform constraint graph into a query planning graph - Find an efficient (optimal?) query plan - Execute plan (interpreted) Once the syntax, graphs and planner is cleanly fleshed out, it should be easy to perform the first three steps inside a macro and generate compiled code from the query plan instead of interpreting it at run time. If anyone is interested in having a deeper discussion on this, we can put it up on the new Trac Wiki (see link from new web page). Cheers, Ian PS - This is a distraction from chasing the platform bugs related to getting 0.6.1 wrapped up. If anyone wants to move the 0.6.1 release along, you could work on OpenMCL integration, adding a few features to migration or adding a couple of simple tests (see TODO file in elephant root directory). On Nov 15, 2006, at 12:16 PM, Daniel Salama wrote: > Ian, > > Thank you for the detailed explanation. > > I think, at least, I was under the impression that Elephant was an > ODB. At least, that's how the first sentence of the web site > presents it: "Elephant is an object database for Common Lisp" :) > Maybe this could confuse other newcomers so you may want to revisit > the web site. > > Now, under the understanding that it is a framework to > "transparently" persist data, it makes it more apparent that any > object model needs to be done in Lisp and in memory and Elephant > will simply aid in persist the data in Lisp's memory (at least that > which you want to persist). > > Going back to all this email thread, makes me wonder, which > direction do you/we all want Elephant to go to. In your email you > mention that it would be nice to incorporation some ODB-like > features into Elephant. Well, I think the approach to query data > may be affected as to the direction we want to take. If we just > have a framework to query data, it will serve one purpose. If we > incorporate a "layer or two" to make it more ODB-like, that could > change the panorama of where Elephant goes, potentially involving > changes to DCM and also whatever querying framework is "developed". > After all, it could end up looking something like CL-SQL with the > ability to _also_ use BDB as the backend :) > > As for the indexing and deletion, it makes more sense. I still need > to understand better how class and slot indices work. From your > explanation, it seems as if the Elephant machinery is automatically > creating these BTree indices on the class/slots. I will look into > the code for the get-instance* methods to learn more how it works > behind the scenes (I suppose that's more like the Lispy mentality > of learning by looking at the library's source code - something > which I still need to get used to) > > Will probably bother more later as questions/concerns come up. > However, as I mentioned before, I'd like to contribute to the > project, specially in the querying layer/framework and possibly, if > that's where we go, the ODB layer(s). I just need to know what will > be the direction we want to go. > > Thanks again, > Daniel > > On Nov 15, 2006, at 6:58 AM, Ian Eslick wrote: > >> Daniel, >> >> There are a couple of things about the Elephant model that should be >> made clear. Elephant is not a very high level DB system. It's >> focus is >> persistence of data. In effect, it is a collection of indexing >> mechanisms and a metaobject protocol that helps us to store/retrieve >> data. There are three ways to persist data. >> >> 1) Put it in the root, or another BTree that you have manually >> created >> and put in the rot >> 2) Create a persistent object. A persistent object has two >> manifestations: >> a) A stub containing an OID and a reference to the controller >> the >> object is stored in >> b) A set of slot values stored in a master slot-value BTree >> >> When you do a slot access, the OID and slot name are used to go into >> this (hidden) master slot-value BTree to find the actual slot value. >> This is done as a tradeoff so if you are writing an integer slot >> in an >> object with a large string, you don't have to load that string into >> memory to get ACID properties on that integer slot. >> >> When you load a persistent object from the root or another index, all >> that is loaded into memory is the stub. All slot accesses go >> independently back to the on-disk store to get their values. This >> means >> that the on-disk value and locking together guarantee that any >> number of >> processes or threads within a process can use the same Elephant store >> and guarantee ACID semantics (BDB & SQL handle locking for us). For >> most lisp applications with a single image, bookkeeping like Robert's >> system make more sense, but you have to worry about locking yourself. >> DCM pre-loads all the slot values but updates the on-disk version on >> writes for CID properties - atomicity has to be explicitly managed. >> We're hoping to make slot caching a natural feature of elephant >> eventually. >> >> 3) Use slot and class indices. Underneath, this is just #1 with >> functions to make the BTrees simple to use. When you created an >> indexed >> object, the object is added to a BTree and a secondary index is >> created >> for slot values on top of the master slot-value index. It's the >> class >> index that guarantees you can reach the object. >> >> Now if you are hacking on elephant, this is the mental model you >> need. >> Eventually we're hoping that it becomes sophisticated enough you >> rarely >> need this level of detail (query language, flexible persistence >> semantics, etc). However the persistence of lisp values and the >> persistent vs. normal class objects means it will never be perfect. >> >> Manual deletions are actually quite hard to do in such a system, >> because >> if you delete an object and forget to delete the references then >> you end >> up with a corrupted data representation that will fail silently >> (return >> garbage or null slot values) if you reload a reference. Also >> deleting >> an object means removing it from all referring data structures and >> also >> deleting (separately) each slot value. Thus the only safe method of >> deletion is GC which is not yet implemented except by manually >> migrating >> your DB which copies everything reachable from root & class-root. >> I'm a >> little worried for large DBs that GC can't happen when the DB >> itself is >> some factor larger than the available working memory. I know how >> to fix >> that, but it's a little involved. >> >> Some more comments below. >> >> PS - All BDB log files start out at 10MB. They store bookkeeping >> information so take up more room than you might expect from the >> stored >> data itself. >> >> Daniel Salama wrote: >>> Ian et al, >>> >>> Based on my comment to Robert and that of Pierre, could you, or >>> anyone, please clarify this for me (and maybe others): >>> >>> If making a class persistent means that there is no need to add >>> it to >>> root or to any persistent collection, when I look at Robert's sample >>> code, I see (excerpts): >>> >>> (defclass User () >>> ((username :type 'string :initform "" :initarg :uname :accessor >>> username-of) >>> (password :type 'string :initform "" :initarg :pword :accessor >>> password-of) >>> (email :type 'string :initform "" :initarg :email :accessor >>> email-of) >>> (fullname :type 'string :initform "" :initarg :fullname :accessor >>> fullname-of) >>> (balance :type 'integer :initform 0 :initarg :balance :accessor >>> balance-of))) >>> >>> (defun random-users (n) >>> (dotimes (x n) >>> (let ((u (make-instance >>> 'User >>> :uname (format nil "user~A" x) >>> :pword (random-password) >>> :email (format nil "user~A at .nowheresville.org" x) >>> :fullname (format nil "~A~A ~A~A" (random-password) x >>> (random-password) x) >>> :balance (random 100)))) >>> (add-to-root x u)))) >>> >>> There is an explicit add-to-root in random-users. I suppose the >>> reason >>> for this is because User class does not inherit from >>> persistent-metaclass and in order to be able to "search for" or >>> retrieve that object (could this also be the reason for the >>> additional >>> storage overhead, as you pointed out yesterday?). Right? So, if my >>> understanding is correct, defining User with defpclass instead would >>> mean that you don't have to add-to-root because it will be >>> automatically persisted. However, after the function exits, there >>> will >>> be no reference to that persistent object and will therefore be >>> eventually garbage collected (whether or not the persistent space >>> will >>> be reclaimed is a different story, as you mentioned in your >>> email). Is >>> that right? If so, how could I avoid for the User objects to be >>> garbage collected in this case, since there really is no other >>> reference to these objects after creating them? Or, if the >>> objects are >>> NOT garbage collected, how could I manually "delete" any of them? >>> >>> Now, if I (or Robert) had defined the User class as: >>> >>> (defpclass User () >>> ((username :type 'string :initform "" :initarg :uname :accessor >>> username-of :index t) >>> (password :type 'string :initform "" :initarg :pword :accessor >>> password-of) >>> (email :type 'string :initform "" :initarg :email :accessor >>> email-of) >>> (fullname :type 'string :initform "" :initarg :fullname :accessor >>> fullname-of) >>> (balance :type 'integer :initform 0 :initarg :balance :accessor >>> balance-of))) >>> >>> where (notice how it's defined with defpclass) the username slot is >>> indexed, the system would automatically store a reference to the >>> object in the slot index, and there would be no need to use the >>> add-to-root in random-users. Correct? If that's the case, how >>> would I >>> then go about removing this user object from persistence? Would >>> it be >>> by setting the indexed slot value to NIL? >> See above. >>> On another note, if I want to create a collection of users, I don't >>> have to store these users in a collection. Simply making them >>> inherit >>> from persistent-metaclass and indexing them would do so >>> automatically >>> (just like the example above). Right? How about this, then: >>> >>> (asdf:operate 'asdf:load-op :elephant-tests) >>> >>> (in-package :elephant-tests) >>> >>> (setf *default-spec* *testbdb-spec*) >>> >>> (open-store *default-spec*) >>> >>> (defpclass state () >>> ((abbr :type 'string :initform "" :initarg :abbr :accessor abbr-of >>> :index t) >>> (name :type 'string :initform "" :initarg :name :accessor name- >>> of))) >>> >>> (defpclass zip-code () >>> ((zip :type 'string :initform "" :initarg :zip :accessor zip-of >>> :index t) >>> (city :type 'string :initform "" :initarg :city :accessor city- >>> of) >>> (county :type 'string :initform "" :initarg :county :accessor >>> county-of) >>> (state :initform nil :initarg :state :accessor state-of))) >>> >>> (defmethod print-object ((obj state) stream) >>> (format stream "State (abbr, name) = (~A, ~A)" (abbr-of obj) >>> (name-of obj))) >>> >>> (defmethod print-object ((obj zip-code) stream) >>> (format stream "Zip (zip, city, county, state) = (~A, ~A, ~A, ~A)" >>> (zip-of obj) (city-of obj) (county-of obj) (state-of >>> obj))) >>> >>> (let* ((s1 (make-instance 'state :abbr "FL" :name "Florida")) >>> (s2 (make-instance 'state :abbr "NY" :name "New York")) >>> (z1 (make-instance 'zip-code :zip "33015" :city >>> "Miami" :county >>> "Dade" :state s1)) >>> (z2 (make-instance 'zip-code :zip "13605" :city >>> "Adams" :county >>> "Jefferson" :state s2)) >>> (z2 (make-instance 'zip-code :zip "33160" :city "Sunny Isles >>> Beach" :county "Dade" :state s1))) >>> (print s1) >>> (print s2) >>> (print z1) >>> (print z2) >>> (print z3)) >>> >>> Here, I'm creating a couple of state objects and a couple of zip- >>> code >>> objects. Since a zip-code can only belong to one state, they have a >>> reference back to the state in order to "quickly" determine the >>> state >>> they belong to. >>> >>> A couple of questions/comments here: >>> >>> 1) If I wanted to ask a state to give me all the zip-code(s) within >>> it, would I create a slot in the state class to hold a collection of >>> zip-code references? Or would I simply create a state-class >>> method like: >>> >>> (defmethod get-zip-codes ((obj state)) >>> (get-instances-by-value 'zip-code 'state obj)) >>> >>> This does not work because the state slot in zip-code is not >>> indexed. >>> Also, from the code above, I don't know how to get a reference to >>> the >>> btree in order to create a cursor so that I can linearly traverse >>> the >>> zip-code(s) to return only those zip-code(s) which belong to that >>> state. >> Yes, you have to decide what queries you want to do and make trade- >> offs >> between space and time. Of course it's easy to make the decision >> "lots >> of zip codes, small ranges in queries, large number of zip codes per >> state = index OR moderate # zip codes, large ranges per state, small >> number of states = add a slot and use a list or array" Then you >> add the >> :index marker to the zip code or add a new slot to state to keep >> track >> of the association. There is no general notion of association as >> you'll >> see below. However that might be a nice thing to add - you start >> to get >> relational notion into the simple object persistence model. >> >> I guess that's the confusion. Elephant is NOT an object database >> - it >> is a persistent object and collection facility. The DB functionality >> you (today) have to write yourself. It might be nice to add a >> layer or >> two that makes it more ODB like. But as Robert has done with DCM >> - you >> can craft an object/storage model that works for your application. >> Keeping references to objects in slots is an implicit DB but it does >> require that you think in a way that RDB's do not. >>> Of course, I would probably want to index the state slot of zip-code >>> because there are tens of thousands of zip codes and I wouldn't want >>> to linearly traverse them, but I just wanted to illustrate the >>> problem >>> to get some additional feedback (the overhead of maintaining a >>> secondary index on state wouldn't matter too much to me because >>> changes to this class/objects are very rare but access is much more >>> frequent) >>> >>> 2) Maybe this is a totally different issue and mainly caused by my >>> lisp ignorance: >>> >>> If I have: >>> >>> (defparameter *s1* (get-instances-by-value 'state 'abbr "FL")) >>> (defparameter *s2* (get-instances-by-value 'state 'abbr "NY")) >>> (defparameter *z1* (get-instances-by-value 'zip-code 'zip "33015")) >>> (defparameter *z2* (get-instances-by-value 'zip-code 'zip "13605")) >>> (defparameter *z3* (get-instances-by-value 'zip-code 'zip "33160")) >>> >>> and I want to remove the association of zip code 33160 from the "FL" >>> state object, I would think all I have to do is: >>> >>> (setf (state-of *z3*) nil) >> First problem here is that get-instances (note the plural) returns a >> list. However that will work. You orphan the zip code by removing >> it's reference to a state. However there is a singular function that >> returns the first instance or nil. >> >> (defparameter *z3* (get-instance-by-value 'zip-code 'zip "13605))) >> >> (setf (state-of *z3*) nil) > From eslick at csail.mit.edu Wed Feb 28 22:31:20 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 28 Feb 2007 17:31:20 -0500 Subject: [elephant-devel] Test on windows + ACL In-Reply-To: <429244679@web.de> References: <429244679@web.de> Message-ID: <320883EA-66DD-4870-8570-21755CE72367@csail.mit.edu> Frank, Outstanding! Thank you. I'll test it locally and promote some patches in a day or two. Cheers, Ian On Feb 27, 2007, at 6:07 PM, Frank Schorr wrote: > On mswin and ACL 8 trial: > > (asdf:operate 'asdf:load-op :elephant) > (asdf:operate 'asdf:load-op :ele-bdb) > (asdf:operate 'asdf:load-op :elephant-tests) > (do-backend-tests '(:BDB "c:/temp/testbdb/")) > > Doing 124 pending tests of 124 tests total. > FIXNUMS FIXNUM-TYPE-1 READ-32-BIT-FIXNUM READ-64-BIT-FIXNUM > WRITE-32-BIT-FIXNUM WRITE-64-BIT-FIXNUM BIGNUMS FLOATS RATIONALS > BASE-STRINGS STRINGS > HARD-STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH- > TABLES-2 ARRAYS-1 ARRAYS-2 TEST-DEEP-EQUALP OBJECTS STRUCTS STRUCT- > NON-STD-CONSTRUCT > CIRCULAR PERSISTENT NON-TRANSIENT-CLASS-SLOT-1 NON-TRANSIENT-CLASS- > SLOT-2 TRANSIENT-CLASS-SLOT CLASS-DEFINERS BAD-INHERITENCE MIXES > MIXES-RIGHT-SLOTS > INHERIT INHERIT-RIGHT-SLOTS INITFORM-CLASSES INITFORM-TEST INITARG- > TEST NO-EVAL-INITFORM REDEFCLASS MAKUNBOUND UPDATE-CLASS CHANGE- > CLASS CHANGE-CLASS3 > BASICPERSISTENCE TESTOID BTREE-MAKE BTREE-PUT BTREE-GET REMOVE-KV > REMOVED MAP-BTREE INDEXED-BTREE-MAKE ADD-INDICES TEST-INDICES > INDEXED-PUT INDEXED-GET > SIMPLE-SLOT-GET INDEXED-GET-FROM-SLOT1 INDEXED-GET-FROM-SLOT2 > REMOVE-KV-INDEXED NO-KEY-NOR-INDICES REMOVE-KV-FROM-SLOT1 NO-KEY- > NOR-INDICES-SLOT1 > REMOVE-KV-FROM-SLOT2 NO-KEY-NOR-INDICES-SLOT2 MAP-INDEXED GET- > FIRST GET-FIRST2 GET-LAST GET-LAST2 SET SET2 SET-RANGE SET-RANGE2 > MAP-INDEXED-INDEX > REM-KV REM-IDEXKV MAKE-INDEXED2 ADD-INDICES2 PUT-INDEXED2 GET- > INDEXED2 GET-FROM-INDEX3 DUP-TEST NODUP-TEST PREV-NODUP-TEST PNODUP- > TEST PPREV-NODUP-TEST > CUR-DEL1 INDEXED-DELETE TEST-DELETED INDEXED-DELETE2 TEST-DELETED2 > CUR-DEL2 GET-BOTH PGET-BOTH PGET-BOTH-RANGE PCURSOR NEWINDEX > PCURSOR2 ADD-GET-REMOVE > ADD-GET-REMOVE-SYMBOL EXISTSP > Warning: Manually finalizing class IDX-ONE > DISABLE-CLASS-INDEXING-TEST INDEXING-BASIC-TRIVIAL INDEXING-BASIC > INDEXING-INHERIT INDEXING-RANGE INDEXING-SLOT-MAKUNBOUND > Warning: Manually finalizing class IDX-FIVE-DEL > INDEXING-WIPE-INDEX INDEXING-RECONNECT-DB INDEXING-CHANGE-CLASS > INDEXING-REDEF-CLASS > Warning: Manually finalizing class STRESS-INDEX > > Ranged get of 10/700 objects = Linear: 0.671 sec Indexed: 0.02 sec > INDEXING-TIMING > Single store mode: ignoring REMOVE-ELEMENT > Single store mode: ignoring MIGRATE-BASIC > Single store mode: ignoring MIGRATE-BTREE > Single store mode: ignoring MIGRATE-IDX-BTREE > Single store mode: ignoring MIGRATE-PCLASS > Single store mode: ignoring MIGRATE-IPCLASS PREPARES-BDB TEST-SEQ1 > TEST-SEQ2 CLEANSUP-BDB > No tests failed. > T > > > This is what I did: > in elephant.asd: > the run-shell-command generated this error, which is strange since > output stream was not defined. > Error: stream # #x20b10a02> can't be used as output > [condition type: SIMPLE-ERROR] > > I used excl.osi:command-output. The following perform makes > libmemutil.dll in the correct > directory (where memutil.fasl is) > > (defmethod perform ((o compile-op) (c elephant-c-source)) > "Run the appropriate compiler for this platform on the source, > getting > the specific options from 'compiler-options method. Default > options > can be overridden or augmented by subclass methods" > #+(or mswindows windows) > (progn > (let* ((pathname (component-pathname c)) > (directory (directory-namestring pathname))) > (let ((command (format nil "~A ~{~A ~}" > (c-compiler-path c) > (compiler-options (c-compiler c) c > :input-file (format nil > "\"~A\"" (namestring pathname)) > :output-file nil > :library nil)))) > (multiple-value-bind (stdout-lines stderr-lines exit-status) > (excl.osi:command-output command :directory directory) > (unless (zerop exit-status) > (error 'operation-error :component c :operation o)))) > > (let ((command (format nil "dlltool -z ~A --export-all- > symbols -e exports.o -l ~A ~A" > (format nil "\"~A\"" (namestring (make- > pathname :type "def" :defaults pathname))) > (format nil "\"~A\"" (namestring (make- > pathname :type "lib" :defaults pathname))) > (format nil "\"~A\"" (namestring (make- > pathname :type "o" :defaults pathname)))))) > (multiple-value-bind (stdout-lines stderr-lines exit-status) > (excl.osi:command-output command :directory directory) > (unless (zerop exit-status) > (error 'operation-error :component c :operation o)))) > > (let ((command (format nil "~A ~{~A ~}" ;; -I~A -L~A -l~A" > (c-compiler-path c) > (compiler-options (c-compiler c) c > :input-file > (list (format nil "\"~A > \"" (namestring > ( > make-pathname :type "o" :defaults pathname))) > "exports.o") > :output-file (format nil > "\"~A\"" (first (output-files o c))) > :library t)))) > (multiple-value-bind (stdout-lines stderr-lines exit-status) > (excl.osi:command-output command :directory directory) > (unless (zerop exit-status) > (error 'operation-error :component c :operation o)))))) > > #-(or mswindows windows) > (unless (zerop (run-shell-command > "~A ~{~A ~}" > (c-compiler-path c) > (compiler-options (c-compiler c) c > :input-file (namestring (component-pathname c)) > :output-file (namestring (first (output-files o c)))))) > (error 'operation-error :component c :operation o))) > > > The compiler options are not correct for libberkeley-db.dll. > Since I did not undestand the concept, I did not try to amend the > method further. > > I changed > > (defmethod compiler-options ((compiler (eql :cygwin)) (c elephant-c- > source) &key input-file output-file library &allow-other-keys) > (unless (or input-file output-file) > (error "Must specify at least one of output and input files")) > ..... > > Since there is no output file sometimes. > > > This produced a correct libberkeley-db.dll: > > gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/ > Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ > 4.5.20/include/ libberkeley-db.c > dlltool -z libberkeley-db.def --export-all-symbols -e exports.o -l > libberkeley-db.lib libberkeley-db.o > gcc -shared -mno-cygwin -mwindows -L/c/Programme/Oracle/Berkeley\ DB > \ 4.5.20/bin/ -llibdb45 libberkeley-db.o exports.o -o libberkeley- > db.dll > > At first, there was this error: > > In file included from libberkeley-db.c:165: > /c/Programme/Oracle/Berkeley DB 4.5.20/include/db.h:99: error: > conflicting types > for 'ssize_t' > /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/ > include/sys/types > .h:104: error: previous declaration of 'ssize_t' was here > > > I commented these lines out in C:\cygwin\usr\include\mingw\sys > \types.h: > > /* > *#ifndef _SSIZE_T_ > *#define _SSIZE_T_ > *typedef long _ssize_t; > * > *#ifndef _NO_OLDNAMES > *typedef _ssize_t ssize_t; > *#endif > *#endif * Not _SSIZE_T_ * > */ > > apparently this this did not cooperate with > > #ifdef _WIN64 > typedef int64_t ssize_t; > #else > typedef int32_t ssize_t; > #endif > > in db.h. > > > There is one remaining warning: > > libberkeley-db.c: In function `case_cmp': > libberkeley-db.c:1233: warning: implicit declaration of function > `_strnicmp' > > > Now, doing (do-backend-tests '(:BDB "c:/temp/testbdb/")) a second > or third ... time produces this: > > 1 out of 124 total tests failed: INDEXING-WIPE-INDEX. > NIL > > > When I delete all files in "c:/temp/testbdb/" the first test is ok, > second has 1 out of 124 failed. > > Elephant is nearly ready for mswin !!! > > Frank > ______________________________________________________________________ > XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club! > Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130 > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From franks-muc at web.de Wed Feb 28 23:44:32 2007 From: franks-muc at web.de (Frank Schorr) Date: Thu, 01 Mar 2007 00:44:32 +0100 Subject: [elephant-devel] Windows + LispWorks Message-ID: <430745635@web.de> This makes libmemutil.dll for ACL and LW: (I still have trouble with the format (format nil "~A ~{~A ~}" ;; -I~A -L~A -l~A which is called for making libberkeley-db.dll) (defmethod perform ((o compile-op) (c elephant-c-source)) "Run the appropriate compiler for this platform on the source, getting the specific options from 'compiler-options method. Default options can be overridden or augmented by subclass methods" #+(or mswindows windows) (progn (let* ((pathname (component-pathname c)) (directory (directory-namestring pathname)) (stdout-lines) (stderr-lines) (exit-status)) (let ((command (format nil "~A ~{~A ~}" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (format nil "\"~A\"" (namestring pathname)) :output-file nil :library nil)))) #+allegro (multiple-value-setq (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory)) #+lispworks (setf exit-status (system:call-system command :current-directory directory)) (unless (zerop exit-status) (error 'operation-error :component c :operation o))) (let ((command (format nil "dlltool -z ~A --export-all-symbols -e exports.o -l ~A ~A" (format nil "\"~A\"" (namestring (make-pathname :type "def" :defaults pathname))) (format nil "\"~A\"" (namestring (make-pathname :type "lib" :defaults pathname))) (format nil "\"~A\"" (namestring (make-pathname :type "o" :defaults pathname)))))) #+allegro (multiple-value-setq (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory)) #+lispworks (setf exit-status (system:call-system command :current-directory directory)) (unless (zerop exit-status) (error 'operation-error :component c :operation o))) (let ((command (format nil "~A ~{~A ~}" ;; -I~A -L~A -l~A (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (list (format nil "\"~A\"" (namestring (make-pathname :type "o" :defaults pathname))) "exports.o") :output-file (format nil "\"~A\"" (first (output-files o c))) :library t)))) #+allegro (multiple-value-setq (stdout-lines stderr-lines exit-status) (excl.osi:command-output command :directory directory)) #+lispworks (setf exit-status (system:call-system command :current-directory directory)) (unless (zerop exit-status) (error 'operation-error :component c :operation o))))) #-(or mswindows windows) (unless (zerop (run-shell-command "~A ~{~A ~}" (c-compiler-path c) (compiler-options (c-compiler c) c :input-file (namestring (component-pathname c)) :output-file (namestring (first (output-files o c)))))) (error 'operation-error :component c :operation o))) And here is some compiler output from LispWorks: ;;; Compiling file c:\lisp\libraries\elephant\src\memutil\memutil.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (DEFPACKAGE "ELEPHANT-MEMUTIL") ; (TOP-LEVEL-FORM 2) ;;;*** Warning in (DEFTYPE ELEPHANT-MEMUTIL:POINTER-INT): (DEFTYPE ELEPHANT-MEMUTIL:POINTER-INT) defined more than once in c:\lisp\libraries\elephant\src\memutil\memutil.lisp. ; (DEFTYPE ELEPHANT-MEMUTIL:POINTER-INT) ;;;*** Warning in (DEFTYPE ELEPHANT-MEMUTIL:POINTER-VOID): (DEFTYPE ELEPHANT-MEMUTIL:POINTER-VOID) defined more than once in c:\lisp\libraries\elephant\src\memutil\memutil.lisp. ; (DEFTYPE ELEPHANT-MEMUTIL:POINTER-VOID) ; (FLI:DEFINE-FOREIGN-TYPE ELEPHANT-MEMUTIL:ARRAY-OR-POINTER-CHAR) ;;;*** Warning in (DEFTYPE ELEPHANT-MEMUTIL:ARRAY-OR-POINTER-CHAR): (DEFTYPE ELEPHANT-MEMUTIL:ARRAY-OR-POINTER-CHAR) defined more than once in c:\lisp\libraries\elephant\src\memutil\memutil.lisp. ; (DEFTYPE ELEPHANT-MEMUTIL:ARRAY-OR-POINTER-CHAR) ; (SUBFUNCTION ELEPHANT-MEMUTIL::COPY-BUFS (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-BUFS)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-BUFS) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-BUFS) ; (DEFVAR ELEPHANT-MEMUTIL:+NULL-VOID+) ; (DEFVAR ELEPHANT-MEMUTIL:+NULL-CHAR+) ; (DEFVAR ELEPHANT-MEMUTIL::*BUFFER-STREAMS*) ; (DEFVAR ELEPHANT-MEMUTIL::*BUFFER-STREAMS-LOCK*) ; (SUBFUNCTION (DEFSETF ELEPHANT-MEMUTIL:BUFFER-STREAM-LENGTH) (DEFSTRUCT ELEPHANT-MEMUTIL:BUFFER-STREAM)) ; (SUBFUNCTION (DEFSETF ELEPHANT-MEMUTIL::BUFFER-STREAM-POSITION) (DEFSTRUCT ELEPHANT-MEMUTIL:BUFFER-STREAM)) ; (SUBFUNCTION (DEFSETF ELEPHANT-MEMUTIL:BUFFER-STREAM-SIZE) (DEFSTRUCT ELEPHANT-MEMUTIL:BUFFER-STREAM)) ; (SUBFUNCTION (DEFSETF ELEPHANT-MEMUTIL:BUFFER-STREAM-BUFFER) (DEFSTRUCT ELEPHANT-MEMUTIL:BUFFER-STREAM)) ; (SUBFUNCTION ELEPHANT-MEMUTIL:MAKE-BUFFER-STREAM (DEFSTRUCT ELEPHANT-MEMUTIL:BUFFER-STREAM)) ; ELEPHANT-MEMUTIL::GRAB-BUFFER-STREAM ;;;*** Warning in ELEPHANT-MEMUTIL::RETURN-BUFFER-STREAM: Inline expansion for ELEPHANT-MEMUTIL:RESET-BUFFER-STREAM not found ;;;*** Warning in ELEPHANT-MEMUTIL::RETURN-BUFFER-STREAM: Inline expansion for ELEPHANT-MEMUTIL:RESET-BUFFER-STREAM not found ; ELEPHANT-MEMUTIL::RETURN-BUFFER-STREAM ; ELEPHANT-MEMUTIL:WITH-BUFFER-STREAMS ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-INT32 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT32)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT32) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT32) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-UINT32 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT32)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT32) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT32) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-INT64 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT64)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT64) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-INT64) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-UINT64 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT64)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT64) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-UINT64) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-FLOAT (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-FLOAT)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-FLOAT (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-FLOAT)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-FLOAT) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-FLOAT) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::READ-DOUBLE) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-INT32 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT32)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT32) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT32) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-UINT32 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT32)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT32) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT32) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-INT64 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT64)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT64) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-INT64) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-UINT64 (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT64)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT64) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-UINT64) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-FLOAT) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::WRITE-DOUBLE) ; (SUBFUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::OFFSET-CHAR-POINTER) ; ELEPHANT-MEMUTIL:BYTE-LENGTH ; (SUBFUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF)) ; (SUBFUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF)) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF) ; (FLI:DEFINE-FOREIGN-FUNCTION ELEPHANT-MEMUTIL::COPY-STR-TO-BUF) ; ELEPHANT-MEMUTIL::PROCESS-STRUCT-SLOT-DEFS ; ELEPHANT-MEMUTIL::WITH-STRUCT-SLOTS ;;;*** Warning in ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM: Inline expansion for ELEPHANT-MEMUTIL::COPY-BUFS not found ;;;*** Warning in ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM: Inline expansion for ELEPHANT-MEMUTIL::COPY-BUFS not found ;;;*** Warning in ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM: Inline expansion for ELEPHANT-MEMUTIL::COPY-BUFS not found ; ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM ;;;*** Warning in ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM-NO-COPY: symbol-macro SIZE is bound but not referenced ; ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM-NO-COPY ; ELEPHANT-MEMUTIL:RESET-BUFFER-STREAM ; ELEPHANT-MEMUTIL:RESET-BUFFER-STREAM ; ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE ; ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE ; ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-INT64 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-INT64 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT64 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT64 ; ELEPHANT-MEMUTIL:BUFFER-WRITE-FLOAT ; ELEPHANT-MEMUTIL:BUFFER-WRITE-FLOAT ; ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE ; ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE ; ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING ; ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING ; ELEPHANT-MEMUTIL:BUFFER-READ-BYTE ; ELEPHANT-MEMUTIL:BUFFER-READ-BYTE ; ELEPHANT-MEMUTIL::BUFFER-READ-BYTE-VECTOR ; ELEPHANT-MEMUTIL::BUFFER-WRITE-BYTE-VECTOR ; ELEPHANT-MEMUTIL:BUFFER-READ-TO-ARRAY-OFFSET ; ELEPHANT-MEMUTIL:BUFFER-WRITE-FROM-ARRAY-OFFSET ; ELEPHANT-MEMUTIL:BUFFER-WRITE-OID ; ELEPHANT-MEMUTIL:BUFFER-WRITE-OID ; ELEPHANT-MEMUTIL:BUFFER-READ-OID ; ELEPHANT-MEMUTIL:BUFFER-READ-OID ;;;*** Warning in ELEPHANT-MEMUTIL:BUFFER-READ-INT: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT-MEMUTIL:BUFFER-READ-INT: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ; ELEPHANT-MEMUTIL:BUFFER-READ-INT ; ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM ; ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM ; ELEPHANT-MEMUTIL:BUFFER-WRITE-INT ;;;*** Warning in ELEPHANT-MEMUTIL:BUFFER-READ-UINT: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UINT32 not found ;;;*** Warning in ELEPHANT-MEMUTIL:BUFFER-READ-UINT: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UINT32 not found ; ELEPHANT-MEMUTIL:BUFFER-READ-UINT ; ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT ; (DEFCONSTANT ELEPHANT-MEMUTIL::+2^32+) ; (DEFCONSTANT ELEPHANT-MEMUTIL::+2^64+) ; ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM32 ; ELEPHANT-MEMUTIL:BUFFER-READ-INT32 ; ELEPHANT-MEMUTIL:BUFFER-READ-INT32 ; ELEPHANT-MEMUTIL:BUFFER-READ-UINT32 ; ELEPHANT-MEMUTIL:BUFFER-READ-UINT32 ; ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM64 ; ELEPHANT-MEMUTIL:BUFFER-READ-INT64 ; ELEPHANT-MEMUTIL:BUFFER-READ-INT64 ; ELEPHANT-MEMUTIL:BUFFER-READ-UINT64 ; ELEPHANT-MEMUTIL:BUFFER-READ-UINT64 ; ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT ; ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT ; ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE ; ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE **++++ Error between functions: Undefined operator ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P in form (ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P). **++++ Error between functions: Undefined operator ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P in form (ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P). ; ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING ; ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING **++++ Error between functions: Undefined operator ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P in form (ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P). **++++ Error between functions: Undefined operator ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P in form (ELEPHANT-MEMUTIL::NEW-STYLE-COPY-P). ; ELEPHANT-MEMUTIL:LITTLE-ENDIAN-P ; (TOP-LEVEL-FORM 3) ; *** 4 errors detected, no fasl file produced. ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\variables.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFVAR ELEPHANT:*ELEPHANT-CODE-VERSION*) ; (DEFVAR ELEPHANT::*ELEPHANT-UNMARKED-CODE-VERSION*) ; (DEFVAR ELEPHANT::*ELEPHANT-PROPERTIES-LABEL*) ; (DEFVAR ELEPHANT::*CACHESIZE*) ; (DEFVAR ELEPHANT::*CIRCULARITY-INITIAL-HASH-SIZE*) ; (DEFVAR ELEPHANT:*STORE-CONTROLLER*) ; (DEFVAR ELEPHANT:*CURRENT-TRANSACTION*) ; ELEPHANT::REMOVE-INDEXED-ELEMENT-AND-ADJUST ; (TOP-LEVEL-FORM 3) ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\variables.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\transactions.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFGENERIC ELEPHANT::EXECUTE-TRANSACTION) ; ELEPHANT::MAKE-TRANSACTION-RECORD ; ELEPHANT::TRANSACTION-STORE ; ELEPHANT::TRANSACTION-OBJECT ; ELEPHANT::TRANSACTION-OBJECT-P ; ELEPHANT::OWNED-TXN-P ; ELEPHANT:WITH-TRANSACTION ; ELEPHANT:ENSURE-TRANSACTION ; ELEPHANT::WITH-BATCH-TRANSACTION ; (DEFGENERIC ELEPHANT::CONTROLLER-START-TRANSACTION) ; (DEFGENERIC ELEPHANT::CONTROLLER-COMMIT-TRANSACTION) ; (DEFGENERIC ELEPHANT::CONTROLLER-ABORT-TRANSACTION) ; (TOP-LEVEL-FORM 3) ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\transactions.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\metaclasses.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFCLASS ELEPHANT:PERSISTENT) ; (DEFCLASS ELEPHANT:PERSISTENT-METACLASS) ; ELEPHANT:DEFPCLASS ; ELEPHANT::ADD-PERSISTENT-METACLASS-ARGUMENT ; (METHOD ELEPHANT::PERSISTENT-SLOTS (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::PERSISTENT-SLOTS (STANDARD-CLASS)) ; (METHOD ELEPHANT::OLD-PERSISTENT-SLOTS (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::UPDATE-PERSISTENT-SLOTS (ELEPHANT:PERSISTENT-METACLASS T)) ; (DEFCLASS ELEPHANT::PERSISTENT-SLOT-DEFINITION) ; (DEFCLASS ELEPHANT::PERSISTENT-DIRECT-SLOT-DEFINITION) ; (DEFCLASS ELEPHANT::PERSISTENT-EFFECTIVE-SLOT-DEFINITION) ; (DEFCLASS ELEPHANT::TRANSIENT-SLOT-DEFINITION) ; (DEFCLASS ELEPHANT::TRANSIENT-DIRECT-SLOT-DEFINITION) ; (DEFCLASS ELEPHANT::TRANSIENT-EFFECTIVE-SLOT-DEFINITION) ; (DEFGENERIC ELEPHANT::TRANSIENT) ; (METHOD ELEPHANT::TRANSIENT (STANDARD-DIRECT-SLOT-DEFINITION)) ; (METHOD ELEPHANT::TRANSIENT (ELEPHANT::PERSISTENT-DIRECT-SLOT-DEFINITION)) ; (DEFCLASS ELEPHANT::INDEXING-RECORD) ; (METHOD PRINT-OBJECT (ELEPHANT::INDEXING-RECORD T)) ; (METHOD ELEPHANT::INDEXED-RECORD (STANDARD-CLASS)) ; (METHOD ELEPHANT::INDEXED-RECORD (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::OLD-INDEXED-RECORD (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::UPDATE-INDEXED-RECORD (ELEPHANT:PERSISTENT-METACLASS T)) ; (METHOD ELEPHANT::MAKE-NEW-INDEXED-RECORD (T T T)) ; (METHOD ELEPHANT::REMOVED-INDEXING? (ELEPHANT:PERSISTENT-METACLASS)) ; ELEPHANT::INDEXED-SLOT-NAMES-FROM-DEFS ; (METHOD ELEPHANT::REGISTER-INDEXED-SLOT (ELEPHANT:PERSISTENT-METACLASS T)) ; (METHOD ELEPHANT::UNREGISTER-INDEXED-SLOT (T T)) ; (METHOD ELEPHANT::REGISTER-DERIVED-INDEX (T T)) ; (METHOD ELEPHANT::UNREGISTER-DERIVED-INDEX (T T)) ; (METHOD ELEPHANT::INDEXED (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::PREVIOUSLY-INDEXED (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::INDEXED (STANDARD-SLOT-DEFINITION)) ; (METHOD ELEPHANT::INDEXED (STANDARD-CLASS)) ; (DEFVAR ELEPHANT::*INHIBIT-INDEXING-LIST*) ; ELEPHANT::INHIBIT-INDEXING ; ELEPHANT::UNINHIBIT-INDEXING ; (METHOD SLOT-DEFINITION-ALLOCATION (ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (METHOD CLOS:DIRECT-SLOT-DEFINITION-CLASS (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD VALIDATE-SUPERCLASS (ELEPHANT:PERSISTENT-METACLASS STANDARD-CLASS)) ; (METHOD VALIDATE-SUPERCLASS (STANDARD-CLASS ELEPHANT:PERSISTENT-METACLASS)) ; (DEFGENERIC ELEPHANT::PERSISTENT-P) ; (METHOD ELEPHANT::PERSISTENT-P (T)) ; (METHOD ELEPHANT::PERSISTENT-P (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD ELEPHANT::PERSISTENT-P (ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (METHOD CLOS:EFFECTIVE-SLOT-DEFINITION-CLASS (ELEPHANT:PERSISTENT-METACLASS)) ; ELEPHANT::ENSURE-TRANSIENT-CHAIN ; (METHOD ELEPHANT::COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS (ELEPHANT:PERSISTENT-METACLASS T)) ; ELEPHANT::FIND-SLOT-DEF-BY-NAME ; ELEPHANT::PERSISTENT-SLOT-DEFS ; ELEPHANT::TRANSIENT-SLOT-DEFS ; ELEPHANT::PERSISTENT-SLOT-NAMES ; ELEPHANT::TRANSIENT-SLOT-NAMES ; (TOP-LEVEL-FORM 3) ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\metaclasses.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\classes.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFVAR ELEPHANT::*DEBUG-SI*) ; (METHOD INITIALIZE-INSTANCE :BEFORE (ELEPHANT:PERSISTENT)) ; (DEFCLASS ELEPHANT:PERSISTENT-OBJECT) ; (METHOD CLOS:ENSURE-CLASS-USING-CLASS :AROUND ((EQL NIL) T)) ; (METHOD CLOS:ENSURE-CLASS-USING-CLASS :AROUND (ELEPHANT:PERSISTENT-METACLASS T)) ; ELEPHANT::REMOVE-INDEX-KEYWORD ; (METHOD SHARED-INITIALIZE :AROUND (ELEPHANT:PERSISTENT-METACLASS T)) ; (METHOD ELEPHANT::FINALIZE-INHERITANCE :AROUND (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD REINITIALIZE-INSTANCE :AROUND (ELEPHANT:PERSISTENT-METACLASS)) ; (METHOD SHARED-INITIALIZE :AROUND (ELEPHANT:PERSISTENT-OBJECT T)) ; ELEPHANT::INITIALIZE-PERSISTENT-SLOTS ; (METHOD UPDATE-INSTANCE-FOR-REDEFINED-CLASS :AROUND (ELEPHANT:PERSISTENT-OBJECT T T T)) ; (METHOD UPDATE-INSTANCE-FOR-DIFFERENT-CLASS :AROUND (ELEPHANT:PERSISTENT ELEPHANT:PERSISTENT)) ; (METHOD CLOS:SLOT-VALUE-USING-CLASS :AROUND (ELEPHANT:PERSISTENT-METACLASS ELEPHANT:PERSISTENT-OBJECT ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (METHOD (SETF CLOS:SLOT-VALUE-USING-CLASS) :AROUND (T ELEPHANT:PERSISTENT-METACLASS ELEPHANT:PERSISTENT-OBJECT ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (METHOD CLOS:SLOT-BOUNDP-USING-CLASS :AROUND (ELEPHANT:PERSISTENT-METACLASS ELEPHANT:PERSISTENT-OBJECT ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (METHOD CLOS:SLOT-BOUNDP-USING-CLASS :AROUND (ELEPHANT:PERSISTENT-METACLASS ELEPHANT:PERSISTENT-OBJECT SYMBOL)) ; (METHOD CLOS:SLOT-MAKUNBOUND-USING-CLASS :AROUND (ELEPHANT:PERSISTENT-METACLASS ELEPHANT:PERSISTENT-OBJECT ELEPHANT::PERSISTENT-SLOT-DEFINITION)) ; (TOP-LEVEL-FORM 3) ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\classes.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\serializer.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; ELEPHANT::SERIALIZE ; ELEPHANT::DESERIALIZE ; (DEFGENERIC ELEPHANT:STRUCT-CONSTRUCTOR) ; (METHOD ELEPHANT:STRUCT-CONSTRUCTOR (T)) ;;;*** Warning in ELEPHANT::SERIALIZE-TO-BASE64-STRING: ELEPHANT::OUT-BUF assumed special ; ELEPHANT::SERIALIZE-TO-BASE64-STRING ; ELEPHANT::CONVERT-BUFFER-TO-BASE64-STRING ;;;*** Warning in ELEPHANT::DESERIALIZE-FROM-BASE64-STRING: ELEPHANT::OTHER assumed special ; ELEPHANT::DESERIALIZE-FROM-BASE64-STRING ;;;*** Warning in ELEPHANT::CONVERT-BUFFER-FROM-BASE64-STRING: ELEPHANT::TARGET assumed special ; ELEPHANT::CONVERT-BUFFER-FROM-BASE64-STRING ; (DEFCONSTANT ELEPHANT::+RESERVED-DBINFO+) ; (DEFCONSTANT ELEPHANT::+ELEPHANT-VERSION+) ; (DEFCONSTANT ELEPHANT::+ELEPHANT-SERIALIZER-VERSION+) ; ELEPHANT:SERIALIZE-DATABASE-VERSION-KEY ; ELEPHANT:SERIALIZE-DATABASE-VERSION-VALUE ; ELEPHANT:DESERIALIZE-DATABASE-VERSION-VALUE ; ELEPHANT::SERIALIZE-DATABASE-SERIALIZER-VERSION-KEY ; ELEPHANT:SERIALIZE-DATABASE-SERIALIZER-VERSION-VALUE ; ELEPHANT:DESERIALIZE-DATABASE-SERIALIZER-VERSION-VALUE ;;;*** Warning in ELEPHANT::SERIALIZE-RESERVED-TAG: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT::SERIALIZE-RESERVED-TAG: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ; ELEPHANT::SERIALIZE-RESERVED-TAG ;;;*** Warning in ELEPHANT::SERIALIZE-SYSTEM-TAG: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT::SERIALIZE-SYSTEM-TAG: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ; ELEPHANT::SERIALIZE-SYSTEM-TAG ;;;*** Warning in ELEPHANT::SERIALIZE-SYSTEM-INTEGER: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT::SERIALIZE-SYSTEM-INTEGER: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ; ELEPHANT::SERIALIZE-SYSTEM-INTEGER ;;;*** Warning in ELEPHANT::DESERIALIZE-SYSTEM-INTEGER: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT::DESERIALIZE-SYSTEM-INTEGER: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ; ELEPHANT::DESERIALIZE-SYSTEM-INTEGER ; ELEPHANT:SLOTS-AND-VALUES ; ELEPHANT:STRUCT-SLOTS-AND-VALUES ; (TOP-LEVEL-FORM 3) ; (DEFVAR ELEPHANT::ARRAY-TYPE-TO-BYTE) ; (DEFVAR ELEPHANT::BYTE-TO-ARRAY-TYPE) ; (TOP-LEVEL-FORM 4) ; (TOP-LEVEL-FORM 5) ; (TOP-LEVEL-FORM 6) ; (TOP-LEVEL-FORM 7) ; (TOP-LEVEL-FORM 8) ; (TOP-LEVEL-FORM 9) ; (TOP-LEVEL-FORM 10) ; (TOP-LEVEL-FORM 11) ; (TOP-LEVEL-FORM 12) ; ELEPHANT::TYPE= ; (TOP-LEVEL-FORM 13) ; (TOP-LEVEL-FORM 14) ; ELEPHANT::ARRAY-TYPE-FROM-BYTE ; ELEPHANT::BYTE-FROM-ARRAY-TYPE ; ELEPHANT:INT-BYTE-SPEC ; (TOP-LEVEL-FORM 15) Warning: COMPILE-FILE warned while performing # on #. ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\serializer.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\serializer1.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFPACKAGE "ELEPHANT-SERIALIZER1") ; (TOP-LEVEL-FORM 3) ; (TOP-LEVEL-FORM 4) ; (DEFTYPE ELEPHANT-SERIALIZER1::FOREIGN-CHAR) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+FIXNUM+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+CHAR+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+SINGLE-FLOAT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+DOUBLE-FLOAT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+NEGATIVE-BIGNUM+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+POSITIVE-BIGNUM+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+RATIONAL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+NIL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS1-SYMBOL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS1-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS1-PATHNAME+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS2-SYMBOL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS2-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS2-PATHNAME+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS4-SYMBOL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS4-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+UCS4-PATHNAME+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+PERSISTENT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+CONS+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+HASH-TABLE+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+OBJECT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+ARRAY+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+RESERVED-DBINFO+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+FILL-POINTER-P+) ; (DEFCONSTANT ELEPHANT-SERIALIZER1::+ADJUSTABLE-P+) ; (DEFVAR ELEPHANT-SERIALIZER1::*LISP-OBJ-ID*) ; (DEFVAR ELEPHANT-SERIALIZER1::*CIRCULARITY-HASH*) ; ELEPHANT-SERIALIZER1::CLEAR-CIRCULARITY-HASH ; ELEPHANT-SERIALIZER1::SERIALIZE ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ; ELEPHANT-SERIALIZER1::SERIALIZE ; (DEFPARAMETER ELEPHANT-SERIALIZER1::*TRACE-SERIALIZER*) ; (DEFPARAMETER ELEPHANT-SERIALIZER1::*TAG-TABLE*) ; ELEPHANT-SERIALIZER1::ENABLE-SERIALIZER-TRACING ; ELEPHANT-SERIALIZER1::DISABLE-SERIALIZER-TRACING ; ELEPHANT-SERIALIZER1::PRINT-PRE-DESERIALIZE-TAG ; ELEPHANT-SERIALIZER1::PRINT-POST-DESERIALIZE-TAG ; ELEPHANT-SERIALIZER1::DESERIALIZE ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Ignoring type declaration with illegal type (OR NULL ELEPHANT-MEMUTIL:BUFFER-STREAM) ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS2-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-UCS1-STRING not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ; ELEPHANT-SERIALIZER1::DESERIALIZE ; ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ;;;*** Warning in ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM: Inline expansion for ELEPHANT:INT-BYTE-SPEC not found ; ELEPHANT-SERIALIZER1::DESERIALIZE-BIGNUM ; (TOP-LEVEL-FORM 5) ;; ** Automatic Minor Clean Down Warning: COMPILE-FILE warned while performing # on #. Warning: COMPILE-FILE failed while performing # on #. ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\serializer1.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\serializer2.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ; (DEFPACKAGE "ELEPHANT-SERIALIZER2") ; (TOP-LEVEL-FORM 3) ; (DEFTYPE ELEPHANT-SERIALIZER2::FOREIGN-CHAR) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+FIXNUM32+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+FIXNUM64+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+CHAR+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+SINGLE-FLOAT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+DOUBLE-FLOAT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+NEGATIVE-BIGNUM+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+POSITIVE-BIGNUM+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+RATIONAL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+UTF8-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+UTF16-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+UTF32-STRING+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+PATHNAME+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+SYMBOL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+PERSISTENT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+CONS+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+HASH-TABLE+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+OBJECT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+ARRAY+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+STRUCT+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+CLASS+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+NIL+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+RESERVED-DBINFO+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+FILL-POINTER-P+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+ADJUSTABLE-P+) ; (DEFPARAMETER ELEPHANT-SERIALIZER2::*CIRCULARITY-HASH-QUEUE*) ; (DEFVAR ELEPHANT-SERIALIZER2::*SERIALIZER-FAST-LOCK*) ; ELEPHANT-SERIALIZER2::GET-CIRCULARITY-HASH ; ELEPHANT-SERIALIZER2::RELEASE-CIRCULARITY-HASH ; (DEFPARAMETER ELEPHANT-SERIALIZER2::*CIRCULARITY-VECTOR-QUEUE*) ; ELEPHANT-SERIALIZER2::GET-CIRCULARITY-VECTOR ; ELEPHANT-SERIALIZER2::RELEASE-CIRCULARITY-VECTOR ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+2^31+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+2^32+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+2^63+) ; (DEFCONSTANT ELEPHANT-SERIALIZER2::+2^64+) ; ELEPHANT-SERIALIZER2::SERIALIZE ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT:SLOTS-AND-VALUES not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-INT32 not found ; ELEPHANT-SERIALIZER2::SERIALIZE ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-WRITE-UINT32 not found ; ELEPHANT-SERIALIZER2::SERIALIZE-BIGNUM ; (DEFPARAMETER ELEPHANT-SERIALIZER2::*TRACE-DESERIALIZER*) ; (DEFPARAMETER ELEPHANT-SERIALIZER2::*TAG-TABLE*) ; ELEPHANT-SERIALIZER2::ENABLE-DESERIALIZER-TRACING ; ELEPHANT-SERIALIZER2::DISABLE-DESERIALIZER-TRACING ; ELEPHANT-SERIALIZER2::PRINT-PRE-DESERIALIZE-TAG ; ELEPHANT-SERIALIZER2::PRINT-POST-DESERIALIZE-TAG ; ELEPHANT-SERIALIZER2::DESERIALIZE ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Ignoring type declaration with illegal type (OR NULL ELEPHANT-MEMUTIL:BUFFER-STREAM) ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-BYTE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FIXNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-DOUBLE not found ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE: Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-FLOAT not found ; ELEPHANT-SERIALIZER2::DESERIALIZE ; ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM ;;;*** Warning in ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ; ELEPHANT-SERIALIZER2::DESERIALIZE-BIGNUM ; (TOP-LEVEL-FORM 4) ;; ** Automatic Minor Clean Down Warning: COMPILE-FILE warned while performing # on #. Warning: COMPILE-FILE failed while performing # on #. ; Loading fasl file c:\lisp\binaries\lispworks-5.0.1-mswindows-x86\lisp\libraries\elephant\src\elephant\serializer2.ofasl ;;; Compiling file c:\lisp\libraries\elephant\src\elephant\unicode2.lisp ... ;;; Safety = 3, Speed = 1, Space = 1, Float = 1, Interruptible = 0 ;;; Compilation speed = 1, Debug = 2, Fixnum safety = 3 ;;; Source level debugging is on ;;; Source file recording is on ;;; Cross referencing is on ; (TOP-LEVEL-FORM 1) ; (TOP-LEVEL-FORM 2) ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-STRING: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ; ELEPHANT-SERIALIZER2::SERIALIZE-STRING ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF8: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM **++++ Error in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF8: Badly formed lambda: (BUFFER BUFFER-STREAM-BUFFER) ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF16LE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM **++++ Error in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF16LE: Badly formed lambda: (BUFFER BUFFER-STREAM-BUFFER) ;;;*** Warning in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF32LE: Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM **++++ Error in ELEPHANT-SERIALIZER2::SERIALIZE-TO-UTF32LE: Badly formed lambda: (BUFFER BUFFER-STREAM-BUFFER) ; (DEFPARAMETER ELEPHANT-SERIALIZER2::NATIVE-STRING-TYPE) ; ELEPHANT-SERIALIZER2::COMPATIBLE-UNICODE-SUPPORT-P ; (DEFGENERIC ELEPHANT-SERIALIZER2::DESERIALIZE-STRING) ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF8) T)): Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF8) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF8) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ; (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF8) T)) ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF16LE) T)): Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF16LE) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF16LE) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF16LE) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ; (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF16LE) T)) ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF32LE) T)): Ignoring type declaration with illegal type ELEPHANT-MEMUTIL:BUFFER-STREAM ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF32LE) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ;;;*** Warning in (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF32LE) T)): Inline expansion for ELEPHANT-MEMUTIL:BUFFER-READ-INT32 not found ; (METHOD ELEPHANT-SERIALIZER2::DESERIALIZE-STRING ((EQL :UTF32LE) T)) ; (TOP-LEVEL-FORM 3) ; *** 3 errors detected, no fasl file produced. Warning: COMPILE-FILE warned while performing # on #. Warning: COMPILE-FILE failed while performing # on #. I hope it helps. Frank _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066