From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: Problems with debug-on-entry in the Lisp debugger. Date: Mon, 07 Mar 2005 16:20:55 +0100 Message-ID: <876503wkh4.fsf@xs4all.nl> References: <87sm37n2bv.fsf@xs4all.nl> <87hdjnegak.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110210311 30690 80.91.229.2 (7 Mar 2005 15:45:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2005 15:45:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 07 16:45:11 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8KJU-0004vw-Av for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2005 16:38:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8KdG-0005Hc-T5 for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2005 10:58:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8KZy-0004AN-TF for emacs-devel@gnu.org; Mon, 07 Mar 2005 10:55:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8KZm-000493-Nb for emacs-devel@gnu.org; Mon, 07 Mar 2005 10:55:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8KZl-0003pF-6x for emacs-devel@gnu.org; Mon, 07 Mar 2005 10:55:21 -0500 Original-Received: from [194.109.24.26] (helo=smtp-vbr6.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D8K2X-0000UZ-08 for emacs-devel@gnu.org; Mon, 07 Mar 2005 10:21:01 -0500 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id j27FKueK063296; Mon, 7 Mar 2005 16:20:56 +0100 (CET) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1D8K2R-0004gs-00; Mon, 07 Mar 2005 16:20:55 +0100 Original-To: Stefan Monnier In-Reply-To: <87hdjnegak.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 07 Mar 2005 08:31:48 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 47 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34281 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34281 Stefan Monnier writes: >> I can think of two points in a macro to set a break for the >> debugger: just before macro expansion and just after it, right >> before the evaluation of the resulting sexp. In both cases, >> hiding the debug-on-entry code from the user of the debugger >> seems not possible. > > To me "entry of a macro" is very clearly "just before expansion". > Especially if you think of macro-expansion occurring because of > explicit calls to macroexpand (e.g. in the byte-compiler) rather > than as a direct part of interpretation. I see you implemented this. This makes debug-on-entry for macros a lot better, of course. Thanks. But the problem I mentioned remains: the debug-entry-code is visible. For example: (defmacro inc (var) (list 'setq var (list '1+ var))) (debug-on-entry 'inc) (progn (setq x 0) (inc x)) gives a backtrace like this: ------ Buffer: *Backtrace* ------ Debugger entered--entering a function: * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil (debug ...)) (list (quote setq) var (list ... var)))(x) (inc x) (progn (setq x 0) (inc x)) eval((progn (setq x 0) (inc x))) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ >> Shall I go ahead and try to implement this, or do people think this >> is a bad idea? > > I think it's a bad idea. The interpreter is already way too slow, > I'd rather not make it worse. I think the effect on performance will be very minimal. Do you know of a good way to test the performance of the interpreter so that I can measure the impact of my proposed change? Can you indicate how much performance loss would be acceptable for you? Lute.