<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
Dear Team and Andrew Philpot,<BR>
This long message from Andrew seemed worth including here.<BR>
Summary:<BR>
1) There are compiler warnings that we should fix<BR>
2) ACL is green on the tests<BR>
3) Some other problems are missing.<BR>
4) Andrew calls for a large example application.<BR>
5) Andrew identifies a place where our error handling needs to be improved.<BR>
All of this sound unpleasant, but is actually good: Andrew is identifying of<BR>
ways to improve the system, and despite these problems is (apparently<BR>
from his words below) actually becoming MORE confident that he<BR>
can use Elephant.<BR>
<BR>
Thank you, Andrew. I will try to get back to you in more detail later this<BR>
week.<BR>
<BR>
<BR>
<BR>
On Tue, 2006-01-10 at 12:28 -0800, Andrew Philpot wrote:<BR>
Before I step in a bucket again, can you make this very clear to me:<BR>
> <BR>
> With all the changes that you have mailed me, are the tests green<BR>
> under ACL? (barring the migration tests.)<BR>
> <BR>
> Most of the edits I sent you in the last couple of days correspond<BR>
> from my perspective to quality improvements, not to getting things to<BR>
> work. When I get compiler warnings, I usually address them just so I<BR>
> can see the "real" errors when they are signaled. I know some other<BR>
> developers can "see around" them better than I, so I don't <BR>
> <BR>
> A note on getting things to work: my build procedure is to always<BR>
> compile elephant itself (:force t), and then to loading clsql as well<BR>
> on top. This nearly eliminates undefined references. (The only one<BR>
> still missing is function :STORE-CONTROLLER-SQL). But this build<BR>
> workaround seems far from ideal, and restructuring the ASDF might be<BR>
> appropriate.<BR>
> <BR>
> (defun build-elephant ()<BR>
> ;; I have UFFI 1.4.6 installed in service of another<BR>
> ;; application which I can't tinker with<BR>
> (asdf:operate 'asdf:load-op :uffi157)<BR>
> (provide :uffi)<BR>
> (asdf:operate 'asdf:load-op :elephant :force t)<BR>
> (asdf:operate 'asdf:load-op :ele-bdb)<BR>
> (asdf:operate 'asdf:load-op :ele-clsql)<BR>
> (asdf:operate 'asdf:load-op :elephant-tests)<BR>
> (eval (read-from-string "(setq elephant-tests::*test-path-primary* <BR>
> \"/opt/elephant/tests/testdb\")"))<BR>
> (eval (read-from-string "(setq elephant-tests::*test-path-secondary* nil)"))<BR>
> (eval (read-from-string "(elephant-tests::do-all-tests-spec <BR>
> elephant-tests::*test-path-primary*)"))<BR>
> )<BR>
> <BR>
> Having said that, following the above I get:<BR>
> <BR>
> 5 out of 106 total tests failed: ELEPHANT-TESTS::MIGRATE1,<BR>
> ELEPHANT-TESTS::MIGRATE2, ELEPHANT-TESTS::MIGRATE3,<BR>
> ELEPHANT-TESTS::MIGRATE4, ELEPHANT-TESTS::MIGRATE5.<BR>
> <BR>
> Can I ask whether sleepycat::*elephant-lib-path* (used in a<BR>
> load-foreign-library call in sleepycat.lisp) is supposed to be the<BR>
> same object (presumably it is the same value) as<BR>
> elephant::*elephant-lib-path* defined in controller.lisp? I get a<BR>
> message that the former is not bound when I compile the sleepycat<BR>
> stuff. To my eye, it looks probable that this is another possibly<BR>
> inappropriate circular reference; shouldn't sleepycat per se be<BR>
> independent of the higher level elephant layer? I'm not setting the<BR>
> former at all right now, but perhaps I should be. What do you think<BR>
> of elephant (and possibly sleepycat) configuration file(s) which would<BR>
> group all this stuff in one place.<BR>
<BR>
I can't yet answer about how it should be set, but yes, I agree that<BR>
sleepycat.lisp ought in theory to be a pure interface to the sleepycat<BR>
API and therefore independent of the other code. Yes, you have<BR>
convinced me the configuration stuff should be rewritten and <BR>
streamlined.<BR>
<BR>
> <BR>
> I'm by no means a UFFI expert. In compiling, I always get warnings<BR>
> about calls to functions named by uninterned symbols (see below). I<BR>
> would think this indicates some kind of mismatch between UFFI and ACL<BR>
> or UFFI and elephant, but I don't have enough understand to inspect,<BR>
> much less propose a fix.<BR>
> <BR>
> ; Fast loading /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/serial<BR>
> izer.xfasl<BR>
> Warning: While compiling these undefined functions were referenced:<BR>
> ELEPHANT::WITH-TRANSACTION-SQL from position 7258 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection<BR>
> s.lisp, 9085 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection<BR>
> s.lisp, 10024<BR>
> in /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collect<BR>
> ions.lisp<BR>
> :STORE-CONTROLLER-SQL from position 7258 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection<BR>
> s.lisp, 9085 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collection<BR>
> s.lisp, 10024<BR>
> in /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/collect<BR>
> ions.lisp<BR>
> ELEPHANT::SQL-REMOVE-FROM-ROOT from position 10715 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li<BR>
> sp<BR>
> ELEPHANT::PERSISTENT-SLOT-BOUNDP-AUX from position 8117 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li<BR>
> sp, 9924 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li<BR>
> sp, 10239 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li<BR>
> sp<BR>
> :DBCN-SPC from position 1523 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/classes.li<BR>
> sp<BR>
> #:G3689 from position 51885 in<BR>
> /nfs/isd3/philpot/lisp/system/elephant/elephant-0.4.0/src/berkeley-d<BR>
> b.lisp<BR>
> #:G3616...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> ...<BR>
> <BR>
> Finally, I think things are working enough to prototype making my<BR>
> knowledge base persistent. Yet, I still get lots of segmentation<BR>
> faults and seeming configuration level errors such as "The slot SLOT1<BR>
> is missing from the object #<PFOO @ #x720bb22a> of class<BR>
> #<PERSISTENT-METACLASS PFOO> during operation SETF." I'm mostly<BR>
> unclear as to why code which works inside a RT:DEFTEST doesn't always<BR>
> work at top level, or in my client code. I seem to do a lot of<BR>
> deleting the database, stopping lisp, rebuilding elephant, and trying<BR>
> my example again. I fear I'm corrupting either the BDB store, the<BR>
> local Lisp connection to it, and/or CLOS with my missteps. Symptoms<BR>
> are things like <BR>
<BR>
I have sometimes had to do restart and executed the BDB command<BR>
"db_restore". During development, this generally happens when I <BR>
have a bug that thows me into the debugger. I suspect it <BR>
happens when a transaction is interrupted. That is also a <BR>
possible difference between the RT tests and whatever you are<BR>
doing.<BR>
<BR>
> <BR>
> Do you have any semi-large applications of ELE-BDB with CLOS? I am<BR>
> kind of looking for a best practices template to follow.<BR>
<BR>
No, I do not -- perhaps someone can mention or contribute one?<BR>
<BR>
I have a large application of my own but I use it with PostGres, <BR>
and I furthermore the way in which it uses Elephant is restricted<BR>
compared to very generally operating on slots in a CLOS operation.<BR>
<BR>
<BR>
> <BR>
> Is it a wart or a feature that SLOT-VALUE and CLOS accessors return<BR>
> three values?<BR>
> <BR>
> TCE(13): abs<BR>
> #<CONCEPT @ #x71edc4ea><BR>
> TCE(14): (class-of abs)<BR>
> #<PERSISTENT-METACLASS CONCEPT><BR>
> TCE(15): (name abs)<BR>
> "O4||ABSOLUTE"<BR>
> 12<BR>
> 24<BR>
> TCE(16): (slot-value abs 'name)<BR>
> "O4||ABSOLUTE"<BR>
> 12<BR>
> 24<BR>
> <BR>
> It seems to me that the following sequence of actions results in a DB<BR>
> that you cannot add anything to or read anything from (i.e., until you<BR>
> recreate package X).<BR>
> <BR>
> 1. Start elephant, open store<BR>
> 2. create lisp package X<BR>
> 3. put a symbol X::Y into the database<BR>
> 4. close store<BR>
> 5. restart lisp, elephant, open store<BR>
> 6. don't create lisp package X<BR>
> 7. Try to access the database -> error<BR>
> <BR>
> Is this an intended behavior? (I'll try not create packages X with<BR>
> forgettable names in future).<BR>
<BR>
I think this is an example of not having good enough error handling.<BR>
Yes, it is a problem that if you try to read an object in and<BR>
the package does not exist, it can't be constructed. The same<BR>
is true of the class definition as well.<BR>
> <BR>
> In any case, when reading X::Y from the store back into Lisp, if X is<BR>
> not available, I think a better error message than "NIL is not a<BR>
> package" would be a good idea.<BR>
<BR>
Yes, I think we can improve the robustness along the lines<BR>
that you suggest.<BR>
<BR>
> <BR>
> Plodding ahead,<BR>
> Andrew<BR>
>
</BODY>
</HTML>