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 modules: emacs-module.c and signaling errors Date: Fri, 27 Nov 2015 11:29:31 -0500 Message-ID: References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com> <83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu> <87si3vox7j.fsf@tromey.com> <56555B52.3030703@cs.ucla.edu> <837fl6xa02.fsf@gnu.org> <5655F10D.9080805@cs.ucla.edu> <83vb8ovkc5.fsf@gnu.org> <83a8q0vgb9.fsf@gnu.org> <83si3stuzn.fsf@gnu.org> <83poywtsxl.fsf@gnu.org> <838u5ju9tu.fsf@gnu.org> <8337vrsae8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448641813 18694 80.91.229.3 (27 Nov 2015 16:30:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 16:30:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 27 17:29:56 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 1a2LuD-0004JM-8Y for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 17:29:53 +0100 Original-Received: from localhost ([::1]:57424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2LuF-00040g-Qm for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 11:29:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Ltz-00040a-6G for emacs-devel@gnu.org; Fri, 27 Nov 2015 11:29:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2Lty-000119-Bm for emacs-devel@gnu.org; Fri, 27 Nov 2015 11:29:39 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Lts-0000zR-PO; Fri, 27 Nov 2015 11:29:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AsEwA731xV/yr292hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwEnLyMFCws0EhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYwwqFQjgWaCMCCCeAEBAQ X-IPAS-Result: A0AsEwA731xV/yr292hcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwEnLyMFCws0EhQYDSSINwjPIwEBAQEGAQEBAR6LOoUFB4QtBYwwqFQjgWaCMCCCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="179567260" Original-Received: from 104-247-246-42.cpe.teksavvy.com (HELO pastel.home) ([104.247.246.42]) by ironport2-out.teksavvy.com with ESMTP; 27 Nov 2015 11:29:31 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 368A563F7A; Fri, 27 Nov 2015 11:29:31 -0500 (EST) In-Reply-To: <8337vrsae8.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Nov 2015 17:57:19 +0200") 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:195383 Archived-At: >> So you're saying that if I call a command which internally calls >> a C module function which turn does "env->funcall" on some Elisp code >> which then signals an error, I'll be throw into the *Backtrace* buffer >> (after setting debug-on-error and not debug-on-signal) right at the >> point where the error is really signaled (i.e. before returning to the >> module's C code), and not later on when it is rethrown by the module >> code? > Yes: > emacs -Q > M-x load-file RET modules/mod-test/mod-test.dll > M-: (mod-test-string-a-to-b (string-match "a" nil) "b") RET > => > Debugger entered--Lisp error: (wrong-type-argument stringp nil) > string-match("a" nil) > (mod-test-string-a-to-b (string-match "a" nil) "b") > eval((mod-test-string-a-to-b (string-match "a" nil) "b") nil) > elisp--eval-last-sexp(nil) > eval-last-sexp(nil) > funcall-interactively(eval-last-sexp nil) > call-interactively(eval-last-sexp nil nil) > command-execute(eval-last-sexp) Hmm... that's not the case I'm talking about: here the string-match is called before even entering the module's code, so the module code is not involved at all. >> >> The core provides naturally a plain raw non-catching funcall, but with >> >> the current design a module author who wants this behavior can't have it >> > Why would a module author want a non-catching funcall? >> Why not? > Sorry, "why not" is not an answer. Given then 271-vs-15 rather of non-catching funcalls vs catching funcalls in Emacs's C code, I think it's pretty clear that it can be very useful. So really the question is the other way around: what makes you think that the modules's code will be so vastly different that it won't want a non-catching funcall, contrary to the experience so far? Stefan