[elephant-devel] Long email from Andrew...

Robert L. Read read at robertlread.net
Tue Jan 10 21:41:59 UTC 2006


Dear Team and Andrew Philpot,
    This long message from Andrew seemed worth including here.
Summary:
1)  There are compiler warnings that we should fix
2)  ACL is green on the tests
3)  Some other problems are missing.
4)  Andrew calls for a large example application.
5)  Andrew identifies a place where our error handling needs to be
improved.
All of this sound unpleasant, but is actually good:  Andrew is
identifying of
ways to improve the system, and despite these problems is (apparently
from his words below) actually becoming MORE confident that he
can use Elephant.

Thank you, Andrew.  I will try to get back to you in more detail later
this
week.



On Tue, 2006-01-10 at 12:28 -0800, Andrew Philpot wrote:
  Before I step in a bucket again, can you make this very clear to me:
> 
>   With all the changes that you have mailed me, are the tests green
>   under ACL? (barring the migration tests.)
> 
> Most of the edits I sent you in the last couple of days correspond
> from my perspective to quality improvements, not to getting things to
> work.  When I get compiler warnings, I usually address them just so I
> can see the "real" errors when they are signaled.  I know some other
> developers can "see around" them better than I, so I don't 
> 
> A note on getting things to work: my build procedure is to always
> compile elephant itself (:force t), and then to loading clsql as well
> on top.  This nearly eliminates undefined references.  (The only one
> still missing is function :STORE-CONTROLLER-SQL).  But this build
> workaround seems far from ideal, and restructuring the ASDF might be
> appropriate.
> 
> (defun build-elephant ()
>        ;; I have UFFI 1.4.6 installed in service of another
>        ;; application which I can't tinker with
>   (asdf:operate 'asdf:load-op :uffi157)
>   (provide :uffi)
>   (asdf:operate 'asdf:load-op :elephant :force t)
>   (asdf:operate 'asdf:load-op :ele-bdb)
>   (asdf:operate 'asdf:load-op :ele-clsql)
>   (asdf:operate 'asdf:load-op :elephant-tests)
>   (eval (read-from-string "(setq elephant-tests::*test-path-primary* 
> \"/opt/elephant/tests/testdb\")"))
>   (eval (read-from-string "(setq elephant-tests::*test-path-secondary*
nil)"))
>   (eval (read-from-string "(elephant-tests::do-all-tests-spec 
> elephant-tests::*test-path-primary*)"))
>   )
> 
> Having said that, following the above I get:
> 
> 5 out of 106 total tests failed: ELEPHANT-TESTS::MIGRATE1,
>    ELEPHANT-TESTS::MIGRATE2, ELEPHANT-TESTS::MIGRATE3,
>    ELEPHANT-TESTS::MIGRATE4, ELEPHANT-TESTS::MIGRATE5.
> 
> Can I ask whether sleepycat::*elephant-lib-path* (used in a
> load-foreign-library call in sleepycat.lisp) is supposed to be the
> same object (presumably it is the same value) as
> elephant::*elephant-lib-path* defined in controller.lisp?  I get a
> message that the former is not bound when I compile the sleepycat
> stuff.  To my eye, it looks probable that this is another possibly
> inappropriate circular reference; shouldn't sleepycat per se be
> independent of the higher level elephant layer?  I'm not setting the
> former at all right now, but perhaps I should be.  What do you think
> of elephant (and possibly sleepycat) configuration file(s) which would
> group all this stuff in one place.

I can't yet answer about how it should be set, but yes, I agree that
sleepycat.lisp ought in theory to be a pure interface to the sleepycat
API and therefore independent of the other code.  Yes, you have
convinced me the configuration stuff should be rewritten and 
streamlined.

> 
> I'm by no means a UFFI expert.  In compiling, I always get warnings
> about calls to functions named by uninterned symbols (see below).  I
> would think this indicates some kind of mismatch between UFFI and ACL
> or UFFI and elephant, but I don't have enough understand to inspect,
> much less propose a fix.
> 
> ; Fast
loading /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/serial
> izer.xfasl
> Warning: While compiling these undefined functions were referenced:
>          ELEPHANT::WITH-TRANSACTION-SQL from position 7258 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection
> s.lisp, 9085 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection
> s.lisp, 10024
>
in /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collect
> ions.lisp
>          :STORE-CONTROLLER-SQL from position 7258 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection
> s.lisp, 9085 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection
> s.lisp, 10024
>
in /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collect
> ions.lisp
>          ELEPHANT::SQL-REMOVE-FROM-ROOT from position 10715 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li
> sp
>          ELEPHANT::PERSISTENT-SLOT-BOUNDP-AUX from position 8117 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li
> sp, 9924 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li
> sp, 10239 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li
> sp
>          :DBCN-SPC from position 1523 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li
> sp
>          #:G3689 from position 51885 in
>            /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/berkeley-d
> b.lisp
>          #:G3616...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
>          ...
> 
> Finally, I think things are working enough to prototype making my
> knowledge base persistent.  Yet, I still get lots of segmentation
> faults and seeming configuration level errors such as "The slot SLOT1
> is missing from the object #<PFOO @ #x720bb22a> of class
> #<PERSISTENT-METACLASS PFOO> during operation SETF."  I'm mostly
> unclear as to why code which works inside a RT:DEFTEST doesn't always
> work at top level, or in my client code.  I seem to do a lot of
> deleting the database, stopping lisp, rebuilding elephant, and trying
> my example again.  I fear I'm corrupting either the BDB store, the
> local Lisp connection to it, and/or CLOS with my missteps.  Symptoms
> are things like 

I have sometimes had to do restart and executed the BDB command
"db_restore".  During development, this generally happens when I 
have a bug that thows me into the debugger.  I suspect it 
happens when a transaction is interrupted.  That is also a 
possible difference between the RT tests and whatever you are
doing.

> 
> Do you have any semi-large applications of ELE-BDB with CLOS?  I am
> kind of looking for a best practices template to follow.

No, I do not -- perhaps someone can mention or contribute one?

I have a large application of my own but I use it with PostGres, 
and I furthermore the way in which it uses Elephant is restricted
compared to very generally operating on slots in a CLOS operation.


> 
> Is it a wart or a feature that SLOT-VALUE and CLOS accessors return
> three values?
> 
> TCE(13): abs
> #<CONCEPT @ #x71edc4ea>
> TCE(14): (class-of abs)
> #<PERSISTENT-METACLASS CONCEPT>
> TCE(15): (name abs)
> "O4||ABSOLUTE"
> 12
> 24
> TCE(16): (slot-value abs 'name)
> "O4||ABSOLUTE"
> 12
> 24
> 
> It seems to me that the following sequence of actions results in a DB
> that you cannot add anything to or read anything from (i.e., until you
> recreate package X).
> 
> 1. Start elephant, open store
> 2. create lisp package X
> 3. put a symbol X::Y into the database
> 4. close store
> 5. restart lisp, elephant, open store
> 6. don't create lisp package X
> 7. Try to access the database -> error
> 
> Is this an intended behavior? (I'll try not create packages X with
> forgettable names in future).

I think this is an example of not having good enough error handling.
Yes, it is a problem that if you try to read an object in and
the package does not exist, it can't be constructed.  The same
is true of the class definition as well.
> 
> In any case, when reading X::Y from the store back into Lisp, if X is
> not available, I think a better error message than "NIL is not a
> package" would be a good idea.

Yes, I think we can improve the robustness along the lines
that you suggest.

> 
> Plodding ahead,
> Andrew
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20060110/39a9911c/attachment.html>


More information about the elephant-devel mailing list