From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 04 Oct 2015 13:24:23 -0400 Message-ID: References: <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> <22025.61338.681227.470671@turnbull.sk.tsukuba.ac.jp> <560AFCE3.8090802@lanl.gov> <22027.31797.6292.498407@turnbull.sk.tsukuba.ac.jp> <560B8EB9.8030801@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443979484 5171 80.91.229.3 (4 Oct 2015 17:24:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 17:24:44 +0000 (UTC) Cc: Paul Eggert , Tom Tromey , Emacs development discussions , =?windows-1252?Q?Aur=E9lien?= Aptel , "Stephen J. Turnbull" , Daniel Colascione , Stephen Leake To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 19:24:34 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zin1V-0005Gr-Fz for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 19:24:33 +0200 Original-Received: from localhost ([::1]:43169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zin1U-0005eZ-M4 for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 13:24:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zin1Q-0005eI-LH for emacs-devel@gnu.org; Sun, 04 Oct 2015 13:24:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zin1N-0000QH-Gq for emacs-devel@gnu.org; Sun, 04 Oct 2015 13:24:28 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zin1N-0000Q8-AG for emacs-devel@gnu.org; Sun, 04 Oct 2015 13:24:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CjDQA731xV/3aQs2tcgxBUXoJQwRWBLiIKhXEEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAQIBAQJTIwULCw4mEhQUBA0kiDcIDc8WAQEBAQEBBAEBAQEaBIs6hQUHhC0FlyGEGplJI4Fmgi4iMQGCRgEBAQ X-IPAS-Result: A0CjDQA731xV/3aQs2tcgxBUXoJQwRWBLiIKhXEEAgKBPDsSAQEBAQEBAYEKQQWDXQEBAQIBAQJTIwULCw4mEhQUBA0kiDcIDc8WAQEBAQEBBAEBAQEaBIs6hQUHhC0FlyGEGplJI4Fmgi4iMQGCRgEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="167392679" Original-Received: from 107-179-144-118.cpe.teksavvy.com (HELO pastel.home) ([107.179.144.118]) by ironport2-out.teksavvy.com with ESMTP; 04 Oct 2015 13:24:24 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 05AB76175A; Sun, 4 Oct 2015 13:24:23 -0400 (EDT) In-Reply-To: (Philipp Stephani's message of "Sun, 04 Oct 2015 08:34:34 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190892 Archived-At: > True, and I think nobody expects otherwise. However, as with other > interfaces, the Emacs module interface should use not all of C, but the > intersection of C and C++ (which is pretty large compared to full C). That would be desirable, but less so than the fact that the API just exposes the functionality provided by Emacs's core code. So as long as Emacs's signaling facility uses longjmp, that's going to be exposed in the core API. >> - do a minimalist binding which keeps using naked longjmp, and just >> let the C++ code use explicit internal_condition_case wrappers where >> it thinks it's needed. > This is currently impossible because the necessary code is not available to > module authors (and partially does not even exist, as in the case of catch). Irrelevant detail: we're talking about design of some upcoming API, which will require coding. Some of that coding may involve writing new core code, of course. Of course, by that measure, some of that coding could involve replacing longjmp with some other mechanism. My gut feeling is that this would be a very large undertaking and that the result would probably not be palatable to the vast majority of Emacs's C contributors, so I won't hold my breath. > Daniel has designed a great API in > https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00960.html. Let's > just implement this API as designed and check later if there's any need for > the other options. If you want: Modules can call Lisp functions using `funcall', which does the obvious thing. If Lisp signals or throws, `funcall' returns NULL. that's OK, but it should then be called `safe_funcall', and we should provide another `funcall' which does not catch the error. And if `safe_funcall' cannot be defined "by hand" in a module using other API methods, that would mean that the API is still lacking functionality (e.e. lacking condition_case and things like that). You're not going to convince me otherwise. Stefan