From eslick at media.mit.edu  Sun Jun  1 15:16:32 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 1 Jun 2008 11:16:32 -0400
Subject: [elephant-devel] Clbuild
In-Reply-To: <200805111422.06254.bryan.emrys@gmail.com>
References: <AF2FA8DE-63BD-4FAF-BC0B-BB672A4AD95D@umich.edu>
	<11ACB1FC-8B1B-43A3-9C32-4051AC5BE3E2@media.mit.edu>
	<3EB34F54-754A-47B0-96FD-F0F7FB2ED924@umich.edu>
	<200805111422.06254.bryan.emrys@gmail.com>
Message-ID: <826BDA20-34DE-460B-AAEF-DAE32FFB1799@media.mit.edu>

Bryan,

Did we address these issues to your satisfaction for clbuild?

I just promoted a patch to our elephant-unstable branch (soon to be  
the main release) that provides a restart to create a my-config.sexp  
file.  If the user isn't warned explicitly, the consequences of a  
default my-config may be hard to track down, but this way we don't  
have to stop the build/load process until you load cl-sql or bdb  
backends.

Regards,
Ian

On May 11, 2008, at 5:22 PM, Bryan Emrys wrote:

> At one point the clbuild maintainers looked at elephant but had some  
> problems that prevented inclusion.
>
> Specifically:
>
> #  - needs sb-posix, but doesn't declare that dependency, meaning that
> #    it doesn't build even with a config file
> #  - ele-clsql loads clsql from the .asd file, not using :depends-on,
> #    which is completely unacceptable
> #    (we blacklist ele-clsql in clbuild.lisp because of that)
>
> Did anyone ever respond?
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From killerstorm at newmail.ru  Sun Jun  1 19:48:20 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Sun, 1 Jun 2008 22:48:20 +0300
Subject: [elephant-devel] unstable postmodern troubled..
Message-ID: <g1uue7$tu5$1@ger.gmane.org>

i can't say i'm completely stuck with it,
but i'm getting pretty weird errors -- it's
different if i run it first time or second time
(on second time there are more errors), and, if i run
whole test suite i get:

 SIMPLE-SLOT-ASSOC-SETUP []:
      Unexpected Error: #<SIMPLE-ERROR {C350169}>
There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION ELEPHANT::SCHEMA-ID (1)>
when called with arguments
  (NIL)...

but when i run test individually, it works:

ELE-TESTS> (do-test-spec 'SIMPLE-SLOT-ASSOC-SETUP)
.
 Did 1 check.
    Pass: 1 (100%)
    Skip: 0 ( 0%)
    Fail: 0 ( 0%)

NIL

so i thought maybe i'll post half-backed patches and someone
could help debugging it -- with such weird bugs more eyeballs
is always better.

also, few questions to Ian:

 * cursor-delete on dup-btree -- should it delete only current
pair or all pairs on some key?
 * why dup-btree has persistent-metaclass? (and so do some other btree 
flavours)
   if it don't use persistent-metaclass, drop-pobject fails for
  dup-btree, but other than that i can't see any reasons..
 why should dup-btree be different from normal btree?
 this might introduce some bloat, so if drop-pobject is the only
 reason, it might be easier to just add method specialization





From eslick at media.mit.edu  Mon Jun  2 01:28:00 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 1 Jun 2008 21:28:00 -0400
Subject: [elephant-devel] unstable postmodern troubled..
In-Reply-To: <g1uue7$tu5$1@ger.gmane.org>
References: <g1uue7$tu5$1@ger.gmane.org>
Message-ID: <C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>

Sounds like there is an issue with schema coherence (the class object  
cache out of sync with the db in some way?  I had some of these tuning  
the BDB implementation).  I'd be happy to look at the patches.

I think the semantics of cursor-delete are the current 'element'.  If  
I can do cursor-next to get to the next element of a duplicate set, I  
wouldn't expect it to have been deleted when I deleted the last one -  
so just the specific key-value pair that would be returned by cursor- 
current.

The indexed-btree is the only class that requires it due to the  
indices slot.  It would take quite a bit of work to handle all the  
issues that persistent-metaclass takes care of.  However, the btree,  
dup-btree, and btree-index don't need it.  I'll pull it out of the BDB  
implementation and test it.

Ian

On Jun 1, 2008, at 3:48 PM, Alex Mizrahi wrote:

> i can't say i'm completely stuck with it,
> but i'm getting pretty weird errors -- it's
> different if i run it first time or second time
> (on second time there are more errors), and, if i run
> whole test suite i get:
>
> SIMPLE-SLOT-ASSOC-SETUP []:
>      Unexpected Error: #<SIMPLE-ERROR {C350169}>
> There is no applicable method for the generic function
>  #<STANDARD-GENERIC-FUNCTION ELEPHANT::SCHEMA-ID (1)>
> when called with arguments
>  (NIL)...
>
> but when i run test individually, it works:
>
> ELE-TESTS> (do-test-spec 'SIMPLE-SLOT-ASSOC-SETUP)
> .
> Did 1 check.
>    Pass: 1 (100%)
>    Skip: 0 ( 0%)
>    Fail: 0 ( 0%)
>
> NIL
>
> so i thought maybe i'll post half-backed patches and someone
> could help debugging it -- with such weird bugs more eyeballs
> is always better.
>
> also, few questions to Ian:
>
> * cursor-delete on dup-btree -- should it delete only current
> pair or all pairs on some key?
> * why dup-btree has persistent-metaclass? (and so do some other btree
> flavours)
>   if it don't use persistent-metaclass, drop-pobject fails for
>  dup-btree, but other than that i can't see any reasons..
> why should dup-btree be different from normal btree?
> this might introduce some bloat, so if drop-pobject is the only
> reason, it might be easier to just add method specialization
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Mon Jun  2 01:51:18 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 1 Jun 2008 21:51:18 -0400
Subject: [elephant-devel] unstable postmodern troubled..
In-Reply-To: <C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
References: <g1uue7$tu5$1@ger.gmane.org>
	<C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
Message-ID: <06C2F9A6-9CD8-4A6F-838D-053E93D8FDF5@media.mit.edu>

Actually btree-index also needs to be persistent-metaclass because of  
its use of slot values.  However, dup-btree does not if that makes  
your life easier.  I pushed a patch to remove that from bdb- 
collections.  All tests pass under SBCL / Linux / BDB (my new primary  
dev platform).

Ian

On Jun 1, 2008, at 9:28 PM, Ian Eslick wrote:

> Sounds like there is an issue with schema coherence (the class  
> object cache out of sync with the db in some way?  I had some of  
> these tuning the BDB implementation).  I'd be happy to look at the  
> patches.
>
> I think the semantics of cursor-delete are the current 'element'.   
> If I can do cursor-next to get to the next element of a duplicate  
> set, I wouldn't expect it to have been deleted when I deleted the  
> last one - so just the specific key-value pair that would be  
> returned by cursor-current.
>
> The indexed-btree is the only class that requires it due to the  
> indices slot.  It would take quite a bit of work to handle all the  
> issues that persistent-metaclass takes care of.  However, the btree,  
> dup-btree, and btree-index don't need it.  I'll pull it out of the  
> BDB implementation and test it.
>
> Ian
>
> On Jun 1, 2008, at 3:48 PM, Alex Mizrahi wrote:
>
>> i can't say i'm completely stuck with it,
>> but i'm getting pretty weird errors -- it's
>> different if i run it first time or second time
>> (on second time there are more errors), and, if i run
>> whole test suite i get:
>>
>> SIMPLE-SLOT-ASSOC-SETUP []:
>>     Unexpected Error: #<SIMPLE-ERROR {C350169}>
>> There is no applicable method for the generic function
>> #<STANDARD-GENERIC-FUNCTION ELEPHANT::SCHEMA-ID (1)>
>> when called with arguments
>> (NIL)...
>>
>> but when i run test individually, it works:
>>
>> ELE-TESTS> (do-test-spec 'SIMPLE-SLOT-ASSOC-SETUP)
>> .
>> Did 1 check.
>>   Pass: 1 (100%)
>>   Skip: 0 ( 0%)
>>   Fail: 0 ( 0%)
>>
>> NIL
>>
>> so i thought maybe i'll post half-backed patches and someone
>> could help debugging it -- with such weird bugs more eyeballs
>> is always better.
>>
>> also, few questions to Ian:
>>
>> * cursor-delete on dup-btree -- should it delete only current
>> pair or all pairs on some key?
>> * why dup-btree has persistent-metaclass? (and so do some other btree
>> flavours)
>>  if it don't use persistent-metaclass, drop-pobject fails for
>> dup-btree, but other than that i can't see any reasons..
>> why should dup-btree be different from normal btree?
>> this might introduce some bloat, so if drop-pobject is the only
>> reason, it might be easier to just add method specialization
>>
>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From varuzza at gmail.com  Mon Jun  2 03:44:27 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Mon, 2 Jun 2008 00:44:27 -0300
Subject: [elephant-devel] Problem with errno in %DB-ENV-CREATE
Message-ID: <5d9c2e640806012044t26c88aecs24bd421b50ce857f@mail.gmail.com>

Hello,

If I change the declaim in the top of berkeley-db.lisp to (safety 3)
(debug 3), I got this error from SBCL 1.0.17 on AMD64:

invalid number of arguments: 1
   [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]

Restarts:
  0: [ABORT-REQUEST] Abort handling SLIME request.
  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{10033483B1}>)

Backtrace:
  0: (DB-BDB::%DB-ENV-CREATE 0)[:EXTERNAL]
  1: (DB-BDB::DB-ENV-CREATE)


Using the normal optimization settings I got the error:

Unhandled memory fault at #x4020002.

Which is exactly the address of the variable errno in the C-function
db_env_cr.  Maybe the error is caused by 64 C code.

Anybody is using elephant in a 64 machine?

-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From leslie.polzer at gmx.net  Mon Jun  2 09:04:00 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Mon, 2 Jun 2008 11:04:00 +0200 (CEST)
Subject: [elephant-devel] Dropping objects
Message-ID: <64877.88.73.241.88.1212397440.squirrel@mail.stardawn.org>


Err, any specific reason why we have DROP-POBJECT and DROP-INSTANCES?
It would be more orthogonal to have one function for deleting objects.

  Leslie




From eslick at media.mit.edu  Mon Jun  2 12:48:57 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 2 Jun 2008 08:48:57 -0400
Subject: [elephant-devel] Dropping objects
In-Reply-To: <64877.88.73.241.88.1212397440.squirrel@mail.stardawn.org>
References: <64877.88.73.241.88.1212397440.squirrel@mail.stardawn.org>
Message-ID: <894FC583-FC46-4C1E-B668-32259EFDA67A@media.mit.edu>

I'm not sure of the history of this distinction - but I updated the  
API to use drop-instance and drop-instances.  I also exported drop- 
instance-slots to delete persistent storage without dropping/ 
invalidating the instance itself.

Ian

On Jun 2, 2008, at 5:04 AM, Leslie P. Polzer wrote:i

>
> Err, any specific reason why we have DROP-POBJECT and DROP-INSTANCES?
> It would be more orthogonal to have one function for deleting objects.
>
>  Leslie
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Mon Jun  2 13:18:21 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 2 Jun 2008 09:18:21 -0400
Subject: [elephant-devel] Problem with errno in %DB-ENV-CREATE
In-Reply-To: <5d9c2e640806012044t26c88aecs24bd421b50ce857f@mail.gmail.com>
References: <5d9c2e640806012044t26c88aecs24bd421b50ce857f@mail.gmail.com>
Message-ID: <6C191992-AC8F-4A4E-B135-DE7173B62860@media.mit.edu>

Just to ask the basic questions.  Which BDB are you using and does  
your my-config.sexp match that version?

Ian

On Jun 1, 2008, at 11:44 PM, Leonardo Varuzza wrote:

> Hello,
>
> If I change the declaim in the top of berkeley-db.lisp to (safety 3)
> (debug 3), I got this error from SBCL 1.0.17 on AMD64:
>
> invalid number of arguments: 1
>   [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
>
> Restarts:
>  0: [ABORT-REQUEST] Abort handling SLIME request.
>  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
> {10033483B1}>)
>
> Backtrace:
>  0: (DB-BDB::%DB-ENV-CREATE 0)[:EXTERNAL]
>  1: (DB-BDB::DB-ENV-CREATE)
>
>
> Using the normal optimization settings I got the error:
>
> Unhandled memory fault at #x4020002.
>
> Which is exactly the address of the variable errno in the C-function
> db_env_cr.  Maybe the error is caused by 64 C code.
>
> Anybody is using elephant in a 64 machine?
>
> -- 
> The most fundamental particles in this product are held together by a
> "gluing" force about which little is currently known and whose
> adhesive power can therefore not be permanently guaranteed.
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From killerstorm at newmail.ru  Mon Jun  2 20:47:36 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Mon, 2 Jun 2008 23:47:36 +0300
Subject: [elephant-devel] Re: unstable postmodern troubled..
References: <g1uue7$tu5$1@ger.gmane.org>
	<C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
Message-ID: <g21m9d$7hi$1@ger.gmane.org>

 IE> Sounds like there is an issue with schema coherence (the class object
 IE> cache out of sync with the db in some way?  I had some of these tuning
 IE> the BDB implementation).

i've found the issue -- postmodern backend creates its "system" btrees
(like root, schema-table etc) in "fancy" way, so it cannot simply 
deserialize
them if something in DB refers to it, so it depends on object cache.

but some tests call flush-instance-cache, so db-postmodern gets broken.

i'm not sure what is the idea behind "special" btrees.. probably it will
work fine without this special stuff, but i'd prefer not to touch them :),
so i'll better specialize flush-instance-cache to ensure system btrees
are cached after flush.

seems to be passing all tests now, ha! 





From eslick at media.mit.edu  Mon Jun  2 21:43:05 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 2 Jun 2008 17:43:05 -0400
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <g21m9d$7hi$1@ger.gmane.org>
References: <g1uue7$tu5$1@ger.gmane.org>
	<C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
	<g21m9d$7hi$1@ger.gmane.org>
Message-ID: <A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>

Fantastic!  Thanks for all the work on this.  Now I have no excuse to  
start the long list of little items necessary to get to a release...

The big areas are:
- Thread safety for all schema-related operations
- Test coverage
- Docs coverage

Some bugs I've seen and haven't been able to fix:
- Leslie's BDB bug on unstable
- BDB on AMD 64

Anything else?

I think Glenn was going to help us out with a little organization of  
this list vis-a-vis documentation?  The missing tests are roughly the  
same as the missing doc sections, so we can come up with a list of  
tests from that.

Anyone want to do a thread-safety review of the schema code?  A fresh  
pair of eyes is usually much better for this than the developer as  
recent e-mails have shown.  However, I'll take a first pass before too  
long.

Thanks,
Ian

On Jun 2, 2008, at 4:47 PM, Alex Mizrahi wrote:

> IE> Sounds like there is an issue with schema coherence (the class  
> object
> IE> cache out of sync with the db in some way?  I had some of these  
> tuning
> IE> the BDB implementation).
>
> i've found the issue -- postmodern backend creates its "system" btrees
> (like root, schema-table etc) in "fancy" way, so it cannot simply
> deserialize
> them if something in DB refers to it, so it depends on object cache.
>
> but some tests call flush-instance-cache, so db-postmodern gets  
> broken.
>
> i'm not sure what is the idea behind "special" btrees.. probably it  
> will
> work fine without this special stuff, but i'd prefer not to touch  
> them :),
> so i'll better specialize flush-instance-cache to ensure system btrees
> are cached after flush.
>
> seems to be passing all tests now, ha!
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Mon Jun  2 21:45:06 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 2 Jun 2008 17:45:06 -0400
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
References: <g1uue7$tu5$1@ger.gmane.org>
	<C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
	<g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
Message-ID: <1E9CD088-7FE3-467A-B410-771A4E7FE354@media.mit.edu>

When the Trac web interface is back online, we can keep a list of  
todo's there as part of the bug tracking system.

We also need to test upgrade from 0.9.1.

I forget if we had figured out what to call this release.  Opinions?

Ian

On Jun 2, 2008, at 5:43 PM, Ian Eslick wrote:

> Fantastic!  Thanks for all the work on this.  Now I have no excuse  
> to start the long list of little items necessary to get to a  
> release...
>
> The big areas are:
> - Thread safety for all schema-related operations
> - Test coverage
> - Docs coverage
>
> Some bugs I've seen and haven't been able to fix:
> - Leslie's BDB bug on unstable
> - BDB on AMD 64
>
> Anything else?
>
> I think Glenn was going to help us out with a little organization of  
> this list vis-a-vis documentation?  The missing tests are roughly  
> the same as the missing doc sections, so we can come up with a list  
> of tests from that.
>
> Anyone want to do a thread-safety review of the schema code?  A  
> fresh pair of eyes is usually much better for this than the  
> developer as recent e-mails have shown.  However, I'll take a first  
> pass before too long.
>
> Thanks,
> Ian
>
> On Jun 2, 2008, at 4:47 PM, Alex Mizrahi wrote:
>
>> IE> Sounds like there is an issue with schema coherence (the class  
>> object
>> IE> cache out of sync with the db in some way?  I had some of these  
>> tuning
>> IE> the BDB implementation).
>>
>> i've found the issue -- postmodern backend creates its "system"  
>> btrees
>> (like root, schema-table etc) in "fancy" way, so it cannot simply
>> deserialize
>> them if something in DB refers to it, so it depends on object cache.
>>
>> but some tests call flush-instance-cache, so db-postmodern gets  
>> broken.
>>
>> i'm not sure what is the idea behind "special" btrees.. probably it  
>> will
>> work fine without this special stuff, but i'd prefer not to touch  
>> them :),
>> so i'll better specialize flush-instance-cache to ensure system  
>> btrees
>> are cached after flush.
>>
>> seems to be passing all tests now, ha!
>>
>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From varuzza at gmail.com  Mon Jun  2 22:43:55 2008
From: varuzza at gmail.com (Leonardo Varuzza)
Date: Mon, 2 Jun 2008 19:43:55 -0300
Subject: [elephant-devel] Problem with errno in %DB-ENV-CREATE
In-Reply-To: <6C191992-AC8F-4A4E-B135-DE7173B62860@media.mit.edu>
References: <5d9c2e640806012044t26c88aecs24bd421b50ce857f@mail.gmail.com>
	<6C191992-AC8F-4A4E-B135-DE7173B62860@media.mit.edu>
Message-ID: <5d9c2e640806021543r5d54c818xe57c0c4472ae1905@mail.gmail.com>

I'm using BDB 4.6 with this my-config.sexp

;; Linux defaults
#+(and (or sbcl allegro openmcl lispworks) (not (or mswindows
windows)) (not (or macosx darwin)))
((:compiler . :gcc)
 (:berkeley-db-version . "4.6")
 (:berkeley-db-include-dir . "/usr/include/")
 (:berkeley-db-lib-dir . "/usr/lib/")
 (:berkeley-db-lib . "/usr/lib/libdb-4.6.so")
 (:berkeley-db-deadlock . "/usr/bin/db4.6_deadlock")
 (:berkeley-db-cachesize . 20971520)
 (:berkeley-db-map-degree2 . t)
 (:clsql-lib-paths . nil)
 (:prebuilt-libraries . nil))


On Mon, Jun 2, 2008 at 10:18 AM, Ian Eslick <eslick at media.mit.edu> wrote:
> Just to ask the basic questions.  Which BDB are you using and does your
> my-config.sexp match that version?
>
> Ian
>
> On Jun 1, 2008, at 11:44 PM, Leonardo Varuzza wrote:
>
>> Hello,
>>
>> If I change the declaim in the top of berkeley-db.lisp to (safety 3)
>> (debug 3), I got this error from SBCL 1.0.17 on AMD64:
>>
>> invalid number of arguments: 1
>>  [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
>>
>> Restarts:
>>  0: [ABORT-REQUEST] Abort handling SLIME request.
>>  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
>> {10033483B1}>)
>>
>> Backtrace:
>>  0: (DB-BDB::%DB-ENV-CREATE 0)[:EXTERNAL]
>>  1: (DB-BDB::DB-ENV-CREATE)
>>
>>
>> Using the normal optimization settings I got the error:
>>
>> Unhandled memory fault at #x4020002.
>>
>> Which is exactly the address of the variable errno in the C-function
>> db_env_cr.  Maybe the error is caused by 64 C code.
>>
>> Anybody is using elephant in a 64 machine?
>>
>> --
>> The most fundamental particles in this product are held together by a
>> "gluing" force about which little is currently known and whose
>> adhesive power can therefore not be permanently guaranteed.
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>



-- 
The most fundamental particles in this product are held together by a
"gluing" force about which little is currently known and whose
adhesive power can therefore not be permanently guaranteed.


From eslick at media.mit.edu  Tue Jun  3 01:57:37 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 2 Jun 2008 21:57:37 -0400
Subject: [elephant-devel] (FIXED) Bug where btree/dup-btrees are "oid: nil"
	in SBCL/BDB
Message-ID: <95B226DC-693B-4BA6-AD23-0ED0BB50BD71@media.mit.edu>


Alex's recent question about why dup-btrees were persistent-metaclass  
along with a project of my own led me to the previously reported bug  
about deserializing btrees that had a nil in the oid slot.  This is  
related to the reason that dup-btrees were originally persistent- 
metaclass.

The class recreation protocol involves a generic function that  
dispatches on the class, not the instance, of the object to be  
recreated.  This means that 'persistent' vs. non-persistent isn't the  
easiest distinction to make.  The recreation function calls a special  
initialization for persistent-metaclass instances (i.e. oid & spec)  
which wasn't getting called for btree and dup-btree.

For now, I've added a call to initialize persistent in the controller  
recreation protocol to handle persistent-collections properly.  (for  
indexes and indexed-btrees this will get called twice).  I probably  
need to think through how to make this protocol cleaner since we  
really want to dispatch on (subtypep class 'persistent) at recreation  
time.

Anyway, this case is what led to the bug about oid:nil in btrees  
reported by Leslie and others earlier and the fix I just pushed should  
take care of that bug (which means Leslie should be able to start his  
testing of elephant-unstable again).

Ian




From leslie.polzer at gmx.net  Tue Jun  3 07:30:45 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Tue, 3 Jun 2008 09:30:45 +0200 (CEST)
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <1E9CD088-7FE3-467A-B410-771A4E7FE354@media.mit.edu>
References: <g1uue7$tu5$1@ger.gmane.org>
	<C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu>
	<g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
	<1E9CD088-7FE3-467A-B410-771A4E7FE354@media.mit.edu>
Message-ID: <63965.88.73.237.179.1212478245.squirrel@mail.stardawn.org>


> I forget if we had figured out what to call this release.  Opinions?

Didn't we agree to have this as 1.0?

Or are there still other issues that need to be solved until then?

  Leslie



From gtarcea at umich.edu  Tue Jun  3 13:19:06 2008
From: gtarcea at umich.edu (V. Glenn Tarcea)
Date: Tue, 3 Jun 2008 09:19:06 -0400
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
References: <g1uue7$tu5$1@ger.gmane.org><C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu><g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
Message-ID: <009301c8c57c$669b27c0$4212a8c0@mimi2>

Yup, I'll be helping on the docs. I'm running silent but watching the
emails. I'll have more time to help out with things in about 2 weeks (end of
spring semester)

Is there a goal date for the next release?

Glenn 

-----Original Message-----
From: elephant-devel-bounces at common-lisp.net
[mailto:elephant-devel-bounces at common-lisp.net] On Behalf Of Ian Eslick
Sent: Monday, June 02, 2008 5:43 PM
To: Elephant bugs and development
Subject: Re: [elephant-devel] Re: unstable postmodern troubled..

Fantastic!  Thanks for all the work on this.  Now I have no excuse to  
start the long list of little items necessary to get to a release...

The big areas are:
- Thread safety for all schema-related operations
- Test coverage
- Docs coverage

Some bugs I've seen and haven't been able to fix:
- Leslie's BDB bug on unstable
- BDB on AMD 64

Anything else?

I think Glenn was going to help us out with a little organization of  
this list vis-a-vis documentation?  The missing tests are roughly the  
same as the missing doc sections, so we can come up with a list of  
tests from that.

Anyone want to do a thread-safety review of the schema code?  A fresh  
pair of eyes is usually much better for this than the developer as  
recent e-mails have shown.  However, I'll take a first pass before too  
long.

Thanks,
Ian

On Jun 2, 2008, at 4:47 PM, Alex Mizrahi wrote:

> IE> Sounds like there is an issue with schema coherence (the class  
> object
> IE> cache out of sync with the db in some way?  I had some of these  
> tuning
> IE> the BDB implementation).
>
> i've found the issue -- postmodern backend creates its "system" btrees
> (like root, schema-table etc) in "fancy" way, so it cannot simply
> deserialize
> them if something in DB refers to it, so it depends on object cache.
>
> but some tests call flush-instance-cache, so db-postmodern gets  
> broken.
>
> i'm not sure what is the idea behind "special" btrees.. probably it  
> will
> work fine without this special stuff, but i'd prefer not to touch  
> them :),
> so i'll better specialize flush-instance-cache to ensure system btrees
> are cached after flush.
>
> seems to be passing all tests now, ha!
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel

_______________________________________________
elephant-devel site list
elephant-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel




From eslick at media.mit.edu  Tue Jun  3 13:40:44 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 3 Jun 2008 09:40:44 -0400
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <009301c8c57c$669b27c0$4212a8c0@mimi2>
References: <g1uue7$tu5$1@ger.gmane.org><C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu><g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
	<009301c8c57c$669b27c0$4212a8c0@mimi2>
Message-ID: <52038A6E-0303-45FF-BB53-20F683822792@media.mit.edu>

End of June would be great - I think it's a bit of a stretch since I'm  
sure there are likely to be various issues cropping up.

I think that feature-wise we're ready for a 1.0, but in terms of  
documentation, use-cases, stability, etc. I'm inclining towards an  
intermediate release or two indicating that we're close so perhaps  
1.0beta1 or 0.9.9?

Major feature development should be moved to a separate branch at  
release time.

I'm also not inclined to promise a query system for 1.0.  To do a  
proper job I believe will require some additional changes to core  
functionality (although hopefully not the data stores or DB) such as  
keeping rough statistics over btree accesses for a query planner,  
etc.  I don't want to rush it.

So here's a proposal:
- Feature-freeze the current branch
- Focus entirely on testing and documentation through the end of June.
- Ensure that we've field tested the 0.9.1->1.0beta1 upgrade

- At the end of June, subject to Robert and I agreeing, we
   release a 1.0beta1 and fork a branch for post 1.0 features

- We'll keep pushing on testing, etc and do monthly 1.0betaX
   releases until we're happy.

Ian

On Jun 3, 2008, at 9:19 AM, V. Glenn Tarcea wrote:

> Yup, I'll be helping on the docs. I'm running silent but watching the
> emails. I'll have more time to help out with things in about 2 weeks  
> (end of
> spring semester)
>
> Is there a goal date for the next release?
>
> Glenn
>
> -----Original Message-----
> From: elephant-devel-bounces at common-lisp.net
> [mailto:elephant-devel-bounces at common-lisp.net] On Behalf Of Ian  
> Eslick
> Sent: Monday, June 02, 2008 5:43 PM
> To: Elephant bugs and development
> Subject: Re: [elephant-devel] Re: unstable postmodern troubled..
>
> Fantastic!  Thanks for all the work on this.  Now I have no excuse to
> start the long list of little items necessary to get to a release...
>
> The big areas are:
> - Thread safety for all schema-related operations
> - Test coverage
> - Docs coverage
>
> Some bugs I've seen and haven't been able to fix:
> - Leslie's BDB bug on unstable
> - BDB on AMD 64
>
> Anything else?
>
> I think Glenn was going to help us out with a little organization of
> this list vis-a-vis documentation?  The missing tests are roughly the
> same as the missing doc sections, so we can come up with a list of
> tests from that.
>
> Anyone want to do a thread-safety review of the schema code?  A fresh
> pair of eyes is usually much better for this than the developer as
> recent e-mails have shown.  However, I'll take a first pass before too
> long.
>
> Thanks,
> Ian
>
> On Jun 2, 2008, at 4:47 PM, Alex Mizrahi wrote:
>
>> IE> Sounds like there is an issue with schema coherence (the class
>> object
>> IE> cache out of sync with the db in some way?  I had some of these
>> tuning
>> IE> the BDB implementation).
>>
>> i've found the issue -- postmodern backend creates its "system"  
>> btrees
>> (like root, schema-table etc) in "fancy" way, so it cannot simply
>> deserialize
>> them if something in DB refers to it, so it depends on object cache.
>>
>> but some tests call flush-instance-cache, so db-postmodern gets
>> broken.
>>
>> i'm not sure what is the idea behind "special" btrees.. probably it
>> will
>> work fine without this special stuff, but i'd prefer not to touch
>> them :),
>> so i'll better specialize flush-instance-cache to ensure system  
>> btrees
>> are cached after flush.
>>
>> seems to be passing all tests now, ha!
>>
>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From killerstorm at newmail.ru  Wed Jun  4 11:53:41 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 14:53:41 +0300
Subject: [elephant-devel] Re: unstable postmodern troubled..
References: <g1uue7$tu5$1@ger.gmane.org><C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu><g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
Message-ID: <g25vob$j5o$1@ger.gmane.org>

here are patches for elephant-unstable.
it still doesn't work perfectly, errors are quite weird:
 odd test runs (1, 3..) work fine, but even ones (2, 4..)  complete with two 
errors, iirc UPDATE-CLASS
and INDEX-REDEFINE, something like that. i hope that are minor errors.
also some minor fixes are pending -- i.e. cursor-delete on dup-btree to 
delete only one row.

 IE> Anything else?

well, postmodern techinically supports (or is close to that) association and 
stuff,
but default-pset implementation for it is a joke -- it creates a new 
database table
for each pset. so it needs specialized pset implementation to be actually
usable. 


begin 666 pm-patch01.hunks
M"DYE=R!P871C:&5S. at H*6W!O<W1M;V1E<FXZ(&1U<"UB=')E90IA;&5X+FUI
M>G)A:&E 9VUA:6PN8V]M*BHR,# X,#8P-#$Q-#0Q-5T@>PIH=6YK("XO<W)C
M+V1B+7!O<W1M;V1E<FXO<&TM8G1R964M:6YD97 at N;&ES<" S"BTH9&5F8VQA
M<W,@<&TM8G1R964M:6YD97@@*&)T<F5E+6EN9&5X('!M+6)T<F5E*0HK*&1E
M9F-L87-S('!M+6)T<F5E+6EN9&5X("AB=')E92UI;F1E>"!P;2UD=7 M8G1R
M964I"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UB=')E92UI;F1E>"YL
M:7-P(#@*+2AD969M971H;V0 at 9'5P;&EC871E<RUA;&QO=V5D+7 @*"AB="!P
M;2UB=')E92UI;F1E>"DI"BT@('0I"BT*:'5N:R N+W-R8R]D8BUP;W-T;6]D
M97)N+W!M+6)T<F5E+6EN9&5X+FQI<W @,C0*+2AD969M971H;V0@<')E<&%R
M92UL;V-A;"UQ=65R:65S(#IA9G1E<B H*&)T('!M+6)T<F5E+6EN9&5X*2D*
M+2 @*')E9VES=&5R+7%U97)Y(&)T("=D96QE=&4M8F]T:" H9F]R;6%T(&YI
M;" B9&5L971E(&9R;VT@?F$@=VAE<F4@<6D])#$@86YD('9A;'5E/20R(B H
M=&%B;&4M;V8 at 8G0I*2DI"BT*:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M
M+6)T<F5E+6EN9&5X+FQI<W @,C<*+2AD969M971H;V0@<F5M;W9E+6ME>2UA
M;F0M=F%L=64M<&%I<B H<V5C;VYD87)Y+6ME>2!V86QU92 H8G0@<&TM8G1R
M964M:6YD97 at I*0HM(" H=VAE;B H86YD('-E8V]N9&%R>2UK97D@*&EN:71I
M86QI>F5D+7 @8G0I*2 [.U1/1$\Z(&-H96-K(&9O<B!S96-O;F1A<GDM:V5Y
M('=A<R!B96-A=7-E(&ET('=A<R!S;VUE=&EM97,@;FEL+"!I<R!T:&ES('1H
M92!C;W)R96-T(&9I>#\*+2 @(" H=VET:"UT<F%N<RUA;F0M=F%R<R H8G0I
M"BT@(" @(" H8G1R964M97AE8RUP<F5P87)E9"!B=" G9&5L971E+6)O=&@*
M+2 @(" @(" @(" @(" @(" @(" @(" @(" @("AL:7-T("AP;W-T9W)E<RUF
M;W)M870@<V5C;VYD87)Y+6ME>2 H:V5Y+71Y<&4M;V8 at 8G0I*0HM(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @*'!O<W1G<F5S+69O<FUA="!V
M86QU92 H=F%L=64M='EP92UO9B!B="DI*0HM(" @(" @(" @(" @(" @(" @
M(" @(" @(" @)V-L+7!O<W1G<F5S.FEG;F]R92UR;W<M<F5A9&5R*2DI*0HK
M"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UB=')E92YL:7-P(#$Q"BT@
M(" @*&9O<FUA="!S=')E86T@(F1B+71A8FQE.GYA(B H=&%B;&4M;V8@<&TM
M8G1R964I*2DI"BT**R @(" H9F]R;6%T('-T<F5A;2 B9&(M=&%B;&4Z?F$B
M"BL)(" @("AW:&5N("AS;&]T+6)O=6YD<"!P;2UB=')E92 G9&)T86)L92D*
M*PD@(" @(" H=&%B;&4M;V8@<&TM8G1R964I*2DI*0IH=6YK("XO<W)C+V1B
M+7!O<W1M;V1E<FXO<&TM8G1R964N;&ES<" W, HM(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @*&9O<FUA="!N:6P@(F-R96%T92!T86)L92!^82 H
M<6D@?F$@?F$@;F]T(&YU;&PL('9A;'5E('YA(&YO="!N=6QL*2!W:71H(&]I
M9',[(@HK(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @*&9O<FUA="!N
M:6P@(F-R96%T92!T86)L92!^82 H<6D@?F$@?F$@;F]T(&YU;&PL('9A;'5E
M('YA(&YO="!N=6QL*3LB"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UB
M=')E92YL:7-P(#,P.0HK.SL at 8G1R964@=VET:"!D=7!L:6-A=&5S"BL**RAD
M969C;&%S<R!P;2UD=7 M8G1R964@*&1U<"UB=')E92!P;2UB=')E92D**R @
M*"D**R @*#IM971A8VQA<W,@<&5R<VES=&5N="UM971A8VQA<W,I*0HK"BLH
M9&5F;65T:&]D(&1U<&QI8V%T97,M86QL;W=E9"UP("@H8G0@<&TM9'5P+6)T
M<F5E*2D@="D**PHK*&1E9FUE=&AO9"!P<F5P87)E+6QO8V%L+7%U97)I97,@
M.F%F=&5R("@H8G0@<&TM9'5P+6)T<F5E*2D**R @*')E9VES=&5R+7%U97)Y
M(&)T("=D96QE=&4M8F]T:" H9F]R;6%T(&YI;" B9&5L971E(&9R;VT@?F$@
M=VAE<F4@<6D])#$@86YD('9A;'5E/20R(B H=&%B;&4M;V8 at 8G0I*2DI"FAU
M;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UB=')E92YL:7-P(#,R, HK*&1E
M9FUE=&AO9"!R96UO=F4M:W8M<&%I<B H:R!V("AB="!P;2UD=7 M8G1R964I
M*2 [.R!43T1/.B!I;G9A;&ED871E(&-A8VAE/PHK(" H=VAE;B H:6YI=&EA
M;&EZ960M<"!B="D**R @(" H=VET:"UT<F%N<RUA;F0M=F%R<R H8G0I"BL@
M(" @(" H8G1R964M97AE8RUP<F5P87)E9"!B=" G9&5L971E+6)O=&@**R @
M(" @(" @(" @(" @(" @(" @(" @(" @("AL:7-T("AP;W-T9W)E<RUF;W)M
M870@:R H:V5Y+71Y<&4M;V8 at 8G0I*0HK(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @*'!O<W1G<F5S+69O<FUA="!V("AV86QU92UT>7!E+6]F
M(&)T*2DI"BL@(" @(" @(" @(" @(" @(" @(" @(" @(" G8VPM<&]S=&=R
M97,Z:6=N;W)E+7)O=RUR96%D97(I*2DI"FAU;FL at +B]S<F,O9&(M<&]S=&UO
M9&5R;B]P;2UC;VYT<F]L;&5R+FQI<W @,S$**RAD969M971H;V0 at 8G5I;&0M
M9'5P+6)T<F5E("@H<V,@<&]S=&UO9&5R;BUS=&]R92UC;VYT<F]L;&5R*2D*
M*R @*&UA:V4M:6YS=&%N8V4@)W!M+61U<"UB=')E92 Z<V,@<V,I*0HK"FAU
M;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UC=7)S;W(N;&ES<" Q.0HM"0D@
M.F)T<F5E(&)T"BT)"2 Z;VED("AO:60 at 8G0I"BL)"2 Z8G1R964@*&-U<G-O
M<BUB=')E92!C=7)S;W(I"BL)"2 Z;VED("AO:60@*&-U<G-O<BUB=')E92!C
M=7)S;W(I*0IH=6YK("XO<W)C+V1B+7!O<W1M;V1E<FXO<&TM8W5R<V]R+FQI
M<W @-S4*+2 @*'=I=&@M<VQO=',@*&)T<F5E*2!C=7)S;W(@*&QI<W0@*&5N
M<W5R92US=')I;F<@*&-U<G)E;G0M<F%W+6ME>2UO9B!C=7)S;W(I*2DI*0HK
M(" H;&ES=" H96YS=7)E+7-T<FEN9R H8W5R<F5N="UR87<M:V5Y+6]F(&-U
M<G-O<BDI*2D*:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M+6-U<G-O<BYL
M:7-P(#$Q,0HM*RAD969M971H;V0 at 8W5R<V]R+75P9&%T92UC=7)R96YT("@H
M8W5R<V]R('!M+6-U<G-O<BDI"BLH9&5F;65T:&]D(&-U<G-O<BUU<&1A=&4M
M8W5R<F5N=" H*&-U<G-O<B!P;2UC=7)S;W(I*0IH=6YK("XO<W)C+V1B+7!O
M<W1M;V1E<FXO<&TM8W5R<V]R+FQI<W @,3$Y"BT*:'5N:R N+W-R8R]D8BUP
M;W-T;6]D97)N+W!M+6-U<G-O<BYL:7-P(#(Q, at HK*&1E9F-L87-S('!M+61U
M<&(M8W5R<V]R("AP;2UC=7)S;W(I("@I*0HK"BLH9&5F;65T:&]D(&UA:V4M
M8W5R<V]R("@H8G0@<&TM9'5P+6)T<F5E*2D**R @*&UA:V4M:6YS=&%N8V4@
M)W!M+61U<&(M8W5R<V]R"BL)"2 Z8G1R964 at 8G0**PD)(#IO:60@*&]I9"!B
M="DI*0HK"BLH9&5F;65T:&]D(&-U<G-O<BUC=7)R96YT+7%U97)Y+7!A<F%M
M<RUA=71O("@H8W5R<V]R('!M+61U<&(M8W5R<V]R*2D**R @*&QI<W0@*&5N
M<W5R92US=')I;F<@*&-U<G)E;G0M<F%W+6ME>2UO9B!C=7)S;W(I*0HK"2AE
M;G-U<F4M<W1R:6YG("AC=7)R96YT+7)A=RUV86QU92UO9B!C=7)S;W(I*2DI
M"BL**RAD969M86-R;R!D968M8W5R<V]R+61U<"UM;W9E<B H;7EN86UE(&)A
M<V5N86UE*2 [(&UA8W)O(&IU<W0 at 9F]R('1W;R!F=6YC=&EO;G, at 86EN)W0@
M<F5A;&QY(&=O;V0L(&)U="XN"BL@(& H9&5F;65T:&]D("QM>6YA;64@*"AC
M=7)S;W(@<&TM9'5P8BUC=7)S;W(I*0HK(" @("AU;FQE<W,@*&-U<G-O<BUI
M;FET:6%L:7IE9"UP(&-U<G-O<BD@*')E='5R;BUF<F]M("QM>6YA;64I*0HK
M(" @("AL970@*"AC:V5Y("AC=7)R96YT+7)A=RUK97DM;V8 at 8W5R<V]R*2DI
M"BL@(" @(" H;75L=&EP;&4M=F%L=64M8FEN9" H9F]U;F0@:R!V*0HK"2 @
M*"QB87-E;F%M92!C=7)S;W(I"BL)*&EF("AA;F0 at 9F]U;F0@*&5Q=6%L(&-K
M97D@*&-U<G)E;G0M<F%W+6ME>2UO9B!C=7)S;W(I*2D**PD@(" @*'9A;'5E
M<R!F;W5N9"!K('8I"BL)(" @("AC=7)S;W(M8VQO<V4 at 8W5R<V]R*2DI*2DI
M"BL**RAD968M8W5R<V]R+61U<"UM;W9E<B!C=7)S;W(M;F5X="UD=7 @8W5R
M<V]R+6YE>'0I"BLH9&5F+6-U<G-O<BUD=7 M;6]V97(@8W5R<V]R+7!R978M
M9'5P(&-U<G-O<BUP<F5V*0HK"BLH9&5F;6%C<F\@9&5F+6-U<G-O<BUN;V1U
M<"UM;W9E<B H;F%M92!F<F]M+6-A8VAE+69E=&-H97(@8V%C:&4M9FEL;&5R
M*0HK("!@*&1E9FUE=&AO9" L;F%M92 H*&-U<G-O<B!P;2UD=7!B+6-U<G-O
M<BDI"BL@(" @*'5N;&5S<R H8W5R<V]R+6EN:71I86QI>F5D+7 @8W5R<V]R
M*2 H<F5T=7)N+69R;VT at +&YA;64I*0HK(" @("AL970@*"AO:V5Y("AC=7)R
M96YT+7)A=RUK97DM;V8 at 8W5R<V]R*2DI"BL@(" @(" H;&]O<" H;75L=&EP
M;&4M=F%L=64M8FEN9" H9F]U;F0@:R!V*0HK"0DH+&9R;VTM8V%C:&4M9F5T
M8VAE<B!C=7)S;W(I"BL)(" @(" @*&-O;F0**PD)*"AA;F0 at 9F]U;F0@*&YO
M=" H97%U86P@*&-U<G)E;G0M<F%W+6ME>2UO9B!C=7)S;W(I(&]K97DI*2D*
M*PD)("AR971U<FXM9G)O;2 L;F%M92 H=F%L=65S('0@:R!V*2DI"BL)"2 at H
M;F]T(&9O=6YD*0HK"0D at +&-A8VAE+69I;&QE<@HK"0D@*')E='5R;BUF<F]M
M("QN86UE("@L9G)O;2UC86-H92UF971C:&5R(&-U<G-O<BDI*0HK"2 @(" @
M("AT(#IC;VYT:6YU92DI*2DI*2D**PHK*&1E9BUC=7)S;W(M;F]D=7 M;6]V
M97(@8W5R<V]R+6YE>'0M;F]D=7 @8W5R<V]R+69E=&-H+6YE>'0M9G)O;2UC
M86-H90HK(" H8W5R<V]R+69E=&-H+6%U=&\@8W5R<V]R("=N97AT+6YO9'5P
M( HK"0D@(" @("@Z:V5Y+6-O;7!A<F4@)SX at .G9A;'5E+6-O;7!A<F4@;FEL
M*0HK"0D@(" @("@H;&ES=" H96YS=7)E+7-T<FEN9R!O:V5Y*2D at .G)E<V5T
M+6-A8VAE('0I*2D**PHK*&1E9BUC=7)S;W(M;F]D=7 M;6]V97(@8W5R<V]R
M+7!R978M;F]D=7 @8W5R<V]R+69E=&-H+7!R978M9G)O;2UC86-H90HK(" H
M8W5R<V]R+69E=&-H+6%U=&\@8W5R<V]R("=P<F5V+6YO9'5P"BL)"2 @(" @
M*#IK97DM8V]M<&%R92 G/" Z=F%L=64M8V]M<&%R92!N:6P at .FME>2UO<F1E
M<B B1$530R(I"BL)"2 @(" @*"AL:7-T("AE;G-U<F4M<W1R:6YG(&]K97DI
M*2 Z<F5S970M8V%C:&4@=" Z8V%C:&4M<')I;W(@="DI*0HK"BLH9&5F;65T
M:&]D(&-U<G-O<BUG970M8F]T:"UR86YG92 H*&-U<G-O<B!P;2UD=7!B+6-U
M<G-O<BD@:V5Y('9A;"D**R @*&-U<G-O<BUF971C:"UA=71O(&-U<G-O<B G
M9V5T+6)O=&@**PD)(" @(" H.FME>2UC;VUP87)E(&YI;" Z=F%L=64M8V]M
M<&%R92 G/CTI"BL)"2 @(" @*"AL:7-T("AK97DM<&%R86UE=&5R(&ME>2!B
M=')E92D**PD)"2 @(" H=F%L=64M<&%R86UE=&5R('9A;"!B=')E92DI(#IR
M97-E="UC86-H92!T*2D**R @*&-U<G-O<BUF971C:"UN97AT+69R;VTM8V%C
M:&4 at 8W5R<V]R*2D**PHK*&1E9FUE=&AO9"!C=7)S;W(M9V5T+6)O=&@@*"AC
M=7)S;W(@<&TM9'5P8BUC=7)S;W(I(&ME>2!V86PI"BL@("AM=6QT:7!L92UV
M86QU92UB:6YD("AF;W5N9"!K('8I"BL@(" @(" H8W5R<V]R+6=E="UB;W1H
M+7)A;F=E(&-U<G-O<B!K97D@=F%L*0HK(" @("AI9B H86YD(&9O=6YD("AE
M;&4Z.FQI<W M8V]M<&%R92UE<75A;"!V86P@*&-U<G)E;G0M=F%L=64M;V8@
M8W5R<V]R*2DI"BL)*'9A;'5E<R!T(&L@=BD**PDH8W5R<V]R+6-L;W-E(&-U
M<G-O<BDI*2D*:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M+6EN9&5X960M
M8G1R964N;&ES<" Q,0HM(" [.R!)="!S965M<R!L:6ME('1H:7,@:7,@<V]M
M971I;65S('5N8F]U;F0L(&)U="!H;W<@8V%N(&ET(&)E/PHK(" [.R!Q=65S
M=&EO;F%B;&4@=V]R:V%R;W5N9"!T;R!C<F5A=&4@<WES=&5M('1A8FQE<R!F
M<F]M(&]I9"X*:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M+6EN9&5X960M
M8G1R964N;&ES<" Q- HM(" **PIH=6YK("XO<W)C+V1B+7!O<W1M;V1E<FXO
M<&TM:6YD97AE9"UB=')E92YL:7-P(#@T"BT@(" @(" @(" @(" @(" @(" @
M("AR96UO=F4M:V5Y+6%N9"UV86QU92UP86ER('-E8V]N9&%R>2UK97D@:V5Y
M(&EN9&5X*2DI*2D**R @(" @(" @(" @(" @(" @(" @*')E;6]V92UK=BUP
M86ER('-E8V]N9&%R>2UK97D@:V5Y(&EN9&5X*2DI*2D*:'5N:R N+W-R8R]D
M8BUP;W-T;6]D97)N+W!M+7-E8V]N9&%R>2YL:7-P(#,*+2AD969C;&%S<R!P
M;2US96-O;F1A<GDM8W5R<V]R("AP;2UC=7)S;W(I( HK*&1E9F-L87-S('!M
M+7-E8V]N9&%R>2UC=7)S;W(@*'!M+61U<&(M8W5R<V]R*2 *:'5N:R N+W-R
M8R]D8BUP;W-T;6]D97)N+W!M+7-E8V]N9&%R>2YL:7-P(#D*+2 @*&UA:V4M
M:6YS=&%N8V4@)W!M+7-E8V]N9&%R>2UC=7)S;W(@"BL@("AM86ME+6EN<W1A
M;F-E("=P;2US96-O;F1A<GDM8W5R<V]R"FAU;FL at +B]S<F,O9&(M<&]S=&UO
M9&5R;B]P;2US96-O;F1A<GDN;&ES<" Q-0HM*&1E9FUE=&AO9"!C=7)S;W(M
M8W5R<F5N="UQ=65R>2UP87)A;7,M875T;R H*&-U<G-O<B!P;2US96-O;F1A
M<GDM8W5R<V]R*2D*+2 @*'=I=&@M<VQO=',@*&)T<F5E*2!C=7)S;W(@"BT@
M(" @*&QI<W0@*&5N<W5R92US=')I;F<@*&-U<G)E;G0M<F%W+6ME>2UO9B!C
M=7)S;W(I*0HM"2 @*&5N<W5R92US=')I;F<@*&-U<G)E;G0M<F%W+79A;'5E
M+6]F(&-U<G-O<BDI*2DI"BT*:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M
M+7-E8V]N9&%R>2YL:7-P(#,W"BTH9&5F;6%C<F\@9&5F+6-U<G-O<BUD=7 M
M;6]V97(@*&UY;F%M92!B87-E;F%M92D at .R!M86-R;R!J=7-T(&9O<B!T=V\@
M9G5N8W1I;VYS(&%I;B=T(')E86QL>2!G;V]D+"!B=70N+ at HM("!@*&1E9FUE
M=&AO9" L;7EN86UE("@H8W5R<V]R('!M+7-E8V]N9&%R>2UC=7)S;W(I*0HM
M(" @("AU;FQE<W,@*&-U<G-O<BUI;FET:6%L:7IE9"UP(&-U<G-O<BD@*')E
M='5R;BUF<F]M("QM>6YA;64I*0HM(" @("AL970@*"AC:V5Y("AC=7)R96YT
M+7)A=RUK97DM;V8 at 8W5R<V]R*2DI"BT@(" @(" H;75L=&EP;&4M=F%L=64M
M8FEN9" H9F]U;F0@:R!V*0HM"2 @*"QB87-E;F%M92!C=7)S;W(I"BT)*&EF
M("AA;F0 at 9F]U;F0@*&5Q=6%L(&-K97D@*&-U<G)E;G0M<F%W+6ME>2UO9B!C
M=7)S;W(I*2D*+0D@(" @*'9A;'5E<R!F;W5N9"!K('8I"BT)(" @("AC=7)S
M;W(M8VQO<V4 at 8W5R<V]R*2DI*2DI"BT*+2AD968M8W5R<V]R+61U<"UM;W9E
M<B!C=7)S;W(M;F5X="UD=7 @8W5R<V]R+6YE>'0I"BTH9&5F+6-U<G-O<BUD
M=7 M;6]V97(@8W5R<V]R+7!R978M9'5P(&-U<G-O<BUP<F5V*0HM"FAU;FL@
M+B]S<F,O9&(M<&]S=&UO9&5R;B]P;2US96-O;F1A<GDN;&ES<" T, HM*&1E
M9FUA8W)O(&1E9BUC=7)S;W(M;F]D=7 M;6]V97(@*&YA;64 at 9G)O;2UC86-H
M92UF971C:&5R(&-A8VAE+69I;&QE<BD*+2 @8"AD969M971H;V0 at +&YA;64@
M*"AC=7)S;W(@<&TM<V5C;VYD87)Y+6-U<G-O<BDI"BT@(" @*'5N;&5S<R H
M8W5R<V]R+6EN:71I86QI>F5D+7 @8W5R<V]R*2 H<F5T=7)N+69R;VT at +&YA
M;64I*0HM(" @("AL970@*"AO:V5Y("AC=7)R96YT+7)A=RUK97DM;V8 at 8W5R
M<V]R*2DI"BT@(" @(" H;&]O<" H;75L=&EP;&4M=F%L=64M8FEN9" H9F]U
M;F0@:R!V*0HM"0DH+&9R;VTM8V%C:&4M9F5T8VAE<B!C=7)S;W(I"BT)(" @
M(" @*&-O;F0*+0D)*"AA;F0 at 9F]U;F0@*&YO=" H97%U86P@*&-U<G)E;G0M
M<F%W+6ME>2UO9B!C=7)S;W(I(&]K97DI*2D*+0D)("AR971U<FXM9G)O;2 L
M;F%M92 H=F%L=65S('0@:R!V*2DI"BT)"2 at H;F]T(&9O=6YD*0HM"0D at +&-A
M8VAE+69I;&QE<@HM"0D@*')E='5R;BUF<F]M("QN86UE("@L9G)O;2UC86-H
M92UF971C:&5R(&-U<G-O<BDI*0HM"2 @(" @("AT(#IC;VYT:6YU92DI*2DI
M*2D*+0HM*&1E9BUC=7)S;W(M;F]D=7 M;6]V97(@8W5R<V]R+6YE>'0M;F]D
M=7 @8W5R<V]R+69E=&-H+6YE>'0M9G)O;2UC86-H90HM(" H8W5R<V]R+69E
M=&-H+6%U=&\@8W5R<V]R("=N97AT+6YO9'5P( HM"0D@(" @("@Z:V5Y+6-O
M;7!A<F4@)SX at .G9A;'5E+6-O;7!A<F4@;FEL*0HM"0D@(" @("@H;&ES=" H
M96YS=7)E+7-T<FEN9R!O:V5Y*2D at .G)E<V5T+6-A8VAE('0I*2D*+0HM*&1E
M9BUC=7)S;W(M;F]D=7 M;6]V97(@8W5R<V]R+7!R978M;F]D=7 @8W5R<V]R
M+69E=&-H+7!R978M9G)O;2UC86-H90HM(" H8W5R<V]R+69E=&-H+6%U=&\@
M8W5R<V]R("=P<F5V+6YO9'5P"BT)"2 @(" @*#IK97DM8V]M<&%R92 G/" Z
M=F%L=64M8V]M<&%R92!N:6P at .FME>2UO<F1E<B B1$530R(I"BT)"2 @(" @
M*"AL:7-T("AE;G-U<F4M<W1R:6YG(&]K97DI*2 Z<F5S970M8V%C:&4@=" Z
M8V%C:&4M<')I;W(@="DI*0HM"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P
M;2US96-O;F1A<GDN;&ES<" T- at HM*&1E9FUE=&AO9"!C=7)S;W(M9V5T+6)O
M=&@M<F%N9V4@*"AC=7)S;W(@<&TM<V5C;VYD87)Y+6-U<G-O<BD@:V5Y('!K
M97DI"BT@("AC=7)S;W(M9F5T8V at M875T;R!C=7)S;W(@)V=E="UB;W1H"BT)
M"2 @(" @*#IK97DM8V]M<&%R92!N:6P at .G9A;'5E+6-O;7!A<F4@)SX]*0HM
M"0D@(" @("@H;&ES=" H:V5Y+7!A<F%M971E<B!K97D at 8G1R964I"BT)"0D@
M(" @*'9A;'5E+7!A<F%M971E<B!P:V5Y(&)T<F5E*2D at .G)E<V5T+6-A8VAE
M('0I*0HM(" H8W5R<V]R+69E=&-H+6YE>'0M9G)O;2UC86-H92!C=7)S;W(I
M*0HM"BTH9&5F;65T:&]D(&-U<G-O<BUG970M8F]T:" H*&-U<G-O<B!P;2US
M96-O;F1A<GDM8W5R<V]R*2!K97D@<&ME>2D*+2 @*&UU;'1I<&QE+79A;'5E
M+6)I;F0@*&9O=6YD(&L@=BD*+2 @(" @("AC=7)S;W(M9V5T+6)O=&@M<F%N
M9V4 at 8W5R<V]R(&ME>2!P:V5Y*0HM(" @("AI9B H86YD(&9O=6YD("AE;&4Z
M.FQI<W M8V]M<&%R92UE<75A;"!P:V5Y("AC=7)R96YT+79A;'5E+6]F(&-U
M<G-O<BDI*0HM"2AV86QU97,@="!K('8I"BT)*&-U<G-O<BUC;&]S92!C=7)S
M;W(I*2DI"BT*?0H*6W!O<W1M;V1E<FXZ(&YE=R!S='5F9B!S=7!P;W)T"F%L
M97 at N;6EZ<F%H:4!G;6%I;"YC;VTJ*C(P,#@P-C T,3$T-34Q72!["FAU;FL@
M+B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UC;VYT<F]L;&5R+FQI<W @,38Y"BLH
M9&5F;65T:&]D(&9L=7-H+6EN<W1A;F-E+6-A8VAE("@H<V,@<&]S=&UO9&5R
M;BUS=&]R92UC;VYT<F]L;&5R*2D**R @(E)E<V5T('1H92!I;G-T86YC92!C
M86-H92 H9FQU<V@@;V)J96-T(&QO;VMU<',I+B **R @($YE960@<W!E8VEA
M;&EZ960@=F5R<VEO;B!F;W(@<&]S=&UO9&5R;B!B96-A=7-E(&ET(')E;&EE
M<R!O;@HK(" @<WES=&5M(&)T<F5E<R!B96EN9R!C86-H960N("(**R @*&5L
M92UW:71H+69A<W0M;&]C:R H*&5L93HZ8V]N=')O;&QE<BUI;G-T86YC92UC
M86-H92UL;V-K('-C*2D**R @(" [.R!C86YN;W0 at 8V%L;"UN97AT+6UE=&AO
M9"!B96-A=7-E(&9A<W0M;&]C:W,@"BL@(" @.SL at 87)E(&YO="!R96-U<G-I
M=F4L(&%N9"!W92!N965D(&%T;VUI8VET>2!H97)E+ at HK(" @("AL970@*"AC
M=" H<V5T9B H96QE.CIC;VYT<F]L;&5R+6EN<W1A;F-E+6-A8VAE('-C*0HK
M"0D@(" @*&5L93HZ;6%K92UC86-H92UT86)L92 Z=&5S=" G97%L*2DI*0HK
M(" @(" @.SL at 86=A:6XL(&-A;B=T('5S92!C86-H92UI;G-T86YC92 **R @
M(" @(#L[(&)E8V%U<V4@;F]N+7)E8W5R<VEV92!L;V-K<PHK(" @(" @*'-E
M=&8@*&5L93HZ9V5T+6-A8VAE("AO:60@*'-L;W0M=F%L=64@<V,@)W)O;W0I
M*2!C="D@*'-L;W0M=F%L=64@<V,@)W)O;W0I"BL)(" @("AE;&4Z.F=E="UC
M86-H92 H;VED("AP97)S:7-T96YT+7-L;W0M8V]L;&5C=&EO;BUO9B!S8RDI
M(&-T*2 H<&5R<VES=&5N="US;&]T+6-O;&QE8W1I;VXM;V8@<V,I"BL)(" @
M("AE;&4Z.F=E="UC86-H92 H;VED("AS;&]T+79A;'5E('-C("=I;G-T86YC
M92UT86)L92DI(&-T*2 H<VQO="UV86QU92!S8R G:6YS=&%N8V4M=&%B;&4I
M"BL)(" @("AE;&4Z.F=E="UC86-H92 H;VED("AS;&]T+79A;'5E('-C("=S
M8VAE;6$M=&%B;&4I*2!C="D@*'-L;W0M=F%L=64@<V,@)W-C:&5M82UT86)L
M92D**PD@(" @*&5L93HZ9V5T+6-A8VAE("AO:60@*'-L;W0M=F%L=64@<V,@
M)VEN9&5X+71A8FQE*2D at 8W0I("AS;&]T+79A;'5E('-C("=I;F1E>"UT86)L
M92DI*2DI"BL**PHK"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P;2UC;VYT
M<F]L;&5R+FQI<W @,3DU"BT@("AF;&5T("@H:6YI="UR;V]T("@I"BT@(" @
M(" @(" @("AS971F("AS;&]T+79A;'5E('-C("=R;V]T*2 H;6%K92UI;G-T
M86YC92 G<&TM:6YD97AE9"UB=')E92 Z<V,@<V, at .F9R;VTM;VED(# @.G1A
M8FQE+6YA;64@(G)O;W0B*2D*+2 @(" @(" @(" @*'-E=&8@*&ME>2UT>7!E
M+6]F("AS;&]T+79A;'5E('-C("=R;V]T*2D@*&1A=&$M='EP92!T*2D*+2 @
M(" @(" @(" @*'-E=&8@*'-L;W0M=F%L=64@<V,@)V-L87-S+7)O;W0I("AM
M86ME+6EN<W1A;F-E("=P;2UI;F1E>&5D+6)T<F5E(#IS8R!S8R Z9G)O;2UO
M:60@,2 Z=&%B;&4M;F%M92 B8VQA<W-R;V]T(BDI"BT@(" @(" @(" @("AS
M971F("AK97DM='EP92UO9B H<VQO="UV86QU92!S8R G8VQA<W,M<F]O="DI
M("AD871A+71Y<&4@="DI*2D**R @*&QA8F5L<R H*&UA:V4M<WES=&5M+6)T
M<F5E("AO:60@;F%M92 F;W!T:6]N86P@*&-L87-S("=P;2UB=')E92D@*&1A
M=&$M97AA;7!L92!T*2D**PD@(" @("AL970@*"AB=" H;6%K92UI;G-T86YC
M92!C;&%S<R Z<V,@<V, at .F9R;VTM;VED(&]I9" Z=&%B;&4M;F%M92!N86UE
M*2DI"BL)(" @(" @("AS971F("AK97DM='EP92UO9B!B="D@*&1A=&$M='EP
M92!D871A+65X86UP;&4I*0HK"2 @(" @("!B="DI"BL)(" @*&EN:70M<F]O
M=" H*0HK"2 @(" @*'-E=&8@*'-L;W0M=F%L=64@<V,@)W)O;W0I("AM86ME
M+7-Y<W1E;2UB=')E92 P(")R;V]T(BD**PD)(" @*'-L;W0M=F%L=64@<V,@
M)VEN<W1A;F-E+71A8FQE*2 H;6%K92US>7-T96TM8G1R964@,2 B:6YS=&%N
M8V5S(B G<&TM:6YD97AE9"UB=')E92 Q*0HK"0D@(" H<VQO="UV86QU92!S
M8R G<V-H96UA+71A8FQE*2 H;6%K92US>7-T96TM8G1R964@,R B<V-H96UA
M<R(@)W!M+6EN9&5X960M8G1R964@,2D**PD)(" @*'-L;W0M=F%L=64@<V,@
M)VEN9&5X+71A8FQE*2 H;6%K92US>7-T96TM8G1R964 at -" B:6YD:6-E<R(I
M*2DI"BL)(" @(" *:'5N:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M+6-O;G1R
M;VQL97(N;&ES<" R,3<*+2 @(" @(" @(" H<V5T9B H<&5R<VES=&5N="US
M;&]T+6-O;&QE8W1I;VXM;V8@<V,I("AM86ME+6EN<W1A;F-E("=P;2UB=')E
M92 Z=&%B;&4M;F%M92 B<VQO=',B(#IF<F]M+6]I9" R(#IS8R!S8RDI"BT@
M(" @(" @(" @*'-E=&8@*&ME>2UT>7!E+6]F("AP97)S:7-T96YT+7-L;W0M
M8V]L;&5C=&EO;BUO9B!S8RDI("AD871A+71Y<&4@*&9O<FTM<VQO="UK97D@
M-S<W("=A+71Y<&EC86PM<VQO="DI*0HK(" @(" @(" @("AS971F("AP97)S
M:7-T96YT+7-L;W0M8V]L;&5C=&EO;BUO9B!S8RD**PD)*&UA:V4M<WES=&5M
M+6)T<F5E(#(@(G-L;W1S(B G<&TM8G1R964@*&9O<FTM<VQO="UK97D at -S<W
M("=A+71Y<&EC86PM<VQO="DI*0IH=6YK("XO<W)C+V1B+7!O<W1M;V1E<FXO
M<&TM8V]N=')O;&QE<BYL:7-P(#(S.0HM(" @(" @(" @(" @(" @(" @(" H
M;6%K92UT86)L92 H<VQO="UV86QU92!S8R G<F]O="DI"BT@(" @(" @(" @
M(" @(" @(" @("AM86ME+71A8FQE("AS;&]T+79A;'5E('-C("=C;&%S<RUR
M;V]T*2D**PD)(" @("AD;VQI<W0@*'-L;W0@)RAR;V]T(&EN<W1A;F-E+71A
M8FQE( HK"0D)"2 @("!S8VAE;6$M=&%B;&4@:6YD97 at M=&%B;&4I*0HK"0D@
M(" @(" H;6%K92UT86)L92 H<VQO="UV86QU92!S8R!S;&]T*2DI"BL*:'5N
M:R N+W-R8R]D8BUP;W-T;6]D97)N+W!M+6-O;G1R;VQL97(N;&ES<" R-S@*
M*RAD969M971H;V0@;F5X="UC:60@*"AS8R!P;W-T;6]D97)N+7-T;W)E+6-O
M;G1R;VQL97(I*0HK(" H=VET:"UC;VYN96-T:6]N+69O<BUT:')E860@*'-C
M*0HK(" @("AW:71H+7!O<W1M;V1E<FXM8V]N;B H*&%C=&EV92UC;VYN96-T
M:6]N*2D**R @(" @("AP;W-T;6]D97)N.G-E<75E;F-E+6YE>'0@)V-L87-S
M7VED7W-E<2DI*2D**PIH=6YK("XO<W)C+V1B+7!O<W1M;V1E<FXO<&TM8V]N
M=')O;&QE<BYL:7-P(#(Y.0HK*&1E9FUE=&AO9"!O:60M/G-C:&5M82UI9" H
M;VED("AS8R!P;W-T;6]D97)N+7-T;W)E+6-O;G1R;VQL97(I*0HK(" B1F]R
M(&1E9F%U;'0 at 9&%T82!S=')U8W1U<F5S+"!P<F]V:61E(&$@9FEX960@;6%P
M<&EN9R!T;R!C;&%S<R!)1', at 8F%S960**R @(&]N('1H92!K;F]W;B!S=&%R
M='5P(&]R9&5R+B H=6=L>2DB"BL@("AI9B H/#T@;VED(#4Q*0HK(" @(" @
M*&-A<V4@;VED"BL)*# @,2D at .R!R;V]T"BL)*#$@,RD at .R!I;G-T86YC97,*
M*PDH,B Q*2 [('-L;W1S"BL)*#,@,RD at .R!S8VAE;6%S"BL)*#0@,2D at .R!I
M;F1I8V5S"BL)*#4P(#0I(" @.R!B=')E92UI;F1I8V5S(&]F"BL)*#4Q(#0I
M*2 @.R @:6YS=&%N8V5S(&%N9"!S8VAE;6%S"BL@(" @(" H8V%L;"UN97AT
M+6UE=&AO9"DI*0HK"BLH9&5F;65T:&]D(&1E9F%U;'0M8VQA<W,M:60@*'1Y
M<&4@*'-C('!O<W1M;V1E<FXM<W1O<F4M8V]N=')O;&QE<BDI"BL@("AE8V%S
M92!T>7!E"BL@(" @*"=P;2UB=')E92 Q*0HK(" @("@G<&TM9'5P+6)T<F5E
M(#(I"BL@(" @*"=P;2UI;F1E>&5D+6)T<F5E(#,I"BL@(" @*"=P;2UB=')E
M92UI;F1E>" T*2DI"BL**RAD969M971H;V0 at 9&5F875L="UC;&%S<RUI9"UT
M>7!E("AC:60@*'-C('!O<W1M;V1E<FXM<W1O<F4M8V]N=')O;&QE<BDI"BL@
M("AC87-E(&-I9 HK(" @("@Q("=P;2UB=')E92D**R @(" H,B G<&TM9'5P
M+6)T<F5E*0HK(" @("@S("=P;2UI;F1E>&5D+6)T<F5E*0HK(" @("@T("=P
M;2UB=')E92UI;F1E>"DI*0HK"FAU;FL at +B]S<F,O9&(M<&]S=&UO9&5R;B]P
M;2US<6PN;&ES<" R-C *+2 @(" @(" @(" @(" @(" @(#L[(" B8W)E871E
M(&EN9&5X(&ED>%]B;&]B7V)I9"!O;B!B;&]B("AB:60I.R(@.SMA;')E861Y
M(&UA9&4@:6UP;&EC:71L>2!W:&5N(&1E9FEN:6YG('!R:6UA<GD@:V5Y(&9O
M<B!T86)L90HM(" @(" @(" @(" @(" @(" @(F-R96%T92!S97%U96YC92!P
M97)S:7-T96YT7W-E<2!S=&%R="!W:71H(#$P.R(I*2 [.R!M86ME(')O;VT@
M9F]R('-O;64@<WES=&5M('1A8FQE<PHK"0D@(")C<F5A=&4@<V5Q=65N8V4@
M8VQA<W-?:61?<V5Q('-T87)T('=I=&@@-3 [(@HK(" @(" @(" @(" @(" @
M(" @(F-R96%T92!S97%U96YC92!P97)S:7-T96YT7W-E<2!S=&%R="!W:71H
M(#4P.R(I*2 [.R!M86ME(')O;VT at 9F]R('-O;64@<WES=&5M('1A8FQE<PI]
M"@I#;VYT97AT. at H*6T9I>"!B=')E92]D=7 M8G1R964 at 87,@;FEL(&-R96%T
M:6]N('!R;V)L96T*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# V,#(R
M,# X,#==( I;0VAA;F=E9"!D<F]P+7!O8FIE8W0 at 05!)('1O(&1R;W M:6YS
M=&%N8V5S+B @4F5M;W9E9"!O;&0 at 9FEL97,N"F5S;&EC:T!C;VUM;VXM;&ES
M<"YN970J*C(P,#@P-C Q,C,S,S(Y72 *6T9I>"!C;VYF:6<@<F5S=&%R="!T
M>7!O+"!A9&0@='EP92!S<&5C:69I97)S('1O(&-O;&QE8W1I;VX@=&5S="P@
M<F5M;W9E(&UE=&%C;&%S<R!S<&5C:69I8V%T:6]N(&9R;VT at 9'5P+6)T<F5E
M(&EN(&)D8BUC;VQL96-T:6]N<PIE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR
M,# X,#8P,3(Q,C8T,5T@"EM);FET:6%L('-U<'!O<G0 at 9F]R($)$0B T+C<@
M+R!S;VUE(&%L;&5G<F\@=6YI8V]D92!P97)F;W)M86YC92!S:V5T8VAE<R O
M(&$@9F5W(&]P=&EM:7IA=&EO;B!R96QA=&5D('1W96%K<PIE<VQI8VM 8V]M
M;6]N+6QI<W N;F5T*BHR,# X,#8P,3$Q,3$Q-UT@"EM!9&0@<F5S=&%R="!T
M;R!C<F5A=&4 at 82!D969A=6QT(&UY+6-O;F9I9RYS97AP"F5S;&EC:T!C;VUM
M;VXM;&ES<"YN970J*C(P,#@P-C Q,3$Q,#0R72 *6T%L97 at G<R!S97)I86QI
M>F5R('!A=&-H.R!U;FEC;V1E('!E<F9O<FUA;F-E(&EM<')O=F5M96YT<SL@
M<V5R:6%L:7IE<B!H87-H(&]P=&EM:7IA=&EO;@IE<VQI8VM 8V]M;6]N+6QI
M<W N;F5T*BHR,# X,#4R.#$R-#@S,ET@"EM3;VUE(&-H86YG97,@=&\@<G5C
M:W-A8VL at 97AP97)I;65N=&%L(&)A8VME;F0*97-L:6-K0&-O;6UO;BUL:7-P
M+FYE="HJ,C P.# U,3<Q-C$W-#)=( I;9FEN86QI>F4M:6YH97)I=&%N8V4M
M<V)C;"UF:7@*9W1A<F-E84!U;6EC:"YE9'4J*C(P,#@P-3$X,C$Q.#4T"B!S
M8F-L(#$N,"XQ-B!F86EL<R!W:&5N(&1O:6YG(&UO<"!I;G1R;W-P96-T:6]N
M(&]N('-O;64 at 8VQA<W-E<RP@=VET:"!T:&4 at 97)R;W(*(%1H92!S;&]T(%-"
M+5!#3#HZ)4-,05-3+5!214-%1$5.0T4M3$E35"!I<R!U;F)O=6YD(&EN('1H
M92!O8FIE8W0@(SQ35$%.1$%21"U#3$%34R!%3$502$%.5#I33$]4+5-%5#X*
M( H at 5&AE(&9U;F-T:6]N('1E>&EN9F\M:6YF97)R960M8F]D>2!W87,@;6]D
M:69I960@=&\@:6YC;'5D92!A(&-A;&P@=&\@9FEN86QI>F4M:6YH97)I=&%N
M8V4N"ET@"EM#3"U344P at 8VAA;F=E<R!U;G)E8V]R9&5D(&EN(&UA:6X@<F5P
M;W-I=&]R>0IR96%D0')O8F5R=&QR96%D+FYE="HJ,C P.# U,3<R,S(Q,C)=
M( I;3V)J96-T(&QE=F5L(&UA;F%G96UE;G0@;V8 at 8V%C:&5D('-L;W1S("AG
M<F5E;B!O;B!!;&QE9W)O+T)$0BD*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ
M,C P.# U,3<R,3 Y,SE=( I;4F5M;W9E('1Y<&4 at 8VAE8VL@:6X@<V5R:6%L
M:7IE<CL at 9FEX('1Y<&\@:6X at 0D1"('!A=&-H"F5S;&EC:T!C;VUM;VXM;&ES
M<"YN970J*C(P,#@P-3$W,# U-S,X72 *6T9I>"!F;W(@;F]N+6%C;"!L:7-P
M<R!O;B!C;&%S<R!C<F5A=&EO;B!C:&5C:W!O:6YT"F5S;&EC:T!C;VUM;VXM
M;&ES<"YN970J*C(P,#@P-3$V,C P,C0Y72 *6T-L87-S(&-R96%T:6]N(&9R
M;VT@<V-H96UA<R!S;F%P<VAO= IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR
M,# X,#4Q-C$Y-#$R.5T@"EM&:7AU<"!I;F1E>&5D+7-L;W1S+FQI<W *<F5A
M9$!R;V)E<G1L<F5A9"YN970J*C(P,#@P-3$V,3DT,#,P72 *6TES<W5E('=I
M=&@@<F5P;W-I=&]R>2!S>6YC"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P
M,#@P-3$V,3DR,S V72 *6T%D9&5D('!E<BUS=&]R92!O<'1I;VYS(&9O<B!L
M;V-K<R F(&-A8VAE('-I>F5S"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P
M,#@P-3$V,3DQ-S0W72 *6T%D9"!M87@@;&]C:R!C;VYF:6=U<F%T:6]N('1O
M($)$0 at IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#4Q-C$X-3$U-5T@
M"EMC;&5A;F5D('5P(&UE<F=E(&IU;FL[('-O;64@<75E<GD@<VME=&-H:6YG
M.R!M86ME(&EN9&5X960M<"!U;FEV97)S86P*97-L:6-K0&-O;6UO;BUL:7-P
M+FYE="HJ,C P.# U,30R,30R,C==( I;;W!E;B!C;VYT<F]L;&5R(&9O<B!B
M9&(@86-C97!T<R!A('!A=&AN86UE('-P96,*4GES>F%R9"!3>F]P82 \<GES
M>F%R9"YS>F]P84!G;6%I;"YC;VT^*BTR,# X,#4Q,S$S,S,U-ET@"EMO<&5N
M(&-O;G1R;VQL97(@9F]R(&)D8B!A8V-E<'1S(&$@<&%T:&YA;64@<W!E8PI2
M>7-Z87)D(%-Z;W!A(#QR>7-Z87)D+G-Z;W!A0&=M86EL+F-O;3XJ*C(P,#@P
M-3$S,3,S,S4V72 *6V5L97!H86YT+61B+7!A=&@M=&5S= I2>7-Z87)D(%-Z
M;W!A(#QR>7-Z87)D+G-Z;W!A0&=M86EL+F-O;3XJ*C(P,#@P-3$S,C$S,C(R
M72 *6TUA:VEN9T-,0E5)3$1296%D>0IR96%D(&%T(')O8F5R=&QR96%D+FYE
M="HJ,C P.# U,30P-#,W-# *(%1H:7,@:7, at 86X@871T96UP="!T;R!M86ME
M($5L97!H86YT(')E861Y(&9O<B!#3$)524Q$"ET@"EM-86MI;F=#3$)U:6QD
M4F5A9'D*<F5A9"!A="!R;V)E<G1L<F5A9"YN970J*C(P,#@P-3$T,#0S-C4T
M72 *6TUA:VEN9T5L97!H86YT0TQ"54E,1%)E861Y"G)E860 at 870@<F]B97)T
M;')E860N;F5T*BTR,# X,#4Q-# S,3DR,ET@"EM3=6)M:71T9610871C:$9O
M<D%"=6<*<F5A9"!A="!R;V)E<G1L<F5A9"YN970J*C(P,#@P-3$T,#,R,#,Q
M"B!3;W)R>2P at 22!F;W)G;W0@=VAO('-U8FUI='1E9"!T:&ES(&)U9R!F:7 at N
M"ET@"EM-86MI;F=%;&5P:&%N=$-,0E5)3$1296%D>0IR96%D(&%T(')O8F5R
M=&QR96%D+FYE="HJ,C P.# U,30P,S$Y,C)=( I;1FEX960 at 8G5G(&EN('!E
M<G-I<W1E;G0 at 8VQA<W,@=F5R:69I8V%T:6]N+"!A8G-T<F%C=&5D('9E<FEF
M:6-A=&EO;@IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#4Q,S$U,CDQ
M,UT@"EM0871H;F%M92!A<F=U;65N="!T;R!D8BUB9&(@;W!E;BUC;VYT<F]L
M;&5R('!A=&-H"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P-3$S,3,U
M.#4U72 *6T%D9" J9&5F875L="UR971R:65S*B!T;R!E;&5P:&%N="!T<F%N
M<V%C=&EO;B!M;V1E;#L@=W)A<"!D96QE=&4@<&]B:B!I;B!T>&X*97-L:6-K
M0&-O;6UO;BUL:7-P+FYE="HJ,C P.# U,3,Q,3 U,SE=( I;1FEX(&UA<"UB
M=')E92!F86EL=7)E('1O(&-H96-K(&EI9B!F:7)S="!V86QU92!I;B!A(')A
M;F=E(&UA<"!I<R!O=70@;V8@<F%N9V4*97-L:6-K0&-O;6UO;BUL:7-P+FYE
M="HJ,C P.# U,3(Q.#(Y-35=( I;1&5F875L="!T;R!N;VXM:6YH97)I=&5D
M(&EN9&5X+"!A9&1E9" Z:6YH97)I="!S;&]T(&]P=&EO;B M('!U<V@@.F5L
M97!H86YT(&]N=&\@*F9E871U<F5S<RHJ"F5S;&EC:T!C;VUM;VXM;&ES<"YN
M970J*C(P,#@P-3$P,C(T-S0U72 *6V-L+7-Q;"!I;7!L96UE;G1I;F<@26%N
M)W,@;6%J;W(@9F5A='5R97,*<F5A9"!A="!R;V)E<G1L<F5A9"YN970J*C(P
M,#@P-3 T,C,P-3(P"B!!;'1H;W5G:"!T:&ES(&ES(&%L;"!G<F5E;BP@:70@
M:7, at 8V5R=&%I;FQY(&YO="!P97)F96-T+ at H@22!A;2!C:&5C:VEN9R!I;B!I
M="!I;B!H;W!E<R!I="!W:6QL(&AE;' @=&AE('!O<W1M;V1E<FX*(&=U>7,L
M('1H;W5G:"!I;B!H:6YD<VEG:'0 at 22!D;W5B="!I="!W:6QL+"!M=6-H+B!)
M)VT at 86QS;PH@<W1A<G1I;F<@=&\@=&AI;FL@=&AE(&-L+7-Q;"!B86-K96YD
M('-H;W5L9"!B92!D97!R96-A=&5D+ at H@"ET@"EM-;W9E(&1E<&5N9&5N8VEE
M<R!O;B!B;W)D96%U>"!T:')E861S('1O(&5L97!H86YT+71E<W1S"F5S;&EC
M:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P-3 S,30P-#4P72 *6T-O9&4@<F5O
M<F<L('=A<FYI;F<@<F5M;W9E+"!B=6<@9FEX(&EN(&-H86YG92UC;&%S<PIE
M<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#4P,S$T,#(S-%T@"EM!9&0@
M<W5P<&]R="!F;W(@8G5L:R!R96%D<SL at 9FEX(&$@9F5W('-M86QL(&)U9W,[
M('1R86YS:65N="!T;R!P97)S:7-T96YT(&-H86YG92!C8VQA<W,@<W5P<&]R
M= IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#4P,S$R,C$Q,%T@"EMU
M;BUD:7-A8FQE9"!T97-T<R!F;W(@4T)#3 IA;&5X+FUI>G)A:&E 9VUA:6PN
M8V]M*BHR,# X,#0Q,# W,#@P-5T@"EMD8BUP;W-T;6]D97)N.B!S>6YC+6-A
M8VAE('1Y<&4@:&%N9&QI;F<@9FEX"F%L97 at N;6EZ<F%H:4!G;6%I;"YC;VTJ
M*C(P,#@P,S(V,C(R,#$X72 *6W1E<W0 at 8V]N8W5R<F5N8WD at 97AT96YD960*
M86QE>"YM:7IR86AI0&=M86EL+F-O;2HJ,C P.# S,C8R,#,Q-#==( I;=')A
M;G-A8W1I;VX@<F5S=&%R="!S=7!P;W)T('!L=7, at 97AT96YD960@9F5A='5R
M97,*86QE>"YM:7IR86AI0&=M86EL+F-O;2HJ,C P.# S,C8R,#,P,#5=( I;
M9&(M<&]S=&UO9&5R;CH@=')A;G-A8W1I;VX@<F5T<GD@:&%N9&QI;F<L('-E
M<FEA;&EZ86)L92!I<V]L871I;VX*86QE>"YM:7IR86AI0&=M86EL+F-O;2HJ
M,C P.# S,3 at Q-34T-#1=( I;9&(M<&]S=&UO9&5R;CH@<VUA;&P@<WEN8R!C
M86-H92!F:7@*86QE>"YM:7IR86AI0&=M86EL+F-O;2HJ,C P.# S,3 at Q-34Q
M,CD*(&-A8VAE('=A<R!D:7-C87)D960@:6X at 96UP='D@='AN"ET@"EM$:7-A
M8FQI;F<@=&AR96%D:6YG('1E<W1S(&9O<B!30D-,"E)O8F5R="!,+B!296%D
M*BHR,# X,#0Q,# Q-34T-%T@"EM#:'5N(%1I86XG<R!C;VYD:71I;VYA;"!F
M;W(@;&ES<'=O<FMS('-L;W0M9&5F:6YI=&EO;BUA;&QO8V%T:6]N"G-R;W-S
M0&-O;6UO;BUL:7-P+FYE="HJ,C P.# T,38Q-C$P,3!=( I;<W!E;&QI;F<@
M97)R;W)S"E)O8F5R="!,+B!296%D*BHR,# X,#0P.#$T,# T.5T@"EM$0BU0
M3U-434]$15)..B!R96UO=F4 at 1$)032U%4E)/4CL at 9&]N)W0 at 871T96UP="!T
M;R!R96UO=F4 at 86X@86QR96%D>2!P<F5P87)E9"!S=&%T96UE;G0@*'!O:6YT
M;&5S<R!S:6YC92!T:&4@='AN(&ES(&%B;W)T960 at 870@=&AE('1I;64I.R!D
M969E<B!A;&P at 97)R;W)S('1O('1X;B!H86YD;&5R("AB=70@=V%R;B!A;F0@
M<')I;G0@=&AE(&]F9F5N9&EN9R!S=&%T96UE;G0I"G!O;'IE<D!G;G4N;W)G
M*BHR,# X,#,Q-S$W,3(U-%T@"EM#:&%N9V5D(&5R<F]N96]U<R!S=&%T96UE
M;G0@:6X@='5T;W)I86P@=&AA="!I;F1E>"!C;VUP87)I<V]N('5S97, at 15%5
M04Q0+ at IP;VQZ97) 9VYU+F]R9RHJ,C P.# R,C8Q,C,R-3)=( I;1$(M4$]3
M5$U/1$523CH@<W5P<&]R="!T<F%N<V%C=&EO;B!R971R:65S.R!H86YD;&4@
M9&5A9&QO8VL[(&%D9"!S879E<&]I;G0@=71I;&ET>2!F=6YC=&EO;G,[(&%D
M9"!W87)N:6YG<R!T;R!H96QP(&1E8G5G9VEN9R!P<F]B;&5M871I8R!C;VYD
M:71I;VYS+ at IP;VQZ97) 9VYU+F]R9RHJ,C P.# S,#8Q,C0U,CA=( I;861D
M960 at 0D]21$5!55 at M5$A214%$4R!D97!E;F1E;F-Y(&%N9"!C:&%N9V5D(%!-
M(&-O;G1R;VQL97(@=&\@=7-E(&ET(&EN<W1E860@;V8 at 4T(M5$A214%$('-T
M=69F+ at IP;VQZ97) 9VYU+F]R9RHJ,C P.# S,#8Q,C0U,3)=( I;861D960@
M8V]N8W5R<F5N8WD@=&5S="!C87-E<RX*<&]L>F5R0&=N=2YO<F<J*C(P,#@P
M,S V,3(T-# W72 *6T1"+5!/4U1-3T1%4DXZ(')E87 @;VQD(&-O;FYE8W1I
M;VYS('=H96X at 82!N97<@;VYE(&ES(')E<75E<W1E9"X*<&]L>F5R0&=N=2YO
M<F<J*C(P,#@P,C(W,34P,S(R72 *6U)E;6]V92!O;&0 at 9FEL97,*97-L:6-K
M0&-O;6UO;BUL:7-P+FYE="HJ,C P.# S,C4Q-3 V,3A=( I;861D('-L;W0M
M=6YB;W5N9"!T97-T"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,S(U
M,3(P-3(P72 *6T%D9"!S8VAE;6$M979O;'5T:6]N+FQI<W *97-L:6-K0&-O
M;6UO;BUL:7-P+FYE="HJ,C P.# S,C4P,C4U,3==( I;4T)#3"!C;VUP871I
M8FEL:71Y(&9I>&5S.R!M:6=R871I;VX at 9FEX97,[('-M86QL(&)U9R!F:7AE
M<PIE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,R,S$T,S0R-UT@"EM$
M97)I=F5D(&EN9&5X('-L;W1S.R!S=7!P;W)T(&UI9W)A=&4O=7!G<F%D93L@
M9FEX('-C:&5M82!E=F]L=71I;VX at 8G5G<PIE<VQI8VM 8V]M;6]N+6QI<W N
M;F5T*BHR,# X,#,R,C(P-3DU,UT@"EM"971T97(@97AP;&EC:70@=G,N('-L
M;W0 at 87-S;V-I871I;VX@=&5S= IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR
M,# X,#,R,3$P-#8T.%T@"EM&:7@@8G5G(&EN(&UA<"!O:61S"F5S;&EC:T!C
M;VUM;VXM;&ES<"YN970J*C(P,#@P,S(Q,3 T-C$Q72 *6T%D9"!T;R!L;V%D
M('-Y<W1E;0IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,R,#$X,3$Q
M.5T@"EM!9&0 at 87-S;V-I871I;VX@=&5S="!F:6QE.R!F:7@@87-S;V-I871I
M;VX at 8G5G<PIE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,R,#$X,#DR
M.5T@"EM!4$D@<')O<&]S86P at 9F]R(&%S<V]C:6%T:6]N('-L;W1S"F5S;&EC
M:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,S(P,#(R,30Q72 *6TEM<&QE;65N
M="!A<W-O8VEA=&EO;G,[(&9I>"!S;VUE(&EN9&5X:6YG+7)E;&%T960 at 8G5G
M<SL@,B!F86EL:6YG('1E<W1S(&QE9G0*97-L:6-K0&-O;6UO;BUL:7-P+FYE
M="HJ,C P.# S,C P,3 Y-35=( I;1FEX(&UE=&%P<F]T;V-O;"!E<G)O<G,L
M('-O;64 at 8V]D92!R96]R9R!A;F0 at 9FEX:6YG('1H92!C:&%N9V4M8VQA<W,@
M=&5S="!T;R!M871C:"!-3U @<W!E8PIE<VQI8VM 8V]M;6]N+6QI<W N;F5T
M*BHR,# X,#,Q.# T,3<T.5T@"EM&:6YI<V@@86YD(&%D9"!S:6UP;&4@<75E
M<GD@:6YT97)P<F5T97(*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# S
M,3$Q-34T,3E=( I;4&%T8V@@<V5R:6%L:7IE<B!F;W(@=6YB;W5N9"!S;&]T
M(&5R<F]R(&9O<B!N;W<[(&%D9" Z:6YD97@@87,@=F%L:60@:6YI=&%R9PIE
M<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,Q,3$U-3$U-ET@"EM&:7AE
M9"!A(&UY<FEA9"!O9B!P<F]B;&5M<R!I;B!S8VAE;6$@979O;'5T:6]N"F5S
M;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,S$Q,#4P.3$U"B *(%-C:&5M
M82!C:&%I;G, at 87)E('!R;W!E<FQY(&UA:6YT86EN960*(%-C:&5M82!I9',@
M<')O<&5R;'D@=7!D871E9"!I;B!I;G-T86YC92UT86)L90H at 26YD97AE9"!S
M;&]T<R!P;W!U;&%T960@;VX@=7!G<F%D92 H:6YD97AE<R!A<F4@:6YC;VAE
M<F5N="!I9B!L87IY('5P9&%T:6YG(2D*(&UA<"UC;&%S<R!A9&IU<W1E9"!T
M;R!W;W)K('=I=&@@86YD('5P9W)A9&4@<')I;W(@:6YS=&%N8V5S"B!E;G-U
M<F4@<')O<&5R(&EN:71I86QI>F%T:6]N(&]F('9A;'5E<PH@<W!E960@=7 @
M=')A;G-A8W1I;VYS(&9O<B!P97)S:7-T96YT(&EN<W1A;F-E(&-R96%T:6]N
M( H@"ET@"EM-87-S:79E('5P9W)A9&4@;V8@;F5W('-C:&5M82UE=F]L=71I
M;VX at 9G5N8W1I;VYA;&ET>3L at 8G5G(&9I>&5S"F5S;&EC:T!C;VUM;VXM;&ES
M<"YN970J*C(P,#@P,S$Q,#,T,S$W"B *($9E871U<F5S. at H@4&%R=&EA;&QY
M('=O<FMI;F<@<W5P<&]R="!F;W(@8VAA;F=E+6-L87-S+"!R961E9FEN92UC
M;&%S<RP@=7!D871E+6EN<W1A;F-E+2H*(%-U<'!O<G0 at 9F]R('-T;W)E('-Y
M;F-H<F]N:7IA=&EO;B!A;F0 at 979O;'5T:6]N(&]F(&1B(&EN<W1A;F-E<R!A
M;F0@<W1O<F%G90H at 3&]T<R!O9B!L:71T;&4@:6YT96=R871I;VX@:7-S=65S
M(&%N9"!R969A8W1O<FEN9PH@"B!"=6=S. at H@061D960@=6YB;W5N9"!S;&]T
M(&5D:71S"B!&:7AE9"!L:71T;&4 at 8G5G<R!H:61I;F<@:6X@<V5R:6%L:7IE
M<BP at 8G1R964@:6UP;&5M96YT871I;VXL(&)T<F5E(&UA<'!I;F<@9G5N8W1I
M;VYS+" *($9I>&5D('-O;64@;&ET=&QE(&)U9W,@:&ED:6YG(&EN(&)D8 at H@
M061D960@=&5S=', at 9F]R(&1U<"UB=')E97, at 86YD('1O('1E<W0 at 9F]R(&)T
M<F5E(&)U9W, at 9G)O;2!B969O<F4*( H@"ET@"EM-;W)E(&5F9FEC:65N="!G
M970M8V]N(&9U;F-T:6]N86QI='D[(&5N<W5R92!F:6YA;&EZ960 at 8VQA<W,@
M=VAE;B!R96=I<W1E<FEN9R!A('-C:&5M80IE<VQI8VM 8V]M;6]N+6QI<W N
M;F5T*BHR,# X,#,P-S W,#,T.%T@"EM687)I;W5S(&9I>&5S('1O(&EN9&5X
M:6YG+"!S970M=F%L=65D('-L;W1S+"!E=&, at 86YD(&9I>&5S('1O(&EN9&5X
M:6YG('1E<W1S"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,S W,#8Q
M,S,P72 *6TEM<&QE;65N="!C86-H960@<VQO=',[(&)A<VEC(&EN9&5X960@
M<VQO=',[('-O;64@=V]R:R!O;B!I;F1E>&5D('1E<W1S"F5S;&EC:T!C;VUM
M;VXM;&ES<"YN970J*C(P,#@P,S W,#4S-#(Y72 *6T9I>"!S97)I86QI>F5R
M(&)U9W, at 9F]R(&QE>&EC86P at 97$[(&)D8B!D969A=6QT(&-I9"!B=6<*97-L
M:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# S,#<P-3,Q,#E=( I;1FEX(&)U
M9W,@<F5L871E9"!T;R!I;F1E>&5D(&-L87-S97,[(&1R;W M:6YS=&%N8V5S
M"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,S V,C$S.34R72 *6T9I
M>"!D96QE=&4@:6X at 9'5P(&)T<F5E"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J
M*C(P,#@P,S V,3DQ-#(W72 *6T9I>"!B9&(M8V]N=')O;&QE<B!I;FET:6%L
M:7IA=&EO;B!F;W(@:6YD97AE9"!B=')E97,*97-L:6-K0&-O;6UO;BUL:7-P
M+FYE="HJ,C P.# S,#8Q.#4V,#%=( I;07-S;V-I871I;VX at 961I=',L(&1U
M<"!B=')E92!F:7AE<RP@<F5M;W9E('1E<W0@:&%R;F5S<R!S='5F9 at IE<VQI
M8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,P-C$V,#(Q-%T@"EM&:7@@0D1"
M(&-O;7!A<FES;VX at 9FX@86YD(&%D9"!K97D@=G,@=F%L=64 at 8V]M<&%R:7-O
M;G,*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# S,#8Q-34Y,S)=( I;
M061D960@<V5T+79A;'5E9"!S;&]T<RP at 9FEX960@8G5G(&EN(&UA<"UC;&%S
M<RP@:&%N9&QE('-E="UV86QU960@<VQO="!I;FET<PIE<VQI8VM 8V]M;6]N
M+6QI<W N;F5T*BHR,# X,#,P-3(Q,C$P.5T@"EM);FET:6%L(')E;W)G('1O
M('-U<'!O<G0@,"XY+C(@9F5A='5R92!S970[('-O;64@=V]R:VEN9R!F96%T
M=7)E<PIE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# X,#,P-#(R,S4P,0H@
M"B!(:65R87)C:&EC86P at 8VQA<W,@:6YD97AI;F<*($-L87-S('-C:&5M87,*
M($1U<&QI8V%T92!B=')E97,*($QA>GD at 9&5S97)I86QI>F%T:6]N('-U<'!O
M<G0*( H@"ET@"EM#:&5C:R!F;W(@=6YB;W5N9"!S;&]T.R!P;W1E;G1I86P@
M9FEX(&9O<B!A(&-O;7!I;&5R(&5R<F]R"F5S;&EC:T!C;VUM;VXM;&ES<"YN
M970J*C(P,#@P,C(V,3DU.#,Y72 *6T9I>"!T97-T(&1E<&5N9&5N8V4 at 9F]R
M(&9F+6EN9&5X+71E<W0*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# R
M,C8Q-3$V-31=( I;26UP<F]V92!B97)K96QE>2!$0B!V97)S:6]N(&%G;F]S
M=&EC(&-O9&4*97-L:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# R,C8Q-3$T
M-3,*( H at 061D960@86X at 97)R;W(@;65S<V%G92!T;R!C;VYF:6=U<F4@;7DM
M8V]N9FEG+G-E>' @86YD(&UA9&4@<W5R92!W92!L;V%D"B!I="!D:7)E8W1L
M>2!F<F]M(&UY+6-O;F9I9RYS97AP('-O('1H870@=V4 at 9V5T(&ET(')I9VAT
M(&%T(&QO860@=&EM92X*(%!R:6]R('!A=&-H(&1I9&XG="!O=F5R<FED92!D
M969A=6QT('5N=&EL(&%F=&5R(&QO860@=&EM92X*( I=( I;4W5P<&]R="!F
M;W(@;75L=&EP;&4 at 0D1"('9E<G-I;VYS"F5S;&EC:T!C;VUM;VXM;&ES<"YN
M970J*C(P,#@P,C(V,34P,3$T72 *6V1B+6)D8B!U<&1A=&5D('1O($)E<FME
M;&5Y1$(@-"XV"FMA>F5N;FEK;W9 9VUA:6PN8V]M*BHR,# W,3(S,#$T,#<S
M,0H at 0VAA;F=E9"!O;FQY($)$0B!C;VYS=&%N=', at 87,@=7!G<F%D92 T+C4@
M+3X at -"XV('1H97D@=V5R90H at 8VAA;F=E9"X*($$@:VEN9"!O9B!H86-K('!E
M<FAA<',N($)U="!I="!W;W)K<RX at 5&AE('1E<W1I;F<@=V%S(&YO="!E>&-E
M<W-I=F4L"B!B=70@:70@=V]R:W,@=V5L;"!F;W(@;7D@<')O:F5C="X*72 *
M6V%D9"!T97-T(&9O<B!35%))3D<@='EP97,@*&%S(&]P<&]S960@=&\@4TE-
M4$Q%+5-44DE.1R!T>7!E<RD*<&]L>F5R0&=N=2YO<F<J*C(P,#@P,C(R,#@Q
M,C4V72 *6U)E9F%C=&]R(%541GLQ-BPS,GU,12!S97)I86QI>F5R<RX*<&]L
M>F5R0&=N=2YO<F<J*C(P,#@P,C(R,#@T.#(T72 *6T5N86)L92!M=6QT:7!L
M92!P<F]C97-S(&-O;FYE8W1I;VYS('1O(&$@0D1"(&1A=&$M<W1O<F4@=FEA
M($1"7U)%1TE35$52(&]P=&EO;@IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR
M,# X,#(R-3(R,C<Q,UT@"EM%;F%B;&4@;75L=&DM<W1O<F4@:6YD97AE9"!C
M;&%S<V5S"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,C(S,3 at T-3 T
M72 *6T-H86YG92!S96UA;G1I8W,@;V8@=')A;G-A8W1I;VX at .G)E=')Y+6-O
M=6YT(&9R;VT@=')I97,@=&\@<F5T<FEE<PIE<VQI8VM 8V]M;6]N+6QI<W N
M;F5T*BHR,# X,#(R,3 S,3 Q-5T@"EM-:6YO<B!E9&ET<RP at 9FEX960@82!C
M;VUM96YT+"!F:7AE9"!A(&1B+6QI<W @;W5T(&]F(&1A=&4 at 97)R;W(*97-L
M:6-K0&-O;6UO;BUL:7-P+FYE="HJ,C P.# R,C$P,C0Q-3%=( I;06QE>"=S
M('!A=&-H(&9O<B X+C,*<F5A9$!R;V)E<G1L<F5A9"YN970J*C(P,#@P,C$W
M,C(S-3$R"B!)(&5N=&5R960@:&5R92!T:&4@<&%T8V@@9G)O;2!!;&5X(&]F
M(#(P.#@O,#(O,38*('=H:6-H(&%P<&%R96YT;'D@;6%K97,@=&AI<R!C;VUP
M871I8FQE('=I=&@@4&]S=&=R97, at ."XS+ at H@270@:7, at 9W)E96X at 9F]R(&UE
M(&]N(&%L;"!T97-T<R!O;B!0;W-G<F5S(#@N,2P@<V\@"B!)(&%M(&-O;6UI
M='1I;F<@:70N"ET@"EMM='EP92!C:&%N9V4@:6X at 9&-M"G)E861 <F]B97)T
M;')E860N;F5T*BHR,# X,#(Q-3$S-3 U-%T@"EMM;W9E9"!C86-H92UI;G-T
M86YC92!I;G1O(&EN:71I86PM<&5R<VES=&5N="US971U< IA;&5X+FUI>G)A
M:&E 9VUA:6PN8V]M*BHR,# X,#$R,#$T,C0S- at H@8F5C875S92!I="!W87,@
M8GEP87-S960 at 8GD@<F5C<F5A=&4M:6YS=&%N8V4@;W1H97)W:7-E"ET@"EMA
M8V-E<W-O<B!N86UE(&EN('1E<W1S(&-H86YG90IA;&5X+FUI>G)A:&E 9VUA
M:6PN8V]M*BHR,# X,#$Q-C(R,C0P-5T@"EMD8BUP;W-T;6]D97)N.B!P;2UB
M=')E92!I;FET:6%L:7IA=&EO;B!F:7AE9 IA;&5X+FUI>G)A:&E 9VUA:6PN
M8V]M*BHR,# X,#$Q-C(R,C,Q-ET@"EMR96-R96%T92UI;G-T86YC92!S='5F
M9B!I;7!R;W9E9 IA;&5X+FUI>G)A:&E 9VUA:6PN8V]M*BHR,# X,#$Q-C(R
M,#$S.%T@"EMD8BUP;W-T;6]D97)N.B!R96UO=F5D('-P96-I86QI>F5D(&UA
M<"UI;F1E> IA;&5X+FUI>G)A:&E 9VUA:6PN8V]M*BHR,# X,#$P-S$S-# Q
M, at H@8F5C875S92!P=7)E(&-U<G-O<B!V97)S:6]N('=O<FMS(&9I;F4 at 86YD
M(&ES(&UO<F4@<F]B=7-T"ET@"EMC=7)S;W(M9'5P;&EC871E(')E;6]V960@
M9G)O;2!D8BUP;W-T;6]D97)N"DAE;G)I:R!(:F5L=&4\:&5N<FEK0&5V86AJ
M96QT92YC;VT^*BTR,# W,3$R-#$V,S<P,5T@"EMD8BUP;W-T;6]D97)N(&9I
M>"!M87 M:6YD97@@;W!T:6UI>F%T:6]N(&)U9PI(96YR:6L at 2&IE;'1E(#QH
M96YR:6LN:&IE;'1E0'-T:7 at N=&\^*BHR,# X,#$P-#$U,38T-%T@"EMD8BUP
M;W-T;6]D97)N.B!C=7)S;W)S(')E+6EM<&QE;65N=&5D"F%L97 at N;6EZ<F%H
M:4!G;6%I;"YC;VTJ*C(P,#<Q,C$U,3DQ.# U72 *6V-O;G1R;VQL97(M9&]C
M+6EM<')O=F5M96YT"G)E861 <F]B97)T;')E860N;F5T*BHR,# X,#(Q,#$U
M-3<Q-ET@"EMT=71O<FEA; IR96%D0')O8F5R=&QR96%D+FYE="HJ,C P.# R
M,#,Q-C$U,S)=( I;;F]N+6ME>7=O<F0M86-C97-S;W)S"G-R;W-S0&-O;6UO
M;BUL:7-P+FYE="HJ,C P.# Q,3,Q-S,V,38*(&%L;&]W<R!L:7-P=V]R:W,@
M=&\@<G5N('1E<W1S+ at I=( I;9G5N8W1I;VXM8V%L;"UK97DM9F]R;0IS<F]S
M<T!C;VUM;VXM;&ES<"YN970J*C(P,#@P,3$S,3<S-30W72 *6V1O8W5M96YT
M871I;VX@='EP92!F:7@*<F5A9$!R;V)E<G1L<F5A9"YN970J*C(P,#@P,3$Q
M,34Q,3(T72 *6T9I>"!T:&4@=7-E(&]F(&EN=&5R;F%L('-Y;6)O;"!O9B!S
M8BUK97)N96P@:6X@;65M=71I;',*3&5O;F%R9&\@5F%R=7IZ82 \=F%R=7IZ
M84!G;6%I;"YC;VT^*BHR,# W,3(S,# P,#$R, H@"B!M96UU=&EL+FQI<W @
M=7-E('1H92!F=6YC=&EO;G,@<V(M:V5R;F5L.CIC;W!Y+2HM9G)O;2US>7-T
M96TM87)E82P@=VAI8V@*(&%R96XG="!E>'!O<G1E9"!I;B!T:&4@;&%T97-T
M('9E<G-I;VX@;V8@<V)C;"X*( H at 1FEX(&ET(&%D9&EN9R!T:&4 at .CH@=VAE
M;B!A<'!R;W!R:6%T90H@"ET@"EMD8BUB9&(@8G5G9FEX.B!W:&5N(&)D8B!K
M97D at 8V]M<&%R:7-O;B!C;VUP87)E9"!O;FQY('1H92!F:7)S="!H86QF(&]F
M('5T9C$V('-T<FEN9W,*:V%Z96YN:6MO=D!G;6%I;"YC;VTJ*C(P,#<Q,C,P
M,30Q,#4U72 *6T9I>"!I;G-T86YC92!D97-E<FEA;&EZ871I;VX@=&\@8GEP
M87-S(&EN:71I86QI>F%T:6]N('!R;W1O8V]L"G-R;W-S0&-O;6UO;BUL:7-P
M+FYE="HM,C P-S$R,30Q-#$Y,SA=( I;9&(M<&]S=&UO9&5R;CH@;W!T:6UI
M>F5D(&UA<"UI;F1E>"!F;W(@+6)Y+79A;'5E(&-A<V4*86QE>"YM:7IR86AI
M0&=M86EL+F-O;2HJ,C P-S$R,#<Q.34T,#)=( I;9&(M<&]S=&UO9&5R;CH@
M;W!T:6UI>F5D(&9O<FTM<VQO="UK97D at 9F]R('!E<G-I<W1E;G0M<VQO="UR
M96%D97(*86QE>"YM:7IR86AI0&=M86EL+F-O;2HJ,C P-S$R,#<R,# X,S4*
M(&ET('5S97, at 4T)#3"!I;G1E<FYA;"!F=6YC=&EO;B!N;W<L(&9O<B!O=&AE
M<B!I;7!L96UE;G1A=&EO;B!I="=S(&QE<W,@;W!T:6UI>F5D+ at I=( I;9&(M
M<&]S=&UO9&5R;CH@<VUA;&P at 97AA;7!L92!U<&1A=&4*86QE>"YM:7IR86AI
M0&=M86EL+F-O;2HJ,C P-S$R,#<R,# V,S!=( I;861D960@<V@@<V-R:7!T
M(&9O<B!F;'5S:&EN9R!L;V=S('-A;7!L90IA;&5X+FUI>G)A:&E 9VUA:6PN
M8V]M*BHR,# W,#DR,# Y-3 at P-ET@"EMD8BUP;W-T;6]D97)N(')E;6]V960@
M<&]S<VEB;&ET>2!O9B!U<VEN9R!.24P at 87, at 82!K97D@:6X at 8G1R965S"DAE
M;G)I:R!(:F5L=&4\:&5N<FEK0&5V86AJ96QT92YC;VT^*BHR,# W,3$R-#$V
M,S at R.%T@"EMC=7)S;W(M9'5P;&EC871E(')E;6]V960 at 9G)O;2!D8BUP;W-T
M;6]D97)N"DAE;G)I:R!(:F5L=&4\:&5N<FEK0&5V86AJ96QT92YC;VT^*BHR
M,# W,3$R-#$V,S<P,5T@"EMR96UO=F5D(&$@;&ET=&QE(&-O;7!I;&5R('=A
M<FYI;F<@*'1Y<&\I"DAE;G)I:R!(:F5L=&4\:&5N<FEK0&5V86AJ96QT92YC
M;VT^*BHR,# W,3$R,C$U,3DR.5T@"EMR96UO=F4@:VEN9"UH:6YT<R!P87)A
M;65T97(@9G)O;2!A9&0M:6YD97@*2&5N<FEK($AJ96QT93QH96YR:6M 979A
M:&IE;'1E+F-O;3XJ*C(P,#<Q,3(R,34Q,#0V"B!0<F]B86)L>2!A(&-O;6EN
M9R!F96%T=7)E(&9R;VT at 26%N+"!B=70*(')I9VAT(&YO=R!I="!B<F5A:W,@
M=&AE(&=E;F5R:6, at 9G5N8W1I;VX at 861D+6EN9&5X"B!A;F0@=&AU<R!P;W-T
M;6]D97)N+"!S;R!)(')E;6]V960@:70 at 9F]R(&YO=RX*72 *6T5N<W5R92!S
M970M9&(M<WEN8V@@:7, at 9&5F:6YE9"!B969O<F4@<'-E="!I<R!L;V%D960*
M<W)O<W- 8V]M;6]N+6QI<W N;F5T*BHR,# W,3(Q-#$T-3 T,5T@"EM&:7@@
M:6YS=&%N8V4 at 9&5S97)I86QI>F%T:6]N('1O(&)Y<&%S<R!I;FET:6%L:7IA
M=&EO;B!P<F]T;V-O; IS<F]S<T!C;VUM;VXM;&ES<"YN970J*C(P,#<Q,C$T
M,30Q.3,X72 *6T9I>"!T;R!F<F]M+65N9"!T<F%V97)S86P@;V8@;F5W(&UA
M<"UI;F1E> IE<VQI8VM 8V]M;6]N+6QI<W N;F5T*BHR,# W,3$S,#(R,S4R
M-%T@"EM.97<@;6%P+6EN9&5X(&EM<&QE;65N=&%T:6]N"F5S;&EC:T!C;VUM
M;VXM;&ES<"YN970J*C(P,#<Q,3,P,C(R-C(P72 *6T-H96%P97(@9V5T+6EN
M<W1A;F-E+6)Y+79A;'5E"F5S;&EC:T!C;VUM;VXM;&ES<"YN970J*C(P,#<Q
M,3,P,C(R-3(P72 *6U1!1R!%3$502$%.5"TP+3DM,0II97-L:6-K0&-O;6UO
M;BUL:7-P+FYE="HJ,C P-S$Q,38Q-3,V,S1=( I0871C:"!B=6YD;&4@:&%S
L:#H*.&)B-&8Q9&0R,S%D,C0R9F(Y-S4Y.39E-F5D.#8U-6-A-C0R8S4R- H`
`
end




From eslick at media.mit.edu  Wed Jun  4 12:48:20 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 4 Jun 2008 08:48:20 -0400
Subject: [elephant-devel] Re: unstable postmodern troubled..
In-Reply-To: <g25vob$j5o$1@ger.gmane.org>
References: <g1uue7$tu5$1@ger.gmane.org><C9C8C20A-0141-4344-859F-712495FE2997@media.mit.edu><g21m9d$7hi$1@ger.gmane.org>
	<A400D305-5509-4933-959E-50A8AE8A2B32@media.mit.edu>
	<g25vob$j5o$1@ger.gmane.org>
Message-ID: <87655A2F-57E8-439F-9003-B18798C29830@media.mit.edu>

Ok, I'll try to integrate this in the next day or two and promote it.

Ian

On Jun 4, 2008, at 7:53 AM, Alex Mizrahi wrote:

> here are patches for elephant-unstable.
> it still doesn't work perfectly, errors are quite weird:
> odd test runs (1, 3..) work fine, but even ones (2, 4..)  complete  
> with two
> errors, iirc UPDATE-CLASS
> and INDEX-REDEFINE, something like that. i hope that are minor errors.
> also some minor fixes are pending -- i.e. cursor-delete on dup-btree  
> to
> delete only one row.
>
> IE> Anything else?
>
> well, postmodern techinically supports (or is close to that)  
> association and
> stuff,
> but default-pset implementation for it is a joke -- it creates a new
> database table
> for each pset. so it needs specialized pset implementation to be  
> actually
> usable.
>
>
> <pm-patch01.hunks>



From killerstorm at newmail.ru  Wed Jun  4 14:30:02 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 17:30:02 +0300
Subject: [elephant-devel] pending patches
Message-ID: <6DD5902D5886480799FE8708E984B445@killer>

 pending patches for stable branch:

[fix for initialize-user-parameters
alex.mizrahi at gmail.com**20080413131102]

;; initialize-user-parameters was totally broken..

[serializer thread safety (temp)
alex.mizrahi at gmail.com**20080528152446]

;; fix for serializer2 race conditions

[race condition in memutil
alex.mizrahi at gmail.com**20080530141323]

;; same kind of race condition in memutil

[Fix MAKE-LOCAL-NAME so it produces keywords instead of randomly 
package-scoped reader-interned symbols.
polzer at gnu.org**20080430121024]

[MAP-INVERTED-INDEX-1 test fixed
alex.mizrahi at gmail.com**20080604140448]

;; test was a bit broken, opening BDB store itself

;;;;;;;;;;;;;; and these patches bundled for unstable:

[race condition in memutil
alex.mizrahi at gmail.com**20080530141323]

[Fix MAKE-LOCAL-NAME so it produces keywords instead of randomly 
package-scoped reader-interned symbols.
polzer at gnu.org**20080430121024]

[one more race condition in serializer2
alex.mizrahi at gmail.com**20080604142449] 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unstable01.patch
Type: application/octet-stream
Size: 15300 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080604/bad1e1b0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stable01.patch
Type: application/octet-stream
Size: 24006 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080604/bad1e1b0/attachment-0001.obj>

From killerstorm at newmail.ru  Wed Jun  4 14:44:55 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 17:44:55 +0300
Subject: [elephant-devel] remove-current-kv  does not work as advertised!
Message-ID: <E1044DDD9A634175B775475AFD698051@killer>

(defvar *current-cursor* nil
  "This dynamic variable is referenced only when deleting elements
   using the following function.  This allows mapping functions to
   delete elements as they map.  This is safe as we don't revisit
   values during maps")

(defun remove-current-kv ()
  (unless *current-cursor*
    (error "Cannot call remove-current-kv outside of a map-btree or 
map-index function argument"))
  (cursor-delete *current-cursor*))

it's supposed that while cursor is iterated in map-btree, we can remove 
current element and then jump to next.

but cursor-delete leaves cursor unitialized, so cursor-next will instead 
jump to first item, and iteration will be restarted.

so, finally it will work (i think), but it's damn slow and painful 
procedure.

i think it's better to remove this functionality, or fix this. if we are not 
going to change cursor-delete
semantics, a way to delete item without making cursor unintialized is 
something like:

(defun remove-current-kv ()
  (unless *current-cursor* (error "Cannot call remove-current-kv outside of 
a map-btree or map-index function argument"))
  (let ((c (cursor-duplicate *current-cursor*)))
     (cursor-delete c)))

but i dunno if it will work in BDB 



From killerstorm at newmail.ru  Wed Jun  4 14:44:55 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 17:44:55 +0300
Subject: [elephant-devel] remove-current-kv  does not work as advertised!
Message-ID: <E1044DDD9A634175B775475AFD698051@killer>

(defvar *current-cursor* nil
  "This dynamic variable is referenced only when deleting elements
   using the following function.  This allows mapping functions to
   delete elements as they map.  This is safe as we don't revisit
   values during maps")

(defun remove-current-kv ()
  (unless *current-cursor*
    (error "Cannot call remove-current-kv outside of a map-btree or 
map-index function argument"))
  (cursor-delete *current-cursor*))

it's supposed that while cursor is iterated in map-btree, we can remove 
current element and then jump to next.

but cursor-delete leaves cursor unitialized, so cursor-next will instead 
jump to first item, and iteration will be restarted.

so, finally it will work (i think), but it's damn slow and painful 
procedure.

i think it's better to remove this functionality, or fix this. if we are not 
going to change cursor-delete
semantics, a way to delete item without making cursor unintialized is 
something like:

(defun remove-current-kv ()
  (unless *current-cursor* (error "Cannot call remove-current-kv outside of 
a map-btree or map-index function argument"))
  (let ((c (cursor-duplicate *current-cursor*)))
     (cursor-delete c)))

but i dunno if it will work in BDB 



From eslick at media.mit.edu  Wed Jun  4 15:18:56 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 4 Jun 2008 11:18:56 -0400
Subject: [elephant-devel] remove-current-kv  does not work as advertised!
In-Reply-To: <E1044DDD9A634175B775475AFD698051@killer>
References: <E1044DDD9A634175B775475AFD698051@killer>
Message-ID: <AA5D55F7-7D53-4E94-81B9-30AF12A91480@media.mit.edu>

remove-current-kv assumes a fix to cursor-delete that robert and I  
talked about that I forgot to do.

My proposal for this was to change the semantics so that the  
consequences of cursor operations that assume the data is valid (i.e.  
other than next/prev, etc) are undefined.  In this way the cursor is  
still valid after a delete, but only certain operations are guaranteed  
to work.  In a normal map operation, the map function would exit and  
be called on the next item in the sequence.

Will these semantics work for postmodern?

Ian

On Jun 4, 2008, at 10:44 AM, Alex Mizrahi wrote:

> (defvar *current-cursor* nil
> "This dynamic variable is referenced only when deleting elements
>  using the following function.  This allows mapping functions to
>  delete elements as they map.  This is safe as we don't revisit
>  values during maps")
>
> (defun remove-current-kv ()
> (unless *current-cursor*
>   (error "Cannot call remove-current-kv outside of a map-btree or  
> map-index function argument"))
> (cursor-delete *current-cursor*))
>
> it's supposed that while cursor is iterated in map-btree, we can  
> remove current element and then jump to next.
>
> but cursor-delete leaves cursor unitialized, so cursor-next will  
> instead jump to first item, and iteration will be restarted.
>
> so, finally it will work (i think), but it's damn slow and painful  
> procedure.
>
> i think it's better to remove this functionality, or fix this. if we  
> are not going to change cursor-delete
> semantics, a way to delete item without making cursor unintialized  
> is something like:
>
> (defun remove-current-kv ()
> (unless *current-cursor* (error "Cannot call remove-current-kv  
> outside of a map-btree or map-index function argument"))
> (let ((c (cursor-duplicate *current-cursor*)))
>    (cursor-delete c)))
>
> but i dunno if it will work in BDB
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From killerstorm at newmail.ru  Wed Jun  4 20:38:17 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 23:38:17 +0300
Subject: [elephant-devel] remove-current-kv  does not work as advertised!
References: <E1044DDD9A634175B775475AFD698051@killer>
	<AA5D55F7-7D53-4E94-81B9-30AF12A91480@media.mit.edu>
Message-ID: <05475D1C7021499185501CDCA198CC9B@killer>

 IE> Will these semantics work for postmodern?

sure, to add this feature i just need to remove one line of code :) -- that 
closes cursor on delete.
pm-cursor caches current value, so even cursor-current will return 
something. 



From killerstorm at newmail.ru  Wed Jun  4 20:38:17 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Wed, 4 Jun 2008 23:38:17 +0300
Subject: [elephant-devel] remove-current-kv  does not work as advertised!
References: <E1044DDD9A634175B775475AFD698051@killer>
	<AA5D55F7-7D53-4E94-81B9-30AF12A91480@media.mit.edu>
Message-ID: <05475D1C7021499185501CDCA198CC9B@killer>

 IE> Will these semantics work for postmodern?

sure, to add this feature i just need to remove one line of code :) -- that 
closes cursor on delete.
pm-cursor caches current value, so even cursor-current will return 
something. 



From gtarcea at umich.edu  Fri Jun  6 11:18:06 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Fri, 6 Jun 2008 07:18:06 -0400
Subject: [elephant-devel] BDB Constants generation
Message-ID: <10AE9D06-D559-455C-9638-3724EE9A176C@umich.edu>

I <think> this will work to remove the dependency on hand generating  
the berkeley-constants.lisp file constants (but not the structures).  
As long as the structures don't change between BDB releases, it  
should remove the explicit dependency on a version of BDB.

=======================
asdf file:

(defvar *gcc* "gcc")

(defclass grovel-file (cl-source-file) ())

(defmethod perform ((o compile-op) (c grovel-file))
   (let* ((output-file (car (output-files o c)))
        (filename (component-pathname c))
        (c-source (merge-pathnames "tmp.c" output-file))
        (a-dot-out (merge-pathnames "a.out" output-file))
        (constants (merge-pathnames "grovel.lisp-temp" output-file))
        (*grovel*))
      (declare (special *grovel*))
      (load filename)
      (and (funcall (the function *grovel*) c-source a-dot-out  
constants)
          (compile-file constants :output-file output-file))))

(defsystem xxxx
    ...
    :components ((:file "defpackage"
                        (:grovel-file "grovel-constants"
                        ....))
  :depends-on (:uffi ....))

=======================

grovel-constants.lisp:

(defun write-groveler (file constants)
     (with-open-file (f file :direction :output :if-exists :supersede)
        (let ((*print-case* :upcase))
          (format f "
#include <...>

void defconstant(char *lisp_name, long unix_number)
{
     printf(\"(defconstant %s %ld); #x%lx\\n\", lisp_name, unix_number);
}

int main()
{
    printf(\"(in-package : THE PACKAGE WE ARE DEFINING)\\n\") ;")
       (dolist (c constants)
          (format f "~&    defconstant(\"~A\", ~A);~%" (car c) (cdr c)))
       (format f "
     return 0 ;
}"))))


(unless (boundp *grovel*)
    (error "No GROVEL hook!"))

(defvar *grovel*)

(setf *grovel*
     (lambda (c obj lisp)
         (write-groveler c
              '(;; BDB Constants
                  (db_create . DB_CREATE)
                ...)))
            (and (zerop (run-shell-command "~A ~A -o ~A"
                          *gcc*
                          (namestring c)
                          (namestring obj)))
                    (zerop (run-shell-command "~A > ~A"
                              (namestring obj)
                              (namestring lisp))))))

======================

This will create a c file and corresponding binary for generating the  
lisp defining the constants. I am using this to generate all the  
constant declarations I need for System V IPC access (eg, IPC_STAT,  
IPC_RMID, etc...). I got much of the structure for this from OSICAT  
with some cleanup and changes on my part.

Glenn






From arnaudpourseb at gmail.com  Mon Jun  9 22:03:15 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Mon, 9 Jun 2008 17:03:15 -0500
Subject: [elephant-devel] Opening new database in unstable
Message-ID: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>

I tried to install elephant-unstable this morning (as drop-instance and some
keyword arguments are not available in 0.9.1 i guess you are testing
weblocks against unstable now), but i get this error when creating
(elephant:open-store '(:clsql (:sqlite3 "/tmp/blog.db"))):

"When attempting to set the slot's value to #<SQL-BTREE oid:1> (SETF of
SLOT-VALUE), the slot DB-CLSQL::CLASS-ROOT is missing from the object
#<SQL-STORE-CONTROLLER (SQLITE3 /tmp/blog.db)>"

Thank you for you help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080609/d47f162f/attachment.html>

From read at robertlread.net  Tue Jun 10 02:35:03 2008
From: read at robertlread.net (Robert L. Read)
Date: Mon, 09 Jun 2008 21:35:03 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
Message-ID: <1213065303.29423.1667.camel@penguin.yourdomain.com>

I'll try this and report back.  I haven't tested with sqlite3 since I
switched to a 64-bit computer.  


On Mon, 2008-06-09 at 17:03 -0500, Sebastian Georges wrote:
> I tried to install elephant-unstable this morning (as drop-instance
> and some keyword arguments are not available in 0.9.1 i guess you are
> testing weblocks against unstable now), but i get this error when
> creating (elephant:open-store '(:clsql (:sqlite3 "/tmp/blog.db"))):
> 
> "When attempting to set the slot's value to #<SQL-BTREE oid:1> (SETF
> of SLOT-VALUE), the slot DB-CLSQL::CLASS-ROOT is missing from the
> object #<SQL-STORE-CONTROLLER (SQLITE3 /tmp/blog.db)>"
> 
> Thank you for you help
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From read at robertlread.net  Tue Jun 10 03:40:05 2008
From: read at robertlread.net (Robert L. Read)
Date: Mon, 09 Jun 2008 22:40:05 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <1213065303.29423.1667.camel@penguin.yourdomain.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
Message-ID: <1213069205.29423.1677.camel@penguin.yourdomain.com>

This is working for me with the idiom from tests/RUNTESTS:


(setq *default-spec*
  `(:clsql (:sqlite3 
	    ,(namestring
	      (merge-pathnames 
	       #p"tests/bogus.db"
	       (asdf:component-pathname (asdf:find-system 'elephant-tests))))))
  )

Does /temp/blog.db already exist?  Is it possible that this is a problem
in an "upgrade" from a previous format?





On Mon, 2008-06-09 at 21:35 -0500, Robert L. Read wrote:
> I'll try this and report back.  I haven't tested with sqlite3 since I
> switched to a 64-bit computer.  
> 
> 
> On Mon, 2008-06-09 at 17:03 -0500, Sebastian Georges wrote:
> > I tried to install elephant-unstable this morning (as drop-instance
> > and some keyword arguments are not available in 0.9.1 i guess you are
> > testing weblocks against unstable now), but i get this error when
> > creating (elephant:open-store '(:clsql (:sqlite3 "/tmp/blog.db"))):
> > 
> > "When attempting to set the slot's value to #<SQL-BTREE oid:1> (SETF
> > of SLOT-VALUE), the slot DB-CLSQL::CLASS-ROOT is missing from the
> > object #<SQL-STORE-CONTROLLER (SQLITE3 /tmp/blog.db)>"
> > 
> > Thank you for you help
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
> 
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From arnaudpourseb at gmail.com  Tue Jun 10 09:24:58 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Tue, 10 Jun 2008 04:24:58 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <1213069205.29423.1677.camel@penguin.yourdomain.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
Message-ID: <9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>

Thank you for your answer.
This particular test doesn't work either, for the same reason. The bases I
intended to open are new. Elephant unstable and clsql are freshly installed;
SBCL version is 1:1.0.11.0-1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080610/f04efd13/attachment.html>

From eslick at media.mit.edu  Tue Jun 10 16:44:52 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 10 Jun 2008 12:44:52 -0400
Subject: [elephant-devel] CL-SQL and Postmodern & dup-btree
Message-ID: <C5A8A942-EDAC-47B0-93BB-17AEF7E1F2D2@media.mit.edu>

Enabling many dup-btrees to be created/destroyed is an important  
performance issue for all the new features of elephant.  I know Alex  
mentioned this should be possible but he hadn't done it yet.  I'm not  
sure if CL-SQL has sufficient support yet (I think so based on what I  
remember of the design - this should fall out naturally).

We should definitely ensure that this is the case for 1.0.

Thanks,
Ian


From killerstorm at newmail.ru  Tue Jun 10 18:24:26 2008
From: killerstorm at newmail.ru (Alex Mizrahi)
Date: Tue, 10 Jun 2008 21:24:26 +0300
Subject: [elephant-devel] Re: CL-SQL and Postmodern & dup-btree
References: <C5A8A942-EDAC-47B0-93BB-17AEF7E1F2D2@media.mit.edu>
Message-ID: <g2mgsv$tc2$1@ger.gmane.org>

 IE> Enabling many dup-btrees to be created/destroyed is an important
 IE> performance issue for all the new features of elephant.

dup-btrees? i thought it's about psets..

pset is created for each instance of object with set-value slot, so there 
could be tons of them.

but dup-btrees are created only one per slot definition, so it's not 
critical.

or i've missed something and dup-btrees are created for each instance in 
some case?

btw, i haven't found any tests related to set-valued slots. do they exist?

 IE>  I know Alex  mentioned this should be possible but he hadn't done it 
yet.

if we want to improve allocation of psets, that should be fairly easy with 
single dup-btree
for all of them, and perhaps code will even be portable between cl-sql and 
postmodern.

but improving allocation of dup-btrees will be sort of challenging..





From liori at exroot.org  Wed Jun 11 12:41:54 2008
From: liori at exroot.org (Tomasz Melcer)
Date: Wed, 11 Jun 2008 14:41:54 +0200
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
Message-ID: <484FC812.6080302@exroot.org>

The testcase that reproduces this every time on my machine:

#v+
#!/bin/sh
mkdir -p database
sbcl --eval '(require :elephant)' \
     --eval '(elephant:open-store (list :BDB "'"$(pwd)"'/database/"))'
#v-

Full output is attached.

I am a lisp newbie, so I am not sure if I am doing everything correctly.

Thank you for help,
Tomasz Melcer

--------------010403030407090506010409
Content-Type: text/plain;
 name="typescript"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="typescript"

U2NyaXB0IHN0YXJ0ZWQgb24gtnJvLCAxMSBjemUgMjAwOCwgMTQ6Mzg6NTUKc2gtMy4yJCAu
L3Rlc3RjYXNlLnNoIA0KVGhpcyBpcyBTQkNMIDEuMC4xNy5kZWJpYW4sIGFuIGltcGxlbWVu
dGF0aW9uIG9mIEFOU0kgQ29tbW9uIExpc3AuDQpNb3JlIGluZm9ybWF0aW9uIGFib3V0IFNC
Q0wgaXMgYXZhaWxhYmxlIGF0IDxodHRwOi8vd3d3LnNiY2wub3JnLz4uDQoNClNCQ0wgaXMg
ZnJlZSBzb2Z0d2FyZSwgcHJvdmlkZWQgYXMgaXMsIHdpdGggYWJzb2x1dGVseSBubyB3YXJy
YW50eS4NCkl0IGlzIG1vc3RseSBpbiB0aGUgcHVibGljIGRvbWFpbjsgc29tZSBwb3J0aW9u
cyBhcmUgcHJvdmlkZWQgdW5kZXINCkJTRC1zdHlsZSBsaWNlbnNlcy4gIFNlZSB0aGUgQ1JF
RElUUyBhbmQgQ09QWUlORyBmaWxlcyBpbiB0aGUNCmRpc3RyaWJ1dGlvbiBmb3IgbW9yZSBp
bmZvcm1hdGlvbi4NCjsgbG9hZGluZyBzeXN0ZW0gZGVmaW5pdGlvbiBmcm9tIC9ob21lL2xp
b3JpLy5zYmNsL3N5c3RlbXMvY2wtYmFzZTY0LmFzZCBpbnRvDQo7ICM8UEFDS0FHRSAiQVNE
RjAiPg0KOyByZWdpc3RlcmluZyAjPFNZU1RFTSBDTC1CQVNFNjQge0FFNTIzMzl9PiBhcyBD
TC1CQVNFNjQNCjsgcmVnaXN0ZXJpbmcgIzxTWVNURU0gQ0wtQkFTRTY0LVRFU1RTIHtBRkEw
RjMxfT4gYXMgQ0wtQkFTRTY0LVRFU1RTDQo7IGxvYWRpbmcgc3lzdGVtIGRlZmluaXRpb24g
ZnJvbSAvaG9tZS9saW9yaS8uc2JjbC9zeXN0ZW1zL3VmZmkuYXNkIGludG8NCjsgIzxQQUNL
QUdFICJBU0RGMCI+DQo7IHJlZ2lzdGVyaW5nICM8U1lTVEVNIFVGRkkge0IyMzI0Nzl9PiBh
cyBVRkZJDQpBdHRlbXB0aW5nIHRvIGxvYWQgbGlibWVtdXRpbC5zby4uLg0KTG9hZGVkIC92
YXIvY2FjaGUvY29tbW9uLWxpc3AtY29udHJvbGxlci8xMDAwL3NiY2wvbG9jYWwvaG9tZS9s
aW9yaS8uc2JjbC9zaXRlL2VsZXBoYW50L3NyYy9tZW11dGlsL2xpYm1lbXV0aWwuc28NCjsg
bG9hZGluZyBzeXN0ZW0gZGVmaW5pdGlvbiBmcm9tIC9ob21lL2xpb3JpLy5zYmNsL3N5c3Rl
bXMvZWxlLWJkYi5hc2QgaW50bw0KOyAjPFBBQ0tBR0UgIkFTREYwIj4NCg0KOyBpbjogTEFN
QkRBIE5JTA0KOyAgICAgKEVMRS1CREItU1lTVEVNOjpHRVQtREItTkFNRSBFTEUtQkRCLVNZ
U1RFTTo6QykNCjsgDQo7IGNhdWdodCBTVFlMRS1XQVJOSU5HOg0KOyAgIHVuZGVmaW5lZCBm
dW5jdGlvbjogR0VULURCLU5BTUUNCg0KOyAgICAgKEVMRS1CREItU1lTVEVNOjpMSUJSQVJZ
LURJUkVDVE9SSUVTIEVMRS1CREItU1lTVEVNOjpDKQ0KOyANCjsgY2F1Z2h0IFNUWUxFLVdB
Uk5JTkc6DQo7ICAgdW5kZWZpbmVkIGZ1bmN0aW9uOiBMSUJSQVJZLURJUkVDVE9SSUVTDQoN
CjsgDQo7IGNhdWdodCBTVFlMRS1XQVJOSU5HOg0KOyAgIFRoZXNlIGZ1bmN0aW9ucyBhcmUg
dW5kZWZpbmVkOg0KOyAgICAgR0VULURCLU5BTUUgTElCUkFSWS1ESVJFQ1RPUklFUw0KOyAN
CjsgY29tcGlsYXRpb24gdW5pdCBmaW5pc2hlZA0KOyAgIGNhdWdodCAzIFNUWUxFLVdBUk5J
TkcgY29uZGl0aW9ucw0KDQo7IGluOiBMQU1CREEgTklMDQo7ICAgICAoRUxFLUJEQi1TWVNU
RU06OkxJQlJBUlktRElSRUNUT1JJRVMgRUxFLUJEQi1TWVNURU06OkMpDQo7IA0KOyBjYXVn
aHQgU1RZTEUtV0FSTklORzoNCjsgICB1bmRlZmluZWQgZnVuY3Rpb246IExJQlJBUlktRElS
RUNUT1JJRVMNCg0KOyANCjsgY2F1Z2h0IFNUWUxFLVdBUk5JTkc6DQo7ICAgVGhpcyBmdW5j
dGlvbiBpcyB1bmRlZmluZWQ6DQo7ICAgICBMSUJSQVJZLURJUkVDVE9SSUVTDQo7IA0KOyBj
b21waWxhdGlvbiB1bml0IGZpbmlzaGVkDQo7ICAgY2F1Z2h0IDIgU1RZTEUtV0FSTklORyBj
b25kaXRpb25zDQo7IHJlZ2lzdGVyaW5nICM8U1lTVEVNIEVMRS1CREIge0E5RjQzNTF9PiBh
cyBFTEUtQkRCDQpBdHRlbXB0aW5nIHRvIGxvYWQgbGlibWVtdXRpbC5zby4uLg0KTG9hZGVk
IC92YXIvY2FjaGUvY29tbW9uLWxpc3AtY29udHJvbGxlci8xMDAwL3NiY2wvbG9jYWwvaG9t
ZS9saW9yaS8uc2JjbC9zaXRlL2VsZXBoYW50L3NyYy9tZW11dGlsL2xpYm1lbXV0aWwuc28N
ClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQ09QWS1CVUZTIGluIERFRlVODQpTVFlMRS1X
QVJOSU5HOiByZWRlZmluaW5nIE1BS0UtQlVGRkVSLVNUUkVBTSBpbiBERUZVTg0KU1RZTEUt
V0FSTklORzogcmVkZWZpbmluZyBHUkFCLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNUWUxF
LVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVUVVJOLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNU
WUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVBRC1JTlQzMiBpbiBERUZVTg0KU1RZTEUtV0FS
TklORzogcmVkZWZpbmluZyBSRUFELUlOVDY0IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiBy
ZWRlZmluaW5nIFJFQUQtVUlOVDMyIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmlu
aW5nIFJFQUQtVUlOVDY0IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIFJF
QUQtRkxPQVQgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVBRC1ET1VC
TEUgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtSU5UMzIgaW4g
REVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtSU5UNjQgaW4gREVGVU4N
ClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtVUlOVDMyIGluIERFRlVODQpTVFlM
RS1XQVJOSU5HOiByZWRlZmluaW5nIFdSSVRFLVVJTlQ2NCBpbiBERUZVTg0KU1RZTEUtV0FS
TklORzogcmVkZWZpbmluZyBXUklURS1GTE9BVCBpbiBERUZVTg0KU1RZTEUtV0FSTklORzog
cmVkZWZpbmluZyBXUklURS1ET1VCTEUgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVm
aW5pbmcgT0ZGU0VULUNIQVItUE9JTlRFUiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVk
ZWZpbmluZyAlQ09QWS1TVFItVE8tQlVGIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRl
ZmluaW5nIENPUFktU1RSLVRPLUJVRiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZp
bmluZyBQUk9DRVNTLVNUUlVDVC1TTE9ULURFRlMgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6
IHJlZGVmaW5pbmcgUkVTSVpFLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNUWUxFLVdBUk5J
Tkc6IHJlZGVmaW5pbmcgUkVTSVpFLUJVRkZFUi1TVFJFQU0tTk8tQ09QWSBpbiBERUZVTg0K
U1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBSRVNFVC1CVUZGRVItU1RSRUFNIGluIERFRlVO
DQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1CWVRFIGluIERFRlVO
DQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQzMiBpbiBERUZV
Tg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVDMyIGluIERF
RlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQ2NCBpbiBE
RUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVDY0IGlu
IERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1GTE9BVCBp
biBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtRE9VQkxF
IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1TVFJJ
TkcgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtQllU
RSBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1CWVRF
LVZFQ1RPUiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJ
VEUtQllURS1WRUNUT1IgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVG
RkVSLVJFQUQtVE8tQVJSQVktT0ZGU0VUIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRl
ZmluaW5nIEJVRkZFUi1XUklURS1GUk9NLUFSUkFZLU9GRlNFVCBpbiBERUZVTg0KU1RZTEUt
V0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtT0lEIGluIERFRlVODQpTVFlMRS1X
QVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELU9JRCBpbiBERUZVTg0KU1RZTEUtV0FS
TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1JTlQgaW4gREVGVU4NClNUWUxFLVdBUk5J
Tkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtRklYTlVNIGluIERFRlVODQpTVFlMRS1XQVJO
SU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQgaW4gREVGVU4NClNUWUxFLVdBUk5J
Tkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtVUlOVCBpbiBERUZVTg0KU1RZTEUtV0FSTklO
RzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVCBpbiBERUZVTg0KU1RZTEUtV0FSTklO
RzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1GSVhOVU0zMiBpbiBERUZVTg0KU1RZTEUtV0FS
TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1JTlQzMiBpbiBERUZVTg0KU1RZTEUtV0FS
TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VSU5UMzIgaW4gREVGVU4NClNUWUxFLVdB
Uk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtRklYTlVNNjQgaW4gREVGVU4NClNUWUxF
LVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtSU5UNjQgaW4gREVGVU4NClNUWUxF
LVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtVUlOVDY0IGluIERFRlVODQpTVFlM
RS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELUZMT0FUIGluIERFRlVODQpTVFlM
RS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELURPVUJMRSBpbiBERUZVTg0KU1RZ
TEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VQ1MxLVNUUklORyBpbiBERUZV
Tg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VQ1M0LVNUUklORyBp
biBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBMSVRUTEUtRU5ESUFOLVAgaW4g
REVGVU4NCkxvYWRpbmcgL3Vzci9saWIvbGliZGItNC41LnNvDQpBdHRlbXB0aW5nIHRvIGxv
YWQgbGliYmVya2VsZXktZGIuc28uLi4NCkxvYWRlZCAvdmFyL2NhY2hlL2NvbW1vbi1saXNw
LWNvbnRyb2xsZXIvMTAwMC9zYmNsL2xvY2FsL2hvbWUvbGlvcmkvLnNiY2wvc2l0ZS9lbGVw
aGFudC9zcmMvZGItYmRiL2xpYmJlcmtlbGV5LWRiLnNvDQpTVFlMRS1XQVJOSU5HOiBJbXBs
aWNpdGx5IGNyZWF0aW5nIG5ldyBnZW5lcmljIGZ1bmN0aW9uIFNUQVJULURFQURMT0NLLURF
VEVDVE9SLg0KU1RZTEUtV0FSTklORzogSW1wbGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJp
YyBmdW5jdGlvbiBTVE9QLURFQURMT0NLLURFVEVDVE9SLg0KU1RZTEUtV0FSTklORzogSW1w
bGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJpYyBmdW5jdGlvbiBDSEVDS1BPSU5ULg0KU1RZ
TEUtV0FSTklORzogSW1wbGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJpYyBmdW5jdGlvbiBC
VUlMRC1CVFJFRS1JTkRFWC4NClNUWUxFLVdBUk5JTkc6IEltcGxpY2l0bHkgY3JlYXRpbmcg
bmV3IGdlbmVyaWMgZnVuY3Rpb24gUE9QVUxBVEUuDQppbGxlZ2FsIGZsYWcgc3BlY2lmaWVk
IHRvIERCX0VOVi0+c2V0X3RpbWVvdXQNCg0KZGVidWdnZXIgaW52b2tlZCBvbiBhIFNJTVBM
RS1FUlJPUiBpbiB0aHJlYWQgIzxUSFJFQUQgImluaXRpYWwgdGhyZWFkIiB7QTg3NDkxOX0+
Og0KICBFcnJvciBkdXJpbmcgcHJvY2Vzc2luZyBvZiAtLWV2YWwgb3B0aW9uICIoZWxlcGhh
bnQ6b3Blbi1zdG9yZSAobGlzdCA6QkRCIFwiL2hvbWUvbGlvcmkvdG1wL3Rlc3RjYXNlL2Rh
dGFiYXNlL1wiKSkiOg0KDQooQSBTQi1JTlQ6Qy1TVFJJTkctREVDT0RJTkctRVJST1Igd2Fz
IGNhdWdodCB3aGVuIHRyeWluZyB0byBwcmludA0KKkRFQlVHLUNPTkRJVElPTiogd2hlbiBl
bnRlcmluZyB0aGUgZGVidWdnZXIuIFByaW50aW5nIHdhcyBhYm9ydGVkIGFuZCB0aGUNClNC
LUlOVDpDLVNUUklORy1ERUNPRElORy1FUlJPUiB3YXMgc3RvcmVkIGluDQpTQi1ERUJVRzo6
Kk5FU1RFRC1ERUJVRy1DT05ESVRJT04qLikNCg0KVHlwZSBIRUxQIGZvciBkZWJ1Z2dlciBo
ZWxwLCBvciAoU0ItRVhUOlFVSVQpIHRvIGV4aXQgZnJvbSBTQkNMLg0KDQpyZXN0YXJ0cyAo
aW52b2thYmxlIGJ5IG51bWJlciBvciBieSBwb3NzaWJseS1hYmJyZXZpYXRlZCBuYW1lKToN
CiAgMDogW0NPTlRJTlVFXSBJZ25vcmUgYW5kIGNvbnRpbnVlIHdpdGggbmV4dCAtLWV2YWwg
b3B0aW9uLg0KICAxOiBbQUJPUlQgICBdIFNraXAgcmVzdCBvZiAtLWV2YWwgb3B0aW9ucy4N
CiAgMjogICAgICAgICAgICBTa2lwIHRvIHRvcGxldmVsIFJFQUQvRVZBTC9QUklOVCBsb29w
Lg0KICAzOiBbUVVJVCAgICBdIFF1aXQgU0JDTCAoY2FsbGluZyAjJ1FVSVQsIGtpbGxpbmcg
dGhlIHByb2Nlc3MpLg0KDQooKExBTUJEQSAoU0ItSU1QTDo6RSkpICM8REItQkRCOjpEQi1F
UlJPUiB7QjJDRjAwOX0+KQ0KMF0gKiBzaC0zLjIkIGV4aXQNCgpTY3JpcHQgZG9uZSBvbiC2
cm8sIDExIGN6ZSAyMDA4LCAxNDozOTowNwo=
--------------010403030407090506010409--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080611/df3696d6/attachment.sig>

From eslick at media.mit.edu  Wed Jun 11 13:06:04 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Jun 2008 09:06:04 -0400
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
In-Reply-To: <484FC812.6080302@exroot.org>
References: <484FC812.6080302@exroot.org>
Message-ID: <AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>

Which darcs tree and BDB version are you using?  What are the contents  
of your my-config.sexp file?

Ian

On Jun 11, 2008, at 8:41 AM, Tomasz Melcer wrote:

> The testcase that reproduces this every time on my machine:
>
> #v+
> #!/bin/sh
> mkdir -p database
> sbcl --eval '(require :elephant)' \
>     --eval '(elephant:open-store (list :BDB "'"$(pwd)"'/database/"))'
> #v-
>
> Full output is attached.
>
> I am a lisp newbie, so I am not sure if I am doing everything  
> correctly.
>
> Thank you for help,
> Tomasz Melcer
>
> --------------010403030407090506010409
> Content-Type: text/plain;
> name="typescript"
> Content-Transfer-Encoding: base64
> Content-Disposition: inline;
> filename="typescript"
>
> U2NyaXB0IHN0YXJ0ZWQgb24gtnJvLCAxMSBjemUgMjAwOCwgMTQ6Mzg6NTUKc2gtMy4yJCAu
> L3Rlc3RjYXNlLnNoIA0KVGhpcyBpcyBTQkNMIDEuMC4xNy5kZWJpYW4sIGFuIGltcGxlbWVu
> dGF0aW9uIG9mIEFOU0kgQ29tbW9uIExpc3AuDQpNb3JlIGluZm9ybWF0aW9uIGFib3V0IFNC
> Q0wgaXMgYXZhaWxhYmxlIGF0IDxodHRwOi8vd3d3LnNiY2wub3JnLz4uDQoNClNCQ0wgaXMg
> ZnJlZSBzb2Z0d2FyZSwgcHJvdmlkZWQgYXMgaXMsIHdpdGggYWJzb2x1dGVseSBubyB3YXJy
> YW50eS4NCkl0IGlzIG1vc3RseSBpbiB0aGUgcHVibGljIGRvbWFpbjsgc29tZSBwb3J0aW9u
> cyBhcmUgcHJvdmlkZWQgdW5kZXINCkJTRC1zdHlsZSBsaWNlbnNlcy4gIFNlZSB0aGUgQ1JF
> RElUUyBhbmQgQ09QWUlORyBmaWxlcyBpbiB0aGUNCmRpc3RyaWJ1dGlvbiBmb3IgbW9yZSBp
> bmZvcm1hdGlvbi4NCjsgbG9hZGluZyBzeXN0ZW0gZGVmaW5pdGlvbiBmcm9tIC9ob21lL2xp
> b3JpLy5zYmNsL3N5c3RlbXMvY2wtYmFzZTY0LmFzZCBpbnRvDQo7ICM8UEFDS0FHRSAiQVNE
> RjAiPg0KOyByZWdpc3RlcmluZyAjPFNZU1RFTSBDTC1CQVNFNjQge0FFNTIzMzl9PiBhcyBD
> TC1CQVNFNjQNCjsgcmVnaXN0ZXJpbmcgIzxTWVNURU0gQ0wtQkFTRTY0LVRFU1RTIHtBRkEw
> RjMxfT4gYXMgQ0wtQkFTRTY0LVRFU1RTDQo7IGxvYWRpbmcgc3lzdGVtIGRlZmluaXRpb24g
> ZnJvbSAvaG9tZS9saW9yaS8uc2JjbC9zeXN0ZW1zL3VmZmkuYXNkIGludG8NCjsgIzxQQUNL
> QUdFICJBU0RGMCI 
> +DQo7IHJlZ2lzdGVyaW5nICM8U1lTVEVNIFVGRkkge0IyMzI0Nzl9PiBh
> cyBVRkZJDQpBdHRlbXB0aW5nIHRvIGxvYWQgbGlibWVtdXRpbC5zby4uLg0KTG9hZGVkIC92
> YXIvY2FjaGUvY29tbW9uLWxpc3AtY29udHJvbGxlci8xMDAwL3NiY2wvbG9jYWwvaG9tZS9s
> aW9yaS8uc2JjbC9zaXRlL2VsZXBoYW50L3NyYy9tZW11dGlsL2xpYm1lbXV0aWwuc28NCjsg
> bG9hZGluZyBzeXN0ZW0gZGVmaW5pdGlvbiBmcm9tIC9ob21lL2xpb3JpLy5zYmNsL3N5c3Rl
> bXMvZWxlLWJkYi5hc2QgaW50bw0KOyAjPFBBQ0tBR0UgIkFTREYwIj4NCg0KOyBpbjogTEFN
> QkRBIE5JTA0KOyAgICAgKEVMRS1CREItU1lTVEVNOjpHRVQtREItTkFNRSBFTEUtQkRCLVNZ
> U1RFTTo6QykNCjsgDQo7IGNhdWdodCBTVFlMRS1XQVJOSU5HOg0KOyAgIHVuZGVmaW5lZCBm
> dW5jdGlvbjogR0VULURCLU5BTUUNCg0KOyAgICAgKEVMRS1CREItU1lTVEVNOjpMSUJSQVJZ
> LURJUkVDVE9SSUVTIEVMRS1CREItU1lTVEVNOjpDKQ0KOyANCjsgY2F1Z2h0IFNUWUxFLVdB
> Uk5JTkc6DQo7ICAgdW5kZWZpbmVkIGZ1bmN0aW9uOiBMSUJSQVJZLURJUkVDVE9SSUVTDQoN
> CjsgDQo7IGNhdWdodCBTVFlMRS1XQVJOSU5HOg0KOyAgIFRoZXNlIGZ1bmN0aW9ucyBhcmUg
> dW5kZWZpbmVkOg0KOyAgICAgR0VULURCLU5BTUUgTElCUkFSWS1ESVJFQ1RPUklFUw0KOyAN
> CjsgY29tcGlsYXRpb24gdW5pdCBmaW5pc2hlZA0KOyAgIGNhdWdodCAzIFNUWUxFLVdBUk5J
> TkcgY29uZGl0aW9ucw0KDQo7IGluOiBMQU1CREEgTklMDQo7ICAgICAoRUxFLUJEQi1TWVNU
> RU06OkxJQlJBUlktRElSRUNUT1JJRVMgRUxFLUJEQi1TWVNURU06OkMpDQo7IA0KOyBjYXVn
> aHQgU1RZTEUtV0FSTklORzoNCjsgICB1bmRlZmluZWQgZnVuY3Rpb246IExJQlJBUlktRElS
> RUNUT1JJRVMNCg0KOyANCjsgY2F1Z2h0IFNUWUxFLVdBUk5JTkc6DQo7ICAgVGhpcyBmdW5j
> dGlvbiBpcyB1bmRlZmluZWQ6DQo7ICAgICBMSUJSQVJZLURJUkVDVE9SSUVTDQo7IA0KOyBj
> b21waWxhdGlvbiB1bml0IGZpbmlzaGVkDQo7ICAgY2F1Z2h0IDIgU1RZTEUtV0FSTklORyBj
> b25kaXRpb25zDQo7IHJlZ2lzdGVyaW5nICM8U1lTVEVNIEVMRS1CREIge0E5RjQzNTF9PiBh
> cyBFTEUtQkRCDQpBdHRlbXB0aW5nIHRvIGxvYWQgbGlibWVtdXRpbC5zby4uLg0KTG9hZGVk
> IC92YXIvY2FjaGUvY29tbW9uLWxpc3AtY29udHJvbGxlci8xMDAwL3NiY2wvbG9jYWwvaG9t
> ZS9saW9yaS8uc2JjbC9zaXRlL2VsZXBoYW50L3NyYy9tZW11dGlsL2xpYm1lbXV0aWwuc28N
> ClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQ09QWS1CVUZTIGluIERFRlVODQpTVFlMRS1X
> QVJOSU5HOiByZWRlZmluaW5nIE1BS0UtQlVGRkVSLVNUUkVBTSBpbiBERUZVTg0KU1RZTEUt
> V0FSTklORzogcmVkZWZpbmluZyBHUkFCLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNUWUxF
> LVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVUVVJOLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNU
> WUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVBRC1JTlQzMiBpbiBERUZVTg0KU1RZTEUtV0FS
> TklORzogcmVkZWZpbmluZyBSRUFELUlOVDY0IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiBy
> ZWRlZmluaW5nIFJFQUQtVUlOVDMyIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmlu
> aW5nIFJFQUQtVUlOVDY0IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIFJF
> QUQtRkxPQVQgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgUkVBRC1ET1VC
> TEUgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtSU5UMzIgaW4g
> REVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtSU5UNjQgaW4gREVGVU4N
> ClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgV1JJVEUtVUlOVDMyIGluIERFRlVODQpTVFlM
> RS1XQVJOSU5HOiByZWRlZmluaW5nIFdSSVRFLVVJTlQ2NCBpbiBERUZVTg0KU1RZTEUtV0FS
> TklORzogcmVkZWZpbmluZyBXUklURS1GTE9BVCBpbiBERUZVTg0KU1RZTEUtV0FSTklORzog
> cmVkZWZpbmluZyBXUklURS1ET1VCTEUgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVm
> aW5pbmcgT0ZGU0VULUNIQVItUE9JTlRFUiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVk
> ZWZpbmluZyAlQ09QWS1TVFItVE8tQlVGIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRl
> ZmluaW5nIENPUFktU1RSLVRPLUJVRiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZp
> bmluZyBQUk9DRVNTLVNUUlVDVC1TTE9ULURFRlMgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6
> IHJlZGVmaW5pbmcgUkVTSVpFLUJVRkZFUi1TVFJFQU0gaW4gREVGVU4NClNUWUxFLVdBUk5J
> Tkc6IHJlZGVmaW5pbmcgUkVTSVpFLUJVRkZFUi1TVFJFQU0tTk8tQ09QWSBpbiBERUZVTg0K
> U1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBSRVNFVC1CVUZGRVItU1RSRUFNIGluIERFRlVO
> DQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1CWVRFIGluIERFRlVO
> DQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQzMiBpbiBERUZV
> Tg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVDMyIGluIERF
> RlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQ2NCBpbiBE
> RUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVDY0IGlu
> IERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1GTE9BVCBp
> biBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtRE9VQkxF
> IGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1TVFJJ
> TkcgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtQllU
> RSBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1CWVRF
> LVZFQ1RPUiBpbiBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJ
> VEUtQllURS1WRUNUT1IgaW4gREVGVU4NClNUWUxFLVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVG
> RkVSLVJFQUQtVE8tQVJSQVktT0ZGU0VUIGluIERFRlVODQpTVFlMRS1XQVJOSU5HOiByZWRl
> ZmluaW5nIEJVRkZFUi1XUklURS1GUk9NLUFSUkFZLU9GRlNFVCBpbiBERUZVTg0KU1RZTEUt
> V0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtT0lEIGluIERFRlVODQpTVFlMRS1X
> QVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELU9JRCBpbiBERUZVTg0KU1RZTEUtV0FS
> TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1JTlQgaW4gREVGVU4NClNUWUxFLVdBUk5J
> Tkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtRklYTlVNIGluIERFRlVODQpTVFlMRS1XQVJO
> SU5HOiByZWRlZmluaW5nIEJVRkZFUi1XUklURS1JTlQgaW4gREVGVU4NClNUWUxFLVdBUk5J
> Tkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtVUlOVCBpbiBERUZVTg0KU1RZTEUtV0FSTklO
> RzogcmVkZWZpbmluZyBCVUZGRVItV1JJVEUtVUlOVCBpbiBERUZVTg0KU1RZTEUtV0FSTklO
> RzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1GSVhOVU0zMiBpbiBERUZVTg0KU1RZTEUtV0FS
> TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1JTlQzMiBpbiBERUZVTg0KU1RZTEUtV0FS
> TklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VSU5UMzIgaW4gREVGVU4NClNUWUxFLVdB
> Uk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtRklYTlVNNjQgaW4gREVGVU4NClNUWUxF
> LVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtSU5UNjQgaW4gREVGVU4NClNUWUxF
> LVdBUk5JTkc6IHJlZGVmaW5pbmcgQlVGRkVSLVJFQUQtVUlOVDY0IGluIERFRlVODQpTVFlM
> RS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELUZMT0FUIGluIERFRlVODQpTVFlM
> RS1XQVJOSU5HOiByZWRlZmluaW5nIEJVRkZFUi1SRUFELURPVUJMRSBpbiBERUZVTg0KU1RZ
> TEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VQ1MxLVNUUklORyBpbiBERUZV
> Tg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBCVUZGRVItUkVBRC1VQ1M0LVNUUklORyBp
> biBERUZVTg0KU1RZTEUtV0FSTklORzogcmVkZWZpbmluZyBMSVRUTEUtRU5ESUFOLVAgaW4g
> REVGVU4NCkxvYWRpbmcgL3Vzci9saWIvbGliZGItNC41LnNvDQpBdHRlbXB0aW5nIHRvIGxv
> YWQgbGliYmVya2VsZXktZGIuc28uLi4NCkxvYWRlZCAvdmFyL2NhY2hlL2NvbW1vbi1saXNw
> LWNvbnRyb2xsZXIvMTAwMC9zYmNsL2xvY2FsL2hvbWUvbGlvcmkvLnNiY2wvc2l0ZS9lbGVw
> aGFudC9zcmMvZGItYmRiL2xpYmJlcmtlbGV5LWRiLnNvDQpTVFlMRS1XQVJOSU5HOiBJbXBs
> aWNpdGx5IGNyZWF0aW5nIG5ldyBnZW5lcmljIGZ1bmN0aW9uIFNUQVJULURFQURMT0NLLURF
> VEVDVE9SLg0KU1RZTEUtV0FSTklORzogSW1wbGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJp
> YyBmdW5jdGlvbiBTVE9QLURFQURMT0NLLURFVEVDVE9SLg0KU1RZTEUtV0FSTklORzogSW1w
> bGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJpYyBmdW5jdGlvbiBDSEVDS1BPSU5ULg0KU1RZ
> TEUtV0FSTklORzogSW1wbGljaXRseSBjcmVhdGluZyBuZXcgZ2VuZXJpYyBmdW5jdGlvbiBC
> VUlMRC1CVFJFRS1JTkRFWC4NClNUWUxFLVdBUk5JTkc6IEltcGxpY2l0bHkgY3JlYXRpbmcg
> bmV3IGdlbmVyaWMgZnVuY3Rpb24gUE9QVUxBVEUuDQppbGxlZ2FsIGZsYWcgc3BlY2lmaWVk
> IHRvIERCX0VOVi0 
> +c2V0X3RpbWVvdXQNCg0KZGVidWdnZXIgaW52b2tlZCBvbiBhIFNJTVBM
> RS1FUlJPUiBpbiB0aHJlYWQgIzxUSFJFQUQgImluaXRpYWwgdGhyZWFkIiB7QTg3NDkxOX0 
> +
> Og0KICBFcnJvciBkdXJpbmcgcHJvY2Vzc2luZyBvZiAtLWV2YWwgb3B0aW9uICIoZWxlcGhh
> bnQ6b3Blbi1zdG9yZSAobGlzdCA6QkRCIFwiL2hvbWUvbGlvcmkvdG1wL3Rlc3RjYXNlL2Rh
> dGFiYXNlL1wiKSkiOg0KDQooQSBTQi1JTlQ6Qy1TVFJJTkctREVDT0RJTkctRVJST1Igd2Fz
> IGNhdWdodCB3aGVuIHRyeWluZyB0byBwcmludA0KKkRFQlVHLUNPTkRJVElPTiogd2hlbiBl
> bnRlcmluZyB0aGUgZGVidWdnZXIuIFByaW50aW5nIHdhcyBhYm9ydGVkIGFuZCB0aGUNClNC
> LUlOVDpDLVNUUklORy1ERUNPRElORy1FUlJPUiB3YXMgc3RvcmVkIGluDQpTQi1ERUJVRzo6
> Kk5FU1RFRC1ERUJVRy1DT05ESVRJT04qLikNCg0KVHlwZSBIRUxQIGZvciBkZWJ1Z2dlciBo
> ZWxwLCBvciAoU0ItRVhUOlFVSVQpIHRvIGV4aXQgZnJvbSBTQkNMLg0KDQpyZXN0YXJ0cyAo
> aW52b2thYmxlIGJ5IG51bWJlciBvciBieSBwb3NzaWJseS1hYmJyZXZpYXRlZCBuYW1lKToN
> CiAgMDogW0NPTlRJTlVFXSBJZ25vcmUgYW5kIGNvbnRpbnVlIHdpdGggbmV4dCAtLWV2YWwg
> b3B0aW9uLg0KICAxOiBbQUJPUlQgICBdIFNraXAgcmVzdCBvZiAtLWV2YWwgb3B0aW9ucy4N
> CiAgMjogICAgICAgICAgICBTa2lwIHRvIHRvcGxldmVsIFJFQUQvRVZBTC9QUklOVCBsb29w
> Lg0KICAzOiBbUVVJVCAgICBdIFF1aXQgU0JDTCAoY2FsbGluZyAjJ1FVSVQsIGtpbGxpbmcg
> dGhlIHByb2Nlc3MpLg0KDQooKExBTUJEQSAoU0ItSU1QTDo6RSkpICM8REItQkRCOjpEQi1F
> UlJPUiB7QjJDRjAwOX0 
> +KQ0KMF0gKiBzaC0zLjIkIGV4aXQNCgpTY3JpcHQgZG9uZSBvbiC2
> cm8sIDExIGN6ZSAyMDA4LCAxNDozOTowNwo=
> --------------010403030407090506010409--
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From liori at exroot.org  Wed Jun 11 13:37:55 2008
From: liori at exroot.org (Tomasz Melcer)
Date: Wed, 11 Jun 2008 15:37:55 +0200
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
In-Reply-To: <AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>
References: <484FC812.6080302@exroot.org>
	<AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>
Message-ID: <484FD533.6040300@exroot.org>

Ian Eslick pisze:
> Which darcs tree and BDB version are you using?  What are the contents
> of your my-config.sexp file?
Oh, I'm sorry, somehow beginning of the message is missing.

SBCL 1:1.0.17.0-1 (debian/sid package)
libdb4.5 4.5.20-12 (debian/sid package), 4.6 gives the same result
elephant installed automagically using (asdf-install:install :elephant)
today, I don't see any version information in the source tree.

I see cvs directories inside the source tree and no darcs directories,
so it is possible that I've got 0.9.

0.9.1 works ok.

Thank you.

Tomasz Melcer


From eslick at media.mit.edu  Wed Jun 11 13:58:00 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Jun 2008 09:58:00 -0400
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
In-Reply-To: <484FD533.6040300@exroot.org>
References: <484FC812.6080302@exroot.org>
	<AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>
	<484FD533.6040300@exroot.org>
Message-ID: <9A52E9EE-298C-4ABC-96A2-55137B41F972@media.mit.edu>

You are saying that release 0.9.1 via darcs does not exhibit this  
error, but the asdf-installable release (0.9) does?

On Jun 11, 2008, at 9:37 AM, Tomasz Melcer wrote:

> Ian Eslick pisze:
>> Which darcs tree and BDB version are you using?  What are the  
>> contents
>> of your my-config.sexp file?
> Oh, I'm sorry, somehow beginning of the message is missing.
>
> SBCL 1:1.0.17.0-1 (debian/sid package)
> libdb4.5 4.5.20-12 (debian/sid package), 4.6 gives the same result
> elephant installed automagically using (asdf- 
> install:install :elephant)
> today, I don't see any version information in the source tree.
>
> I see cvs directories inside the source tree and no darcs directories,
> so it is possible that I've got 0.9.
>
> 0.9.1 works ok.
>
> Thank you.
>
> Tomasz Melcer
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From liori at exroot.org  Wed Jun 11 14:16:42 2008
From: liori at exroot.org (Tomasz Melcer)
Date: Wed, 11 Jun 2008 16:16:42 +0200
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
In-Reply-To: <9A52E9EE-298C-4ABC-96A2-55137B41F972@media.mit.edu>
References: <484FC812.6080302@exroot.org>	<AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>	<484FD533.6040300@exroot.org>
	<9A52E9EE-298C-4ABC-96A2-55137B41F972@media.mit.edu>
Message-ID: <484FDE4A.8030209@exroot.org>

Ian Eslick pisze:
> You are saying that release 0.9.1 via darcs does not exhibit this error,
> but the asdf-installable release (0.9) does?
Yes. Is there any reason that 0.9.1 is not in asdf-install?

Tomasz Melcer


From eslick at media.mit.edu  Wed Jun 11 16:02:31 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Jun 2008 12:02:31 -0400
Subject: [elephant-devel] Referential Integrity
Message-ID: <0FC9AB33-2C31-4B09-915E-79FD037C8260@media.mit.edu>

While Elephant currently has a reasonable method for lazy handling of  
broken dependencies (pointers from an object slot to an object that no  
longer exists), it doesn't provide any reasonable method for computing  
the set of broken dependancies when an object is dropped.

I'm finding for my current application that this would be very useful  
(if I delete a person's account, I need to delete all objects created  
by that refer to that user or that the user refers to that aren't  
linked to anything else.  Ideally this would be handled by a garbage  
collector, but think about this in the context of indexing.

For example, imagine a User instance references a Profile instance and  
a set of SurveyAnswer instance (with indexed slots user and name)  
point back to the User instance.

When I delete the User all SurveyAnswer and the Profile instance  
should also be deleted, otherwise when I go through all SurveyAnswers  
of a given name, I get an answer instance that reference a user that  
doesn't exist.  Those dangling entries need to be removed from the  
indices.

I'd like to extend the current drop API along the lines of:

- related-instances - a collection of all objects that would be  
rendered invalid on a drop
- drop-instance - add a :drop-related t keyword to walk the graph and  
delete all related insts


There are several approaches to gathering the information necessary to  
compute this:

- Manual code to perform cleanup (Today)

- Explicit declarations of object dependencies
   For example a constraint class argument in defpclass?  Or a more  
direct method of telling the database about dependencies between class/ 
slot values and instances of classes.  This would be automatically  
maintained for associations?)

- Implicit declarations via type information in slots

- Fully automated

This last one is probably too much overhead.  Dynamic types mean we'd  
have to check types at runtime which involves far more overhead to the  
slot access functions than I'd like.  We're already a bit heavy on  
checks in slot access dispatch.


Does anyone have experience implementing something like this?  Any  
suggestions or recommendations?

Thank you,
Ian


From eslick at media.mit.edu  Wed Jun 11 16:02:54 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Jun 2008 12:02:54 -0400
Subject: [elephant-devel] illegal flag specified to DB_ENV->set_timeout
In-Reply-To: <484FDE4A.8030209@exroot.org>
References: <484FC812.6080302@exroot.org>	<AD30E4E7-0C80-4CE8-A1DB-6A0BCF99C70F@media.mit.edu>	<484FD533.6040300@exroot.org>
	<9A52E9EE-298C-4ABC-96A2-55137B41F972@media.mit.edu>
	<484FDE4A.8030209@exroot.org>
Message-ID: <6879DEBC-CD86-4F4F-8CDB-DA3BC07C9C0B@media.mit.edu>

No good reason that I know of - no one has made a tarball yet and  
posted the link on cliki.net.

There was one issue that I recall which was that all root .asd files  
are run, some of which are almost guaranteed to fail during load.  I  
don't know if this is still an issue...

Ian

On Jun 11, 2008, at 10:16 AM, Tomasz Melcer wrote:

> Ian Eslick pisze:
>> You are saying that release 0.9.1 via darcs does not exhibit this  
>> error,
>> but the asdf-installable release (0.9) does?
> Yes. Is there any reason that 0.9.1 is not in asdf-install?
>
> Tomasz Melcer
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Wed Jun 11 16:35:59 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Jun 2008 12:35:59 -0400
Subject: [elephant-devel] Object caching
Message-ID: <721600A5-0785-4397-AE7D-9A88D0AA68CE@media.mit.edu>

I'm dissatisfied with the current approach to object caching in  
elephant-unstable.

Issues:
- Not thread safe
- Break most transactional guarantees
- Adds per-instance slot overhead to maintain the cache mode
- Incompatible with indexing API
- No standard usage model with well understood implications

This leads me to some strong statements about the features:

- The :cache option simply reserves space during instance allocation  
to cache values.
- Cached objects can never be considered thread safe or transactional  
(isolated/atomic)
- Directly setting the cache mode of an object is an advanced feature  
intended to be used by a higher level API

I think that something lightweight along the lines of Robert's DCM or  
my snapshot-set model might provide guidance on a higher level model  
that exploits caching.  (i.e. caching is used in some larger context  
like a 'with-cached-objects' macro or a check-in/check-out protocol  
with some guard object as in DCM).

I can think of a couple of primary usage models:

1) Check-in/check-out a set of objects on which a thread will perform  
repeated operations.

    This checkout should be guarded and implicitly turns on a caching  
policy.  (save oncheck-in, write-through for state durability, etc)

2) A read-only pool of objects shared by many threads (in-memory  
objects w/ on-disk indices)

3) There is a variation on #2 which allows for updates to the pool via  
a single-writer.  The user is responsible for using the single-writer  
API to avoid conflicts.  This requires that updates to cached objects  
not be atomic; or that caching is turned off during updates so that it  
is (there may still be race conditions that violate isolation/ 
atomicity here).

To support either case we need something beyond what is already there;  
for example a model that provides cheap mutexes via the DB instead of  
just in-memory?


For example, a web session is rendering a set of objects to a client  
and updating the client on each request.  Rather than hitting the DB  
on every web transaction, we want to allow the session to run for  
awhile, keeping that state in memory, then commit the changes when a  
'commit' button is clicked, or perhaps we want a write-through policy  
that keeps track of changes by only hitting the DB when the user has  
changed something.

In my application a user might be editing a questionnaire and the UI  
provides an explicit indication that the questionnaire is being  
edited.  A session 'checks out' the questionnaire.  The questionnaire  
has an association with its root questions, which have an association  
with their sub-questions, etc.  Ideally this whole tree would be  
checked out; either based on a user-provided function or some  
declaration that defines the checkout set.  I'd use a write-through  
policy so work was never lost and have the application layer implement  
any needed undo/reset functionality.

Any other use cases?

In short, there are alot of ways to get into trouble with this  
mechanism, so I think it behooves us to spec out an API for using this  
facility that is reasonably robust and can give people canned ways to  
gain the performance benefits without putting too many holes in their  
feet.

Thanks,
Ian



From read at robertlread.net  Thu Jun 12 03:20:42 2008
From: read at robertlread.net (Robert L. Read)
Date: Wed, 11 Jun 2008 22:20:42 -0500
Subject: [elephant-devel] Referential Integrity
In-Reply-To: <0FC9AB33-2C31-4B09-915E-79FD037C8260@media.mit.edu>
References: <0FC9AB33-2C31-4B09-915E-79FD037C8260@media.mit.edu>
Message-ID: <1213240842.29423.1796.camel@penguin.yourdomain.com>

If one could operate under the assumption that most of the database fits
into memory, I would say the act of dealing with references that would
be left dangling is definitely better handled at the "business object"
layer.  This would mean that in the "delete" method for each class, it
would know who might refer to it and take appropriate action, such as
querying the managers of the referrers to find referrers and then
deleting them.  Writing such code is similar to establishing a cascading
delete constraint (or a "cascading finalizer" or "cascading :after
method", which would be more general.)  If we had a constraint system,
it would probably be easier, but less general, than a coded approach.

However, if you don't assume this, then I think that you are correct in
that it essentially becomes equivalent to the garbage collection
problem.

Personally, I rather the like the idea of being able to do:

(apply #'function to-my-whole-gigantic-database),

where #'function could be a garbage collector, or a "delete-if-null"
function.

Make it fast might be another matter.

I personally don't want to compete against other constraint-based
systems, so if I were going to implement a constraint like "this slot
must point to a valid persistent object", then I would try to write as a
simple lisp function, and then try to figure out how to apply it
efficiently in two relevant cases:  Write before a transaction is
committed, so that we can guarantee universal constraint obedience, and
two the entire database (for the same reason.)

It is at least in theory possible for a transaction to know what it
might have modified, and therefore to implement the first efficiently.



On Wed, 2008-06-11 at 12:02 -0400, Ian Eslick wrote:
> While Elephant currently has a reasonable method for lazy handling of  
> broken dependencies (pointers from an object slot to an object that no  
> longer exists), it doesn't provide any reasonable method for computing  
> the set of broken dependancies when an object is dropped.
> 
> I'm finding for my current application that this would be very useful  
> (if I delete a person's account, I need to delete all objects created  
> by that refer to that user or that the user refers to that aren't  
> linked to anything else.  Ideally this would be handled by a garbage  
> collector, but think about this in the context of indexing.
> 
> For example, imagine a User instance references a Profile instance and  
> a set of SurveyAnswer instance (with indexed slots user and name)  
> point back to the User instance.
> 
> When I delete the User all SurveyAnswer and the Profile instance  
> should also be deleted, otherwise when I go through all SurveyAnswers  
> of a given name, I get an answer instance that reference a user that  
> doesn't exist.  Those dangling entries need to be removed from the  
> indices.
> 
> I'd like to extend the current drop API along the lines of:
> 
> - related-instances - a collection of all objects that would be  
> rendered invalid on a drop
> - drop-instance - add a :drop-related t keyword to walk the graph and  
> delete all related insts
> 
> 
> There are several approaches to gathering the information necessary to  
> compute this:
> 
> - Manual code to perform cleanup (Today)
> 
> - Explicit declarations of object dependencies
>    For example a constraint class argument in defpclass?  Or a more  
> direct method of telling the database about dependencies between class/ 
> slot values and instances of classes.  This would be automatically  
> maintained for associations?)
> 
> - Implicit declarations via type information in slots
> 
> - Fully automated
> 
> This last one is probably too much overhead.  Dynamic types mean we'd  
> have to check types at runtime which involves far more overhead to the  
> slot access functions than I'd like.  We're already a bit heavy on  
> checks in slot access dispatch.
> 
> 
> Does anyone have experience implementing something like this?  Any  
> suggestions or recommendations?
> 
> Thank you,
> Ian
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From read at robertlread.net  Thu Jun 12 03:32:57 2008
From: read at robertlread.net (Robert L. Read)
Date: Wed, 11 Jun 2008 22:32:57 -0500
Subject: [elephant-devel] Object caching
In-Reply-To: <721600A5-0785-4397-AE7D-9A88D0AA68CE@media.mit.edu>
References: <721600A5-0785-4397-AE7D-9A88D0AA68CE@media.mit.edu>
Message-ID: <1213241577.29423.1806.camel@penguin.yourdomain.com>

Obviously, I am biased, not by self-conceit but by familiarity with DCM.

I think something like DCM, in which you use a write-through in-memory
cache, is very workable.  To my mind, an ideal system would allow cache
policy to be set separately from the concurrency control and elephant
usage.  To me, a simple hash-table is the starting point for a cache,
but you almost always want to be able to control the size of the cache,
and that decision will typically vary with the particular persistent
class in question.

DCM provides an understandable example
, and even provides generational strategies.

However, DCM uses btrees directly; I think you would want something that
would work with the persistent class machinery that you wrote.

Whether these things would be extensions of persistent-class or more
loosely coupled outside of them, I'm not sure.

For example, if we are building a reusable caching system that really
could be independent of Elephant, that would have value independently,
just as a serializer for lisp objects is value independent of Elephant
(though of course Elephant must use one.)




On Wed, 2008-06-11 at 12:35 -0400, Ian Eslick wrote:
> I'm dissatisfied with the current approach to object caching in  
> elephant-unstable.
> 
> Issues:
> - Not thread safe
> - Break most transactional guarantees
> - Adds per-instance slot overhead to maintain the cache mode
> - Incompatible with indexing API
> - No standard usage model with well understood implications
> 
> This leads me to some strong statements about the features:
> 
> - The :cache option simply reserves space during instance allocation  
> to cache values.
> - Cached objects can never be considered thread safe or transactional  
> (isolated/atomic)
> - Directly setting the cache mode of an object is an advanced feature  
> intended to be used by a higher level API
> 
> I think that something lightweight along the lines of Robert's DCM or  
> my snapshot-set model might provide guidance on a higher level model  
> that exploits caching.  (i.e. caching is used in some larger context  
> like a 'with-cached-objects' macro or a check-in/check-out protocol  
> with some guard object as in DCM).
> 
> I can think of a couple of primary usage models:
> 
> 1) Check-in/check-out a set of objects on which a thread will perform  
> repeated operations.
> 
>     This checkout should be guarded and implicitly turns on a caching  
> policy.  (save oncheck-in, write-through for state durability, etc)
> 
> 2) A read-only pool of objects shared by many threads (in-memory  
> objects w/ on-disk indices)
> 
> 3) There is a variation on #2 which allows for updates to the pool via  
> a single-writer.  The user is responsible for using the single-writer  
> API to avoid conflicts.  This requires that updates to cached objects  
> not be atomic; or that caching is turned off during updates so that it  
> is (there may still be race conditions that violate isolation/ 
> atomicity here).
> 
> To support either case we need something beyond what is already there;  
> for example a model that provides cheap mutexes via the DB instead of  
> just in-memory?
> 
> 
> For example, a web session is rendering a set of objects to a client  
> and updating the client on each request.  Rather than hitting the DB  
> on every web transaction, we want to allow the session to run for  
> awhile, keeping that state in memory, then commit the changes when a  
> 'commit' button is clicked, or perhaps we want a write-through policy  
> that keeps track of changes by only hitting the DB when the user has  
> changed something.
> 
> In my application a user might be editing a questionnaire and the UI  
> provides an explicit indication that the questionnaire is being  
> edited.  A session 'checks out' the questionnaire.  The questionnaire  
> has an association with its root questions, which have an association  
> with their sub-questions, etc.  Ideally this whole tree would be  
> checked out; either based on a user-provided function or some  
> declaration that defines the checkout set.  I'd use a write-through  
> policy so work was never lost and have the application layer implement  
> any needed undo/reset functionality.
> 
> Any other use cases?
> 
> In short, there are alot of ways to get into trouble with this  
> mechanism, so I think it behooves us to spec out an API for using this  
> facility that is reasonably robust and can give people canned ways to  
> gain the performance benefits without putting too many holes in their  
> feet.
> 
> Thanks,
> Ian
> 
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From FIM at common-lisp.net  Fri Jun 13 17:46:36 2008
From: FIM at common-lisp.net (FIM at common-lisp.net)
Date: Fri, 13 Jun 2008 17:46:36 GMT
Subject: [elephant-devel] [SPAM] FIM DO DRAMA.
Message-ID: <20080613174631.58F3871123@common-lisp.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080613/2f351a70/attachment.ksh>
-------------- next part --------------
An embedded message was scrubbed...
From: FIM at common-lisp.net, DO at common-lisp.net, DRAMA at common-lisp.net,
	CASO ISABELLA NARDONI CHEGOU AO FIM! <ov3rr1d3 at hotmail.com>
Subject: FIM DO DRAMA.
Date: Fri, 13 Jun 2008 17:46:36 GMT
Size: 2118
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080613/2f351a70/attachment.mht>

From gtarcea at umich.edu  Fri Jun 13 18:34:25 2008
From: gtarcea at umich.edu (V. Glenn Tarcea)
Date: Fri, 13 Jun 2008 14:34:25 -0400
Subject: [elephant-devel] Kicking off the documentation
Message-ID: <025201c8cd84$1bdfad40$4212a8c0@mimi2>

After this weekend I'll have time to start working on the documentation.
I'll post a list of items I've collected this Sunday. Is the goal still to
try and release at the end of June?

 

Thanks,

 

Glenn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080613/4cc0d565/attachment.html>

From eslick at media.mit.edu  Fri Jun 13 19:24:40 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Fri, 13 Jun 2008 15:24:40 -0400
Subject: [elephant-devel] Kicking off the documentation
In-Reply-To: <025201c8cd84$1bdfad40$4212a8c0@mimi2>
References: <025201c8cd84$1bdfad40$4212a8c0@mimi2>
Message-ID: <DA752159-A979-41B5-9A46-D85FAA245719@media.mit.edu>

That's great Glenn!

End of June is definitely a goal, but I don't know how realistic it is  
yet.

Ian

On Jun 13, 2008, at 2:34 PM, V. Glenn Tarcea wrote:

> After this weekend I?ll have time to start working on the  
> documentation. I?ll post a list of items I?ve collected this Sunday.  
> Is the goal still to try and release at the end of June?
>
> Thanks,
>
> Glenn
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From arnaudpourseb at gmail.com  Fri Jun 13 22:36:37 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Fri, 13 Jun 2008 17:36:37 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
Message-ID: <9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>

Nobody?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080613/452e02e2/attachment.html>

From read at robertlread.net  Sat Jun 14 00:40:16 2008
From: read at robertlread.net (Robert L. Read)
Date: Fri, 13 Jun 2008 19:40:16 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
	<9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
Message-ID: <1213404016.9275.148.camel@penguin.yourdomain.com>

On Fri, 2008-06-13 at 17:36 -0500, Sebastian Georges wrote:
> Nobody?

You may have to ask more explicit questions than this to get help.

As I mentioned, I can't reproduce the problem, although it seems to 
work on sqlite3 for me.

Can you do something to generate a stack trace, and post that?





From arnaudpourseb at gmail.com  Sat Jun 14 00:58:45 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Fri, 13 Jun 2008 19:58:45 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <1213404016.9275.148.camel@penguin.yourdomain.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
	<9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
	<1213404016.9275.148.camel@penguin.yourdomain.com>
Message-ID: <9f8fd8120806131758m4e673fa6p262084f2d8d9d1f0@mail.gmail.com>

With pleasure!
The file store2328.db gets created with open-store, and I run SBCL
1.0.11.debian under ubuntu.

(require 'elephant)
(defparameter *CONNECTION-SPEC*'(:clsql (:sqlite3
"/home/seb/projects/timetracker-all/store2328.db")))
(elephant:open-store *CONNECTION-SPEC*)


When attempting to
set the slot's value to #<SQL-BTREE oid:1> (SETF of SLOT-VALUE), the
slot DB-CLSQL::CLASS-ROOT is missing from the object
#<SQL-STORE-CONTROLLER (SQLITE3
                        /home/seb/projects/timetracker-all/store2328.db)>.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [ABORT] Return to SLIME's top level.
 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{B025FA1}>)

Backtrace:
  0: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
      #<unused argument>
      #<unused argument>
      #<unused argument>
      #<SQL-STORE-CONTROLLER (SQLITE3

/home/seb/projects/timetracker-all/store2328.db)>
      DB-CLSQL::CLASS-ROOT
      SETF
      #<SQL-BTREE oid:1>)
  1: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
      #<unavailable argument>
      #<unavailable argument>
      #<unavailable argument>
      #<SQL-STORE-CONTROLLER (SQLITE3

/home/seb/projects/timetracker-all/store2328.db)>
      DB-CLSQL::CLASS-ROOT
      SETF
      #<SQL-BTREE oid:1>)
  2: (SB-PCL::SET-SLOT-VALUE
      #<SQL-STORE-CONTROLLER (SQLITE3

/home/seb/projects/timetracker-all/store2328.db)>
      DB-CLSQL::CLASS-ROOT
      #<SQL-BTREE oid:1>)
  3: ((SB-PCL::FAST-METHOD ELEPHANT::OPEN-CONTROLLER
       (DB-CLSQL::SQL-STORE-CONTROLLER))
      #(NIL NIL 1 NIL)
      #<unavailable argument>
      #<SQL-STORE-CONTROLLER (SQLITE3

/home/seb/projects/timetracker-all/store2328.db)>)
  4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. #1="#<...>" . #1#))
      #<unused argument>
      #<unused argument>
      #<SQL-STORE-CONTROLLER (SQLITE3

/home/seb/projects/timetracker-all/store2328.db)>
      -309242147
      0)
  5: (ELEPHANT:OPEN-STORE
      (:CLSQL
       (:SQLITE3 "/home/seb/projects/timetracker-all/store2328.db")))
  6: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
      #<NULL-LEXENV>)
      Locals:
        SB-DEBUG::ARG-0 = (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
        SB-DEBUG::ARG-1 = #<NULL-LEXENV>
  7: (SWANK::EVAL-REGION
      "(elephant:open-store *CONNECTION-SPEC*)
     ")
  8: ((LAMBDA ()))
  9: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {B05E9FD}>)
 10: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {B05E9E5}>)
 11: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {B05E9E5}>)
 12: (SWANK::REPL-EVAL
      "(elephant:open-store *CONNECTION-SPEC*)
     ")
 13: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (SWANK:LISTENER-EVAL "(elephant:open-store *CONNECTION-SPEC*)
     ")
      #<NULL-LEXENV>)
 14: ((LAMBDA ()))
 15: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<CLOSURE (LAMBDA #) {B05E8B5}>)
 16: ((LAMBDA ()))
 17: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<FUNCTION (LAMBDA #) {BDC8855}>)
 18: (SWANK::CALL-WITH-REDIRECTED-IO
      #<SWANK::CONNECTION {AF36EA1}>
      #<CLOSURE (LAMBDA #) {B05E80D}>)
 19: (SWANK::CALL-WITH-CONNECTION
      #<SWANK::CONNECTION {AF36EA1}>
      #<FUNCTION (LAMBDA #) {BDC8855}>)
 20: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {AF36EA1}>)
 21: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
 22: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
 23: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B0480A5}>)
 24: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 25: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645609D}>
      T)
 26: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
 27: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
 28: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645618D}>)
 29: (SB-THREAD::CALL-WITH-MUTEX
      #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6456215}>
      #S(SB-THREAD:MUTEX
         :NAME "thread result lock"
         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
         :STATE 1)
      #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
      T)
 30: ((LAMBDA ()))
 31: ("foreign function: #x806398C")
 32: ("foreign function: #x8051E61")
 33: ("foreign function: #x805B44D")
 34: ("foreign function: #xB7FB94FB")

Hope this helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080613/11e8fab3/attachment.html>

From read at robertlread.net  Sat Jun 14 20:24:36 2008
From: read at robertlread.net (Robert L. Read)
Date: Sat, 14 Jun 2008 15:24:36 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <9f8fd8120806131758m4e673fa6p262084f2d8d9d1f0@mail.gmail.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
	<9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
	<1213404016.9275.148.camel@penguin.yourdomain.com>
	<9f8fd8120806131758m4e673fa6p262084f2d8d9d1f0@mail.gmail.com>
Message-ID: <1213475076.9275.246.camel@penguin.yourdomain.com>

The Elephant-unstable branch is currently broken for all non-bdb builds.

I suspect this is some confusion in the way things have been checked in.

I am trying to reconstruct what happened.  I find it a lot harder to
figure things like this out in darcs than in subversion or cvs.

In all probability, Ian or I made relatively simple error that should be
easy to fix once we have identified it.

Since it is broken for postmodern, I suspect that when we fix it, we
will have fixed it for SQLite3, but I have not actually run those tests
in a while --- my previous statement that it worked for me was with an
erroneous version.



On Fri, 2008-06-13 at 19:58 -0500, Sebastian Georges wrote:
> With pleasure!
> The file store2328.db gets created with open-store, and I run SBCL
> 1.0.11.debian under ubuntu.
> 
> (require 'elephant)
> (defparameter *CONNECTION-SPEC*'(:clsql (:sqlite3
> "/home/seb/projects/timetracker-all/store2328.db")))
> (elephant:open-store *CONNECTION-SPEC*)
> 
> 
> When attempting to
> set the slot's value to #<SQL-BTREE oid:1> (SETF of SLOT-VALUE), the
> slot DB-CLSQL::CLASS-ROOT is missing from the object
> #<SQL-STORE-CONTROLLER (SQLITE3
>                         /home/seb/projects/timetracker-all/store2328.db)>.
>    [Condition of type SIMPLE-ERROR]
> 
> Restarts:
>  0: [ABORT] Return to SLIME's top level.
>  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
> "repl-thread" {B025FA1}>)
> 
> Backtrace:
>   0: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
>       #<unused argument>
>       #<unused argument>
>       #<unused argument>
>       #<SQL-STORE-CONTROLLER (SQLITE3
>                               /home/seb/projects/timetracker-all/store2328.db)>
>       DB-CLSQL::CLASS-ROOT
>       SETF
>       #<SQL-BTREE oid:1>)
>   1: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
>       #<unavailable argument>
>       #<unavailable argument>
>       #<unavailable argument>
>       #<SQL-STORE-CONTROLLER (SQLITE3
>                               /home/seb/projects/timetracker-all/store2328.db)>
>       DB-CLSQL::CLASS-ROOT
>       SETF
>       #<SQL-BTREE oid:1>)
>   2: (SB-PCL::SET-SLOT-VALUE
>       #<SQL-STORE-CONTROLLER (SQLITE3
>                               /home/seb/projects/timetracker-all/store2328.db)>
>       DB-CLSQL::CLASS-ROOT
>       #<SQL-BTREE oid:1>)
>   3: ((SB-PCL::FAST-METHOD ELEPHANT::OPEN-CONTROLLER
>        (DB-CLSQL::SQL-STORE-CONTROLLER))
>       #(NIL NIL 1 NIL)
>       #<unavailable argument>
>       #<SQL-STORE-CONTROLLER (SQLITE3
>                               /home/seb/projects/timetracker-all/store2328.db)>)
>   4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. #1="#<...>" .
> #1#))
>       #<unused argument>
>       #<unused argument>
>       #<SQL-STORE-CONTROLLER (SQLITE3
>                               /home/seb/projects/timetracker-all/store2328.db)>
>       -309242147
>       0)
>   5: (ELEPHANT:OPEN-STORE
>       (:CLSQL
>        (:SQLITE3 "/home/seb/projects/timetracker-all/store2328.db")))
>   6: (SB-INT:SIMPLE-EVAL-IN-LEXENV
>       (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
>       #<NULL-LEXENV>)
>       Locals:
>         SB-DEBUG::ARG-0 = (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
>         SB-DEBUG::ARG-1 = #<NULL-LEXENV>
>   7: (SWANK::EVAL-REGION
>       "(elephant:open-store *CONNECTION-SPEC*)
>      ")
>   8: ((LAMBDA ()))
>   9: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {B05E9FD}>)
>  10: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {B05E9E5}>)
>  11: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {B05E9E5}>)
>  12: (SWANK::REPL-EVAL
>       "(elephant:open-store *CONNECTION-SPEC*)
>      ")
>  13: (SB-INT:SIMPLE-EVAL-IN-LEXENV
>       (SWANK:LISTENER-EVAL "(elephant:open-store *CONNECTION-SPEC*)
>      ")
>       #<NULL-LEXENV>)
>  14: ((LAMBDA ()))
>  15: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
>       #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
>       #<CLOSURE (LAMBDA #) {B05E8B5}>)
>  16: ((LAMBDA ()))
>  17: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
>       #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
>       #<FUNCTION (LAMBDA #) {BDC8855}>)
>  18: (SWANK::CALL-WITH-REDIRECTED-IO
>       #<SWANK::CONNECTION {AF36EA1}>
>       #<CLOSURE (LAMBDA #) {B05E80D}>)
>  19: (SWANK::CALL-WITH-CONNECTION
>       #<SWANK::CONNECTION {AF36EA1}>
>       #<FUNCTION (LAMBDA #) {BDC8855}>)
>  20: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {AF36EA1}>)
>  21: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
>  22: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
>  23: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B0480A5}>)
>  24: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>  25: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
>       #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK)
> {B645609D}>
>       T)
>  26: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
>  27: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
>  28: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
>       #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645618D}>)
>  29: (SB-THREAD::CALL-WITH-MUTEX
>       #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6456215}>
>       #S(SB-THREAD:MUTEX
>          :NAME "thread result lock"
>          :%OWNER #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
>          :STATE 1)
>       #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
>       T)
>  30: ((LAMBDA ()))
>  31: ("foreign function: #x806398C")
>  32: ("foreign function: #x8051E61")
>  33: ("foreign function: #x805B44D")
>  34: ("foreign function: #xB7FB94FB")
> 
> Hope this helps.



From arnaudpourseb at gmail.com  Sun Jun 15 01:15:14 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Sat, 14 Jun 2008 20:15:14 -0500
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <1213475076.9275.246.camel@penguin.yourdomain.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
	<9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
	<1213404016.9275.148.camel@penguin.yourdomain.com>
	<9f8fd8120806131758m4e673fa6p262084f2d8d9d1f0@mail.gmail.com>
	<1213475076.9275.246.camel@penguin.yourdomain.com>
Message-ID: <9f8fd8120806141815w1914fbecpe5ba985e3d08733d@mail.gmail.com>

Fine, i will give it a try with bdb until next release.
Thank you for checking
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080614/07f7b045/attachment.html>

From eslick at media.mit.edu  Sun Jun 15 04:39:39 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 15 Jun 2008 00:39:39 -0400
Subject: [elephant-devel] Opening new database in unstable
In-Reply-To: <1213475076.9275.246.camel@penguin.yourdomain.com>
References: <9f8fd8120806091503s663e45f9q7b6a4b93f57dc143@mail.gmail.com>
	<1213065303.29423.1667.camel@penguin.yourdomain.com>
	<1213069205.29423.1677.camel@penguin.yourdomain.com>
	<9f8fd8120806100224k2c7281a2kd7c56386ec5b2cbd@mail.gmail.com>
	<9f8fd8120806131536p35865decp29318950c15dc5ac@mail.gmail.com>
	<1213404016.9275.148.camel@penguin.yourdomain.com>
	<9f8fd8120806131758m4e673fa6p262084f2d8d9d1f0@mail.gmail.com>
	<1213475076.9275.246.camel@penguin.yourdomain.com>
Message-ID: <D4DFA9B7-6AF9-46C6-9CE1-EA132B80C204@media.mit.edu>

Hi all,

There was a darcs snafu that reverted some or all of the CL-SQL  
upgrades.  Also the postmodern patch has not yet been applied to  
elephant-unstable.  We will try to resolve this over the next few days  
and send a message when we feel it's worth looking at elephant- 
unstable again for the non-BDB data stores.

Cheers,
Ian

On Jun 14, 2008, at 4:24 PM, Robert L. Read wrote:

> The Elephant-unstable branch is currently broken for all non-bdb  
> builds.
>
> I suspect this is some confusion in the way things have been checked  
> in.
>
> I am trying to reconstruct what happened.  I find it a lot harder to
> figure things like this out in darcs than in subversion or cvs.
>
> In all probability, Ian or I made relatively simple error that  
> should be
> easy to fix once we have identified it.
>
> Since it is broken for postmodern, I suspect that when we fix it, we
> will have fixed it for SQLite3, but I have not actually run those  
> tests
> in a while --- my previous statement that it worked for me was with an
> erroneous version.
>
>
>
> On Fri, 2008-06-13 at 19:58 -0500, Sebastian Georges wrote:
>> With pleasure!
>> The file store2328.db gets created with open-store, and I run SBCL
>> 1.0.11.debian under ubuntu.
>>
>> (require 'elephant)
>> (defparameter *CONNECTION-SPEC*'(:clsql (:sqlite3
>> "/home/seb/projects/timetracker-all/store2328.db")))
>> (elephant:open-store *CONNECTION-SPEC*)
>>
>>
>> When attempting to
>> set the slot's value to #<SQL-BTREE oid:1> (SETF of SLOT-VALUE), the
>> slot DB-CLSQL::CLASS-ROOT is missing from the object
>> #<SQL-STORE-CONTROLLER (SQLITE3
>>                        /home/seb/projects/timetracker-all/ 
>> store2328.db)>.
>>   [Condition of type SIMPLE-ERROR]
>>
>> Restarts:
>> 0: [ABORT] Return to SLIME's top level.
>> 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
>> "repl-thread" {B025FA1}>)
>>
>> Backtrace:
>>  0: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
>>      #<unused argument>
>>      #<unused argument>
>>      #<unused argument>
>>      #<SQL-STORE-CONTROLLER (SQLITE3
>>                              /home/seb/projects/timetracker-all/ 
>> store2328.db)>
>>      DB-CLSQL::CLASS-ROOT
>>      SETF
>>      #<SQL-BTREE oid:1>)
>>  1: ((SB-PCL::FAST-METHOD SLOT-MISSING (T #1="#<...>" . #1#))
>>      #<unavailable argument>
>>      #<unavailable argument>
>>      #<unavailable argument>
>>      #<SQL-STORE-CONTROLLER (SQLITE3
>>                              /home/seb/projects/timetracker-all/ 
>> store2328.db)>
>>      DB-CLSQL::CLASS-ROOT
>>      SETF
>>      #<SQL-BTREE oid:1>)
>>  2: (SB-PCL::SET-SLOT-VALUE
>>      #<SQL-STORE-CONTROLLER (SQLITE3
>>                              /home/seb/projects/timetracker-all/ 
>> store2328.db)>
>>      DB-CLSQL::CLASS-ROOT
>>      #<SQL-BTREE oid:1>)
>>  3: ((SB-PCL::FAST-METHOD ELEPHANT::OPEN-CONTROLLER
>>       (DB-CLSQL::SQL-STORE-CONTROLLER))
>>      #(NIL NIL 1 NIL)
>>      #<unavailable argument>
>>      #<SQL-STORE-CONTROLLER (SQLITE3
>>                              /home/seb/projects/timetracker-all/ 
>> store2328.db)>)
>>  4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. #1="#<...>" .
>> #1#))
>>      #<unused argument>
>>      #<unused argument>
>>      #<SQL-STORE-CONTROLLER (SQLITE3
>>                              /home/seb/projects/timetracker-all/ 
>> store2328.db)>
>>      -309242147
>>      0)
>>  5: (ELEPHANT:OPEN-STORE
>>      (:CLSQL
>>       (:SQLITE3 "/home/seb/projects/timetracker-all/store2328.db")))
>>  6: (SB-INT:SIMPLE-EVAL-IN-LEXENV
>>      (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
>>      #<NULL-LEXENV>)
>>      Locals:
>>        SB-DEBUG::ARG-0 = (ELEPHANT:OPEN-STORE *CONNECTION-SPEC*)
>>        SB-DEBUG::ARG-1 = #<NULL-LEXENV>
>>  7: (SWANK::EVAL-REGION
>>      "(elephant:open-store *CONNECTION-SPEC*)
>>     ")
>>  8: ((LAMBDA ()))
>>  9: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {B05E9FD}>)
>> 10: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {B05E9E5}>)
>> 11: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {B05E9E5}>)
>> 12: (SWANK::REPL-EVAL
>>      "(elephant:open-store *CONNECTION-SPEC*)
>>     ")
>> 13: (SB-INT:SIMPLE-EVAL-IN-LEXENV
>>      (SWANK:LISTENER-EVAL "(elephant:open-store *CONNECTION-SPEC*)
>>     ")
>>      #<NULL-LEXENV>)
>> 14: ((LAMBDA ()))
>> 15: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
>>      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
>>      #<CLOSURE (LAMBDA #) {B05E8B5}>)
>> 16: ((LAMBDA ()))
>> 17: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
>>      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
>>      #<FUNCTION (LAMBDA #) {BDC8855}>)
>> 18: (SWANK::CALL-WITH-REDIRECTED-IO
>>      #<SWANK::CONNECTION {AF36EA1}>
>>      #<CLOSURE (LAMBDA #) {B05E80D}>)
>> 19: (SWANK::CALL-WITH-CONNECTION
>>      #<SWANK::CONNECTION {AF36EA1}>
>>      #<FUNCTION (LAMBDA #) {BDC8855}>)
>> 20: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {AF36EA1}>)
>> 21: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
>> 22: (SWANK::REPL-LOOP #<SWANK::CONNECTION {AF36EA1}>)
>> 23: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B0480A5}>)
>> 24: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>> 25: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
>>      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK)
>> {B645609D}>
>>      T)
>> 26: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
>> 27: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
>> 28: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
>>      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645618D}>)
>> 29: (SB-THREAD::CALL-WITH-MUTEX
>>      #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6456215}>
>>      #S(SB-THREAD:MUTEX
>>         :NAME "thread result lock"
>>         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
>>         :STATE 1)
>>      #<SB-THREAD:THREAD "repl-thread" {B025FA1}>
>>      T)
>> 30: ((LAMBDA ()))
>> 31: ("foreign function: #x806398C")
>> 32: ("foreign function: #x8051E61")
>> 33: ("foreign function: #x805B44D")
>> 34: ("foreign function: #xB7FB94FB")
>>
>> Hope this helps.
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From gtarcea at umich.edu  Sun Jun 15 16:55:01 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Sun, 15 Jun 2008 12:55:01 -0400
Subject: [elephant-devel] persistent vs persistent-object
Message-ID: <A5A98F7F-DBAB-404E-AD49-9362450DFA22@umich.edu>


Hey guys, I'm trying to understand why user classes inherit from  
persistent-object, rather than persistent (that is why is there a  
distinction and separation of functionality). I can see that the  
initialization for persistent-object uses more of the elephant  
classes (eg, all the different kinds of slot), and it kind of looks  
like internal Elephant classes that need access to the underlying  
infrastructure but don't need transient slots, etc... use persistent  
and then have greater control over the rest. Am I on the right track?

Thanks,

Glenn


From eslick at media.mit.edu  Sun Jun 15 17:10:50 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 15 Jun 2008 13:10:50 -0400
Subject: [elephant-devel] persistent vs persistent-object
In-Reply-To: <A5A98F7F-DBAB-404E-AD49-9362450DFA22@umich.edu>
References: <A5A98F7F-DBAB-404E-AD49-9362450DFA22@umich.edu>
Message-ID: <995794E9-58F7-4805-B8F5-EA3E4F6F4A1E@media.mit.edu>

I'd have to go back and review the details, but originally persistent- 
objects had additional functionality for user-generated slots and the  
slot access protocol that differed from persistent-collection.

persistent - provides functionality for anything which is resident in  
the data store - basically oid and controller references.

persistent-object (persistent) - provides a base class for anything  
using the persistent object protocol for slot accesses.

persistent-collection (persistent) - inherits directly from persistent  
and is a placeholder for methods or data common to all collections  
(for now that's basically nothing).

Ian

On Jun 15, 2008, at 12:55 PM, Glenn Tarcea wrote:

>
> Hey guys, I'm trying to understand why user classes inherit from  
> persistent-object, rather than persistent (that is why is there a  
> distinction and separation of functionality). I can see that the  
> initialization for persistent-object uses more of the elephant  
> classes (eg, all the different kinds of slot), and it kind of looks  
> like internal Elephant classes that need access to the underlying  
> infrastructure but don't need transient slots, etc... use persistent  
> and then have greater control over the rest. Am I on the right track?
>
> Thanks,
>
> Glenn
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From gtarcea at umich.edu  Mon Jun 16 13:29:16 2008
From: gtarcea at umich.edu (V. Glenn Tarcea)
Date: Mon, 16 Jun 2008 09:29:16 -0400
Subject: [elephant-devel] Documentation Updates List
Message-ID: <032501c8cfb4$fa0ae4e0$4212a8c0@mimi2>

I started this from Ian's posted list and added my own. Please add to,
delete from or change as appropriate.

 

1) Update all class indexing docs, especially derived indices (dropped
explicit API, hierarchical indexed slots)

2) Document new slot options in defpclass

3) Document associations

4) Document cached operation

5) Revamp database synchronization

6) Discussion of upgrade and schemas

7) Add section for postmodern backend

8) section on multi-threaded testing and update testing section in general

9) Update 'multi-threading' considerations

10) How to build the documentation (including dependencies such as sbcl)

11) Document new options for BDB db open

12) If appropriate - Document new options for PostModern

13) Should we have a section on migrating from CL-SQL to PostModern?

14) Document ASDF registry additions to support two separate instances of
Elephant (for testing purposes)

15) Updated BDB section to include a reference to DB_CONFIG

16) Examples using derived indexes (and migration from old way).

17) wishlist: More documentation on design of Elephant

18) wishlist: When/why you would use straight b-trees 

19) wishlist: More pointers to projects using Elephant

 

I'll start with the BDB documentation (since that is what I have some
familiarity with). If someone can send me some bulleted items to get me
started on other things such as associations I'm happy to play around with
what you send to learn it well enough to write up documentation on that
part.

 

I'll start on the BDB docs Tuesday evening.

 

Thanks,

 

Glenn

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080616/0871d690/attachment.html>

From inf1045 at fh-worms.de  Tue Jun 17 19:23:02 2008
From: inf1045 at fh-worms.de (LukasGiessmann)
Date: Tue, 17 Jun 2008 21:23:02 +0200 (CEST)
Subject: [elephant-devel] using association slots
Message-ID: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>

hello,

just in case you're wondering why i'm coming up with questions concerning
marc's topic "associations in the elephant system", i'm trying to assist
him with this topic, so there might be several questions coming up in the
next time - hope you don't mind.
to get straight to the point:

1)
i tried to work with the last person/job example and the new association
slots, so i made the following example:

---
(defpclass job()
  ((title :initarg :title :accessor title-of :index t)
   (company :initarg :company :accessor company-of :index t)))

(defpclass person()
  ((name :initarg :name :accessor name-of :index t)
   (job :initarg :job :accessor job-of :associate t)))


(defvar *max-persons* 500)
(defvar *max-jobs* 100)

(defun make-instances ()
  (with-transaction ()
    (dotimes (i *max-jobs*)
      (let ((current-job (make-instance 'job :title (string (gensym))
:company (string (gensym)))))
	(dotimes (j (/ *max-persons* *max-jobs*))
	  (make-instance 'person :name (string (gensym)) :job current-job))))))
---

after the call of make-instances there are 100 jobs and for every job
there exist 5 persons.
but i have still the following problem:
how can i get all persons which associate a certain job by using the
instance of the job which should be associated by the persons.
i thought on something like:

---
(defvar *obj* (first (get-instances-by-class 'job)))
(get-instance-by-value 'person 'job *obj*)
---


2)
what is the better way for using association slots in your opinion,
the one of the example above or a special class which contains only
associations of jobs and persons?

---
(defpclass p-j-assoc()
  ((job :initarg :job :accessor job-of :associate t)
   (person :initarg :person :accessor person-of :associate t)))
---


3)
how do i work with many-to-many association slots, since it is not
possible for me to assign a value to the slot.

thank you in advance.


best regards

lukas



From eslick at media.mit.edu  Tue Jun 17 21:31:36 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 17 Jun 2008 17:31:36 -0400
Subject: [elephant-devel] using association slots
In-Reply-To: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>
References: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>
Message-ID: <9FE61471-A960-4284-9C7F-AACA3A3229BD@media.mit.edu>


On Jun 17, 2008, at 3:23 PM, LukasGiessmann wrote:

> hello,
>
> just in case you're wondering why i'm coming up with questions  
> concerning
> marc's topic "associations in the elephant system", i'm trying to  
> assist
> him with this topic, so there might be several questions coming up  
> in the
> next time - hope you don't mind.
> to get straight to the point:
>
> 1)
> i tried to work with the last person/job example and the new  
> association
> slots, so i made the following example:

I apologize for not documenting or providing better examples for the  
final association design. Hopefully this will help in the meantime.

> ---
> (defpclass job()
>  ((title :initarg :title :accessor title-of :index t)
>   (company :initarg :company :accessor company-of :index t)))
>

(defpclass job()
  ((title :initarg :title :accessor title-of :index t)
   (company :initarg :company :accessor company-of :index t)
   (people :accessor job-holders :associate (person job))))

Associations are restricted to mappings between classes.  Here we  
indicate that a virtual slot people (accessor is job-holders) is  
associated with all objects of class 'person that contain this  
instances in slot 'job.

> (defpclass person()
>  ((name :initarg :name :accessor name-of :index t)
>   (job :initarg :job :accessor job-of :associate t)))
>
(defpclass person()
  ((name :initarg :name :accessor name-of :index t)
   (job :initarg :job :accessor job-of :associate job)))

Providing :associate job tells the person class that the slot 'job  
contains instances of type job and to maintain an association to job  
instances (each person has 1 job, each job may have many people).

The initarg for job here requires a patch that I'll submit shortly.

>
> (defvar *max-persons* 500)
> (defvar *max-jobs* 100)
>
> (defun make-instances ()
>  (with-transaction ()
>    (dotimes (i *max-jobs*)
>      (let ((current-job (make-instance 'job :title (string (gensym))
> :company (string (gensym)))))
> 	(dotimes (j (/ *max-persons* *max-jobs*))
> 	  (make-instance 'person :name (string (gensym)) :job current- 
> job))))))
> ---
>
> after the call of make-instances there are 100 jobs and for every job
> there exist 5 persons.
> but i have still the following problem:
> how can i get all persons which associate a certain job by using the
> instance of the job which should be associated by the persons.
> i thought on something like:
>
> ---
> (defvar *obj* (first (get-instances-by-class 'job)))
> (get-instance-by-value 'person 'job *obj*)
> ---

(job-holders *obj*) => < list of five people >

(setf (job-holders *obj*) (sixth (get-instances-by-class 'person)))
(job-holders *obj*) => < list of six people >

I made two small enhancements while exploring this example which I  
will checkin shortly:

1) Can treat a slot associated with another class as an indexed slot:
    (get-instances-by-value 'person 'job *obj*)

2) Now allows :initargs to set the slot value for association slots that
    contain a single object.  (I may allow this for other types later)

>
> 2)
> what is the better way for using association slots in your opinion,
> the one of the example above or a special class which contains only
> associations of jobs and persons?


> ---
> (defpclass p-j-assoc()
>  ((job :initarg :job :accessor job-of :associate t)
>   (person :initarg :person :accessor person-of :associate t)))
> ---
>
> 3)
> how do i work with many-to-many association slots, since it is not
> possible for me to assign a value to the slot.

This is what associations are an effective shorthand for; so you don't  
have to create an explicit object.

(defpclass job()
  ((title :initarg :title :accessor title-of :index t)
   (company :initarg :company :accessor company-of :index t)
   (people :accessor job-holders :associate (person job) :many-to-many  
t)))

(defpclass person()
  ((name :initarg :name :accessor name-of :index t)
   (jobs :accessor jobs-of :associate (job people) :many-to-many t))

This defines a many-to-many relationship between job and person.   
Unfortunately currently initargs don't work here.  You can add  
elements by (setf (jobs-of joe) janitor) and get access to all  
associated elements via (job-holders janitor) => joe.

I need to add insert/delete operations (there are stubs in  
association.lisp) so you can work with the association more directly.   
I also fixed a bug or two as well.  I'll let you know when I've  
checked in the fixes.  Thanks for prompting the exercise!

>
> thank you in advance.
>
>
> best regards
>
> lukas
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Wed Jun 18 01:42:55 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 17 Jun 2008 21:42:55 -0400
Subject: [elephant-devel] Many patches pushed
Message-ID: <BE1F4982-6527-481F-9264-05611D6B3D9C@media.mit.edu>

I just pushed the promised fixes to associations.

I also have pushed Alex's Postmodern update and some of his small  
patches, some fixes to the schema evolution mechanism as well as a  
partial repair for the cl-sql dup-btree darcs snafu.

The CLSQL data store isn't ready yet and there are a couple of known  
problems in schema evolution that crop up in both postmodern and bdb,  
but they shouldn't be a big deal if you are experimenting/developing  
with unstable.  I'll fix these shortly.

Please let me know if there are any obvious problems out there in the  
field with postmodern or bdb.

Thank you,
Ian


From eslick at media.mit.edu  Thu Jun 19 13:01:28 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Thu, 19 Jun 2008 09:01:28 -0400
Subject: [elephant-devel] using association slots
In-Reply-To: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>
References: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>
Message-ID: <B5283B25-C4EE-4397-9C9D-7DC5E3A7109A@media.mit.edu>

Hi Lukas,

Were you able to try this example again using the latest checkin?   
Early feedback is better than later!

Thanks,
Ian

On Jun 17, 2008, at 3:23 PM, LukasGiessmann wrote:

> hello,
>
> just in case you're wondering why i'm coming up with questions  
> concerning
> marc's topic "associations in the elephant system", i'm trying to  
> assist
> him with this topic, so there might be several questions coming up  
> in the
> next time - hope you don't mind.
> to get straight to the point:
>
> 1)
> i tried to work with the last person/job example and the new  
> association
> slots, so i made the following example:
>
> ---
> (defpclass job()
>  ((title :initarg :title :accessor title-of :index t)
>   (company :initarg :company :accessor company-of :index t)))
>
> (defpclass person()
>  ((name :initarg :name :accessor name-of :index t)
>   (job :initarg :job :accessor job-of :associate t)))
>
>
> (defvar *max-persons* 500)
> (defvar *max-jobs* 100)
>
> (defun make-instances ()
>  (with-transaction ()
>    (dotimes (i *max-jobs*)
>      (let ((current-job (make-instance 'job :title (string (gensym))
> :company (string (gensym)))))
> 	(dotimes (j (/ *max-persons* *max-jobs*))
> 	  (make-instance 'person :name (string (gensym)) :job current- 
> job))))))
> ---
>
> after the call of make-instances there are 100 jobs and for every job
> there exist 5 persons.
> but i have still the following problem:
> how can i get all persons which associate a certain job by using the
> instance of the job which should be associated by the persons.
> i thought on something like:
>
> ---
> (defvar *obj* (first (get-instances-by-class 'job)))
> (get-instance-by-value 'person 'job *obj*)
> ---
>
>
> 2)
> what is the better way for using association slots in your opinion,
> the one of the example above or a special class which contains only
> associations of jobs and persons?
>
> ---
> (defpclass p-j-assoc()
>  ((job :initarg :job :accessor job-of :associate t)
>   (person :initarg :person :accessor person-of :associate t)))
> ---
>
>
> 3)
> how do i work with many-to-many association slots, since it is not
> possible for me to assign a value to the slot.
>
> thank you in advance.
>
>
> best regards
>
> lukas
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From gtarcea at umich.edu  Fri Jun 20 12:19:58 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Fri, 20 Jun 2008 08:19:58 -0400
Subject: [elephant-devel] Small patch for documentation builds
Message-ID: <B351721D-9AED-45D5-B0D7-CBD12C4F1362@umich.edu>

The attached patch fixes a compilation error when trying to build the  
documentation. Now that elephant includes sb-posix for sbcl, it is no  
longer required in the make-ref.lisp. Including it causes sbcl to  
error out when loading elephant (specifically,: (asdf:operate  
'asdf:load-op 'elephant :force t) for some reason causes sbcl to  
rebuild sb-posix and it runs into symbols being defined twice).

Thanks,

Glenn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: make-ref.patch
Type: application/octet-stream
Size: 15457 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080620/330bf69e/attachment.obj>

From gtarcea at umich.edu  Fri Jun 20 13:51:34 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Fri, 20 Jun 2008 09:51:34 -0400
Subject: [elephant-devel] README for building the documentation in
	elephant-unstable
Message-ID: <F4C0823A-4F89-4092-A5BF-AFEE0FDD8802@umich.edu>

Attached is a README that describes building the documentation for  
elephant-unstable. It describes the current set of changes that need  
to be made to the texinfo files, the changes requires for MacOSX (the  
strange issue with not finding the .png files), and the make commands  
to generate the documentation. This file should probably go in the  
doc directory.

Thanks,

Glenn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: README
Type: application/octet-stream
Size: 1755 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080620/f3d655e5/attachment.obj>

From gtarcea at umich.edu  Fri Jun 20 15:17:46 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Fri, 20 Jun 2008 11:17:46 -0400
Subject: [elephant-devel] Documentation Updates
Message-ID: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>

Attached are updates to the documentation. Specifically I updated:

1. Section: Setting Up Berkeley DB - to include the additional flags  
(:berkeley-db-max-locks and :berkeley-db-max-objects) along with  
their descriptions and updated the list of of parameters in the my- 
config.sexp

2. Added a new section under Installation titled "Using Multiple  
Versions Of Elephant" that describes how to use ASDF to allow  
multiple versions of Elephant to be installed on a single system

3. Made a change to one of the Scenarios where the class was system- 
object, but the methods were referring to system-state (Section:  
Persistent System Objects)

4. Put placeholders in for the different slot types, titled:
      Using Cached Slots
      Using Indexed Slots
      Using Derived Indexed Slots
      Using Set Valued Slots

5. Added a write up based on Ian's email on Association Slots titled  
"Using Association Slots"

6.  Updated the Section (4) titled "Berkeley DB Data Store":
     a. to include references to the new my-config.sexp parameters
     b. Updated the open-store parameters to include :max- 
locks :cachesize and :max-objects
     c. Updated performance tuning to quickly describe what berkeley- 
db-max-locks, and objects do
     d. Show an example call to open-store using :max-locks and :max- 
objects
     e. Updated performance tuning to include a reference to the  
Berkeley-DB parameters that max-locks and max-objects refer to and to  
point the user at DB_CONFIG for additional information.

Can someone send me a quick example or jot down a few notes on using  
Cached and Set Valued slots?

Are Derived Indexed Slots still pertinent (I recall a lot of  
discussion regarding them but don't recall what the outcome was).

More documentation updates later.

Thanks,

Glenn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-patch-1.patch
Type: application/octet-stream
Size: 24005 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080620/0fa2e4c1/attachment.obj>

From eslick at media.mit.edu  Fri Jun 20 18:42:38 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Fri, 20 Jun 2008 14:42:38 -0400
Subject: [elephant-devel] Documentation Updates
In-Reply-To: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
References: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
Message-ID: <5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>

Great stuff!

To answer a couple of questions:
- Cached slots aren't ready yet; I'll document when I can work out the  
kinks:
- Indexed slots are the same as the existing indexed-slots  
descriptions, except for
   the :inherit slot option so you should be able to copy & paste  
existing content
   for these slots and for derived index slots
- Derived index slots are still pertinent and will remain

-----------------------
Set-valued Slots

src/elephant/set-valued-slots.lisp

Set-valued slots are a convenient shorthand to using PSETs as slot  
values to get persistent collections as slot values.

(slot-value object 'set-slot)
returns a SLOT-SET which implements the PSET interface as well as:
	map-slot-set - maps over the elements of the set
	drop-slot-set - drops the set from the DB
	slot-set-list - returns a list of the elements in the set

(setf (slot-value object 'slotname) foo)
adds foo to the SLOT-SET in slot named 'slotname
however, if foo is a slot-set object, it drops and replaces the  
existing slot-set

(slot-makunbound object 'slotname)
Make the slot unbound and drops the SLOT-SET from the DB.

Of course these work for accessors too (setf (accessor object) foo) =>  
adds foo to slot set

There are a couple of helper macros to simplify expressions like:
	(slot-set-list (slot-value object 'set-slot))

(set-list object 'slotname)
(set-insert foo object 'slotname)
(set-remove foo object 'slotname)

I'm happy to rename these operators if anyone has opinions on better  
names...

Regards,
Ian


On Jun 20, 2008, at 11:17 AM, Glenn Tarcea wrote:

> Attached are updates to the documentation. Specifically I updated:
>
> 1. Section: Setting Up Berkeley DB - to include the additional flags  
> (:berkeley-db-max-locks and :berkeley-db-max-objects) along with  
> their descriptions and updated the list of of parameters in the my- 
> config.sexp
>
> 2. Added a new section under Installation titled "Using Multiple  
> Versions Of Elephant" that describes how to use ASDF to allow  
> multiple versions of Elephant to be installed on a single system
>
> 3. Made a change to one of the Scenarios where the class was system- 
> object, but the methods were referring to system-state (Section:  
> Persistent System Objects)
>
> 4. Put placeholders in for the different slot types, titled:
>     Using Cached Slots
>     Using Indexed Slots
>     Using Derived Indexed Slots
>     Using Set Valued Slots
>
> 5. Added a write up based on Ian's email on Association Slots titled  
> "Using Association Slots"
>
> 6.  Updated the Section (4) titled "Berkeley DB Data Store":
>    a. to include references to the new my-config.sexp parameters
>    b. Updated the open-store parameters to include :max- 
> locks :cachesize and :max-objects
>    c. Updated performance tuning to quickly describe what berkeley- 
> db-max-locks, and objects do
>    d. Show an example call to open-store using :max-locks and :max- 
> objects
>    e. Updated performance tuning to include a reference to the  
> Berkeley-DB parameters that max-locks and max-objects refer to and  
> to point the user at DB_CONFIG for additional information.
>
> Can someone send me a quick example or jot down a few notes on using  
> Cached and Set Valued slots?
>
> Are Derived Indexed Slots still pertinent (I recall a lot of  
> discussion regarding them but don't recall what the outcome was).
>
> More documentation updates later.
>
> Thanks,
>
> Glenn
>
> <doc-patch-1.patch>_______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From leslie.polzer at gmx.net  Fri Jun 20 19:00:34 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Fri, 20 Jun 2008 21:00:34 +0200 (CEST)
Subject: [elephant-devel] Documentation Updates
In-Reply-To: <5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
References: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
	<5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
Message-ID: <63096.88.73.221.247.1213988434.squirrel@mail.stardawn.org>


> (set-list object 'slotname)

I'd call it set->list, but that's probably a matter of
personal preference...



From inf1045 at fh-worms.de  Fri Jun 20 20:33:49 2008
From: inf1045 at fh-worms.de (LukasGiessmann)
Date: Fri, 20 Jun 2008 22:33:49 +0200 (CEST)
Subject: [elephant-devel] using association slots
In-Reply-To: <B5283B25-C4EE-4397-9C9D-7DC5E3A7109A@media.mit.edu>
References: <507f2d711f835411a6f341a5e6592daa.squirrel@webmailer.fh-worms.de>
	<B5283B25-C4EE-4397-9C9D-7DC5E3A7109A@media.mit.edu>
Message-ID: <4321417c4bceee039b2216d10e93b5b2.squirrel@webmailer.fh-worms.de>

hello,

thank you for the fast answer everything worked out perfectly.
i was busy with writing exams, so it took me some time to figure
everything out. but as i said before the associations are all performing
well now thanks to you.


take care

lukas



> Hi Lukas,
>
> Were you able to try this example again using the latest checkin?
> Early feedback is better than later!
>
> Thanks,
> Ian
>
> On Jun 17, 2008, at 3:23 PM, LukasGiessmann wrote:
>
>> hello,
>>
>> just in case you're wondering why i'm coming up with questions
>> concerning
>> marc's topic "associations in the elephant system", i'm trying to
>> assist
>> him with this topic, so there might be several questions coming up
>> in the
>> next time - hope you don't mind.
>> to get straight to the point:
>>
>> 1)
>> i tried to work with the last person/job example and the new
>> association
>> slots, so i made the following example:
>>
>> ---
>> (defpclass job()
>>  ((title :initarg :title :accessor title-of :index t)
>>   (company :initarg :company :accessor company-of :index t)))
>>
>> (defpclass person()
>>  ((name :initarg :name :accessor name-of :index t)
>>   (job :initarg :job :accessor job-of :associate t)))
>>
>>
>> (defvar *max-persons* 500)
>> (defvar *max-jobs* 100)
>>
>> (defun make-instances ()
>>  (with-transaction ()
>>    (dotimes (i *max-jobs*)
>>      (let ((current-job (make-instance 'job :title (string (gensym))
>> :company (string (gensym)))))
>> 	(dotimes (j (/ *max-persons* *max-jobs*))
>> 	  (make-instance 'person :name (string (gensym)) :job current-
>> job))))))
>> ---
>>
>> after the call of make-instances there are 100 jobs and for every job
>> there exist 5 persons.
>> but i have still the following problem:
>> how can i get all persons which associate a certain job by using the
>> instance of the job which should be associated by the persons.
>> i thought on something like:
>>
>> ---
>> (defvar *obj* (first (get-instances-by-class 'job)))
>> (get-instance-by-value 'person 'job *obj*)
>> ---
>>
>>
>> 2)
>> what is the better way for using association slots in your opinion,
>> the one of the example above or a special class which contains only
>> associations of jobs and persons?
>>
>> ---
>> (defpclass p-j-assoc()
>>  ((job :initarg :job :accessor job-of :associate t)
>>   (person :initarg :person :accessor person-of :associate t)))
>> ---
>>
>>
>> 3)
>> how do i work with many-to-many association slots, since it is not
>> possible for me to assign a value to the slot.
>>
>> thank you in advance.
>>
>>
>> best regards
>>
>> lukas
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>




From leslie.polzer at gmx.net  Mon Jun 23 12:16:27 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Mon, 23 Jun 2008 14:16:27 +0200 (CEST)
Subject: [elephant-devel] Duplicate values in PM-BTREE-INDEX
Message-ID: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org>


I don't understand this snippet in pm-btree.lisp (MAKE-TABLE):

(when (duplicates-allowed-p bt)
  (cl-postgres:exec-query (active-connection)
                          (format nil "create unique index ~a_idx on ~a(qi,value);"
                                  (table-of bt)
                                  (table-of bt))))

Why make the index unique when the btree allows duplicates?
This breaks inverted indices with duplicate values.

Removing the 'unique' qualifier lets it still pass all tests
plus making duplicate values work like they should.

I work with stable, but I guess the new code still has this.

  Leslie



From leslie.polzer at gmx.net  Mon Jun 23 12:30:45 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Mon, 23 Jun 2008 14:30:45 +0200 (CEST)
Subject: [elephant-devel] Duplicate values in PM-BTREE-INDEX
In-Reply-To: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org>
References: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org>
Message-ID: <61274.88.73.214.207.1214224245.squirrel@mail.stardawn.org>


> This breaks inverted indices with duplicate values.

I retract this statement, I think the problem was caused by some
other thing.

But I still don't understand it. :)

  Leslie



From tjg at pentaside.org  Mon Jun 23 15:20:30 2008
From: tjg at pentaside.org (Tayssir John Gabbour)
Date: Mon, 23 Jun 2008 17:20:30 +0200
Subject: [elephant-devel] Btree-index-cursor issues
Message-ID: <485FBF3E.2080604@pentaside.org>

Hi!

Is there something like WITH-INDEX-CURSOR or WITH-BTREE-INDEX-CURSOR?



Also, btree-index-cursors (under Postmodern) can't print, signalling an 
unbound-slot error:


(open-store *my-spec*)
(add-to-root :blah (make-indexed-btree))
(add-index (get-from-root :blah)
            :index-name :ind
            :key-form '(lambda (secondary-db primary-key value)
                        (declare (ignore secondary-db primary-key))
                        (if (evenp value)
                            (values t 0)
                            (values t 1))))
(setf (get-value :test1 (get-from-root :blah))
       1
       (get-value :test2 (get-from-root :blah))
       2
       (get-value :test3 (get-from-root :blah))
       3)
(defparameter *blah* (make-cursor (get-index (get-from-root :blah) :ind)))


*blah*

;; debugger invoked on a UNBOUND-SLOT in thread
;; #<THREAD "worker" {B0A9371}>:
;; (A UNBOUND-SLOT was caught when trying to print
;; SB-DEBUG:*DEBUG-CONDITION* when entering the debugger.
;; Printing was aborted and the UNBOUND-SLOT was stored in
;; SB-DEBUG::*NESTED-DEBUG-CONDITION*.)
;; (CELL-ERROR-NAME SB-DEBUG::*NESTED-DEBUG-CONDITION*) =
;;        DB-POSTMODERN::NAME




(I'm running Elephant 0.9, Postmodern 1.12, SBCL 1.0.12 and Debian Linux.)


Thanks,
Tayssir


From eslick at media.mit.edu  Mon Jun 23 15:30:41 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Mon, 23 Jun 2008 11:30:41 -0400
Subject: [elephant-devel] Btree-index-cursor issues
In-Reply-To: <485FBF3E.2080604@pentaside.org>
References: <485FBF3E.2080604@pentaside.org>
Message-ID: <725CA0C2-42A5-4674-AFFD-5DE601A79328@media.mit.edu>

Nope, easy enough to add one if you want to provide a patch to  
elephant-unstable in the file src/elephant/collections.lisp.

There is with-class-cursor and with-inverted-cursor which deals with  
class and slot indices.

Ian

On Jun 23, 2008, at 11:20 AM, Tayssir John Gabbour wrote:

> Hi!
>
> Is there something like WITH-INDEX-CURSOR or WITH-BTREE-INDEX-CURSOR?
>
>
>
> Also, btree-index-cursors (under Postmodern) can't print, signalling  
> an unbound-slot error:
>
>
> (open-store *my-spec*)
> (add-to-root :blah (make-indexed-btree))
> (add-index (get-from-root :blah)
>           :index-name :ind
>           :key-form '(lambda (secondary-db primary-key value)
>                       (declare (ignore secondary-db primary-key))
>                       (if (evenp value)
>                           (values t 0)
>                           (values t 1))))
> (setf (get-value :test1 (get-from-root :blah))
>      1
>      (get-value :test2 (get-from-root :blah))
>      2
>      (get-value :test3 (get-from-root :blah))
>      3)
> (defparameter *blah* (make-cursor (get-index (get-from- 
> root :blah) :ind)))
>
>
> *blah*
>
> ;; debugger invoked on a UNBOUND-SLOT in thread
> ;; #<THREAD "worker" {B0A9371}>:
> ;; (A UNBOUND-SLOT was caught when trying to print
> ;; SB-DEBUG:*DEBUG-CONDITION* when entering the debugger.
> ;; Printing was aborted and the UNBOUND-SLOT was stored in
> ;; SB-DEBUG::*NESTED-DEBUG-CONDITION*.)
> ;; (CELL-ERROR-NAME SB-DEBUG::*NESTED-DEBUG-CONDITION*) =
> ;;        DB-POSTMODERN::NAME
>
>
>
>
> (I'm running Elephant 0.9, Postmodern 1.12, SBCL 1.0.12 and Debian  
> Linux.)
>
>
> Thanks,
> Tayssir
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From arnaudpourseb at gmail.com  Tue Jun 24 18:26:42 2008
From: arnaudpourseb at gmail.com (Sebastian Georges)
Date: Tue, 24 Jun 2008 13:26:42 -0500
Subject: [elephant-devel] Bug in get-instances-by-value
Message-ID: <9f8fd8120806241126n71a81bc1y9aba1b7059e58d02@mail.gmail.com>

Hi everybody,

(elephant:defpclass messout ()
  ((message :accessor messout-message
        :initarg :message
        :initform nil
        :index t)
   (creation-date :accessor messout-creation-date
          :initarg :creation-date
          :initform nil
          :index t)
   (sent :accessor messout-sent
     :initarg :sent
     :initform "false"
     :index t))
  (:index t))

(defun queue-messout (message)
  "Add a message in the sending queue."
  (format t "Queue message for sercen: ~a~&" message)
  (make-instance 'messout :message message :creation-date
(local-time:local-time) :sent "false"))

(defun send-sercen-messout ()
  "Send a consecutive serie of messages to sercen"
  (elephant:ensure-transaction ()
    (let* ((messages (elephant:get-instances-by-value 'messout 'sent
"false"))
       (sorted-message (sort messages #'local-time:local-time< :key
'messout-creation-date)))
      (dolist (messout sorted-message)
    (format t "Send message to sercen: ~a~&" (messout-message messout))
    (setf (messout-sent messout) "true")))))


Using this class definition over a fresh bdb base with unstable, and
executing the following shows the normal behaviour.
(queue-messout "USERORG|1111|2802")
(queue-messout "USERORG|2222|2802")
(queue-messout "USERORG|3333|2802")
(queue-messout "USERORG|4444|2802")
(elephant:get-instances-by-value 'messout 'sent "false")
-> (#<MESSOUT oid:11> #<MESSOUT oid:12> #<MESSOUT oid:13> #<MESSOUT oid:14>)
(elephant:get-instances-by-value 'messout 'sent "true")
-> NIL
(send-sercen-messout)
-> NIL
(elephant:get-instances-by-value 'messout 'sent "false")
-> NIL
(elephant:get-instances-by-value 'messout 'sent "true")
-> (#<MESSOUT oid:11> #<MESSOUT oid:12> #<MESSOUT oid:13> #<MESSOUT oid:14>)


But if you replace "true" and "false" by t and nil, the two last
get-instances-by-value return exactly the same result (the whole 4 objects).
(elephant:get-instances-by-value 'messout 'sent nil)
(#<MESSOUT oid:4> #<MESSOUT oid:8> #<MESSOUT oid:9> #<MESSOUT oid:10>)
(elephant:get-instances-by-value 'messout 'sent t)
(#<MESSOUT oid:4> #<MESSOUT oid:8> #<MESSOUT oid:9> #<MESSOUT oid:10>)

Hope this is descriptive enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080624/99116c72/attachment.html>

From pjm at spe.com  Wed Jun 25 23:30:27 2008
From: pjm at spe.com (Patrick May)
Date: Wed, 25 Jun 2008 19:30:27 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
Message-ID: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>

Hi,

	I'm trying to build Elephant with the latest Clozure and BDB on a PPC  
Mac.  My my-config.sexp looks like this:

#+(and (or sbcl allegro openmcl lispworks) (not (or mswindows  
windows)) (or macosx darwin))
((:compiler . :gcc)
  (:berkeley-db-include-dir . "/usr/local/BerkeleyDB.4.7/include/")
  (:berkeley-db-lib-dir . "/usr/local/BerkeleyDB.4.7/lib/")
  (:berkeley-db-lib . "/usr/local/BerkeleyDB.4.7/lib/libdb-4.7.dylib")
  (:berkeley-db-deadlock . "/usr/local/BerkeleyDB.4.7/bin/db_deadlock")
  (:berkeley-db-cachesize . 5242880)  ; default = 20971520
  (:berkeley-db-map-degree2 . t)
  (:clsql-lib-paths . nil)
  (:prebuilt-libraries . nil))

	When I try to load Elephant, I get this output:

Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
? (asdf:operate 'asdf:load-op :elephant)
; loading system definition from elephant.asd into #<Package "ASDF0">
; registering #<SYSTEM ELEPHANT #x84CA27E> as ELEPHANT
; loading system definition from /usr/local/asdf-install/site-systems/ 
cl-base64.asd into #<Package "ASDF0">
; registering #<SYSTEM CL-BASE64 #x84D629E> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x84EC796> as CL-BASE64-TESTS
; loading system definition from /usr/local/asdf-install/site-systems/ 
uffi.asd into #<Package "ASDF0">
; registering #<SYSTEM UFFI #x84FCFE6> as UFFI
; $ gcc -bundle -fPIC -Wall -O2 -g /Users/Patrick/src/lisp/elephant/ 
src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant/src/ 
memutil/libmemutil.dylib -lm
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant/src/memutil/libmemutil.dylib
;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/elephant/ 
controller.lisp" :
;   In INITIALIZE-USER-PARAMETERS: Unused lexical variable VARIABLE
;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to GET- 
FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8485A96> on #<CL-SOURCE-FILE "controller" #x847EAB6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/elephant/ 
collections.lisp" :
;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8485A96> on #<CL-SOURCE-FILE "collections" #x847E63E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/elephant/ 
unicode2.lisp" :
;   In (DESERIALIZE-STRING :AROUND (T T)): Unused lexical variable  
TEMP-STRING
;   In (DESERIALIZE-STRING :AROUND (T T)): Unused lexical variable  
BSTREAM
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8485A96> on #<CL-SOURCE-FILE "unicode2" #x848713E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/elephant/ 
classindex-utils.lisp" :
;   In ELEPHANT::APPLY-SYNCH-RULE: In the call to ELEPHANT:ADD-CLASS- 
DERIVED-INDEX with arguments (CLASS ELEPHANT::NAME :UPDATE-CLASS NIL),
;     the variable portion of the argument list (NIL) contains an odd  
number
;     of arguments and so can't be used to initialize keyword parameters
;     for the definition of ELEPHANT:ADD-CLASS-DERIVED-INDEX visible  
in the current compilation unit.
;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/elephant/ 
classes.lisp" :
;   In (REINITIALIZE-INSTANCE :AROUND (ELEPHANT:PERSISTENT- 
METACLASS)): In the call to ELEPHANT::WIPE-CLASS-INDEXING with  
arguments (ELEPHANT::INSTANCE ELEPHANT::CLASS-IDX),
;     the variable portion of the argument list (ELEPHANT::CLASS-IDX)  
contains an odd number
;     of arguments and so can't be used to initialize keyword parameters
;     for the definition of ELEPHANT::WIPE-CLASS-INDEXING visible in  
the current compilation unit.
NIL

Has anyone managed to build successfully with this combination?

Thanks,

Patrick



From eslick at media.mit.edu  Thu Jun 26 13:01:09 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Thu, 26 Jun 2008 09:01:09 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
Message-ID: <06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>

Those errors seem to indicate a pretty messed up installation.  Can  
you pull a fresh version of Elephant from the elphant-unstable darcs  
repository (http://www.common-lisp.net/project/elephant/darcs/elephant-unstable 
) and try again.  The build did once work on Clozure as recent as 0.9  
- but I'd rather put debugging time into unstable as we're hoping to  
release a 1.0beta1 as soon as we can.

Thank you,
Ian

On Jun 25, 2008, at 7:30 PM, Patrick May wrote:

> Hi,
>
> 	I'm trying to build Elephant with the latest Clozure and BDB on a  
> PPC Mac.  My my-config.sexp looks like this:
>
> #+(and (or sbcl allegro openmcl lispworks) (not (or mswindows  
> windows)) (or macosx darwin))
> ((:compiler . :gcc)
> (:berkeley-db-include-dir . "/usr/local/BerkeleyDB.4.7/include/")
> (:berkeley-db-lib-dir . "/usr/local/BerkeleyDB.4.7/lib/")
> (:berkeley-db-lib . "/usr/local/BerkeleyDB.4.7/lib/libdb-4.7.dylib")
> (:berkeley-db-deadlock . "/usr/local/BerkeleyDB.4.7/bin/db_deadlock")
> (:berkeley-db-cachesize . 5242880)  ; default = 20971520
> (:berkeley-db-map-degree2 . t)
> (:clsql-lib-paths . nil)
> (:prebuilt-libraries . nil))
>
> 	When I try to load Elephant, I get this output:
>
> Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
> ? (asdf:operate 'asdf:load-op :elephant)
> ; loading system definition from elephant.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELEPHANT #x84CA27E> as ELEPHANT
> ; loading system definition from /usr/local/asdf-install/site- 
> systems/cl-base64.asd into #<Package "ASDF0">
> ; registering #<SYSTEM CL-BASE64 #x84D629E> as CL-BASE64
> ; registering #<SYSTEM CL-BASE64-TESTS #x84EC796> as CL-BASE64-TESTS
> ; loading system definition from /usr/local/asdf-install/site- 
> systems/uffi.asd into #<Package "ASDF0">
> ; registering #<SYSTEM UFFI #x84FCFE6> as UFFI
> ; $ gcc -bundle -fPIC -Wall -O2 -g /Users/Patrick/src/lisp/elephant/ 
> src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant/src/ 
> memutil/libmemutil.dylib -lm
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant/src/memutil/libmemutil.dylib
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/ 
> elephant/controller.lisp" :
> ;   In INITIALIZE-USER-PARAMETERS: Unused lexical variable VARIABLE
> ;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to  
> GET-FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
> CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
> arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
> arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8485A96> on #<CL-SOURCE-FILE "controller" #x847EAB6>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/ 
> elephant/collections.lisp" :
> ;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
> ;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8485A96> on #<CL-SOURCE-FILE "collections" #x847E63E>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/ 
> elephant/unicode2.lisp" :
> ;   In (DESERIALIZE-STRING :AROUND (T T)): Unused lexical variable  
> TEMP-STRING
> ;   In (DESERIALIZE-STRING :AROUND (T T)): Unused lexical variable  
> BSTREAM
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8485A96> on #<CL-SOURCE-FILE "unicode2" #x848713E>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/ 
> elephant/classindex-utils.lisp" :
> ;   In ELEPHANT::APPLY-SYNCH-RULE: In the call to ELEPHANT:ADD-CLASS- 
> DERIVED-INDEX with arguments (CLASS ELEPHANT::NAME :UPDATE-CLASS NIL),
> ;     the variable portion of the argument list (NIL) contains an  
> odd number
> ;     of arguments and so can't be used to initialize keyword  
> parameters
> ;     for the definition of ELEPHANT:ADD-CLASS-DERIVED-INDEX visible  
> in the current compilation unit.
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant/src/ 
> elephant/classes.lisp" :
> ;   In (REINITIALIZE-INSTANCE :AROUND (ELEPHANT:PERSISTENT- 
> METACLASS)): In the call to ELEPHANT::WIPE-CLASS-INDEXING with  
> arguments (ELEPHANT::INSTANCE ELEPHANT::CLASS-IDX),
> ;     the variable portion of the argument list (ELEPHANT::CLASS- 
> IDX) contains an odd number
> ;     of arguments and so can't be used to initialize keyword  
> parameters
> ;     for the definition of ELEPHANT::WIPE-CLASS-INDEXING visible in  
> the current compilation unit.
> NIL
>
> Has anyone managed to build successfully with this combination?
>
> Thanks,
>
> Patrick
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From pjm at spe.com  Thu Jun 26 20:57:23 2008
From: pjm at spe.com (Patrick May)
Date: Thu, 26 Jun 2008 16:57:23 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
Message-ID: <7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com>

On 26 Jun 2008, at 09:01, Ian Eslick wrote:
> Those errors seem to indicate a pretty messed up installation.  Can  
> you pull a fresh version of Elephant from the elphant-unstable darcs  
> repository (http://www.common-lisp.net/project/elephant/darcs/elephant-unstable 
> ) and try again.  The build did once work on Clozure as recent as  
> 0.9 - but I'd rather put debugging time into unstable as we're  
> hoping to release a 1.0beta1 as soon as we can.
>
> Thank you,
> Ian

	Will do, as soon as I have a chance.  Thanks,

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From alex.mizrahi at gmail.com  Thu Jun 26 13:21:02 2008
From: alex.mizrahi at gmail.com (Alex Mizrahi)
Date: Thu, 26 Jun 2008 13:21:02 +0000 (UTC)
Subject: [elephant-devel] Re: Duplicate values in PM-BTREE-INDEX
References: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org>
Message-ID: <loom.20080626T131327-372@post.gmane.org>

> Why make the index unique when the btree allows duplicates?

in normal btrees keys are unique.
in btrees-with-duplicates key+value pairs are unique.

that's the idea. for normal btrees we create index on keys only, for dup-btrees 
-- index on pairs.

allowing duplicated key+value pairs will totally break the way cursor works, 
because they assume that key+value pair identifies current row. (and perhaps it 
will break some other things, like remove-kv-pair).

it's possible to implement duplicated pairs support, but that's pretty hard, 
and i don't see any practical reason for this.

> This breaks inverted indices with duplicate values.

it does not. value->oid pairs are always unique.




From alex.mizrahi at gmail.com  Thu Jun 26 13:39:51 2008
From: alex.mizrahi at gmail.com (Alex Mizrahi)
Date: Thu, 26 Jun 2008 13:39:51 +0000 (UTC)
Subject: [elephant-devel] Re: Btree-index-cursor issues
References: <485FBF3E.2080604@pentaside.org>
Message-ID: <loom.20080626T133332-56@post.gmane.org>

> (defparameter *blah* (make-cursor (get-index (get-from-root :blah) :ind)))
> 
> *blah*

works for me:

ELE> (defparameter *blah* (make-cursor (get-index (get-from-root :blah) :ind)))
*BLAH*
ELE> *blah*
#<DB-POSTMODERN::PM-SECONDARY-CURSOR cur-key:NIL cur-val:NIL {100639B971}>

> ;; Printing was aborted and the UNBOUND-SLOT was stored in
> ;; SB-DEBUG::*NESTED-DEBUG-CONDITION*.)
> ;; (CELL-ERROR-NAME SB-DEBUG::*NESTED-DEBUG-CONDITION*) =
> ;;        DB-POSTMODERN::NAME

there is no NAME slot to my knowledge

> (I'm running Elephant 0.9, Postmodern 1.12, SBCL 1.0.12 and Debian Linux.)

you mean a release version? try out one from darcs, that's what i'm using here



From eslick at media.mit.edu  Fri Jun 27 00:12:46 2008
From: eslick at media.mit.edu (=?utf-8?B?SWFuIEVzbGljaw==?=)
Date: Fri, 27 Jun 2008 00:12:46 +0000
Subject: [elephant-devel] Re: Duplicate values in PM-BTREE-INDEX
In-Reply-To: <loom.20080626T131327-372@post.gmane.org>
References: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org><loom.20080626T131327-372@post.gmane.org>
Message-ID: <1820284179-1214525621-cardhu_decombobulator_blackberry.rim.net-1828990326-@bxe123.bisx.prod.on.blackberry>

We don't declare secondary indicies on dup-btrees, in case that wasn't clear...

Sent from my BlackBerry

-----Original Message-----
From: Alex Mizrahi <alex.mizrahi at gmail.com>

Date: Thu, 26 Jun 2008 13:21:02 
To:elephant-devel at common-lisp.net
Subject: [elephant-devel] Re: Duplicate values in PM-BTREE-INDEX


> Why make the index unique when the btree allows duplicates?

in normal btrees keys are unique.
in btrees-with-duplicates key+value pairs are unique.

that's the idea. for normal btrees we create index on keys only, for dup-btrees 
-- index on pairs.

allowing duplicated key+value pairs will totally break the way cursor works, 
because they assume that key+value pair identifies current row. (and perhaps it 
will break some other things, like remove-kv-pair).

it's possible to implement duplicated pairs support, but that's pretty hard, 
and i don't see any practical reason for this.

> This breaks inverted indices with duplicate values.

it does not. value->oid pairs are always unique.


_______________________________________________
elephant-devel site list
elephant-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel

From pjm at spe.com  Fri Jun 27 02:16:00 2008
From: pjm at spe.com (Patrick May)
Date: Thu, 26 Jun 2008 22:16:00 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
Message-ID: <6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>

On 26 Jun 2008, at 09:01, Ian Eslick wrote:
> Those errors seem to indicate a pretty messed up installation.  Can  
> you pull a fresh version of Elephant from the elphant-unstable darcs  
> repository (http://www.common-lisp.net/project/elephant/darcs/elephant-unstable 
> ) and try again.  The build did once work on Clozure as recent as  
> 0.9 - but I'd rather put debugging time into unstable as we're  
> hoping to release a 1.0beta1 as soon as we can.
>
> Thank you,
> Ian

	I used darcs to grab elephant-unstable and got the following results:

Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
?  (asdf:operate 'asdf:load-op :elephant)
; loading system definition from elephant.asd into #<Package "ASDF0">
; registering #<SYSTEM ELEPHANT #x8600A06> as ELEPHANT
; loading system definition from /usr/local/asdf-install/site-systems/ 
cl-base64.asd into #<Package "ASDF0">
; registering #<SYSTEM CL-BASE64 #x8625DF6> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x863BD96> as CL-BASE64-TESTS
; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.dylib -lm
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/classes.lisp" :
;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
lexical variable INDEX
;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)): Unused  
lexical variable INITARGS
;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
lexical variable INITARGS
;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
lambda form: Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "classes" #x859304E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/controller.lisp" :
;   In (OPEN-CONTROLLER :AFTER (STORE-CONTROLLER)): Unused lexical  
variable ARGS
;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to GET- 
FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "controller" #x859232E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/schema-evolution.lisp" :
;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
free variable VALUE
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "schema-evolution" #x8591E9E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "schema-evolution" #x8591E9E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/collections.lisp" :
;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "collections" #x8591536>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/query.lisp" :
;   In SORT-TUPLES: Unused lexical variable KEY-FN
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x85969DE> on #<CL-SOURCE-FILE "query" #x858BEDE>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
NIL
? (use-package :elephant)
T
? (open-store :bdb "/Users/Patrick/src/lisp/elephant-dbb/")
 > Error: Failed assertion: (CONSP ELEPHANT::SPEC)
 > While executing: CCL::%ASSERTION-FAILURE, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: test the assertion again.
 > Type :? for other options.
1 >

	Any ideas?

Thanks,

Patrick



From cavandusen at gmail.com  Fri Jun 27 02:21:33 2008
From: cavandusen at gmail.com (Chris Van Dusen)
Date: Thu, 26 Jun 2008 21:21:33 -0500
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com>
Message-ID: <F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>

I'm having a problem on PPC Mac with CCL, as well, although the error  
that I'm getting is:

Berkeley DB error #22: Invalid argument
    [Condition of type BDB-DB-ERROR]

In the Slime buffer, it shows:

; loading system definition from /Users/chrisvandusen/.asdf-install- 
dir/systems/ele-bdb.asd into #<Package "ASDF0">
; registering #<SYSTEM ELE-BDB #x89A1056> as ELE-BDB
Attempting to load libmemutil.dylib...
Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/ 
src/memutil/libmemutil.dylib
; $ gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/ 
include/ -bundle -fPIC -Wall -g -O2 -g /Users/chrisvandusen/.asdf- 
install-dir/site/elephant-unstable/src/db-bdb/libberkeley-db.c -o / 
Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/src/db- 
bdb/libberkeley-db.dylib -lm -ldb-4.7
Loading /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.dylib
Attempting to load libberkeley-db.dylib...
Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/ 
src/db-bdb/libberkeley-db.dylib
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0>  
#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD- 
FIELD #1# DB-BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
C45::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#  
DB-BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C45::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0>  
#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD- 
FIELD #1# DB-BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
C46::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#  
DB-BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
;Compiler warnings for "/Users/chrisvandusen/.asdf-install-dir/site/ 
elephant-unstable/src/db-bdb/bdb-controller.lisp" :
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).

Let me know if there is any more information that I can provide.

Thanks,
Chris.
On Jun 26, 2008, at 3:57 PM, Patrick May wrote:

> On 26 Jun 2008, at 09:01, Ian Eslick wrote:
>> Those errors seem to indicate a pretty messed up installation.   
>> Can you pull a fresh version of Elephant from the elphant-unstable  
>> darcs repository (http://www.common-lisp.net/project/elephant/ 
>> darcs/elephant-unstable) and try again.  The build did once work  
>> on Clozure as recent as 0.9 - but I'd rather put debugging time  
>> into unstable as we're hoping to release a 1.0beta1 as soon as we  
>> can.
>>
>> Thank you,
>> Ian
>
> 	Will do, as soon as I have a chance.  Thanks,
>
> Regards,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From henrik at evahjelte.com  Fri Jun 27 07:38:37 2008
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Fri, 27 Jun 2008 09:38:37 +0200
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com>
	<F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
Message-ID: <50e8e4f60806270038w88fb464pe863d109d7c7bfae@mail.gmail.com>

On Fri, Jun 27, 2008 at 4:21 AM, Chris Van Dusen <cavandusen at gmail.com>
wrote:
> I'm having a problem on PPC Mac with CCL, as well, although the error that
I'm getting is

>
It seems like you are compiling against BerkeleyDB 4.7, is that version
really working? I think it is 4.5 and 4.6 that is supported.

/Henrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080627/8c5fec34/attachment.html>

From alex.mizrahi at gmail.com  Fri Jun 27 10:31:41 2008
From: alex.mizrahi at gmail.com (Alex Mizrahi)
Date: Fri, 27 Jun 2008 10:31:41 +0000 (UTC)
Subject: [elephant-devel] Re: Many patches pushed
References: <BE1F4982-6527-481F-9264-05611D6B3D9C@media.mit.edu>
Message-ID: <loom.20080627T100812-284@post.gmane.org>

> Please let me know if there are any obvious problems out there in the  
> field with postmodern or bdb.

does postmodern work for you if you run tests 2-3 times in a row? (and does bdb 
work in such case?)

iirc it was popping up errors about class redefinitions or something.
i'm not sure how it works at all, so i did not bother to debug. could be also a 
bug of SBCL which i was using.

also, iirc i have some postmodern patches pending, but unfortunately i cannot 
access them now :(. i'll get to it in a week or so maybe.

and, by the way, what's with "CL-SQL and Postmodern & dup-btree", you did not 
reply, so i don't know if i was confused or you were. should we have better 
pset implementation for 1.0beta release?

also, just to note, db-postmodern won't automatically upgrade 0.9.1 storage to 
1.0 format -- i just did not bother with it, as PostgreSQL style of upgrades is 
to use dump/restore into intermediate format, so recommended way of upgrading 
db-postmodern repositories is to use gp-export or similar util to make a dump 
of database, and restore it into a fresh one.

with best regards, Alex 'killer_storm' Mizrahi.



From alex.mizrahi at gmail.com  Fri Jun 27 10:38:19 2008
From: alex.mizrahi at gmail.com (Alex Mizrahi)
Date: Fri, 27 Jun 2008 10:38:19 +0000 (UTC)
Subject: [elephant-devel] Re: Duplicate values in PM-BTREE-INDEX
References: <63272.88.73.214.207.1214223387.squirrel@mail.stardawn.org><loom.20080626T131327-372@post.gmane.org>
	<1820284179-1214525621-cardhu_decombobulator_blackberry.rim.net-1828990326-@bxe123.bisx.prod.on.blackberry>
Message-ID: <loom.20080627T103533-503@post.gmane.org>

> We don't declare secondary indicies on dup-btrees, 
> in case that wasn't clear...

if we did, semantics would be pretty strange, i think..

but what's not clear (perhaps i was not attentive) is if dup-btree in bdb 
supports duplicated <key, value> pairs, or only duplicated keys with different 
values. if it supports duplicated pairs, it's worth documenting that db-
postmodern does not.



From eslick at media.mit.edu  Fri Jun 27 11:08:36 2008
From: eslick at media.mit.edu (=?utf-8?B?SWFuIEVzbGljaw==?=)
Date: Fri, 27 Jun 2008 11:08:36 +0000
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
Message-ID: <250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>

The right command is

(open-store '(:BDB "dirname"))

Sent from my BlackBerry

-----Original Message-----
From: Patrick May <pjm at spe.com>

Date: Thu, 26 Jun 2008 22:16:00 
To:Elephant bugs and development <elephant-devel at common-lisp.net>
Subject: Re: [elephant-devel] Problem installing with latest Clozure


On 26 Jun 2008, at 09:01, Ian Eslick wrote:
> Those errors seem to indicate a pretty messed up installation.  Can  
> you pull a fresh version of Elephant from the elphant-unstable darcs  
> repository (http://www.common-lisp.net/project/elephant/darcs/elephant-unstable 
> ) and try again.  The build did once work on Clozure as recent as  
> 0.9 - but I'd rather put debugging time into unstable as we're  
> hoping to release a 1.0beta1 as soon as we can.
>
> Thank you,
> Ian

	I used darcs to grab elephant-unstable and got the following results:

Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
?  (asdf:operate 'asdf:load-op :elephant)
; loading system definition from elephant.asd into #<Package "ASDF0">
; registering #<SYSTEM ELEPHANT #x8600A06> as ELEPHANT
; loading system definition from /usr/local/asdf-install/site-systems/ 
cl-base64.asd into #<Package "ASDF0">
; registering #<SYSTEM CL-BASE64 #x8625DF6> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x863BD96> as CL-BASE64-TESTS
; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.dylib -lm
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/classes.lisp" :
;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
lexical variable INDEX
;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)): Unused  
lexical variable INITARGS
;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
lexical variable INITARGS
;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
lambda form: Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "classes" #x859304E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/controller.lisp" :
;   In (OPEN-CONTROLLER :AFTER (STORE-CONTROLLER)): Unused lexical  
variable ARGS
;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to GET- 
FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "controller" #x859232E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/schema-evolution.lisp" :
;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
free variable VALUE
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "schema-evolution" #x8591E9E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "schema-evolution" #x8591E9E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/collections.lisp" :
;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B8E> on #<CL-SOURCE-FILE "collections" #x8591536>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/query.lisp" :
;   In SORT-TUPLES: Unused lexical variable KEY-FN
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x85969DE> on #<CL-SOURCE-FILE "query" #x858BEDE>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
NIL
? (use-package :elephant)
T
? (open-store :bdb "/Users/Patrick/src/lisp/elephant-dbb/")
 > Error: Failed assertion: (CONSP ELEPHANT::SPEC)
 > While executing: CCL::%ASSERTION-FAILURE, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: test the assertion again.
 > Type :? for other options.
1 >

	Any ideas?

Thanks,

Patrick

_______________________________________________
elephant-devel site list
elephant-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel

From eslick at media.mit.edu  Fri Jun 27 11:09:27 2008
From: eslick at media.mit.edu (=?utf-8?B?SWFuIEVzbGljaw==?=)
Date: Fri, 27 Jun 2008 11:09:27 +0000
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com><F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
Message-ID: <457116780-1214565022-cardhu_decombobulator_blackberry.rim.net-1356591095-@bxe123.bisx.prod.on.blackberry>

We don't support BDB 4.7 yet (4.5 and 4.6 only)
Sent from my BlackBerry

-----Original Message-----
From: Chris Van Dusen <cavandusen at gmail.com>

Date: Thu, 26 Jun 2008 21:21:33 
To:Elephant bugs and development <elephant-devel at common-lisp.net>
Subject: Re: [elephant-devel] Problem installing with latest Clozure


I'm having a problem on PPC Mac with CCL, as well, although the error  
that I'm getting is:

Berkeley DB error #22: Invalid argument
    [Condition of type BDB-DB-ERROR]

In the Slime buffer, it shows:

; loading system definition from /Users/chrisvandusen/.asdf-install- 
dir/systems/ele-bdb.asd into #<Package "ASDF0">
; registering #<SYSTEM ELE-BDB #x89A1056> as ELE-BDB
Attempting to load libmemutil.dylib...
Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/ 
src/memutil/libmemutil.dylib
; $ gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/ 
include/ -bundle -fPIC -Wall -g -O2 -g /Users/chrisvandusen/.asdf- 
install-dir/site/elephant-unstable/src/db-bdb/libberkeley-db.c -o / 
Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/src/db- 
bdb/libberkeley-db.dylib -lm -ldb-4.7
Loading /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.dylib
Attempting to load libberkeley-db.dylib...
Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/ 
src/db-bdb/libberkeley-db.dylib
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0>  
#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD- 
FIELD #1# DB-BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
C45::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#  
DB-BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C45::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0>  
#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD- 
FIELD #1# DB-BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
C46::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#  
DB-BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl- 
thread(5).
;Compiler warnings for "/Users/chrisvandusen/.asdf-install-dir/site/ 
elephant-unstable/src/db-bdb/bdb-controller.lisp" :
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).

Let me know if there is any more information that I can provide.

Thanks,
Chris.
On Jun 26, 2008, at 3:57 PM, Patrick May wrote:

> On 26 Jun 2008, at 09:01, Ian Eslick wrote:
>> Those errors seem to indicate a pretty messed up installation.   
>> Can you pull a fresh version of Elephant from the elphant-unstable  
>> darcs repository (http://www.common-lisp.net/project/elephant/ 
>> darcs/elephant-unstable) and try again.  The build did once work  
>> on Clozure as recent as 0.9 - but I'd rather put debugging time  
>> into unstable as we're hoping to release a 1.0beta1 as soon as we  
>> can.
>>
>> Thank you,
>> Ian
>
> 	Will do, as soon as I have a chance.  Thanks,
>
> Regards,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel

_______________________________________________
elephant-devel site list
elephant-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel

From pjm at spe.com  Fri Jun 27 11:14:12 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 07:14:12 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <457116780-1214565022-cardhu_decombobulator_blackberry.rim.net-1356591095-@bxe123.bisx.prod.on.blackberry>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com><F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
	<457116780-1214565022-cardhu_decombobulator_blackberry.rim.net-1356591095-@bxe123.bisx.prod.on.blackberry>
Message-ID: <054BA863-56B7-4CB0-BB34-3720274360B0@spe.com>

On 27 Jun 2008, at 07:09, Ian Eslick wrote:
> We don't support BDB 4.7 yet (4.5 and 4.6 only)

	Thanks, I'll install 4.5.

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From pjm at spe.com  Fri Jun 27 13:00:40 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 09:00:40 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
Message-ID: <ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>

On 27 Jun 2008, at 07:08, Ian Eslick wrote:
> The right command is
>
> (open-store '(:BDB "dirname"))

	Thanks for the help.  I installed BDB 4.5 and used the above form.   
This is the result:

? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
; loading system definition from ele-bdb.asd into #<Package "ASDF0">
; registering #<SYSTEM ELE-BDB #x8721FBE> as ELE-BDB
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
Attempting to load libberkeley-db.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
libberkeley-db.dylib
 > Error: There is no package named "DB-BDB-C47" .
 > While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Retry finding package with name "DB-BDB-C47".
 > Type :? for other options.
1 >

	Is my install misconfigured or is this something to do with using the  
bleeding edge release?

Thanks,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From eslick at media.mit.edu  Fri Jun 27 13:24:26 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Fri, 27 Jun 2008 09:24:26 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
Message-ID: <FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>

Check your my-config.sexp

Ian

On Jun 27, 2008, at 9:00 AM, Patrick May wrote:

> On 27 Jun 2008, at 07:08, Ian Eslick wrote:
>> The right command is
>>
>> (open-store '(:BDB "dirname"))
>
> 	Thanks for the help.  I installed BDB 4.5 and used the above form.   
> This is the result:
>
> ? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
> ; loading system definition from ele-bdb.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELE-BDB #x8721FBE> as ELE-BDB
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
> libmemutil.dylib
> Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
> Attempting to load libberkeley-db.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
> libberkeley-db.dylib
> > Error: There is no package named "DB-BDB-C47" .
> > While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
> > Type :GO to continue, :POP to abort, :R for a list of available  
> restarts.
> > If continued: Retry finding package with name "DB-BDB-C47".
> > Type :? for other options.
> 1 >
>
> 	Is my install misconfigured or is this something to do with using  
> the bleeding edge release?
>
> Thanks,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From pjm at spe.com  Fri Jun 27 13:38:07 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 09:38:07 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com><06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu><6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
Message-ID: <8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>

	It's a copy of the OSX Defaults section of config.sexp with only  
the :berkeley-db-cachesize changed.

Thanks,

Patrick

On 27 Jun 2008, at 09:24, Ian Eslick wrote:

> Check your my-config.sexp
>
> Ian
>
> On Jun 27, 2008, at 9:00 AM, Patrick May wrote:
>
>> On 27 Jun 2008, at 07:08, Ian Eslick wrote:
>>> The right command is
>>>
>>> (open-store '(:BDB "dirname"))
>>
>> 	Thanks for the help.  I installed BDB 4.5 and used the above  
>> form.  This is the result:
>>
>> ? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
>> ; loading system definition from ele-bdb.asd into #<Package "ASDF0">
>> ; registering #<SYSTEM ELE-BDB #x8721FBE> as ELE-BDB
>> Attempting to load libmemutil.dylib...
>> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
>> libmemutil.dylib
>> Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
>> Attempting to load libberkeley-db.dylib...
>> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
>> libberkeley-db.dylib
>> > Error: There is no package named "DB-BDB-C47" .
>> > While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
>> > Type :GO to continue, :POP to abort, :R for a list of available  
>> restarts.
>> > If continued: Retry finding package with name "DB-BDB-C47".
>> > Type :? for other options.
>> 1 >
>>
>> 	Is my install misconfigured or is this something to do with using  
>> the bleeding edge release?
>>
>> Thanks,
>>
>> Patrick
>>
>> ----
>> pjm at spe.com
>> S P Engineering, Inc.
>> Large scale, mission-critical, distributed OO systems design and  
>> implementation.
>> (C++, Java, Common Lisp, Jini, middleware, SOA)
>>
>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From henrik at evahjelte.com  Fri Jun 27 14:20:57 2008
From: henrik at evahjelte.com (Henrik Hjelte)
Date: Fri, 27 Jun 2008 16:20:57 +0200
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
Message-ID: <50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>

>>no package named "DB-BDB-C47"

The C47 here looks to me like there is something remaining from your old
attempt with 4.7
Delete all fasls, and isn't libberkeley-db.dylib created when you compile
for the first time?
Try removing it, or just download a fresh copy of elephant.

/Henrik


On Fri, Jun 27, 2008 at 3:38 PM, Patrick May <pjm at spe.com> wrote:

>        It's a copy of the OSX Defaults section of config.sexp with only the
> :berkeley-db-cachesize changed.
>
> Thanks,
>
> Patrick
>
>
> On 27 Jun 2008, at 09:24, Ian Eslick wrote:
>
>  Check your my-config.sexp
>>
>> Ian
>>
>> On Jun 27, 2008, at 9:00 AM, Patrick May wrote:
>>
>>  On 27 Jun 2008, at 07:08, Ian Eslick wrote:
>>>
>>>> The right command is
>>>>
>>>> (open-store '(:BDB "dirname"))
>>>>
>>>
>>>        Thanks for the help.  I installed BDB 4.5 and used the above form.
>>>  This is the result:
>>>
>>> ? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
>>> ; loading system definition from ele-bdb.asd into #<Package "ASDF0">
>>> ; registering #<SYSTEM ELE-BDB #x8721FBE> as ELE-BDB
>>> Attempting to load libmemutil.dylib...
>>> Loaded
>>> /Users/Patrick/src/lisp/elephant-unstable/src/memutil/libmemutil.dylib
>>> Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
>>> Attempting to load libberkeley-db.dylib...
>>> Loaded
>>> /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/libberkeley-db.dylib
>>> > Error: There is no package named "DB-BDB-C47" .
>>> > While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
>>> > Type :GO to continue, :POP to abort, :R for a list of available
>>> restarts.
>>> > If continued: Retry finding package with name "DB-BDB-C47".
>>> > Type :? for other options.
>>> 1 >
>>>
>>>        Is my install misconfigured or is this something to do with using
>>> the bleeding edge release?
>>>
>>> Thanks,
>>>
>>> Patrick
>>>
>>> ----
>>> pjm at spe.com
>>> S P Engineering, Inc.
>>> Large scale, mission-critical, distributed OO systems design and
>>> implementation.
>>> (C++, Java, Common Lisp, Jini, middleware, SOA)
>>>
>>>
>>>
>>> _______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>


-- 
Henrik Hjelte
henrik.hjelte at stix.to
+46703993945
http://stix.to
L?stmakarg 18-20 (IQube)
Box 7438
S-103 91 Stockholm
Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080627/92dc5388/attachment.html>

From pjm at spe.com  Fri Jun 27 14:28:17 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 10:28:17 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
Message-ID: <DAACA043-A165-4A4C-9BF1-2E94C3071EDD@spe.com>

On 27 Jun 2008, at 10:20, Henrik Hjelte wrote:
> >>no package named "DB-BDB-C47"
>
> The C47 here looks to me like there is something remaining from your  
> old attempt with 4.7
> Delete all fasls, and isn't libberkeley-db.dylib created when you  
> compile for the first time?
> Try removing it, or just download a fresh copy of elephant.


	Removing the .dfsl files got me further.  I'm going to start from a  
clean install tonight.  Thanks for the assistance.

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080627/e99f32cf/attachment.html>

From pjm at spe.com  Fri Jun 27 15:41:45 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 11:41:45 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
Message-ID: <38A1845C-23C9-473C-9340-D4EAB545AB27@spe.com>

On 27 Jun 2008, at 10:20, Henrik Hjelte wrote:
> >>no package named "DB-BDB-C47"
>
> The C47 here looks to me like there is something remaining from your  
> old attempt with 4.7
> Delete all fasls, and isn't libberkeley-db.dylib created when you  
> compile for the first time?
> Try removing it, or just download a fresh copy of elephant.


	With a fresh download of elephant-unstable I get this error when  
running (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb")):

; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x870BE8E> on #<CL-SOURCE-FILE "bdb-controller" #x870D0B6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
 > Error: Undefined function #:G2120 called with arguments (#<A  
Foreign Pointer #x805A00> #<A Null Foreign Pointer> #<A Foreign  
Pointer #x108420> 2 #<A Foreign Pointer #x108400> 10 0 #<A Foreign  
Pointer [stack-allocated] #x565900>) .
 > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Retry applying #:G2120 to (#<A Foreign Pointer  
#x805A00> #<A Null Foreign Pointer> #<A Foreign Pointer #x108420> 2  
#<A Foreign Pointer #x108400> 10 0 #<A Foreign Pointer [stack- 
allocated] #x565900>).
 > Type :? for other options.
1 >

	I'll try with the stable release tonight.

Thanks,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080627/265d5b60/attachment.html>

From pjm at spe.com  Fri Jun 27 19:31:21 2008
From: pjm at spe.com (Patrick May)
Date: Fri, 27 Jun 2008 15:31:21 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
Message-ID: <153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>

On 27 Jun 2008, at 10:20, Henrik Hjelte wrote:
> >>no package named "DB-BDB-C47"
>
> The C47 here looks to me like there is something remaining from your  
> old attempt with 4.7
> Delete all fasls, and isn't libberkeley-db.dylib created when you  
> compile for the first time?
> Try removing it, or just download a fresh copy of elephant.

	I tried both the 0.9.1 and unstable releases.  My my-config.sexp uses  
the OSX defaults from config.sexp.  This is the output I get:

Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
? (asdf:operate 'asdf:load-op :elephant)
; loading system definition from elephant.asd into #<Package "ASDF0">
; registering #<SYSTEM ELEPHANT #x861D6FE> as ELEPHANT
; loading system definition from /usr/local/asdf-install/site-systems/ 
cl-base64.asd into #<Package "ASDF0">
; registering #<SYSTEM CL-BASE64 #x8622AF6> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x8638A0E> as CL-BASE64-TESTS
; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.dylib -lm
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/classes.lisp" :
;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
lexical variable INDEX
;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)): Unused  
lexical variable INITARGS
;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
lexical variable INITARGS
;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
lambda form: Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8596F26> on #<CL-SOURCE-FILE "classes" #x859179E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/controller.lisp" :
;   In (OPEN-CONTROLLER :AFTER (STORE-CONTROLLER)): Unused lexical  
variable ARGS
;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to GET- 
FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
which are recognized
;     by the definition of GET-FROM-ROOT visible in the current  
compilation unit.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8596F26> on #<CL-SOURCE-FILE "controller" #x8590A7E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/schema-evolution.lisp" :
;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
free variable VALUE
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8596F26> on #<CL-SOURCE-FILE "schema-evolution" #x85905EE>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x8596F26> on #<CL-SOURCE-FILE "schema-evolution" #x85905EE>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/collections.lisp" :
;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8596F26> on #<CL-SOURCE-FILE "collections" #x858FC86>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/query.lisp" :
;   In SORT-TUPLES: Unused lexical variable KEY-FN
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8594DA6> on #<CL-SOURCE-FILE "query" #x8595C5E>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
NIL
? (use-package :elephant)
T
? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
; loading system definition from ele-bdb.asd into #<Package "ASDF0">
; registering #<SYSTEM ELE-BDB #x877C356> as ELE-BDB
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
; $ gcc -L/usr/local/BerkeleyDB.4.5/lib/ -I/usr/local/BerkeleyDB.4.5/ 
include/ -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
elephant-unstable/src/db-bdb/libberkeley-db.c -o /Users/Patrick/src/ 
lisp/elephant-unstable/src/db-bdb/libberkeley-db.dylib -lm -ldb-4.5
Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
Attempting to load libberkeley-db.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
libberkeley-db.dylib
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD-FIELD #1# DB- 
BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-C45::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x875E93E> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x875E8EE> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2# DB- 
BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C45::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD-FIELD #1# DB- 
BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-C46::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x875E93E> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x875E8EE> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2# DB- 
BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
db-bdb/bdb-controller.lisp" :
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform  
QUOTE in ECASE statement.
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x870CBAE> on #<CL-SOURCE-FILE "bdb-controller" #x870DDD6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x870CBAE> on #<CL-SOURCE-FILE "bdb-controller" #x870DDD6>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
 > Error: Undefined function #:G2120 called with arguments (#<A  
Foreign Pointer #x805800> #<A Null Foreign Pointer> #<A Foreign  
Pointer #x107A60> 2 #<A Foreign Pointer #x107A70> 10 0 #<A Foreign  
Pointer [stack-allocated] #x565900>) .
 > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Retry applying #:G2120 to (#<A Foreign Pointer  
#x805800> #<A Null Foreign Pointer> #<A Foreign Pointer #x107A60> 2  
#<A Foreign Pointer #x107A70> 10 0 #<A Foreign Pointer [stack- 
allocated] #x565900>).
 > Type :? for other options.
1 >

	Any thoughts?

Thanks,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080627/d86c5223/attachment.html>

From cavandusen at gmail.com  Sat Jun 28 22:58:23 2008
From: cavandusen at gmail.com (Chris Van Dusen)
Date: Sat, 28 Jun 2008 17:58:23 -0500
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <457116780-1214565022-cardhu_decombobulator_blackberry.rim.net-1356591095-@bxe123.bisx.prod.on.blackberry>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<7A9AA753-5174-4A6E-8BD5-130D8EE792FE@spe.com>
	<F4391A77-A567-4D70-B4F9-DC76DED1DEFC@gmail.com>
	<457116780-1214565022-cardhu_decombobulator_blackberry.rim.net-1356591095-@bxe123.bisx.prod.on.blackberry>
Message-ID: <ceededb70806281558i57c6ba2dwfd507cd248371aba@mail.gmail.com>

ok.

Pointing my-config to 4.6, clearing out the dfsl's and libberkely-db.dylib
as mentioned in this thread got me going.

Now, time to play.

Thanks,
Chris.

2008/6/27 Ian Eslick <eslick at media.mit.edu>:

> We don't support BDB 4.7 yet (4.5 and 4.6 only)
> Sent from my BlackBerry
>
> -----Original Message-----
> From: Chris Van Dusen <cavandusen at gmail.com>
>
> Date: Thu, 26 Jun 2008 21:21:33
> To:Elephant bugs and development <elephant-devel at common-lisp.net>
> Subject: Re: [elephant-devel] Problem installing with latest Clozure
>
>
> I'm having a problem on PPC Mac with CCL, as well, although the error
> that I'm getting is:
>
> Berkeley DB error #22: Invalid argument
>    [Condition of type BDB-DB-ERROR]
>
> In the Slime buffer, it shows:
>
> ; loading system definition from /Users/chrisvandusen/.asdf-install-
> dir/systems/ele-bdb.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELE-BDB #x89A1056> as ELE-BDB
> Attempting to load libmemutil.dylib...
> Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/
> src/memutil/libmemutil.dylib
> ; $ gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/
> include/ -bundle -fPIC -Wall -g -O2 -g /Users/chrisvandusen/.asdf-
> install-dir/site/elephant-unstable/src/db-bdb/libberkeley-db.c -o /
> Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/src/db-
> bdb/libberkeley-db.dylib -lm -ldb-4.7
> Loading /usr/local/BerkeleyDB.4.7/lib/libdb-4.7.dylib
> Attempting to load libberkeley-db.dylib...
> Loaded /Users/chrisvandusen/.asdf-install-dir/site/elephant-unstable/
> src/db-bdb/libberkeley-db.dylib
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE
> (:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0>
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD-
> FIELD #1# DB-BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-
> C45::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl-
> thread(5).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED
> 32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>
> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)
> #x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY-
> TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD
> #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF
> (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)
> (MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0> #<FOREIGN-
> RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#
> DB-BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C45::OBJ
> 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl-
> thread(5).
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE
> (:UNSIGNED 32) #x8346F76> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x8347136> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0>
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD-
> FIELD #1# DB-BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-
> C46::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl-
> thread(5).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED
> 32) #x8347136> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>
> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)
> #x8346F76> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY-
> TYPE (ARRAY (:SIGNED 8)) #x894DCE6> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD
> #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF
> (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)
> (MODE (:SIGNED 32) 32))) #x894DCA6> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN-
> RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2#
> DB-BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ
> 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process repl-
> thread(5).
> ;Compiler warnings for "/Users/chrisvandusen/.asdf-install-dir/site/
> elephant-unstable/src/db-bdb/bdb-controller.lisp" :
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform
> QUOTE in ECASE statement.
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform
> QUOTE in ECASE statement.
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate keyform
> QUOTE in ECASE statement.
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL
> #x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
> ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).
> ; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL
> #x890209E> on #<CL-SOURCE-FILE "bdb-controller" #x89032C6>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
> ASDF:CL-SOURCE-FILE)>, in process repl-thread(5).
>
> Let me know if there is any more information that I can provide.
>
> Thanks,
> Chris.
> On Jun 26, 2008, at 3:57 PM, Patrick May wrote:
>
> > On 26 Jun 2008, at 09:01, Ian Eslick wrote:
> >> Those errors seem to indicate a pretty messed up installation.
> >> Can you pull a fresh version of Elephant from the elphant-unstable
> >> darcs repository (http://www.common-lisp.net/project/elephant/
> >> darcs/elephant-unstable) and try again.  The build did once work
> >> on Clozure as recent as 0.9 - but I'd rather put debugging time
> >> into unstable as we're hoping to release a 1.0beta1 as soon as we
> >> can.
> >>
> >> Thank you,
> >> Ian
> >
> >       Will do, as soon as I have a chance.  Thanks,
> >
> > Regards,
> >
> > Patrick
> >
> > ----
> > pjm at spe.com
> > S P Engineering, Inc.
> > Large scale, mission-critical, distributed OO systems design and
> > implementation.
> > (C++, Java, Common Lisp, Jini, middleware, SOA)
> >
> >
> >
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> 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: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080628/cd056118/attachment.html>

From eslick at media.mit.edu  Sun Jun 29 01:23:50 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sat, 28 Jun 2008 21:23:50 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
Message-ID: <E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>

Patrick,

Can you send the contents of your my-config.sexp?  Also, what version  
of uffi are you using?

The big hint here is that the BDB constants your are loading are  
coming from the C46 constants package and not the C45 package that you  
should be loading to match the BDB 4.5 that you're compiling.  I'm not  
sure why this is the case; but can you confirm that :berkeley-db- 
version in your my-config.sexp is "4.5".

Ian

PS - In looking at your compiler output I've corrected and pushed a  
patch for a couple of odd typos that probably don't effect this.

On Jun 27, 2008, at 3:31 PM, Patrick May wrote:

> On 27 Jun 2008, at 10:20, Henrik Hjelte wrote:
>> >>no package named "DB-BDB-C47"
>>
>> The C47 here looks to me like there is something remaining from  
>> your old attempt with 4.7
>> Delete all fasls, and isn't libberkeley-db.dylib created when you  
>> compile for the first time?
>> Try removing it, or just download a fresh copy of elephant.
>
> 	I tried both the 0.9.1 and unstable releases.  My my-config.sexp  
> uses the OSX defaults from config.sexp.  This is the output I get:
>
> Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
> ? (asdf:operate 'asdf:load-op :elephant)
> ; loading system definition from elephant.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELEPHANT #x861D6FE> as ELEPHANT
> ; loading system definition from /usr/local/asdf-install/site- 
> systems/cl-base64.asd into #<Package "ASDF0">
> ; registering #<SYSTEM CL-BASE64 #x8622AF6> as CL-BASE64
> ; registering #<SYSTEM CL-BASE64-TESTS #x8638A0E> as CL-BASE64-TESTS
> ; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
> elephant-unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/ 
> lisp/elephant-unstable/src/memutil/libmemutil.dylib -lm
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
> libmemutil.dylib
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/classes.lisp" :
> ;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
> lexical variable INDEX
> ;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)):  
> Unused lexical variable INITARGS
> ;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
> lexical variable INITARGS
> ;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
> lambda form: Unused lexical variable ARGS
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8596F26> on #<CL-SOURCE-FILE "classes" #x859179E>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/controller.lisp" :
> ;   In (OPEN-CONTROLLER :AFTER (STORE-CONTROLLER)): Unused lexical  
> variable ARGS
> ;   In (CONTROLLER-PROPERTIES (STORE-CONTROLLER)): In the call to  
> GET-FROM-ROOT with arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE- 
> CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ;   In (SET-ELE-PROPERTY (T T)): In the call to GET-FROM-ROOT with  
> arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ;   In (GET-ELE-PROPERTY (T)): In the call to GET-FROM-ROOT with  
> arguments (*ELEPHANT-PROPERTIES-LABEL* :STORE-CONTROLLER SC),
> ;     the keyword argument :STORE-CONTROLLER is not one of (:SC),  
> which are recognized
> ;     by the definition of GET-FROM-ROOT visible in the current  
> compilation unit.
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8596F26> on #<CL-SOURCE-FILE "controller" #x8590A7E>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/schema-evolution.lisp" :
> ;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
> free variable VALUE
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8596F26> on #<CL-SOURCE-FILE "schema-evolution" #x85905EE>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
> #x8596F26> on #<CL-SOURCE-FILE "schema-evolution" #x85905EE>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/collections.lisp" :
> ;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
> ;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8596F26> on #<CL-SOURCE-FILE "collections" #x858FC86>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/query.lisp" :
> ;   In SORT-TUPLES: Unused lexical variable KEY-FN
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8594DA6> on #<CL-SOURCE-FILE "query" #x8595C5E>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> NIL
> ? (use-package :elephant)
> T
> ? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
> ; loading system definition from ele-bdb.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELE-BDB #x877C356> as ELE-BDB
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
> libmemutil.dylib
> ; $ gcc -L/usr/local/BerkeleyDB.4.5/lib/ -I/usr/local/BerkeleyDB.4.5/ 
> include/ -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
> elephant-unstable/src/db-bdb/libberkeley-db.c -o /Users/Patrick/src/ 
> lisp/elephant-unstable/src/db-bdb/libberkeley-db.dylib -lm -ldb-4.5
> Loading /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib
> Attempting to load libberkeley-db.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
> libberkeley-db.dylib
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD- 
> FIELD #1# DB-BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
> C45::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:SIGNED 32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE  
> 32 at 32> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED  
> 32) #x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN- 
> ARRAY-TYPE (ARRAY (:SIGNED 8)) #x875E93E> OBJ 8 at 96> #<FOREIGN-RECORD- 
> FIELD #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK  
> (OFF (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32)  
> 32) (MODE (:SIGNED 32) 32))) #x875E8EE> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD- 
> FIELD #2# DB-BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB- 
> BDB-C45::OBJ 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK  
> 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD- 
> FIELD #1# DB-BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
> C46::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:SIGNED 32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE  
> 32 at 32> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED  
> 32) #x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN- 
> ARRAY-TYPE (ARRAY (:SIGNED 8)) #x875E93E> OBJ 8 at 96> #<FOREIGN-RECORD- 
> FIELD #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK  
> (OFF (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32)  
> 32) (MODE (:SIGNED 32) 32))) #x875E8EE> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD- 
> FIELD #2# DB-BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB- 
> BDB-C46::OBJ 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK  
> 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/db-bdb/bdb-controller.lisp" :
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate  
> keyform QUOTE in ECASE statement.
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate  
> keyform QUOTE in ECASE statement.
> ;   In (DEFAULT-CLASS-ID (T BDB-STORE-CONTROLLER)): Duplicate  
> keyform QUOTE in ECASE statement.
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x870CBAE> on #<CL-SOURCE-FILE "bdb-controller" #x870DDD6>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
> #x870CBAE> on #<CL-SOURCE-FILE "bdb-controller" #x870DDD6>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> > Error: Undefined function #:G2120 called with arguments (#<A  
> Foreign Pointer #x805800> #<A Null Foreign Pointer> #<A Foreign  
> Pointer #x107A60> 2 #<A Foreign Pointer #x107A70> 10 0 #<A Foreign  
> Pointer [stack-allocated] #x565900>) .
> > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
> BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
> > Type :GO to continue, :POP to abort, :R for a list of available  
> restarts.
> > If continued: Retry applying #:G2120 to (#<A Foreign Pointer  
> #x805800> #<A Null Foreign Pointer> #<A Foreign Pointer #x107A60> 2  
> #<A Foreign Pointer #x107A70> 10 0 #<A Foreign Pointer [stack- 
> allocated] #x565900>).
> > Type :? for other options.
> 1 >
>
> 	Any thoughts?
>
> Thanks,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Sun Jun 29 01:31:32 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sat, 28 Jun 2008 21:31:32 -0400
Subject: [elephant-devel] Caching and 1.0
Message-ID: <9A332B47-C710-4FF3-A45B-E07061A922F0@media.mit.edu>

FYI - After due consideration I've decided to exclude object caching  
as a supported feature in the upcoming Elephant 1.0 beta 1 release.   
The good ideas I come up with for resolving some of the issues brought  
up earlier, particularly by Alex, involve enough delicate work in the  
slot access protocol and transaction macros that I won't have time to  
focus on verifying and debugging more essential features.  Caching can  
be a cool feature in the roadmap that I may do sooner rather than  
later to satisfy my own needs...

Ian


From pjm at spe.com  Sun Jun 29 13:44:42 2008
From: pjm at spe.com (Patrick May)
Date: Sun, 29 Jun 2008 09:44:42 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
Message-ID: <6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>

On 28 Jun 2008, at 21:23, Ian Eslick wrote:
> Patrick,
>
> Can you send the contents of your my-config.sexp?  Also, what  
> version of uffi are you using?
>
> The big hint here is that the BDB constants your are loading are  
> coming from the C46 constants package and not the C45 package that  
> you should be loading to match the BDB 4.5 that you're compiling.   
> I'm not sure why this is the case; but can you confirm  
> that :berkeley-db-version in your my-config.sexp is "4.5".
>
> Ian
>
> PS - In looking at your compiler output I've corrected and pushed a  
> patch for a couple of odd typos that probably don't effect this.


Ian,

	Thanks for the help.  My my-config.sexp in elephant-unstable is:

#+(and (or sbcl allegro openmcl lispworks) (not (or mswindows  
windows)) (or macosx darwin))
((:compiler . :gcc)
  (:berkeley-db-version . "4.5")
  (:berkeley-db-include-dir . "/usr/local/BerkeleyDB.4.5/include/")
  (:berkeley-db-lib-dir . "/usr/local/BerkeleyDB.4.5/lib/")
  (:berkeley-db-lib . "/usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib")
  (:berkeley-db-deadlock . "/usr/local/BerkeleyDB.4.5/bin/db_deadlock")
  (:berkeley-db-cachesize . 5242880)
  (:berkeley-db-max-locks . 2000)
  (:berkeley-db-max-objects . 2000)
  (:berkeley-db-map-degree2 . t)
  (:clsql-lib-paths . nil)
  (:prebuilt-libraries . nil))

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From eslick at media.mit.edu  Sun Jun 29 14:17:33 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 29 Jun 2008 10:17:33 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
Message-ID: <2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>

Chris got unstable to work on ccl, so my best guess is that there are  
stale fasls.  Try :force t on asdf:load-op or ensuring that all fasls  
are deleted in the src/db-bdb directory.

The error your forwarded refers to constants in DB-BDB-C46 when they  
should be referring to DB-BDB-C45.  If you get the wrong constants,  
then the BDB library is going to complain loudly...

          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x875E93E> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x875E8EE> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2# DB- 
BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).


On Jun 29, 2008, at 9:44 AM, Patrick May wrote:

> On 28 Jun 2008, at 21:23, Ian Eslick wrote:
>> Patrick,
>>
>> Can you send the contents of your my-config.sexp?  Also, what  
>> version of uffi are you using?
>>
>> The big hint here is that the BDB constants your are loading are  
>> coming from the C46 constants package and not the C45 package that  
>> you should be loading to match the BDB 4.5 that you're compiling.   
>> I'm not sure why this is the case; but can you confirm  
>> that :berkeley-db-version in your my-config.sexp is "4.5".
>>
>> Ian
>>
>> PS - In looking at your compiler output I've corrected and pushed a  
>> patch for a couple of odd typos that probably don't effect this.
>
>
> Ian,
>
> 	Thanks for the help.  My my-config.sexp in elephant-unstable is:
>
> #+(and (or sbcl allegro openmcl lispworks) (not (or mswindows  
> windows)) (or macosx darwin))
> ((:compiler . :gcc)
> (:berkeley-db-version . "4.5")
> (:berkeley-db-include-dir . "/usr/local/BerkeleyDB.4.5/include/")
> (:berkeley-db-lib-dir . "/usr/local/BerkeleyDB.4.5/lib/")
> (:berkeley-db-lib . "/usr/local/BerkeleyDB.4.5/lib/libdb-4.5.dylib")
> (:berkeley-db-deadlock . "/usr/local/BerkeleyDB.4.5/bin/db_deadlock")
> (:berkeley-db-cachesize . 5242880)
> (:berkeley-db-max-locks . 2000)
> (:berkeley-db-max-objects . 2000)
> (:berkeley-db-map-degree2 . t)
> (:clsql-lib-paths . nil)
> (:prebuilt-libraries . nil))
>
> Regards,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From gtarcea at umich.edu  Sun Jun 29 14:22:09 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Sun, 29 Jun 2008 10:22:09 -0400
Subject: [elephant-devel] Documentation Updates
In-Reply-To: <5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
References: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
	<5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
Message-ID: <D07A1529-D292-4822-8488-99A15133CCDC@umich.edu>

Ian,

The set-valued-slots are very nice. I've been playing around with  
them to write the documentation and have found they will cleanup some  
code I had written using make-pset. One question: Should the write up  
on PSETs remain in the documentation, or should there be a write up  
to migrate people over to using the slot-valued-sets instead?

Thanks,

Glenn

On Jun 20, 2008, at 2:42 PM, Ian Eslick wrote:

> Great stuff!
>
> To answer a couple of questions:
> - Cached slots aren't ready yet; I'll document when I can work out  
> the kinks:
> - Indexed slots are the same as the existing indexed-slots  
> descriptions, except for
>   the :inherit slot option so you should be able to copy & paste  
> existing content
>   for these slots and for derived index slots
> - Derived index slots are still pertinent and will remain
>
> -----------------------
> Set-valued Slots
>
> src/elephant/set-valued-slots.lisp
>
> Set-valued slots are a convenient shorthand to using PSETs as slot  
> values to get persistent collections as slot values.
>
> (slot-value object 'set-slot)
> returns a SLOT-SET which implements the PSET interface as well as:
> 	map-slot-set - maps over the elements of the set
> 	drop-slot-set - drops the set from the DB
> 	slot-set-list - returns a list of the elements in the set
>
> (setf (slot-value object 'slotname) foo)
> adds foo to the SLOT-SET in slot named 'slotname
> however, if foo is a slot-set object, it drops and replaces the  
> existing slot-set
>
> (slot-makunbound object 'slotname)
> Make the slot unbound and drops the SLOT-SET from the DB.
>
> Of course these work for accessors too (setf (accessor object) foo)  
> => adds foo to slot set
>
> There are a couple of helper macros to simplify expressions like:
> 	(slot-set-list (slot-value object 'set-slot))
>
> (set-list object 'slotname)
> (set-insert foo object 'slotname)
> (set-remove foo object 'slotname)
>
> I'm happy to rename these operators if anyone has opinions on  
> better names...
>
> Regards,
> Ian
>
>
> On Jun 20, 2008, at 11:17 AM, Glenn Tarcea wrote:
>
>> Attached are updates to the documentation. Specifically I updated:
>>
>> 1. Section: Setting Up Berkeley DB - to include the additional  
>> flags (:berkeley-db-max-locks and :berkeley-db-max-objects) along  
>> with their descriptions and updated the list of of parameters in  
>> the my-config.sexp
>>
>> 2. Added a new section under Installation titled "Using Multiple  
>> Versions Of Elephant" that describes how to use ASDF to allow  
>> multiple versions of Elephant to be installed on a single system
>>
>> 3. Made a change to one of the Scenarios where the class was  
>> system-object, but the methods were referring to system-state  
>> (Section: Persistent System Objects)
>>
>> 4. Put placeholders in for the different slot types, titled:
>>     Using Cached Slots
>>     Using Indexed Slots
>>     Using Derived Indexed Slots
>>     Using Set Valued Slots
>>
>> 5. Added a write up based on Ian's email on Association Slots  
>> titled "Using Association Slots"
>>
>> 6.  Updated the Section (4) titled "Berkeley DB Data Store":
>>    a. to include references to the new my-config.sexp parameters
>>    b. Updated the open-store parameters to include :max- 
>> locks :cachesize and :max-objects
>>    c. Updated performance tuning to quickly describe what berkeley- 
>> db-max-locks, and objects do
>>    d. Show an example call to open-store using :max-locks and :max- 
>> objects
>>    e. Updated performance tuning to include a reference to the  
>> Berkeley-DB parameters that max-locks and max-objects refer to and  
>> to point the user at DB_CONFIG for additional information.
>>
>> Can someone send me a quick example or jot down a few notes on  
>> using Cached and Set Valued slots?
>>
>> Are Derived Indexed Slots still pertinent (I recall a lot of  
>> discussion regarding them but don't recall what the outcome was).
>>
>> More documentation updates later.
>>
>> Thanks,
>>
>> Glenn
>>
>> <doc-patch-1.patch>_______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>



From pjm at spe.com  Sun Jun 29 14:48:19 2008
From: pjm at spe.com (Patrick May)
Date: Sun, 29 Jun 2008 10:48:19 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
	<2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
Message-ID: <076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>

On 29 Jun 2008, at 10:17, Ian Eslick wrote:
> Chris got unstable to work on ccl, so my best guess is that there  
> are stale fasls.  Try :force t on asdf:load-op or ensuring that all  
> fasls are deleted in the src/db-bdb directory.
>
> The error your forwarded refers to constants in DB-BDB-C46 when they  
> should be referring to DB-BDB-C45.  If you get the wrong constants,  
> then the BDB library is going to complain loudly...


	I had removed 0.9.1 and unstable and retrieved them again via darcs  
before running that test.  As a second test, I cleaned and re- 
retrieved them again, installed BDB 4.6, changed my-config.sexp  
appropriately, and got this error:

; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
 > Error: Undefined function #:G2122 called with arguments (#<A  
Foreign Pointer #x805A00> #<A Null Foreign Pointer> #<A Foreign  
Pointer #x1084A0> 2 #<A Foreign Pointer #x107340> 10 0 #<A Foreign  
Pointer [stack-allocated] #x565900>) .
 > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Retry applying #:G2122 to (#<A Foreign Pointer  
#x805A00> #<A Null Foreign Pointer> #<A Foreign Pointer #x1084A0> 2  
#<A Foreign Pointer #x107340> 10 0 #<A Foreign Pointer [stack- 
allocated] #x565900>).
 > Type :? for other options.
1 >

	I've put the full output below my sig.

Thanks,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)


Dagny:Patrick:~/src/lisp/elephant-unstable> ccl
; loading system definition from /usr/local/ccl/tools/asdf-install/ 
asdf-install.asd into #<Package "ASDF0">
; registering #<SYSTEM ASDF-INSTALL #x84EC1A6> as ASDF-INSTALL
;;; ASDF-Install version 0.6.10
; loading system definition from /Users/Patrick/src/lisp/clsql-4.0.3/ 
clsql.asd into #<Package "ASDF0">
; loading system definition from /usr/local/asdf-install/site-systems/ 
uffi.asd into #<Package "ASDF1">
; registering #<SYSTEM UFFI #x85376DE> as UFFI
; registering #<SYSTEM CLSQL #x85099AE> as CLSQL
Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
? (asdf:operate 'asdf:load-op :elephant)
; loading system definition from elephant.asd into #<Package "ASDF0">
; registering #<SYSTEM ELEPHANT #x860095E> as ELEPHANT
; loading system definition from /usr/local/asdf-install/site-systems/ 
cl-base64.asd into #<Package "ASDF0">
; registering #<SYSTEM CL-BASE64 #x8625CEE> as CL-BASE64
; registering #<SYSTEM CL-BASE64-TESTS #x863BC8E> as CL-BASE64-TESTS
; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/lisp/elephant- 
unstable/src/memutil/libmemutil.dylib -lm
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/classes.lisp" :
;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
lexical variable INDEX
;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)): Unused  
lexical variable INITARGS
;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
lexical variable INITARGS
;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
lambda form: Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B56> on #<CL-SOURCE-FILE "classes" #x8593016>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/schema-evolution.lisp" :
;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
free variable VALUE
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B56> on #<CL-SOURCE-FILE "schema-evolution" #x8591E66>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
#x8598B56> on #<CL-SOURCE-FILE "schema-evolution" #x8591E66>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/collections.lisp" :
;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8598B56> on #<CL-SOURCE-FILE "collections" #x85914FE>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/src/ 
elephant/query.lisp" :
;   In SORT-TUPLES: Unused lexical variable KEY-FN
; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
#x8596A46> on #<CL-SOURCE-FILE "query" #x858BF46>.
; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
ASDF:CL-SOURCE-FILE)>, in process listener(1).
NIL
? (use-package :elephant)
T
? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
; loading system definition from ele-bdb.asd into #<Package "ASDF0">
; registering #<SYSTEM ELE-BDB #x8771A66> as ELE-BDB
Attempting to load libmemutil.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
libmemutil.dylib
; $ gcc -L/usr/local/BerkeleyDB.4.6/lib/ -I/usr/local/BerkeleyDB.4.6/ 
include/ -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
elephant-unstable/src/db-bdb/libberkeley-db.c -o /Users/Patrick/src/ 
lisp/elephant-unstable/src/db-bdb/libberkeley-db.dylib -lm -ldb-4.6
Loading /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.dylib
Attempting to load libberkeley-db.dylib...
Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
libberkeley-db.dylib
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD-FIELD #1# DB- 
BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-C45::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x876531E> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x87652CE> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2# DB- 
BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C45::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCK fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
(:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
#2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD-FIELD #1# DB- 
BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB-C46::MODE 32 at 96>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE (:SIGNED  
32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE 32 at 32>  
#<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED 32)  
#x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN-ARRAY- 
TYPE (ARRAY (:SIGNED 8)) #x876531E> OBJ 8 at 96> #<FOREIGN-RECORD-FIELD  
#4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK (OFF  
(:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32) 32)  
(MODE (:SIGNED 32) 32))) #x87652CE> LOCK 32 at 128>)
;          were
;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0> #<FOREIGN- 
RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD-FIELD #2# DB- 
BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB-BDB-C46::OBJ  
8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK 32 at 128>)
; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
listener(1).
 > Error: Undefined function #:G2122 called with arguments (#<A  
Foreign Pointer #x805A00> #<A Null Foreign Pointer> #<A Foreign  
Pointer #x1084A0> 2 #<A Foreign Pointer #x107340> 10 0 #<A Foreign  
Pointer [stack-allocated] #x565900>) .
 > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available  
restarts.
 > If continued: Retry applying #:G2122 to (#<A Foreign Pointer  
#x805A00> #<A Null Foreign Pointer> #<A Foreign Pointer #x1084A0> 2  
#<A Foreign Pointer #x107340> 10 0 #<A Foreign Pointer [stack- 
allocated] #x565900>).
 > Type :? for other options.
1 >




From eslick at media.mit.edu  Sun Jun 29 15:54:06 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 29 Jun 2008 11:54:06 -0400
Subject: [elephant-devel] Documentation Updates
In-Reply-To: <D07A1529-D292-4822-8488-99A15133CCDC@umich.edu>
References: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
	<5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
	<D07A1529-D292-4822-8488-99A15133CCDC@umich.edu>
Message-ID: <4263BEE4-AC88-4DE8-9E78-74E704C7599D@media.mit.edu>

They should both stay, people may want access to the primitives (for  
example a set of sets) and there is no reason not to provide it.

Ian

On Jun 29, 2008, at 10:22 AM, Glenn Tarcea wrote:

> Ian,
>
> The set-valued-slots are very nice. I've been playing around with  
> them to write the documentation and have found they will cleanup  
> some code I had written using make-pset. One question: Should the  
> write up on PSETs remain in the documentation, or should there be a  
> write up to migrate people over to using the slot-valued-sets instead?
>
> Thanks,
>
> Glenn
>
> On Jun 20, 2008, at 2:42 PM, Ian Eslick wrote:
>
>> Great stuff!
>>
>> To answer a couple of questions:
>> - Cached slots aren't ready yet; I'll document when I can work out  
>> the kinks:
>> - Indexed slots are the same as the existing indexed-slots  
>> descriptions, except for
>>  the :inherit slot option so you should be able to copy & paste  
>> existing content
>>  for these slots and for derived index slots
>> - Derived index slots are still pertinent and will remain
>>
>> -----------------------
>> Set-valued Slots
>>
>> src/elephant/set-valued-slots.lisp
>>
>> Set-valued slots are a convenient shorthand to using PSETs as slot  
>> values to get persistent collections as slot values.
>>
>> (slot-value object 'set-slot)
>> returns a SLOT-SET which implements the PSET interface as well as:
>> 	map-slot-set - maps over the elements of the set
>> 	drop-slot-set - drops the set from the DB
>> 	slot-set-list - returns a list of the elements in the set
>>
>> (setf (slot-value object 'slotname) foo)
>> adds foo to the SLOT-SET in slot named 'slotname
>> however, if foo is a slot-set object, it drops and replaces the  
>> existing slot-set
>>
>> (slot-makunbound object 'slotname)
>> Make the slot unbound and drops the SLOT-SET from the DB.
>>
>> Of course these work for accessors too (setf (accessor object) foo)  
>> => adds foo to slot set
>>
>> There are a couple of helper macros to simplify expressions like:
>> 	(slot-set-list (slot-value object 'set-slot))
>>
>> (set-list object 'slotname)
>> (set-insert foo object 'slotname)
>> (set-remove foo object 'slotname)
>>
>> I'm happy to rename these operators if anyone has opinions on  
>> better names...
>>
>> Regards,
>> Ian
>>
>>
>> On Jun 20, 2008, at 11:17 AM, Glenn Tarcea wrote:
>>
>>> Attached are updates to the documentation. Specifically I updated:
>>>
>>> 1. Section: Setting Up Berkeley DB - to include the additional  
>>> flags (:berkeley-db-max-locks and :berkeley-db-max-objects) along  
>>> with their descriptions and updated the list of of parameters in  
>>> the my-config.sexp
>>>
>>> 2. Added a new section under Installation titled "Using Multiple  
>>> Versions Of Elephant" that describes how to use ASDF to allow  
>>> multiple versions of Elephant to be installed on a single system
>>>
>>> 3. Made a change to one of the Scenarios where the class was  
>>> system-object, but the methods were referring to system-state  
>>> (Section: Persistent System Objects)
>>>
>>> 4. Put placeholders in for the different slot types, titled:
>>>    Using Cached Slots
>>>    Using Indexed Slots
>>>    Using Derived Indexed Slots
>>>    Using Set Valued Slots
>>>
>>> 5. Added a write up based on Ian's email on Association Slots  
>>> titled "Using Association Slots"
>>>
>>> 6.  Updated the Section (4) titled "Berkeley DB Data Store":
>>>   a. to include references to the new my-config.sexp parameters
>>>   b. Updated the open-store parameters to include :max- 
>>> locks :cachesize and :max-objects
>>>   c. Updated performance tuning to quickly describe what berkeley- 
>>> db-max-locks, and objects do
>>>   d. Show an example call to open-store using :max-locks and :max- 
>>> objects
>>>   e. Updated performance tuning to include a reference to the  
>>> Berkeley-DB parameters that max-locks and max-objects refer to and  
>>> to point the user at DB_CONFIG for additional information.
>>>
>>> Can someone send me a quick example or jot down a few notes on  
>>> using Cached and Set Valued slots?
>>>
>>> Are Derived Indexed Slots still pertinent (I recall a lot of  
>>> discussion regarding them but don't recall what the outcome was).
>>>
>>> More documentation updates later.
>>>
>>> Thanks,
>>>
>>> Glenn
>>>
>>> <doc-patch-1.patch>_______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From eslick at media.mit.edu  Sun Jun 29 16:00:53 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 29 Jun 2008 12:00:53 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
	<2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
	<076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>
Message-ID: <E8F1C795-E2C1-4EB2-B823-20FA07CC8980@media.mit.edu>

Well Patrick, I'm sorry to say that I'm stumped.  I no longer have  
access to a 32-bit PPC system to debug this locally.  I remember  
having problems with the 64-bit CCL on Intel the last time I tried to  
run CCL and was waiting for them to go to production before running it  
again.

Have you tried to build & run elephant on any other platform?  Has  
anyone else out there run Elephant successfully with ccl under PPC-32?

Patrick, can you build elephant using SBCL on your platform?

Ian

On Jun 29, 2008, at 10:48 AM, Patrick May wrote:

> On 29 Jun 2008, at 10:17, Ian Eslick wrote:
>> Chris got unstable to work on ccl, so my best guess is that there  
>> are stale fasls.  Try :force t on asdf:load-op or ensuring that all  
>> fasls are deleted in the src/db-bdb directory.
>>
>> The error your forwarded refers to constants in DB-BDB-C46 when  
>> they should be referring to DB-BDB-C45.  If you get the wrong  
>> constants, then the BDB library is going to complain loudly...
>
>
> 	I had removed 0.9.1 and unstable and retrieved them again via darcs  
> before running that test.  As a second test, I cleaned and re- 
> retrieved them again, installed BDB 4.6, changed my-config.sexp  
> appropriately, and got this error:
>
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> > Error: Undefined function #:G2122 called with arguments (#<A  
> Foreign Pointer #x805A00> #<A Null Foreign Pointer> #<A Foreign  
> Pointer #x1084A0> 2 #<A Foreign Pointer #x107340> 10 0 #<A Foreign  
> Pointer [stack-allocated] #x565900>) .
> > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
> BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
> > Type :GO to continue, :POP to abort, :R for a list of available  
> restarts.
> > If continued: Retry applying #:G2122 to (#<A Foreign Pointer  
> #x805A00> #<A Null Foreign Pointer> #<A Foreign Pointer #x1084A0> 2  
> #<A Foreign Pointer #x107340> 10 0 #<A Foreign Pointer [stack- 
> allocated] #x565900>).
> > Type :? for other options.
> 1 >
>
> 	I've put the full output below my sig.
>
> Thanks,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
> Dagny:Patrick:~/src/lisp/elephant-unstable> ccl
> ; loading system definition from /usr/local/ccl/tools/asdf-install/ 
> asdf-install.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ASDF-INSTALL #x84EC1A6> as ASDF-INSTALL
> ;;; ASDF-Install version 0.6.10
> ; loading system definition from /Users/Patrick/src/lisp/clsql-4.0.3/ 
> clsql.asd into #<Package "ASDF0">
> ; loading system definition from /usr/local/asdf-install/site- 
> systems/uffi.asd into #<Package "ASDF1">
> ; registering #<SYSTEM UFFI #x85376DE> as UFFI
> ; registering #<SYSTEM CLSQL #x85099AE> as CLSQL
> Welcome to Clozure Common Lisp Version 1.2-r9226-RC1  (DarwinPPC32)!
> ? (asdf:operate 'asdf:load-op :elephant)
> ; loading system definition from elephant.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELEPHANT #x860095E> as ELEPHANT
> ; loading system definition from /usr/local/asdf-install/site- 
> systems/cl-base64.asd into #<Package "ASDF0">
> ; registering #<SYSTEM CL-BASE64 #x8625CEE> as CL-BASE64
> ; registering #<SYSTEM CL-BASE64-TESTS #x863BC8E> as CL-BASE64-TESTS
> ; $ gcc -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
> elephant-unstable/src/memutil/libmemutil.c -o /Users/Patrick/src/ 
> lisp/elephant-unstable/src/memutil/libmemutil.dylib -lm
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
> libmemutil.dylib
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/classes.lisp" :
> ;   In (SHARED-INITIALIZE :AROUND (PERSISTENT-METACLASS T)): Unused  
> lexical variable INDEX
> ;   In (REINITIALIZE-INSTANCE :AROUND (PERSISTENT-METACLASS)):  
> Unused lexical variable INITARGS
> ;   In (INITIALIZE-INSTANCE :AROUND (PERSISTENT-OBJECT)): Unused  
> lexical variable INITARGS
> ;   In (RECREATE-INSTANCE (PERSISTENT-OBJECT)) inside an anonymous  
> lambda form: Unused lexical variable ARGS
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8598B56> on #<CL-SOURCE-FILE "classes" #x8593016>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/schema-evolution.lisp" :
> ;   In (UPGRADE-ALL-MEMORY-INSTANCES (STORE-CONTROLLER)): Undeclared  
> free variable VALUE
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8598B56> on #<CL-SOURCE-FILE "schema-evolution" #x8591E66>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ; Warning: COMPILE-FILE failed while performing #<COMPILE-OP NIL  
> #x8598B56> on #<CL-SOURCE-FILE "schema-evolution" #x8591E66>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/collections.lisp" :
> ;   In (MAP-BTREE (T BTREE)): Unused lexical variable ARGS
> ;   In (MAP-INDEX (T BTREE-INDEX)): Unused lexical variable ARGS
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8598B56> on #<CL-SOURCE-FILE "collections" #x85914FE>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> ;Compiler warnings for "/Users/Patrick/src/lisp/elephant-unstable/ 
> src/elephant/query.lisp" :
> ;   In SORT-TUPLES: Unused lexical variable KEY-FN
> ; Warning: COMPILE-FILE warned while performing #<COMPILE-OP NIL  
> #x8596A46> on #<CL-SOURCE-FILE "query" #x858BF46>.
> ; While executing: #<STANDARD-METHOD ASDF:PERFORM (ASDF:COMPILE-OP  
> ASDF:CL-SOURCE-FILE)>, in process listener(1).
> NIL
> ? (use-package :elephant)
> T
> ? (open-store '(:BDB "/Users/Patrick/src/lisp/elephant-bdb/"))
> ; loading system definition from ele-bdb.asd into #<Package "ASDF0">
> ; registering #<SYSTEM ELE-BDB #x8771A66> as ELE-BDB
> Attempting to load libmemutil.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/memutil/ 
> libmemutil.dylib
> ; $ gcc -L/usr/local/BerkeleyDB.4.6/lib/ -I/usr/local/BerkeleyDB.4.6/ 
> include/ -bundle -fPIC -Wall -g -O2 -g /Users/Patrick/src/lisp/ 
> elephant-unstable/src/db-bdb/libberkeley-db.c -o /Users/Patrick/src/ 
> lisp/elephant-unstable/src/db-bdb/libberkeley-db.dylib -lm -ldb-4.6
> Loading /usr/local/BerkeleyDB.4.6/lib/libdb-4.6.dylib
> Attempting to load libberkeley-db.dylib...
> Loaded /Users/Patrick/src/lisp/elephant-unstable/src/db-bdb/ 
> libberkeley-db.dylib
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OFF 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::NDX 32 at 32> #<FOREIGN-RECORD- 
> FIELD #1# DB-BDB-C45::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
> C45::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:SIGNED 32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE  
> 32 at 32> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED  
> 32) #x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN- 
> ARRAY-TYPE (ARRAY (:SIGNED 8)) #x876531E> OBJ 8 at 96> #<FOREIGN-RECORD- 
> FIELD #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK  
> (OFF (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32)  
> 32) (MODE (:SIGNED 32) 32))) #x87652CE> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::OP 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C45::MODE 32 at 32> #<FOREIGN-RECORD- 
> FIELD #2# DB-BDB-C45::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB- 
> BDB-C45::OBJ 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C45::LOCK  
> 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCK fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:UNSIGNED 32) #x834783E> OFF 32 at 0> #<FOREIGN-RECORD-FIELD #1# NDX  
> 32 at 32> #<FOREIGN-RECORD-FIELD #1# GEN 32 at 64> #<FOREIGN-RECORD-FIELD  
> #2=#<FOREIGN-INTEGER-TYPE (:SIGNED 32) #x83479FE> MODE 32 at 96>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OFF 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::NDX 32 at 32> #<FOREIGN-RECORD- 
> FIELD #1# DB-BDB-C46::GEN 32 at 64> #<FOREIGN-RECORD-FIELD #2# DB-BDB- 
> C46::MODE 32 at 96>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> ; Warning: Redefining STRUCT DB-LOCKREQ fields to be:
> ;          (#<FOREIGN-RECORD-FIELD #1=#<FOREIGN-INTEGER-TYPE  
> (:SIGNED 32) #x83479FE> OP 32 at 0> #<FOREIGN-RECORD-FIELD #1# MODE  
> 32 at 32> #<FOREIGN-RECORD-FIELD #2=#<FOREIGN-INTEGER-TYPE (:UNSIGNED  
> 32) #x834783E> TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3=#<FOREIGN- 
> ARRAY-TYPE (ARRAY (:SIGNED 8)) #x876531E> OBJ 8 at 96> #<FOREIGN-RECORD- 
> FIELD #4=#<FOREIGN-POINTER-TYPE (:* (:STRUCT DB-BDB-C45::DB-LOCK  
> (OFF (:UNSIGNED 32) 32) (NDX (:UNSIGNED 32) 32) (GEN (:UNSIGNED 32)  
> 32) (MODE (:SIGNED 32) 32))) #x87652CE> LOCK 32 at 128>)
> ;          were
> ;          (#<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::OP 32 at 0>  
> #<FOREIGN-RECORD-FIELD #1# DB-BDB-C46::MODE 32 at 32> #<FOREIGN-RECORD- 
> FIELD #2# DB-BDB-C46::TIMEOUT 32 at 64> #<FOREIGN-RECORD-FIELD #3# DB- 
> BDB-C46::OBJ 8 at 96> #<FOREIGN-RECORD-FIELD #4# DB-BDB-C46::LOCK  
> 32 at 128>)
> ; While executing: CCL::PARSE-FOREIGN-RECORD-TYPE, in process  
> listener(1).
> > Error: Undefined function #:G2122 called with arguments (#<A  
> Foreign Pointer #x805A00> #<A Null Foreign Pointer> #<A Foreign  
> Pointer #x1084A0> 2 #<A Foreign Pointer #x107340> 10 0 #<A Foreign  
> Pointer [stack-allocated] #x565900>) .
> > While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
> BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
> > Type :GO to continue, :POP to abort, :R for a list of available  
> restarts.
> > If continued: Retry applying #:G2122 to (#<A Foreign Pointer  
> #x805A00> #<A Null Foreign Pointer> #<A Foreign Pointer #x1084A0> 2  
> #<A Foreign Pointer #x107340> 10 0 #<A Foreign Pointer [stack- 
> allocated] #x565900>).
> > Type :? for other options.
> 1 >
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From gtarcea at umich.edu  Sun Jun 29 16:11:03 2008
From: gtarcea at umich.edu (Glenn Tarcea)
Date: Sun, 29 Jun 2008 12:11:03 -0400
Subject: [elephant-devel] Set-Valued-Slots Documentation Update
In-Reply-To: <4263BEE4-AC88-4DE8-9E78-74E704C7599D@media.mit.edu>
References: <5B8CCB3C-BBD4-4131-A2D1-C93E01A2ECDF@umich.edu>
	<5EF621BA-E912-414B-A69F-869DC8A3278B@media.mit.edu>
	<D07A1529-D292-4822-8488-99A15133CCDC@umich.edu>
	<4263BEE4-AC88-4DE8-9E78-74E704C7599D@media.mit.edu>
Message-ID: <A5A426FE-061B-415F-BBB5-904C2AC6C9EE@umich.edu>

Attached is a set of patches for the Set-Valued-Slots. This patch  
also includes the changes from the last set of documentation patches  
(I had to do this to get the new set of changes included).

On top of the last set of document changes this new patch set  
includes the following 3 changes:

1. I removed the subsection on Cached Slots
2. I corrected the spelling for the Set-Valued slots sections (Valued  
was spelled Valed).
3. I included a write up on using set-valued-slots. All the examples  
in the section should work

I have not updated the API documentation to include the new calls and  
macros. I also did not include a write up on how to remove the sets  
from the DB.  At the moment I'm pondering documentation layout and  
will post some thoughts on some small changes to the layout (and  
didn't want to include these changes only to move them around). Also  
I'm trying to keep my patches small (which I assume will make it  
easier to review).

If there is a better/easier way for me to post the documentation  
changes let me know.

Thanks,

Glenn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc-update-june29v1.patch
Type: application/octet-stream
Size: 28285 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080629/9716db00/attachment.obj>
-------------- next part --------------


On Jun 29, 2008, at 11:54 AM, Ian Eslick wrote:

> They should both stay, people may want access to the primitives  
> (for example a set of sets) and there is no reason not to provide it.
>
> Ian
>
> On Jun 29, 2008, at 10:22 AM, Glenn Tarcea wrote:
>
>> Ian,
>>
>> The set-valued-slots are very nice. I've been playing around with  
>> them to write the documentation and have found they will cleanup  
>> some code I had written using make-pset. One question: Should the  
>> write up on PSETs remain in the documentation, or should there be  
>> a write up to migrate people over to using the slot-valued-sets  
>> instead?
>>
>> Thanks,
>>
>> Glenn
>>
>> On Jun 20, 2008, at 2:42 PM, Ian Eslick wrote:
>>
>>> Great stuff!
>>>
>>> To answer a couple of questions:
>>> - Cached slots aren't ready yet; I'll document when I can work  
>>> out the kinks:
>>> - Indexed slots are the same as the existing indexed-slots  
>>> descriptions, except for
>>>  the :inherit slot option so you should be able to copy & paste  
>>> existing content
>>>  for these slots and for derived index slots
>>> - Derived index slots are still pertinent and will remain
>>>
>>> -----------------------
>>> Set-valued Slots
>>>
>>> src/elephant/set-valued-slots.lisp
>>>
>>> Set-valued slots are a convenient shorthand to using PSETs as  
>>> slot values to get persistent collections as slot values.
>>>
>>> (slot-value object 'set-slot)
>>> returns a SLOT-SET which implements the PSET interface as well as:
>>> 	map-slot-set - maps over the elements of the set
>>> 	drop-slot-set - drops the set from the DB
>>> 	slot-set-list - returns a list of the elements in the set
>>>
>>> (setf (slot-value object 'slotname) foo)
>>> adds foo to the SLOT-SET in slot named 'slotname
>>> however, if foo is a slot-set object, it drops and replaces the  
>>> existing slot-set
>>>
>>> (slot-makunbound object 'slotname)
>>> Make the slot unbound and drops the SLOT-SET from the DB.
>>>
>>> Of course these work for accessors too (setf (accessor object)  
>>> foo) => adds foo to slot set
>>>
>>> There are a couple of helper macros to simplify expressions like:
>>> 	(slot-set-list (slot-value object 'set-slot))
>>>
>>> (set-list object 'slotname)
>>> (set-insert foo object 'slotname)
>>> (set-remove foo object 'slotname)
>>>
>>> I'm happy to rename these operators if anyone has opinions on  
>>> better names...
>>>
>>> Regards,
>>> Ian
>>>
>>>
>>> On Jun 20, 2008, at 11:17 AM, Glenn Tarcea wrote:
>>>
>>>> Attached are updates to the documentation. Specifically I updated:
>>>>
>>>> 1. Section: Setting Up Berkeley DB - to include the additional  
>>>> flags (:berkeley-db-max-locks and :berkeley-db-max-objects)  
>>>> along with their descriptions and updated the list of of  
>>>> parameters in the my-config.sexp
>>>>
>>>> 2. Added a new section under Installation titled "Using Multiple  
>>>> Versions Of Elephant" that describes how to use ASDF to allow  
>>>> multiple versions of Elephant to be installed on a single system
>>>>
>>>> 3. Made a change to one of the Scenarios where the class was  
>>>> system-object, but the methods were referring to system-state  
>>>> (Section: Persistent System Objects)
>>>>
>>>> 4. Put placeholders in for the different slot types, titled:
>>>>    Using Cached Slots
>>>>    Using Indexed Slots
>>>>    Using Derived Indexed Slots
>>>>    Using Set Valued Slots
>>>>
>>>> 5. Added a write up based on Ian's email on Association Slots  
>>>> titled "Using Association Slots"
>>>>
>>>> 6.  Updated the Section (4) titled "Berkeley DB Data Store":
>>>>   a. to include references to the new my-config.sexp parameters
>>>>   b. Updated the open-store parameters to include :max- 
>>>> locks :cachesize and :max-objects
>>>>   c. Updated performance tuning to quickly describe what  
>>>> berkeley-db-max-locks, and objects do
>>>>   d. Show an example call to open-store using :max-locks  
>>>> and :max-objects
>>>>   e. Updated performance tuning to include a reference to the  
>>>> Berkeley-DB parameters that max-locks and max-objects refer to  
>>>> and to point the user at DB_CONFIG for additional information.
>>>>
>>>> Can someone send me a quick example or jot down a few notes on  
>>>> using Cached and Set Valued slots?
>>>>
>>>> Are Derived Indexed Slots still pertinent (I recall a lot of  
>>>> discussion regarding them but don't recall what the outcome was).
>>>>
>>>> More documentation updates later.
>>>>
>>>> Thanks,
>>>>
>>>> Glenn
>>>>
>>>> <doc-patch-1.patch>_______________________________________________
>>>> elephant-devel site list
>>>> elephant-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>> _______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>


From pjm at spe.com  Sun Jun 29 18:58:23 2008
From: pjm at spe.com (Patrick May)
Date: Sun, 29 Jun 2008 14:58:23 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <E8F1C795-E2C1-4EB2-B823-20FA07CC8980@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
	<2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
	<076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>
	<E8F1C795-E2C1-4EB2-B823-20FA07CC8980@media.mit.edu>
Message-ID: <381DCBD3-9DF9-4899-AE1D-1F8874787AD7@spe.com>

On 29 Jun 2008, at 12:00, Ian Eslick wrote:
> Well Patrick, I'm sorry to say that I'm stumped.  I no longer have  
> access to a 32-bit PPC system to debug this locally.  I remember  
> having problems with the 64-bit CCL on Intel the last time I tried  
> to run CCL and was waiting for them to go to production before  
> running it again.
>
> Have you tried to build & run elephant on any other platform?  Has  
> anyone else out there run Elephant successfully with ccl under PPC-32?
>
> Patrick, can you build elephant using SBCL on your platform?


	I just tried SBCL 1.0.2, elephant-unstable, and Berkeley DB 4.5.  It  
worked.

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)





From eslick at media.mit.edu  Mon Jun 30 00:56:21 2008
From: eslick at media.mit.edu (Ian Eslick)
Date: Sun, 29 Jun 2008 20:56:21 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <381DCBD3-9DF9-4899-AE1D-1F8874787AD7@spe.com>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
	<2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
	<076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>
	<E8F1C795-E2C1-4EB2-B823-20FA07CC8980@media.mit.edu>
	<381DCBD3-9DF9-4899-AE1D-1F8874787AD7@spe.com>
Message-ID: <9DF2A294-5F91-4700-8F58-EF449F2A8926@media.mit.edu>

I'll talk to the Clozure developers when I get a chance; it's possible  
one of them will have an easier time figuring out what's causing this  
problem.

Cheers,
Ian


On Jun 29, 2008, at 2:58 PM, Patrick May wrote:

> On 29 Jun 2008, at 12:00, Ian Eslick wrote:
>> Well Patrick, I'm sorry to say that I'm stumped.  I no longer have  
>> access to a 32-bit PPC system to debug this locally.  I remember  
>> having problems with the 64-bit CCL on Intel the last time I tried  
>> to run CCL and was waiting for them to go to production before  
>> running it again.
>>
>> Have you tried to build & run elephant on any other platform?  Has  
>> anyone else out there run Elephant successfully with ccl under  
>> PPC-32?
>>
>> Patrick, can you build elephant using SBCL on your platform?
>
>
> 	I just tried SBCL 1.0.2, elephant-unstable, and Berkeley DB 4.5.   
> It worked.
>
> Regards,
>
> Patrick
>
> ----
> pjm at spe.com
> S P Engineering, Inc.
> Large scale, mission-critical, distributed OO systems design and  
> implementation.
> (C++, Java, Common Lisp, Jini, middleware, SOA)
>
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel



From pjm at spe.com  Mon Jun 30 03:16:01 2008
From: pjm at spe.com (Patrick May)
Date: Sun, 29 Jun 2008 23:16:01 -0400
Subject: [elephant-devel] Problem installing with latest Clozure
In-Reply-To: <9DF2A294-5F91-4700-8F58-EF449F2A8926@media.mit.edu>
References: <72A138AC-671B-459C-88D5-A03A7B214BDF@spe.com>
	<06A7F5B2-17FD-4E33-8485-670B39DE3875@media.mit.edu>
	<6457A671-BF86-42F9-8605-C08D2DBF1EB6@spe.com>
	<250994741-1214564971-cardhu_decombobulator_blackberry.rim.net-1469284678-@bxe123.bisx.prod.on.blackberry>
	<ACBF9929-78CC-4342-9D94-E3A0A52DC802@spe.com>
	<FBBCF1AF-A49F-4582-8215-0960B3062DFB@media.mit.edu>
	<8724B86A-3DA2-41FE-8839-C3E29A720E4D@spe.com>
	<50e8e4f60806270720m33adf3c0ra70e1bed2f3ec7b5@mail.gmail.com>
	<153DC919-DE51-4006-BFCE-3767753F5FD7@spe.com>
	<E752BBAF-3D63-4588-AE38-6B20E5CEF8BD@media.mit.edu>
	<6FD92050-7E07-4958-A07C-982816BEFDAD@spe.com>
	<2DEE8D5B-0287-4DA1-A1A4-EBCED62AB9E8@media.mit.edu>
	<076967FC-E8CD-4DD0-AE18-F52644093A26@spe.com>
	<E8F1C795-E2C1-4EB2-B823-20FA07CC8980@media.mit.edu>
	<381DCBD3-9DF9-4899-AE1D-1F8874787AD7@spe.com>
	<9DF2A294-5F91-4700-8F58-EF449F2A8926@media.mit.edu>
Message-ID: <8C2032A7-64B8-4165-B8AD-1FCB266852D5@spe.com>

On 29 Jun 2008, at 20:56, Ian Eslick wrote:
> I'll talk to the Clozure developers when I get a chance; it's  
> possible one of them will have an easier time figuring out what's  
> causing this problem.
>
> Cheers,
> Ian

Ian,

	Thanks.  Let me know if you'd like me to run any other tests.

Regards,

Patrick

----
pjm at spe.com
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and  
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)