Re: Dynamic loading progress

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

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

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> schrieb am Do., 24. Sep.
2015 um 14:45 Uhr:

> Some updates.
>
> I haven't made any progress on errors. I was reading on
> condition-case, setjmp/longjmp and how it's used for
> signaling/throwing. I actually knew very little about it. I shouldnt
> be the one writing this stuff I think... Anyway I was looking into how
> I would set up a "catch-all" wrapping code so that we can implement a
> funcall that always returns and I still haven't figured it out.


I have implemented this in a private fork:
https://github.com/phst/emacs-dynamic-module/commit/b14073ef8a522bdb90a8d7f0edc575edfd75da26
Note that code is only a suggestion how it could be implemented. It
deviates from Daniel's design by using return parameters instead of TLS,
but that's only a minor difference. The important part is the addition of
protected_call_n to eval.c.


> And realisticly if we
> want this in emacs 25 it's the only way (I don't feel confident enough
> to do that bit properly and I'm the only one working on this).


I feel relatively strongly about this, so I'd work on implementing this if
you'd like.


> We can
> always fix it afterwards or simply have a "safe" and an "unsafe"
> version of funcall in the API.


Going from the safe to the unsafe direction is easy if it's really
required, but going the other direction is hard. I'd suggest to only
implement the safe version for now and only add the unsafe version if
there's some data that shows it's required.


> I think changing the API in the early stage is fine and I don't worry
> too much about binary API changes because it's only going to be used
> with GPL plugins (i.e. modules can be fixed and recompiled, most of
> the time).
>
>
True, however once there's an API it's a good idea to keep it stable. I
expect people to start writing modules relatively soon once the interface
is available, so it's better to put a bit more effort into the interface.

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