[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress

From: Philipp Stephani
Subject: Re: Dynamic loading progress
Date: Mon, 28 Sep 2015 15:35:45 +0000

Aurélien Aptel <address@hidden> 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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]