From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: jan Newsgroups: gmane.emacs.help Subject: Re: edebug question - context of calling function Date: 18 Oct 2003 12:59:41 -0700 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <0tWdnZ-zD5A5zBKiRTvUqg@texas.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066445531 12722 80.91.224.253 (18 Oct 2003 02:52:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2003 02:52:11 +0000 (UTC) Cc: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Oct 18 04:52:09 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAhCL-0002aR-00 for ; Sat, 18 Oct 2003 04:52:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAhA8-000719-HG for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Oct 2003 22:49:52 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AAh9w-00070s-Cl for help-gnu-emacs@gnu.org; Fri, 17 Oct 2003 22:49:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AAh9Q-0006ss-Br for help-gnu-emacs@gnu.org; Fri, 17 Oct 2003 22:49:39 -0400 Original-Received: from [210.50.30.52] (helo=smtp01.syd.iprimus.net.au) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAh9P-0006sb-UI for help-gnu-emacs@gnu.org; Fri, 17 Oct 2003 22:49:08 -0400 Original-Received: from ABE (210.50.171.38) by smtp01.syd.iprimus.net.au (7.0.020) id 3F8B009E0019D749; Sat, 18 Oct 2003 12:49:06 +1000 Original-To: "David Vanderschel" In-Reply-To: <0tWdnZ-zD5A5zBKiRTvUqg@texas.net> Original-Lines: 94 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:13321 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13321 "David Vanderschel" writes: > > > I sometimes put a source breakpoint in my code to catch a > > > particular error condition. When such a conditional breakpoint > > > fires, the actual problem, though recognized in the called > > > function, is often attributable to the calling function. What I > > > want to do then is to look around at the state of the calling > > > function at the time it called the function which invoked > > > edebug. I can instrument the calling function; but, when in the > > > debugger, I cannot see how to pop the context stack so that I > > > can look around at the variables in the calling program. What > > > am I missing? > > If I understand you correctly, you want to walk up the stack and > > look at the local variable in the functions along the way. I had a > > quick look and both edebug and the standard emacs debugger seem to > > be missing this feature. However, it may not be necessary because > > elisp is a dynamically scoped language, for example: > I think you do understand me correctly. Unfortunately, I often > reuse the same local variables (eg., i, j, x, ...). I'm guessing that i and j are iteration variables, and x is a position on an x-axis. If not, I think you need to use more descriptive variable names, and use dabbrev-expand (M-/) or hippie-expand to save yourself the extra typing. > I was also interested in the calling context in the sense of "Among > multiple possible invocations in the calling program, which > invocation of of the function which noticed the condition caused > this break." I guess you are correct that I have to move the logic > which catches the inconsistency up a level. But there is no one > nice place to put it for the bug I am chasing now. If you can reproduce the bug consistently, just use the backtrace to find out which function to move the breakpoint up into. Otherwise, if you're willing to recompile emacs then the following function combined with the backtrace should give you all the info you need to piece together what's happening. (defun edebug-symbol-values (symbol) "Display SYMBOL's values in the minibuffer. If interactive, prompt for SYMBOL. See `symbol-values' documentation for more details, including bugs and limitations." (interactive "SSymbol: ") (princ (symbol-values symbol))) (require 'edebug) (define-key edebug-mode-map "s" 'edebug-symbol-values) (define-key global-edebug-map "s" 'edebug-symbol-values) I had to drop into C to write symbol-values. I added it to ../emacs-21.2/src/data.c just after the definition for symbol-value. DEFUN ("symbol-values", Fsymbol_values, Ssymbol_values, 1, 1, 0, "Return SYMBOL's special binding stack as a list.\n\ The first value in the returned list is the current value.\n\ The last value in the returned list is the global value.\n\n\ Bugs:\n\ There is no way to distinguish a void value from the symbol `unbound'.\n\ Buffer-local, frame-local and terminal-local variables are ignored.") (symbol) Lisp_Object symbol; { Lisp_Object values = Qnil; struct specbinding *specpdl_iterator = specpdl; CHECK_SYMBOL (symbol, 0); for (;specpdl_iterator < specpdl_ptr; ++specpdl_iterator) { if (EQ (specpdl_iterator->symbol, symbol)) values = Fcons (specpdl_iterator->old_value, values); } return Fcons (XSYMBOL (symbol)->value, values); } And don't forget to register the function with defsubr, again I added it just after the symbol_value version. defsubr (&Ssymbol_values); -- jan