From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Wed, 30 Sep 2015 11:32:50 -0600 Organization: XCP-1 Message-ID: <560C1CC2.10209@lanl.gov> 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> <22028.6378.473298.814646@turnbull.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443684769 22568 80.91.229.3 (1 Oct 2015 07:32:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 07:32:49 +0000 (UTC) Cc: Paul Eggert , Daniel Colascione , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?ISO-8859-1?Q?Aur=E9lien_Aptel?= , Tom Tromey , Stephen Leake To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 09:32:40 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 1ZhYM1-00080Z-94 for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 09:32:37 +0200 Original-Received: from localhost ([::1]:39832 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhYM0-0007yV-JV for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 03:32:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhLFc-0005xc-0J for emacs-devel@gnu.org; Wed, 30 Sep 2015 13:33:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhLFX-0004HN-Uq for emacs-devel@gnu.org; Wed, 30 Sep 2015 13:33:07 -0400 Original-Received: from proofpoint5.lanl.gov ([2001:400:4210:400::a5]:55656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhLFX-0004GH-MD for emacs-devel@gnu.org; Wed, 30 Sep 2015 13:33:03 -0400 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailgate5.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id t8UHWom4024582; Wed, 30 Sep 2015 11:32:50 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id A787FEC077E; Wed, 30 Sep 2015 11:32:50 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Original-Received: from xray-r08.lanl.gov (xray-r08.lanl.gov [128.165.123.189]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 82D3BEC0772; Wed, 30 Sep 2015 11:32:50 -0600 (MDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110717 Lanikai/3.1.11 In-Reply-To: <22028.6378.473298.814646@turnbull.sk.tsukuba.ac.jp> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-30_11:2015-09-30, 2015-09-30, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:400:4210:400::a5 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:190526 Archived-At: > So what's the advantage over unwind_to_catch as implemented? You > still need to put the barrier in place, only now you're using mixed > idioms (Lisp for the pitcher, C++ for the catcher). That kind of > thing always gives me hives. As I think I said, it lets you avoid reinstalling the handler every time you call into Emacs (and thus having to wrap every Emacs API function). > > But it's not ignore-errors: in my example, > > A-ah, that's *your* example. I was referring to what I believe Daniel > and Philipp want, which was the idea you pretty much dismissed as > "[too] inflexible": a handler hidden behind the API. (I'm still talking about my example here, but only because it serves to demonstrate what properties a hidden handler might have. Another implementation of hidden handlers could of course behave differently, but I haven't seen any particular implementation firmly chosen.) Even if the handler is hidden, the signal isn't swallowed (or even turned into a famously-easy-to-ignore return code): it's turned into an exception and thrown. It's up to the module code what to do about it, as always. My follow-on template-wrapper idea didn't squelch exceptions either, but turned them back into propagating Lisp signals after having run whatever C++ destructors. The inflexible part of the automatic/hidden handler, as I saw it, is that every entry point must perform the try/catch even if it has no destructors to run because Emacs will cause the exception to be thrown anytime control is within the module. It also prevents doing any preparatory work before installing the handler, or making a dynamic choice of handler -- but for neither of those do I have a use case at the moment. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.