Subject: [clisp-list] DEF-LIB-CALL-OUT and dynamic FFI & library by name

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Apr 24 07:56:04 2002

Sam Steingold wrote:
> Similarly, I want DEF-CALL-OUT with many options, some of which may be
> required, instead of DEF-C-CALL-OUT, DEF-LIB-CALL-OUT,
> DEF-LIB-C-CALL-OUT, DEF-LIB-STDCALL-CALL-OUT &c.

Can you live with
(DEF-CALL-OUT FOO
  (:name "compress")
  (:library *zlib*) ; This and only this option gets evaluated...
  (:return-type ...))
I can come up with that (implementing *FOREIGN-LIBRARIES* list, somewhat different from the list the Amiga has) in the future. Then the library name can be a string (nickname), like with Amiga's DEF-LIB-CALL-OUT. With strings, nobody will care whether this is evaluated or not.
It's more work. This is not ready yet.

> I thought that the DLL FFI will make the current module facility DLL
> based too, i.e., while now modules create their own lisp.run by linking
> lisp.a with their *.o files, the new modules will compile to *.so
> (*.dll) and load them from the lisp code.
This might work on UNIX only.

I believe that what you describe is already there for UNIX systems: SYS::DYNLOAD-MODULES is in pathname.d. It's not documented for whatever reason.

On other systems, a .dll is its own binary, may have an own process space and whatever. It is not an incomplete object which needs to be linked against something to come to life. It's not an .so.

Modules are a portable way to write extensions to CLISP in C. It works on any platform which can build CLISP.
Building a .so or .dll is not portable. The C code becomes cluttered with lots of [WINAPI] __export _SYSCALL _CDECL I don't know about. It might not be available on any platform that CLISP supports.

Current modules are as distinct from shared libraries as libtool modules from shared libraries. Like CLISP modules, they have a special structure and some special identifiers not found in any other arbitrary .so.

There are other differences.
Module's functions are reactivated when a Lisp session is resumed. FFI objects are dead.
Modules can access Lisp objects. The FFI cannot.
Modules present an API based on CLISP's "object model", shared libraries one based on the C model.

Could you describe how regexp could be turned into a .so on UNIX? Maybe the UNIX link-kit script could provide the choice to create an .so instead of a .o?
Probably somebody there has already done that? E.g. whoever wrote dynload-modules (Eric Marsden?)

Is there a ready-made regexp.so found on e.g. Linux distributions? (Isn't regexp part of the Linux libc.a?)

> is this the only place where #+CYGWIN is useful?
> then it's not worth it!
I have no opinion on that.

I realized UFFI has an interesting FIND-FOREIGN-LIBRARY which might work in all cases:
http://uffi.med-info.com/manual/r1520.htm
I believe it will look for a mix of a given set of names (e.g. "zlib" "cygz" "libz") and a given set of types (e.g. "so" "dll") and take the first it finds.

Today, I recommended something like this on the UFFI mailing list:
(defvar uffi::*default-lib-types*
 '( #+(and CLISP WIN32) "dll"
    #+(and CLISP UNIX) "so"
    #+(and CLISP UNIX) "dll" ; for cygwin
    #+(and CLISP UNIX) xyz ; for HP-UX
    ... for whatever 30 systems CLISP runs on.
    #+(and CLISP AMIGA) "library"
))

> I abhor the "many names" approach.
I tend to dislike too much polymorphism as exhibited in UNIX' ioctl() or setsockopt(). Some people find it cool that open/close/read/write/ioctl is all you need on UNIX. I don't. It is appealing, though.

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Wed Apr 24 08:24:06 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] DEF-LIB-CALL-OUT and dynamic FFI & library by name"
> * Sent on Wed, 24 Apr 2002 16:55:20 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> Sam Steingold wrote:

looks good; that's what we have now.

> Could you describe how regexp could be turned into a .so on UNIX?
> Maybe the UNIX link-kit script could provide the choice to create an
> .so instead of a .o?  Probably somebody there has already done that?

regexp is a part of the POSIX standard and thus must be present in
every libc.

> (Isn't regexp part of the Linux libc.a?)

yes, regexp is in glibc.
this brings this to mind - did you submit your regex.c patch to the
glibc people?  I want to use the glibc regex.c in clisp, dumping the
8-years old version we have right now for the brand new glibc 2.5 one.
You needed some changes, and, since, I do not want to maintain a fork,
I asked you to get the patch into the main glibc distribution.

> I tend to dislike too much polymorphism as exhibited in UNIX' ioctl()
> or setsockopt(). Some people find it cool that
> open/close/read/write/ioctl is all you need on UNIX. I don't. It is
> appealing, though.

this is Lisp, not C!
Look at DEFSTRUCT and DEFCLASS!
Adding a new option is less stress than adding a new call, so, for the
benefit of future modifications, _please_ keep the number of calls you
define to a minimum and move everything to arguments (like we talked
about REGISTER-FOREIGN -VARIABLE/-FUNCTION - this should be _one_ call).

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
"Syntactic sugar causes cancer of the semicolon."	-Alan Perlis