From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 14 Sep 2015 09:45:41 -0500 Message-ID: <86zj0p3vqi.fsf@stephe-leake.org> References: <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> <87a8spzcit.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442248230 21367 80.91.229.3 (14 Sep 2015 16:30:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 16:30:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 18:30:20 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 1ZbWe3-0000Uj-Sw for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 18:30:20 +0200 Original-Received: from localhost ([::1]:41938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbWe3-0003sr-Cv for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 12:30:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbV1B-0003oh-LS for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbV15-0001B9-PE for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:46:05 -0400 Original-Received: from gproxy10-pub.mail.unifiedlayer.com ([69.89.20.226]:33575) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZbV15-0001A9-Hc for emacs-devel@gnu.org; Mon, 14 Sep 2015 10:45:59 -0400 Original-Received: (qmail 15318 invoked by uid 0); 14 Sep 2015 14:45:54 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 14 Sep 2015 14:45:54 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id H2lm1r02H2UdiVW012lpQd; Mon, 14 Sep 2015 08:45:54 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=ff-B7xzCdYMA:10 a=Wn2H3lT2AAAA:8 a=5VgxRhkzk3_HvQKEwbMA:9 Original-Received: from [76.218.37.33] (port=51758 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZbV0s-0000Em-JW for emacs-devel@gnu.org; Mon, 14 Sep 2015 08:45:46 -0600 In-Reply-To: <87a8spzcit.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 14 Sep 2015 16:27:22 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.20.226 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:189949 Archived-At: "Stephen J. Turnbull" writes: > 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? That was my initial view as well, because I new I needed fast performance for my particular use case. But I suspect some (most?) modules will be added just to provide a lisp interface to some external library; the authors will see that as part of their lisp code, not part of Emacs core. One reason Emacs succeeds is because lisp is so forgiving; module developers will expect the Emacs module API to be similarly forgiving. I don't think we need to accept that as a hard requirement, but anything we can do towards that goal that has reasonable performance penalties could be a win. > > 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. I see that as "conventional code"; you certainly didn't mention callbacks and longjmp here. > 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, Always a good idea anyway, at least until thorough testing is done. > or just wrap the whole thing in a condition-case (such as > ignore-errors) before passing it to the library. What is the downside of having the Emacs module API do that for you? -- -- Stephe