Well, just to encourage you a bit more... While programmatic generation of JNA callbacks might not be the best answer to my current problems, one area where I see programmatic generation of native interfaces and structures to be really, really useful would be dynamic loading of OSX "BridgeSupport" files.
These are XML files that describe (non-Objective-C) native interfaces in a way that can be easily read by language bridges like those for Python and Ruby. So essentially these describe calls in a way that code can build libffi invocations on the fly (since these languages bridges are all built with libffi, and in fact Apple ships libffi with the OS.) So it should be possible to read these files and generate classes that can be used by JNA to build libffi calls. The most obvious way to do this would be to generate java classes "ahead of time" but I'd like to get to something that works without forcing AOT steps. The "right" solution would probably be to remove the middleman (i.e JNA) and implement a lower level mechanism for building libffi calls - but this will not be trivial work, and it seems like the code you're building would provide a means of achieving the dynamic loading parts while still taking advantage of all of JNA's plumbing. Cheers ..Mark.. On Mon, Jan 25, 2010 at 10:50 PM, mac <[email protected]> wrote: >> This looks pretty nice - one question though: is there an API provided >> that would let me build callbacks and structs programmatically - as >> opposed to the declarative style of defclib? > > Not currently but it's definetly doable. I already use clojure.asm to > generate classes on the fly. > > I have thought about this a bit actually and I will try to make my > code more modular for my own sake as well (it's very messy and > monolithic at the moment) so I could probably expose some of the class > generation functions once that is done. > > Some random info about my implementation: > All my interface code is generated at runtime because I wanted to use > the direct mapping feature of jna which requires exotic things like > static initializers and inner classes. > So defclib just parses it's body and creates a "library specification" > which can be used at runtime (by calling loadlib) to generate and load > proper jna classes. > The reason it's done at runtime are > 1. Native longs are different sizes on different platforms and this > way they user doesn't have to care about it because the size will be > known at runtime so only one type of long is required. > 2. Since I needed to generate classes I would have to build in support > for AOT compilation if class generation would be done before runtime > and I didn't feel like spending energy on that ;) > > /Markus > >> >> Being able to create callbacks programmatically would be one way of >> working around the problem I describe >> here:https://jna.dev.java.net/servlets/ReadMsg?list=dev&msgNo=808 >> >> (I realize that this would basically be the "generate callback classes >> OTF solution" that I said I'd rather not do, but if the code for this >> already exists I could be persuaded otherwise.) >> >> Cheers >> >> ..Mark.. >> >> >> >> On Sun, Jan 24, 2010 at 8:54 AM, mac <[email protected]> wrote: >> > A little progress update. >> >> > I havent had much time to work on this since my initial effort. But >> > this weekend I have gotten structures to work. >> > The reason that special support for structures is needed is to support >> > C api's that pass them by value. >> > Most of the effort to make this work went into how I handle types. I >> > want the type definitions in the clojure DSL to look sort of like C so >> > that it's easy to copy a C header file and get it right. >> > Since I had to support user specified types to support structures, as >> > an added safety bonus the callbacks are now typed as well. >> > Usage examples are here: >> >http://github.com/bagucode/clj-native/tree/master/src/examples/ >> >> > enjoy! >> > /Markus >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to [email protected] >> > Note that posts from new members are moderated - please be patient with >> > your first post. >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> >http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
