From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 14 Sep 2015 16:27:22 +0900 Message-ID: <87a8spzcit.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87vbgpk1po.fsf@lifelogs.com> <85mw20gmeo.fsf@stephe-leake.org> <878u97nyjn.fsf@lifelogs.com> <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> <55F644F2.9040303@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1442215685 3590 80.91.229.3 (14 Sep 2015 07:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 07:28:05 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?utf-8?Q?Aur=C3=A9lien?= Aptel , Tom Tromey , Stephen Leake To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 09:27:54 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 1ZbOB3-0005Yk-0o for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 09:27:49 +0200 Original-Received: from localhost ([::1]:38828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbOAx-000125-DL for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 03:27:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbOAj-00011k-SC for emacs-devel@gnu.org; Mon, 14 Sep 2015 03:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbOAg-0005DE-K3 for emacs-devel@gnu.org; Mon, 14 Sep 2015 03:27:29 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:53655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbOAg-0005Ch-At for emacs-devel@gnu.org; Mon, 14 Sep 2015 03:27:26 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 41F171C38D7; Mon, 14 Sep 2015 16:27:23 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 13D8211EF83; Mon, 14 Sep 2015 16:27:23 +0900 (JST) In-Reply-To: <55F644F2.9040303@dancol.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:189917 Archived-At: Daniel Colascione writes: > On 09/13/2015 08:43 PM, Stephen J. Turnbull wrote: > > Daniel Colascione writes: > > > On 09/13/2015 01:31 PM, Stefan Monnier wrote: > > > > > >> It's not possible to skip frames in module code using longjmp, so > > > > > > > > Why not? > > > > > > Because most C code isn't expecting to be unwound. Forcing non-local > > > flow control on module code is completely unacceptable. > > > > "Completely unacceptable" is nonsense. Module code needs to be > > written the same way any other Emacs code is written, using various > > unwind-protect constructs. > > Why? There is no positive reason to make Emacs module code resemble > Emacs core code. Er, because it *is* Emacs code? If a function in a module simply wraps a library call, then you need to use that library's facilities to handle problems. But if it manipulates any Emacs data using Emacs APIs, you'll use Emacs facilities to handle all that ugly stuff like GC and Fsignal. > In fact, there's a strong reason to make Emacs module code more > conventional, because it'll improve the accessibility of the API, > which in turn will increase the quantity and quality of Emacs > modules. I think that's wishful thinking. In my experience with the XEmacs module code, what basically happens most of the time is that you write some Lisp to beat the data into the right structure, then you write a little bit of C to marshal Lisp primitive types into the underlying library's format, then you call the library API, and marshal the return into Lisp data types. Often it's more convenient to call the Lisp APIs from C than to return to Lisp and do it there, but it's equivalent. Sure, there's a lot of boring boilerplate, but it ain't rocket science by that very token. In the relatively rare case that you have a way of passing a callback into Lisp to the library, you either program very defensively in the Lisp, or just wrap the whole thing in a condition-case (such as ignore-errors) before passing it to the library. > The Emacs core code has a lot of baggage. It's not practical to > clean it up today, but the module system is a greenfield > project. There is no reason to burden it the same way. AFAICS, no, it's not a greenfield project. It's a second story on the same foundations. You're welcome to prove otherwise, but I don't have a clue how you propose to do it (without disallowing callbacks into Lisp entirely, and I don't see how you can enforce that without some very pervasive nannying code). > Can you name an extension system for any other program that > longjmps out of its public API functions? No, not with any confidence. XEmacs is the only program whose internal implementation of nonlocal exit I know well. But I would guess that if the language implements nonlocal exits, then any callback that can be an arbitrary function in the language can longjmp.