Re: Dynamic loading progress

[Stephen Leake]

Eli Zaretskii <address@hidden> writes:

>> From: Stefan Monnier <address@hidden>
>> Date: Fri, 13 Feb 2015 14:11:33 -0500
>> Cc: Paul Eggert <address@hidden>, address@hidden
>>
>> > I would start by coming up with the minimum set of requirements a
>> > module needs to be able to communicate with Emacs.
>>
>> Easy: take the existing sample modules and see what they need.
>
> No one seems to care, so I will bite the bullet.

I took a stab at creating emacs_module_api.h; attached.

To do this, I replaced "#include <lisp.h>"
in modules/curl/curl.c with "#include <emacs_modules_api.h>", and copied
stuff from lisp.h and other headers to emacs_module_api.h until it
compiled. Note the FIXMEs; I could not figure out what was going on in
some places, so I just kludged it for now.

I don't know if this is useful, but it is my interpretation of what
Stefan proposed; lisp.h would "#include emacs_modules_api.h". (He called
it "emacs.h", but I think including 'modules' in the name is better).

> The below is based
> on looking at the modules branch.
>
> It looks like modules need:
>
>  . A function to replace the DEFUN macro and the related defsubr call.
>
>  . Some definition of Lisp_Object
>
>    This already presents at least 2 problems.  The first is 32- vs
>    64-bit issues.  We need some way of checking that a 32-bit module
>    isn't loaded by a 64-bit Emacs, and vice versa.

Good point. That's a special case of "don't load a module compiled for
processor X in an Emacs compiled for processor Y". gnu binutils has
facilities for that.

>    The other problem is more serious: Emacs can be built with or
>    without --check-lisp-object-type, and with or without --wide-int;
>    how will the module know which implementation to use?

Similar check when the module is loaded. Which means we need some
metainfo for each module, and a standard function to retrieve it.

>  . Functions to access values of Lisp objects.  We shouldn't rely on C
>    macros like XINT and XWINDOW for that, because macros track too
>    closely the internals of each object.  So I propose to use
>    functions that will be exposed via the API.

If we follow Stefan's suggestion, then either this function approach is
not viable, or we need another #ifdef for module vs emacs.

> The above means that most of the C source files under modules/ should
> be thoroughly rewritten.

Yes.

> They are currently written as if the code were an integral part of
> Emacs on one of the Emacs C files. Going that way means that modules
> will have to be recompiled from sources for each Emacs version, and
> practically will have to live in the Emacs tree. Maybe this is what we
> want, I don't know.

This is the model I had in mind. Since I need max speed with mixed
Ada/lisp code, I need tight integration with the core. The people who
need that speed for Ada mode will simply have to recompile the module
for each Emacs release; they are coders, so that's not a problem.

On the other hand, modules for other use cases (I have in mind a spam
filter for Gnus) would not need to be nearly so tightly bound, so a more
limited/safe API would be appropriate.


Rather than splitting out emacs_module_api.h from lisp.h, we could add
__declspec(dllexport) to a subset of the functions in lisp.h; I suspect
that will be a small number. I'll give that a try next.

Is there an equivalent on Linux (I don't recall ever seeing one)?

--
-- Stephe

emacs_modules_api.h
Description: Binary data