[Openmcl-devel] Darwin and shared libraries
alex at widgetworks.com
Mon Apr 1 23:11:03 EST 2002
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
existing work, which means foreign functions.
ffigen is a good start, but what I really want is to be able to build
interfaces so that a developer can say (use-foreign-interface "X11") and
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
types would get translated into the appropriate C typed objects without
the developer to explicitly cast everything.
My personal opinion is that the entire thing should be automagicly
a read-only package space that can be unloaded as a unit. This
cross linking issues between packages, though, since the packages arn't
in the original API designs in the foreign library.
That being said, the existing interface is, IMHO, incomplete. Problems I
The packages themselves are designed and released independently of the
interfaces, so the interfaces should be derivative products of the
expected that some lisp might be required to augment a given package,
general procedure should be to distribute a makefile and some supporting
to generate a finished package during the installation. Perl does a
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
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
be possible to gain low level access to the foreign interfaces for
reasons, but developers shouldn't have to worry about a crash because
mis-cast an argument.
I don't want to sound like a winer (or a wiener) - Hats off to the team
for bringing home a great product. I'd like to see it get used and a
function interface would turn MCL into a general purpose progamming
for UNIX and Macintosh, because we would get everything - your SQL
X11/Gtk and friends, the entire NextStep suite (under darwin), SSL, a
interface, Imlib, and several hundred other packages for the price of a
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,
Does it exist?
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel