liberte@uiucdcsb.cs.uiuc.edu (11/18/87)
The debugger is certainly better than nothing, but it could be better. Some problems: If you have more than two windows up, the debugger pops up in a different window each single step. It should use the same window. If you start debugging with your on-line source in the wrong place and you go and find the right place, and then you continue the debugger, it does you the favor of returning the screen to the old set up. What is needed is two window configurations - one is the original, before debugging is activated, and the other is whatever the user changes it to before continuing the debugger. Then there should be two ways to quit the debugger, one for each window configuration. Is anyone working on a source-level debugger that allows the user to single step through source rather than tip-toe through the tulips, so to speak? That is one Gosling Emacs feature I miss. Dan LaLiberte liberte@a.cs.uiuc.edu uiucdcs!liberte
drw@culdev1.UUCP (Dale Worley) (11/18/87)
conor@goose.UUCP (Conor Rafferty) writes: | If I set a debug-on-entry point, jump into the subroutine, and type | a few d's, I end up with the following "stack trace" which is | gibberish to me. Is this the best I can expect? | | Entering: | * debug(exit "Entering debugger...") | * message("Entering debugger...") | * byte-code("\316\317!\210\303\320 ^K^K\321\322!\303^^^F^]^\^Z^Y^X\323\216\212\324\213))\210^N^F\211^V A few points: You can't debug anything if it is compiled into byte code. You can get around this if you find-file the source file for the function you are interested in, and re-execute the defun that defines the function (use eval-defun). The "c" command means "continue on". The only thing that will stop execution (other than explicitly set breaks) is returning from stack frames marked with a "*" in the Backtrace buffer. This is best used for "stepping over" the execution of a function. The "d" command means "break on entry to next function". This should only be used if you have stopped execution at exit from a function. If you have code that looks like: (function arg arg) (function2 arg arg) Then the sequence of events is: 1. starting with being stopped at entry to function, type c 2. stops at exit from function, type d 3. stops at entry to function2, type c 4. stops at exit from function2. Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw If you get fed twice a day, how bad can life be?
rlk@think.COM (Robert Krawitz) (11/18/87)
In article <1759@culdev1.UUCP> drw@culdev1.UUCP (Dale Worley) writes:
]
]You can't debug anything if it is compiled into byte code. You can
]get around this if you find-file the source file for the function you
]are interested in, and re-execute the defun that defines the function
](use eval-defun).
This isn't true. You can debug byte-compiled functions, it's just
that they won't be quite so legible (the lexical structure of the
program might not be perfectly preserved). The one thing you can't do
is debug subr's (Lisp functions hardcoded in C).
The V17 debugger sometimes had problems if you typed 'd' when there
were no more calls to make; in that case, it tried to debug the calls
to debug, leading to considerable confusion. The V18 debugger lets
you debug by continuously typing 'd'.
cca >>>>>>>>>> |
harvard >>>>>> |
bloom-beacon > |think!rlk Robert Krawitz <rlk@think.com>
rutgers >>>>>> |
ihnp4 >>>>>>>> .