[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic loading progress
From: |
Stephen Leake |
Subject: |
Re: Dynamic loading progress |
Date: |
Sat, 14 Feb 2015 19:02:48 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) |
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
- Re: Dynamic loading progress, (continued)
- Re: Dynamic loading progress, joakim, 2015/02/15
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/15
- Re: Dynamic loading progress, joakim, 2015/02/16
- Re: Dynamic loading progress, Stephen Leake, 2015/02/14
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/13
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/14
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/14
- Re: Dynamic loading progress,
Stephen Leake <=
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/15
- Re: Dynamic loading progress, Stephen Leake, 2015/02/15
- implementing curl module with opaque emacs types, Stephen Leake, 2015/02/15
- Re: implementing curl module with opaque emacs types, Eli Zaretskii, 2015/02/15
- Re: implementing curl module with opaque emacs types, Stephen Leake, 2015/02/17
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/15
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/15
- Re: Dynamic loading progress, Stephen Leake, 2015/02/16
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/16
- Re: Dynamic loading progress, Stephen J. Turnbull, 2015/02/15