Re: Dynamic loading progress

[Aurélien Aptel]

I wrote what we agreed on...

On Mon, Sep 28, 2015 at 5:01 AM, Stefan Monnier
<address@hidden> wrote:
> What means "implemented signal()"?  You mean, you export Fsignal to
> the modules?

yes

>> Except for signal() all error related functions are unimplemented
>> (they are not useful because funcall() doesn't return to module code
>> on error right now).
>
> I'm not sure what that means.  What other error-related functions?

Look at error_* function in the API (src/emacs_module.h [1]).
error_get() lets you get the signal symbol & data. error_check()
simply tells you if there was an error and error_clear() clears
current error. They will be implemented once we have a safe funcall.
The safe funcall() will have a catch-all condition-case and will set a
global error state than will be accessible via the API. (Daniel's
design)

> on error right now"?  What means "returns to module code"?

"Returns to module code" means when a function (funcall in this case)
exits normally via return (no longjmp). Since funcall() is called by
modules, when it returns it returns to module code. Hence "returns to
module code".

> Do you provide "cdr"?

no, not directly. You have to intern "cdr" and call funcall().

>  If so, what does it do when a module calls it on
> a string object?  I'd expect it to signal the error and longjmp to the
> nearest condition-case that catches it (presumably from outside of the
> module code, unless the module code setup condition_case as well).

Correct. condition-case is not part of the API though. Like for cdr
you have to intern "condition-case", setup the lisp forms as arguments
yourself and funcall() it. Haven't tested it yet.

> You're talking about how to get docstrings from the source code, but
> I think we should expect Emacs to need/fetch them during "load" at which
> point we'll be looking at the compiled code.  So the first question is
> where should those docstrings (regardless of whether they were found and
> prepared by make-docfile or by some new tool) be located?  Inside the
> .so file?  Is the source code which should be placed nearby?  In some
> kind of separate DOC file?

Like with my old module branch, I was thinking of having multiple DOC files.
When a module is built a DOC file is also generated from the source of
the module. When a module is loaded it looks for the module DOC file
and uses it. This involves changing the doc field of a symbol from int
to Lisp_Object that stores ("path/to/doc" . POSITION), iirc. See
previous discussions we had on this.

We can always do things differently, its not too late. The pro of
docfile is that you can also store the position of the definition in
the source code, which is always helpful.

> Even without a printer function, I think it makes sense at least to
> provide some kind of "type" information so that it's obvious when two
> "user objects" are "of the same type".  The method table can play the
> role of a "type".
>
> Also, it might make sense to let Emacs build this "method table" object.
> So instead of exposing an emacs_user_ptr_ops structure, export
> a function which creates a pointer to such an object.  This way the
> actual emacs_user_ptr_ops structure can more easily evolve, and Emacs
> can more easily fill the various slots with default values where

Good idea.

> applicable (e.g. one slot might point to the module that owns the object
> and might better be filled by the Emacs core than by the module itself).

Currently each instance of the emacs_env (the struct that holds
function pointers to the API that is created upon request from
modules) has a unique id used for module identification. That way the
module API implementation can know which module is using each API
function.

1: 
https://github.com/aaptel/emacs-dynamic-module/blob/dynamic-modules-2/src/emacs_module.h