[MIT-Scheme-devel] FFI and KyotoCabinet

[Matt Birkholz]

> From: Peter Feigl <address@hidden>
> Date: Wed, 23 Mar 2011 22:48:13 +0100
> 
> Hello!
> 
> I've been trying to create bindings for KyotoCabinet (a
> berkeley-db-like database) with the FFI bindings, and have largely
> succeeded.

I hope it was not too trying.

> A couple of questions remain:
> - How can I get MIT-Scheme to look for the files that are generated by
>   the FFI in the current working directory, instead of the main lib
>   directory? Development would be much easier that way.

I was trying to avoid the accidental use of mismatched types and
shims, so I load FOO-types.bin from the same directory as FOO-shim.so.
FOO-shim.so must be in the main lib directory because it is loaded
on-demand, when the current working directory is whatever.

>   Right now, I get the following error message: 
>   <Unable to find file "/usr/lib/mit-scheme-i386/kyotocabinet-types"
>    because: File does not exist.>

PREpend "." to MITSCHEME_LIBRARY_PATH.  Your -types.bin/-shim.so must
be in the FIRST directory on this list, at syntax/run time.

> - Is there a way to include extern variables? For example, I have the
>   following declaration in the header file:
>   <extern const char* const KCVERSION;>
>   Right now, I include it as an enum, but it would be great if I could
>   somehow correctly access this value.

Yes -- a quick way.  Add this helper function to your shim:

        const char *
        kcget_version (void)
        {
          return (KCVERSION);
        }

and this to your cdecls:

        (extern (* (const char)) kcget_version)

and this to your code:

        (define (kcversion) (c-peek-cstring (C-call "kcget_version")))

Or something like that.

A higher performance way: a new syntax, like C-callback, to memoize
the result of a call to dld-lookup-symbol.  The memoized alien can
then be used directly by c-peek- primitives, no fancy stack-sealing
trampolines necessary.  Thus we might write this:

        (c-peek-cstringp (C-variable "KCVERSION") 0)

I'll leave the actual implementation (esp. the cdecl syntax) as a
problem for someone who really WANTS it. :-)

> - Does c-peek-cstring copy the actual string data? Can I release the
>   memory, even if I want to keep using the string?

Yep and yep.

> - (Not related to KyotoCabinet, but to Berkeley DB): How can I access
>   and call function pointers that are structure members?
>   Berkeley DB defines roughly the following:
>   <struct DB { int (*open)(DB *, DB_TXN *, const char *, const char *, 
>                            DBTYPE, u_int32_t, int);
>    };>
>   Is there a way I can call this open function?

Yes.  Add this helper tramp to your shim:

        int
        DB_open (db DB, ...)
        {
            (db->open)(db, ...);
        }

and this to your cdecls:

        (extern int DB_open (db DB) ...)

and this to your code:

        (C-call "DB_open" db ...)

> - If it is useful, I'd like to contribute this code to the main
>   MIT-Scheme repository. How do I go about doing this? "Just" prepare
>   a patch against git and email it? Where to?

Yes, here.  Just a few questions if you please...

Are you party to an employment contract?

Do you intend this to be one of the INSTALLED_SUBDIRS?  If you just
want a spot in src/, like src/swat/, that should be no problem (except
perhaps the copyright).  If you expect to be one of the
INSTALLED_SUBDIRS, you will want to play nice with the whole
./Setup.sh, ./configure, make, make install, make maintainer-clean
cycle.  My Gtk interface, for example, implements options
--without-gtk and --with-gtk, and auto-selection via pkg-config.

> Thanks for making MIT-Scheme such a great system.

Me too.  We stand on the shoulders of giants standing on the shoulders
of giants...  (It's giants all the way down! :-)