[elephant-devel] Problems with Elephant on Clozure CL

R. Matthew Emerson rme at clozure.com
Mon Dec 15 19:38:33 UTC 2008


On Dec 15, 2008, at 10:17 AM, Wesley Kerr wrote:

> I found this not helpful when I asked a similar question (It came from
> R. Matthew Emerson)  :

I hope that was supposed to be "this note helpful" instead of "this  
not helpful".

Another way to address the problem would be to fix UFFI so that a  
definition like

(def-function ("db_get_raw" %db-get-key-buffered)
    ((db :pointer-void)
     (txn :pointer-void)
     (key array-or-pointer-char)
     (key-size :unsigned-int)
     (buffer array-or-pointer-char)
     (buffer-length :unsigned-int)
     (flags :unsigned-int)
     (result-size :unsigned-int :out))
  :returning :int)

would macroexpand into CCL-specific code like this

(defun %db-get-key-buffered (db txn key key-size buffer buffer-length  
flags)
  (rlet ((result-size :unsigned))
    (values (external-call "db_get_raw"
                           :address db
                           :address txn
                           :address key
                           ...)
            (pref result-size :unsigned))))

rather than the gensym-named stub and slightly higher-level wrapper  
around it.

This way, you could inline %DB-GET-KEY-BUFFERED with no problem  
(although it's not clear at first glance how much sense it makes to  
inline something that does a possibly expensive database operation).


>
> At the top of src/db-bdb/berkeley-db.lisp is a declaim form that
> declaims a bunch of functions inline.
>
> (declaim
> #-elephant-without-optimize (optimize (speed 3) (safety 1) (debug 1)  
> (space 1))
> #-lispworks
> (inline %db-get-key-buffered db-get-key-buffered
>                %db-get-buffered db-get-buffered db-get
>                %db-put-buffered db-put-buffered
>                ...))
>
> Make that #-lispworks be #-(or lispworks ccl) and that should get you
> going.
>
> Long explanation:
>
> Consider the following DEF-FUNCTION form:
>
> (def-function ("db_get_raw" %db-get-key-buffered)
>   ((db :pointer-void)
>    (txn :pointer-void)
>    ...
>    (result-size :unsigned-int :out))
> :returning :int)
>
> This macroexpands into something like
>
> (progn
> (defun #:G0 (arg0 arg1 ...)
>   ...)
> (defun %db-get-key-buffered ()
>   (values (#:G0 arg0 arg1 ...)
>           ...)))
>
> If %DB-GET-KEY-BUFFERED is declaimed INLINE, we save its lambda
> expression, which includes the gensym.  When the lambda expression in
> substituted into a caller defined in some other file, it won't be
> referencing the same #:G0, and you get undefined function error.
>
> (Inlining across files used to be disabled, at least until several  
> months
> ago, so if this cropped up recently, that might be why.)
>
> [from Gary Byers:]
>
> SBCL seems to handle a toplevel (DECLAIM (INLINE FOO)) (or the  
> combination
> of the declamation and a subsequent DEFUN) as something like:
>
> (eval-when (:compile-toplevel)
> (save-lambda-definition (lambda-definition-for 'foo) *env*))
> (eval-when (:load-toplevel)
> (save-global-lambda-definition (preprocessed-definition-for foo)))
>
> where the "preprocessed definition" appears to be fully macroexpanded
> (doesn't contain references to macros that may have been defined at
> compile time but might not be defined at load time.)  That could be  
> nice
> functionality to have, but there's no way that the load-time
> inline-expansion and the compile-time inline-expansion can be  
> equivalent
> when uninterned symbols are involved.  Once we've crossed a point  
> where
> we can't guarantee that, I think that we're pretty much into an area
> where code is depending on non-portable implementation artifacts.
>
> Hope this helps.
>
> On Sat, Dec 13, 2008 at 4:11 PM, Clinton Ebadi <clinton at unknownlamer.org 
> > wrote:
>>
>> Greetings,
>>
>> I am attempting to use Elephant (-stable or -unstable; it fails on  
>> both
>> in the same way) with BDB (4.5, 4.6, and 4.7 also all fail the same  
>> way)
>> on Clozure CL (1.2 or 1.3-trunk) linux_x86-64.
>>
>> The main portion of Elephant builds fine, but OPEN-STORE fails when
>> opening a :BDB store when loading berekely-db-constant.lisp with
>> `Package DB-BDB-C4[567] does not exist` (the [567] being the same  
>> as the
>> version of BDB I'm attempting to use). If I nuke the fasl cache and  
>> then
>> manually (clc:clc-require :ele-bdb) after loading Elephant things  
>> work
>> fine, but then OPEN-STORE fails again with:
>>
>> ? (elephant:open-store '(:bdb "/home/clinton/local/var/beesknees/ 
>> bdb/"))
>>> Error: Undefined function #:G13940 called with arguments (#<A  
>>> Foreign Pointer #x227F540> #<A Null Foreign Pointer> #<A Foreign  
>>> Pointer #x2282200> 2 20 #<A Foreign Pointer #x22821E0> 0 10 0 #<A  
>>> Foreign Pointer #1=[stack-allocated] #x4046ADD0> #<A Foreign  
>>> Pointer #1# #x4046AD90>) .
>>> While executing: #<STANDARD-METHOD ELEPHANT::DATABASE-VERSION (DB- 
>>> BDB::BDB-STORE-CONTROLLER)>, in process listener(1).
>>
>> Backtrace:
>>
>> *(7FE3D6466618) : 0 (FUNCALL #'#<#<STANDARD-METHOD  
>> ELEPHANT::DATABASE-VERSION (DB-BDB::BDB-STORE-CONTROLLER)>> #<BDB- 
>> STORE-CONTROLLER /home/clinton/local/var/beesknees/bdb/>) 621
>> (7FE3D6466790) : 1 (%CALL-NEXT-METHOD #<A Foreign Pointer [stack- 
>> allocated] #x4046AD90>) 1061
>> (7FE3D6466810) : 2 (FUNCALL #'#<#<STANDARD-METHOD  
>> ELEPHANT::DATABASE-VERSION :AROUND (T)>> #<BDB-STORE-CONTROLLER / 
>> home/clinton/local/var/beesknees/bdb/>) 37
>> (7FE3D6466830) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (#<STANDARD- 
>> METHOD ELEPHANT::DATABASE-VERSION :AROUND #> #<STANDARD-METHOD  
>> ELEPHANT::DATABASE-VERSION #>) 17577066155281) 781
>> (7FE3D6466898) : 5 (FUNCALL #'#<#<STANDARD-METHOD  
>> ELEPHANT::INITIALIZE-SERIALIZER (ELEPHANT:STORE-CONTROLLER)>> #<BDB- 
>> STORE-CONTROLLER /home/clinton/local/var/beesknees/bdb/>) 53
>> (7FE3D64668B8) : 6 (FUNCALL #'#<#<STANDARD-METHOD ELEPHANT::OPEN- 
>> CONTROLLER (DB-BDB::BDB-STORE-CONTROLLER)>> #<BDB-STORE-CONTROLLER / 
>> home/clinton/local/var/beesknees/bdb/> :RECOVER T :RECOVER-FATAL  
>> NIL :THREAD T :REGISTER T :DEADLOCK-DETECT T :MULTIVERSION  
>> NIL :CACHE-SIZE 20971520 :MAX-LOCKS 2000 :MAX-OBJECTS 2000) 1461
>> (7FE3D64669C0) : 7 (%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE (NIL  
>> #<STANDARD-METHOD ELEPHANT::OPEN-CONTROLLER #> . 17577066155344)) 861
>> (7FE3D6466A30) : 8 (%%STANDARD-COMBINED-METHOD-DCODE (NIL (#<#>)  
>> #<STANDARD-METHOD ELEPHANT::OPEN-CONTROLLER #>) 17577066155344) 269
>> (7FE3D6466A90) : 10 (OPEN-STORE (:BDB "/home/clinton/local/var/ 
>> beesknees/bdb/")) 253
>> (7FE3D6466AC8) : 11 (CALL-CHECK-REGS ELEPHANT:OPEN-STORE (:BDB "/ 
>> home/clinton/local/var/beesknees/bdb/")) 229
>> (7FE3D6466B00) : 12 (TOPLEVEL-EVAL (ELEPHANT:OPEN-STORE '#) NIL) 733
>> (7FE3D6466BA0) : 13 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to  
>> *TERMINAL-IO* #x300040EEA30D> :OUTPUT-STREAM #<SYNONYM-STREAM to  
>> *TERMINAL-IO* #x300040EEA1AD> :BREAK-LEVEL 0 :PROMPT-FUNCTION  
>> #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global)   
>> #x30004054DB7F>) 1821
>> (7FE3D6466DD8) : 14 (TOPLEVEL-LOOP) 109
>> (7FE3D6466E08) : 15 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION  
>> (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 101
>> (7FE3D6466E20) : 16 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER- 
>> PROCESS)>) 645
>> (7FE3D6466EB8) : 17 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER  
>> listener(1) [Active] #x300040E9B74D> (#<COMPILED-LEXICAL-CLOSURE #  
>> #x300040EE93CF>)) 717
>> (7FE3D6466F48) : 18 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET- 
>> INTERNAL)> #<TTY-LISTENER listener(1) [Active] #x300040E9B74D>  
>> (#<COMPILED-LEXICAL-CLOSURE # #x300040EE93CF>)) 389
>> (7FE3D6466F98) : 19 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE- 
>> STARTUP-FUNCTION)>) 293
>>
>> The same test works fine on SBCL. Any ideas? Given the problem with
>> autoloading :ELE-BDB when OPEN-STORE is called leads me to believe
>> something is wrong with the asdf system, but I can't see why it would
>> fail to work properly.
>>
>> --
>> <captain_krunk> ntk is currently using "telnet fyodor 25" to send  
>> email
>>
>> _______________________________________________
>> 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





More information about the elephant-devel mailing list