Can you get us temporary access to your 64-bit machine to do some experimentation? We had another user go through this same problem on an AMD awhile back and it's hard for Robert and I to test because neither of us have a 64-bit machine available.
#2 - The double definition is intentional - it's two different lisp ways to call the same C function, one is general for any generic value and one uses c-strings only. It avoids the general overhead of buffer-streams. I assume you're using BDB-4.3? #1 - I haven't seen the fp overflow problem before, however. A couple of thoughts. The system does read some values from the DB after open. You might trace the db-bdb/bdb-controller function to see where it's failing - that might help us have a better clue as to the source. Is it failing opening the environment, a particular table, or in reading those values? It's also possible that the serializer has a 32-bit assumption hidden in it (although most of that should be in memutil). I've got a serializer rewrite that fixes anything like that, but it won't be ready to commit for awhile. Ian Marco Baringer wrote: > i'm currently trying to get elephant to run on sbcl x86-64. i've > patched memutil and sleepycat.lisp heavily to remove the assumption > that an int is equivalent to a (signed 32), most of db.h is defined in > terms of uint32_t anyway so this wasn't a big problem. i'm currently > able to open a db store and most of the serializer tests pass (except > those related to btree objects). > > 1) now i've got some problems related to the berkeleydb backend (i > think) which i can't seem to figure out :( anything btree related > fails with the cryptic error: > > arithmetic error FLOATING-POINT-OVERFLOW signalled > > this even happens if i just open, close and then attempt to reopen > the test db. anybody seen this before? > > 2) in sleepycat.lisp the c function db_get_raw is defined twice, once > as %db-get-key-buffered and once as %db-get-buffered. is this > intentional? > > p.s. - i'm running elephant 0.6.0 since that's what i was using before > and i know it works. i'll upgrade to cvs if neccessary but i'd like to > avoid dealing wth api changes (assuming there have been some). > > p.p.s - elephant is a sweet piece of software :) > _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
