Re: edebug question - context of calling function

[jan]

"David Vanderschel" <DJV1@Austin.RR.com> 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