From read at robertlread.net Wed Jul 4 22:49:45 2007 From: read at robertlread.net (Robert L. Read) Date: Wed, 04 Jul 2007 17:49:45 -0500 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <1178981162.1893.107.camel@trinidad> References: <1178981162.1893.107.camel@trinidad> Message-ID: <1183589386.13792.14.camel@localhost.localdomain> I have just integrated Henrik Hjelte's postmodern-based backend into the official darcs repository for elephant: http://common-lisp.net/project/elephant/darcs/elephant/ However, this is not an official release, but presumably will be part of the next official release. It passes all of the tests. The Postmodern backend is not quite twice as fast on our testsuite as the CL-SQL backend. The CL-SQL backend still has some value, however, for non-Postgres databases. If someone were to write another DB-specific backend, such as a MySQL backend or an Oracle backend, I would assume they would benefit from both the CL-SQL version and the Postmodern version. However, I think the Postmodern version is better-written. I thank Henrik very much for preparing such a well-written, easy-to-integrate backend. I did, however, have to make three changes to get this to work for me under SBCL. Postmodern defines "db-error" incompatibly with the BDB backend, so I renamed the BDB symbol from db-error to bdb-db-error. This was one issue on a "handler-case" that I assume was acceptable under Henrik's LISP, but didn't work under SBCL, or seem to follow the CLHS. Finally, in shared-initialize :after method that builds the cache- indices I had to explicitly set the slot to the initform, to prevent a reading of an unbound-slot. I still have no idea why the slot was unbound at that point, in spite of all documentation saying that it should be. I slightly modified Henrik's test to harmonize more with the CL-SQL version, and added an example of using postmodern into the RUNTEST.lisp file. Describing this in the manual remains to be done; I don't have any immediate plans to do so. Personally, I think each backend adds to the overall usability of Elephant, and should broaden our user base. Particularly since one can migrate data from one backend to another, it would seem that we are offering a solid platform. Once this is officially released, users can expect the postmodern backend to be supported indefinitely. If we ever drop a backend, we will provide a way to migrate data out of it. On Sat, 2007-05-12 at 16:46 +0200, Henrik Hjelte wrote: > I have made some changes to the postmodern postgresql backend. The darcs > repo is now based on the official elephant darcs repo, so patches can be > moved between them easily. The postmodern backend passes all "official" > tests, but has not been extensively tested with real data yet. > > The db-postmodern tree can be found here: > http://common-lisp.net/project/grand-prix/darcs/elephant > > /Henrik Hjelte > > _______________________________________________ > 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 nowhere.man at levallois.eu.org Thu Jul 5 11:58:36 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Thu, 5 Jul 2007 13:58:36 +0200 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <1183589386.13792.14.camel@localhost.localdomain> References: <1178981162.1893.107.camel@trinidad> <1183589386.13792.14.camel@localhost.localdomain> Message-ID: <20070705115836.GB24133@bateleur.arcanes.fr.eu.org> Scribit Robert L. Read dies 04/07/2007 hora 17:49: > The Postmodern backend is not quite twice as fast on our testsuite as > the CL-SQL backend. Great. I found the CL-SQL backend with PostgreSQL a bit slow for my specific use case. Do you know why and how this backend is so much faster? > Postmodern defines "db-error" incompatibly with the BDB backend, so I > renamed the BDB symbol from db-error to bdb-db-error. Was there any value in having the same condition for all backends? If yes, will it be a goal to "fix" this divergence? Curiously, Pierre -- nowhere.man at levallois.eu.org OpenPGP 0xD9D50D8A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From read at robertlread.net Thu Jul 5 15:20:03 2007 From: read at robertlread.net (Robert L. Read) Date: Thu, 05 Jul 2007 10:20:03 -0500 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <20070705115836.GB24133@bateleur.arcanes.fr.eu.org> References: <1178981162.1893.107.camel@trinidad> <1183589386.13792.14.camel@localhost.localdomain> <20070705115836.GB24133@bateleur.arcanes.fr.eu.org> Message-ID: <1183648803.13792.53.camel@localhost.localdomain> On Thu, 2007-07-05 at 13:58 +0200, Pierre THIERRY wrote: > Scribit Robert L. Read dies 04/07/2007 hora 17:49: > > The Postmodern backend is not quite twice as fast on our testsuite as > > the CL-SQL backend. > > Great. I found the CL-SQL backend with PostgreSQL a bit slow for my > specific use case. Do you know why and how this backend is so much > faster? I haven't studied it deeply; Henrik could answer better than I. However, it uses tables more effectively, and uses stored procedures which are very Postgres-specific and not portable to a different database. > > > Postmodern defines "db-error" incompatibly with the BDB backend, so I > > renamed the BDB symbol from db-error to bdb-db-error. > > Was there any value in having the same condition for all backends? If > yes, will it be a goal to "fix" this divergence? No, this is an internal matter ---- I don't think we have attempted to provide a cross-platform error mechanism, and I would hesitate to try to do so. Ideally, I would like the Elephant development to be shaped by the actual needs of the users. Although we have been responsive to bugs, I don't feel that we have been given a lot of feedback in terms of what direction it should take. I agree with Ian that a pure-lisp backend would be nice, because it would let someone use Elephant without installing anything else, while still leaving open the engineering decision of what to use later. > > Curiously, > Pierre > _______________________________________________ > 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 nowhere.man at levallois.eu.org Fri Jul 6 23:47:42 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Sat, 7 Jul 2007 01:47:42 +0200 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <1183648803.13792.53.camel@localhost.localdomain> References: <1178981162.1893.107.camel@trinidad> <1183589386.13792.14.camel@localhost.localdomain> <20070705115836.GB24133@bateleur.arcanes.fr.eu.org> <1183648803.13792.53.camel@localhost.localdomain> Message-ID: <20070706234742.GF24133@bateleur.arcanes.fr.eu.org> Scribit Robert L. Read dies 05/07/2007 hora 10:20: > However, it uses tables more effectively, and uses stored procedures > which are very Postgres-specific and not portable to a different > database. Well, I think that constitutes an answer to my earlier question about the performance gains of stored procedures: it's definitely worth investigating. I would find interesting to see how to cl-sql backend could be made extensible, so that most of the postmodern's improvements related to the use of the database could be ported to it. Does the way the postmodern backend communicates with the DB could also be a source of speedup? > Although we have been responsive to bugs, I don't feel that we have > been given a lot of feedback in terms of what direction it should > take. Well, I think my recent paper give some interesting directions: http://lisp-ecoop07.bknr.net/submission/13418 Curiously, Pierre -- nowhere.man at levallois.eu.org OpenPGP 0xD9D50D8A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From henrik at evahjelte.com Mon Jul 9 08:30:07 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 9 Jul 2007 10:30:07 +0200 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <20070706234742.GF24133@bateleur.arcanes.fr.eu.org> References: <1178981162.1893.107.camel@trinidad> <1183589386.13792.14.camel@localhost.localdomain> <20070705115836.GB24133@bateleur.arcanes.fr.eu.org> <1183648803.13792.53.camel@localhost.localdomain> <20070706234742.GF24133@bateleur.arcanes.fr.eu.org> Message-ID: <50e8e4f60707090130q73b21928s269a93b5a170751a@mail.gmail.com> On 7/7/07, Pierre THIERRY wrote> Scribit Robert L. Read dies 05/07/2007 hora 10:20: > > However, it uses tables more effectively, and uses stored procedures > > which are very Postgres-specific and not portable to a different > > database. > > Well, I think that constitutes an answer to my earlier question about > the performance gains of stored procedures: it's definitely worth > investigating. I tried to measure when developing the backend. Prepared queries gave the same speed as stored procedures. Stored procedures are only used for inserts which does a few steps in an if then clause, then I thought it was unnecessary to send intermediate values between client and server. > I would find interesting to see how to cl-sql backend could be made > extensible, so that most of the postmodern's improvements related to the > use of the database could be ported to it. It should be easy to factor out from clsql. Also, the postgresql specific parts of the postmodern backend could rather easily be factored out, they are not so many. > Does the way the postmodern backend communicates with the DB could also > be a source of speedup? Yes maybe, but I don't think it is of highest importance. > > > Although we have been responsive to bugs, I don't feel that we have > > been given a lot of feedback in terms of what direction it should > > take. > > Well, I think my recent paper give some interesting directions: > > http://lisp-ecoop07.bknr.net/submission/13418 Looks interesting from a fast scan, I must read it better before commenting on it though. But the shortcomings you address should be fixed, definitely. /Henrik From read at robertlread.net Tue Jul 10 20:41:47 2007 From: read at robertlread.net (Robert L. Read) Date: Tue, 10 Jul 2007 15:41:47 -0500 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <1183589386.13792.14.camel@localhost.localdomain> References: <1178981162.1893.107.camel@trinidad> <1183589386.13792.14.camel@localhost.localdomain> Message-ID: <1184100108.5313.20.camel@localhost.localdomain> Henrik and I have fixed some subtle bugs that occurred under certain data values (which happened to occur in my "live" database for "konsenti.com", my for- profit business. I have now integrated these fixes into the main darcs elephant repository. If anybody pulls and tests the :ele-postmodern backend, please send us a note. It works under SBCL, but has not been tested under our full matrix, AFAIK. By the way, one might be interested in how one migrated from an exsiting CL-SQL backend to the Postmodern-based ele-postmodern backend. Here is approximately the lisp code that I used to move from "konsenti", a CL-SQL based backend, to "kosenti2", a postmodern-based backend: (defparameter *REPOSITORY-SPEC* (list :clsql (list :postgresql (coerce-to-base "localhost.localdomain" ) (coerce-to-base "konsenti" ) (coerce-to-base "postgres" ) (coerce-to-base "mrmtzplx")))) (defparameter *UPGRADE-REPOSITORY-SPEC* (list :postmodern (list :postgresql (coerce-to-base "localhost.localdomain" ) (coerce-to-base "konsenti2" ) (coerce-to-base "postgres" ) (coerce-to-base "mrmtzplx")))) (use-package :elephant) (setq orig (open-store *REPOSITORY-SPEC*)) (setq pm (open-store *UPGRADE-REPOSITORY-SPEC*)) (migrate pm orig) On Wed, 2007-07-04 at 17:49 -0500, Robert L. Read wrote: > I have just integrated Henrik Hjelte's postmodern-based backend into > the official > darcs repository for elephant: > > http://common-lisp.net/project/elephant/darcs/elephant/ > > However, this is not an official release, but presumably will be part > of the next official release. > It passes all of the tests. The Postmodern backend is not quite twice > as fast on our testsuite as > the CL-SQL backend. The CL-SQL backend still has some value, however, > for non-Postgres > databases. If someone were to write another DB-specific backend, such > as a MySQL backend > or an Oracle backend, I would assume they would benefit from both the > CL-SQL version and > the Postmodern version. However, I think the Postmodern version is > better-written. I thank > Henrik very much for preparing such a well-written, easy-to-integrate > backend. > > I did, however, have to make three changes to get this to work for me > under SBCL. > Postmodern defines "db-error" incompatibly with the BDB backend, so I > renamed the BDB symbol > from db-error to bdb-db-error. This was one issue on a "handler-case" > that I assume was > acceptable under Henrik's LISP, but didn't work under SBCL, or seem to > follow the CLHS. > Finally, in shared-initialize :after method that builds the cache- > indices I had to explicitly > set the slot to the initform, to prevent a reading of an unbound-slot. > I still have no idea > why the slot was unbound at that point, in spite of all documentation > saying that it should be. > > I slightly modified Henrik's test to harmonize more with the CL-SQL > version, and added an > example of using postmodern into the RUNTEST.lisp file. > > Describing this in the manual remains to be done; I don't have any > immediate plans to do so. > > Personally, I think each backend adds to the overall usability of > Elephant, and should broaden > our user base. Particularly since one can migrate data from one > backend to another, it would > seem that we are offering a solid platform. > > Once this is officially released, users can expect the postmodern > backend to be supported > indefinitely. If we ever drop a backend, we will provide a way to > migrate data out of it. > > > > > > > On Sat, 2007-05-12 at 16:46 +0200, Henrik Hjelte wrote: > > > I have made some changes to the postmodern postgresql backend. The darcs > > repo is now based on the official elephant darcs repo, so patches can be > > moved between them easily. The postmodern backend passes all "official" > > tests, but has not been extensively tested with real data yet. > > > > The db-postmodern tree can be found here: > > http://common-lisp.net/project/grand-prix/darcs/elephant > > > > /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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gorbatovsky at gmail.com Tue Jul 10 23:19:37 2007 From: gorbatovsky at gmail.com (Dmitri V. Gorbatovsky) Date: Wed, 11 Jul 2007 02:19:37 +0300 Subject: [elephant-devel] garbage collection Message-ID: <200707110219.37077.dg@midasitech.com> Hello, from grateful user. I find that size of %ELEPHANT file (BDB) only grows with time and transactions. No matter how many objects I delete. Is there are any conventional way to shrink it? Sorry if the question is stupid, Iam not really advanced in Berkeley db usage. Thanks, DG From eslick at csail.mit.edu Wed Jul 11 01:32:36 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Tue, 10 Jul 2007 21:32:36 -0400 Subject: [elephant-devel] garbage collection In-Reply-To: <200707110219.37077.dg@midasitech.com> References: <200707110219.37077.dg@midasitech.com> Message-ID: <4B8F8329-7030-414B-AE6E-10886D07BE22@csail.mit.edu> Dmitri, The latest version in CVS does export a compact function that works on BDB stores, but it only truncates the end of the %ELEPHANT file and isn't very reliable because if you haven't dropped the last object added then it can't truncate at all. If you do drop objects, BDB should reuse the pages that were allocated to those objects so it should grow more slowly, but it doesn't reorganize to optimize space so fragmentation can lead to an inefficient use of space. However, the best way to reclaim disk space today is to migrate from your current BDB store to a new one. This will copy over only those objects that are globally reachable; namely anything reachable from the controller-root and all indexed instances. At some point I'll finish a wrapper function for this (currently a sketch is in src/elephant/gc.lisp and called via elephant::stop-and- copy-gc) but you are better off doing the copy manually for now. If the documentation doesn't make this process clear, please write back to us. Good luck, Ian On Jul 10, 2007, at 7:19 PM, Dmitri V. Gorbatovsky wrote: > Hello, from grateful user. > I find that size of %ELEPHANT file (BDB) only grows with > time and transactions. No matter how many objects I delete. > Is there are any conventional way to shrink it? > Sorry if the question is stupid, Iam not really advanced > in Berkeley db usage. > > Thanks, DG > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From gorbatovsky at gmail.com Wed Jul 11 18:21:05 2007 From: gorbatovsky at gmail.com (Dmitri V. Gorbatovsky) Date: Wed, 11 Jul 2007 21:21:05 +0300 Subject: [elephant-devel] garbage collection In-Reply-To: <4B8F8329-7030-414B-AE6E-10886D07BE22@csail.mit.edu> References: <200707110219.37077.dg@midasitech.com> <4B8F8329-7030-414B-AE6E-10886D07BE22@csail.mit.edu> Message-ID: <200707112121.05705.dg@midasitech.com> On Wednesday 11 July 2007 04:32, Ian Eslick wrote: > However, the best way to reclaim disk space today is to migrate from > your current BDB store to a new one. This will copy over only those > objects that are globally reachable; namely anything reachable from > the controller-root and all indexed instances. ... > If the documentation doesn't make this process clear, please write > back to us. > > Good luck, > Ian Thank you, Ian. Yes, I am afraid, I can't get it from the documentation. If it possible, could you please provide me with simple example of whole database migration from one directory ~/bdb/db-source ?to another ~/bdb/db-result. Thanks, Dmitri From eslick at csail.mit.edu Wed Jul 11 19:18:29 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 11 Jul 2007 15:18:29 -0400 Subject: [elephant-devel] garbage collection In-Reply-To: <200707112121.05705.dg@midasitech.com> References: <200707110219.37077.dg@midasitech.com> <4B8F8329-7030-414B-AE6E-10886D07BE22@csail.mit.edu> <200707112121.05705.dg@midasitech.com> Message-ID: <6C56FE00-935E-497E-9A1A-F50EF49CD3D3@csail.mit.edu> Some documentation: http://common-lisp.net/project/elephant/doc/Repository-Migration-and- Upgrade.html#Repository-Migration-and-Upgrade http://common-lisp.net/project/elephant/doc/Migration-and-Upgrading- API.html#Migration-and-Upgrading-API This is the safest route: Start lisp & load elephant: => (setf source-store (open-store '(:BDB "~/bdb/db-source"))) => (setf target-store (open-store '(:BDB "~/bdb/db-result"))) => (migrate target-store source-store) Exit and restart lisp: => (open-store '(:BDB "~/bdb/db-result")) That's it! I recommend that you run a simple validation test: - create a simple database - populating it with a bunch of data, record the size - delete 1/2 of the data randomly (or every other object) - call (optimize-layout *store-controller*), record the compacted size - do the migration as described above, record the resulting size I'm sure we'd love to see the three different sizes that result from this simple test and I'm sure you'd feel better knowing that it works! Regards, Ian On Jul 11, 2007, at 2:21 PM, Dmitri V. Gorbatovsky wrote: > On Wednesday 11 July 2007 04:32, Ian Eslick wrote: > >> However, the best way to reclaim disk space today is to migrate from >> your current BDB store to a new one. This will copy over only those >> objects that are globally reachable; namely anything reachable from >> the controller-root and all indexed instances. > ... >> If the documentation doesn't make this process clear, please write >> back to us. >> >> Good luck, >> Ian > > Thank you, Ian. > Yes, I am afraid, I can't get it from the documentation. > If it possible, could you please provide me with > simple example of whole database migration from one directory > ~/bdb/db-source to another ~/bdb/db-result. > > Thanks, Dmitri > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From gorbatovsky at gmail.com Sun Jul 15 12:51:55 2007 From: gorbatovsky at gmail.com (Dmitri V. Gorbatovsky) Date: Sun, 15 Jul 2007 15:51:55 +0300 Subject: [elephant-devel] garbage collection In-Reply-To: <6C56FE00-935E-497E-9A1A-F50EF49CD3D3@csail.mit.edu> References: <200707110219.37077.dg@midasitech.com> <200707112121.05705.dg@midasitech.com> <6C56FE00-935E-497E-9A1A-F50EF49CD3D3@csail.mit.edu> Message-ID: <200707151551.55569.dg@midasitech.com> Thanks a lot, Ian. Finally I get it right. I makes a few wrong assumptions about robustness and simplicity of general migrate procedure , consider btrees and objects references. Thanks again, Dmitri On Wednesday 11 July 2007 22:18, Ian Eslick wrote: > Some documentation: > > http://common-lisp.net/project/elephant/doc/Repository-Migration-and- > Upgrade.html#Repository-Migration-and-Upgrade > > http://common-lisp.net/project/elephant/doc/Migration-and-Upgrading- > API.html#Migration-and-Upgrading-API > > > This is the safest route: > > Start lisp & load elephant: > > => (setf source-store (open-store '(:BDB "~/bdb/db-source"))) > => (setf target-store (open-store '(:BDB "~/bdb/db-result"))) > > => (migrate target-store source-store) > > Exit and restart lisp: > > => (open-store '(:BDB "~/bdb/db-result")) > > That's it! > > I recommend that you run a simple validation test: > - create a simple database > - populating it with a bunch of data, record the size > - delete 1/2 of the data randomly (or every other object) > - call (optimize-layout *store-controller*), record the compacted size > - do the migration as described above, record the resulting size > > I'm sure we'd love to see the three different sizes that result from > this simple test and I'm sure you'd feel better knowing that it works! > > Regards, > Ian > > On Jul 11, 2007, at 2:21 PM, Dmitri V. Gorbatovsky wrote: > > On Wednesday 11 July 2007 04:32, Ian Eslick wrote: > >> However, the best way to reclaim disk space today is to migrate from > >> your current BDB store to a new one. This will copy over only those > >> objects that are globally reachable; namely anything reachable from > >> the controller-root and all indexed instances. > > > > ... > > > >> If the documentation doesn't make this process clear, please write > >> back to us. > >> > >> Good luck, > >> Ian > > > > Thank you, Ian. > > Yes, I am afraid, I can't get it from the documentation. > > If it possible, could you please provide me with > > simple example of whole database migration from one directory > > ~/bdb/db-source to another ~/bdb/db-result. > > > > Thanks, Dmitri > > _______________________________________________ > > 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 =?windows-1255?Q?=E0=EC=E5 at common-lisp.net Mon Jul 16 02:50:17 2007 From: =?windows-1255?Q?=E0=EC=E5 at common-lisp.net (=?windows-1255?Q?=E0=EC=E5 at common-lisp.net) Date: Mon, 16 Jul 2007 04:50:17 +0200 Subject: [elephant-devel] =?windows-1255?b?7Ofh+OX6IOD44uXw6e0g5fLx9+nt?= =?windows-1255?b?IC0g7Pfw5fog5ez6+OXtIOzg7OUi6A==?= Message-ID: <7e33bd98d72ff58f14e58c3b001c1c5c@gmail.com> An HTML attachment was scrubbed... URL: From emailmac at gmail.com Mon Jul 23 03:08:20 2007 From: emailmac at gmail.com (Mac Chan) Date: Sun, 22 Jul 2007 20:08:20 -0700 Subject: [elephant-devel] db-postmodern update - Integrated! Message-ID: <4877ae640707222008p1fdcd9cfn217bf2a38abf0a6d@mail.gmail.com> FYI, here's another data point. I got the latest source from darcs and ran the test on fedora fc6 + lispworks 32bit 5.0.2 All tests passed but there were some warning (I've seen similar warnings from the dbd backend). However, the test took almost one hour to finish, is that normal? ELE-TESTS 34 > (do-backend-tests) Warning: Postgres warning: CREATE TABLE / PRIMARY KEY will create implicit index "blob_pkey" for table "blob" Warning: Postgres warning: CREATE TABLE / PRIMARY KEY will create implicit index "metatree_pkey" for table "metatree" Doing 128 pending tests of 128 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 COMPLEXES 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 Second store spec missing: ignoring CROSS-STORE-REFERENCE-CONDITION UNINDEXED-CLASS-CONDITION 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 BASICPERSISTENCETesting length = 163840 KEYSIZETEST 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 Warning: Postmodern users beware, don't mix cursor-prev and cursor-set. Inefficient! Warning: Postmodern users beware, don't mix cursor-prev and cursor-set. Inefficient! MAP-INDEX-FROM-END REM-KV REM-IDEXKV MAKE-INDEXED2 ADD-INDICES2<**>wrong header in mark-pointer pointer =218766cb,header-place =218766c8 header =21e6edcd previous 214b51c4 ;>>>>> dumping 214b51c4 [1] ;> 214b51c4: 2168f25a cbbf0037 e9218766 1da086 ;>>>>> dumping 218766b8 [5] ;> 218766b8: 21e6ea25 21e6ea25 218766d4 2027d65b ;> 218766c8: 21e6edcd 21e6edcd 21e6edcd 21876760 ;> 218766d8: 203be5b1 90ff8096 21e6eee3 218766e9 ;> 218766e8: 90ff8096 21e6ec7a 218766f5 90ff8096 ;> 218766f8: 21e6ef9b 21876701 90ff8096 21c48852 <**> bad closure =214b51ca info 218766cb <**>wrong header in mark-pointer pointer =218766cb,header-place =218766c8 header =21e6edcd previous 214b5224 ;>>>>> dumping 214b5224 [1] ;> 214b5224: 2168f25a cbbf0037 e9218766 1da026 ;>>>>> dumping 218766b8 [5] ;> 218766b8: 21e6ea25 21e6ea25 218766d4 2027d65b ;> 218766c8: 21e6edcd 21e6edcd 21e6edcd 21876760 ;> 218766d8: 203be5b1 90ff8096 21e6eee3 218766e9 ;> 218766e8: 90ff8096 21e6ec7a 218766f5 90ff8096 ;> 218766f8: 21e6ef9b 21876701 90ff8096 21c48852 <**> bad closure =214b522a info 218766cb 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 PSET DISABLE-CLASS-INDEXING-TEST INDEXING-BASIC-TRIVIAL INDEXING-BASIC INDEXING-CLASS-OPT INDEXING-INHERIT INDEXING-RANGE INDEXING-SLOT-MAKUNBOUND INDEXING-WIPE-INDEX INDEXING-RECONNECT-DB INDEXING-CHANGE-CLASS INDEXING-REDEF-CLASS Ranged get of 10/700 objects = Linear: 2.52 sec Indexed: 0.76 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-MULT-PCLASS Single store mode: ignoring MIGRATE-IPCLASS No tests failed. T From henrik at evahjelte.com Mon Jul 23 21:00:46 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 23 Jul 2007 23:00:46 +0200 Subject: [elephant-devel] db-postmodern update - Integrated! In-Reply-To: <4877ae640707222008p1fdcd9cfn217bf2a38abf0a6d@mail.gmail.com> References: <4877ae640707222008p1fdcd9cfn217bf2a38abf0a6d@mail.gmail.com> Message-ID: <50e8e4f60707231400l674fc0d0h720f019a805a4fdf@mail.gmail.com> On 7/23/07, Mac Chan wrote: > FYI, here's another data point. > > I got the latest source from darcs and ran the test on fedora fc6 + > lispworks 32bit 5.0.2 > > All tests passed but there were some warning (I've seen similar > warnings from the dbd backend). > > However, the test took almost one hour to finish, is that normal? No. I haven't tried it with lispworks but these are my timings just now when running in sbcl on linux in a vmware image on a recent macbook: ;;(time (do-backend-tests)) ;; 61 secs for bdb ;; 114-122 secs for postmodern ;; 227 seconds for clsql One thing that might slow things down is if you are running on an old database. You might have to drop the testdatabase and rebuild it, since the indexes have changed quite recently. If the problem persists, can you give some more details: does it stall on a certain test? Anything else you can think off? Thanks, Henrik From henrik at evahjelte.com Tue Jul 24 07:50:34 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Tue, 24 Jul 2007 09:50:34 +0200 Subject: [elephant-devel] Fwd: some patches In-Reply-To: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> References: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> Message-ID: <50e8e4f60707240050p667670fenf7532a2398597932@mail.gmail.com> I sent this message yesterday but I guess it got stuck in the mailing list filter. Perhaps the attachment was too big. Since my common-lisp.net user hhjelte does not have write access to elephant I have placed the patches from here instead: darcs get http://common-lisp.net/project/grand-prix/darcs/elephant ---------- Forwarded message ---------- From: Henrik Hjelte Date: Jul 23, 2007 11:28 PM Subject: some patches To: elephant-devel at common-lisp.net Here are some darcs patches that might be of interest. I had some problems with map-index on db-postmodern that made me almost rip my hair of, but finally I made it to work again. The problem is that map-index for a string value rely on the ordering in the btree (continue-p makes use of less than for strings). The postmodern backend relies on how the database backend orders things, which is not always the same thing. Is it a necessary feature that b-trees of string and objects are required to be ordered by lisp-compare<=? In the process of solving the bug I have upgraded the test framework to use FiveAM instead of RT, It has in my opinion a very nice syntax and some useful features to track dependencies between tests. I hope you agree that it improves on things. /Henrik Hjelte From eslick at csail.mit.edu Tue Jul 24 13:48:37 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Tue, 24 Jul 2007 09:48:37 -0400 Subject: [elephant-devel] Fwd: some patches In-Reply-To: <50e8e4f60707240050p667670fenf7532a2398597932@mail.gmail.com> References: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> <50e8e4f60707240050p667670fenf7532a2398597932@mail.gmail.com> Message-ID: Robert and I have had some extended discussions on ordering in indices. I think that all we really need to agree on is _some_ canonical ordering. If we have mixed types in an index, how should they be ordered relative to each other? In BDB we have a C function which implements the ordering based on the type tag and then based on the type within it. Are you relying on a pure binary sort in postmodern? Robert or I will get to submitting that patch shortly. I have recently sent in a patch to lisp-compare<= so we'll see if we had to make parallel changes. Thanks, Ian On Jul 24, 2007, at 3:50 AM, Henrik Hjelte wrote: > I sent this message yesterday but I guess it got stuck in the mailing > list filter. Perhaps the attachment was too big. Since my > common-lisp.net user hhjelte does not have write access to elephant I > have placed the patches from here instead: > darcs get http://common-lisp.net/project/grand-prix/darcs/elephant > > ---------- Forwarded message ---------- > From: Henrik Hjelte > Date: Jul 23, 2007 11:28 PM > Subject: some patches > To: elephant-devel at common-lisp.net > > > Here are some darcs patches that might be of interest. I had some > problems with map-index on db-postmodern that made me almost rip my > hair of, but finally I made it to work again. The problem is that > map-index for a string value rely on the ordering in the btree > (continue-p makes use of less than for strings). The postmodern > backend relies on how the database backend orders things, which is not > always the same thing. Is it a necessary feature that b-trees of > string and objects are required to be ordered by lisp-compare<=? > > In the process of solving the bug I have upgraded the test framework > to use FiveAM instead of RT, It has in my opinion a very nice syntax > and some useful features to track dependencies between tests. I hope > you agree that it improves on things. > > /Henrik Hjelte > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From woei at yandex.ru Wed Jul 25 11:30:31 2007 From: woei at yandex.ru (woei at yandex.ru) Date: Wed, 25 Jul 2007 15:30:31 +0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" Message-ID: <200707251530.31553.woei@yandex.ru> With sqlite backend from time to time I have error "Error 5 / database is locked" I have workarounded this by wrapping calls to cl-sql with (defmacro wrapper-submacro (name &rest q) `(loop (handler-case (return (,name , at q)) (clsql:sql-condition () (sleep .05))))) I think using sqlite3_busy_timeout call is more elegant solution. But calling sqlite functions via UFFI directly from elephant doesnt seem to be a good idea. Any suggestions? From eslick at csail.mit.edu Wed Jul 25 13:44:28 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 25 Jul 2007 09:44:28 -0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: <200707251530.31553.woei@yandex.ru> References: <200707251530.31553.woei@yandex.ru> Message-ID: Are you using the SQLite data store in a multi-threaded application? Robert, how did we resolve threading for CL-SQL data stores? This sounds like a conflict where a second thread is accessing a db while the first thread has the file locked. However this is just a speculation. Ian On Jul 25, 2007, at 7:30 AM, woei at yandex.ru wrote: > With sqlite backend from time to time I have error "Error 5 / > database is > locked" > I have workarounded this by wrapping calls to cl-sql with > > (defmacro wrapper-submacro (name &rest q) > `(loop > (handler-case > (return (,name , at q)) > (clsql:sql-condition () > (sleep .05))))) > > I think using sqlite3_busy_timeout call is more elegant solution. > But calling sqlite functions via UFFI directly from elephant > doesnt seem to > be a good idea. > > Any suggestions? > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From woei at yandex.ru Wed Jul 25 14:08:48 2007 From: woei at yandex.ru (woei at yandex.ru) Date: Wed, 25 Jul 2007 18:08:48 +0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: References: <200707251530.31553.woei@yandex.ru> Message-ID: <200707251808.48115.woei@yandex.ru> ? ????????? ?? 25 ???? 2007 17:44 Ian Eslick ???????(a): > Are you using the SQLite data store in a multi-threaded application? ? > Robert, how did we resolve threading for CL-SQL data stores? ?This ? > sounds like a conflict where a second thread is accessing a db while ? > the first thread has the file locked. ?However this is just a ? > speculation. Yes, I am using sqlite in a multi-threaded application. >From sqlite wiki: Do not use the same database connection at the same time in more than one thread. From eslick at csail.mit.edu Wed Jul 25 14:17:13 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 25 Jul 2007 10:17:13 -0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: <200707251808.48115.woei@yandex.ru> References: <200707251530.31553.woei@yandex.ru> <200707251808.48115.woei@yandex.ru> Message-ID: I think that Robert implemented an approach where each thread allocated its own handle to the DB. However he should verify when he has a moment. Ian On Jul 25, 2007, at 10:08 AM, woei at yandex.ru wrote: > ? ????????? ?? 25 ???? 2007 17:44 Ian Eslick > ???????(a): >> Are you using the SQLite data store in a multi-threaded application? >> Robert, how did we resolve threading for CL-SQL data stores? This >> sounds like a conflict where a second thread is accessing a db while >> the first thread has the file locked. However this is just a >> speculation. > > Yes, I am using sqlite in a multi-threaded application. > >> From sqlite wiki: Do not use the same database connection at the >> same time in > more than one thread. > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From woei at yandex.ru Wed Jul 25 15:16:01 2007 From: woei at yandex.ru (woei at yandex.ru) Date: Wed, 25 Jul 2007 19:16:01 +0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: References: <200707251530.31553.woei@yandex.ru> <200707251808.48115.woei@yandex.ru> Message-ID: <200707251916.01671.woei@yandex.ru> ? ????????? ?? 25 ???? 2007 18:17 Ian Eslick ???????(a): > I think that Robert implemented an approach where each thread > allocated its own handle to the DB. However he should verify when he > has a moment. I think this won't help. from sqlite wiki: Note that an SQLITE_LOCKED error is distinct from SQLITE_BUSY (5). SQLITE_BUSY means that another database connection (probably in another process) is using the database in a way that prevents you from using it. SQLITE_LOCKED means the source of contention is internal and comes from the same database connection that received the SQLITE_LOCKED error. From eslick at csail.mit.edu Wed Jul 25 18:04:05 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 25 Jul 2007 14:04:05 -0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: <200707251916.01671.woei@yandex.ru> References: <200707251530.31553.woei@yandex.ru> <200707251808.48115.woei@yandex.ru> <200707251916.01671.woei@yandex.ru> Message-ID: Do you know from within what operation or transaction this is occuring? On Jul 25, 2007, at 11:16 AM, woei at yandex.ru wrote: > ? ????????? ?? 25 ???? 2007 18:17 Ian Eslick > ???????(a): >> I think that Robert implemented an approach where each thread >> allocated its own handle to the DB. However he should verify when he >> has a moment. > > I think this won't help. > > from sqlite wiki: > Note that an SQLITE_LOCKED error is distinct from SQLITE_BUSY (5). > SQLITE_BUSY > means that another database connection (probably in another > process) is using > the database in a way that prevents you from using it. > SQLITE_LOCKED means > the source of contention is internal and comes from the same database > connection that received the SQLITE_LOCKED error. > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From woei at yandex.ru Wed Jul 25 18:23:35 2007 From: woei at yandex.ru (woei at yandex.ru) Date: Wed, 25 Jul 2007 22:23:35 +0400 Subject: [elephant-devel] sqlite backend, "Error 5 / database is locked" In-Reply-To: References: <200707251530.31553.woei@yandex.ru> <200707251916.01671.woei@yandex.ru> Message-ID: <200707252223.36048.woei@yandex.ru> > Do you know from within what operation or transaction this is occuring? I had these error messages: While accessing database # with expression "SELECT VALUE FROM KEYVALUE WHERE ((CLCTN_ID = 0) AND (KEY = '...'))": Error 5 / database is locked has occurred. While accessing database # with expression "UPDATE KEYVALUE SET KEY = '...',CLCTN_ID = 0,VALUE = '...' WHERE ((CLCTN_ID = 0) AND (KEY = '...'))": Error 5 / database is locked has occurred. While accessing database # with expression "UPDATE KEYVALUE SET KEY = '...',CLCTN_ID = 0,VALUE = '...' WHERE ((CLCTN_ID = 0) AND (KEY = '...'))": Error 5 / database is locked has occurred. I don't use with-transaction or ensure-transaction macro. From henrik at evahjelte.com Mon Jul 23 21:28:06 2007 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 23 Jul 2007 23:28:06 +0200 Subject: [elephant-devel] some patches Message-ID: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> Here are some darcs patches that might be of interest. I had some problems with map-index on db-postmodern that made me almost rip my hair of, but finally I made it to work again. The problem is that map-index for a string value rely on the ordering in the btree (continue-p makes use of less than for strings). The postmodern backend relies on how the database backend orders things, which is not always the same thing. Is it a necessary feature that b-trees of string and objects are required to be ordered by lisp-compare<=? In the process of solving the bug I have upgraded the test framework to use FiveAM instead of RT, It has in my opinion a very nice syntax and some useful features to track dependencies between tests. I hope you agree that it improves on things. /Henrik Hjelte -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.bundle Type: application/octet-stream Size: 85963 bytes Desc: not available URL: From read at robertlread.net Tue Jul 31 16:50:39 2007 From: read at robertlread.net (Robert L. Read) Date: Tue, 31 Jul 2007 11:50:39 -0500 Subject: [elephant-devel] Fwd: some patches In-Reply-To: References: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> <50e8e4f60707240050p667670fenf7532a2398597932@mail.gmail.com> Message-ID: <1185900639.4846.229.camel@localhost.localdomain> Personally, I think the only sensible way to handle this problem is to require the user to specify an ordering function. We can of course provide a default, which will be error-prone but tend to work most of the time. The function called "my-generic-less-than" which is in the source tree now could be a starting point for a generic ordering. On Tue, 2007-07-24 at 09:48 -0400, Ian Eslick wrote: > Robert and I have had some extended discussions on ordering in > indices. I think that all we really need to agree on is _some_ > canonical ordering. If we have mixed types in an index, how should > they be ordered relative to each other? In BDB we have a C function > which implements the ordering based on the type tag and then based on > the type within it. Are you relying on a pure binary sort in > postmodern? > > Robert or I will get to submitting that patch shortly. I have > recently sent in a patch to lisp-compare<= so we'll see if we had to > make parallel changes. > > > Thanks, > Ian > > On Jul 24, 2007, at 3:50 AM, Henrik Hjelte wrote: > > > I sent this message yesterday but I guess it got stuck in the mailing > > list filter. Perhaps the attachment was too big. Since my > > common-lisp.net user hhjelte does not have write access to elephant I > > have placed the patches from here instead: > > darcs get http://common-lisp.net/project/grand-prix/darcs/elephant > > > > ---------- Forwarded message ---------- > > From: Henrik Hjelte > > Date: Jul 23, 2007 11:28 PM > > Subject: some patches > > To: elephant-devel at common-lisp.net > > > > > > Here are some darcs patches that might be of interest. I had some > > problems with map-index on db-postmodern that made me almost rip my > > hair of, but finally I made it to work again. The problem is that > > map-index for a string value rely on the ordering in the btree > > (continue-p makes use of less than for strings). The postmodern > > backend relies on how the database backend orders things, which is not > > always the same thing. Is it a necessary feature that b-trees of > > string and objects are required to be ordered by lisp-compare<=? > > > > In the process of solving the bug I have upgraded the test framework > > to use FiveAM instead of RT, It has in my opinion a very nice syntax > > and some useful features to track dependencies between tests. I hope > > you agree that it improves on things. > > > > /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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Tue Jul 31 19:24:39 2007 From: eslick at csail.mit.edu (Ian Eslick) Date: Tue, 31 Jul 2007 15:24:39 -0400 Subject: [elephant-devel] Fwd: some patches In-Reply-To: <1185900639.4846.229.camel@localhost.localdomain> References: <50e8e4f60707231428n524e337ey1d0a7909bbf9ae6e@mail.gmail.com> <50e8e4f60707240050p667670fenf7532a2398597932@mail.gmail.com> <1185900639.4846.229.camel@localhost.localdomain> Message-ID: <93791CD1-7CAF-4B91-B9F8-077D5D148BA9@csail.mit.edu> The practical problem that led to the current design of index sorting is that we cannot use lisp code to define the sorting function for serialized values inside BDB Btrees (same problem I imagine that Henrik had with postmodern). Instead, there is a hairy custom C procedure that is registered with BDB that parses the serialized format so that sorting is done first by type (symbol, string, object, pobject, etc) followed by ordering within numeric types, strings and symbols. Everything else is ordered based on the byte ordering of its serialized representation. To map across indices correctly, we need to know up front whether the start value is less than the end value. And so we need a standard lisp function that is isomorphic to the BDB sorting function. Ideally postmodern would have a similar sorting function that properly interprets the serialized format just like the BDB function does. I think it's best to have a single standard ordering that is as close to lisp's notion of ordering as possible so we don't have to maintain different orderings. Ian PS - It might be possible to have a lisp ordering function implement BDB's notion of sorting by registering it as a callback, however it would have to deserialize the BDB values each time. So the problems with this are both stability concerns for foreign callbacks and the performance impact of serialization/deserialization for internal BDB operations. On the cleanliness/performance axis, I think the current approach is the right tradeoff (it's the original one Ben made, FYI). On Jul 31, 2007, at 12:50 PM, Robert L. Read wrote: > Personally, I think the only sensible way to handle this problem is > to require the user to > specify an ordering function. We can of course provide a default, > which will be error-prone > but tend to work most of the time. > > The function called "my-generic-less-than" which is in the source > tree now could be > a starting point for a generic ordering. > > > On Tue, 2007-07-24 at 09:48 -0400, Ian Eslick wrote: >> Robert and I have had some extended discussions on ordering in >> indices. I think that all we really need to agree on is _some_ >> canonical ordering. If we have mixed types in an index, how should >> they be ordered relative to each other? In BDB we have a C >> function which implements the ordering based on the type tag and >> then based on the type within it. Are you relying on a pure binary >> sort in postmodern? Robert or I will get to submitting that patch >> shortly. I have recently sent in a patch to lisp-compare<= so >> we'll see if we had to make parallel changes. Thanks, Ian On Jul >> 24, 2007, at 3:50 AM, Henrik Hjelte wrote: > I sent this message >> yesterday but I guess it got stuck in the mailing > list filter. >> Perhaps the attachment was too big. Since my > common-lisp.net >> user hhjelte does not have write access to elephant I > have >> placed the patches from here instead: > darcs get http://common- >> lisp.net/project/grand-prix/darcs/elephant > > ---------- >> Forwarded message ---------- > From: Henrik Hjelte >> > Date: Jul 23, 2007 11:28 PM > Subject: >> some patches > To: elephant-devel at common-lisp.net > > > Here are >> some darcs patches that might be of interest. I had some > >> problems with map-index on db-postmodern that made me almost rip >> my > hair of, but finally I made it to work again. The problem is >> that > map-index for a string value rely on the ordering in the >> btree > (continue-p makes use of less than for strings). The >> postmodern > backend relies on how the database backend orders >> things, which is not > always the same thing. Is it a necessary >> feature that b-trees of > string and objects are required to be >> ordered by lisp-compare<=? > > In the process of solving the bug I >> have upgraded the test framework > to use FiveAM instead of RT, It >> has in my opinion a very nice syntax > and some useful features to >> track dependencies between tests. I hope > you agree that it >> improves on things. > > /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