[Openmcl-devel] Darwin and shared libraries

[alex crain]

This is pretty long - sorry about that.

As an aside, how many people actually read this?

On Monday, April 1, 2002, at 09:30 PM, John DeSoi wrote:
> What kinds of library formats will work? Can Carbon shared libraries 
> that don't make any windowing or user interface calls be used? I have a 
> SQL database library I would like to use with OpenMCL.

I've really only been able to take a cursory look at MCL (I only 
discovered the code
three days ago) but it looks like a perfect starting point for something 
(I'm not sure
what, exactly, whatever). The logical place to start seems to be 
integration with
existing work, which means foreign functions.

ffigen is a good start, but what I really want is to be able to build 
atomic package
interfaces so that a developer can say (use-foreign-interface "X11") and 
get
everything in one shot. At a minimum that means:

   importing all the functions and symbols from libX11
   importing all the type definitions from X11.h and friends

and in a more perfect world, we would get a set of wrappers so that 
"standard" lisp
types would get translated into the appropriate C typed objects without 
requiring
the developer to explicitly cast everything.

My personal opinion is that the entire thing should be automagicly 
loaded into
a read-only package space that can be unloaded as a unit. This 
introduces some
cross linking issues between packages, though, since the packages arn't 
represented
in the original API designs in the foreign library.

That being said, the existing interface is, IMHO, incomplete. Problems I 
see are:

The packages themselves are designed and released independently of the 
MCL
interfaces, so the interfaces should be derivative products of the 
packages. It's
expected that some lisp might be required to augment a given package, 
but the
general procedure should be to distribute a makefile and some supporting 
code
to generate a finished package during the installation. Perl does a 
pretty good
job with this.

The lisp interface should be simple, and should not require any 
knowledge of the
underlying library structure.  This would increase portability across 
the architectures
and minimize programmer frustration.

The lisp API specification should be a direct derivative of the the 
original C API,
with as much type translation possible handled under the covers. It 
should still
be possible to gain low level access to the foreign interfaces for 
performance
reasons, but developers shouldn't have to worry about a crash because 
they
mis-cast an argument.

I don't want to sound like a winer (or a wiener) - Hats off to the team 
at clozure
for bringing home a great product. I'd like to see it get used and a 
good foreign
function interface would turn MCL into a general purpose progamming 
language
for UNIX and Macintosh, because we would get everything - your SQL 
library,
X11/Gtk and friends, the entire NextStep suite (under darwin), SSL, a 
full networking
interface, Imlib, and several hundred other packages for the price of a 
few makefiles
and the best part is that someone else maintains most of it.

> BTW, I have been working on a MCL port for UFFI, a package designed to 
> provide a single Lisp interface for foreign functions that will work 
> with almost any Lisp environment. See http://uffi.med-info.com/. I hope 
> to port this for OpenMCL once the shared library issues are resolved 
> for Darwin.

I'd really like to get a gcc based ffigen for Darwin - I'll be happy to 
write it if necessary
but I'd rather play with MCL internals then GCC internals (been there, 
done that).
Does it exist?


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel