<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.lisp.elephant.devel">
    <title>gmane.lisp.elephant.devel</title>
    <link>http://blog.gmane.org/gmane.lisp.elephant.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2531"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2530"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2523"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2520"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2515"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2514"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2513"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2511"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2505"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2504"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2503"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2498"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2497"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2496"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2495"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2487"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2484"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2481"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2466"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.elephant.devel/2452"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2531">
    <title>failures with asdf3</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2531</link>
    <description>&lt;pre&gt;Dear Lisp hacker(s),

ASDF3 now checks deferred warnings by default.
On SBCL, this means that it will treat as an error
any undeclared free variable, including forward references to special variables
as well as any undefined function that isn't defined by the end of the system.

Using cl-test-grid to compile all the systems in quicklisp,
we found the following failure on a system we believe you maintain.
Can you please fix it?

—♯ƒ • François-René ÐVB Rideau •Reflection&amp;amp;Cybernethics• http://fare.tunes.org
Not only is there no contradiction between egoism and altruism, but no
altruism is possible without egoism - for what betterment to wish to an other
person devoid of selfish desire, to whom any change is indifferent?


elephant-tests
http://cl-test-grid.appspot.com/blob?key=aolorltuuv

dcm
http://cl-test-grid.appspot.com/blob?key=cs137uooya

_______________________________________________
elephant-devel site list
elephant-devel&amp;lt; at &amp;gt;common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-d&lt;/pre&gt;</description>
    <dc:creator>Faré</dc:creator>
    <dc:date>2013-02-21T05:13:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2530">
    <title>Slot ELEPHANT::SCHEMA-NAME-INDEX unbound error</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2530</link>
    <description>&lt;pre&gt;Hello,

I've been using ELEPHANT (from Quicklisp) for one particular project and 
noticed a lot of errors.

About the CLP backend, I'm getting this error:

The slot ELEPHANT::SCHEMA-NAME-INDEX is unbound in the object 
#&amp;lt;CLP-CONTROLLER /home/gugamilare/test/&amp;gt;.

All I am doing is:

CL-USER&amp;gt; (open-store '(:clp "/home/gugamilare/test/"))
#&amp;lt;CLP-CONTROLLER /home/gugamilare/test/&amp;gt;
CL-USER&amp;gt; (defpclass foo ()
            ((foos :accessor foos-of :initform nil)))
#&amp;lt;PERSISTENT-METACLASS FOO&amp;gt;
CL-USER&amp;gt; (add-to-root :foo1 (make-instance 'foo))
#&amp;lt;FOO oid:6&amp;gt;
CL-USER&amp;gt; (close-store)
NIL

;;; Restart Lisp...

CL-USER&amp;gt; (defpclass foo ()
            ((foos :accessor foos-of :initform nil)))
#&amp;lt;PERSISTENT-METACLASS FOO&amp;gt;
CL-USER&amp;gt; (open-store '(:clp "/home/gugamilare/test/"))
; Evaluation aborted on #&amp;lt;UNBOUND-SLOT SCHEMA-NAME-INDEX {1004F3EAE3}&amp;gt;.


Berkeley DB seems a bit off to me, since I'd have to manually download 
the version 4.7, so CLSQL is the only one which works for me now.

Regards,
Gustavo

&lt;/pre&gt;</description>
    <dc:creator>Gustavo Milaré</dc:creator>
    <dc:date>2013-02-08T23:40:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2523">
    <title>Migration and derived slots</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2523</link>
    <description>&lt;pre&gt;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 &lt;/pre&gt;</description>
    <dc:creator>Arnaud Betremieux</dc:creator>
    <dc:date>2011-09-28T16:52:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2520">
    <title>Reason for</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2520</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Ian Eslick</dc:creator>
    <dc:date>2011-09-28T00:19:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2515">
    <title>Multiple store controllers,with each its own set of classes</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2515</link>
    <description>&lt;pre&gt;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 rel&lt;/pre&gt;</description>
    <dc:creator>Arnaud Betremieux</dc:creator>
    <dc:date>2011-09-20T07:46:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2514">
    <title>status update</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2514</link>
    <description>&lt;pre&gt;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 --&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-14T14:39:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2513">
    <title>bugs in tests</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2513</link>
    <description>&lt;pre&gt;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.


&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-14T12:30:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2511">
    <title>set-valued slots review</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2511</link>
    <description>&lt;pre&gt;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 u&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-12T15:26:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2505">
    <title>CL implementation support</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2505</link>
    <description>&lt;pre&gt;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.


&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-09T10:23:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2504">
    <title>Are there any postmodern backend users here?</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2504</link>
    <description>&lt;pre&gt;I would like to discuss handling of types, i.e. integer/string keys 
which support range queries (and work faster).

There is a couple of options for handling type mismatches, I want to 
consider possible applications.


&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-06T10:34:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2503">
    <title>status update on db-postmodern</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2503</link>
    <description>&lt;pre&gt;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, an&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-09-05T14:10:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2498">
    <title>patches</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2498</link>
    <description>&lt;pre&gt;I've pushed both my patches and fix posted by Nikodemus.

These ones fix general elephant functionality, so code review is welcome:

   * default-pset workaround
   * removed unnecessary MOP manipulations for SBCL (as reported by N. 
Siivola)
   * fix dropping instance with derived index
   * derived index rebuilding, inherited index rebuilding
   * different handling of ensure-schema and compute-derived-index-triggers

These ones are specific to db-postmodern:

   * pset fix
   * pm-pset
   * in place upgrade support


&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-08-19T15:51:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2497">
    <title>memory problems with elephant in a multi-threadedsbcl-system</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2497</link>
    <description>&lt;pre&gt;
Hi list,

I've a problem with elephant and threading that drives me to despair. In the hope that anyone solved similar problems and may suggest a solution I am posting this thread.

I am running the latest darcs version of elephant on a 64 bit debian dual-core system on sbcl 1.0.40.0.debian with berkeley db 4.7.25.

The last days I ran a performance test on our system. Since the system is multi-threaded and we use transactions, we also use mutexes to synchronize the write and read operations (our mutex synchronisation is working!). The test I performed has only read the storage, i.e. clients started a TCP connection and invoked a read operation on the system. If more than 4 clients/threads read concurrently the storage, the memory/swap of the server system was fully reserved by the SBCL process and not released after the requests.
The requested data we use is persisted by using defpclass on several class definitions.

During my tests I made the following observations:
* the more intensive the algorithm and &lt;/pre&gt;</description>
    <dc:creator>Lukas Georgieff</dc:creator>
    <dc:date>2011-08-04T13:07:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2496">
    <title>SBCL errors</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2496</link>
    <description>&lt;pre&gt;I am getting errors with SBCL on a few tests;  I am using 1.0.50 and I
have patched elephant with Nikodemus' SBCL patch.  Has anyone else seen
these?

 Did 505 checks.
    Pass: 500 (99%)
    Skip: 1 ( 0%)
    Fail: 4 ( 0%)

 Failure Details:
 --------------------------------
 SIMPLE-EXPLICIT-ASSOC-SETUP []:
      Unexpected Error: #&amp;lt;SB-INT:BUG "~&amp;lt; at &amp;gt;&amp;lt;failed AVER: ~2I~_~A~:&amp;gt;"
{1002E81E41}&amp;gt;
  failed AVER: NSLOTDS
This is probably a bug in SBCL itself. (Alternatively, SBCL might have been
corrupted by bad user code, e.g. by an undefined Lisp operation like
(FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe
Lisp code; or there might be a bug in the OS or hardware that SBCL is
running
on.) If it seems to be a bug in SBCL itself, the maintainers would like
to know
about it. Bug reports are welcome on the SBCL mailing lists, which you
can find
at &amp;lt;http://sbcl.sourceforge.net/&amp;gt;...
 --------------------------------
 --------------------------------
 CHANGE-CLASS2 []:
      Unexpected Error: #&amp;lt;S&lt;/pre&gt;</description>
    <dc:creator>Kevin Raison</dc:creator>
    <dc:date>2011-07-29T05:05:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2495">
    <title>Invitation to connect on LinkedIn</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2495</link>
    <description>&lt;pre&gt;LinkedIn
------------




    Eli Naeher requested to add you as a connection on LinkedIn:
  
------------------------------------------

Matthias,

I'd like to add you to my professional network on LinkedIn.

- Eli

Accept invitation from Eli Naeher
http://www.linkedin.com/e/-nvo87p-gq2tb5og-57/XJRBqECPwQJqnAancQ4FbOZYT35FEhCMWjsQygZYLySReD/blk/I1516119070_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnP0Tc3ANcjoNdj59bPdfcz1Fj31abPsRe30McP0PdjcLrCBxbOYWrSlI/EML_comm_afe/

View invitation from Eli Naeher
http://www.linkedin.com/e/-nvo87p-gq2tb5og-57/XJRBqECPwQJqnAancQ4FbOZYT35FEhCMWjsQygZYLySReD/blk/I1516119070_3/3dvc3sMej4Ndz4RckALqnpPbOYWrSlI/svi/


 
&lt;/pre&gt;</description>
    <dc:creator>Eli Naeher via LinkedIn</dc:creator>
    <dc:date>2011-07-13T21:38:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2487">
    <title>Looking for Elephant maintainers</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2487</link>
    <description>&lt;pre&gt;By the way, Hans Hubner appears to be looking for the Elephant maintainers
(apparently there is a dead email or something):

http://netzhansa.blogspot.com/2011/05/orphaned-projects-on-common-lispnet.html

&lt;/pre&gt;</description>
    <dc:creator>Elliott Slaughter</dc:creator>
    <dc:date>2011-05-15T21:43:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2484">
    <title>finalize-inheritance</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2484</link>
    <description>&lt;pre&gt;I've found the problem: finalize-inheritance is not always called on 
class updates (even when compute-slots is called). Spec says that it is 
called at least once somewhere between class being defined and 
instantiation of its instances, and that's it.

CCL calls it just once for class and never again:

Clozure Common Lisp Version 1.6-r14468M  (LinuxX8664)!
http://paste.lisp.org/display/121960

SBCL calls finalize-inheritance for redefined class (if it is finalized) 
but not for dependent classes.

http://paste.lisp.org/display/121960#2

So I think we cannot depend on finalize-inheritance to detect class 
redefinitions/updates.

What we can depend on, though? I'm not a MOP expert, but it looks like 
COMPUTE-SLOTS is ideal for slot-related stuff, like derived index triggers.

As for schema stuff, I don't know... But it looks like we care mostly 
about slots, and we don't need layout to be computed. So maybe we can 
move all class definition/redefinition/update related code to 
COMPUTE-SLOTS method (after sta&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-05-12T17:05:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2481">
    <title>topo sort?</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2481</link>
    <description>&lt;pre&gt;hi

I was inspecting code of rebuild-slot-indices and it looks like it has a 
problem with inherited indices (although it is not easy to reproduce it).

rebuild-slot-index drops index first. With inherited indices it tries to 
drop an index but fails (because it looks for index for this class 
rather than super class), so index is dropped only once (in the base 
class which has this inherited index).

But (I think) this works correctly only if base class's index is rebuild 
before subclass index. Otherwise index already populated with some 
entries will be dropped and so some instances will be lost.

E.g. if foo is base class which defines inherited slot/index bar and 
quux is subclass of foo it works correctly if foo is rebuilt before quux.

So I think we need to sort classes (topologically) in known-classes 
function to make sure that order is correct.

Or am I missing something?


&lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-05-09T13:17:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2466">
    <title>using one store with mutiple lisp instances</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2466</link>
    <description>&lt;pre&gt;
Hi,
I want to use one elephant (BDB) store that is used with two instances of sbcl in parallel. The documentation [1] says that "Transactions will ensure there is no interaction between processes.". Does this mean that I have to use the common methods to open the store (open-store '(:BDB "path-to-database")) and have to ensure that all database-operations are guarded by "with-transaction"?
Some time ago there was a mail with the subject "[elephant-devel] PANIC: fatal region error detected; run recovery‏" - I think it was a similar problem, Leslie answered that
that means "(open-store '(:BDB "path-to-database") :register t)" - I did not find this in the documentation?
Has someone any experience using elephant in that manner?

Best regards,
Lukas


1: http://common-lisp.net/project/elephant/doc/elephant.html#Multiple-Processes-and-Distributed-Applications       &lt;/pre&gt;</description>
    <dc:creator>Lukas Georgieff</dc:creator>
    <dc:date>2011-05-04T09:34:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2452">
    <title>How do I populate an index of a slot that was created later with values created before slot became indexed?</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2452</link>
    <description>&lt;pre&gt;After creating a lot of objects of a specific class I decided to change a
slot to be indexed. It did change, no old items were included in the index.
How can I populate the index with old values?
&lt;/pre&gt;</description>
    <dc:creator>Vassilis Radis</dc:creator>
    <dc:date>2011-04-28T12:48:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.elephant.devel/2447">
    <title>inherited indices</title>
    <link>http://comments.gmane.org/gmane.lisp.elephant.devel/2447</link>
    <description>&lt;pre&gt;Index inheritance is a nice feature for the case when you have several 
sub-classes inheriting from a common base class and you want to lookup 
instances by a slot value regadless of the sub-class.
E.g. if super-from and mega-frob inherit from frob base class you can look 
up any kind of frob by frob-id if it is inherited.

But what's about the case where you want to be able to do queries both among 
all subclasses and for a specific sub-class?

id slot is probably a bad example since it is likely to be unique, so let's 
say we have frob-style slot.

Sometimes I want get any kind of frob with a specific style:

  (ele:get-instances-by-value 'frob 'frob-style "vanilla")

Sometimes I want to get instances of a specific class with a certain 
property:

  (ele:get-instances-by-value 'super-frob 'frob-style "vanilla")

But if slot frob-style has inherited index it doesn't matter what specific 
class is passed to get-instances-by-value, it can return frobs and 
mega-frobs even if you're asking for super-frobs.

I &lt;/pre&gt;</description>
    <dc:creator>Alex Mizrahi</dc:creator>
    <dc:date>2011-04-26T21:12:11</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.elephant.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.elephant.devel</link>
  </textinput>
</rdf:RDF>
