From read at robertlread.net Sat Oct 1 02:09:03 2005 From: read at robertlread.net (Robert L. Read) Date: Fri, 30 Sep 2005 21:09:03 -0500 Subject: [elephant-devel] Creating documentation.... Message-ID: <1128132543.7997.66.camel@localhost.localdomain> The html directory in the elepahnt-0.2.1/doc directory is the SOURCE for the documentation, correct, and not the output of some other tool? I add to the documentation by writing HTML into that directory, correct? ---- 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 mega at hotpop.com Wed Oct 5 17:12:21 2005 From: mega at hotpop.com (=?utf-8?q?G=C3=A1bor_Melis?=) Date: Wed, 5 Oct 2005 19:12:21 +0200 Subject: [elephant-devel] Creating documentation.... In-Reply-To: <1128132543.7997.66.camel@localhost.localdomain> References: <1128132543.7997.66.camel@localhost.localdomain> Message-ID: <200510051912.21959.mega@hotpop.com> On Saturday 01 October 2005 04:09, Robert L. Read wrote: > The html directory in the elepahnt-0.2.1/doc directory is the SOURCE > for the documentation, > correct, and not the output of some other tool? I add to the > documentation by writing HTML > into that directory, correct? It's the source but it contains texinfo. HTML is generated from that. Do you have the cvs version checked out? > > > ---- > 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 From read at robertlread.net Wed Oct 5 18:38:53 2005 From: read at robertlread.net (Robert L. Read) Date: Wed, 05 Oct 2005 13:38:53 -0500 Subject: [elephant-devel] Creating documentation.... In-Reply-To: <200510051912.21959.mega@hotpop.com> References: <1128132543.7997.66.camel@localhost.localdomain> <200510051912.21959.mega@hotpop.com> Message-ID: <1128537533.7997.165.camel@localhost.localdomain> No, I don't have the CVS version checked out; I didn't know the repository was accesible. Where is it? What is the command to make the HTML from the texinfo? On Wed, 2005-10-05 at 19:12 +0200, G?bor Melis wrote: > On Saturday 01 October 2005 04:09, Robert L. Read wrote: > > The html directory in the elepahnt-0.2.1/doc directory is the SOURCE > > for the documentation, > > correct, and not the output of some other tool? I add to the > > documentation by writing HTML > > into that directory, correct? > > It's the source but it contains texinfo. HTML is generated from that. Do > you have the cvs version checked out? > > > > > > > ---- > > 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 mega at hotpop.com Wed Oct 5 17:54:32 2005 From: mega at hotpop.com (=?utf-8?q?G=C3=A1bor_Melis?=) Date: Wed, 5 Oct 2005 19:54:32 +0200 Subject: [elephant-devel] Creating documentation.... In-Reply-To: <1128537533.7997.165.camel@localhost.localdomain> References: <1128132543.7997.66.camel@localhost.localdomain> <200510051912.21959.mega@hotpop.com> <1128537533.7997.165.camel@localhost.localdomain> Message-ID: <200510051954.32591.mega@hotpop.com> On Wednesday 05 October 2005 20:38, Robert L. Read wrote: > No, I don't have the CVS version checked out; > I didn't know the repository was accesible. > > Where is it? use anon cvs from common-lisp.net: http://common-lisp.net/project-intro.shtml > What is the command to make the HTML from the texinfo? It seems the makefile is missing. Issue: makeinfo --force --html elephant.texinfo Use --force until you get docstrings.lisp running. It is from sbcl maybe the makefile can be liberated too. From read at robertlread.net Mon Oct 10 02:30:03 2005 From: read at robertlread.net (Robert L. Read) Date: Sun, 09 Oct 2005 21:30:03 -0500 Subject: [elephant-devel] Problem compiling the head of the CVS repository under SBCL 0.8.18 Message-ID: <1128911403.7997.230.camel@localhost.localdomain> In my ongoing attempt to implement a CL-SQL based backend, I have checked out the latest version of the CVS repository and attempted to install it before merging my (extremely large) patch from the Elephant 0.2.1 version where I have been developing previously. I am running SBCL 0.8.18. When I attempt to do: (asdf:operate 'asdf:load-op :elephant), (after properly compiling and installing in the correct places the berkeleydb 4.3 library and the libsleepycat C library) I get the error pasted in below. I understand CLOS, but just barely. It is not obvious why this is happening; I assume it is some SBCL specific feature, and the the head of the repository build successfully on some other system? Or am I just confused? If anyone has any idea or can help, please post immediately; I have been working on this full-time for over a month now and would really like to put a ribbon around it and publish it rather than abandon it. The slot %PERSISTENT-SLOTS is unbound in the object #. [Condition of type UNBOUND-SLOT] [Condition of type UNBOUND-SLOT] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. Backtrace: 0: ((SLOT-UNBOUND (T T T)) # # # # %PERSISTENT-SLOTS) 1: ("XEP for (SLOT-UNBOUND (T T T))" 5 # # # # %PERSISTENT-SLOTS)[:EXTERNAL] Locals: SB-DEBUG::ARG-0 = 5 SB-DEBUG::ARG-1 = : SB-DEBUG::ARG-2 = : SB-DEBUG::ARG-3 = : SB-DEBUG::ARG-4 = # SB-DEBUG::ARG-5 = %PERSISTENT-SLOTS [No catch-tags] 2: (SB-PCL::SLOT-UNBOUND-INTERNAL # 19) Locals: SB-DEBUG::ARG-0 = # SB-DEBUG::ARG-1 = 19 [No catch-tags] 3: ((UPDATE-PERSISTENT-SLOTS (PERSISTENT-METACLASS T)) # # # (INDICES)) Locals: SB-DEBUG::ARG-0 = : SB-DEBUG::ARG-1 = : SB-DEBUG::ARG-2 = # SB-DEBUG::ARG-3 = (INDICES) [No catch-tags] 4: ((REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # (:DIRECT-SUPERCLASSES (#) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) 5: ((SB-MOP:ENSURE-CLASS-USING-CLASS (SB-PCL::PCL-CLASS T)) # # # INDEXED-BTREE (:METACLASS PERSISTENT-METACLASS :DIRECT-SUPERCLASSES (BTREE) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) 6: (SB-PCL::REAL-LOAD-DEFCLASS INDEXED-BTREE PERSISTENT-METACLASS (BTREE) ((:INITFUNCTION #1=# :NAME INDICES :READERS (INDICES) :WRITERS (#) :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS (INDICES-CACHE) :WRITERS (#) :INITARGS NIL ...)) (:DOCUMENTATION "A BTree which supports secondary indices.") (INDICES-CACHE INDICES) ((SETF INDICES-CACHE) (SETF INDICES)) (INDICES-CACHE INDICES)) 7: (SB-INT:EVAL-IN-LEXENV 2 (LET ((#:G5805 #)) (SB-PCL::LOAD-DEFCLASS (QUOTE INDEXED-BTREE) (QUOTE PERSISTENT-METACLASS) (QUOTE #) (LIST # #) (LIST :DOCUMENTATION "A BTree which supports secondary indices.") (QUOTE #) (QUOTE #) (QUOTE #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 8: (SB-INT:EVAL-IN-LEXENV 2 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (LET (#) (SB-PCL::LOAD-DEFCLASS # # # # # # # #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 9: (SB-INT:EVAL-IN-LEXENV 2 (DEFCLASS INDEXED-BTREE (BTREE) ((INDICES :ACCESSOR INDICES :INITFORM #) (INDICES-CACHE :ACCESSOR INDICES-CACHE :INITFORM # :TRANSIENT T)) (:METACLASS PERSISTENT-METACLASS) (:DOCUMENTATION "A BTree which supports secondary indices.")) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 10: ("#'(LAMBDA NIL (LET # # ...))") 11: ((SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) # # #) 12: (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) ((indices :accessor indices :initform (make-hash-table)) (indices-cache :accessor indices-cache :initform (make-hash-table) :transient t)) (:metaclass persistent-metaclass) (:documentation \"A BTree which supports secondary indices.\")) ") 13: (SB-INT:EVAL-IN-LEXENV 2 (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) ((indices :accessor indices :initform (make-hash-table)) (indices-cache :accessor indices-cache :initform (make-hash-table) :transient t)) (:metaclass persistent-metaclass) (:documentation \"A BTree which supports secondary indices.\")) ") #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 14: (SWANK::EVAL-FOR-EMACS (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) ((indices :accessor indices :initform (make-hash-table)) (indices-cache :accessor indices-cache :initform (make-hash-table) :transient t)) (:metaclass persistent-metaclass) (:documentation \"A BTree which supports secondary indices.\")) ") "\"ELEPHANT\"" 125) 15: ("#'(LAMBDA NIL (LET # #))") 16: (SWANK::CALL-WITH-REDIRECTED-IO # #) 17: (SWANK::HANDLE-REQUEST #) 18: (SWANK::PROCESS-AVAILABLE-INPUT # #) 19: ("FLET SWANK::HANDLER") 20: ("#'(LAMBDA (SWANK-BACKEND::_) SWANK-BACKEND::_ ...)" #) -------------- next part -------------- An HTML attachment was scrubbed... URL: From blumberg at math.uchicago.edu Mon Oct 10 08:59:40 2005 From: blumberg at math.uchicago.edu (Andrew Blumberg) Date: Mon, 10 Oct 2005 03:59:40 -0500 (CDT) Subject: [elephant-devel] Problem compiling the head of the CVS repository under SBCL 0.8.18 In-Reply-To: <1128911403.7997.230.camel@localhost.localdomain> References: <1128911403.7997.230.camel@localhost.localdomain> Message-ID: hi robert, i wrote the clos metaclass stuff for elephant, and although i don't really have time to do much further development work i'd be happy to help you try and debug this. i'll try and take a look at it tomorrow evening (unless someone chimes in with a concise answer sooner). - andrew On Sun, 9 Oct 2005, Robert L. Read wrote: > In my ongoing attempt to implement a CL-SQL based backend, I have > checked out > the latest version of the CVS repository and attempted to install it > before merging > my (extremely large) patch from the Elephant 0.2.1 version where I have > been developing > previously. I am running SBCL 0.8.18. > > When I attempt to do: (asdf:operate 'asdf:load-op :elephant), (after > properly compiling > and installing in the correct places the berkeleydb 4.3 library and the > libsleepycat C library) > I get the error pasted in below. > > I understand CLOS, but just barely. It is not obvious why this is > happening; I assume it > is some SBCL specific feature, and the the head of the repository build > successfully > on some other system? Or am I just confused? > > If anyone has any idea or can help, please post immediately; I have been > working on > this full-time for over a month now and would really like to put a > ribbon around it > and publish it rather than abandon it. > > > > The slot %PERSISTENT-SLOTS is unbound in the object # METACLASS INDEXED-BTREE>. > [Condition of type UNBOUND-SLOT] > > > [Condition of type UNBOUND-SLOT] > > Restarts: > 0: [ABORT] Abort handling SLIME request. > 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). > 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. > > Backtrace: > 0: ((SLOT-UNBOUND (T T T)) # # # # %PERSISTENT-SLOTS) > 1: ("XEP for (SLOT-UNBOUND (T T T))" 5 # # # # %PERSISTENT-SLOTS)[:EXTERNAL] > Locals: > SB-DEBUG::ARG-0 = 5 > SB-DEBUG::ARG-1 = : > SB-DEBUG::ARG-2 = : > SB-DEBUG::ARG-3 = : > SB-DEBUG::ARG-4 = # > SB-DEBUG::ARG-5 = %PERSISTENT-SLOTS > [No catch-tags] > 2: (SB-PCL::SLOT-UNBOUND-INTERNAL # 19) > Locals: > SB-DEBUG::ARG-0 = # > SB-DEBUG::ARG-1 = 19 > [No catch-tags] > 3: ((UPDATE-PERSISTENT-SLOTS (PERSISTENT-METACLASS T)) # # # (INDICES)) > Locals: > SB-DEBUG::ARG-0 = : > SB-DEBUG::ARG-1 = : > SB-DEBUG::ARG-2 = # > SB-DEBUG::ARG-3 = (INDICES) > [No catch-tags] > 4: ((REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # (:DIRECT-SUPERCLASSES (#) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > 5: ((SB-MOP:ENSURE-CLASS-USING-CLASS (SB-PCL::PCL-CLASS T)) # # # INDEXED-BTREE (:METACLASS PERSISTENT-METACLASS :DIRECT-SUPERCLASSES (BTREE) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > 6: (SB-PCL::REAL-LOAD-DEFCLASS INDEXED-BTREE PERSISTENT-METACLASS (BTREE) ((:INITFUNCTION #1=# :NAME INDICES :READERS (INDICES) :WRITERS (#) :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS (INDICES-CACHE) :WRITERS (#) :INITARGS NIL ...)) (:DOCUMENTATION "A BTree which supports secondary indices.") (INDICES-CACHE INDICES) ((SETF INDICES-CACHE) (SETF INDICES)) (INDICES-CACHE INDICES)) > 7: (SB-INT:EVAL-IN-LEXENV 2 (LET ((#:G5805 #)) (SB-PCL::LOAD-DEFCLASS (QUOTE INDEXED-BTREE) (QUOTE PERSISTENT-METACLASS) (QUOTE #) (LIST # #) (LIST :DOCUMENTATION "A BTree which supports secondary indices.") (QUOTE #) (QUOTE #) (QUOTE #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > 8: (SB-INT:EVAL-IN-LEXENV 2 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (LET (#) (SB-PCL::LOAD-DEFCLASS # # # # # # # #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > 9: (SB-INT:EVAL-IN-LEXENV 2 (DEFCLASS INDEXED-BTREE (BTREE) ((INDICES :ACCESSOR INDICES :INITFORM #) (INDICES-CACHE :ACCESSOR INDICES-CACHE :INITFORM # :TRANSIENT T)) (:METACLASS PERSISTENT-METACLASS) (:DOCUMENTATION "A BTree which supports secondary indices.")) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > 10: ("#'(LAMBDA NIL (LET # # ...))") > 11: ((SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) # # #) > 12: (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > ((indices :accessor indices :initform (make-hash-table)) > (indices-cache :accessor indices-cache :initform (make-hash-table) > :transient t)) > (:metaclass persistent-metaclass) > (:documentation \"A BTree which supports secondary indices.\")) > ") > 13: (SB-INT:EVAL-IN-LEXENV 2 (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > ((indices :accessor indices :initform (make-hash-table)) > (indices-cache :accessor indices-cache :initform (make-hash-table) > :transient t)) > (:metaclass persistent-metaclass) > (:documentation \"A BTree which supports secondary indices.\")) > ") #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > 14: (SWANK::EVAL-FOR-EMACS (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > ((indices :accessor indices :initform (make-hash-table)) > (indices-cache :accessor indices-cache :initform (make-hash-table) > :transient t)) > (:metaclass persistent-metaclass) > (:documentation \"A BTree which supports secondary indices.\")) > ") "\"ELEPHANT\"" 125) > 15: ("#'(LAMBDA NIL (LET # #))") > 16: (SWANK::CALL-WITH-REDIRECTED-IO # #) > 17: (SWANK::HANDLE-REQUEST #) > 18: (SWANK::PROCESS-AVAILABLE-INPUT # #) > 19: ("FLET SWANK::HANDLER") > 20: ("#'(LAMBDA (SWANK-BACKEND::_) SWANK-BACKEND::_ ...)" #) > From read at robertlread.net Mon Oct 10 14:34:30 2005 From: read at robertlread.net (Robert L. Read) Date: Mon, 10 Oct 2005 09:34:30 -0500 Subject: [elephant-devel] Problem compiling the head of the CVS repository under SBCL 0.8.18 In-Reply-To: References: <1128911403.7997.230.camel@localhost.localdomain> Message-ID: <1128954871.7997.232.camel@localhost.localdomain> OK, thanks. I'll spend a couple of hours on it today, and if I am not completely stumped I'll tell you what I find. On Mon, 2005-10-10 at 03:59 -0500, Andrew Blumberg wrote: > hi robert, > > i wrote the clos metaclass stuff for elephant, and although i > don't really have time to do much further development work i'd be happy to > help you try and debug this. i'll try and take a look at it tomorrow > evening (unless someone chimes in with a concise answer sooner). > > - andrew > > On Sun, 9 Oct 2005, Robert L. Read wrote: > > > In my ongoing attempt to implement a CL-SQL based backend, I have > > checked out > > the latest version of the CVS repository and attempted to install it > > before merging > > my (extremely large) patch from the Elephant 0.2.1 version where I have > > been developing > > previously. I am running SBCL 0.8.18. > > > > When I attempt to do: (asdf:operate 'asdf:load-op :elephant), (after > > properly compiling > > and installing in the correct places the berkeleydb 4.3 library and the > > libsleepycat C library) > > I get the error pasted in below. > > > > I understand CLOS, but just barely. It is not obvious why this is > > happening; I assume it > > is some SBCL specific feature, and the the head of the repository build > > successfully > > on some other system? Or am I just confused? > > > > If anyone has any idea or can help, please post immediately; I have been > > working on > > this full-time for over a month now and would really like to put a > > ribbon around it > > and publish it rather than abandon it. > > > > > > > > The slot %PERSISTENT-SLOTS is unbound in the object # > METACLASS INDEXED-BTREE>. > > [Condition of type UNBOUND-SLOT] > > > > > > [Condition of type UNBOUND-SLOT] > > > > Restarts: > > 0: [ABORT] Abort handling SLIME request. > > 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). > > 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. > > > > Backtrace: > > 0: ((SLOT-UNBOUND (T T T)) # # # # %PERSISTENT-SLOTS) > > 1: ("XEP for (SLOT-UNBOUND (T T T))" 5 # # # # %PERSISTENT-SLOTS)[:EXTERNAL] > > Locals: > > SB-DEBUG::ARG-0 = 5 > > SB-DEBUG::ARG-1 = : > > SB-DEBUG::ARG-2 = : > > SB-DEBUG::ARG-3 = : > > SB-DEBUG::ARG-4 = # > > SB-DEBUG::ARG-5 = %PERSISTENT-SLOTS > > [No catch-tags] > > 2: (SB-PCL::SLOT-UNBOUND-INTERNAL # 19) > > Locals: > > SB-DEBUG::ARG-0 = # > > SB-DEBUG::ARG-1 = 19 > > [No catch-tags] > > 3: ((UPDATE-PERSISTENT-SLOTS (PERSISTENT-METACLASS T)) # # # (INDICES)) > > Locals: > > SB-DEBUG::ARG-0 = : > > SB-DEBUG::ARG-1 = : > > SB-DEBUG::ARG-2 = # > > SB-DEBUG::ARG-3 = (INDICES) > > [No catch-tags] > > 4: ((REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # (:DIRECT-SUPERCLASSES (#) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > > 5: ((SB-MOP:ENSURE-CLASS-USING-CLASS (SB-PCL::PCL-CLASS T)) # # # INDEXED-BTREE (:METACLASS PERSISTENT-METACLASS :DIRECT-SUPERCLASSES (BTREE) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > > 6: (SB-PCL::REAL-LOAD-DEFCLASS INDEXED-BTREE PERSISTENT-METACLASS (BTREE) ((:INITFUNCTION #1=# :NAME INDICES :READERS (INDICES) :WRITERS (#) :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS (INDICES-CACHE) :WRITERS (#) :INITARGS NIL ...)) (:DOCUMENTATION "A BTree which supports secondary indices.") (INDICES-CACHE INDICES) ((SETF INDICES-CACHE) (SETF INDICES)) (INDICES-CACHE INDICES)) > > 7: (SB-INT:EVAL-IN-LEXENV 2 (LET ((#:G5805 #)) (SB-PCL::LOAD-DEFCLASS (QUOTE INDEXED-BTREE) (QUOTE PERSISTENT-METACLASS) (QUOTE #) (LIST # #) (LIST :DOCUMENTATION "A BTree which supports secondary indices.") (QUOTE #) (QUOTE #) (QUOTE #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 8: (SB-INT:EVAL-IN-LEXENV 2 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (LET (#) (SB-PCL::LOAD-DEFCLASS # # # # # # # #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 9: (SB-INT:EVAL-IN-LEXENV 2 (DEFCLASS INDEXED-BTREE (BTREE) ((INDICES :ACCESSOR INDICES :INITFORM #) (INDICES-CACHE :ACCESSOR INDICES-CACHE :INITFORM # :TRANSIENT T)) (:METACLASS PERSISTENT-METACLASS) (:DOCUMENTATION "A BTree which supports secondary indices.")) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 10: ("#'(LAMBDA NIL (LET # # ...))") > > 11: ((SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) # # #) > > 12: (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") > > 13: (SB-INT:EVAL-IN-LEXENV 2 (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 14: (SWANK::EVAL-FOR-EMACS (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") "\"ELEPHANT\"" 125) > > 15: ("#'(LAMBDA NIL (LET # #))") > > 16: (SWANK::CALL-WITH-REDIRECTED-IO # #) > > 17: (SWANK::HANDLE-REQUEST #) > > 18: (SWANK::PROCESS-AVAILABLE-INPUT # #) > > 19: ("FLET SWANK::HANDLER") > > 20: ("#'(LAMBDA (SWANK-BACKEND::_) SWANK-BACKEND::_ ...)" #) > > > _______________________________________________ > 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 Oct 10 20:07:24 2005 From: read at robertlread.net (Robert L. Read) Date: Mon, 10 Oct 2005 15:07:24 -0500 Subject: [elephant-devel] Problem compiling the head of the CVS repository under SBCL 0.8.18 In-Reply-To: References: <1128911403.7997.230.camel@localhost.localdomain> Message-ID: <1128974845.7997.244.camel@localhost.localdomain> This change: (defmethod update-persistent-slots ((class persistent-metaclass) new- slot-list) ;; (setf (%persistent-slots class) (cons new-slot-list (car (% persistent-slots class))))) (setf (%persistent-slots class) (cons new-slot-list (if (slot-boundp class '%persistent-slots) (car (%persistent-slots class)) nil)))) Let's me build and get just 4 out 91 failures: Expected value: T Actual value: NIL. 4 out of 91 total tests failed: PREPARES-SLEEPYCAT, TEST-SEQ1, TEST- SEQ2, CLEANSUP-SLEEPYCAT. I don't know if that's to be expected or not on SBCL. The change above seems sensible to me but I can't pretend that I understand it well enough to know if it is creating these failures, or will create some horrible bug somewhere else. Perhaps you have an opinion, Andrew? On Mon, 2005-10-10 at 03:59 -0500, Andrew Blumberg wrote: > hi robert, > > i wrote the clos metaclass stuff for elephant, and although i > don't really have time to do much further development work i'd be happy to > help you try and debug this. i'll try and take a look at it tomorrow > evening (unless someone chimes in with a concise answer sooner). > > - andrew > > On Sun, 9 Oct 2005, Robert L. Read wrote: > > > In my ongoing attempt to implement a CL-SQL based backend, I have > > checked out > > the latest version of the CVS repository and attempted to install it > > before merging > > my (extremely large) patch from the Elephant 0.2.1 version where I have > > been developing > > previously. I am running SBCL 0.8.18. > > > > When I attempt to do: (asdf:operate 'asdf:load-op :elephant), (after > > properly compiling > > and installing in the correct places the berkeleydb 4.3 library and the > > libsleepycat C library) > > I get the error pasted in below. > > > > I understand CLOS, but just barely. It is not obvious why this is > > happening; I assume it > > is some SBCL specific feature, and the the head of the repository build > > successfully > > on some other system? Or am I just confused? > > > > If anyone has any idea or can help, please post immediately; I have been > > working on > > this full-time for over a month now and would really like to put a > > ribbon around it > > and publish it rather than abandon it. > > > > > > > > The slot %PERSISTENT-SLOTS is unbound in the object # > METACLASS INDEXED-BTREE>. > > [Condition of type UNBOUND-SLOT] > > > > > > [Condition of type UNBOUND-SLOT] > > > > Restarts: > > 0: [ABORT] Abort handling SLIME request. > > 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). > > 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. > > > > Backtrace: > > 0: ((SLOT-UNBOUND (T T T)) # # # # %PERSISTENT-SLOTS) > > 1: ("XEP for (SLOT-UNBOUND (T T T))" 5 # # # # %PERSISTENT-SLOTS)[:EXTERNAL] > > Locals: > > SB-DEBUG::ARG-0 = 5 > > SB-DEBUG::ARG-1 = : > > SB-DEBUG::ARG-2 = : > > SB-DEBUG::ARG-3 = : > > SB-DEBUG::ARG-4 = # > > SB-DEBUG::ARG-5 = %PERSISTENT-SLOTS > > [No catch-tags] > > 2: (SB-PCL::SLOT-UNBOUND-INTERNAL # 19) > > Locals: > > SB-DEBUG::ARG-0 = # > > SB-DEBUG::ARG-1 = 19 > > [No catch-tags] > > 3: ((UPDATE-PERSISTENT-SLOTS (PERSISTENT-METACLASS T)) # # # (INDICES)) > > Locals: > > SB-DEBUG::ARG-0 = : > > SB-DEBUG::ARG-1 = : > > SB-DEBUG::ARG-2 = # > > SB-DEBUG::ARG-3 = (INDICES) > > [No catch-tags] > > 4: ((REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) # (:DIRECT-SUPERCLASSES (#) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > > 5: ((SB-MOP:ENSURE-CLASS-USING-CLASS (SB-PCL::PCL-CLASS T)) # # # INDEXED-BTREE (:METACLASS PERSISTENT-METACLASS :DIRECT-SUPERCLASSES (BTREE) :DIRECT-SLOTS ((:INITFUNCTION #1=# :NAME INDICES :READERS # :WRITERS # :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS # :WRITERS # :INITARGS NIL ...)) :DEFINITION-SOURCE ((DEFCLASS INDEXED-BTREE) NIL) :DOCUMENTATION "A BTree which supports secondary indices.")) > > 6: (SB-PCL::REAL-LOAD-DEFCLASS INDEXED-BTREE PERSISTENT-METACLASS (BTREE) ((:INITFUNCTION #1=# :NAME INDICES :READERS (INDICES) :WRITERS (#) :INITARGS NIL ...) (:INITFUNCTION #1# :NAME INDICES-CACHE :READERS (INDICES-CACHE) :WRITERS (#) :INITARGS NIL ...)) (:DOCUMENTATION "A BTree which supports secondary indices.") (INDICES-CACHE INDICES) ((SETF INDICES-CACHE) (SETF INDICES)) (INDICES-CACHE INDICES)) > > 7: (SB-INT:EVAL-IN-LEXENV 2 (LET ((#:G5805 #)) (SB-PCL::LOAD-DEFCLASS (QUOTE INDEXED-BTREE) (QUOTE PERSISTENT-METACLASS) (QUOTE #) (LIST # #) (LIST :DOCUMENTATION "A BTree which supports secondary indices.") (QUOTE #) (QUOTE #) (QUOTE #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 8: (SB-INT:EVAL-IN-LEXENV 2 (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) (LET (#) (SB-PCL::LOAD-DEFCLASS # # # # # # # #))) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 9: (SB-INT:EVAL-IN-LEXENV 2 (DEFCLASS INDEXED-BTREE (BTREE) ((INDICES :ACCESSOR INDICES :INITFORM #) (INDICES-CACHE :ACCESSOR INDICES-CACHE :INITFORM # :TRANSIENT T)) (:METACLASS PERSISTENT-METACLASS) (:DOCUMENTATION "A BTree which supports secondary indices.")) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 10: ("#'(LAMBDA NIL (LET # # ...))") > > 11: ((SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) # # #) > > 12: (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") > > 13: (SB-INT:EVAL-IN-LEXENV 2 (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :HANDLED-CONDITIONS NIL :DISABLED-PACKAGE-LOCKS NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] > > 14: (SWANK::EVAL-FOR-EMACS (SWANK:INTERACTIVE-EVAL "(defclass indexed-btree (btree) > > ((indices :accessor indices :initform (make-hash-table)) > > (indices-cache :accessor indices-cache :initform (make-hash-table) > > :transient t)) > > (:metaclass persistent-metaclass) > > (:documentation \"A BTree which supports secondary indices.\")) > > ") "\"ELEPHANT\"" 125) > > 15: ("#'(LAMBDA NIL (LET # #))") > > 16: (SWANK::CALL-WITH-REDIRECTED-IO # #) > > 17: (SWANK::HANDLE-REQUEST #) > > 18: (SWANK::PROCESS-AVAILABLE-INPUT # #) > > 19: ("FLET SWANK::HANDLER") > > 20: ("#'(LAMBDA (SWANK-BACKEND::_) SWANK-BACKEND::_ ...)" #) > > > _______________________________________________ > 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 Oct 13 23:35:40 2005 From: read at robertlread.net (Robert L. Read) Date: Thu, 13 Oct 2005 18:35:40 -0500 Subject: [elephant-devel] Bug report --- hanging lisp image with certain transaction commands on clean 0.2.1 installation Message-ID: <1129246540.7997.310.camel@localhost.localdomain> This series of operations hangs an out-of-the box 0.2.1 installation on SBC 0.8.18 against BerkeleyDB 4.2 as well as the tip of the branch against BerkeleyDB 4.3 (at least, in my code! (asdf:operate 'asdf:load-op :elephant) (asdf:operate 'asdf:load-op :elephant-tests) (in-package "ELEPHANT-TESTS") (open-store *testdb-path*) # ELE-TESTS> (start-transaction) # ELE-TESTS> (commit-transaction) # ELE-TESTS> (setq *current-transaction* (db-transaction-begin (controller-environment *store-controller*))) # ELE-TESTS> (db-transaction-commit :transaction *current-transaction*) NIL ELE-TESTS> (defvar *friends-birthdays* (make-instance 'btree)) Control stack guard page temporarily disabled: proceed with caution ; Evaluation aborted ELE-TESTS> (defvar *friends-birthdays* (make-instance 'btree)) *FRIENDS-BIRTHDAYS* ELE-TESTS> (add-to-root "friends-birthdays" *friends-birthdays*) ; Evaluation aborted ELE-TESTS> The hang appears to be somehow have something to do with the LISP state; if you restart the LISP, you can again connect without having to run "db_recover" on the sleepycat database. I discovered this bug in my own (highly changed) code and went back to a clean 0.2.1 install to verify that it exists there. I have not tried it in a clean install against BerkeleyDB 4.3 (that is, the tip of the CVS trunk, with none of my modifications.) I have no reason to belive this is important, but this sequence is in the "tutorial" documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Fri Oct 14 16:18:49 2005 From: read at robertlread.net (Robert L. Read) Date: Fri, 14 Oct 2005 11:18:49 -0500 Subject: [elephant-devel] Bug report --- hanging lisp image with certain transaction commands on clean 0.2.1 installation (AND cvs head) In-Reply-To: References: <1129246540.7997.310.camel@localhost.localdomain> Message-ID: <1129306729.7997.317.camel@localhost.localdomain> On Fri, 2005-10-14 at 01:38 -0500, Andrew Blumberg wrote: > it'd be pretty interesting to know if this bug is present in the head > of the CVS code (unmodified). . . > > - andrew I just checked out the head and did a completely clean install. Executing this sequence of commands creates a segmentation fault (slightly different than in my code and in 0.2.1?) with no backtrace. segmentation violation at #X3CF6FE [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. Backtrace: Here are the commands, after loading elephant, test, and changing package names. This is SBCL 0.8.18. ELE-TESTS> (open-store *testdb-path*) # ELE-TESTS> (start-transaction) # ELE-TESTS> (commit-transaction) # ELE-TESTS> (setq *current-transaction* (db-transaction-begin (controller-environment *store-controller*))) # ELE-TESTS> (db-transaction-commit :transaction *current-transaction*) NIL ELE-TESTS> (defvar *friends-birthdays* (make-instance 'btree)) *FRIENDS-BIRTHDAYS* ELE-TESTS> (add-to-root "friends-birthdays" *friends-birthdays*) ; Evaluation aborted ELE-TESTS> (add-to-root "spud" "mud") ; Evaluation aborted ELE-TESTS> -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Sat Oct 15 15:53:35 2005 From: read at robertlread.net (Robert L. Read) Date: Sat, 15 Oct 2005 10:53:35 -0500 Subject: [elephant-devel] Third attempt to send message (attachments removed) Message-ID: <1129391615.7997.363.camel@localhost.localdomain> This is my third attempt to send this message. I have removed the HTML that I had included and the attachments to see if a spam filter is blocking this or something. If this go through, I will attempt again to post the remainder of the message. Dear Elephant Devel team, Here is my good-enough-to-be-released extension of elephant to use CL-SQL as a back-end (with PostGres). Below is the documentation that I wrote (It's in the texinfo, but I thought you might like to read it directly, so I pasted it here.) Please find attached a tar file containing all of the new files, and additionally a file containing the cvs diff of the files that already existed in the repository. If your interested in this, you should probably read the documentation below. The code change is so great that I doubt you can see much from the diff; the best way to really analyze would be to create a separate branch in CVS and allow me to commit my stuff there, so that one can easily checkout the whole branch. In a nutshell, I have extended Elephant to utilized CL-SQL (on top of PostGres) as a back-end in addition to BerkeleyDB. Some people may think this pointless; others may be pleased with the more permissive licensing of PostGres, or see this as a step to supporting, for example, SQLite. Addtionally, this version is a "mutli-repository" version in that many repositories can be open at the same time, and data can be migrated between them, without regard to the implementation strategy that underlies the repository. I commend the Elephant developers on the good set of tests they had; I have expanded them to allow testing on multiple repository types and to test migration. I know the current owners of Elephant are looking for a new owner. That, and the fact that some people might like Elephant the way it is and hate the apparent complexity that I have added, or might really like what I have done, creates a complicated set of questions we have to answer: 1) Who will own Elephant? 2) Should this be the next version of Elephant, or should it be a fork (that is, a completely different project, maybe "Bignose" or something)? I don't know how many people use Elephant or are on this list. I enjoyed it until I hit the BerkeleyDB licensing restriction. I definitely plan to use this work that I have done in a website moving forward, and will be maintaining it, one way or the other. I have not yet offered to own Elephant, since I am not an expert LISP coder, have never managed a large open-source project before, don't know who is using it, don't plan to pay for any lisp system, and don't know how much time is involved in maintaining such a package, and am not an expert on BerkeleyDB. However, if nobody else has volunteered and Ben can't do it, I suppose that I must be better than nothing at all. Please express some sort of opinion. I spent 5 solid weeks on this; which in hindsight was probably a three-week waste of time compared to just implementing my own serializer, which would have served my purpose. However, now that it is presentable, I certainly hope that someone in addition to myself will benefit from it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Sat Oct 15 16:06:32 2005 From: read at robertlread.net (Robert L. Read) Date: Sat, 15 Oct 2005 11:06:32 -0500 Subject: [elephant-devel] Can one not send attachments to to this list? Message-ID: <1129392393.7997.368.camel@localhost.localdomain> I need to distribute a tar file and a large cvs diff, or else have a branch in the CVS tree into which I can commit my changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dankna at accela.net Sun Oct 16 12:48:14 2005 From: dankna at accela.net (Dan Knapp) Date: Sun, 16 Oct 2005 08:48:14 -0400 Subject: [elephant-devel] Third attempt to send message (attachments removed) In-Reply-To: <1129391615.7997.363.camel@localhost.localdomain> References: <1129391615.7997.363.camel@localhost.localdomain> Message-ID: Well, I'm still using Elephant. I'm happy to see your port, although I have not run up against the licensing issues with Sleepycat, so I don't really need it. I really wish I could volunteer my own time to keep Elephant alive... it's an excellent project but it can't last without a maintainer. Somebody ought to put out a call for maintainership on Planet Lisp, comp.lang.lisp, etc. There may be people with the time to spare who aren't on this mailing list... In answer to your question, I think this should be the next version of Elephant, in that otherwise it looks like things are going to end up unmaintained anyway. Have I understood correctly, that the Sleepycat backend still works with this version, although you can't guarantee it won't break in future? Not that my answer changes if not, but if that's the case I see it as a no-brainer. Elephant isn't truly what I would call a large project, so hopefully you will find maintaining it easier than you expect. It's just a little hard to get oriented in somebody else's code, isn't it? You'll get the hang of it though. Do you need web space to let people get your patch? I can host it for you. -- Dan Knapp -------------- next part -------------- An HTML attachment was scrubbed... URL: From read at robertlread.net Sun Oct 16 16:06:41 2005 From: read at robertlread.net (Robert L. Read) Date: Sun, 16 Oct 2005 11:06:41 -0500 Subject: [elephant-devel] Third attempt to send message (attachments removed) In-Reply-To: References: <1129391615.7997.363.camel@localhost.localdomain> Message-ID: <1129478802.7997.376.camel@localhost.localdomain> Yes, the Berkeley DB back-end works completely with the new code; I intend to keep it working as well, just not to actively develop for it. Thanks for the offer of hosting; I have my own site and will put the stuff there at least to make it available to th people on this list. On Sun, 2005-10-16 at 08:48 -0400, Dan Knapp wrote: > Well, I'm still using Elephant. I'm happy to see your port, > although I have not run up against the licensing issues with > Sleepycat, so I don't really need it. > > > I really wish I could volunteer my own time to keep Elephant > alive... it's an excellent project but it can't last without a > maintainer. Somebody ought to put out a call for maintainership on > Planet Lisp, comp.lang.lisp, etc. There may be people with the time > to spare who aren't on this mailing list... > > > In answer to your question, I think this should be the next version > of Elephant, in that otherwise it looks like things are going to end > up unmaintained anyway. Have I understood correctly, that the > Sleepycat backend still works with this version, although you can't > guarantee it won't break in future? Not that my answer changes if > not, but if that's the case I see it as a no-brainer. > > > Elephant isn't truly what I would call a large project, so hopefully > you will find maintaining it easier than you expect. It's just a > little hard to get oriented in somebody else's code, isn't it? You'll > get the hang of it though. > > > Do you need web space to let people get your patch? I can host it > for you. > > > > -- Dan Knapp > > > > > _______________________________________________ > 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 Oct 15 15:58:16 2005 From: read at robertlread.net (Robert L. Read) Date: Sat, 15 Oct 2005 10:58:16 -0500 Subject: [elephant-devel] SQL Back-end ready --- sending with links removed in hopes it goes through Message-ID: <1129391897.7997.365.camel@localhost.localdomain> Dear Elephant Devel team, Here is my good-enough-to-be-released extension of elephant to use CL-SQL as a back-end (with PostGres). Below is the documentation that I wrote (It's in the texinfo, but I thought you might like to read it directly, so I pasted it here.) Please find attached a tar file containing all of the new files, and additionally a file containing the cvs diff of the files that already existed in the repository. If your interested in this, you should probably read the documentation below. The code change is so great that I doubt you can see much from the diff; the best way to really analyze would be to create a separate branch in CVS and allow me to commit my stuff there, so that one can easily checkout the whole branch. In a nutshell, I have extended Elephant to utilized CL-SQL (on top of PostGres) as a back-end in addition to BerkeleyDB. Some people may think this pointless; others may be pleased with the more permissive licensing of PostGres, or see this as a step to supporting, for example, SQLite. Addtionally, this version is a "mutli-repository" version in that many repositories can be open at the same time, and data can be migrated between them, without regard to the implementation strategy that underlies the repository. I commend the Elephant developers on the good set of tests they had; I have expanded them to allow testing on multiple repository types and to test migration. I know the current owners of Elephant are looking for a new owner. That, and the fact that some people might like Elephant the way it is and hate the apparent complexity that I have added, or might really like what I have done, creates a complicated set of questions we have to answer: 1) Who will own Elephant? 2) Should this be the next version of Elephant, or should it be a fork (that is, a completely different project, maybe "Bignose" or something)? I don't know how many people use Elephant or are on this list. I enjoyed it until I hit the BerkeleyDB licensing restriction. I definitely plan to use this work that I have done in a website moving forward, and will be maintaining it, one way or the other. I have not yet offered to own Elephant, since I am not an expert LISP coder, have never managed a large open-source project before, don't know who is using it, don't plan to pay for any lisp system, and don't know how much time is involved in maintaining such a package, and am not an expert on BerkeleyDB. However, if nobody else has volunteered and Ben can't do it, I suppose that I must be better than nothing at all. Please express some sort of opinion. I spent 5 solid weeks on this; which in hindsight was probably a three-week waste of time compared to just implementing my own serializer, which would have served my purpose. However, now that it is presentable, I certainly hope that someone in addition to myself will benefit from it. 5 SQL back-end * SQL-Introduction: The design and status of the SQL back-end extention. * Extention Status: The current status of the SQL back-end extention. * Back-compatibility: Issues if you have already been using Elephant * Multi-repository Operation: Specifying repositories * Setting up PostGres: An example * Repository Migration: How to move objects from one repository to another * 5.1 SQL-Introduction Although originally designed as an interface to the BerkeleyDB system, the original Elephant system has been experimenetally extended to support the use of relational database management systems as the implementation of the persistent store. This relies on Kevin Rosenberg's CL-SQL interface to relational systems. Although the BerkeleyDB system is an ideal object store for LISP objects, one might prefer the licensing of a different system. For example, at the time of this writing, it is my interpretation that one cannot use the BerkeleyDB system behind a public website http://www.sleepycat.com/download/licensinginfo.shtml#redistribute unless one releases the entire web application as open source. The PostGres DBMS has no such restriction. Elephant itself is released under the GPL. It is somewhat debatable if the GPL allows one to construct to construct a non-open-source web application but the preponderance of opinion appears to be that it does. Thefore using Elephant and the other GPLed software that it depends upon allows one to host a a non open-source web application. This might be a reason to use Elephant on PostGres rather than Elephant on BerkeleyDB. Other reasons to use a relational database system might include: familiarity with those systems, the fact that some part of your application needs to use the truly relational aspects of those systems, preference for the tools associated with those systems, etc. The SQL back-end extention of Elephant provides a function for migrating data seamlessly between repositories. That is, one can quite easily move data from a BerkeleyDB repository to a PostGres repository, and vice versa. In fact, one of the most important aspects of the extention is that it makes Elephant a multi-repository system, rather than a single repository system, as addition to allowing different implementation strategies for those repositories. This offers at least the possiblity than once can develop using one backend, for example BerkeleyDB, and then later move to MySQL. At the time of this writing, the basic strategy for the SQL implementation is quite simple. The same serializer used for the Sleepycat implementation is employed, the byte-string is base64 encoded, and placed in a single table which is managed by Elephant. 5.1 SQL-Introduction Although originally designed as an interface to the BerkeleyDB system, the original Elephant system has been experimenetally extended to support the use of relational database management systems as the implementation of the persistent store. This relies on Kevin Rosenberg's CL-SQL interface to relational systems. Although the BerkeleyDB system is an ideal object store for LISP objects, one might prefer the licensing of a different system. For example, at the time of this writing, it is my interpretation that one cannot use the BerkeleyDB system behind a public website http://www.sleepycat.com/download/licensinginfo.shtml#redistribute unless one releases the entire web application as open source. The PostGres DBMS has no such restriction. Elephant itself is released under the GPL. It is somewhat debatable if the GPL allows one to construct to construct a non-open-source web application but the preponderance of opinion appears to be that it does. Thefore using Elephant and the other GPLed software that it depends upon allows one to host a a non open-source web application. This might be a reason to use Elephant on PostGres rather than Elephant on BerkeleyDB. Other reasons to use a relational database system might include: familiarity with those systems, the fact that some part of your application needs to use the truly relational aspects of those systems, preference for the tools associated with those systems, etc. The SQL back-end extention of Elephant provides a function for migrating data seamlessly between repositories. That is, one can quite easily move data from a BerkeleyDB repository to a PostGres repository, and vice versa. In fact, one of the most important aspects of the extention is that it makes Elephant a multi-repository system, rather than a single repository system, as addition to allowing different implementation strategies for those repositories. This offers at least the possiblity than once can develop using one backend, for example BerkeleyDB, and then later move to MySQL. At the time of this writing, the basic strategy for the SQL implementation is quite simple. The same serializer used for the Sleepycat implementation is employed, the byte-string is base64 encoded, and placed in a single table which is managed by Elephant. 5.3 Back-compatibility The CL-SQL based extention is very back-compatible with any existing Elephant application, except for two items. First, the routines ?build-btree? and ?build-index-btree? should be used in place of the previous approach to direct calls to make-instance. This is necessary, because the underlying class of the object depends on what repository it is stored in. These routines, like make-instance on persistent objects directly, allow you to specify the store controller at creation time. However, build-btree and build-index-btree will use the global *store-controller* if no keyword argument is provided. Secondly, in addition to executing: (asdf:operate 'asdf:load-op :elephant) to load elephant, one must execute either or both of: (asdf:operate 'asdf:load-op :ele-clsql) (asdf:operate 'asdf:load-op :ele-bdb) depending on whether or not you wish to use the clsql backend or the BerkeleyDB backend, or both. 5.4 Multi-repository Operation Elephant now keeps a small hashtables that maps ?database specifications? into actual database connections. If a database spec is a string, it is assumed to be a BerkeleyDB path. If it is a list, it is a assumed to be a CL-SQL connection specification. The tests now have a function ?do-all-tests-spec? that take a spec and based on its type attempt to open the correct kind of store controller and perform the tests. The routine ?get-controller? takes this specifiation. The basic strategy is that the ?database specification? object is stored in every persistent object and collection so that the repository can be found. In this way, objects that reside in different repositories can coexist within the LISP object space, allowing data migration. 5.5 Setting up PostGres To set up a PostGres based back end, you should: 1. Install postgres and make sure postmaster is running. 2. Create a database called ?test? and set its permissions to be reached by whatever connection specification you intend to use. The tests use: (defvar *testpg-path* '("localhost.localdomain" "test" "postgres" "")) meaning that connections must be allowed to the database test, user ?postgres?, no password, connected from the same machine ?localhost.localdomain?. (This would be changed to something more secure in a real application.) Typically you edit the file : pg_hba.conf to enable various kinds of connections in postgres. 3. Be sure to enable socket connection to postgres when you invoke the postmaster. 4. Test that you can connect to the database with these credentials by running: psql -h 127.0.0.1 -U postgres test Before you attempt to connect with Elephant. meaning that connections must be allowed to the database test, user ?postgres?, no password, connected from the same machine ?localhost.localdomain?. (This would be changed to something more secure in a real application.) Furthermore, you must grant practically all creation/read/write privileges to the user postgres on this schema, so that it can construct the tables it needs. Upon first opening a CL-SQL based store controller, the tables, indexes, sequences, and so on needed by the Elephant system will be created in the schema named ?test? automatically. To run the tests, execute: (asdf:operate 'asdf:load-op :elephant) (asdf:operate 'asdf:load-op :ele-clsql) (asdf:oos 'asdf:load-op :clsql-postgresql-socket) (in-package "ELEPHANT-TESTS") (do-all-tests-spec *testpg-path*) This should produce a small number of errors (about 7) for those test having to do with migration and the BerkeleyDB system specifically. If you execute: (asdf:operate 'asdf:load-op :ele-bdb) Then connection to the BerkeleyDB system will be enabled, and you should be able to execute both (do-all-tests-spec *testpg-path*) (do-all-tests-spec *testdb-path*) with no errors in either case. At present the system has only been tested under PostGres. Some code parametrization would be required to work with other databases. 5.6 Repository Migration This version of Elephant supports migration betwen store controllers, whether of the same implementation strategy or not. The tests migrate1 - migrate5 are demonstrations of this techinque. The functions for performing these migrations are: migraten-pobj The name of this function is meant to imply that it is destructive of the object in question, mutating it to point at the new repository. Which requies that you provide a copy-function to copy whatever slots you want from the persistent object as deeply or as shallowly as you desire. Data collections (btree's) can be move with the function: migrate A simple object that does not inherit from ?persistent? but is attached to a key (on the root) can be copied with the routine copy-from-key It is hoped that these routines would allow, with some labor, a user to use one repository, and later decide to start using a different implementation strategy, and easily migrate the objects to the the new repository. The old repository could then be abandoned, or multiple repositories could be used at the same time. ---- 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 -------------- A non-text attachment was scrubbed... Name: cvs.diff Type: text/x-patch Size: 145969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sql-backend.tar.gz Type: application/x-compressed-tar Size: 18154 bytes Desc: not available URL: From read at robertlread.net Wed Oct 19 20:00:39 2005 From: read at robertlread.net (Robert L. Read) Date: Wed, 19 Oct 2005 15:00:39 -0500 Subject: [elephant-devel] New maintainer and new branch Message-ID: <1129752040.22232.60.camel@localhost.localdomain> I am now the new maintainer of the Elephant project. I don't know much about the history of what has been going on, so please be patient with me and give me as much information as you can. I have recently written a significant extension the original Elephant project. This allows one to use CL-SQL, and in particular PostGres, as a backend. However, the BerkeleyDB system still works and in fact functions are provided to migrate data between multiple co-existing repositories, whether implemented with PostGres or BerkeleyDB. The PostGres system is presently much slower. However, some people may prefer it to the BerkeleyDB system due to the BerkeleyDB license, which does not allow you to build a public website unless your system is all open-source. The extention is checked into a branch of CVS called "SQL-BACK-END". The easiest way to get it, and the extention of the documentation that I wrote, is to do an anonymous CVS checkout of the revision "SQL-BACK- END": cvs -z3 -d :pserver:anonymous:anonymous at common- lisp.net:/project/elephant/cvsroot co -r SQL-BACK-END elephant By doing a "make" in the docs directory, you can construct the HTML based documentation that includes a new chapter on this extension. Or you can read it on the common-lisp Elephant site: http://common-lisp.net/project/elephant/doc/SQL-back_002dend.html#SQL- back_002dend The file "src/RUNTEST.lisp" shows how to load and run the implementation-specific tests, as well as the migration tests. I don't know how many people are using elephant, or what your desires may be. My basic plan is to wait until mid-November and if nobody has complained enough, to make the SQL-BACK-END version the main version to be released as Elephant 0.3, at which point a tar file will be available. I am not an expert on BerkeleyDB but intend to maintain complete back compatibility with it. This issue is discussed in the new documentation. I intend to actively use this system. I may not be actively developing it, but here is my wish list: 1) SQLite compatibility (estimate: 3 days?) 2) Much more efficient encoding (estimate: 5 days?) Please let me hear from you if you have any interest in this; I am strongly motivated to maintain software that people are using. ---- 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 midfield at gmail.com Thu Oct 20 00:31:33 2005 From: midfield at gmail.com (Ben Lee) Date: Wed, 19 Oct 2005 19:31:33 -0500 Subject: [elephant-devel] New maintainer and new branch In-Reply-To: <1129752040.22232.60.camel@localhost.localdomain> References: <1129752040.22232.60.camel@localhost.localdomain> Message-ID: <4356E565.9030302@gmail.com> Hi, I wanted to thank Robert for his work and his taking over Elephant. Andrew and I will try to be around to help out when we can, too. Also, probably since Elephant is no longer dependent on Sleepycat we might want to rethink the license. Are there people who are interested in a new license for Elephant? Ben Robert L. Read wrote: > I am now the new maintainer of the Elephant project. > > I don't know much about the history of what has been going on, so please > be patient with me and give me as much information as you can. > > I have recently written a significant extension the original Elephant > project. > This allows one to use CL-SQL, and in particular PostGres, as a backend. > However, the BerkeleyDB system still works and in fact functions are > provided to migrate data between multiple co-existing repositories, whether > implemented with PostGres or BerkeleyDB. > > The PostGres system is presently much slower. However, some people > may prefer it to the BerkeleyDB system due to the BerkeleyDB license, > which does not allow you to build a public website unless your system is > all open-source. > > The extention is checked into a branch of CVS called "SQL-BACK-END". > > The easiest way to get it, and the extention of the documentation that > I wrote, is to do an anonymous CVS checkout of the revision "SQL-BACK-END": > > cvs -z3 -d > :pserver:anonymous:anonymous at common-lisp.net:/project/elephant/cvsroot > co -r SQL-BACK-END elephant > > By doing a "make" in the docs directory, you can construct the HTML > based documentation > that includes a new chapter on this extension. Or you can read it on the > common-lisp Elephant site: > http://common-lisp.net/project/elephant/doc/SQL-back_002dend.html#SQL-back_002dend > > The file "src/RUNTEST.lisp" shows how to load and run the > implementation-specific tests, > as well as the migration tests. > > I don't know how many people are using elephant, or what your desires > may be. > My basic plan is to wait until mid-November and if nobody has complained > enough, > to make the SQL-BACK-END version the main version to be released as > Elephant 0.3, > at which point a tar file will be available. > > I am not an expert on BerkeleyDB but intend to maintain complete back > compatibility > with it. This issue is discussed in the new documentation. > > I intend to actively use this system. I may not be actively developing > it, but here is > my wish list: > > 1) SQLite compatibility (estimate: 3 days?) > 2) Much more efficient encoding (estimate: 5 days?) > > Please let me hear from you if you have any interest in this; I am > strongly motivated > to maintain software that people are using. > > > ---- > 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