[Larceny-users] FFI and Larceny libs

[Álvaro Castro-Castilla]

El 4 de enero de 2010 16:32, Felix Klock <felixluser at pnkfx.org> escribió:

> On Jan 4, 2010, at 11:12 AM, Álvaro Castro-Castilla wrote:
>
> > Is it possible to compile with Larceny some code into a library, defining
> a C interface for a number of functions (or just one) so I can call them
> from C code, dynamically loading or linking against it?
>
> It is hypothetically possible.  After all, the entry point to the native
> Larceny runtime itself is invoked from a C function.
>
> It may even be relatively easy with *Petit* Larceny, since that is designed
> to be hosted on top of C, and so there is no shift in the machine model when
> one transitions between the Larceny, and as part of its build process, it
> generates a library file that holds the runtime system.
>
> But I think its fairest to say that this is not a use-case we have worked
> on (for either the native nor the Petit runtime), so it will be difficult to
> achieve, and no method for doing it is documented.  For example, to do it
> with native Larceny, you'd almost certainly have to link the runtime in with
> your own code, which means you'd have to muck with the runtime build process
> to mix the two together.
>
> ----
>
> Larceny's FFI is meant to place the Larceny runtime on top of the control
> structure; then Larceny Scheme code invokes the functions implemented in C,
> shifting the machine state and marshaling values where appropriate e.g.
> passing along function pointers to call back into Scheme when you pass a
> Scheme procedure (closure) to a C routine expecting a function pointer.
>
> So depending on what you are trying to accomplish, the easiest short-term
> solution may be to compile your C code into a dynamically loadable library
> (lets call it foo.so), then start Larceny, load up foo.so via the FFI, and
> then invoke an entry point to foo.so and passing along the Larceny functions
> that you want to access as arguments.
>
> Does that make sense?
>
> (The main problem with this is that not all C code is easily turned into a
> dynamically loadable library.  If your C code footprint is small it may be
> easy, but integrating Larceny into a large code base in this way is not
> realistic.)
>
> -Felix
>
>
>
Thanks for such a quick reply!

I understand that the approach taken for FFI is precisely of giving main
control to Larceny, as you would use C functions for system calls or
bindings to C libraries. My use case is very different, though. I intend to
build a "plugin" for a little program I'm making (actually in D, not C, but
can set C linkage for specific functions). I could of course call D code
from within a Larceny process, but that would change completely the
situation. What I need is to load code able to work on a data structure
originally created by the program I already have. That's why the original
control must rely on the D application side.

The only other way to make this work that I can think of is with
interprocess communication, so the self-contained Larceny program is able to
access the memory from that other program. On the D side, that could be
possible. Is Lacerny able to do that, defining the needed marshalling for
interpreting the raw data somehow?

Thanks again for your response.

Álvaro Castro-Castilla
-------------- next part --------------
HTML attachment scrubbed and removed