From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Reporting Lisp errors in dynamic modules Date: Fri, 27 Nov 2015 16:40:23 +0000 Message-ID: References: <83egfbsnu2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114450c8a38a2305258859e7 X-Trace: ger.gmane.org 1448642450 28295 80.91.229.3 (27 Nov 2015 16:40:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 16:40:50 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, dancol@dancol.org To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 27 17:40:41 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 1a2M4f-0000FX-0c for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 17:40:41 +0100 Original-Received: from localhost ([::1]:57517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2M4h-0007Hu-Qq for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 11:40:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2M4b-0007Gx-7v for emacs-devel@gnu.org; Fri, 27 Nov 2015 11:40:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2M4a-0004NH-6G for emacs-devel@gnu.org; Fri, 27 Nov 2015 11:40:37 -0500 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2M4X-0004Ms-S7; Fri, 27 Nov 2015 11:40:34 -0500 Original-Received: by wmec201 with SMTP id c201so64639187wme.1; Fri, 27 Nov 2015 08:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Z3GQoWPBi4QgrWRRpJF9/1oJ2c/J5otfjcesMcpNIOs=; b=VGim9vmPeRFFAJhamIQHis+0zvDSeSlVkdA3dOQUwD039n7Mz2NHzgW5nJJfoQ7yAv sepd9ltTNEGXRcvlzsC8rjAvVcGdv53utAmdnMceTSx73fgqEDHVtdyrvzquIMDIbY3k Fl/PAEXwMMNK0TV83B1q6GJ7XMioFl13JZ6eP1rnYk6xCBIwUxFhaksWM88Z3Teu2Pyx Rr05BhEuju6iL5q8pb2nosDvYPMOk19Nhq9J9GmpY8qtiBLUBYpPmXao0l5jnIPrI4nv dOjPsH6cf+K+nhBjyaMmPue3cfTv34YvPGDy3YwmXGcyxNpTdv33taZat1j8v4Nye/tr QeEQ== X-Received: by 10.28.7.8 with SMTP id 8mr11154830wmh.45.1448642433221; Fri, 27 Nov 2015 08:40:33 -0800 (PST) In-Reply-To: <83egfbsnu2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22f 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:195384 Archived-At: --001a114450c8a38a2305258859e7 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Fr., 27. Nov. 2015 um 12:07 Uhr: > With the latest emacs-25 branch, load modules/mod-test/mod-test.so, > then evaluate '(mod-test-sum "1" 2)'. The backtrace that pops up is > this: > > Debugger entered--Lisp error: (wrong-type-argument integerp "1") > #(# > > ("1" 2)) > mod-test-sum("1" 2) > eval((mod-test-sum "1" 2) 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) > > I believe the line with "" is suboptimal, in that it > looks alien and includes all kinds of unneeded and weirdly formatted > data. AFAIU, the reason is that we deliberately unintern module-call. > Should we perhaps reconsider that decision, so that the backtrace is > in more familiar form? What exactly are the dangers of having > module-call exposed as any other primitive? > - Somebody calls it with the wrong type. Right now it doesn't do any type checking, so that would crash/be UB. - An existing function outside of Emacs might already be called like that. Those are really minor issues, but since module-call is unusable from Lisp or module code anyway, I've decided to avoid them by uninterning it. If type checking is added and the name clash issue is consider minor, interning it is fine. A cleaner approach would be to define module functions as separate kind of function object. I think right now we have lists (Lisp closures and lambdas), subrs, and bytecode objects, module functions could be a fourth type. But that would require more thorough changes. --001a114450c8a38a2305258859e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Fr., 27. Nov. 2015 um 12:07=C2=A0Uhr:
With the latest emacs-25 branch, load modules/mod-test/mod-test.so,
then evaluate '(mod-test-sum "1" 2)'.=C2=A0 The backtrace= that pops up is
this:

=C2=A0 Debugger entered--Lisp error: (wrong-type-argument integerp "1&= quot;)
=C2=A0 =C2=A0 #<subr module-call>(#<save-value <pointer 00fdab9= 0> <unused> <unused> <unused>> ("1" 2)) =C2=A0 =C2=A0 mod-test-sum("1" 2)
=C2=A0 =C2=A0 eval((mod-test-sum "1" 2) nil)
=C2=A0 =C2=A0 elisp--eval-last-sexp(nil)
=C2=A0 =C2=A0 eval-last-sexp(nil)
=C2=A0 =C2=A0 funcall-interactively(eval-last-sexp nil)
=C2=A0 =C2=A0 call-interactively(eval-last-sexp nil nil)
=C2=A0 =C2=A0 command-execute(eval-last-sexp)

I believe the line with "<subr module-call>" is suboptimal,= in that it
looks alien and includes all kinds of unneeded and weirdly formatted
data.=C2=A0 AFAIU, the reason is that we deliberately unintern module-call.=
Should we perhaps reconsider that decision, so that the backtrace is
in more familiar form?=C2=A0 What exactly are the dangers of having
module-call exposed as any other primitive?

=
- Somebody calls it with the wrong type. Right now it doesn't do a= ny type checking, so that would crash/be UB.
- An existing functi= on outside of Emacs might already be called like that.

=
Those are really minor issues, but since module-call is unusable from = Lisp or module code anyway, I've decided to avoid them by uninterning i= t. If type checking is added and the name clash issue is consider minor, in= terning it is fine.

A cleaner approach would be to= define module functions as separate kind of function object. I think right= now we have lists (Lisp closures and lambdas), subrs, and bytecode objects= , module functions could be a fourth type. But that would require more thor= ough changes.
--001a114450c8a38a2305258859e7--