Re: Dynamic loading progress

[Daniel Colascione]

On 02/13/2015 08:55 AM, Eli Zaretskii wrote:
>> Date: Fri, 13 Feb 2015 08:20:09 -0800
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden, address@hidden
>>
>>> Sorry, I don't share your optimism about the stability of their ABI.
>>
>> My optimism is rooted in reality.
> 
> So is mine.  I guess our experiences differ.
> 
>> w32-win.el isn't that bad, especially for a module that loads quite a
>> few different image libraries.
> 
> It's not bad when you get it ready.  But the effort it took to find
> out which versions changed ABI, to design the way of testing that, and
> to have all the #ifdef's in Emacs core to support all of those
> versions, and continue maintaining that as new versions arrive, is
> anything but trivial, take it from someone who did most of that.
> 
>> Besides: using modules tightly coupled to the Emacs core doesn't
>> actually help. Instead of elisp coupled to one module's stable ABI, you
>> have a piece of native code tightly coupled not only to that module's
>> stable ABI, but _also_ to the volatile Emacs internal ABI. As jwz would
>> say, now you have two problems.
> 
> No, we have only one problem: design and implement a minimal set of
> APIs necessary for modules to work, and keep it minimal.  All the rest
> is the problem of module developers.

Well, at least the proposed module design should allow the creation of a
CFFI interface _on top_ of it --- a bit like how we can use Java's JNI
to implement JNA.

By the way: Java does it the proposed Emacs way (via JNI), and the CLR
does it the way I propose (via P/Invoke). In my experience,
P/Invoke-using modules have been far less painful to use and maintain
than JNI-using ones.

Speaking of JNI: if you insist on tightly coupling modules to the Emacs
core, it's better to use a versioned system like JNI than to just
dynamically export symbols from the Emacs core. This way, module A can
request interface version 1 and module B can request interface version
2, and as long as a particular Emacs supports both interfaces 1 and 2,
you can load both modules into the same Emacs without trouble and
without rebuilding anything.

> It makes little sense to me to turn the table and make module
> compatibility something that core developers need to take care of.

With the proposed design, core developers have to take pains to make
Emacs itself export a stable ABI. With a CFFI-style interface, Emacs
doesn't have to maintain a stable ABI at all. To me, that sounds like
making life for core developers easier.

>>> And we didn't yet start talking about problems with passing FILE
>>> pointers and malloc'ed buffers between Emacs and the modules.
>>
>> You have that problem anyway: a tightly-bound Emacs module for bridging
>> the Emacs core and some third-party library would have to link against
>> _some_ libc, and unless both the Emacs core and the third-party library
>> used the same libc, you'd lose.
> 
> A well-designed set of APIs between Emacs and modules will avoid this
> and other similar problems.  This has already been done at least
> twice, in 2 different ways: in Make and in Gawk.  I see no reason why
> Emacs couldn't do something similar to one of those methods.

Woah. I had no idea that make supported loading dynamic objects.

signature.asc
Description: OpenPGP digital signature