Thanks a ton for the quick response and the suggestions. I'd been using @eval because I'd misread the docs, and didn't realize that ccall would happily take a const for its first param.
The naming follows our existing convention, where all of our bindings packages are named fdb-*. How strict are the naming practices in the Julia community? I'll look at turning this into a package. I had one other question: our C library is designed to be used asynchronously, so it kind of stings to have to implement a blocking interface. Does anybody have a futures library in the works that I should be aware of? Thanks a ton, Will On Tuesday, February 11, 2014 5:08:24 PM UTC-5, Keno Fischer wrote: > > Cool! A couple of notes: > > 1) This should probably be a proper package. > 2) Your use of @eval is unnecessary and slow, just remove @eval and all > the $ signs and you should be fine in all cases that I saw. > 3) Rather than the whole dlopen/dlsym/dlclose buisiness, just use > `cglobal`. It has the benefit of using the same compiler magic as ccall > does and will eventually also allow precompilation to work more easily and > more performantly > 4) The @windows? syntax can become a bit painful with multiline > expressions. I recommend > @windows_only begin > # windows stuff > end > > @unix_only begin > #unix stuff > end > > Cheers, > Keno > > > > On Tue, Feb 11, 2014 at 4:59 PM, <[email protected] > <javascript:>>wrote: > >> Hi all, >> >> I'm new to Julia, but was intrigued by the simplicity of y'all's C >> interface so as a little side-project I threw together some bindings for >> the NoSQL database that I work on: >> >> https://github.com/wwilson/fdb-julia/ >> >> It's extremely alpha right now, and doesn't let you do much more than get >> and set key-value pairs transactionally (and in a blocking fashion, at >> that). My intention is to keep working on it until it's a mature interface >> to the database, then use it as the basis for a homomorphic encryption >> layer on top of our storage engine. >> >> Cool project! Keep up the great work! >> >> Will >> >> P.S. I'm aware that the way in which I extract a function pointer to >> run_network with dlsym() and then pass that directly to >> _beginthread/pthread_create is extremely sketchy, since the stack is in a >> technically invalid state. Given the calling convention on x86_64, however, >> it should always work. Not sure about other platforms. >> > >
