From eslick at csail.mit.edu Sun Feb 5 23:18:40 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 05 Feb 2006 18:18:40 -0500 Subject: [elephant-devel] Bug in classes.lisp effected Migrate5 in 0.5.0-rc1 Message-ID: <43E687D0.1040607@csail.mit.edu> The slot-boundp-using-class function looks for slots with type eq to 'persistent-slot-definition and should be looking for any subtype of that base type. (i.e. under allegro the returned slot is a persistent-effective-slot-definition and not 'persistent-slot-definition). Also, the loop clause in slot-boundp-using-class under allegro (and slot-makunbound-using-class) that operates on a symbol fails to return a t value. It appears that the 'finally' clause does not provide the loop value which seems to jive with the loop spec. Perhaps some loop implementations allow finally to return but mine was unhappy depending on that so I just did finally (return ...) which is unambiguous. I checked in these fixes into HEAD-0.5.0-rc1 can can confirm that all tests under Allegro 7.0 using BDB 4.3 and SQLite3 now pass. Cheers, Ian From read at robertlread.net Sun Feb 5 23:44:07 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 05 Feb 2006 17:44:07 -0600 Subject: [elephant-devel] Re: Bug in classes.lisp effected Migrate5 in 0.5.0-rc1 In-Reply-To: <43E687D0.1040607@csail.mit.edu> References: <43E687D0.1040607@csail.mit.edu> Message-ID: <1139183048.4658.234.camel@localhost.localdomain> Fabulous! I will test again under SBCL and then cut the 0.5.0 release if it passes. We have made some small changes that might have broken OpenMCL, but I assume that risk is worth ignoring. If an OpenMCLer gets this message and feels like running the tests, that would be good. On Sun, 2006-02-05 at 18:18 -0500, Ian Eslick wrote: > The slot-boundp-using-class function looks for slots with type eq to > 'persistent-slot-definition and should be looking for any subtype of > that base type. (i.e. under allegro the returned slot is a > persistent-effective-slot-definition and not 'persistent-slot-definition). > > Also, the loop clause in slot-boundp-using-class under allegro (and > slot-makunbound-using-class) that operates on a symbol fails to return a > t value. It appears that the 'finally' clause does not provide the loop > value which seems to jive with the loop spec. Perhaps some loop > implementations allow finally to return but mine was unhappy depending > on that so I just did finally (return ...) which is unambiguous. > > I checked in these fixes into HEAD-0.5.0-rc1 can can confirm that all > tests under Allegro 7.0 using BDB 4.3 and SQLite3 now pass. > > Cheers, > Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Mon Feb 6 02:39:23 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 05 Feb 2006 20:39:23 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL Message-ID: <1139193563.4658.243.camel@localhost.localdomain> Elephant 0.5.0 is now available under the LLGPL. I put the following text on the project website: The latest version is 0.5.0, release Feb. 5, 2006. It is released under the LLGPL. This version works with ACL, OpenMCL, and SBCL with or without Unicode support. It has significant bug fixes over 0.4.0, especially with respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, and Waldo Rubinstein. The tutorial and documentation are improved, but may still lag the source code in some ways. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From waldo at trianet.net Mon Feb 6 02:51:40 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Sun, 5 Feb 2006 21:51:40 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <1139193563.4658.243.camel@localhost.localdomain> References: <1139193563.4658.243.camel@localhost.localdomain> Message-ID: <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> Just downloaded this version and already ran into a little problem. The new sleepycat libraries are built with .dylib extension for Mac OSX. However, when I launch OpenMCL, it complaints that it cannot find libmemutil.so and does not even look for libmemutil.dylib. It looks like the actual elephant library is not synchronized with the Makefile, or something like that. Thanks, Waldo On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > Elephant 0.5.0 is now available under the LLGPL. > > I put the following text on the project website: > > > The latest version is 0.5.0, release Feb. 5, 2006. It is released > under the LLGPL. This version works with ACL, OpenMCL, and SBCL > with or without Unicode support. It has significant bug fixes over > 0.4.0, especially with respect to OpenMCL and ACL. Thanks to Andrew > Blumberg, Ian Eslick, and Waldo Rubinstein. The tutorial and > documentation are improved, but may still lag the source code in > some ways. > > > > ---- > Robert L. Read, PhD read &T > robertlread.net > Consider visiting Progressive Engineering: http:// > robertlread.net/pe > In Austin: 912-8593 "Think > globally, Act locally." -- RBF > > > _______________________________________________ > 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 6 04:03:20 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 05 Feb 2006 23:03:20 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> Message-ID: <43E6CA88.8040308@csail.mit.edu> Does OpenMCL use darwin or macosx in the *features* variable? In sleepycat.lisp there's a #+macosx and #-macosx around the form assigned to *c-library-extension* which is used to figure out which library type to load (dylib or so). If you modify this to #+(or macosx darwin) that should fix it. I'll look around for other macosx only reader conditionals I stuck in there. Under Allegro they use macosx and not darwin. Does OpenMCL require dylibs or so's? Ian Waldo Rubinstein wrote: > Just downloaded this version and already ran into a little problem. > > The new sleepycat libraries are built with .dylib extension for Mac > OSX. However, when I launch OpenMCL, it complaints that it cannot find > libmemutil.so and does not even look for libmemutil.dylib. > > It looks like the actual elephant library is not synchronized with the > Makefile, or something like that. > > Thanks, > Waldo > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > >> Elephant 0.5.0 is now available under the LLGPL. >> >> I put the following text on the project website: >> >> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released >> under the LLGPL . This >> version works with ACL, OpenMCL, and SBCL with or without Unicode >> support. It has significant bug fixes over 0.4.0, especially with >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, >> and Waldo Rubinstein. The tutorial and documentation are improved, >> but may still lag the source code in some ways. >> >> >> >> ---- >> Robert L. Read, PhD read &T >> robertlread.net >> Consider visiting Progressive Engineering: http://robertlread.net/pe >> In Austin: 912-8593 "Think >> globally, Act locally." -- RBF >> >> >> _______________________________________________ >> 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 read at robertlread.net Mon Feb 6 04:13:54 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 05 Feb 2006 22:13:54 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <43E6CA88.8040308@csail.mit.edu> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> Message-ID: <1139199234.4658.246.camel@localhost.localdomain> Also I changed the default directory from "elephant-0-3" to just "elephant" at the end of the path, that might create a problem for someone. I should have documented that more thoroughly. On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > Does OpenMCL use darwin or macosx in the *features* variable? In > sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > to *c-library-extension* which is used to figure out which library type > to load (dylib or so). If you modify this to #+(or macosx darwin) that > should fix it. I'll look around for other macosx only reader > conditionals I stuck in there. Under Allegro they use macosx and not > darwin. > > Does OpenMCL require dylibs or so's? > > Ian > > Waldo Rubinstein wrote: > > Just downloaded this version and already ran into a little problem. > > > > The new sleepycat libraries are built with .dylib extension for Mac > > OSX. However, when I launch OpenMCL, it complaints that it cannot find > > libmemutil.so and does not even look for libmemutil.dylib. > > > > It looks like the actual elephant library is not synchronized with the > > Makefile, or something like that. > > > > Thanks, > > Waldo > > > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > > > >> Elephant 0.5.0 is now available under the LLGPL. > >> > >> I put the following text on the project website: > >> > >> > >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > >> under the LLGPL . This > >> version works with ACL, OpenMCL, and SBCL with or without Unicode > >> support. It has significant bug fixes over 0.4.0, especially with > >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > >> and Waldo Rubinstein. The tutorial and documentation are improved, > >> but may still lag the source code in some ways. > >> > >> > >> > >> ---- > >> Robert L. Read, PhD read &T > >> robertlread.net > >> Consider visiting Progressive Engineering: http://robertlread.net/pe > >> In Austin: 912-8593 "Think > >> globally, Act locally." -- RBF > >> > >> > >> _______________________________________________ > >> 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 waldo at trianet.net Mon Feb 6 06:19:29 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Mon, 6 Feb 2006 01:19:29 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <1139199234.4658.246.camel@localhost.localdomain> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> Message-ID: I had noticed that I changed it to point to the .dylib path, but it still failed. BTW, OpenMCL's *features*: ? *features* (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32- BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST :OPENMCL- PRIVATE-HASH-TABLES) - Waldo On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > Also I changed the default directory from "elephant-0-3" to just > "elephant" at the > end of the path, that might create a problem for someone. I should > have documented > that more thoroughly. > > > On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >> Does OpenMCL use darwin or macosx in the *features* variable? In >> sleepycat.lisp there's a #+macosx and #-macosx around the form >> assigned >> to *c-library-extension* which is used to figure out which library >> type >> to load (dylib or so). If you modify this to #+(or macosx darwin) >> that >> should fix it. I'll look around for other macosx only reader >> conditionals I stuck in there. Under Allegro they use macosx and not >> darwin. >> >> Does OpenMCL require dylibs or so's? >> >> Ian >> >> Waldo Rubinstein wrote: >> > Just downloaded this version and already ran into a little problem. >> > >> > The new sleepycat libraries are built with .dylib extension for Mac >> > OSX. However, when I launch OpenMCL, it complaints that it >> cannot find >> > libmemutil.so and does not even look for libmemutil.dylib. >> > >> > It looks like the actual elephant library is not synchronized >> with the >> > Makefile, or something like that. >> > >> > Thanks, >> > Waldo >> > >> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: >> > >> >> Elephant 0.5.0 is now available under the LLGPL. >> >> >> >> I put the following text on the project website: >> >> >> >> >> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released >> >> under the LLGPL . This >> >> version works with ACL, OpenMCL, and SBCL with or without Unicode >> >> support. It has significant bug fixes over 0.4.0, especially with >> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, >> >> and Waldo Rubinstein. The tutorial and documentation are improved, >> >> but may still lag the source code in some ways. >> >> >> >> >> >> >> >> ---- >> >> Robert L. Read, PhD read &T >> >> robertlread.net >> >> Consider visiting Progressive Engineering: http:// >> robertlread.net/pe >> >> In Austin: 912-8593 "Think >> >> globally, Act locally." -- RBF >> >> >> >> >> >> _______________________________________________ >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Mon Feb 6 13:55:34 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 06 Feb 2006 07:55:34 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> Message-ID: <1139234134.4658.253.camel@localhost.localdomain> I'm a little confused by this; other than the default path, I don't think we changed changed anything related to this from the most recent version that you tested. Here are two additional questions: 1) Does libmemutil.so exist on your system? If so, does the *elephant- lib-path* correctly point to it? 2) If you run "make", does it not build libmemutil.so? I suspect this is more an installation/path issue than a problem. The released version is only slightly different than the version you tested a few days ago. Waldo wrote: Just downloaded this version and already ran into a little problem. The new sleepycat libraries are built with .dylib extension for Mac OSX. However, when I launch OpenMCL, it complaints that it cannot find libmemutil.so and does not even look for libmemutil.dylib. It looks like the actual elephant library is not synchronized with the Makefile, or something like that. Thanks, Waldo On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: > I had noticed that I changed it to point to the .dylib path, but it > still failed. > > > BTW, OpenMCL's *features*: > > > ? *features* > (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- > LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- > THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- > MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- > HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32- > BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST :OPENMCL- > PRIVATE-HASH-TABLES) > > > - Waldo > > On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > > > > Also I changed the default directory from "elephant-0-3" to just > > "elephant" at the > > end of the path, that might create a problem for someone. I should > > have documented > > that more thoroughly. > > > > > > On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > > > > > Does OpenMCL use darwin or macosx in the *features* variable? In > > > sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > > > to *c-library-extension* which is used to figure out which library type > > > to load (dylib or so). If you modify this to #+(or macosx darwin) that > > > should fix it. I'll look around for other macosx only reader > > > conditionals I stuck in there. Under Allegro they use macosx and not > > > darwin. > > > > > > Does OpenMCL require dylibs or so's? > > > > > > Ian > > > > > > Waldo Rubinstein wrote: > > > > Just downloaded this version and already ran into a little problem. > > > > > > > > The new sleepycat libraries are built with .dylib extension for Mac > > > > OSX. However, when I launch OpenMCL, it complaints that it cannot find > > > > libmemutil.so and does not even look for libmemutil.dylib. > > > > > > > > It looks like the actual elephant library is not synchronized with the > > > > Makefile, or something like that. > > > > > > > > Thanks, > > > > Waldo > > > > > > > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > > > > > > > >> Elephant 0.5.0 is now available under the LLGPL. > > > >> > > > >> I put the following text on the project website: > > > >> > > > >> > > > >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > > > >> under the LLGPL . This > > > >> version works with ACL, OpenMCL, and SBCL with or without Unicode > > > >> support. It has significant bug fixes over 0.4.0, especially with > > > >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > > > >> and Waldo Rubinstein. The tutorial and documentation are improved, > > > >> but may still lag the source code in some ways. > > > >> > > > >> > > > >> > > > >> ---- > > > >> Robert L. Read, PhD read &T > > > >> robertlread.net > > > >> Consider visiting Progressive Engineering: http://robertlread.net/pe > > > >> In Austin: 912-8593 "Think > > > >> globally, Act locally." -- RBF > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 waldo at trianet.net Mon Feb 6 14:12:50 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Mon, 6 Feb 2006 09:12:50 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <1139234134.4658.253.camel@localhost.localdomain> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> Message-ID: In the previous versions of elephant, "make" built the corresponding .so files. In this latest version, it builds .dylib files (at least on my Mac). I did correct the controller.lisp and bdb-enable.lisp to point to the new elephant library path instead of the elephant-0.3 path. However, it still complaints about not finding libmemutil.so. It's like it doesn't even bother to look for libmemutil.dylib. - Waldo On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > I'm a little confused by this; other than the default path, I don't > think we changed > changed anything related to this from the most recent version that > you tested. > > Here are two additional questions: > > 1) Does libmemutil.so exist on your system? If so, does the > *elephant-lib-path* > correctly point to it? > > 2) If you run "make", does it not build libmemutil.so? > > I suspect this is more an installation/path issue than a problem. > The released version > is only slightly different than the version you tested a few days ago. > > > > Waldo wrote: > > Just downloaded this version and already ran into a little problem. > > > The new sleepycat libraries are built with .dylib extension for Mac > OSX. However, when I launch OpenMCL, it complaints that it cannot > find libmemutil.so and does not even look for libmemutil.dylib. > > > It looks like the actual elephant library is not synchronized with > the Makefile, or something like that. > > > Thanks, > Waldo > > On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: >> I had noticed that I changed it to point to the .dylib path, but >> it still failed. >> >> >> BTW, OpenMCL's *features*: >> >> >> ? *features* >> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- >> LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- >> THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- >> MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- >> HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET : >> 32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN- >> HOST :OPENMCL-PRIVATE-HASH-TABLES) >> >> >> - Waldo >> >> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: >> >>> Also I changed the default directory from "elephant-0-3" to just >>> "elephant" at the >>> end of the path, that might create a problem for someone. I >>> should have documented >>> that more thoroughly. >>> >>> >>> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >>>> Does OpenMCL use darwin or macosx in the *features* variable? In >>>> sleepycat.lisp there's a #+macosx and #-macosx around the form >>>> assigned >>>> to *c-library-extension* which is used to figure out which >>>> library type >>>> to load (dylib or so). If you modify this to #+(or macosx >>>> darwin) that >>>> should fix it. I'll look around for other macosx only reader >>>> conditionals I stuck in there. Under Allegro they use macosx >>>> and not >>>> darwin. >>>> >>>> Does OpenMCL require dylibs or so's? >>>> >>>> Ian >>>> >>>> Waldo Rubinstein wrote: >>>> > Just downloaded this version and already ran into a little >>>> problem. >>>> > >>>> > The new sleepycat libraries are built with .dylib extension >>>> for Mac >>>> > OSX. However, when I launch OpenMCL, it complaints that it >>>> cannot find >>>> > libmemutil.so and does not even look for libmemutil.dylib. >>>> > >>>> > It looks like the actual elephant library is not synchronized >>>> with the >>>> > Makefile, or something like that. >>>> > >>>> > Thanks, >>>> > Waldo >>>> > >>>> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: >>>> > >>>> >> Elephant 0.5.0 is now available under the LLGPL. >>>> >> >>>> >> I put the following text on the project website: >>>> >> >>>> >> >>>> >> The latest version is 0.5.0, release Feb. 5, 2006. It is >>>> released >>>> >> under the LLGPL . >>>> This >>>> >> version works with ACL, OpenMCL, and SBCL with or without >>>> Unicode >>>> >> support. It has significant bug fixes over 0.4.0, especially >>>> with >>>> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian >>>> Eslick, >>>> >> and Waldo Rubinstein. The tutorial and documentation are >>>> improved, >>>> >> but may still lag the source code in some ways. >>>> >> >>>> >> >>>> >> >>>> >> ---- >>>> >> Robert L. Read, PhD read &T >>>> >> robertlread.net >>>> >> Consider visiting Progressive Engineering: http:// >>>> robertlread.net/pe >>>> >> In Austin: 912-8593 >>>> "Think >>>> >> globally, Act locally." -- RBF >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Mon Feb 6 14:43:55 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 06 Feb 2006 08:43:55 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> Message-ID: <1139237035.12408.3.camel@localhost.localdomain> The makefile makes a switch based on what "uname -s" returns from the shell. What does it return from your system? It looks like Ian put this in, and perhaps his Mac version is different than yours. I personally have zero knowledge of dylibs vs. .so's or anything else relating to Mac stuff. You can change the Makefile easily enough to produce the .so, by assigning to the EXT variable, for example. On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: > In the previous versions of elephant, "make" built the > corresponding .so files. In this latest version, it builds .dylib > files (at least on my Mac). > > > I did correct the controller.lisp and bdb-enable.lisp to point to the > new elephant library path instead of the elephant-0.3 path. > > > However, it still complaints about not finding libmemutil.so. It's > like it doesn't even bother to look for libmemutil.dylib. > > > - Waldo > > On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > > > > I'm a little confused by this; other than the default path, I don't > > think we changed > > changed anything related to this from the most recent version that > > you tested. > > > > Here are two additional questions: > > > > 1) Does libmemutil.so exist on your system? If so, does the > > *elephant-lib-path* > > correctly point to it? > > > > 2) If you run "make", does it not build libmemutil.so? > > > > I suspect this is more an installation/path issue than a problem. > > The released version > > is only slightly different than the version you tested a few days > > ago. > > > > > > > > Waldo wrote: > > > > Just downloaded this version and already ran into a little problem. > > > > > > The new sleepycat libraries are built with .dylib extension for Mac > > OSX. However, when I launch OpenMCL, it complaints that it cannot > > find libmemutil.so and does not even look for libmemutil.dylib. > > > > > > It looks like the actual elephant library is not synchronized with > > the Makefile, or something like that. > > > > > > Thanks, > > Waldo > > > > On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: > > > > > I had noticed that I changed it to point to the .dylib path, but > > > it still failed. > > > > > > > > > BTW, OpenMCL's *features*: > > > > > > > > > ? *features* > > > (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- > > > LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- > > > THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- > > > MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- > > > HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN- > > > TARGET :32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN- > > > HOST :OPENMCL-PRIVATE-HASH-TABLES) > > > > > > > > > - Waldo > > > > > > On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > > > > > > > > > > Also I changed the default directory from "elephant-0-3" to just > > > > "elephant" at the > > > > end of the path, that might create a problem for someone. I > > > > should have documented > > > > that more thoroughly. > > > > > > > > > > > > On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > > > > > > > > > Does OpenMCL use darwin or macosx in the *features* variable? In > > > > > sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > > > > > to *c-library-extension* which is used to figure out which library type > > > > > to load (dylib or so). If you modify this to #+(or macosx darwin) that > > > > > should fix it. I'll look around for other macosx only reader > > > > > conditionals I stuck in there. Under Allegro they use macosx and not > > > > > darwin. > > > > > > > > > > Does OpenMCL require dylibs or so's? > > > > > > > > > > Ian > > > > > > > > > > Waldo Rubinstein wrote: > > > > > > Just downloaded this version and already ran into a little problem. > > > > > > > > > > > > The new sleepycat libraries are built with .dylib extension for Mac > > > > > > OSX. However, when I launch OpenMCL, it complaints that it cannot find > > > > > > libmemutil.so and does not even look for libmemutil.dylib. > > > > > > > > > > > > It looks like the actual elephant library is not synchronized with the > > > > > > Makefile, or something like that. > > > > > > > > > > > > Thanks, > > > > > > Waldo > > > > > > > > > > > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > > > > > > > > > > > >> Elephant 0.5.0 is now available under the LLGPL. > > > > > >> > > > > > >> I put the following text on the project website: > > > > > >> > > > > > >> > > > > > >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > > > > > >> under the LLGPL . This > > > > > >> version works with ACL, OpenMCL, and SBCL with or without Unicode > > > > > >> support. It has significant bug fixes over 0.4.0, especially with > > > > > >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > > > > > >> and Waldo Rubinstein. The tutorial and documentation are improved, > > > > > >> but may still lag the source code in some ways. > > > > > >> > > > > > >> > > > > > >> > > > > > >> ---- > > > > > >> Robert L. Read, PhD read &T > > > > > >> robertlread.net > > > > > >> Consider visiting Progressive Engineering: http://robertlread.net/pe > > > > > >> In Austin: 912-8593 "Think > > > > > >> globally, Act locally." -- RBF > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 waldo at trianet.net Mon Feb 6 15:11:10 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Mon, 6 Feb 2006 10:11:10 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <1139237035.12408.3.camel@localhost.localdomain> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <1139237035.12408.3.camel@localhost.localdomain> Message-ID: Yeah. I would assume it would have to be something like that. I know I can change the build to produce .so files, but I thought this change was made intentionally to produce .dylibs and that's the reason I didn't want to touch it. Anyway, when I run uname -a I get: waldo:~ waldo$ uname -a Darwin waldo.local 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc Simply changing the EXT variable to so makes it work just fine. BTW, once that change is in place, I ran the BDB tests and they all ran fine on OpenMCL: ELE-TESTS> (do-all-tests-spec *testdb-path*) Doing 106 pending tests of 106 tests total. FIXNUMS FIXNUM-TYPE-1 BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 ARRAYS-2 TEST-DEEP-EQUALP OBJECTS 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-CLASS2 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 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 PREPARES-SLEEPYCAT TEST-SEQ1 TEST-SEQ2 CLEANSUP-SLEEPYCAT REMOVE-ELEMENT MIGRATE1 MIGRATE2 MIGRATE3 MIGRATE4 MIGRATE5 No tests failed. T - Waldo On Feb 6, 2006, at 9:43 AM, Robert L. Read wrote: > The makefile makes a switch based on what "uname -s" returns from > the shell. > > What does it return from your system? > > It looks like Ian put this in, and perhaps his Mac version is > different than yours. > > I personally have zero knowledge of dylibs vs. .so's or anything > else relating > to Mac stuff. > > You can change the Makefile easily enough to produce the .so, by > assigning to > the EXT variable, for example. > > > On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: >> In the previous versions of elephant, "make" built the >> corresponding .so files. In this latest version, it builds .dylib >> files (at least on my Mac). >> >> >> I did correct the controller.lisp and bdb-enable.lisp to point to >> the new elephant library path instead of the elephant-0.3 path. >> >> >> However, it still complaints about not finding libmemutil.so. It's >> like it doesn't even bother to look for libmemutil.dylib. >> >> >> - Waldo >> >> On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: >> >>> I'm a little confused by this; other than the default path, I >>> don't think we changed >>> changed anything related to this from the most recent version >>> that you tested. >>> >>> Here are two additional questions: >>> >>> 1) Does libmemutil.so exist on your system? If so, does the >>> *elephant-lib-path* >>> correctly point to it? >>> >>> 2) If you run "make", does it not build libmemutil.so? >>> >>> I suspect this is more an installation/path issue than a >>> problem. The released version >>> is only slightly different than the version you tested a few days >>> ago. >>> >>> >>> >>> Waldo wrote: >>> >>> Just downloaded this version and already ran into a little problem. >>> >>> >>> The new sleepycat libraries are built with .dylib extension for >>> Mac OSX. However, when I launch OpenMCL, it complaints that it >>> cannot find libmemutil.so and does not even look for >>> libmemutil.dylib. >>> >>> >>> It looks like the actual elephant library is not synchronized >>> with the Makefile, or something like that. >>> >>> >>> Thanks, >>> Waldo >>> >>> On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: >>>> I had noticed that I changed it to point to the .dylib path, but >>>> it still failed. >>>> >>>> >>>> BTW, OpenMCL's *features*: >>>> >>>> >>>> ? *features* >>>> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- >>>> LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- >>>> THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- >>>> MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- >>>> HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN- >>>> TARGET :32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG- >>>> ENDIAN-HOST :OPENMCL-PRIVATE-HASH-TABLES) >>>> >>>> >>>> - Waldo >>>> >>>> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: >>>> >>>>> Also I changed the default directory from "elephant-0-3" to >>>>> just "elephant" at the >>>>> end of the path, that might create a problem for someone. I >>>>> should have documented >>>>> that more thoroughly. >>>>> >>>>> >>>>> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >>>>>> Does OpenMCL use darwin or macosx in the *features* variable? In >>>>>> sleepycat.lisp there's a #+macosx and #-macosx around the form >>>>>> assigned >>>>>> to *c-library-extension* which is used to figure out which >>>>>> library type >>>>>> to load (dylib or so). If you modify this to #+(or macosx >>>>>> darwin) that >>>>>> should fix it. I'll look around for other macosx only reader >>>>>> conditionals I stuck in there. Under Allegro they use macosx >>>>>> and not >>>>>> darwin. >>>>>> >>>>>> Does OpenMCL require dylibs or so's? >>>>>> >>>>>> Ian >>>>>> >>>>>> Waldo Rubinstein wrote: >>>>>> > Just downloaded this version and already ran into a little >>>>>> problem. >>>>>> > >>>>>> > The new sleepycat libraries are built with .dylib extension >>>>>> for Mac >>>>>> > OSX. However, when I launch OpenMCL, it complaints that it >>>>>> cannot find >>>>>> > libmemutil.so and does not even look for libmemutil.dylib. >>>>>> > >>>>>> > It looks like the actual elephant library is not >>>>>> synchronized with the >>>>>> > Makefile, or something like that. >>>>>> > >>>>>> > Thanks, >>>>>> > Waldo >>>>>> > >>>>>> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: >>>>>> > >>>>>> >> Elephant 0.5.0 is now available under the LLGPL. >>>>>> >> >>>>>> >> I put the following text on the project website: >>>>>> >> >>>>>> >> >>>>>> >> The latest version is 0.5.0, release Feb. 5, 2006. It is >>>>>> released >>>>>> >> under the LLGPL >>>>> preamble.html>. This >>>>>> >> version works with ACL, OpenMCL, and SBCL with or without >>>>>> Unicode >>>>>> >> support. It has significant bug fixes over 0.4.0, >>>>>> especially with >>>>>> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian >>>>>> Eslick, >>>>>> >> and Waldo Rubinstein. The tutorial and documentation are >>>>>> improved, >>>>>> >> but may still lag the source code in some ways. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> ---- >>>>>> >> Robert L. Read, PhD >>>>>> read &T >>>>>> >> robertlread.net >>>>>> >> Consider visiting Progressive Engineering: http:// >>>>>> robertlread.net/pe >>>>>> >> In Austin: 912-8593 >>>>>> "Think >>>>>> >> globally, Act locally." -- RBF >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> elephant-devel site list >>>>>> >> elephant-devel at common-lisp.net >>>>> 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 6 15:22:00 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 06 Feb 2006 10:22 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> Message-ID: <4737-SnapperMsg01518A7FC00D1A3B@208.54.103.134> Did you not get my earlier e-mail about adding #+(or macosx darwin) to sleepycat.lisp in place of #+macosx? That will fix it for MCL. We also need to do something about user system-specific dependencies. Folks should not have to modify sources to get things personalized to their system. One option is to use asdf-config as an option which was designed to allow user config of params without requiring source modification... Ian ___ Sent with SnapperMail www.snappermail.com ..... Original Message ....... On Mon, 6 Feb 2006 09:12:50 -0500 "Waldo Rubinstein" wrote: >In the previous versions of elephant, "make" built the corresponding .so files. In this latest version, it builds .dylib files (at least on my Mac). > >I did correct the controller.lisp and bdb-enable.lisp to point to the new elephant library path instead of the elephant-0.3 path. > >However, it still complaints about not finding libmemutil.so. It's like it doesn't even bother to look for libmemutil.dylib. > >- Waldo > >On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > > >I'm a little confused by this; other than the default path, I don't think we changed >changed anything related to this from the most recent version that you tested. > >Here are two additional questions: > >1)? Does libmemutil.so exist on your system?? If so, does the *elephant-lib-path* >correctly point to it? > >2)? If you run "make", does it not build libmemutil.so? > >I suspect this is more an installation/path issue than a problem.? The released version >is only slightly different than the version you tested a few days ago. > > > >Waldo wrote: > >Just downloaded this version and already ran into a little problem. > > >The new sleepycat libraries are built with .dylib extension for Mac OSX. However, when I launch OpenMCL, it complaints that it cannot find libmemutil.so and does not even look for libmemutil.dylib. > > >It looks like the actual elephant library is not synchronized with the Makefile, or something like that. > > >Thanks, >Waldo > >On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: >I had noticed that I changed it to point to the .dylib path, but it still failed. > > >BTW, OpenMCL's *features*: > > >? *features* >(:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON-LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32-HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST :OPENMCL-PRIVATE-HASH-TABLES) > > >- Waldo > >On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > >Also I changed the default directory from "elephant-0-3" to just "elephant" at the >end of the path, that might create a problem for someone.? I should have documented >that more thoroughly. > > >On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >Does OpenMCL use darwin or macosx in the *features* variable? In sleepycat.lisp there's a #+macosx and #-macosx around the form assigned to *c-library-extension* which is used to figure out which library type to load (dylib or so). If you modify this to #+(or macosx darwin) that should fix it. I'll look around for other macosx only reader conditionals I stuck in there. Under Allegro they use macosx and not darwin. Does OpenMCL require dylibs or so's? Ian Waldo Rubinstein wrote: > Just downloaded this version and already ran into a little problem. > > The new sleepycat libraries are built with .dylib extension for Mac > OSX. However, when I launch OpenMCL, it complaints that it cannot find > libmemutil.so and does not even look for libmemutil.dylib. > > It looks like the actual elephant library is not synchronized with the > Makefile, or something like that. > > Thanks, > Waldo > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > >> Elephant 0.5.0 is now available under the LLGPL. >> >> I put the following text on the project website: >> >> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released >> under the LLGPL . This >> version works with ACL, OpenMCL, and SBCL with or without Unicode >> support. It has significant bug fixes over 0.4.0, especially with >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, >> and Waldo Rubinstein. The tutorial and documentation are improved, >> but may still lag the source code in some ways. >> >> >> >> ---- >> Robert L. Read, PhD read &T >> robertlread.net >> Consider visiting Progressive Engineering: http://robertlread.net/pe >> In Austin: 912-8593 "Think >> globally, Act locally." -- RBF >> >> >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel > > ------------------------------------------------------------------------ > > _______________________________________________ > elephant-devel site list > From waldo at trianet.net Mon Feb 6 15:30:15 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Mon, 6 Feb 2006 10:30:15 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <4737-SnapperMsg01518A7FC00D1A3B@208.54.103.134> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <4737-SnapperMsg01518A7FC00D1A3B@208.54.103.134> Message-ID: Sorry Ian, I got your previous email but didn't realize you wanted me to make the change to sleepycat.lisp. Just to confirm that after changing sleepycat.lisp, as per your instructions, it all works fine with .dylibs and all tests ran clean again. You may want to commit this change. Thanks, Waldo On Feb 6, 2006, at 10:22 AM, Ian Eslick wrote: > Did you not get my earlier e-mail about adding #+(or macosx darwin) > to sleepycat.lisp in place of #+macosx? That will fix it for MCL. > > We also need to do something about user system-specific > dependencies. Folks should not have to modify sources to get > things personalized to their system. One option is to use asdf- > config as an option which was designed to allow user config of > params without requiring source modification... > > Ian > ___ > Sent with SnapperMail > www.snappermail.com > > ..... Original Message ....... > On Mon, 6 Feb 2006 09:12:50 -0500 "Waldo Rubinstein" > wrote: >> In the previous versions of elephant, "make" built the >> corresponding .so files. In this latest version, it builds .dylib >> files (at least on my Mac). >> >> I did correct the controller.lisp and bdb-enable.lisp to point to >> the new elephant library path instead of the elephant-0.3 path. >> >> However, it still complaints about not finding libmemutil.so. It's >> like it doesn't even bother to look for libmemutil.dylib. >> >> - Waldo >> >> On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: >> >> >> I'm a little confused by this; other than the default path, I >> don't think we changed >> changed anything related to this from the most recent version that >> you tested. >> >> Here are two additional questions: >> >> 1) Does libmemutil.so exist on your system? If so, does the >> *elephant-lib-path* >> correctly point to it? >> >> 2) If you run "make", does it not build libmemutil.so? >> >> I suspect this is more an installation/path issue than a problem. >> The released version >> is only slightly different than the version you tested a few days >> ago. >> >> >> >> Waldo wrote: >> >> Just downloaded this version and already ran into a little problem. >> >> >> The new sleepycat libraries are built with .dylib extension for >> Mac OSX. However, when I launch OpenMCL, it complaints that it >> cannot find libmemutil.so and does not even look for >> libmemutil.dylib. >> >> >> It looks like the actual elephant library is not synchronized with >> the Makefile, or something like that. >> >> >> Thanks, >> Waldo >> >> On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: >> I had noticed that I changed it to point to the .dylib path, but >> it still failed. >> >> >> BTW, OpenMCL's *features*: >> >> >> ? *features* >> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- >> LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- >> THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- >> MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- >> HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET : >> 32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN- >> HOST :OPENMCL-PRIVATE-HASH-TABLES) >> >> >> - Waldo >> >> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: >> >> Also I changed the default directory from "elephant-0-3" to just >> "elephant" at the >> end of the path, that might create a problem for someone. I >> should have documented >> that more thoroughly. >> >> >> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >> Does OpenMCL use darwin or macosx in the *features* variable? In >> sleepycat.lisp there's a #+macosx and #-macosx around the form >> assigned to *c-library-extension* which is used to figure out >> which library type to load (dylib or so). If you modify this to #+ >> (or macosx darwin) that should fix it. I'll look around for other >> macosx only reader conditionals I stuck in there. Under Allegro >> they use macosx and not darwin. Does OpenMCL require dylibs or >> so's? Ian Waldo Rubinstein wrote: > Just downloaded this version >> and already ran into a little problem. > > The new sleepycat >> libraries are built with .dylib extension for Mac > OSX. However, >> when I launch OpenMCL, it complaints that it cannot find > >> libmemutil.so and does not even look for libmemutil.dylib. > > It >> looks like the actual elephant library is not synchronized with >> the > Makefile, or something like that. > > Thanks, > Waldo > > On >> Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > >> Elephant 0.5.0 >> is now available under the LLGPL. >> >> I put the following text >> on the project website: >> >> >> The latest version is 0.5.0, >> release Feb. 5, 2006. It is released >> under the LLGPL > opensource.franz.com/preamble.html>. This >> version works with >> ACL, OpenMCL, and SBCL with or without Unicode >> support. It has >> significant bug fixes over 0.4.0, especially with >> respect to >> OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, >> and >> Waldo Rubinstein. The tutorial and documentation are improved, >> >> but may still lag the source code in some ways. >> >> >> >> ---- >> >> Robert L. Read, PhD read &T >> robertlread.net >> Consider >> visiting Progressive Engineering: http://robertlread.net/pe >> In >> Austin: 912-8593 "Think >> globally, Act locally." -- RBF >> >> >> >> _______________________________________________ >> elephant-devel >> site list >> elephant-devel at common-lisp.net > devel at common-lisp.net> >> http://common-lisp.net/mailman/listinfo/ >> elephant-devel > > >> --------------------------------------------------------------------- >> --- > > _______________________________________________ > elephant- >> devel site list > From read at robertlread.net Mon Feb 6 16:45:01 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 06 Feb 2006 10:45:01 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <1139237035.12408.3.camel@localhost.localdomain> Message-ID: <1139244301.12408.7.camel@localhost.localdomain> Excellent! I bet Ian can figure out a more robust way to write the makefile.... On Mon, 2006-02-06 at 10:11 -0500, Waldo Rubinstein wrote: > Yeah. I would assume it would have to be something like that. I know I > can change the build to produce .so files, but I thought this change > was made intentionally to produce .dylibs and that's the reason I > didn't want to touch it. > > > Anyway, when I run uname -a I get: > > > waldo:~ waldo$ uname -a > Darwin waldo.local 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 > 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh > powerpc > > > Simply changing the EXT variable to so makes it work just fine. > > > BTW, once that change is in place, I ran the BDB tests and they all > ran fine on OpenMCL: > > > ELE-TESTS> (do-all-tests-spec *testdb-path*) > Doing 106 pending tests of 106 tests total. > FIXNUMS FIXNUM-TYPE-1 BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS > SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 > ARRAYS-2 TEST-DEEP-EQUALP OBJECTS 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-CLASS2 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 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 PREPARES- > SLEEPYCAT > TEST-SEQ1 TEST-SEQ2 CLEANSUP-SLEEPYCAT REMOVE-ELEMENT MIGRATE1 > MIGRATE2 > MIGRATE3 MIGRATE4 MIGRATE5 > No tests failed. > T > > > - Waldo > > On Feb 6, 2006, at 9:43 AM, Robert L. Read wrote: > > > > The makefile makes a switch based on what "uname -s" returns from > > the shell. > > > > What does it return from your system? > > > > It looks like Ian put this in, and perhaps his Mac version is > > different than yours. > > > > I personally have zero knowledge of dylibs vs. .so's or anything > > else relating > > to Mac stuff. > > > > You can change the Makefile easily enough to produce the .so, by > > assigning to > > the EXT variable, for example. > > > > > > On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: > > > > > In the previous versions of elephant, "make" built the > > > corresponding .so files. In this latest version, it builds .dylib > > > files (at least on my Mac). > > > > > > > > > I did correct the controller.lisp and bdb-enable.lisp to point to > > > the new elephant library path instead of the elephant-0.3 path. > > > > > > > > > However, it still complaints about not finding libmemutil.so. It's > > > like it doesn't even bother to look for libmemutil.dylib. > > > > > > > > > - Waldo > > > > > > On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > > > > > > > > > > I'm a little confused by this; other than the default path, I > > > > don't think we changed > > > > changed anything related to this from the most recent version > > > > that you tested. > > > > > > > > Here are two additional questions: > > > > > > > > 1) Does libmemutil.so exist on your system? If so, does the > > > > *elephant-lib-path* > > > > correctly point to it? > > > > > > > > 2) If you run "make", does it not build libmemutil.so? > > > > > > > > I suspect this is more an installation/path issue than a > > > > problem. The released version > > > > is only slightly different than the version you tested a few > > > > days ago. > > > > > > > > > > > > > > > > Waldo wrote: > > > > > > > > Just downloaded this version and already ran into a little > > > > problem. > > > > > > > > > > > > The new sleepycat libraries are built with .dylib extension for > > > > Mac OSX. However, when I launch OpenMCL, it complaints that it > > > > cannot find libmemutil.so and does not even look for > > > > libmemutil.dylib. > > > > > > > > > > > > It looks like the actual elephant library is not synchronized > > > > with the Makefile, or something like that. > > > > > > > > > > > > Thanks, > > > > Waldo > > > > > > > > On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: > > > > > > > > > I had noticed that I changed it to point to the .dylib path, > > > > > but it still failed. > > > > > > > > > > > > > > > BTW, OpenMCL's *features*: > > > > > > > > > > > > > > > ? *features* > > > > > (:ASDF :PRIMARY- > > > > > CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON- > > > > > LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE- > > > > > THREADS :OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL- > > > > > MOP-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32- > > > > > HOST :DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN- > > > > > TARGET :32-BIT-TARGET :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG- > > > > > ENDIAN-HOST :OPENMCL-PRIVATE-HASH-TABLES) > > > > > > > > > > > > > > > - Waldo > > > > > > > > > > On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > > > > > > > > > > > > > > > > Also I changed the default directory from "elephant-0-3" to > > > > > > just "elephant" at the > > > > > > end of the path, that might create a problem for someone. I > > > > > > should have documented > > > > > > that more thoroughly. > > > > > > > > > > > > > > > > > > On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > > > > > > > > > > > > > Does OpenMCL use darwin or macosx in the *features* variable? In > > > > > > > sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > > > > > > > to *c-library-extension* which is used to figure out which library type > > > > > > > to load (dylib or so). If you modify this to #+(or macosx darwin) that > > > > > > > should fix it. I'll look around for other macosx only reader > > > > > > > conditionals I stuck in there. Under Allegro they use macosx and not > > > > > > > darwin. > > > > > > > > > > > > > > Does OpenMCL require dylibs or so's? > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > Waldo Rubinstein wrote: > > > > > > > > Just downloaded this version and already ran into a little problem. > > > > > > > > > > > > > > > > The new sleepycat libraries are built with .dylib extension for Mac > > > > > > > > OSX. However, when I launch OpenMCL, it complaints that it cannot find > > > > > > > > libmemutil.so and does not even look for libmemutil.dylib. > > > > > > > > > > > > > > > > It looks like the actual elephant library is not synchronized with the > > > > > > > > Makefile, or something like that. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Waldo > > > > > > > > > > > > > > > > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > > > > > > > > > > > > > > > >> Elephant 0.5.0 is now available under the LLGPL. > > > > > > > >> > > > > > > > >> I put the following text on the project website: > > > > > > > >> > > > > > > > >> > > > > > > > >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > > > > > > > >> under the LLGPL . This > > > > > > > >> version works with ACL, OpenMCL, and SBCL with or without Unicode > > > > > > > >> support. It has significant bug fixes over 0.4.0, especially with > > > > > > > >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > > > > > > > >> and Waldo Rubinstein. The tutorial and documentation are improved, > > > > > > > >> but may still lag the source code in some ways. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> ---- > > > > > > > >> Robert L. Read, PhD read &T > > > > > > > >> robertlread.net > > > > > > > >> Consider visiting Progressive Engineering: http://robertlread.net/pe > > > > > > > >> In Austin: 912-8593 "Think > > > > > > > >> globally, Act locally." -- RBF > > > > > > > >> > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 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 read at robertlread.net Mon Feb 6 17:57:19 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 06 Feb 2006 11:57:19 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <43E78AD8.40109@csail.mit.edu> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <1139237035.12408.3.camel@localhost.localdomain> <1139244301.12408.7.camel@localhost.localdomain> <43E78AD8.40109@csail.mit.edu> Message-ID: <1139248639.12408.25.camel@localhost.localdomain> I put the patch on the project website. On Mon, 2006-02-06 at 12:43 -0500, Ian Eslick wrote: > The .dylib extension change failed due to the missing or statement in > sleepycat.lisp. The Makefile should be fine as it is. This was perhaps > a superfluous change - but I wanted to be clear about what kind of files > were what. > > Ian > > Robert L. Read wrote: > > Excellent! I bet Ian can figure out a more robust way to write the > > makefile.... > > > > > > On Mon, 2006-02-06 at 10:11 -0500, Waldo Rubinstein wrote: > >> Yeah. I would assume it would have to be something like that. I know > >> I can change the build to produce .so files, but I thought this > >> change was made intentionally to produce .dylibs and that's the > >> reason I didn't want to touch it. > >> > >> > >> Anyway, when I run uname -a I get: > >> > >> > >> waldo:~ waldo$ uname -a > >> Darwin waldo.local 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 > >> 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power > >> Macintosh powerpc > >> > >> > >> Simply changing the EXT variable to so makes it work just fine. > >> > >> > >> BTW, once that change is in place, I ran the BDB tests and they all > >> ran fine on OpenMCL: > >> > >> > >> ELE-TESTS> (do-all-tests-spec *testdb-path*) > >> Doing 106 pending tests of 106 tests total. > >> FIXNUMS FIXNUM-TYPE-1 BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS > >> SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 > >> ARRAYS-2 TEST-DEEP-EQUALP OBJECTS 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-CLASS2 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 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 PREPARES-SLEEPYCAT > >> TEST-SEQ1 TEST-SEQ2 CLEANSUP-SLEEPYCAT REMOVE-ELEMENT MIGRATE1 MIGRATE2 > >> MIGRATE3 MIGRATE4 MIGRATE5 > >> No tests failed. > >> T > >> > >> > >> - Waldo > >> > >> On Feb 6, 2006, at 9:43 AM, Robert L. Read wrote: > >> > >>> The makefile makes a switch based on what "uname -s" returns from > >>> the shell. > >>> > >>> What does it return from your system? > >>> > >>> It looks like Ian put this in, and perhaps his Mac version is > >>> different than yours. > >>> > >>> I personally have zero knowledge of dylibs vs. .so's or anything > >>> else relating > >>> to Mac stuff. > >>> > >>> You can change the Makefile easily enough to produce the .so, by > >>> assigning to > >>> the EXT variable, for example. > >>> > >>> > >>> On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: > >>>> In the previous versions of elephant, "make" built the > >>>> corresponding .so files. In this latest version, it builds .dylib > >>>> files (at least on my Mac). > >>>> > >>>> > >>>> I did correct the controller.lisp and bdb-enable.lisp to point to > >>>> the new elephant library path instead of the elephant-0.3 path. > >>>> > >>>> > >>>> However, it still complaints about not finding libmemutil.so. It's > >>>> like it doesn't even bother to look for libmemutil.dylib. > >>>> > >>>> > >>>> - Waldo > >>>> > >>>> On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > >>>> > >>>>> I'm a little confused by this; other than the default path, I > >>>>> don't think we changed > >>>>> changed anything related to this from the most recent version that > >>>>> you tested. > >>>>> > >>>>> Here are two additional questions: > >>>>> > >>>>> 1) Does libmemutil.so exist on your system? If so, does the > >>>>> *elephant-lib-path* > >>>>> correctly point to it? > >>>>> > >>>>> 2) If you run "make", does it not build libmemutil.so? > >>>>> > >>>>> I suspect this is more an installation/path issue than a problem. > >>>>> The released version > >>>>> is only slightly different than the version you tested a few days ago. > >>>>> > >>>>> > >>>>> > >>>>> Waldo wrote: > >>>>> > >>>>> Just downloaded this version and already ran into a little problem. > >>>>> > >>>>> > >>>>> The new sleepycat libraries are built with .dylib extension for > >>>>> Mac OSX. However, when I launch OpenMCL, it complaints that it > >>>>> cannot find libmemutil.so and does not even look for libmemutil.dylib. > >>>>> > >>>>> > >>>>> It looks like the actual elephant library is not synchronized with > >>>>> the Makefile, or something like that. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Waldo > >>>>> > >>>>> On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: > >>>>>> I had noticed that I changed it to point to the .dylib path, but > >>>>>> it still failed. > >>>>>> > >>>>>> > >>>>>> BTW, OpenMCL's *features*: > >>>>>> > >>>>>> > >>>>>> ? *features* > >>>>>> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL > >>>>>> :COMMON-LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX > >>>>>> :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP > >>>>>> :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :POWERPC :PPC-TARGET > >>>>>> :PPC-CLOS :PPC32-TARGET :PPC32-HOST :DARWINPPC-TARGET > >>>>>> :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32-BIT-TARGET > >>>>>> :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST > >>>>>> :OPENMCL-PRIVATE-HASH-TABLES) > >>>>>> > >>>>>> > >>>>>> - Waldo > >>>>>> > >>>>>> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > >>>>>> > >>>>>>> Also I changed the default directory from "elephant-0-3" to just > >>>>>>> "elephant" at the > >>>>>>> end of the path, that might create a problem for someone. I > >>>>>>> should have documented > >>>>>>> that more thoroughly. > >>>>>>> > >>>>>>> > >>>>>>> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > >>>>>>>> Does OpenMCL use darwin or macosx in the *features* variable? In > >>>>>>>> sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > >>>>>>>> to *c-library-extension* which is used to figure out which library type > >>>>>>>> to load (dylib or so). If you modify this to #+(or macosx darwin) that > >>>>>>>> should fix it. I'll look around for other macosx only reader > >>>>>>>> conditionals I stuck in there. Under Allegro they use macosx and not > >>>>>>>> darwin. > >>>>>>>> > >>>>>>>> Does OpenMCL require dylibs or so's? > >>>>>>>> > >>>>>>>> Ian > >>>>>>>> > >>>>>>>> Waldo Rubinstein wrote: > >>>>>>>> > Just downloaded this version and already ran into a little problem. > >>>>>>>> > > >>>>>>>> > The new sleepycat libraries are built with .dylib extension for Mac > >>>>>>>> > OSX. However, when I launch OpenMCL, it complaints that it cannot find > >>>>>>>> > libmemutil.so and does not even look for libmemutil.dylib. > >>>>>>>> > > >>>>>>>> > It looks like the actual elephant library is not synchronized with the > >>>>>>>> > Makefile, or something like that. > >>>>>>>> > > >>>>>>>> > Thanks, > >>>>>>>> > Waldo > >>>>>>>> > > >>>>>>>> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > >>>>>>>> > > >>>>>>>> >> Elephant 0.5.0 is now available under the LLGPL. > >>>>>>>> >> > >>>>>>>> >> I put the following text on the project website: > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > >>>>>>>> >> under the LLGPL . This > >>>>>>>> >> version works with ACL, OpenMCL, and SBCL with or without Unicode > >>>>>>>> >> support. It has significant bug fixes over 0.4.0, especially with > >>>>>>>> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > >>>>>>>> >> and Waldo Rubinstein. The tutorial and documentation are improved, > >>>>>>>> >> but may still lag the source code in some ways. > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> ---- > >>>>>>>> >> Robert L. Read, PhD read &T > >>>>>>>> >> robertlread.net > >>>>>>>> >> Consider visiting Progressive Engineering: http://robertlread.net/pe > >>>>>>>> >> In Austin: 912-8593 "Think > >>>>>>>> >> globally, Act locally." -- RBF > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> _______________________________________________ > >>>>>>>> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Mon Feb 6 02:39:23 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 05 Feb 2006 20:39:23 -0600 Subject: [elephant-devel] [elephant-announce] Elephant 0.5.0 is released under the LLGPL Message-ID: <1139193563.4658.243.camel@localhost.localdomain> Elephant 0.5.0 is now available under the LLGPL. I put the following text on the project website: The latest version is 0.5.0, release Feb. 5, 2006. It is released under the LLGPL. This version works with ACL, OpenMCL, and SBCL with or without Unicode support. It has significant bug fixes over 0.4.0, especially with respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, and Waldo Rubinstein. The tutorial and documentation are improved, but may still lag the source code in some ways. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ elephant-announce site list elephant-announce at common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-announce From read at robertlread.net Mon Feb 6 17:53:11 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 06 Feb 2006 11:53:11 -0600 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <43E78AD8.40109@csail.mit.edu> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <1139237035.12408.3.camel@localhost.localdomain> <1139244301.12408.7.camel@localhost.localdomain> <43E78AD8.40109@csail.mit.edu> Message-ID: <1139248391.12408.23.camel@localhost.localdomain> Yes; I should have read all my mail before I wrote the message below. On Mon, 2006-02-06 at 12:43 -0500, Ian Eslick wrote: > The .dylib extension change failed due to the missing or statement in > sleepycat.lisp. The Makefile should be fine as it is. This was perhaps > a superfluous change - but I wanted to be clear about what kind of files > were what. > > Ian > > Robert L. Read wrote: > > Excellent! I bet Ian can figure out a more robust way to write the > > makefile.... > > > > > > On Mon, 2006-02-06 at 10:11 -0500, Waldo Rubinstein wrote: > >> Yeah. I would assume it would have to be something like that. I know > >> I can change the build to produce .so files, but I thought this > >> change was made intentionally to produce .dylibs and that's the > >> reason I didn't want to touch it. > >> > >> > >> Anyway, when I run uname -a I get: > >> > >> > >> waldo:~ waldo$ uname -a > >> Darwin waldo.local 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 > >> 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power > >> Macintosh powerpc > >> > >> > >> Simply changing the EXT variable to so makes it work just fine. > >> > >> > >> BTW, once that change is in place, I ran the BDB tests and they all > >> ran fine on OpenMCL: > >> > >> > >> ELE-TESTS> (do-all-tests-spec *testdb-path*) > >> Doing 106 pending tests of 106 tests total. > >> FIXNUMS FIXNUM-TYPE-1 BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS > >> SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 > >> ARRAYS-2 TEST-DEEP-EQUALP OBJECTS 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-CLASS2 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 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 PREPARES-SLEEPYCAT > >> TEST-SEQ1 TEST-SEQ2 CLEANSUP-SLEEPYCAT REMOVE-ELEMENT MIGRATE1 MIGRATE2 > >> MIGRATE3 MIGRATE4 MIGRATE5 > >> No tests failed. > >> T > >> > >> > >> - Waldo > >> > >> On Feb 6, 2006, at 9:43 AM, Robert L. Read wrote: > >> > >>> The makefile makes a switch based on what "uname -s" returns from > >>> the shell. > >>> > >>> What does it return from your system? > >>> > >>> It looks like Ian put this in, and perhaps his Mac version is > >>> different than yours. > >>> > >>> I personally have zero knowledge of dylibs vs. .so's or anything > >>> else relating > >>> to Mac stuff. > >>> > >>> You can change the Makefile easily enough to produce the .so, by > >>> assigning to > >>> the EXT variable, for example. > >>> > >>> > >>> On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: > >>>> In the previous versions of elephant, "make" built the > >>>> corresponding .so files. In this latest version, it builds .dylib > >>>> files (at least on my Mac). > >>>> > >>>> > >>>> I did correct the controller.lisp and bdb-enable.lisp to point to > >>>> the new elephant library path instead of the elephant-0.3 path. > >>>> > >>>> > >>>> However, it still complaints about not finding libmemutil.so. It's > >>>> like it doesn't even bother to look for libmemutil.dylib. > >>>> > >>>> > >>>> - Waldo > >>>> > >>>> On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: > >>>> > >>>>> I'm a little confused by this; other than the default path, I > >>>>> don't think we changed > >>>>> changed anything related to this from the most recent version that > >>>>> you tested. > >>>>> > >>>>> Here are two additional questions: > >>>>> > >>>>> 1) Does libmemutil.so exist on your system? If so, does the > >>>>> *elephant-lib-path* > >>>>> correctly point to it? > >>>>> > >>>>> 2) If you run "make", does it not build libmemutil.so? > >>>>> > >>>>> I suspect this is more an installation/path issue than a problem. > >>>>> The released version > >>>>> is only slightly different than the version you tested a few days ago. > >>>>> > >>>>> > >>>>> > >>>>> Waldo wrote: > >>>>> > >>>>> Just downloaded this version and already ran into a little problem. > >>>>> > >>>>> > >>>>> The new sleepycat libraries are built with .dylib extension for > >>>>> Mac OSX. However, when I launch OpenMCL, it complaints that it > >>>>> cannot find libmemutil.so and does not even look for libmemutil.dylib. > >>>>> > >>>>> > >>>>> It looks like the actual elephant library is not synchronized with > >>>>> the Makefile, or something like that. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Waldo > >>>>> > >>>>> On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: > >>>>>> I had noticed that I changed it to point to the .dylib path, but > >>>>>> it still failed. > >>>>>> > >>>>>> > >>>>>> BTW, OpenMCL's *features*: > >>>>>> > >>>>>> > >>>>>> ? *features* > >>>>>> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL > >>>>>> :COMMON-LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX > >>>>>> :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP > >>>>>> :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :POWERPC :PPC-TARGET > >>>>>> :PPC-CLOS :PPC32-TARGET :PPC32-HOST :DARWINPPC-TARGET > >>>>>> :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32-BIT-TARGET > >>>>>> :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST > >>>>>> :OPENMCL-PRIVATE-HASH-TABLES) > >>>>>> > >>>>>> > >>>>>> - Waldo > >>>>>> > >>>>>> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: > >>>>>> > >>>>>>> Also I changed the default directory from "elephant-0-3" to just > >>>>>>> "elephant" at the > >>>>>>> end of the path, that might create a problem for someone. I > >>>>>>> should have documented > >>>>>>> that more thoroughly. > >>>>>>> > >>>>>>> > >>>>>>> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: > >>>>>>>> Does OpenMCL use darwin or macosx in the *features* variable? In > >>>>>>>> sleepycat.lisp there's a #+macosx and #-macosx around the form assigned > >>>>>>>> to *c-library-extension* which is used to figure out which library type > >>>>>>>> to load (dylib or so). If you modify this to #+(or macosx darwin) that > >>>>>>>> should fix it. I'll look around for other macosx only reader > >>>>>>>> conditionals I stuck in there. Under Allegro they use macosx and not > >>>>>>>> darwin. > >>>>>>>> > >>>>>>>> Does OpenMCL require dylibs or so's? > >>>>>>>> > >>>>>>>> Ian > >>>>>>>> > >>>>>>>> Waldo Rubinstein wrote: > >>>>>>>> > Just downloaded this version and already ran into a little problem. > >>>>>>>> > > >>>>>>>> > The new sleepycat libraries are built with .dylib extension for Mac > >>>>>>>> > OSX. However, when I launch OpenMCL, it complaints that it cannot find > >>>>>>>> > libmemutil.so and does not even look for libmemutil.dylib. > >>>>>>>> > > >>>>>>>> > It looks like the actual elephant library is not synchronized with the > >>>>>>>> > Makefile, or something like that. > >>>>>>>> > > >>>>>>>> > Thanks, > >>>>>>>> > Waldo > >>>>>>>> > > >>>>>>>> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: > >>>>>>>> > > >>>>>>>> >> Elephant 0.5.0 is now available under the LLGPL. > >>>>>>>> >> > >>>>>>>> >> I put the following text on the project website: > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released > >>>>>>>> >> under the LLGPL . This > >>>>>>>> >> version works with ACL, OpenMCL, and SBCL with or without Unicode > >>>>>>>> >> support. It has significant bug fixes over 0.4.0, especially with > >>>>>>>> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, > >>>>>>>> >> and Waldo Rubinstein. The tutorial and documentation are improved, > >>>>>>>> >> but may still lag the source code in some ways. > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> ---- > >>>>>>>> >> Robert L. Read, PhD read &T > >>>>>>>> >> robertlread.net > >>>>>>>> >> Consider visiting Progressive Engineering: http://robertlread.net/pe > >>>>>>>> >> In Austin: 912-8593 "Think > >>>>>>>> >> globally, Act locally." -- RBF > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> _______________________________________________ > >>>>>>>> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Mon Feb 6 17:43:52 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 06 Feb 2006 12:43:52 -0500 Subject: [elephant-devel] Elephant 0.5.0 is released under the LLGPL In-Reply-To: <1139244301.12408.7.camel@localhost.localdomain> References: <1139193563.4658.243.camel@localhost.localdomain> <662C8F15-BC1F-4CFC-A50B-2087E41BF431@trianet.net> <43E6CA88.8040308@csail.mit.edu> <1139199234.4658.246.camel@localhost.localdomain> <1139234134.4658.253.camel@localhost.localdomain> <1139237035.12408.3.camel@localhost.localdomain> <1139244301.12408.7.camel@localhost.localdomain> Message-ID: <43E78AD8.40109@csail.mit.edu> The .dylib extension change failed due to the missing or statement in sleepycat.lisp. The Makefile should be fine as it is. This was perhaps a superfluous change - but I wanted to be clear about what kind of files were what. Ian Robert L. Read wrote: > Excellent! I bet Ian can figure out a more robust way to write the > makefile.... > > > On Mon, 2006-02-06 at 10:11 -0500, Waldo Rubinstein wrote: >> Yeah. I would assume it would have to be something like that. I know >> I can change the build to produce .so files, but I thought this >> change was made intentionally to produce .dylibs and that's the >> reason I didn't want to touch it. >> >> >> Anyway, when I run uname -a I get: >> >> >> waldo:~ waldo$ uname -a >> Darwin waldo.local 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 >> 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> >> Simply changing the EXT variable to so makes it work just fine. >> >> >> BTW, once that change is in place, I ran the BDB tests and they all >> ran fine on OpenMCL: >> >> >> ELE-TESTS> (do-all-tests-spec *testdb-path*) >> Doing 106 pending tests of 106 tests total. >> FIXNUMS FIXNUM-TYPE-1 BIGNUMS FLOATS RATIONALS BASE-STRINGS STRINGS >> SYMBOLS CHARS PATHNAMES CONSES HASH-TABLES-1 HASH-TABLES-2 ARRAYS-1 >> ARRAYS-2 TEST-DEEP-EQUALP OBJECTS 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-CLASS2 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 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 PREPARES-SLEEPYCAT >> TEST-SEQ1 TEST-SEQ2 CLEANSUP-SLEEPYCAT REMOVE-ELEMENT MIGRATE1 MIGRATE2 >> MIGRATE3 MIGRATE4 MIGRATE5 >> No tests failed. >> T >> >> >> - Waldo >> >> On Feb 6, 2006, at 9:43 AM, Robert L. Read wrote: >> >>> The makefile makes a switch based on what "uname -s" returns from >>> the shell. >>> >>> What does it return from your system? >>> >>> It looks like Ian put this in, and perhaps his Mac version is >>> different than yours. >>> >>> I personally have zero knowledge of dylibs vs. .so's or anything >>> else relating >>> to Mac stuff. >>> >>> You can change the Makefile easily enough to produce the .so, by >>> assigning to >>> the EXT variable, for example. >>> >>> >>> On Mon, 2006-02-06 at 09:12 -0500, Waldo Rubinstein wrote: >>>> In the previous versions of elephant, "make" built the >>>> corresponding .so files. In this latest version, it builds .dylib >>>> files (at least on my Mac). >>>> >>>> >>>> I did correct the controller.lisp and bdb-enable.lisp to point to >>>> the new elephant library path instead of the elephant-0.3 path. >>>> >>>> >>>> However, it still complaints about not finding libmemutil.so. It's >>>> like it doesn't even bother to look for libmemutil.dylib. >>>> >>>> >>>> - Waldo >>>> >>>> On Feb 6, 2006, at 8:55 AM, Robert L. Read wrote: >>>> >>>>> I'm a little confused by this; other than the default path, I >>>>> don't think we changed >>>>> changed anything related to this from the most recent version that >>>>> you tested. >>>>> >>>>> Here are two additional questions: >>>>> >>>>> 1) Does libmemutil.so exist on your system? If so, does the >>>>> *elephant-lib-path* >>>>> correctly point to it? >>>>> >>>>> 2) If you run "make", does it not build libmemutil.so? >>>>> >>>>> I suspect this is more an installation/path issue than a problem. >>>>> The released version >>>>> is only slightly different than the version you tested a few days ago. >>>>> >>>>> >>>>> >>>>> Waldo wrote: >>>>> >>>>> Just downloaded this version and already ran into a little problem. >>>>> >>>>> >>>>> The new sleepycat libraries are built with .dylib extension for >>>>> Mac OSX. However, when I launch OpenMCL, it complaints that it >>>>> cannot find libmemutil.so and does not even look for libmemutil.dylib. >>>>> >>>>> >>>>> It looks like the actual elephant library is not synchronized with >>>>> the Makefile, or something like that. >>>>> >>>>> >>>>> Thanks, >>>>> Waldo >>>>> >>>>> On Mon, 2006-02-06 at 01:19 -0500, Waldo Rubinstein wrote: >>>>>> I had noticed that I changed it to point to the .dylib path, but >>>>>> it still failed. >>>>>> >>>>>> >>>>>> BTW, OpenMCL's *features*: >>>>>> >>>>>> >>>>>> ? *features* >>>>>> (:ASDF :PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL >>>>>> :COMMON-LISP :MCL :OPENMCL :ANSI-CL :PROCESSES :UNIX >>>>>> :OPENMCL-NATIVE-THREADS :OPENMCL-PARTIAL-MOP >>>>>> :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2 :POWERPC :PPC-TARGET >>>>>> :PPC-CLOS :PPC32-TARGET :PPC32-HOST :DARWINPPC-TARGET >>>>>> :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET :32-BIT-TARGET >>>>>> :32-BIT-HOST :BIG-ENDIAN-TARGET :BIG-ENDIAN-HOST >>>>>> :OPENMCL-PRIVATE-HASH-TABLES) >>>>>> >>>>>> >>>>>> - Waldo >>>>>> >>>>>> On Feb 5, 2006, at 11:13 PM, Robert L. Read wrote: >>>>>> >>>>>>> Also I changed the default directory from "elephant-0-3" to just >>>>>>> "elephant" at the >>>>>>> end of the path, that might create a problem for someone. I >>>>>>> should have documented >>>>>>> that more thoroughly. >>>>>>> >>>>>>> >>>>>>> On Sun, 2006-02-05 at 23:03 -0500, Ian Eslick wrote: >>>>>>>> Does OpenMCL use darwin or macosx in the *features* variable? In >>>>>>>> sleepycat.lisp there's a #+macosx and #-macosx around the form assigned >>>>>>>> to *c-library-extension* which is used to figure out which library type >>>>>>>> to load (dylib or so). If you modify this to #+(or macosx darwin) that >>>>>>>> should fix it. I'll look around for other macosx only reader >>>>>>>> conditionals I stuck in there. Under Allegro they use macosx and not >>>>>>>> darwin. >>>>>>>> >>>>>>>> Does OpenMCL require dylibs or so's? >>>>>>>> >>>>>>>> Ian >>>>>>>> >>>>>>>> Waldo Rubinstein wrote: >>>>>>>> > Just downloaded this version and already ran into a little problem. >>>>>>>> > >>>>>>>> > The new sleepycat libraries are built with .dylib extension for Mac >>>>>>>> > OSX. However, when I launch OpenMCL, it complaints that it cannot find >>>>>>>> > libmemutil.so and does not even look for libmemutil.dylib. >>>>>>>> > >>>>>>>> > It looks like the actual elephant library is not synchronized with the >>>>>>>> > Makefile, or something like that. >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Waldo >>>>>>>> > >>>>>>>> > On Feb 5, 2006, at 9:39 PM, Robert L. Read wrote: >>>>>>>> > >>>>>>>> >> Elephant 0.5.0 is now available under the LLGPL. >>>>>>>> >> >>>>>>>> >> I put the following text on the project website: >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> The latest version is 0.5.0, release Feb. 5, 2006. It is released >>>>>>>> >> under the LLGPL . This >>>>>>>> >> version works with ACL, OpenMCL, and SBCL with or without Unicode >>>>>>>> >> support. It has significant bug fixes over 0.4.0, especially with >>>>>>>> >> respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, >>>>>>>> >> and Waldo Rubinstein. The tutorial and documentation are improved, >>>>>>>> >> but may still lag the source code in some ways. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> ---- >>>>>>>> >> Robert L. Read, PhD read &T >>>>>>>> >> robertlread.net >>>>>>>> >> Consider visiting Progressive Engineering: http://robertlread.net/pe >>>>>>>> >> In Austin: 912-8593 "Think >>>>>>>> >> globally, Act locally." -- RBF >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> _______________________________________________ >>>>>>>> >> 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 read at robertlread.net Mon Feb 6 02:39:23 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 05 Feb 2006 20:39:23 -0600 Subject: [elephant-devel] [elephant-announce] Elephant 0.5.0 is released under the LLGPL Message-ID: <1139193563.4658.243.camel@localhost.localdomain> Elephant 0.5.0 is now available under the LLGPL. I put the following text on the project website: The latest version is 0.5.0, release Feb. 5, 2006. It is released under the LLGPL. This version works with ACL, OpenMCL, and SBCL with or without Unicode support. It has significant bug fixes over 0.4.0, especially with respect to OpenMCL and ACL. Thanks to Andrew Blumberg, Ian Eslick, and Waldo Rubinstein. The tutorial and documentation are improved, but may still lag the source code in some ways. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ elephant-announce site list elephant-announce at common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-announce From eslick at csail.mit.edu Wed Feb 8 18:24:16 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 08 Feb 2006 13:24:16 -0500 Subject: [elephant-devel] Indexing support in HEAD - requesting comments on design Message-ID: <43EA3750.5010706@csail.mit.edu> To the Elephant Community, The current development HEAD contains beta code for the upcoming 0.6.0 release, the major feature of which is providing the option to generate secondary indices on slot values very similar to Statice and Allegro Cache/Store. Independant documentation is forthcoming, however the API in src/indexing.lisp is reasonably documented. There's also a simple example in src/index-tutorial.lisp and a (potentially out of date) top level file to run the example in tests/RunIndexingTutorial.lisp. If anyone would like to take a look at this I'm open to suggestions on improving the interface before I commit a naming convention and usage model. Also, does anyone have a problem with me adding a macro defpclass to metaclasses.lisp that handles adding the persistent-metaclass option to a normal defclass? Design decisions: I was reading the Static and AllegroCache docs today which inspired a couple of trivial features to consider adding: - A future ability to declare a slot index to be unique (:indexed t = :any) (:indexed :unique) My intention is to change the :indexed t option to use the allegro cache convention of :index :any and :index :any-unique before we release 0.6.0. - The ability to define secondary index accessors with :inverse-accessor name slot options. This implicitly enables the :indexed :any option and creates a defmethod - Class :indexed option (this is the default case in Statice and AllegroCache - all classes are implicitly indexed which is not the current elephant default). I'll leave the default to 'off' for backwards compatibility. I've already planned to add something like the Statice 'foreach' macro which is a loop-like syntax that iterates over a set of objects satisfying certain constraints, optionally sorted. When there are inverse indices available the iteration time will be highly compressed. Transactions: Allegro Cache supports an interactive model where there is an implicit start-transaction if you do any database writes but you don't have to commit until you are ready to commit a set of changes (over seconds or minutes) by calling (commit) or (rollback). Ben, do you know if BDB will have problems handling long-lived transactions with very few write operations in standalone mode? This is nice for exploring/testing without commit long-lived changes. If anyone has questions or comments, I'm trying to finalize these tradeoffs and the API naming conventions in the next two weeks so I can release 0.6.0 and move on with my life, so would appreciate input. Also testing help is needed. The current release works on my Allegro/MacOSX configuration but is failing on SBCL/Linux. I'm setting up SBCL/MacOSX on my system to test locally but it would be great to accelerate this process. Regards, Ian From eslick at csail.mit.edu Wed Feb 8 19:21:00 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 08 Feb 2006 14:21:00 -0500 Subject: [elephant-devel] Indexing support in HEAD - requesting comments on design In-Reply-To: <9157df230602081043m5264c586taf698fa1abac4985@mail.gmail.com> References: <43EA3750.5010706@csail.mit.edu> <9157df230602081043m5264c586taf698fa1abac4985@mail.gmail.com> Message-ID: <43EA449C.7020605@csail.mit.edu> I'll look out for that if I try to support the interactive transaction mode later. Thanks for the heads up. BDB does seem to be richly featured but poorly abstracted. I keep running into lockup conditions and am having trouble figuring out how to get it to timeout instead of wait. Even when I set the environment timeouts it still freezes in a select call inside db_lget (called from db-put-raw in lisp). Sigh... Ian Ben wrote: > Hi Ian, > > Looks pretty sweet. About long-lived transactions, I don't really > know of any problem. The biggest issue I know of appears to be static > memory limits in BDB, which make big transactions run out of memory, > or limits the number of transactions / locks, etc. That might be a > problem, but might also be configurable. > > In general I have felt a bit uncomfortable with BDB, not that I think > it is a bad product but it seems to require a lot of arcane knowledge > to wield properly, something against my original elephant philosophy. > On the other hand, the sleepycat developers that hang out on the > google groups page for sleepycat are fairly responsive and helpful. > > Sorry I can't be more help, Ben > > On 2/8/06, Ian Eslick wrote: > >> To the Elephant Community, >> >> The current development HEAD contains beta code for the upcoming 0.6.0 >> release, the major feature of which is providing the option to generate >> secondary indices on slot values very similar to Statice and Allegro >> Cache/Store. >> >> Independant documentation is forthcoming, however the API in >> src/indexing.lisp is reasonably documented. There's also a simple >> example in src/index-tutorial.lisp and a (potentially out of date) top >> level file to run the example in tests/RunIndexingTutorial.lisp. If >> anyone would like to take a look at this I'm open to suggestions on >> improving the interface before I commit a naming convention and usage >> model. >> >> Also, does anyone have a problem with me adding a macro defpclass to >> metaclasses.lisp that handles adding the persistent-metaclass option to >> a normal defclass? >> >> Design decisions: >> >> I was reading the Static and AllegroCache docs today which inspired a >> couple of trivial features to consider adding: >> >> - A future ability to declare a slot index to be unique (:indexed t = >> :any) (:indexed :unique) My intention is to >> change the :indexed t option to use the allegro cache convention of >> :index :any and :index :any-unique >> before we release 0.6.0. >> >> - The ability to define secondary index accessors with :inverse-accessor >> name slot options. This implicitly >> enables the :indexed :any option and creates a defmethod >> >> - Class :indexed option (this is the default case in Statice and >> AllegroCache - all classes are implicitly >> indexed which is not the current elephant default). I'll leave the >> default to 'off' for backwards compatibility. >> >> I've already planned to add something like the Statice 'foreach' macro >> which is a loop-like syntax that iterates over a set of objects >> satisfying certain constraints, optionally sorted. When there are >> inverse indices available the iteration time will be highly compressed. >> >> Transactions: >> >> Allegro Cache supports an interactive model where there is an implicit >> start-transaction if you do any database writes but you don't have to >> commit until you are ready to commit a set of changes (over seconds or >> minutes) by calling (commit) or (rollback). Ben, do you know if BDB >> will have problems handling long-lived transactions with very few write >> operations in standalone mode? This is nice for exploring/testing >> without commit long-lived changes. >> >> If anyone has questions or comments, I'm trying to finalize these >> tradeoffs and the API naming conventions in the next two weeks so I can >> release 0.6.0 and move on with my life, so would appreciate input. >> >> Also testing help is needed. The current release works on my >> Allegro/MacOSX configuration but is failing on SBCL/Linux. I'm setting >> up SBCL/MacOSX on my system to test locally but it would be great to >> accelerate this process. >> >> Regards, >> Ian >> >> >> _______________________________________________ >> 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 10 03:40:39 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 09 Feb 2006 22:40:39 -0500 Subject: [elephant-devel] Feature question Message-ID: <43EC0B37.2030606@csail.mit.edu> If we have persistent objects with persistent base classes - do we want instances of a base class to also be indexed by class? For example if I had a base class 'log' with an indexed slot 'date' and two subclasses 'error-log' and 'warning-log' with their own indexed slots. Do I want to be able to find all instances of error-log and warning-log in a given time interval by looking in the class index for 'log'? Or should I search in both 'error-log' and 'warning-log'? Currently I only index by the actual class of the instance and not it's persistent indexed subclasses. Writes get more expensive if we add this feature and dynamic class changes (redefinition, change-class, etc) all get more complex. Large class hierarchies are also problematic. For now I'm going to ignore this and put the onus on the user. Base classes with indexed slots all end up in the secondary index with that slot name for the leaf subclass. Ian From tjg-lisp at pentaside.org Mon Feb 13 11:10:12 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Mon, 13 Feb 2006 12:10:12 +0100 Subject: [elephant-devel] Installing on MacOS X, SBCL Message-ID: <43F06914.2030300@pentaside.org> Hi all, (I'm using SBCL 0.9.4 on MacOS X) I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a loss about how to deal with the following Slime stack trace. (Elephant apparently knows about the "dylib" naming convention and all that...) ---- Attempt to call an undefined alien function. [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) 1: ("foreign function: call_into_lisp") 2: (SLEEPYCAT::%DB-ENV-CREATE 0) 3: (SLEEPYCAT:DB-ENV-CREATE) 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) (#(NIL 1) . #()) # # (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL :RECOVER-FATAL NIL :THREAD T) 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") #) ---- Thanks for any advice, Tayssir From tjg-lisp at pentaside.org Mon Feb 13 13:37:22 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Mon, 13 Feb 2006 14:37:22 +0100 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <43F06914.2030300@pentaside.org> References: <43F06914.2030300@pentaside.org> Message-ID: <43F08B92.2070206@pentaside.org> Whoops, forgot to mention I was executing the basic command: (open-store "testdb") Tayssir Tayssir John Gabbour wrote: >> Hi all, >> >> (I'm using SBCL 0.9.4 on MacOS X) >> >> I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >> loss about how to deal with the following Slime stack trace. (Elephant >> apparently knows about the "dylib" naming convention and all that...) >> >> ---- >> Attempt to call an undefined alien function. >> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >> >> Restarts: >> 0: [ABORT] Abort handling SLIME request. >> 1: [ABORT] Exit debugger, returning to top level. >> >> Backtrace: >> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >> 1: ("foreign function: call_into_lisp") >> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >> 3: (SLEEPYCAT:DB-ENV-CREATE) >> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >> (#(NIL 1) . #()) # #> {11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >> :RECOVER-FATAL NIL :THREAD T) >> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >> #) >> ---- >> >> Thanks for any advice, >> Tayssir >> _______________________________________________ >> elephant-devel site list >> elephant-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel >> From read at robertlread.net Mon Feb 13 13:49:25 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 13 Feb 2006 07:49:25 -0600 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <43F06914.2030300@pentaside.org> References: <43F06914.2030300@pentaside.org> Message-ID: <1139838565.12408.338.camel@localhost.localdomain> This is just a guess: Did you run "make" and do the following two files exists in this location: /usr/local/share/common-lisp/elephant/libsleepycat.so /usr/local/share/common-lisp/elephant/libmemutil.so and does /usr/lib/libdb.so exists in a standard lib location, such as /usr/lib/libdb.so? On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: > Hi all, > > (I'm using SBCL 0.9.4 on MacOS X) > > I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a > loss about how to deal with the following Slime stack trace. (Elephant > apparently knows about the "dylib" naming convention and all that...) > > ---- > Attempt to call an undefined alien function. > [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] > > Restarts: > 0: [ABORT] Abort handling SLIME request. > 1: [ABORT] Exit debugger, returning to top level. > > Backtrace: > 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) > 1: ("foreign function: call_into_lisp") > 2: (SLEEPYCAT::%DB-ENV-CREATE 0) > 3: (SLEEPYCAT:DB-ENV-CREATE) > 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) > (#(NIL 1) . #()) # # {11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) > 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") > 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL > :RECOVER-FATAL NIL :THREAD T) > 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") > #) > ---- > > Thanks for any advice, > Tayssir > _______________________________________________ > 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 tjg-lisp at pentaside.org Mon Feb 13 14:54:31 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Mon, 13 Feb 2006 15:54:31 +0100 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <1139838565.12408.338.camel@localhost.localdomain> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> Message-ID: <43F09DA7.9060400@pentaside.org> Yes, make created in (the ASDF-accessible) elephant-0.5/: libsleepycat.dylib libmemutil.dylib Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but I just made a soft and a hard link to: /usr/lib/libdb.dylib which didn't fix the problem. :( Tayssir Robert L. Read wrote: > This is just a guess: > > Did you run "make" and do the following two files exists in this location: > > /usr/local/share/common-lisp/elephant/libsleepycat.so > /usr/local/share/common-lisp/elephant/libmemutil.so > > and does > /usr/lib/libdb.so > > exists in a standard lib location, such as /usr/lib/libdb.so? > > > On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: > >>Hi all, >> >>(I'm using SBCL 0.9.4 on MacOS X) >> >>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >>loss about how to deal with the following Slime stack trace. (Elephant >>apparently knows about the "dylib" naming convention and all that...) >> >>---- >>Attempt to call an undefined alien function. >> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >> >>Restarts: >> 0: [ABORT] Abort handling SLIME request. >> 1: [ABORT] Exit debugger, returning to top level. >> >>Backtrace: >> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >> 1: ("foreign function: call_into_lisp") >> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >> 3: (SLEEPYCAT:DB-ENV-CREATE) >> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >>(#(NIL 1) . #()) # #>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >>:RECOVER-FATAL NIL :THREAD T) >> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >>#) >>---- >> >>Thanks for any advice, >>Tayssir >>_______________________________________________ >>elephant-devel site list >>elephant-devel at common-lisp.net >>http://common-lisp.net/mailman/listinfo/elephant-devel >> From read at robertlread.net Mon Feb 13 15:04:26 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 13 Feb 2006 09:04:26 -0600 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <43F09DA7.9060400@pentaside.org> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> Message-ID: <1139843066.12408.344.camel@localhost.localdomain> Does elephant-0.5 match the value of *elephant-lib-path*? I recently changed it to just use "elephant", since we have made so many releases in the last few months and plan to make more soon. (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: > Yes, make created in (the ASDF-accessible) elephant-0.5/: > libsleepycat.dylib > libmemutil.dylib > > Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but > I just made a soft and a hard link to: > /usr/lib/libdb.dylib > > which didn't fix the problem. :( > > > Tayssir > > > > Robert L. Read wrote: > > This is just a guess: > > > > Did you run "make" and do the following two files exists in this location: > > > > /usr/local/share/common-lisp/elephant/libsleepycat.so > > /usr/local/share/common-lisp/elephant/libmemutil.so > > > > and does > > /usr/lib/libdb.so > > > > exists in a standard lib location, such as /usr/lib/libdb.so? > > > > > > On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: > > > >>Hi all, > >> > >>(I'm using SBCL 0.9.4 on MacOS X) > >> > >>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a > >>loss about how to deal with the following Slime stack trace. (Elephant > >>apparently knows about the "dylib" naming convention and all that...) > >> > >>---- > >>Attempt to call an undefined alien function. > >> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] > >> > >>Restarts: > >> 0: [ABORT] Abort handling SLIME request. > >> 1: [ABORT] Exit debugger, returning to top level. > >> > >>Backtrace: > >> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) > >> 1: ("foreign function: call_into_lisp") > >> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) > >> 3: (SLEEPYCAT:DB-ENV-CREATE) > >> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) > >>(#(NIL 1) . #()) # # >>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) > >> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") > >> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL > >>:RECOVER-FATAL NIL :THREAD T) > >> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") > >>#) > >>---- > >> > >>Thanks for any advice, > >>Tayssir > >>_______________________________________________ > >>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 read at robertlread.net Mon Feb 13 15:15:51 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 13 Feb 2006 09:15:51 -0600 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <1139843066.12408.344.camel@localhost.localdomain> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> Message-ID: <1139843751.12408.352.camel@localhost.localdomain> One gentleman who uses a Mac has to modify the makefile so it produced a .so instead of a .dylib. You might try that; I don't have a Mac and don't fully understand the difference. On Mon, 2006-02-13 at 09:04 -0600, Robert L. Read wrote: > Does elephant-0.5 match the value of *elephant-lib-path*? > I recently changed it to just use "elephant", since we have made so > many releases in the > last few months and plan to make more soon. > > > (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") > > > On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: > > > Yes, make created in (the ASDF-accessible) elephant-0.5/: > > libsleepycat.dylib > > libmemutil.dylib > > > > Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but > > I just made a soft and a hard link to: > > /usr/lib/libdb.dylib > > > > which didn't fix the problem. :( > > > > > > Tayssir > > > > > > > > Robert L. Read wrote: > > > This is just a guess: > > > > > > Did you run "make" and do the following two files exists in this location: > > > > > > /usr/local/share/common-lisp/elephant/libsleepycat.so > > > /usr/local/share/common-lisp/elephant/libmemutil.so > > > > > > and does > > > /usr/lib/libdb.so > > > > > > exists in a standard lib location, such as /usr/lib/libdb.so? > > > > > > > > > On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: > > > > > >>Hi all, > > >> > > >>(I'm using SBCL 0.9.4 on MacOS X) > > >> > > >>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a > > >>loss about how to deal with the following Slime stack trace. (Elephant > > >>apparently knows about the "dylib" naming convention and all that...) > > >> > > >>---- > > >>Attempt to call an undefined alien function. > > >> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] > > >> > > >>Restarts: > > >> 0: [ABORT] Abort handling SLIME request. > > >> 1: [ABORT] Exit debugger, returning to top level. > > >> > > >>Backtrace: > > >> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) > > >> 1: ("foreign function: call_into_lisp") > > >> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) > > >> 3: (SLEEPYCAT:DB-ENV-CREATE) > > >> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) > > >>(#(NIL 1) . #()) # # > >>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) > > >> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") > > >> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL > > >>:RECOVER-FATAL NIL :THREAD T) > > >> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") > > >>#) > > >>---- > > >> > > >>Thanks for any advice, > > >>Tayssir > > >>_______________________________________________ > > >>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 13 15:23:11 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 13 Feb 2006 10:23:11 -0500 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <1139843751.12408.352.camel@localhost.localdomain> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> Message-ID: <43F0A45F.7070601@csail.mit.edu> I provided a patch to the .so vs. .dylib problem under SBCL. Is that in the current 0.5.0 release or is it on the trunk after the current 0.5.0? Regardless, the patch for this is on the main web page. Much of the lisp code in elephant on Mac OS X is looking for .dylib and the stack trace below seems to indicate that a library is not being loaded or that there's a general problem with foreign function calling. Another thought, is the SBCL version current enough? I haven't got my SBCL environment up and running on Mac OS X yet to test this. Ian Robert L. Read wrote: > One gentleman who uses a Mac has to modify the makefile so it > produced a .so instead of a .dylib. You might try that; I don't have > a Mac and don't fully understand the difference. > > On Mon, 2006-02-13 at 09:04 -0600, Robert L. Read wrote: >> Does elephant-0.5 match the value of *elephant-lib-path*? >> I recently changed it to just use "elephant", since we have made so >> many releases in the >> last few months and plan to make more soon. >> >> >> (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") >> >> >> On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: >>> Yes, make created in (the ASDF-accessible) elephant-0.5/: >>> libsleepycat.dylib >>> libmemutil.dylib >>> >>> Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but >>> I just made a soft and a hard link to: >>> /usr/lib/libdb.dylib >>> >>> which didn't fix the problem. :( >>> >>> >>> Tayssir >>> >>> >>> >>> Robert L. Read wrote: >>> > This is just a guess: >>> > >>> > Did you run "make" and do the following two files exists in this location: >>> > >>> > /usr/local/share/common-lisp/elephant/libsleepycat.so >>> > /usr/local/share/common-lisp/elephant/libmemutil.so >>> > >>> > and does >>> > /usr/lib/libdb.so >>> > >>> > exists in a standard lib location, such as /usr/lib/libdb.so? >>> > >>> > >>> > On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: >>> > >>> >>Hi all, >>> >> >>> >>(I'm using SBCL 0.9.4 on MacOS X) >>> >> >>> >>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >>> >>loss about how to deal with the following Slime stack trace. (Elephant >>> >>apparently knows about the "dylib" naming convention and all that...) >>> >> >>> >>---- >>> >>Attempt to call an undefined alien function. >>> >> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >>> >> >>> >>Restarts: >>> >> 0: [ABORT] Abort handling SLIME request. >>> >> 1: [ABORT] Exit debugger, returning to top level. >>> >> >>> >>Backtrace: >>> >> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >>> >> 1: ("foreign function: call_into_lisp") >>> >> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >>> >> 3: (SLEEPYCAT:DB-ENV-CREATE) >>> >> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >>> >>(#(NIL 1) . #()) # #>> >>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >>> >> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >>> >> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >>> >>:RECOVER-FATAL NIL :THREAD T) >>> >> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >>> >>#) >>> >>---- >>> >> >>> >>Thanks for any advice, >>> >>Tayssir >>> >>_______________________________________________ >>> >>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 read at robertlread.net Mon Feb 13 15:38:49 2006 From: read at robertlread.net (Robert L. Read) Date: Mon, 13 Feb 2006 09:38:49 -0600 Subject: [elephant-devel] Change in reply-to.... Message-ID: <1139845129.12408.357.camel@localhost.localdomain> At the request of a participant, I just changed the default "reply-to" of this list to go back to the list (at least I think I did.) Please check exactly where you want your reply to go; I think this list so far has been completely informative and only occasionally too detailed for a general readership, but I would like to keep it that way. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjg-lisp at pentaside.org Mon Feb 13 16:42:33 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Mon, 13 Feb 2006 17:42:33 +0100 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <1139843751.12408.352.camel@localhost.localdomain> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> Message-ID: <43F0B6F9.3090905@pentaside.org> Robert L. Read wrote: > Does elephant-0.5 match the value of *elephant-lib-path*? > I recently changed it to just use "elephant", since we have made > so many releases in the > last few months and plan to make more soon. > > (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") Yes, I changed it to: (defvar *elephant-lib-path* "/Users/main/Apps/asdf/elephant-0.5.0/") Hmm, looking at the ASDF output when it loads Elephant, it has 60 lines complaining of style-warnings, like: ---- ; loading system definition from ; /Users/main/Apps/asdf/elephant-0.5.0/elephant.asd into # ; registering # as ELEPHANT STYLE-WARNING: Undefined alien: "linux_no_threads_p" STYLE-WARNING: Undefined alien: "db_env_cr" STYLE-WARNING: Undefined alien: "db_env_close" ... more STYLE-WARNINGs... --- (Incidentally, I have XCode 2.1 installed; XCode 2.2 was recently released...) > One gentleman who uses a Mac has to modify the makefile so it > produced a .so instead of a .dylib. You might try that; I don't have > a Mac and don't fully understand the difference. Unfortunately, I get the same error when I do that. (Fortunately, make's willing to make the .so file, with only a few complaints...) Tayssir Robert L. Read wrote: > Does elephant-0.5 match the value of *elephant-lib-path*? > I recently changed it to just use "elephant", since we have made so many > releases in the > last few months and plan to make more soon. > > > (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") > > > On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: > >>Yes, make created in (the ASDF-accessible) elephant-0.5/: >>libsleepycat.dylib >>libmemutil.dylib >> >>Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but >>I just made a soft and a hard link to: >>/usr/lib/libdb.dylib >> >>which didn't fix the problem. :( >> >> >>Tayssir >> >> >> >>Robert L. Read wrote: >>> This is just a guess: >>> >>> Did you run "make" and do the following two files exists in this location: >>> >>> /usr/local/share/common-lisp/elephant/libsleepycat.so >>> /usr/local/share/common-lisp/elephant/libmemutil.so >>> >>> and does >>> /usr/lib/libdb.so >>> >>> exists in a standard lib location, such as /usr/lib/libdb.so? >>> >>> >>> On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: >>> >>>>Hi all, >>>> >>>>(I'm using SBCL 0.9.4 on MacOS X) >>>> >>>>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >>>>loss about how to deal with the following Slime stack trace. (Elephant >>>>apparently knows about the "dylib" naming convention and all that...) >>>> >>>>---- >>>>Attempt to call an undefined alien function. >>>> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >>>> >>>>Restarts: >>>> 0: [ABORT] Abort handling SLIME request. >>>> 1: [ABORT] Exit debugger, returning to top level. >>>> >>>>Backtrace: >>>> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >>>> 1: ("foreign function: call_into_lisp") >>>> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >>>> 3: (SLEEPYCAT:DB-ENV-CREATE) >>>> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >>>>(#(NIL 1) . #()) # #>>>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >>>> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >>>> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >>>>:RECOVER-FATAL NIL :THREAD T) >>>> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >>>>#) >>>>---- >>>> >>>>Thanks for any advice, >>>>Tayssir >>>>_______________________________________________ >>>>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 13 16:57:35 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Mon, 13 Feb 2006 11:57:35 -0500 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <43F0B6F9.3090905@pentaside.org> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> <43F0B6F9.3090905@pentaside.org> Message-ID: <43F0BA7F.6020100@csail.mit.edu> Have you tried the patch I suggested and reverted to building .dylibs? This really seems to indicate that the libraries were not loaded. There may be another warning somewhere that a given library wasn't found or of the three libraries a missing message saying it was loaded. If you can identify which library wasn't loaded it will be easier to track down your problem. Ian Tayssir John Gabbour wrote: > Robert L. Read wrote: > >> Does elephant-0.5 match the value of *elephant-lib-path*? >> I recently changed it to just use "elephant", since we have made >> so many releases in the >> last few months and plan to make more soon. >> >> (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") >> > > Yes, I changed it to: > (defvar *elephant-lib-path* "/Users/main/Apps/asdf/elephant-0.5.0/") > > > Hmm, looking at the ASDF output when it loads Elephant, it has 60 lines > complaining of style-warnings, like: > > ---- > ; loading system definition from > ; /Users/main/Apps/asdf/elephant-0.5.0/elephant.asd into # "ASDF4686"> > ; registering # as ELEPHANT > STYLE-WARNING: Undefined alien: "linux_no_threads_p" > STYLE-WARNING: Undefined alien: "db_env_cr" > STYLE-WARNING: Undefined alien: "db_env_close" > ... more STYLE-WARNINGs... > --- > > (Incidentally, I have XCode 2.1 installed; XCode 2.2 was recently > released...) > > > >> One gentleman who uses a Mac has to modify the makefile so it >> produced a .so instead of a .dylib. You might try that; I don't have >> a Mac and don't fully understand the difference. >> > > Unfortunately, I get the same error when I do that. (Fortunately, make's > willing to make the .so file, with only a few complaints...) > > > Tayssir > > > > > > > Robert L. Read wrote: > >> Does elephant-0.5 match the value of *elephant-lib-path*? >> I recently changed it to just use "elephant", since we have made so many >> releases in the >> last few months and plan to make more soon. >> >> >> (defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") >> >> >> On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: >> >> >>> Yes, make created in (the ASDF-accessible) elephant-0.5/: >>> libsleepycat.dylib >>> libmemutil.dylib >>> >>> Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but >>> I just made a soft and a hard link to: >>> /usr/lib/libdb.dylib >>> >>> which didn't fix the problem. :( >>> >>> >>> Tayssir >>> >>> >>> >>> Robert L. Read wrote: >>> >>>> This is just a guess: >>>> >>>> Did you run "make" and do the following two files exists in this >>>> > location: > >>>> /usr/local/share/common-lisp/elephant/libsleepycat.so >>>> /usr/local/share/common-lisp/elephant/libmemutil.so >>>> >>>> and does >>>> /usr/lib/libdb.so >>>> >>>> exists in a standard lib location, such as /usr/lib/libdb.so? >>>> >>>> >>>> On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: >>>> >>>> >>>>> Hi all, >>>>> >>>>> (I'm using SBCL 0.9.4 on MacOS X) >>>>> >>>>> I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >>>>> loss about how to deal with the following Slime stack trace. (Elephant >>>>> apparently knows about the "dylib" naming convention and all that...) >>>>> >>>>> ---- >>>>> Attempt to call an undefined alien function. >>>>> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >>>>> >>>>> Restarts: >>>>> 0: [ABORT] Abort handling SLIME request. >>>>> 1: [ABORT] Exit debugger, returning to top level. >>>>> >>>>> Backtrace: >>>>> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >>>>> 1: ("foreign function: call_into_lisp") >>>>> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >>>>> 3: (SLEEPYCAT:DB-ENV-CREATE) >>>>> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >>>>> (#(NIL 1) . #()) # #>>>> {11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >>>>> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >>>>> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >>>>> :RECOVER-FATAL NIL :THREAD T) >>>>> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >>>>> #) >>>>> ---- >>>>> >>>>> Thanks for any advice, >>>>> Tayssir >>>>> _______________________________________________ >>>>> 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 tjg-lisp at pentaside.org Mon Feb 13 17:20:57 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Mon, 13 Feb 2006 18:20:57 +0100 Subject: [elephant-devel] Installing on MacOS X, SBCL In-Reply-To: <43F0BA7F.6020100@csail.mit.edu> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> <43F0B6F9.3090905@pentaside.org> <43F0BA7F.6020100@csail.mit.edu> Message-ID: <43F0BFF9.5050805@pentaside.org> Ian Eslick wrote: > Have you tried the patch I suggested and reverted to building > .dylibs? This really seems to indicate that the libraries were > not loaded. There may be another warning somewhere that a given > library wasn't found or of the three libraries a missing message > saying it was loaded. If you can identify which library wasn't > loaded it will be easier to track down your problem. Yes, this one? (eval-when (:compile-toplevel :load-toplevel) (defparameter *c-library-extension* - #+macosx "dylib" - #-macosx "so" )) + #+(or darwin macosx) "dylib" + #-(or darwin macosx) "so" )) I even tried pushing :macosx to *features*, in a fit of cuteness... :-) I'll try tracking down what hasn't been loaded... Tayssir Ian Eslick wrote: > Have you tried the patch I suggested and reverted to building .dylibs? > This really seems to indicate that the libraries were not loaded. There > may be another warning somewhere that a given library wasn't found or of > the three libraries a missing message saying it was loaded. If you can > identify which library wasn't loaded it will be easier to track down > your problem. > > Ian > > Tayssir John Gabbour wrote: > >>Robert L. Read wrote: >> >> >>>Does elephant-0.5 match the value of *elephant-lib-path*? >>>I recently changed it to just use "elephant", since we have made >>>so many releases in the >>>last few months and plan to make more soon. >>> >>>(defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") >>> >> >>Yes, I changed it to: >>(defvar *elephant-lib-path* "/Users/main/Apps/asdf/elephant-0.5.0/") >> >> >>Hmm, looking at the ASDF output when it loads Elephant, it has 60 lines >>complaining of style-warnings, like: >> >>---- >>; loading system definition from >>; /Users/main/Apps/asdf/elephant-0.5.0/elephant.asd into #>"ASDF4686"> >>; registering # as ELEPHANT >>STYLE-WARNING: Undefined alien: "linux_no_threads_p" >>STYLE-WARNING: Undefined alien: "db_env_cr" >>STYLE-WARNING: Undefined alien: "db_env_close" >>... more STYLE-WARNINGs... >>--- >> >>(Incidentally, I have XCode 2.1 installed; XCode 2.2 was recently >>released...) >> >> >> >> >>>One gentleman who uses a Mac has to modify the makefile so it >>>produced a .so instead of a .dylib. You might try that; I don't have >>>a Mac and don't fully understand the difference. >>> >> >>Unfortunately, I get the same error when I do that. (Fortunately, make's >>willing to make the .so file, with only a few complaints...) >> >> >>Tayssir >> >> >> >> >> >> >>Robert L. Read wrote: >> >> >>>Does elephant-0.5 match the value of *elephant-lib-path*? >>>I recently changed it to just use "elephant", since we have made so many >>>releases in the >>>last few months and plan to make more soon. >>> >>> >>>(defvar *elephant-lib-path* "/usr/local/share/common-lisp/elephant/") >>> >>> >>>On Mon, 2006-02-13 at 15:54 +0100, Tayssir John Gabbour wrote: >>> >>> >>> >>>>Yes, make created in (the ASDF-accessible) elephant-0.5/: >>>>libsleepycat.dylib >>>>libmemutil.dylib >>>> >>>>Previously, libdb.dylib was only in /usr/local/BerkeleyDB.4.3/lib/, but >>>>I just made a soft and a hard link to: >>>>/usr/lib/libdb.dylib >>>> >>>>which didn't fix the problem. :( >>>> >>>> >>>>Tayssir >>>> >>>> >>>> >>>>Robert L. Read wrote: >>>> >>>> >>>>>This is just a guess: >>>>> >>>>>Did you run "make" and do the following two files exists in this >>>>> >> >>location: >> >> >>>>>/usr/local/share/common-lisp/elephant/libsleepycat.so >>>>>/usr/local/share/common-lisp/elephant/libmemutil.so >>>>> >>>>>and does >>>>>/usr/lib/libdb.so >>>>> >>>>>exists in a standard lib location, such as /usr/lib/libdb.so? >>>>> >>>>> >>>>>On Mon, 2006-02-13 at 12:10 +0100, Tayssir John Gabbour wrote: >>>>> >>>>> >>>>> >>>>>>Hi all, >>>>>> >>>>>>(I'm using SBCL 0.9.4 on MacOS X) >>>>>> >>>>>>I installed Elephant-0.5.0, BerkeleyDB.4.3, uffi-1.5.7.. and I'm at a >>>>>>loss about how to deal with the following Slime stack trace. (Elephant >>>>>>apparently knows about the "dylib" naming convention and all that...) >>>>>> >>>>>>---- >>>>>>Attempt to call an undefined alien function. >>>>>> [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR] >>>>>> >>>>>>Restarts: >>>>>> 0: [ABORT] Abort handling SLIME request. >>>>>> 1: [ABORT] Exit debugger, returning to top level. >>>>>> >>>>>>Backtrace: >>>>>> 0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR) >>>>>> 1: ("foreign function: call_into_lisp") >>>>>> 2: (SLEEPYCAT::%DB-ENV-CREATE 0) >>>>>> 3: (SLEEPYCAT:DB-ENV-CREATE) >>>>>> 4: ((SB-PCL::FAST-METHOD OPEN-CONTROLLER (BDB-STORE-CONTROLLER)) >>>>>>(#(NIL 1) . #()) # #>>>>>{11DAC349}> (:RECOVER NIL :RECOVER-FATAL NIL :THREAD T)) >>>>>> 5: (ELEPHANT::GET-CONTROLLER "/Users/main/Desktop/testdb") >>>>>> 6: (OPEN-STORE "/Users/main/Desktop/testdb" :RECOVER NIL >>>>>>:RECOVER-FATAL NIL :THREAD T) >>>>>> 7: (SB-INT:EVAL-IN-LEXENV (OPEN-STORE "/Users/main/Desktop/testdb") >>>>>>#) >>>>>>---- >>>>>> >>>>>>Thanks for any advice, >>>>>>Tayssir >>>>>>_______________________________________________ >>>>>>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 tjg-lisp at pentaside.org Tue Feb 14 12:56:55 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Tue, 14 Feb 2006 13:56:55 +0100 Subject: [elephant-devel] YEEHA! Got it to work on MacOS X In-Reply-To: <43F0BFF9.5050805@pentaside.org> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> <43F0B6F9.3090905@pentaside.org> <43F0BA7F.6020100@csail.mit.edu> <43F0BFF9.5050805@pentaside.org> Message-ID: <43F1D397.5000802@pentaside.org> Good morning, Ok, patch attached to this email. Not stress tested, but I can certainly open a store, put stuff in it, close it, then find it again upon reopening. Patch is against 0.5.0, and I'm now running SBCL 0.99. Tayssir -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: elephant.patch URL: From read at robertlread.net Tue Feb 14 13:58:59 2006 From: read at robertlread.net (Robert L. Read) Date: Tue, 14 Feb 2006 07:58:59 -0600 Subject: [elephant-devel] YEEHA! Got it to work on MacOS X In-Reply-To: <43F1D397.5000802@pentaside.org> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> <43F0B6F9.3090905@pentaside.org> <43F0BA7F.6020100@csail.mit.edu> <43F0BFF9.5050805@pentaside.org> <43F1D397.5000802@pentaside.org> Message-ID: <1139925539.12408.400.camel@localhost.localdomain> Thanks! I'm glad it's working for you. If you have any suspicions that it is not working, you may wish to run the full test suite, BerkeleyDB-tests.lisp. On Tue, 2006-02-14 at 13:56 +0100, Tayssir John Gabbour wrote: > Good morning, > > Ok, patch attached to this email. Not stress tested, but I can certainly > open a store, put stuff in it, close it, then find it again upon reopening. > > Patch is against 0.5.0, and I'm now running SBCL 0.99. > > Tayssir > > plain text document attachment (elephant.patch) > > Common subdirectories: /Users/blah/Desktop/elephant/src/CVS and ../src/CVS > diff -U 5 /Users/blah/Desktop/elephant/src/bdb-enable.lisp ../src/bdb-enable.lisp > --- /Users/blah/Desktop/elephant/src/bdb-enable.lisp 2006-02-06 01:30:54.000000000 +0100 > +++ ../src/bdb-enable.lisp 2006-02-14 13:40:19.000000000 +0100 > @@ -63,11 +63,11 @@ > ;; Sleepycat: this works on linux > #+linux > ;; "/db/ben/lisp/db43/lib/libdb.so" > "/usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so" > ;; this works on FreeBSD > - #+(and (or bsd freebsd) (not darwin macosx)) > + #+(and (or bsd freebsd) (not darwin) (not macosx)) > "/usr/local/lib/db43/libdb.so" > #+(or darwin macosx) > ;; for Fink (OS X) -- but I will assume Linux more common... > ;; "/sw/lib/libdb-4.3.dylib" > ;; a possible manual install > diff -U 5 /Users/blah/Desktop/elephant/src/serializer.lisp ../src/serializer.lisp > --- /Users/blah/Desktop/elephant/src/serializer.lisp 2006-02-06 01:30:54.000000000 +0100 > +++ ../src/serializer.lisp 2006-02-14 13:46:00.000000000 +0100 > @@ -464,11 +464,11 @@ > > > (eval-when (:compile-toplevel :load-toplevel) > (asdf:operate 'asdf:load-op :cl-base64) > ) > -(defun ser-deser-equal (x1 &keys sc) > +(defun ser-deser-equal (x1 &key sc) > (let* ( > (x1s (serialize-to-base64-string x1)) > (x1prime (deserialize-from-base64-string x1s :sc sc))) > (assert (equal x1 x1prime)) > (equal x1 x1prime))) > @@ -480,11 +480,11 @@ > (sleepycat::buffer-read-byte-vector > (serialize x out-buf)))) > ) > > > -(defun deserialize-from-base64-string (x &keys sc) > +(defun deserialize-from-base64-string (x &key sc) > (with-buffer-streams (other) > (deserialize > (sleepycat::buffer-write-byte-vector > other > (cl-base64::base64-string-to-usb8-array x)) > _______________________________________________ > 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 tjg-lisp at pentaside.org Tue Feb 14 14:23:56 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Tue, 14 Feb 2006 15:23:56 +0100 Subject: [elephant-devel] YEEHA! Got it to work on MacOS X In-Reply-To: <1139925539.12408.400.camel@localhost.localdomain> References: <43F06914.2030300@pentaside.org> <1139838565.12408.338.camel@localhost.localdomain> <43F09DA7.9060400@pentaside.org> <1139843066.12408.344.camel@localhost.localdomain> <1139843751.12408.352.camel@localhost.localdomain> <43F0B6F9.3090905@pentaside.org> <43F0BA7F.6020100@csail.mit.edu> <43F0BFF9.5050805@pentaside.org> <43F1D397.5000802@pentaside.org> <1139925539.12408.400.camel@localhost.localdomain> Message-ID: <43F1E7FC.5090403@pentaside.org> Cool. It ran a whole bunch of tests, apparently successfully, and at the end here are the ones it appears to have skipped (out of 106): ---- *test-path-secondary* and *test-path-primary* not both set, skipping this test. REMOVE-ELEMENT*test-path-secondary* and *test-path-primary* not both set, skipping this test. MIGRATE1*test-path-secondary* and *test-path-primary* not both set, skipping this test. MIGRATE2*test-path-secondary* and *test-path-primary* not both set, skipping this test. MIGRATE3*test-path-secondary* and *test-path-primary* not both set, skipping this test. MIGRATE4*test-path-secondary* and *test-path-primary* not both set, skipping this test. MIGRATE5 No tests failed. ---- Tayssir Robert L. Read wrote: > Thanks! I'm glad it's working for you. > > If you have any suspicions that it is not working, you may wish to run > the full test suite, > BerkeleyDB-tests.lisp. > > On Tue, 2006-02-14 at 13:56 +0100, Tayssir John Gabbour wrote: > >>Good morning, >> >>Ok, patch attached to this email. Not stress tested, but I can certainly >>open a store, put stuff in it, close it, then find it again upon reopening. >> >>Patch is against 0.5.0, and I'm now running SBCL 0.99. >> >>Tayssir >> >> plain text document attachment (elephant.patch) From eslick at csail.mit.edu Fri Feb 17 01:01:27 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 16 Feb 2006 20:01:27 -0500 Subject: [elephant-devel] Any Allegro users out there? Message-ID: <43F52067.7080106@csail.mit.edu> I found that my prior solution to string serialization on Mac OS X was too slow. I believe I have a better fix but am worried about whether it works on allegro on all platforms (endianness, etc). What Allegro users are out there and what platform configurations and allegro versions are you using? If you send me mail offline (eslick at media.mit.edu) I may try to ask you to help me test this fix. It provides about a 4x improvement in one benchmark that is important to me and generally speeds up all symbol & string serialization so should have very positive performance implications. My specs are: - PowerPC G4 - Mac OS X 10.4 - Allegro 8.0 Enterprise (default alisp image) Regards, Ian From tjg-lisp at pentaside.org Fri Feb 17 11:00:23 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Fri, 17 Feb 2006 12:00:23 +0100 Subject: [elephant-devel] Mutating slots persistently? Message-ID: <43F5ACC7.7010504@pentaside.org> Hi, How do people deal with the following problem... suppose I have a persistent object with a slot that holds a list. And I mutate the list with RPLACA. (Perhaps an innocent-looking SETF which expands into RPLACA.) Well, this won't be stored persistently. How do people deal with this situation? Basically just always use methods which set the entire slot? Are there any tricks to keep from having to do this? Thanks, Tayssir From whalliburton at gmail.com Fri Feb 17 04:30:35 2006 From: whalliburton at gmail.com (William Halliburton) Date: Thu, 16 Feb 2006 23:30:35 -0500 Subject: [elephant-devel] with-slots in SBCL 0.9.7 Message-ID: <4e7bd29e0602162030k440cc5d0v506bc0ff2f742212@mail.gmail.com> with-slots does not seem to work for a persistent-metaclass object. I get When attempting to read the slot's value (slot-value), the slot DATE is missing from the object #. [Condition of type SIMPLE-ERROR] I can use accessors, but would rather use with-slots. Any ideas? Thank you, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Fri Feb 17 14:05:06 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 08:05:06 -0600 Subject: [elephant-devel] with-slots in SBCL 0.9.7 In-Reply-To: <4e7bd29e0602162030k440cc5d0v506bc0ff2f742212@mail.gmail.com> References: <4e7bd29e0602162030k440cc5d0v506bc0ff2f742212@mail.gmail.com> Message-ID: <1140185106.12408.586.camel@localhost.localdomain> I would like to help with this, but am right in the middle of trying to get 0.6.0 finalized. Perhaps someone else can look at it, but if you need it in the next few weeks you may have to work around it or debug it yourself. On Thu, 2006-02-16 at 23:30 -0500, William Halliburton wrote: > > with-slots does not seem to work for a persistent-metaclass object. I > get > > When attempting to read the slot's value (slot-value), the slot DATE > is missing > from the object #. > [Condition of type SIMPLE-ERROR] > > I can use accessors, but would rather use with-slots. > > Any ideas? > > Thank you, > Will > > _______________________________________________ > 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 read at robertlread.net Fri Feb 17 14:11:01 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 08:11:01 -0600 Subject: [elephant-devel] Mutating slots persistently? In-Reply-To: <43F5ACC7.7010504@pentaside.org> References: <43F5ACC7.7010504@pentaside.org> Message-ID: <1140185461.12408.592.camel@localhost.localdomain> Yes --- in my opinion (which gets more humble everyday), you just need to reset the entire slot with setf. I can't think of a better solution right now. One could, of course, store the list as separate persistent data items, or use a btree for the entire list. This would make the change to a single item of the list more or less automatically saved; however, the great advantage of Elephant is that that it allows you to use the LISP data-space design that you prefer more or less directly, and changing that defeats some of the advantage of using Elephant. On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote: > Hi, > > How do people deal with the following problem... suppose I have a > persistent object with a slot that holds a list. And I mutate the list > with RPLACA. (Perhaps an innocent-looking SETF which expands into > RPLACA.) Well, this won't be stored persistently. > > How do people deal with this situation? Basically just always use > methods which set the entire slot? Are there any tricks to keep from > having to do this? > > Thanks, > Tayssir > > _______________________________________________ > 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 tjg-lisp at pentaside.org Fri Feb 17 14:23:56 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Fri, 17 Feb 2006 15:23:56 +0100 Subject: [elephant-devel] with-slots in SBCL 0.9.7 Message-ID: <43F5DC7C.3070301@pentaside.org> William Halliburton wrote: > with-slots does not seem to work for a persistent-metaclass object. > I get > > When attempting to read the slot's value (slot-value), the slot > DATE is missing > from the object #. > [Condition of type SIMPLE-ERROR] > > I can use accessors, but would rather use with-slots. Hi, Hmm, on my SBCL 0.99 (on Darwin/PPC) WITH-SLOTS works fine. Could you reproduce it in a small form like the following? (defclass my-simple-test-class () ((slot1 :accessor slot1 :initarg :slot1 :initform 10)) (:metaclass persistent-metaclass)) (defmethod print-object ((o my-simple-test-class) s) (with-slots (slot1) o (print-unreadable-object (o s :type t :identity t) (format s "~S:~S" 'slot1 slot1)))) Now at the REPL: CL-USER> (add-to-root "elephant-devel" (make-instance 'my-simple-test-class :slot1 20)) # CL-USER> (with-slots (slot1) (get-from-root "elephant-devel") slot1) 20 Tayssir From read at robertlread.net Fri Feb 17 15:17:06 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 09:17:06 -0600 Subject: [elephant-devel] A thorny problem.... Message-ID: <1140189426.12408.597.camel@localhost.localdomain> I think I've a identified a serious problem relating to the the dependencies on various modules that I offer up for you comment. I major goal of the multiple backend system is to allow you to not need to install the software related to the system you don't need. If you want to use BerkeleyDB, you shouldn't have to install CL-SQL. If you want to use CL-SQL and a relational database, you can't shouldn't have to install BerkeleyDB (which would subject you to their license, in any case.) Unfortunately, the "with-transaction" macro, which exists in cl-sql, BDB, and also Elephant, must be in place at compilation time. I have written this macro to take a key argument, and, based on the type of the passed-in store-controller, to resolve either to the CL-SQL with-transaction macro, or the existing with-transaciton macro for BDB. I don't know how to write this macro without having CL-SQL macro loaded (which implies that you have it installed.) I am therefore in a bind: I can't right a generic with-transaction macro without loading CL-SQL, and I can't make you install CL-SQL if you don't want to use it. The macros cannot be treated as functions, (which could easily remain undefined if they did not actually need to be executed), since the "with-transaction" idea cannot possibly be written as a function. I can think of two solutions: 1) Create two asdf systems: one for with clsql, one without. Then it would not be possible or necessary to load "elephant" without choosing a back-end (or a set of back-ends). 2) Alternatively, the loading of the cl-sql module could reload the files with macro in place. This will technically work, but is hideous in the sense that performing a (asdf:operate 'asdf:load-op :ele-clsql) would perform a reloading or a recompilation of more than half the project. Unless someone can provide me some better advice, I'm going to investigate #1. I find all of these dependencies complicated, and macros tend to exacerbate the problem. Perhaps there is a much simpler way of dealing with this that someone can suggest. I must admit that I don't understand how 0.5.0 works, and why only now Ian Eslick's code in the head brings this problem to light. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Fri Feb 17 15:50:14 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 17 Feb 2006 10:50:14 -0500 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <1140189426.12408.597.camel@localhost.localdomain> References: <1140189426.12408.597.camel@localhost.localdomain> Message-ID: <43F5F0B6.1070401@csail.mit.edu> I've been absently noodling over the same problem. I think in general we want to factor out the backends more cleanly so we can have a load system like that in UCW, Slime, CL-SQL, etc. (multiple backends where only one needs to be loaded). Robert has already done much of the work toward this with cursors, btrees, etc One way to handle the transaction macro, although we should think about this a bit because it adds a function call cost during short transactions and I may also be missing some dependency: (defmacro with-transaction ((&key store-controller ...) &body body) `(execute-store-transaction store-controller (lambda (*store-controller* *auto-commit* ...) (declare (special *store-controller* *auto-commit*)) , at body))) Then for BDB: (defmethod execute-store-transaction ((store bdb-store-controller) body args) `(loop .... (let ((,txn (db-transaction-begin ...insert args...))) (catch 'transaction (unwind-protect (prog1 (funcall body store-controller nil) (setq ,success t) (db-transaction-success ...) (unless ,success (db-transaction-abort ...) ...)) Don't you just love lisp? This is one of the functions of closures; to dynamically manipulate lexical environments without having to do source transformations. I think the closure will naturally reference external specials like *store-controller* without us needed to pass them in the lambda - but passing them in the lambda gives us more control over the body of the transaction. cl-prevalence did something very similar to this (all transaction bodies were named lambdas that could be called later to replay a transaction). In this way a backend needs to implement: store protocol transaction protocol btree protocol indexed-btree btree-index cursor protocol persistent object protocol (those aux functions you created are a good start) The current implementation of class indexing should come for free, I tried to make it backend independant but for performance we might want to implement a native protocol later. The load sequence can be like CL-SQL and UCW: a main load (elephant), to define the interface and common functionality followed by a backend load (ele-bdb or ele-sqlite3 or ele-postgres). You can also make the backend load part of a dispatch list in the (open-store) function. You open a store with a keyword specified of :type 'bdb and :spec "/pathname/" and that code calls asdf:load-op on the appropriate backend loader. Ideally each family of backends would have its own subdirectory and files to implement the protocols and any other functionality (like sleepycat). I have a pretty good idea of what this should look like and would be happy to help do it as part of 0.6.0 as I don't think it's that much work if done incrementally and carefully. Robert, do you want me to take a crack at the transaction fix? I've got a great stress test application on my side with lots of rapid transactions and some good performance data to compare against. Anyway, my ten cents... Ian Robert L. Read wrote: > I think I've a identified a serious problem relating to the > the dependencies on various modules that I offer up > for you comment. > > I major goal of the multiple backend system is to allow > you to not need to install the software related to the system > you don't need. If you want to use BerkeleyDB, you shouldn't have > to install CL-SQL. If you want to use CL-SQL and a relational database, > you can't shouldn't have to install BerkeleyDB (which would subject > you to their license, in any case.) > > Unfortunately, the "with-transaction" macro, which exists in > cl-sql, BDB, and also Elephant, must be in place at compilation > time. > > I have written this macro to take a key argument, and, based on > the type of the passed-in store-controller, to resolve either to > the CL-SQL with-transaction macro, or the existing with-transaciton > macro for BDB. > > I don't know how to write this macro without having CL-SQL macro > loaded (which implies that you have it installed.) > > I am therefore in a bind: > I can't right a generic with-transaction macro without loading CL-SQL, > and I can't make you install CL-SQL if you don't want to use it. > The macros cannot be treated as functions, (which could easily remain > undefined if they did not actually need to be executed), since the > "with-transaction" idea cannot possibly be written as a function. > > I can think of two solutions: > > 1) Create two asdf systems: one for with clsql, one without. Then > it would not be possible or necessary to load "elephant" without > choosing a back-end (or a set of back-ends). > 2) Alternatively, the loading of the cl-sql module could reload the > files with macro in place. This will technically work, but is hideous > in the sense that performing a > (asdf:operate 'asdf:load-op :ele-clsql) > would perform a reloading or a recompilation of more than half the > project. > > Unless someone can provide me some better advice, I'm going to > investigate > #1. > > I find all of these dependencies complicated, and macros tend to > exacerbate > the problem. Perhaps there is a much simpler way of dealing with this > that someone can suggest. > > > I must admit that I don't understand how 0.5.0 works, and why only now > Ian Eslick's code in the head brings this problem to light. > > > ---- > Robert L. Read, PhD read &T > robertlread.net > Consider visiting Progressive Engineering: http://robertlread.net/pe > In Austin: 912-8593 "Think > globally, Act locally." -- RBF > > > ------------------------------------------------------------------------ > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From read at robertlread.net Fri Feb 17 16:20:03 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 10:20:03 -0600 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <43F5F0B6.1070401@csail.mit.edu> References: <1140189426.12408.597.camel@localhost.localdomain> <43F5F0B6.1070401@csail.mit.edu> Message-ID: <1140193203.12408.610.camel@localhost.localdomain> Yes, this is a great solution. I was fumbling towards it, having defined "get-transaction-macro-symbol" already, but you have a much greater command of it. Clearly, something like this where a completely back-end specific method accomplishes the "with-transaction" need is the clean way to go, and allows for expansion to other back-ends (like a simple file) later. I completely agree that having different directories for different back-ends is a very clean and clarifying way to handle it. I would be very grateful if you would do this Ian; I suspect you can do it faster than I can. I will support you in anyway possible. It's not hard to be a maintainer when people such as yourself are so very helpful! If you can complete the entire plan you've outlined in 0.6.0, great! If not, I think if we can just solve the "transaction problem" (which I think will make us green on all of the tests for all of the currently tested implementation), then I would be happy to release 0.6.0 at that point. But remember the Inventor's Paradox: sometimes doing the more ambitious thing is easier. Let me know how I can help. On Fri, 2006-02-17 at 10:50 -0500, Ian Eslick wrote: > I've been absently noodling over the same problem. I think in general > we want to factor out the backends more cleanly so we can have a load > system like that in UCW, Slime, CL-SQL, etc. (multiple backends where > only one needs to be loaded). Robert has already done much of the work > toward this with cursors, btrees, etc > > One way to handle the transaction macro, although we should think about > this a bit because it adds a function call cost during short > transactions and I may also be missing some dependency: > > (defmacro with-transaction ((&key store-controller ...) &body body) > `(execute-store-transaction store-controller > (lambda (*store-controller* *auto-commit* ...) > (declare (special *store-controller* *auto-commit*)) > , at body))) > > Then for BDB: > > (defmethod execute-store-transaction ((store bdb-store-controller) body > args) > `(loop > .... > (let ((,txn (db-transaction-begin ...insert args...))) > (catch 'transaction > (unwind-protect > (prog1 (funcall body store-controller nil) > (setq ,success t) > (db-transaction-success ...) > (unless ,success > (db-transaction-abort ...) > ...)) > > Don't you just love lisp? This is one of the functions of closures; to > dynamically manipulate lexical environments without having to do source > transformations. I think the closure will naturally reference > external specials like *store-controller* without us needed to pass them > in the lambda - but passing > them in the lambda gives us more control over the body of the > transaction. cl-prevalence did something > very similar to this (all transaction bodies were named lambdas that > could be called later to replay > a transaction). > > In this way a backend needs to implement: > store protocol > transaction protocol > btree protocol > indexed-btree > btree-index > cursor protocol > persistent object protocol (those aux functions you created are a good > start) > > The current implementation of class indexing should come for free, I > tried to make it backend independant but for performance we might want > to implement a native protocol later. > > The load sequence can be like CL-SQL and UCW: a main load (elephant), to > define the interface and common functionality followed by a backend load > (ele-bdb or ele-sqlite3 or ele-postgres). You can also make the backend > load part of a dispatch list in the (open-store) function. You open a > store with a keyword specified of :type 'bdb and :spec "/pathname/" and > that code calls asdf:load-op on the appropriate backend loader. > > Ideally each family of backends would have its own subdirectory and > files to implement the protocols and any other functionality (like > sleepycat). > > I have a pretty good idea of what this should look like and would be > happy to help do it as part of 0.6.0 as I don't think it's that much > work if done incrementally and carefully. > > Robert, do you want me to take a crack at the transaction fix? I've got > a great stress test application on my side with lots of rapid > transactions and some good performance data to compare against. > > Anyway, my ten cents... > > Ian > > Robert L. Read wrote: > > I think I've a identified a serious problem relating to the > > the dependencies on various modules that I offer up > > for you comment. > > > > I major goal of the multiple backend system is to allow > > you to not need to install the software related to the system > > you don't need. If you want to use BerkeleyDB, you shouldn't have > > to install CL-SQL. If you want to use CL-SQL and a relational database, > > you can't shouldn't have to install BerkeleyDB (which would subject > > you to their license, in any case.) > > > > Unfortunately, the "with-transaction" macro, which exists in > > cl-sql, BDB, and also Elephant, must be in place at compilation > > time. > > > > I have written this macro to take a key argument, and, based on > > the type of the passed-in store-controller, to resolve either to > > the CL-SQL with-transaction macro, or the existing with-transaciton > > macro for BDB. > > > > I don't know how to write this macro without having CL-SQL macro > > loaded (which implies that you have it installed.) > > > > I am therefore in a bind: > > I can't right a generic with-transaction macro without loading CL-SQL, > > and I can't make you install CL-SQL if you don't want to use it. > > The macros cannot be treated as functions, (which could easily remain > > undefined if they did not actually need to be executed), since the > > "with-transaction" idea cannot possibly be written as a function. > > > > I can think of two solutions: > > > > 1) Create two asdf systems: one for with clsql, one without. Then > > it would not be possible or necessary to load "elephant" without > > choosing a back-end (or a set of back-ends). > > 2) Alternatively, the loading of the cl-sql module could reload the > > files with macro in place. This will technically work, but is hideous > > in the sense that performing a > > (asdf:operate 'asdf:load-op :ele-clsql) > > would perform a reloading or a recompilation of more than half the > > project. > > > > Unless someone can provide me some better advice, I'm going to > > investigate > > #1. > > > > I find all of these dependencies complicated, and macros tend to > > exacerbate > > the problem. Perhaps there is a much simpler way of dealing with this > > that someone can suggest. > > > > > > I must admit that I don't understand how 0.5.0 works, and why only now > > Ian Eslick's code in the head brings this problem to light. > > > > > > ---- > > Robert L. Read, PhD read &T > > robertlread.net > > Consider visiting Progressive Engineering: http://robertlread.net/pe > > In Austin: 912-8593 "Think > > globally, Act locally." -- RBF > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 janderson at ravenpack.com Fri Feb 17 16:08:37 2006 From: janderson at ravenpack.com (James Anderson) Date: Fri, 17 Feb 2006 17:08:37 +0100 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <1140189426.12408.597.camel@localhost.localdomain> Message-ID: hello; -----Original Message----- From: elephant-devel-bounces at common-lisp.net [mailto:elephant-devel-bounces at common-lisp.net]On Behalf Of Robert L. Read Sent: Friday, February 17, 2006 16.17 To: Elephant-devel mailing list Subject: [elephant-devel] A thorny problem.... I think I've a identified a serious problem relating to the the dependencies on various modules that I offer up for you comment. i have a naive know ledge of elephant, but would be surprised that this is a problem. one writes a macro which targets a generic function. a macro does several useful things. 1. it preforms syntactic rewriting 2. it delays evaluation. 3. if it is to be useful, this king of macro provides a standard interface to varying implementations. when i skim over the definitions which i find in utils.lisp and berkeley.lisp, i observe that thay do lots of 1, none of 2 and half of three, and that it appears that their siginficance to a bit of application code depends on the active package. in order to avoid what you describe as a thorny problem, you would need to - have one macro only. not different ones with analogous names in different packages. - have that macro always take the same syntax (which those seem, mostly, to do) - prepare all arguments to pass to an implementation-specific function - capture the body in a closure - invoke the implementation-specific function with a specializing argument, the closure, and the keyword arguments. the implementation-specific function is generic, with a method defined by each backend. the approach is good parcive in general for macros - means you don't need to recompile code if the implementation changes, but is essential to implement and use modular back.ends. ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Fri Feb 17 19:20:12 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 17 Feb 2006 14:20:12 -0500 Subject: [elephant-devel] Mutating slots persistently? In-Reply-To: <1140185461.12408.592.camel@localhost.localdomain> References: <43F5ACC7.7010504@pentaside.org> <1140185461.12408.592.camel@localhost.localdomain> Message-ID: <43F621EC.60004@csail.mit.edu> There are no tricks, this is pretty fundamental to the semantics of lisp. The metaclass protocol allows you to override operations on slots, but not operations on arbitrary lisp objects (like complex numbers, cons cells, etc) so there's no way to intercede. Typically, if you're having this problem there is probably an opportunity to think differently about how you construction your data and functional abstractions. Ask what you're trying to manipulate and why you want it to persist (where ordinarily you'd write a file IO routine to save/restore the data) and just make sure the functions that implement the abstraction push data to the persistent store at the appropriate points by, as Robert said, setf'ing the persistent object slot. One other thought and something I do often is perform list operations over a set of persistent objects. That way if I do operations on the car of a cons my functions side effect the persistent object (as in find, replace, etc). Lists should be stored in elephant only when they can be done so infrequently. Elephant is, after all, a persistent 'object' store rather than a Persistent Lisp. :) Ian Robert L. Read wrote: > Yes --- in my opinion (which gets more humble everyday), you just need to > reset the entire slot with setf. > > I can't think of a better solution right now. > > One could, of course, store the list as separate persistent data items, or > use a btree for the entire list. This would make the change to a > single item > of the list more or less automatically saved; however, the great > advantage of > Elephant is that that it allows you to use the LISP data-space design > that > you prefer more or less directly, and changing that defeats some of the > advantage of using Elephant. > > > > > On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote: >> Hi, >> >> How do people deal with the following problem... suppose I have a >> persistent object with a slot that holds a list. And I mutate the list >> with RPLACA. (Perhaps an innocent-looking SETF which expands into >> RPLACA.) Well, this won't be stored persistently. >> >> How do people deal with this situation? Basically just always use >> methods which set the entire slot? Are there any tricks to keep from >> having to do this? >> >> Thanks, >> Tayssir >> >> _______________________________________________ >> 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 tjg-lisp at pentaside.org Fri Feb 17 19:44:23 2006 From: tjg-lisp at pentaside.org (Tayssir John Gabbour) Date: Fri, 17 Feb 2006 20:44:23 +0100 Subject: [elephant-devel] Mutating slots persistently? In-Reply-To: <43F621EC.60004@csail.mit.edu> References: <43F5ACC7.7010504@pentaside.org> <1140185461.12408.592.camel@localhost.localdomain> <43F621EC.60004@csail.mit.edu> Message-ID: <43F62797.3060302@pentaside.org> Yeah, I was hoping for something off-the-wall like, say, (differently-named) SETF and DEFINE-SETF-EXPANDER replacements. But I guess that's just too weird and maybe would give people the wrong impression. ;) Thanks, Tayssir Ian Eslick wrote: > There are no tricks, this is pretty fundamental to the semantics of > lisp. The metaclass protocol allows you to override operations on > slots, but not operations on arbitrary lisp objects (like complex > numbers, cons cells, etc) so there's no way to intercede. > > Typically, if you're having this problem there is probably an > opportunity to think differently about how you construction your data > and functional abstractions. Ask what you're trying to manipulate and > why you want it to persist (where ordinarily you'd write a file IO > routine to save/restore the data) and just make sure the functions that > implement the abstraction push data to the persistent store at the > appropriate points by, as Robert said, setf'ing the persistent object slot. > > One other thought and something I do often is perform list operations > over a set of persistent objects. That way if I do operations on the > car of a cons my functions side effect the persistent object (as in > find, replace, etc). Lists should be stored in elephant only when they > can be done so infrequently. > > Elephant is, after all, a persistent 'object' store rather than a > Persistent Lisp. :) > > Ian > > > Robert L. Read wrote: > >>Yes --- in my opinion (which gets more humble everyday), you just need to >>reset the entire slot with setf. >> >>I can't think of a better solution right now. >> >>One could, of course, store the list as separate persistent data items, or >>use a btree for the entire list. This would make the change to a >>single item >>of the list more or less automatically saved; however, the great >>advantage of >>Elephant is that that it allows you to use the LISP data-space design >>that >>you prefer more or less directly, and changing that defeats some of the >>advantage of using Elephant. >> >> >> >> >>On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote: >> >>>Hi, >>> >>>How do people deal with the following problem... suppose I have a >>>persistent object with a slot that holds a list. And I mutate the list >>>with RPLACA. (Perhaps an innocent-looking SETF which expands into >>>RPLACA.) Well, this won't be stored persistently. >>> >>>How do people deal with this situation? Basically just always use >>>methods which set the entire slot? Are there any tricks to keep from >>>having to do this? >>> >>>Thanks, >>>Tayssir >>> >>>_______________________________________________ >>>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 eslick at csail.mit.edu Fri Feb 17 22:37:03 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 17 Feb 2006 17:37:03 -0500 Subject: [elephant-devel] Mutating slots persistently? In-Reply-To: <43F62797.3060302@pentaside.org> References: <43F5ACC7.7010504@pentaside.org> <1140185461.12408.592.camel@localhost.localdomain> <43F621EC.60004@csail.mit.edu> <43F62797.3060302@pentaside.org> Message-ID: <43F6500F.6080903@csail.mit.edu> Hmmmm.... Out of curiosity, I just looked at BDB and it appears that the underlying database allows partial writes into key and data fields. With a whole bunch of low level API changes it would theoretically be possible to support rplaca, (setf aref) and other such subfield sets (and gets) at the DB level. The API wouldn't allow that today. Is the same thing true of SQL? Can you do a partial write into a blob field (or whatever rep we're using to store serialized data) in a SQL table? The immediate problems to think about relate to figuring out how to maintain the consistency of the serialized target. There's also an even bigger problem in how to hook into the lisp APIs in a tasteful way (setf (aref (get-value key btree) 5) 10) couldn't be overloaded due to aref not being a generic function. You might be able to have a parallel syntax (setf (paref (get-value key btree) 5) 10) that would work... Just something to archive for a very ambitious hack that someone else would have to do. ;) Ian Tayssir John Gabbour wrote: > Yeah, I was hoping for something off-the-wall like, say, > (differently-named) SETF and DEFINE-SETF-EXPANDER replacements. But I > guess that's just too weird and maybe would give people the wrong > impression. ;) > > Thanks, > Tayssir > > > > Ian Eslick wrote: > >> There are no tricks, this is pretty fundamental to the semantics of >> lisp. The metaclass protocol allows you to override operations on >> slots, but not operations on arbitrary lisp objects (like complex >> numbers, cons cells, etc) so there's no way to intercede. >> >> Typically, if you're having this problem there is probably an >> opportunity to think differently about how you construction your data >> and functional abstractions. Ask what you're trying to manipulate and >> why you want it to persist (where ordinarily you'd write a file IO >> routine to save/restore the data) and just make sure the functions that >> implement the abstraction push data to the persistent store at the >> appropriate points by, as Robert said, setf'ing the persistent object >> > slot. > >> One other thought and something I do often is perform list operations >> over a set of persistent objects. That way if I do operations on the >> car of a cons my functions side effect the persistent object (as in >> find, replace, etc). Lists should be stored in elephant only when they >> can be done so infrequently. >> >> Elephant is, after all, a persistent 'object' store rather than a >> Persistent Lisp. :) >> >> Ian >> >> >> Robert L. Read wrote: >> >> >>> Yes --- in my opinion (which gets more humble everyday), you just need to >>> reset the entire slot with setf. >>> >>> I can't think of a better solution right now. >>> >>> One could, of course, store the list as separate persistent data items, or >>> use a btree for the entire list. This would make the change to a >>> single item >>> of the list more or less automatically saved; however, the great >>> advantage of >>> Elephant is that that it allows you to use the LISP data-space design >>> that >>> you prefer more or less directly, and changing that defeats some of the >>> advantage of using Elephant. >>> >>> >>> >>> >>> On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote: >>> >>> >>>> Hi, >>>> >>>> How do people deal with the following problem... suppose I have a >>>> persistent object with a slot that holds a list. And I mutate the list >>>> with RPLACA. (Perhaps an innocent-looking SETF which expands into >>>> RPLACA.) Well, this won't be stored persistently. >>>> >>>> How do people deal with this situation? Basically just always use >>>> methods which set the entire slot? Are there any tricks to keep from >>>> having to do this? >>>> >>>> Thanks, >>>> Tayssir >>>> >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > From eslick at csail.mit.edu Sat Feb 18 00:05:02 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Fri, 17 Feb 2006 19:05:02 -0500 Subject: [elephant-devel] Multi-repository operation Message-ID: <43F664AE.2060607@csail.mit.edu> How important is multi-repository operation for any application other than migration? If we can limit two live stores and live objects to being from multiple stores to that specific case, then we can simplify a bunch of stuff that would be worrying about interleaved transaction from multiple stores and conflicts between the current *store-controller* and a persistent objects' database connection spec. If we do want to support this more generally, I can add some error checking in the meantime to squawk when a the body of transaction is trying to write to a store that isn't protected by the transaction (i.e. the transaction turns off auto-commit and a write to a non-protected store fails to receive the auto-commit signal). I'll not worry about this for now, but want some voting on whether we should be fixing these possible screw cases. (Some of which have bit us during running tests over multiple backends). Cheers, Ian From read at robertlread.net Sat Feb 18 04:15:01 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 22:15:01 -0600 Subject: [elephant-devel] Multi-repository operation In-Reply-To: <43F664AE.2060607@csail.mit.edu> References: <43F664AE.2060607@csail.mit.edu> Message-ID: <1140236101.12408.626.camel@localhost.localdomain> IMHO, multi-repository operation is mainly valuable during migration from one implementation to another. I don't believe support cross-repository transactions if valuable, compared to other improvements that could be made. But please, don't let my opinion keep others from commenting..... On Fri, 2006-02-17 at 19:05 -0500, Ian Eslick wrote: > How important is multi-repository operation for any application other > than migration? > > If we can limit two live stores and live objects to being from multiple > stores to that specific case, then we can simplify a bunch of stuff that > would be worrying about interleaved transaction from multiple stores and > conflicts between the current *store-controller* and a persistent > objects' database connection spec. > > If we do want to support this more generally, I can add some error > checking in the meantime to squawk when a the body of transaction is > trying to write to a store that isn't protected by the transaction (i.e. > the transaction turns off auto-commit and a write to a non-protected > store fails to receive the auto-commit signal). > > I'll not worry about this for now, but want some voting on whether we > should be fixing these possible screw cases. (Some of which have bit us > during running tests over multiple backends). > > Cheers, > Ian > _______________________________________________ > 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 read at robertlread.net Sat Feb 18 04:15:01 2006 From: read at robertlread.net (Robert L. Read) Date: Fri, 17 Feb 2006 22:15:01 -0600 Subject: [elephant-devel] Multi-repository operation In-Reply-To: <43F664AE.2060607@csail.mit.edu> References: <43F664AE.2060607@csail.mit.edu> Message-ID: <1140236101.12408.626.camel@localhost.localdomain> IMHO, multi-repository operation is mainly valuable during migration from one implementation to another. I don't believe support cross-repository transactions if valuable, compared to other improvements that could be made. But please, don't let my opinion keep others from commenting..... On Fri, 2006-02-17 at 19:05 -0500, Ian Eslick wrote: > How important is multi-repository operation for any application other > than migration? > > If we can limit two live stores and live objects to being from multiple > stores to that specific case, then we can simplify a bunch of stuff that > would be worrying about interleaved transaction from multiple stores and > conflicts between the current *store-controller* and a persistent > objects' database connection spec. > > If we do want to support this more generally, I can add some error > checking in the meantime to squawk when a the body of transaction is > trying to write to a store that isn't protected by the transaction (i.e. > the transaction turns off auto-commit and a write to a non-protected > store fails to receive the auto-commit signal). > > I'll not worry about this for now, but want some voting on whether we > should be fixing these possible screw cases. (Some of which have bit us > during running tests over multiple backends). > > Cheers, > Ian > _______________________________________________ > 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 klaus at harbo.net Sat Feb 18 17:33:31 2006 From: klaus at harbo.net (Klaus Harbo) Date: Sat, 18 Feb 2006 18:33:31 +0100 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <1140189426.12408.597.camel@localhost.localdomain> References: <1140189426.12408.597.camel@localhost.localdomain> Message-ID: On 17/02/2006, at 16:17, Robert L. Read wrote: > I think I've a identified a serious problem relating to the > the dependencies on various modules that I offer up > for you comment. > > I major goal of the multiple backend system is to allow > you to not need to install the software related to the system > you don't need. If you want to use BerkeleyDB, you shouldn't have > to install CL-SQL. If you want to use CL-SQL and a relational > database, > you can't shouldn't have to install BerkeleyDB (which would subject > you to their license, in any case.) I have spent some time looking at what it would take to make Elephant work with Lispworks. It would a considerable advantage if I could deal with making one backend work at a time. -Klaus. PS I case you're wondering, the status of this effort is that I can get basic values into and out from the Postgres backend store, whereas I keep getting EAGAIN signals whenever I try to use the Berkeley backend. I haven't had time yet to look more into getting persistent classes work. The Berkeley backend required a significant number of changes, since the code generated by UFFI for Lispworks requires placeholder (dummy) arguments for :out parameters, where Allegro and SBCL/CMUCL seem to want none. From eslick at csail.mit.edu Sat Feb 18 18:29:12 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 18 Feb 2006 13:29:12 -0500 Subject: [elephant-devel] A thorny problem.... In-Reply-To: References: <1140189426.12408.597.camel@localhost.localdomain> Message-ID: <43F76778.4070901@csail.mit.edu> Klaus, We should talk offline. I'm in the middle of a large re-organization of the codebase and am trying to simplify alot of the backend functionality. Merging your changes into mine will be non-trivial. If most of your changes are limited to berkeley-db and sleepycat then it shouldn't be hard to make the changes there by hand. The metaclass protocol should get fixed by migrating to closer-to-mop in the near future which deals with most of the mopish problems that are patched in the current metaclasses.lisp file. Anyway, why don't you fill me in on what you're doing so we can coordinate and keep the pain under control. :) Ian Klaus Harbo wrote: > > On 17/02/2006, at 16:17, Robert L. Read wrote: > >> I think I've a identified a serious problem relating to the >> the dependencies on various modules that I offer up >> for you comment. >> >> I major goal of the multiple backend system is to allow >> you to not need to install the software related to the system >> you don't need. If you want to use BerkeleyDB, you shouldn't have >> to install CL-SQL. If you want to use CL-SQL and a relational database, >> you can't shouldn't have to install BerkeleyDB (which would subject >> you to their license, in any case.) > > I have spent some time looking at what it would take to make Elephant > work with Lispworks. It would a considerable advantage if I could > deal with making one backend work at a time. > > -Klaus. > > PS I case you're wondering, the status of this effort is that I can > get basic values into and out from the Postgres backend store, whereas > I keep getting EAGAIN signals whenever I try to use the Berkeley > backend. I haven't had time yet to look more into getting persistent > classes work. The Berkeley backend required a significant number of > changes, since the code generated by UFFI for Lispworks requires > placeholder (dummy) arguments for :out parameters, where Allegro and > SBCL/CMUCL seem to want > none._______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From read at robertlread.net Sat Feb 18 18:29:37 2006 From: read at robertlread.net (Robert L. Read) Date: Sat, 18 Feb 2006 12:29:37 -0600 Subject: [elephant-devel] A thorny problem.... In-Reply-To: References: <1140189426.12408.597.camel@localhost.localdomain> Message-ID: <1140287378.12408.632.camel@localhost.localdomain> Excellent! It would be wonderful if it would work with lispworks. It is certainly reasonable to create a "lispworks+CLSQL" only solution OR a "lispsworks+BDB" only solution; I would be happy to roll that into a release, and hope that in the future the full feature set would be supported. On Sat, 2006-02-18 at 18:33 +0100, Klaus Harbo wrote: > On 17/02/2006, at 16:17, Robert L. Read wrote: > > > I think I've a identified a serious problem relating to the > > the dependencies on various modules that I offer up > > for you comment. > > > > I major goal of the multiple backend system is to allow > > you to not need to install the software related to the system > > you don't need. If you want to use BerkeleyDB, you shouldn't have > > to install CL-SQL. If you want to use CL-SQL and a relational > > database, > > you can't shouldn't have to install BerkeleyDB (which would subject > > you to their license, in any case.) > > I have spent some time looking at what it would take to make Elephant > work with Lispworks. It would a considerable advantage if I could > deal with making one backend work at a time. > > -Klaus. > > PS I case you're wondering, the status of this effort is that I can > get basic values into and out from the Postgres backend store, > whereas I keep getting EAGAIN signals whenever I try to use the > Berkeley backend. I haven't had time yet to look more into getting > persistent classes work. The Berkeley backend required a significant > number of changes, since the code generated by UFFI for Lispworks > requires placeholder (dummy) arguments for :out parameters, where > Allegro and SBCL/CMUCL seem to want none. > _______________________________________________ > 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 Sat Feb 18 18:39:43 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 18 Feb 2006 13:39:43 -0500 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <1140287378.12408.632.camel@localhost.localdomain> References: <1140189426.12408.597.camel@localhost.localdomain> <1140287378.12408.632.camel@localhost.localdomain> Message-ID: <43F769EF.4050605@csail.mit.edu> With the separate backend system I'm implementing you can specify that only CLSQL backends can be loaded so you will be able to debug backends against lisps independently without much problem. Robert, I'm mostly done with the conversion although I got carried away on scope a bit. I'm testing it now and should be checking it in this afternoon. Ian Robert L. Read wrote: > Excellent! It would be wonderful if it would work with lispworks. > > It is certainly reasonable to create a "lispworks+CLSQL" only > solution OR a "lispsworks+BDB" only solution; I would be happy > to roll that into a release, and hope that in the future the full feature > set would be supported. > > > On Sat, 2006-02-18 at 18:33 +0100, Klaus Harbo wrote: >> On 17/02/2006, at 16:17, Robert L. Read wrote: >> >> > I think I've a identified a serious problem relating to the >> > the dependencies on various modules that I offer up >> > for you comment. >> > >> > I major goal of the multiple backend system is to allow >> > you to not need to install the software related to the system >> > you don't need. If you want to use BerkeleyDB, you shouldn't have >> > to install CL-SQL. If you want to use CL-SQL and a relational >> > database, >> > you can't shouldn't have to install BerkeleyDB (which would subject >> > you to their license, in any case.) >> >> I have spent some time looking at what it would take to make Elephant >> work with Lispworks. It would a considerable advantage if I could >> deal with making one backend work at a time. >> >> -Klaus. >> >> PS I case you're wondering, the status of this effort is that I can >> get basic values into and out from the Postgres backend store, >> whereas I keep getting EAGAIN signals whenever I try to use the >> Berkeley backend. I haven't had time yet to look more into getting >> persistent classes work. The Berkeley backend required a significant >> number of changes, since the code generated by UFFI for Lispworks >> requires placeholder (dummy) arguments for :out parameters, where >> Allegro and SBCL/CMUCL seem to want none. >> _______________________________________________ >> 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 read at robertlread.net Sat Feb 18 18:51:32 2006 From: read at robertlread.net (Robert L. Read) Date: Sat, 18 Feb 2006 12:51:32 -0600 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <43F769EF.4050605@csail.mit.edu> References: <1140189426.12408.597.camel@localhost.localdomain> <1140287378.12408.632.camel@localhost.localdomain> <43F769EF.4050605@csail.mit.edu> Message-ID: <1140288692.12408.635.camel@localhost.localdomain> Holy smokes! Good thing I had the good sense to stay out of the way... On Sat, 2006-02-18 at 13:39 -0500, Ian Eslick wrote: > With the separate backend system I'm implementing you can specify that > only CLSQL backends can be loaded so you will be able to debug backends > against lisps independently without much problem. > > Robert, I'm mostly done with the conversion although I got carried away > on scope a bit. I'm testing it now and should be checking it in this > afternoon. > > Ian > > Robert L. Read wrote: > > Excellent! It would be wonderful if it would work with lispworks. > > > > It is certainly reasonable to create a "lispworks+CLSQL" only > > solution OR a "lispsworks+BDB" only solution; I would be happy > > to roll that into a release, and hope that in the future the full feature > > set would be supported. > > > > > > On Sat, 2006-02-18 at 18:33 +0100, Klaus Harbo wrote: > >> On 17/02/2006, at 16:17, Robert L. Read wrote: > >> > >> > I think I've a identified a serious problem relating to the > >> > the dependencies on various modules that I offer up > >> > for you comment. > >> > > >> > I major goal of the multiple backend system is to allow > >> > you to not need to install the software related to the system > >> > you don't need. If you want to use BerkeleyDB, you shouldn't have > >> > to install CL-SQL. If you want to use CL-SQL and a relational > >> > database, > >> > you can't shouldn't have to install BerkeleyDB (which would subject > >> > you to their license, in any case.) > >> > >> I have spent some time looking at what it would take to make Elephant > >> work with Lispworks. It would a considerable advantage if I could > >> deal with making one backend work at a time. > >> > >> -Klaus. > >> > >> PS I case you're wondering, the status of this effort is that I can > >> get basic values into and out from the Postgres backend store, > >> whereas I keep getting EAGAIN signals whenever I try to use the > >> Berkeley backend. I haven't had time yet to look more into getting > >> persistent classes work. The Berkeley backend required a significant > >> number of changes, since the code generated by UFFI for Lispworks > >> requires placeholder (dummy) arguments for :out parameters, where > >> Allegro and SBCL/CMUCL seem to want none. > >> _______________________________________________ > >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus at harbo.net Sat Feb 18 19:01:26 2006 From: klaus at harbo.net (Klaus Harbo) Date: Sat, 18 Feb 2006 20:01:26 +0100 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <43F76778.4070901@csail.mit.edu> References: <1140189426.12408.597.camel@localhost.localdomain> <43F76778.4070901@csail.mit.edu> Message-ID: On 18/02/2006, at 19:29, Ian Eslick wrote: > Klaus, > > We should talk offline. I'm in the middle of a large re- > organization of > the codebase and am trying to simplify alot of the backend > functionality. Merging your changes into mine will be non-trivial. > > If most of your changes are limited to berkeley-db and sleepycat > then it > shouldn't be hard to make the changes there by hand. The metaclass > protocol should get fixed by migrating to closer-to-mop in the near > future which deals with most of the mopish problems that are > patched in > the current metaclasses.lisp file. > > Anyway, why don't you fill me in on what you're doing so we can > coordinate and keep the pain under control. :) > > Ian Well, I think the best way to characterize what I've been doing is to 'hack' Elephant to make it work with LW, i.e. I wouldn't consider what I've done 'changes to Elephant'. My main aim has been to understand the kinds of changes that would be required to make it work -- with that understanding I would then look at what would be the best way to fold it into Elephant. I'm encouraged that you're working on a reorganization; IMHO the code really needs it (I do not mean this as criticism -- considering the process Elephant has been through, lack organization is quite understandable). If it is okay to venture an opinion, I think the code would benefit from stratifying both in terms of backends (which I believe is already happening judging from recent postings to the list), and in terms of CL implementations. The latter could perhaps be approached like in Portable AllegroServe, where there's a clear interface to certain functionality, a separate files implement this interface for different implementations? As I mentioned, I don't have persistent classes working, and - frankly - my meta-programming skills are not very advanced; yet! Poring over the code, I wondered if using Pascal Costanza's Closer framework might help Elephant become highly portable across implementations? I know that, all things being equal, it is better to rely on fewer libraries rather than more, but I think there's considerable risk that we'll be reinventing the wheel... (I should perhaps add that I have not actually used Closer, but I have great respect for Pascal's abilities so I would expect it to be relatively usable.) -Klaus - The pencil is mightier than the pen - From eslick at csail.mit.edu Sat Feb 18 19:21:34 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 18 Feb 2006 14:21:34 -0500 Subject: [elephant-devel] A thorny problem.... In-Reply-To: References: <1140189426.12408.597.camel@localhost.localdomain> <43F76778.4070901@csail.mit.edu> Message-ID: <43F773BE.60900@csail.mit.edu> Klaus, Glad to hear I'm not messing things up for you too much. I share your respect for Pascal's skills also. Would you be willing to bite off taking the lead on a Closer to MOP port as part of fixing the MOP implementation for lispworks? I was thinking about doing it but won't be able to do it for awhile. It's a hairy project but I'd be happy to support you and if we could find a couple of other testers we could slowly migrate one function at a time and test it. Pascal is looking for other metaobject protocol implementations to test closer so I'm sure he'd be happy to help support. Pascal also works in Lispworks natively so might be motivated to make elephant work under lispworks. We shouldn't attempt this until after the current 0.6.0 is released however as there's already too much going on in this release. Hopefully 0.6.0 will come out next week or at least "very soon now". :) Cheers, Ian Klaus Harbo wrote: > > On 18/02/2006, at 19:29, Ian Eslick wrote: > >> Klaus, >> >> We should talk offline. I'm in the middle of a large re-organization of >> the codebase and am trying to simplify alot of the backend >> functionality. Merging your changes into mine will be non-trivial. >> >> If most of your changes are limited to berkeley-db and sleepycat then it >> shouldn't be hard to make the changes there by hand. The metaclass >> protocol should get fixed by migrating to closer-to-mop in the near >> future which deals with most of the mopish problems that are patched in >> the current metaclasses.lisp file. >> >> Anyway, why don't you fill me in on what you're doing so we can >> coordinate and keep the pain under control. :) >> >> Ian > > Well, I think the best way to characterize what I've been doing is to > 'hack' Elephant to make it work with LW, i.e. I wouldn't consider what > I've done 'changes to Elephant'. My main aim has been to understand > the kinds of changes that would be required to make it work -- with > that understanding I would then look at what would be the best way to > fold it into Elephant. > > I'm encouraged that you're working on a reorganization; IMHO the code > really needs it (I do not mean this as criticism -- considering the > process Elephant has been through, lack organization is quite > understandable). If it is okay to venture an opinion, I think the > code would benefit from stratifying both in terms of backends (which I > believe is already happening judging from recent postings to the > list), and in terms of CL implementations. The latter could perhaps > be approached like in Portable AllegroServe, where there's a clear > interface to certain functionality, a separate files implement this > interface for different implementations? > > As I mentioned, I don't have persistent classes working, and - frankly > - my meta-programming skills are not very advanced; yet! Poring over > the code, I wondered if using Pascal Costanza's Closer framework might > help Elephant become highly portable across implementations? I know > that, all things being equal, it is better to rely on fewer libraries > rather than more, but I think there's considerable risk that we'll be > reinventing the wheel... (I should perhaps add that I have not > actually used Closer, but I have great respect for Pascal's abilities > so I would expect it to be relatively usable.) > > -Klaus > > - The pencil is mightier than the pen - > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel From klaus at harbo.net Sat Feb 18 20:08:43 2006 From: klaus at harbo.net (Klaus Harbo) Date: Sat, 18 Feb 2006 21:08:43 +0100 Subject: [elephant-devel] A thorny problem.... In-Reply-To: <43F773BE.60900@csail.mit.edu> References: <1140189426.12408.597.camel@localhost.localdomain> <43F76778.4070901@csail.mit.edu> <43F773BE.60900@csail.mit.edu> Message-ID: <8B9723D1-8419-4411-A3AE-00C846FCC601@harbo.net> On 18/02/2006, at 20:21, Ian Eslick wrote: > Klaus, > > Glad to hear I'm not messing things up for you too much. I share your > respect for Pascal's skills also. > > Would you be willing to bite off taking the lead on a Closer to MOP > port > as part of fixing the MOP implementation for lispworks? I was > thinking > about doing it but won't be able to do it for awhile. It's a hairy > project but I'd be happy to support you and if we could find a > couple of > other testers we could slowly migrate one function at a time and test > it. Pascal is looking for other metaobject protocol > implementations to > test closer so I'm sure he'd be happy to help support. > > Pascal also works in Lispworks natively so might be motivated to make > elephant work under lispworks. > > We shouldn't attempt this until after the current 0.6.0 is released > however as there's already too much going on in this release. > Hopefully > 0.6.0 will come out next week or at least "very soon now". :) > > Cheers, > Ian It's an interesting project, so I'm interested... ;-) BUT, I don't think I'm in a very good position right now to port Elephant to Closer since I don't have a version of Elephant which works with my preferred CL implementation! I think the best I can do, short-term, is to focus on getting Elephant to work with Lispworks. A clear separation of the backends will help, since I think the path of least resistence to getting something to work with Lispworks is the Postgres backend, and in this respect the Berkeley-related problems is mostly noise. When/if my current efforts result in reasonably working LW port of Elephant, porting to Closer could be something I might venture to do. best regards, -Klaus. PS BTW: Does anyone know anything about the licensing implications of Oracle's recent acquisition of Sleepycat? - The pencil is mightier than the pen - From eslick at csail.mit.edu Sun Feb 19 04:59:36 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 18 Feb 2006 23:59:36 -0500 Subject: [elephant-devel] Elephant Reorganization in preparation for release 0.6.0 Message-ID: <43F7FB38.7030502@csail.mit.edu> I just checked in a rather sweeping reorganization of elephant to HEAD for 0.6.0. We tagged the HEAD version prior to this with ELEPHANT-0-6-0-beta-rc1 so anyone making modifications can continue to work on that until I can help you integrate your changes into the new HEAD. This change pulled a number of little features planned for 0.6.1 into 0.6.0. The completed changes are green for Sleepycat under SBCL and ACL 8.0 under Mac OS X. I'll check in fixes to make the CLSQL backend work shortly. I'll also fix the remaining outstanding items that are partially done and marked with '*' below. More info can be found in the main TODO file. I also added a src/README file as a guide to the new sources. While there is some loss of backward compatibility in these changes, the impact to existing source code should be minor and easy to catch. Interfaces changed include open-store, with-store-controller, from-root-existsp (just renamed to root-existp), migrate functions and any code which served as a backend. - Directory reorganization - Broke the source tree into backends, serialization utils and a main elephant directory - Build enhancements - A user only loads :elephant via asdf. When backends are created, they load the appropriate additional files via asdf and the generic functions for that backend automatically dispatch on the appropriate store-controller type. If the user wants to pre-load a backend they can do this via the asdf files in the top directory - Changed the way that backends are registered and managed * ASDF will call make on most platforms (no need for manual make) to build elephant libraries * Compiled C libraries are put into the proper directories * non-elephant library location definitions have been lifted to the top-level asdf files - Backend factoring - Extracted sql and bdb backends into separate directories & packages - Clarified the backend interface via generic functions in the main source files: controller, collections, transactions - Added a package :elephant-backend for backends to import to get access to internal elephant symbols and all the generic functions they need to override. This clarifies what symbols are shared between units and keeps any other packages from seeing them in the :elephant exports. - To implement a new backend all you need to do is implement the appropriate generic functions for store-controller, btree, indexed-btree, btree-index and btree-cursor and a few miscellaneous ones exported from elephant-backend. - Changed the inheritance heirarchy for btrees and factored out some slots so they were local to the different backend. There was some suspicious sharing going on earlier. - Backends are added by adding an additional backend table entry to the global var *elephant-backends* in variables.lisp which indicates the function to create a store, the asdf dependencies keyed by the db type - Check-con is now get-con and takes an instance of type persistent rather than requiring the accessor call at each use - Factored out slots from the base store-controller into the new backend packages - Serialization - I separated serialization from sleepycat into it's own package. The berkeley db depends on uffi and memory functionality in this sub-package, but binary serialization and the buffer-stream interface is now separated and can be loaded without loading berkeley-db - I also improved allegro's string handling, but this may cause problems on non Mac OSX platforms so please test this! - Transaction macro - Fixed the transaction macro to support different backend via generic functions and closures - No change to the user API however * Provided a generic way of creating a thread that binds local vars depending on what backends are loaded - New open-store interface - open-store takes an extended type spec. All specs are conses with the first cons being the type of backend you intend to open. The remainder is as usual. The sql backend ensures that the asdf files for the specific SQL backend are loaded. - with-store-controller is now deprecated for user use - For clarity, user API for making indices is make-XX instead of build-XX which is the backend generic function and requires a store controller argument, whereas make will default to *store-controller* - Improved migration interface * I rewrote the migration interface to use a generic function protocol to allow for user customization of the copy process from one repos to another. * Added support to copy one repository to another wholesale (a poor-man's stop-and-copy garbage collector!) Sorry for any hassle this causes the users, but I think this will payoff in flexibility, clarity and stability in the very near future. Ian From eslick at csail.mit.edu Sun Feb 19 16:46:31 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 19 Feb 2006 11:46:31 -0500 Subject: [elephant-devel] functions.lisp Message-ID: <43F8A0E7.7070202@csail.mit.edu> Is the uffi patch in functions.lisp still required in the release, or can we point people to the latest uffi distribution? Ian From eslick at csail.mit.edu Sun Feb 19 20:12:55 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 19 Feb 2006 15:12:55 -0500 Subject: [elephant-devel] SQL Backend (almost) ready for 0.6.0-beta Message-ID: <43F8D147.6050403@csail.mit.edu> Ok, check out the new instructions in INSTALL and give it a whirl on other platforms. The BDB backend is clean under SBCL and ACL on Mac OS X. The CLSQL backend still fails a few SQL indexing tests on both SBCL and ACL under Mac OS X One bug I'm tracking down is the first run of INDEXING-BASIC and the other is that a range indexing query using cursor-pset-range goes to target+1 and not the target value on integer slot values in INDEXING-RANGE. If someone (Robert?) can look into these that would be helpful! Feel free to fire questions to the list or to me directly if elements or assumptions behind the reorg are confusing. I touched quite a bit of code... Ian From eslick at csail.mit.edu Sun Feb 19 20:25:25 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 19 Feb 2006 15:25:25 -0500 Subject: [elephant-devel] Caveat: migration Message-ID: <43F8D435.4000504@csail.mit.edu> I should mention that migration is not yet repaired, so only run the (do-backend-tests ...) to validate a given backend. Ian From midfield at gmail.com Sun Feb 19 21:43:37 2006 From: midfield at gmail.com (Ben) Date: Sun, 19 Feb 2006 15:43:37 -0600 Subject: [elephant-devel] functions.lisp In-Reply-To: <43F8A0E7.7070202@csail.mit.edu> References: <43F8A0E7.7070202@csail.mit.edu> Message-ID: <9157df230602191343o3f5221d1l238ffbf210248f95@mail.gmail.com> i think not. i'm pretty sure they updated functions.lisp in uffi as of a year ago or so. B On 2/19/06, Ian Eslick wrote: > > Is the uffi patch in functions.lisp still required in the release, or > can we point people to the latest uffi distribution? > > Ian > _______________________________________________ > 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 19 23:19:49 2006 From: read at robertlread.net (Robert L. Read) Date: Sun, 19 Feb 2006 17:19:49 -0600 Subject: [elephant-devel] Re: SQL Backend (almost) ready for 0.6.0-beta In-Reply-To: <43F8D147.6050403@csail.mit.edu> References: <43F8D147.6050403@csail.mit.edu> Message-ID: <1140391189.12408.663.camel@localhost.localdomain> I intend to test this; unfortunately, I can't seem to reach common- lisp.net right now. On Sun, 2006-02-19 at 15:12 -0500, Ian Eslick wrote: > Ok, check out the new instructions in INSTALL and give it a whirl on > other platforms. > > The BDB backend is clean under SBCL and ACL on Mac OS X. > The CLSQL backend still fails a few SQL indexing tests on both SBCL and > ACL under Mac OS X > > One bug I'm tracking down is the first run of INDEXING-BASIC and the > other is that a range indexing query using cursor-pset-range goes to > target+1 and not the target value on integer slot values in INDEXING-RANGE. > > If someone (Robert?) can look into these that would be helpful! Feel > free to fire questions to the list or to me directly if elements or > assumptions behind the reorg are confusing. I touched quite a bit of > code... > > Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Wed Feb 22 18:31:20 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 22 Feb 2006 13:31:20 -0500 Subject: [elephant-devel] Odd interaction between elephant and SBCL PCL/MOP Message-ID: <43FCADF8.7020509@csail.mit.edu> After the reorg we're left with a couple of little annoyances. One of them deals with class redefinition interacting with indexing interacting with SBCL's PCL/MOP under BerkeleyDB. I want to see if anyone on the list is more familiar with SBCL than I and might have an idea of where this problem lies. It's also one of those unpleasant bugs that only show up in certain contexts. 1) Run indexing-reconnect-db standalone: passes fine 2) Run do-backend-tests: fails with one of two bugs: a) berkeley-db error (still tracking down exactly why there's an error) b) slot-boundp doesn't find slots that are clearly there and readable by slot-value I'm trying to isolate the problem but am short on time and SBCL familiarity. I am doing one funny thing in the tests to try to set proper initial conditions for the test and that is wiping the reference to the class via: (setf (find-class 'class-name) nil). I can provide some more insights if anyone is willing to lend a bit of a hand. We're very, very close to 0.6.0 now I think. Ian From eslick at csail.mit.edu Wed Feb 22 19:04:27 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 22 Feb 2006 14:04:27 -0500 Subject: [elephant-devel] Odd interaction between elephant and SBCL PCL/MOP In-Reply-To: <43FCADF8.7020509@csail.mit.edu> References: <43FCADF8.7020509@csail.mit.edu> Message-ID: <43FCB5BB.7080608@csail.mit.edu> The BDB write problem is resolved. An earlier test in the suite set *auto-commit* to nil which fails in BDB in any write not wrapped in a transaction. Slot writes are not automatically wrapped in transactions and thus depend on auto-commit; although (now) all btree operations are wrapped in an inner transaction. auto-commit = t is important for such unprotected write cases. The nice thing about that is you can wrap an outer transaction, deassert *auto-commit* and get pretty efficient slot writes (especially with :no-sync) under BDB if you so choose. I wonder if it's worth tracing all paths to BDB writes and putting in asserts to catch unprotected calls in 0.6.1. Maybe a trace macro that can be turned on for debugging and off for production to avoid performance hits. The slot-boundp problem still exists however. Ian Ian Eslick wrote: > After the reorg we're left with a couple of little annoyances. One of > them deals with class redefinition interacting with indexing interacting > with SBCL's PCL/MOP under BerkeleyDB. I want to see if anyone on the > list is more familiar with SBCL than I and might have an idea of where > this problem lies. It's also one of those unpleasant bugs that only > show up in certain contexts. > > 1) Run indexing-reconnect-db standalone: passes fine > 2) Run do-backend-tests: fails with one of two bugs: > a) berkeley-db error (still tracking down exactly why there's an error) > b) slot-boundp doesn't find slots that are clearly there and > readable by slot-value > > I'm trying to isolate the problem but am short on time and SBCL > familiarity. I am doing one funny thing in the tests to try to set > proper initial conditions for the test and that is wiping the reference > to the class via: (setf (find-class 'class-name) nil). > > I can provide some more insights if anyone is willing to lend a bit of a > hand. We're very, very close to 0.6.0 now I think. > > Ian > _______________________________________________ > elephant-devel site list > elephant-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > From read at robertlread.net Wed Feb 22 19:13:05 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 13:13:05 -0600 Subject: [elephant-devel] Odd interaction between elephant and SBCL PCL/MOP In-Reply-To: <43FCB5BB.7080608@csail.mit.edu> References: <43FCADF8.7020509@csail.mit.edu> <43FCB5BB.7080608@csail.mit.edu> Message-ID: <1140635585.4834.118.camel@localhost.localdomain> Almost certainly. On Wed, 2006-02-22 at 14:04 -0500, Ian Eslick wrote: > I wonder if it's worth tracing all paths to BDB writes and putting in > asserts to catch unprotected calls in 0.6.1. Maybe a trace macro that > can be turned on for debugging and off for production to avoid > performance hits. However, I think this could legitimately be documented in your nice "TODO" and deferred. ---- Robert L. Read, PhD read &T robertlread.net Consider visiting Progressive Engineering: http://robertlread.net/pe In Austin: 912-8593 "Think globally, Act locally." -- RBF -------------- next part -------------- An HTML attachment was scrubbed... URL: From blumberg at math.uchicago.edu Wed Feb 22 19:38:58 2006 From: blumberg at math.uchicago.edu (Andrew Blumberg) Date: Wed, 22 Feb 2006 13:38:58 -0600 (CST) Subject: [elephant-devel] Re: Odd interaction between elephant and SBCL PCL/MOP In-Reply-To: <43FCADF8.7020509@csail.mit.edu> References: <43FCADF8.7020509@csail.mit.edu> Message-ID: i'll investigate this. - andrew On Wed, 22 Feb 2006, Ian Eslick wrote: > b) slot-boundp doesn't find slots that are clearly there and > readable by slot-value From read at robertlread.net Wed Feb 22 20:26:51 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 14:26:51 -0600 Subject: [elephant-devel] Just checked in a change in how configuration is done... Message-ID: <1140640012.4834.125.camel@localhost.localdomain> Based on Ian's reorg, there is now a file called config.lisp that is used to configure library locations. (As of this moment, I am green in all but "INDEXING-REDEF-CLASS" on both BDB and SQL, have not tried the migration tests, and believe that there is a SQL bug that is not deleting classes correctly meaning that you can't successfully run the SQL-backend tests twice.) config.lisp looks like this: ;; CLSQL BACKEND ;; Make sure the libraries that CLSQL needs for a particular system ;; are pointed to by these libraries. ;; These values will be irrelevant if you don't use a CLSQL-based backend. (defparameter *clsql-foreign-lib-path* #p"/usr/local/share/common- lisp/elephant/") ;; BerkeleyDB ;; Make sure the libraries that CLSQL needs for a particular system ;; are pointed to by these libraries. (defparameter *sleepycat-foreign-library-path* ;; Sleepycat: this works on linux #+linux ;; "/db/ben/lisp/db43/lib/libdb.so" "/usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so" ;; this works on FreeBSD #+(and (or bsd freebsd) (not (or darwin macosx))) "/usr/local/lib/db43/libdb.so" #+(or darwin macosx) ;; for Fink (OS X) -- but I will assume Linux more common... ;; "/sw/lib/libdb-4.3.dylib" ;; a possible manual install "/usr/local/BerkeleyDB.4.3/lib/libdb.dylib") -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Wed Feb 22 22:28:52 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Wed, 22 Feb 2006 17:28:52 -0500 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class Message-ID: <43FCE5A4.8040603@csail.mit.edu> These do not appear to be properly implemented for persistent slots on any platform. This may be part of the problem that Andrew, Robert and I are looking at. It should be easy to add, but I don't understand why it's not failing. I also found a couple of small problems I introduced into the tests accidentally while exploring these bugs. I have fixed these in my latest checkin. If you're working on these bugs, please update: My full status as of this checkin is: Mac OS X 10.4 / ACL 8.0 / BDB - Backend: Green Migration: Green Mac OS X 10.4 / ACL 8.0 / SQL - Backend: Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value returning 0 instead of 1 instance) Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value returns 2 instead of 1 instance) Migration: Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value returning 2 instead of 1) Mac OS X 10.4 / SBCL 8.0 / BDB Backend: Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier e-mail) Migration: Green Mac OS X 10.4 / SBCL 8.0 / SQL Backend: Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier e-mail) Migration: Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value returning 2 instead of 1) I'm beginning to think that porting over to a MOP compatibility layer (like closer-to-mop) may be a better course than to continue to patch the current system if no one can find this with a little more effort. I don't have time for at least two weeks to look at this. I will be available to answer questions, but not for any significant debugging or development. Ian From read at robertlread.net Thu Feb 23 03:43:08 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 21:43:08 -0600 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <43FCE5A4.8040603@csail.mit.edu> References: <43FCE5A4.8040603@csail.mit.edu> Message-ID: <1140666188.4834.136.camel@localhost.localdomain> Thanks for this large and excellent body of work, Ian. I agree that we should use closer-to-mop. However, I am tempted to release 0.6.0 even in the presence of these bugs, as all of them concern the new functionality that you have added. I am pretty confident 0.6.0 represents no regression from previous releases, and certainly is better in other ways. On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: > These do not appear to be properly implemented for persistent slots on > any platform. This may be part of the problem that Andrew, Robert and I > are looking at. It should be easy to add, but I don't understand why > it's not failing. > > I also found a couple of small problems I introduced into the tests > accidentally while exploring these bugs. I have fixed these in my > latest checkin. If you're working on these bugs, please update: > > My full status as of this checkin is: > > Mac OS X 10.4 / ACL 8.0 / BDB - > Backend: Green > Migration: Green > Mac OS X 10.4 / ACL 8.0 / SQL - > Backend: > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > returning 0 instead of 1 instance) > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > returns 2 instead of 1 instance) > Migration: > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > returning 2 instead of 1) > Mac OS X 10.4 / SBCL 8.0 / BDB > Backend: > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > e-mail) > Migration: Green > Mac OS X 10.4 / SBCL 8.0 / SQL > Backend: > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > e-mail) > Migration: > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > returning 2 instead of 1) > > I'm beginning to think that porting over to a MOP compatibility layer > (like closer-to-mop) may be a better course than to continue to patch > the current system if no one can find this with a little more effort. I > don't have time for at least two weeks to look at this. I will be > available to answer questions, but not for any significant debugging or > development. > > Ian > _______________________________________________ > 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 read at robertlread.net Thu Feb 23 03:43:08 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 21:43:08 -0600 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <43FCE5A4.8040603@csail.mit.edu> References: <43FCE5A4.8040603@csail.mit.edu> Message-ID: <1140666188.4834.136.camel@localhost.localdomain> Thanks for this large and excellent body of work, Ian. I agree that we should use closer-to-mop. However, I am tempted to release 0.6.0 even in the presence of these bugs, as all of them concern the new functionality that you have added. I am pretty confident 0.6.0 represents no regression from previous releases, and certainly is better in other ways. On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: > These do not appear to be properly implemented for persistent slots on > any platform. This may be part of the problem that Andrew, Robert and I > are looking at. It should be easy to add, but I don't understand why > it's not failing. > > I also found a couple of small problems I introduced into the tests > accidentally while exploring these bugs. I have fixed these in my > latest checkin. If you're working on these bugs, please update: > > My full status as of this checkin is: > > Mac OS X 10.4 / ACL 8.0 / BDB - > Backend: Green > Migration: Green > Mac OS X 10.4 / ACL 8.0 / SQL - > Backend: > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > returning 0 instead of 1 instance) > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > returns 2 instead of 1 instance) > Migration: > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > returning 2 instead of 1) > Mac OS X 10.4 / SBCL 8.0 / BDB > Backend: > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > e-mail) > Migration: Green > Mac OS X 10.4 / SBCL 8.0 / SQL > Backend: > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > e-mail) > Migration: > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > returning 2 instead of 1) > > I'm beginning to think that porting over to a MOP compatibility layer > (like closer-to-mop) may be a better course than to continue to patch > the current system if no one can find this with a little more effort. I > don't have time for at least two weeks to look at this. I will be > available to answer questions, but not for any significant debugging or > development. > > Ian > _______________________________________________ > 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 waldo at trianet.net Thu Feb 23 04:01:24 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Wed, 22 Feb 2006 23:01:24 -0500 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <1140666188.4834.136.camel@localhost.localdomain> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> Message-ID: <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> How about releasing 0.6.0.rc1 instead? It just doesn't fly well with me the fact that a new release is coming out with known bugs. I understand your point. The question is, like Ian asked, is it worth fixing this bug or re-engineering to closer-to-mop. - Waldo On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: > Thanks for this large and excellent body of work, Ian. > > I agree that we should use closer-to-mop. > > However, I am tempted to release 0.6.0 even in the presence of > these bugs, > as all of them concern the new functionality that you have added. > I am pretty > confident 0.6.0 represents no regression from previous releases, > and certainly > is better in other ways. > > On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: >> These do not appear to be properly implemented for persistent >> slots on >> any platform. This may be part of the problem that Andrew, Robert >> and I >> are looking at. It should be easy to add, but I don't understand why >> it's not failing. >> >> I also found a couple of small problems I introduced into the tests >> accidentally while exploring these bugs. I have fixed these in my >> latest checkin. If you're working on these bugs, please update: >> >> My full status as of this checkin is: >> >> Mac OS X 10.4 / ACL 8.0 / BDB - >> Backend: Green >> Migration: Green >> Mac OS X 10.4 / ACL 8.0 / SQL - >> Backend: >> Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value >> returning 0 instead of 1 instance) >> Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value >> returns 2 instead of 1 instance) >> Migration: >> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >> returning 2 instead of 1) >> Mac OS X 10.4 / SBCL 8.0 / BDB >> Backend: >> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in >> earlier >> e-mail) >> Migration: Green >> Mac OS X 10.4 / SBCL 8.0 / SQL >> Backend: >> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in >> earlier >> e-mail) >> Migration: >> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >> returning 2 instead of 1) >> >> I'm beginning to think that porting over to a MOP compatibility layer >> (like closer-to-mop) may be a better course than to continue to patch >> the current system if no one can find this with a little more >> effort. I >> don't have time for at least two weeks to look at this. I will be >> available to answer questions, but not for any significant >> debugging or >> development. >> >> Ian >> _______________________________________________ >> 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 read at robertlread.net Thu Feb 23 04:09:27 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 22:09:27 -0600 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> Message-ID: <1140667768.4834.141.camel@localhost.localdomain> Well, Ian and I are both exhausted (metaphorically.) It is a rare project that does not release with known bugs. But 0.6.0.rc1 can serve as well as 0.6.0 for most people, so I don't mind using that name --- but I will make a tar file of it, for the convenience of a hypothetic new user. If they choose not to use class-indexing, they will not experience the known bugs; it is the unknown once that will be the problem. But we do have a solid test suite, relatively speaking. On Wed, 2006-02-22 at 23:01 -0500, Waldo Rubinstein wrote: > How about releasing 0.6.0.rc1 instead? It just doesn't fly well with > me the fact that a new release is coming out with known bugs. I > understand your point. The question is, like Ian asked, is it worth > fixing this bug or re-engineering to closer-to-mop. > > > - Waldo > > On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: > > > > Thanks for this large and excellent body of work, Ian. > > > > I agree that we should use closer-to-mop. > > > > However, I am tempted to release 0.6.0 even in the presence of these > > bugs, > > as all of them concern the new functionality that you have added. I > > am pretty > > confident 0.6.0 represents no regression from previous releases, and > > certainly > > is better in other ways. > > > > On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: > > > > > These do not appear to be properly implemented for persistent slots on > > > any platform. This may be part of the problem that Andrew, Robert and I > > > are looking at. It should be easy to add, but I don't understand why > > > it's not failing. > > > > > > I also found a couple of small problems I introduced into the tests > > > accidentally while exploring these bugs. I have fixed these in my > > > latest checkin. If you're working on these bugs, please update: > > > > > > My full status as of this checkin is: > > > > > > Mac OS X 10.4 / ACL 8.0 / BDB - > > > Backend: Green > > > Migration: Green > > > Mac OS X 10.4 / ACL 8.0 / SQL - > > > Backend: > > > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > > > returning 0 instead of 1 instance) > > > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > > > returns 2 instead of 1 instance) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > Mac OS X 10.4 / SBCL 8.0 / BDB > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: Green > > > Mac OS X 10.4 / SBCL 8.0 / SQL > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > > > > I'm beginning to think that porting over to a MOP compatibility layer > > > (like closer-to-mop) may be a better course than to continue to patch > > > the current system if no one can find this with a little more effort. I > > > don't have time for at least two weeks to look at this. I will be > > > available to answer questions, but not for any significant debugging or > > > development. > > > > > > Ian > > > _______________________________________________ > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Thu Feb 23 04:09:27 2006 From: read at robertlread.net (Robert L. Read) Date: Wed, 22 Feb 2006 22:09:27 -0600 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> Message-ID: <1140667768.4834.141.camel@localhost.localdomain> Well, Ian and I are both exhausted (metaphorically.) It is a rare project that does not release with known bugs. But 0.6.0.rc1 can serve as well as 0.6.0 for most people, so I don't mind using that name --- but I will make a tar file of it, for the convenience of a hypothetic new user. If they choose not to use class-indexing, they will not experience the known bugs; it is the unknown once that will be the problem. But we do have a solid test suite, relatively speaking. On Wed, 2006-02-22 at 23:01 -0500, Waldo Rubinstein wrote: > How about releasing 0.6.0.rc1 instead? It just doesn't fly well with > me the fact that a new release is coming out with known bugs. I > understand your point. The question is, like Ian asked, is it worth > fixing this bug or re-engineering to closer-to-mop. > > > - Waldo > > On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: > > > > Thanks for this large and excellent body of work, Ian. > > > > I agree that we should use closer-to-mop. > > > > However, I am tempted to release 0.6.0 even in the presence of these > > bugs, > > as all of them concern the new functionality that you have added. I > > am pretty > > confident 0.6.0 represents no regression from previous releases, and > > certainly > > is better in other ways. > > > > On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: > > > > > These do not appear to be properly implemented for persistent slots on > > > any platform. This may be part of the problem that Andrew, Robert and I > > > are looking at. It should be easy to add, but I don't understand why > > > it's not failing. > > > > > > I also found a couple of small problems I introduced into the tests > > > accidentally while exploring these bugs. I have fixed these in my > > > latest checkin. If you're working on these bugs, please update: > > > > > > My full status as of this checkin is: > > > > > > Mac OS X 10.4 / ACL 8.0 / BDB - > > > Backend: Green > > > Migration: Green > > > Mac OS X 10.4 / ACL 8.0 / SQL - > > > Backend: > > > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > > > returning 0 instead of 1 instance) > > > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > > > returns 2 instead of 1 instance) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > Mac OS X 10.4 / SBCL 8.0 / BDB > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: Green > > > Mac OS X 10.4 / SBCL 8.0 / SQL > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > > > > I'm beginning to think that porting over to a MOP compatibility layer > > > (like closer-to-mop) may be a better course than to continue to patch > > > the current system if no one can find this with a little more effort. I > > > don't have time for at least two weeks to look at this. I will be > > > available to answer questions, but not for any significant debugging or > > > development. > > > > > > Ian > > > _______________________________________________ > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eslick at csail.mit.edu Thu Feb 23 06:02:54 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 23 Feb 2006 01:02:54 -0500 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <1140667768.4834.141.camel@localhost.localdomain> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> <1140667768.4834.141.camel@localhost.localdomain> Message-ID: <43FD500E.2000904@csail.mit.edu> I agree with Waldo. Since 0.6.0 is a significant re-organization as well as a new feature release with known problems, then logically it is more of a release candidate and that designation will set people's expectation. (For example, I'm sure there are also problems with MCL also as it hasn't been tested on that platform yet.) I vote to release 0.6.0 when we get the test suite to pass and the new docs and tutorial completed. In the meantime I think it's perfectly fine to make rc1 available as part of an extended release process. Anyone who really wants to use the new features can pitch in some time to find the remaining bug or two (Andrew has volunteered to take a look at the MOP bug in the next day or two) and I'm sure one of us will get around to it in the coming weeks. Cheers, Ian Robert L. Read wrote: > Well, Ian and I are both exhausted (metaphorically.) > > It is a rare project that does not release with known bugs. > > But 0.6.0.rc1 can serve as well as 0.6.0 for most people, so > I don't mind using that name --- but I will make a tar file of it, > for the convenience of a hypothetic new user. If they choose > not to use class-indexing, they will not experience the known > bugs; it is the unknown once that will be the problem. > > But we do have a solid test suite, relatively speaking. > > On Wed, 2006-02-22 at 23:01 -0500, Waldo Rubinstein wrote: >> How about releasing 0.6.0.rc1 instead? It just doesn't fly well with >> me the fact that a new release is coming out with known bugs. I >> understand your point. The question is, like Ian asked, is it worth >> fixing this bug or re-engineering to closer-to-mop. >> >> >> - Waldo >> >> On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: >> >>> Thanks for this large and excellent body of work, Ian. >>> >>> I agree that we should use closer-to-mop. >>> >>> However, I am tempted to release 0.6.0 even in the presence of these >>> bugs, >>> as all of them concern the new functionality that you have added. I >>> am pretty >>> confident 0.6.0 represents no regression from previous releases, and >>> certainly >>> is better in other ways. >>> >>> On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: >>>> These do not appear to be properly implemented for persistent slots on >>>> any platform. This may be part of the problem that Andrew, Robert and I >>>> are looking at. It should be easy to add, but I don't understand why >>>> it's not failing. >>>> >>>> I also found a couple of small problems I introduced into the tests >>>> accidentally while exploring these bugs. I have fixed these in my >>>> latest checkin. If you're working on these bugs, please update: >>>> >>>> My full status as of this checkin is: >>>> >>>> Mac OS X 10.4 / ACL 8.0 / BDB - >>>> Backend: Green >>>> Migration: Green >>>> Mac OS X 10.4 / ACL 8.0 / SQL - >>>> Backend: >>>> Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value >>>> returning 0 instead of 1 instance) >>>> Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value >>>> returns 2 instead of 1 instance) >>>> Migration: >>>> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >>>> returning 2 instead of 1) >>>> Mac OS X 10.4 / SBCL 8.0 / BDB >>>> Backend: >>>> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier >>>> e-mail) >>>> Migration: Green >>>> Mac OS X 10.4 / SBCL 8.0 / SQL >>>> Backend: >>>> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier >>>> e-mail) >>>> Migration: >>>> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >>>> returning 2 instead of 1) >>>> >>>> I'm beginning to think that porting over to a MOP compatibility layer >>>> (like closer-to-mop) may be a better course than to continue to patch >>>> the current system if no one can find this with a little more effort. I >>>> don't have time for at least two weeks to look at this. I will be >>>> available to answer questions, but not for any significant debugging or >>>> development. >>>> >>>> Ian >>>> _______________________________________________ >>>> 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 eslick at csail.mit.edu Thu Feb 23 06:02:54 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 23 Feb 2006 01:02:54 -0500 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <1140667768.4834.141.camel@localhost.localdomain> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> <1140667768.4834.141.camel@localhost.localdomain> Message-ID: <43FD500E.2000904@csail.mit.edu> I agree with Waldo. Since 0.6.0 is a significant re-organization as well as a new feature release with known problems, then logically it is more of a release candidate and that designation will set people's expectation. (For example, I'm sure there are also problems with MCL also as it hasn't been tested on that platform yet.) I vote to release 0.6.0 when we get the test suite to pass and the new docs and tutorial completed. In the meantime I think it's perfectly fine to make rc1 available as part of an extended release process. Anyone who really wants to use the new features can pitch in some time to find the remaining bug or two (Andrew has volunteered to take a look at the MOP bug in the next day or two) and I'm sure one of us will get around to it in the coming weeks. Cheers, Ian Robert L. Read wrote: > Well, Ian and I are both exhausted (metaphorically.) > > It is a rare project that does not release with known bugs. > > But 0.6.0.rc1 can serve as well as 0.6.0 for most people, so > I don't mind using that name --- but I will make a tar file of it, > for the convenience of a hypothetic new user. If they choose > not to use class-indexing, they will not experience the known > bugs; it is the unknown once that will be the problem. > > But we do have a solid test suite, relatively speaking. > > On Wed, 2006-02-22 at 23:01 -0500, Waldo Rubinstein wrote: >> How about releasing 0.6.0.rc1 instead? It just doesn't fly well with >> me the fact that a new release is coming out with known bugs. I >> understand your point. The question is, like Ian asked, is it worth >> fixing this bug or re-engineering to closer-to-mop. >> >> >> - Waldo >> >> On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: >> >>> Thanks for this large and excellent body of work, Ian. >>> >>> I agree that we should use closer-to-mop. >>> >>> However, I am tempted to release 0.6.0 even in the presence of these >>> bugs, >>> as all of them concern the new functionality that you have added. I >>> am pretty >>> confident 0.6.0 represents no regression from previous releases, and >>> certainly >>> is better in other ways. >>> >>> On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: >>>> These do not appear to be properly implemented for persistent slots on >>>> any platform. This may be part of the problem that Andrew, Robert and I >>>> are looking at. It should be easy to add, but I don't understand why >>>> it's not failing. >>>> >>>> I also found a couple of small problems I introduced into the tests >>>> accidentally while exploring these bugs. I have fixed these in my >>>> latest checkin. If you're working on these bugs, please update: >>>> >>>> My full status as of this checkin is: >>>> >>>> Mac OS X 10.4 / ACL 8.0 / BDB - >>>> Backend: Green >>>> Migration: Green >>>> Mac OS X 10.4 / ACL 8.0 / SQL - >>>> Backend: >>>> Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value >>>> returning 0 instead of 1 instance) >>>> Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value >>>> returns 2 instead of 1 instance) >>>> Migration: >>>> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >>>> returning 2 instead of 1) >>>> Mac OS X 10.4 / SBCL 8.0 / BDB >>>> Backend: >>>> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier >>>> e-mail) >>>> Migration: Green >>>> Mac OS X 10.4 / SBCL 8.0 / SQL >>>> Backend: >>>> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier >>>> e-mail) >>>> Migration: >>>> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >>>> returning 2 instead of 1) >>>> >>>> I'm beginning to think that porting over to a MOP compatibility layer >>>> (like closer-to-mop) may be a better course than to continue to patch >>>> the current system if no one can find this with a little more effort. I >>>> don't have time for at least two weeks to look at this. I will be >>>> available to answer questions, but not for any significant debugging or >>>> development. >>>> >>>> Ian >>>> _______________________________________________ >>>> 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 waldo at trianet.net Thu Feb 23 04:01:24 2006 From: waldo at trianet.net (Waldo Rubinstein) Date: Wed, 22 Feb 2006 23:01:24 -0500 Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <1140666188.4834.136.camel@localhost.localdomain> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> Message-ID: <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> How about releasing 0.6.0.rc1 instead? It just doesn't fly well with me the fact that a new release is coming out with known bugs. I understand your point. The question is, like Ian asked, is it worth fixing this bug or re-engineering to closer-to-mop. - Waldo On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: > Thanks for this large and excellent body of work, Ian. > > I agree that we should use closer-to-mop. > > However, I am tempted to release 0.6.0 even in the presence of > these bugs, > as all of them concern the new functionality that you have added. > I am pretty > confident 0.6.0 represents no regression from previous releases, > and certainly > is better in other ways. > > On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: >> These do not appear to be properly implemented for persistent >> slots on >> any platform. This may be part of the problem that Andrew, Robert >> and I >> are looking at. It should be easy to add, but I don't understand why >> it's not failing. >> >> I also found a couple of small problems I introduced into the tests >> accidentally while exploring these bugs. I have fixed these in my >> latest checkin. If you're working on these bugs, please update: >> >> My full status as of this checkin is: >> >> Mac OS X 10.4 / ACL 8.0 / BDB - >> Backend: Green >> Migration: Green >> Mac OS X 10.4 / ACL 8.0 / SQL - >> Backend: >> Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value >> returning 0 instead of 1 instance) >> Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value >> returns 2 instead of 1 instance) >> Migration: >> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >> returning 2 instead of 1) >> Mac OS X 10.4 / SBCL 8.0 / BDB >> Backend: >> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in >> earlier >> e-mail) >> Migration: Green >> Mac OS X 10.4 / SBCL 8.0 / SQL >> Backend: >> Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in >> earlier >> e-mail) >> Migration: >> Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value >> returning 2 instead of 1) >> >> I'm beginning to think that porting over to a MOP compatibility layer >> (like closer-to-mop) may be a better course than to continue to patch >> the current system if no one can find this with a little more >> effort. I >> don't have time for at least two weeks to look at this. I will be >> available to answer questions, but not for any significant >> debugging or >> development. >> >> Ian >> _______________________________________________ >> 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 read at robertlread.net Thu Feb 23 14:57:29 2006 From: read at robertlread.net (Robert L. Read) Date: Thu, 23 Feb 2006 08:57:29 -0600 Subject: [elephant-devel] ELEPHANT-0-6-0-rc1 is tagged. In-Reply-To: <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> References: <43FCE5A4.8040603@csail.mit.edu> <1140666188.4834.136.camel@localhost.localdomain> <51C6091E-4BC6-463F-BCC2-15EE0A2DCD44@trianet.net> Message-ID: <1140706650.4834.144.camel@localhost.localdomain> It looks like it might be a few more weeks before 0.6.0 is completely ready to be released. ELEPHANT-0-6-0-rc1 is tagged. On Wed, 2006-02-22 at 23:01 -0500, Waldo Rubinstein wrote: > How about releasing 0.6.0.rc1 instead? It just doesn't fly well with > me the fact that a new release is coming out with known bugs. I > understand your point. The question is, like Ian asked, is it worth > fixing this bug or re-engineering to closer-to-mop. > > > - Waldo > > On Feb 22, 2006, at 10:43 PM, Robert L. Read wrote: > > > > Thanks for this large and excellent body of work, Ian. > > > > I agree that we should use closer-to-mop. > > > > However, I am tempted to release 0.6.0 even in the presence of these > > bugs, > > as all of them concern the new functionality that you have added. I > > am pretty > > confident 0.6.0 represents no regression from previous releases, and > > certainly > > is better in other ways. > > > > On Wed, 2006-02-22 at 17:28 -0500, Ian Eslick wrote: > > > > > These do not appear to be properly implemented for persistent slots on > > > any platform. This may be part of the problem that Andrew, Robert and I > > > are looking at. It should be easy to add, but I don't understand why > > > it's not failing. > > > > > > I also found a couple of small problems I introduced into the tests > > > accidentally while exploring these bugs. I have fixed these in my > > > latest checkin. If you're working on these bugs, please update: > > > > > > My full status as of this checkin is: > > > > > > Mac OS X 10.4 / ACL 8.0 / BDB - > > > Backend: Green > > > Migration: Green > > > Mac OS X 10.4 / ACL 8.0 / SQL - > > > Backend: > > > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > > > returning 0 instead of 1 instance) > > > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > > > returns 2 instead of 1 instance) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > Mac OS X 10.4 / SBCL 8.0 / BDB > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: Green > > > Mac OS X 10.4 / SBCL 8.0 / SQL > > > Backend: > > > Fails: INDEXING-REDEF-CLASS (slot not found bug discussed in earlier > > > e-mail) > > > Migration: > > > Fails: MIGRATE-IPCLASS (fails due to get-instances-by-value > > > returning 2 instead of 1) > > > > > > I'm beginning to think that porting over to a MOP compatibility layer > > > (like closer-to-mop) may be a better course than to continue to patch > > > the current system if no one can find this with a little more effort. I > > > don't have time for at least two weeks to look at this. I will be > > > available to answer questions, but not for any significant debugging or > > > development. > > > > > > Ian > > > _______________________________________________ > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blumberg at math.uchicago.edu Thu Feb 23 12:36:52 2006 From: blumberg at math.uchicago.edu (Andrew Blumberg) Date: Thu, 23 Feb 2006 06:36:52 -0600 (CST) Subject: [elephant-devel] slot-exists-p / slot-exists-p-using-class In-Reply-To: <43FCE5A4.8040603@csail.mit.edu> References: <43FCE5A4.8040603@csail.mit.edu> Message-ID: what's your hypothesis about these failures? (i guess i'm really asking if this is another mop issue i should investigate. . .) - andrew On Wed, 22 Feb 2006, Ian Eslick wrote: > Fails: INDEXING-CHANGE-CLASS (fails due to get-instances-by-value > returning 0 instead of 1 instance) > Fails: INDEXING-REDEF-CLASS (fails due to get-instances-by-value > returns 2 instead of 1 instance) From eslick at csail.mit.edu Thu Feb 23 18:56:34 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Thu, 23 Feb 2006 13:56:34 -0500 Subject: [elephant-devel] Uses of elephant Message-ID: <43FE0562.4040407@csail.mit.edu> I thought with all the excitement regarding bugs, changes and such related to the delayed 0.6.0 release, I thought I'd pass along an application report built on top of 0.6.0-rc1. My development on elephant has been targeted to support a web-mining research project in which I am analyzing the presence on the web of a particular type of data. To do this I load 700k persistent objects into memory that represent my dataset of queries. Each query has an inverse-indexed timestamp slot and inverse indexed query-string slot and some stats variables. I then go out and scrape various search engines for references to the strings. Overnight the system performed 20k web searches, loaded in 70k+ urls including inverse indexing all the urls and timestamps. This all went off without a hitch. BDB/Allegro and indexing have been very stable over the past few days and I can now do those wonderful instance range queries in well under a second (all pages looked up between 7 and 8am this morning; join those pages the query db and get all queries processed this morning between 7am and 8am, etc) to analyze my initial dataset. As a separate part of the project, I've also implemented a simple full-text inverse index on top of the btree abstraction and have done some stress testing of 100 pages of an average of 10kB size at a throughput of 5pps. I think I can get that up a bit, but for now it's mostly btree seek limited as I'm using a btree as my sequence store. Sorted btree inserts aren't the cheapest thing in the world and inverse indexing is pretty random access. A cheap set operator (like AllegroCache) might make such collection building go faster. Queries on the full text database are limited to simply optimized phrases w/ wildcards and the NEAR operator between two phrases. With just a little more work & thinking about performance nested OR/AND/NEAR queries should be possible. Later this week I hope to scrape the URL collection and inverse index all the resulting pages which will be a true stress test of the whole system (hundreds of thousands of full-text indexed web pages, etc). If someone is really interested in the full-text indexing I think it only depends on my natural language toolkit and document representation model which I've released separately. It might make a nice project to (over time;) add it in as a contrib or module on top of elephant and speed it up a bit at the same time. Regards, Ian From eslick at csail.mit.edu Sat Feb 25 17:04:39 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 25 Feb 2006 12:04:39 -0500 Subject: [elephant-devel] MOP fix & SBCL indexing status Message-ID: <44008E27.7040400@csail.mit.edu> Andrew Blumberg sent me a simple one-line fix for our MOP bug under SBCL. SBCL + BDB is now green under OS X and this should fix it under linux also. Thanks Andrew! I'll check this in as soon as common-lisp.net lets me. I've identified, I believe, the source of the SQL indexing bugs but have to think carefully about a fix. It's a bug in index maintenance turned up by slight differences in the semantics of the BDB and SQL backends (maintaining secondary indices). I'll get to this over the weekend or early next week sometime. Ian From read at robertlread.net Sat Feb 25 20:13:30 2006 From: read at robertlread.net (Robert L. Read) Date: Sat, 25 Feb 2006 14:13:30 -0600 Subject: [elephant-devel] MOP fix & SBCL indexing status In-Reply-To: <44008E27.7040400@csail.mit.edu> References: <44008E27.7040400@csail.mit.edu> Message-ID: <1140898411.4834.193.camel@localhost.localdomain> Great work, gentlemen! On Sat, 2006-02-25 at 12:04 -0500, Ian Eslick wrote: > Andrew Blumberg sent me a simple one-line fix for our MOP bug under > SBCL. SBCL + BDB is now green under OS X and this should fix it under > linux also. Thanks Andrew! I'll check this in as soon as > common-lisp.net lets me. > > I've identified, I believe, the source of the SQL indexing bugs but have > to think carefully about a fix. It's a bug in index maintenance turned > up by slight differences in the semantics of the BDB and SQL backends > (maintaining secondary indices). I'll get to this over the weekend or > early next week sometime. > > Ian > _______________________________________________ > 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 read at robertlread.net Sat Feb 25 20:13:30 2006 From: read at robertlread.net (Robert L. Read) Date: Sat, 25 Feb 2006 14:13:30 -0600 Subject: [elephant-devel] MOP fix & SBCL indexing status In-Reply-To: <44008E27.7040400@csail.mit.edu> References: <44008E27.7040400@csail.mit.edu> Message-ID: <1140898411.4834.193.camel@localhost.localdomain> Great work, gentlemen! On Sat, 2006-02-25 at 12:04 -0500, Ian Eslick wrote: > Andrew Blumberg sent me a simple one-line fix for our MOP bug under > SBCL. SBCL + BDB is now green under OS X and this should fix it under > linux also. Thanks Andrew! I'll check this in as soon as > common-lisp.net lets me. > > I've identified, I believe, the source of the SQL indexing bugs but have > to think carefully about a fix. It's a bug in index maintenance turned > up by slight differences in the semantics of the BDB and SQL backends > (maintaining secondary indices). I'll get to this over the weekend or > early next week sometime. > > Ian > _______________________________________________ > 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 Sat Feb 25 20:55:37 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sat, 25 Feb 2006 15:55:37 -0500 Subject: [elephant-devel] SQL vs BDB Message-ID: <4400C449.9090601@csail.mit.edu> The SQL backend was allowing duplicate key-value rows to be written on secondary indices. This behavior deviates from BDB which only allows unique k-v pairs (bdb ignores duplicate k+v writes on btrees) but allows duplicate keys with different values: write k1 v1 => ((k1 . v1)) write k1 v2 => ((k1 . v1) (k1 . v2)) write k2 v1 => ((k1 . v1) (k1 . v2) (k2 . v1)) write k1 v2 => ((k1 . v1) (k1 . v2) (k2 . v1)) ;; write should ignore duplicate k1 . v2 entry I added a key-value-existsp operator to sql and use it to ensure that duplicate secondary rows are not written in (setf get-value) for sql-indexed-btree or in (add-index). I've added another test to enforce the semantics that if you unindex a slot such that the class no longer needs to be indexed, then the class is dropped from the database. Later, if you re-enable indexing old instances are not indexed. Accordingly I modified the redefine-class and change-class protocols to properly handle this kind of index accounting. NOTE: If you redefine a class so that no slots are indexed, the class indexing will be dropped also and any instances not reachable from the root are lost forever! We will provide a class option that allows you to specify indexing class instances without indexing any slots in 0.6.1. On Mac OS X, Allegro 8.0 and SBCL 0.9.7 all tests, including migration, are 100% Green. Please test on other platforms! Ian From eslick at csail.mit.edu Sun Feb 26 19:23:46 2006 From: eslick at csail.mit.edu (Ian Eslick) Date: Sun, 26 Feb 2006 14:23:46 -0500 Subject: [elephant-devel] Elephant & Berkeley DB questions In-Reply-To: <9157df230602081043m5264c586taf698fa1abac4985@mail.gmail.com> References: <43EA3750.5010706@csail.mit.edu> <9157df230602081043m5264c586taf698fa1abac4985@mail.gmail.com> Message-ID: <44020042.1030301@csail.mit.edu> I thought I'd share these questions with the list. A quick design question for Ben Lee: In your notes on upgrades/fixes you mention a separate OID table. I'm finding that when I inverse index into a bunch of persistent objects the serialization of the type is taking up significant duplicated area in my DB. I presume that storing an OID->TYPE field separately from the OID will make the storage of persistent objects more efficient while adding an additional disk seek for each first retrieval of the object from a btree key or value field. You argued that this would improve change-class. Right now change-class works fine when the system stays online, but if you exit and restart and there are unchanged class instances serialized in the DB, I assume they will be orphaned and not conform to the new type as lisp has lost the class-change dependency information? Since I'm thinking of making the OID table change for 0.6.1 I wanted to plumb your thoughts on how this effects the change & redefine class protocols. Several performance / stability questions: 1) I'm seeing HUGE growth in the database when I build inverse indices (a 64MB text file, tokenized into words and inverse indexed in 10-15 word chunks is over 2G on disk! Since most of this storage is archival except upon retrieval which tends to be to small subsets, I'm not overly worried at present but when I start indexing complete documents it's going to become a problem. Any thoughts/suggestions out there? Perhaps it's a page granularity issue? 2) I occasionally find, even in user code, that if I'm not careful with my transactions and cursors I lock my lisp up in the Berkeley locking code and have to kill the process. Berkeley DB claims to have a deadlock detection process that will yield a deadlock error when a DB routine attempts to lock a page, but I've never made it work with elephant and I'd be happy to implement transaction retries and deal with locking errors but I can't seem to get the DB code to do this. Anyone else have luck? While I can mostly code around this now by being extra careful, it's annoying to have what feels like such a fragile system. In 0.6.1 I hope to add checks so that a non-transactional cursor operation complains on the lisp side instead of relying on the DB library to behave properly so I don't have to keep fighting this but I'll wait for 0.6.0 to stabilize and ship first. Thanks! Ian