13 Oct 09:17
28 Sep 18:52
Migration and derived slots
With the latest Git revision on SBCL 1.0.51, when trying to migrate objects that have a derived slot, elephant tries to call setf slot-value-using-class on the derived slot, resulting in an error : "Cannot write computed (derived) slot... for read/index retrieval only". It seems to me that copy-persistent-slots shouldn't try to write derived slots, as the work will be done when (setf slot-value-using-class) is called on the slots the derived function depends on. So I tried to patch the code for that (see attached patch). This seems to do the trick in that the migration works. I stumble upon another problem though : the derived slots are unbound after migration. Apparently, update-derived-slots is called when copying slot values, but derived-slots-trigger seems to always return nil... I don't get why. Here's my test case if anyone is interested (notice that I need to require bordeaux-threads manually, which is probably a small dependency bug ?). The first describe shows c=3, as expected, while the second describe shows c unbound. (require 'elephant) (require 'bordeaux-threads) (use-package 'elephant) (defvar *store1* (open-store '(:BDB "store1"))) (defvar *store2* (open-store '(:BDB "store2")))(Continue reading)
28 Sep 02:19
Reason for
Anyone remember why we put this into the elephant.asd file? I think the goal was to force some action to take place so that all the dynamic libraries were loaded each time. It was causing the CCL MOP problem discussed earlier. I may have fixes for the CCL MOP - a few tests still fail which I will diagnose later. Part of the win is removing the following line from elephant.asd, but I'm sure I'm casing a regression against another use case this was intended to handle. (defmethod operation-done-p ((o load-op) (c elephant-c-source)) nil) Thank you, Ian
20 Sep 09:46
Multiple store controllers, with each its own set of classes
Hi all, I'm trying to use two (BDB) store controllers, each with its own set of persistent classes. The reason is that I want to be able to modify the secondary store outside the application (it's read-only within it) and just plug-in a modified version (close-store, change directory, open-store) at some point without affecting the rest of the data. If I just use a let binding to set *store-controller* to the secondary store around make-instance and get-instances-by-class, everything works, except I can see the class index is stored in the main store-controller, which is not good, as I want the secondary store to be independant. If I set the global *store-controller* to the secondary controller after having opened both, and even close the first one to make sure before I call defpclass or any other elephant function, the class index is created in the right store-controller this time, but I get a new one each time I open the store (empty btree with a new oid). I have tried understanding and tracing the related parts of code, but that part is not exactly easy to dive in for an elephant noob, so I was hoping that someone familiar with the code could explain what's happening, or that someone would have a trick for using multiple store controllers in this fashion. Thanks a lot, Arnaud
14 Sep 16:39
status update
Recent patches: * set-valued slot tests, optimized postmodern support * test-slot-sets enabled in asd test-slot-sets thoroughly verifies current behaviour (rather weird) optimized postmodern support uses pm-pset for backend storage which keeps everything in one btree (database table) * disabled testconditions * fixes FINISHES macro in tests * prevent loading same foreign library (and stuff which "depends" on it) * with-interrupts for db-postmodern * pm-cursor typo fixed * import class-direct-subclasses Current status: two tests fail both on SBCL 1.0.16 and CCL 1.7: 1. ELEPHANT-DB-PATH-TEST -- as I understand, both tests and function ELEPHANT-DB-PATH are buggy as test comments do not quite match function's behaviour. I do not quite get how it was supposed to work, so I'll leave it as it is for now. I don't quite get why we got this failure only now, perhaps reshuffling enabled tests which were not run previously (problems from migration to fiveam) 2. CACHING-STYLE-REQUIRED -- I guess some MOP code which handles option inheritance is broken (or does not exist). INHIBIT-ROLLBACK test in testconditions crashes both CCL and SBCL, as I've mentioned previously, but I've disabled it for now. (I have no idea(Continue reading)
14 Sep 14:30
bugs in tests
It turns out that for compatibility with RT deftest we redefine 5am:finishes (not shadowing it) into something which is supposed to work with deftest -- it returns NIL if there was error and T otherwise. There are three problems with it: 1. if `finishes` is in a middle of deftest its output is ignored, i.e. it is OK even if there was an ERROR. 2. it just doesn't work in 5am:test, even if you spelled it 5am:finishes 3. And the worst part is that it eats CONDITION as if test was successful. And there are conditions which are worse than errors: memory corruption, etc. And this is what happened with inhibit-rollback test -- it crashes CCL and makes SBCL signaling memory error. Besides that, it turns out that cached-test-inherit-ok part of caching-style-required did not work, i.e. :cache-style is not inherited.
12 Sep 17:26
set-valued slots review
I. RATIONALE
There is a number of cases where one might want to store more than one
value in a slot. An example from our testassociations: person can hold
multiple jobs, job can have multiple holders.
There is a number of ways how you can hold these multiple values in a
single slot:
1. Lisp collection like list or array. It is serialized as a whole, so
you need to be careful to update slot after manipulations. If there are
many items and list is frequently updated it is less than perfect.
2. Associations: it is, perhaps, ideal when you have relationship
between classes. (I'll cover it in another message.)
3. pset (or btree): just assign pset instance to slot, then use pset API
functions on it.
4. New slot-valued slot feature.
So how what is it? It is very similar to storing pset in a slot, and in
fact it is implemented as a pset under the hood, with a number of
differences:
1. There are convenience macros like set-insert and set-remove which
combine slot-value with pset function. But you can use them on
pset-in-a-slot too, so it is not really a difference.
2. On-demand ("lazy") initialization -- object is created with an
unbound slot and it is created on first access. So it can save space
(and time) if set is empty.
(Continue reading)
9 Sep 12:23
CL implementation support
It looks like something weird happens with CCL's CLOS when we load Elephant. Given that we have openmcl-mop-patches.lisp, it might be that we break something with out patches. Or something... Is anybody interested in Elephant on CCL? Or other CL implementations? If not, it will be SBCL-only until somebody enthusiastic enough comes and fixes problems.
6 Sep 12:34
5 Sep 16:10
status update on db-postmodern
I've fixed problem with db-postmodern, now it passes almost all tests on SBCL 1.0.16 (except NIL-SLOT-CLASS). The problem was that with-btree-cursor using WITHOUT-INTERRUPTS while making cursor to prevent potential resource leak, but POSTMODERN depends on interrupts for socket communications (select). I've fixed this problem through use of ALLOW-WITH-INTERRUPTS in ele:WITHOUT-INTERRUPTS -- it allows re-enabling interrupts -- and WITH-INTERRUPTS around code which works with DB. This is SBCL-specific solutions, but we don't support WITHOUT-INTERRUPTS on other implementations anyway. (Well, we have it for AllegroCL but I don't support it.) Other possible solution is to remove WITHOUT-INTERRUPTS, I don't see much value in preventing resource leaks when people cancel threads through signals. Canceling threads sucks. ... There is still a potential problem with select being called when interrupts are disabled: schema-related functions which access DB might be called while compiling/loading code, and SBCL has internal WITHOUT-INTERRUPTS around code which calls our code. But, well, it works anyway.Problem might happen only when you're loading/compiling code, so if it already works it should be fine.
23 Aug 16:41
Re: SBCL errors
Nikodemus, you can do the following to test the BDB backend, assuming that you have the BDB libs installed and your my-config.sexp* setup: (asdf:operate 'asdf:load-op :elephant) (asdf:operate 'asdf:load-op :ele-bdb) (asdf:operate 'asdf:load-op :elephant-tests) (in-package "ELEPHANT-TESTS") (setq *default-spec* *testbdb-spec*) (do-backend-tests) After each test, you will want to clear out the test repo by changing to the elephant tests directory and running a script: cd /usr/local/lib/sbcl/site/elephant-1.0/tests sh ./delscript.sh Cheers, Kevin * my-config.sexp goes in the elephant distribution root, in my case /usr/local/lib/sbcl/site/elephant-1.0/my-config.sexp. On Ubuntu 10.04, with libdb4.7, libdb4.7-dev and db4.7-util packages installed, my-config.sexp should look like: ((:compiler . :gcc) (:berkeley-db-version . "4.7") (:berkeley-db-include-dir . "/usr/include/") (:berkeley-db-lib-dir . "/usr/lib/") (:berkeley-db-lib . "/usr/lib/libdb-4.7.so") (:berkeley-db-deadlock . "/usr/bin/db4.7_deadlock")(Continue reading)
RSS Feed