Re: Dynamic loading progress

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> schrieb am Do., 15. Okt.
2015 um 01:32 Uhr:

> Your approach is interesting but it currently works as-is for 64bits
> platforms and 32bits platform without wide-int and can be fixed later
> without breaking the API, if I understand correctly.
>

I would be more worried about representation of nullptr. With casting
nullptr can stand for a valid Lisp value, so that it's not possible to
return invalid values, which is visible to the user.


> * Loading
>
> I know that on OSX there's both ".dyn" and ".so" but I don't know much
> about it. Is supporting both worth it?
>

According to http://stackoverflow.com/a/2339910/178761 there are two types:
bundles and dynamic libraries. The differences were bigger in the past
(only bundles could be loaded dynamically), but now they are mostly
equivalent. Apparently .so and .bundle are usually used for bundles and
.dylib for dynamic libraries, but e.g. your example modules compile as
dynamic libraries with an .so extension and Emacs is totally happy. So
supporting .so should be enough.


>
> Couldn't we simply pick an extension like ".edm" (emacs dynamic
> module) and rename the generated lib on each system when a module is
> built?
>

I'd prefer using the conventional extensions. A custom extension might
confuse users and clash with existing meanings of that extension.


>
> * Doc strings
>
> If we use the doxygen syntax, it won't follow the various elisp
> conventions (args in caps, first line must be descriptive, etc).
> Jumping to definition is also pretty convenient, should we keep that
> feature for modules? Also how should we load the docstrings
> themselves?
>
>
Can't modules already run the equivalent of

(put 'module-func 'function-documentation "docstring")

? With that the basics should already be there.


> * Packaging
>
> We need to extend the spec of ELisp packages to take into account
> modules. The way I see it a module will have a "core" source file in C
> (or something else) and a bunch of helpers implemented in elisp on top
> that expose the package features in a more user-friendly way.
>

That is one option, but modules consisting entirely of non-Elisp files are
also to be expected, given that the module API is as powerful as Elisp.

[-- Attachment #2: Type: text/html, Size: 3421 bytes --]