Return to ch15.n CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps2 / 09.lisp

Annotation of 43BSDReno/share/doc/ps2/09.lisp/ch15.n, revision 1.1

1.1     ! root        1: .\" Copyright (c) 1980 Regents of the University of California.
        !             2: .\" All rights reserved.  The Berkeley software License Agreement
        !             3: .\" specifies the terms and conditions for redistribution.
        !             4: .\"
        !             5: .\"    @(#)ch15.n      6.2 (Berkeley) 5/14/86
        !             6: .\"
        !             7: ." $Header: /na/franz/doc/RCS/ch15.n,v 1.1 83/01/31 07:08:47 jkf Exp $
        !             8: .Lc The\ FIXIT\ Debugger 15
        !             9: .sh 2 Introduction \n(ch 1
        !            10: FIXIT is a debugging environment for
        !            11: .Fr
        !            12: users doing program development.  This documentation and FIXIT
        !            13: were written by David S. Touretzky
        !            14: of Carnegie-Mellon University for MACLisp, and adapted to
        !            15: .Fr
        !            16: by Mitch Marcus of Bell Labs.  One of
        !            17: FIXIT's goals is to get the program running again as quickly
        !            18: as possible.  The user is assisted in making changes to his
        !            19: functions "on the fly", i.e. in the midst of execution, and
        !            20: then computation is resumed.
        !            21: .pp
        !            22: To enter the debugger type \fI(debug)\fP.
        !            23: The debugger goes into its own
        !            24: read-eval-print loop.  Like the top-level, the debugger understands
        !            25: certain special commands.  One of these is help, which prints a list of
        !            26: the available commands.  The basic idea is that you are somewhere in a
        !            27: stack of calls to eval.  The command "bka" is probably the most appropriate
        !            28: for looking at the stack.  There are commands to move up and down.  If
        !            29: you want to know the value of "x" as of some place in the stack, move to
        !            30: that place and type "x" (or (cdr x) or anything else that you might want
        !            31: to evaluate).  All evaluation is done as of the current stack position.
        !            32: You can fix the problem by changing the values of variables, editing
        !            33: functions or expressions in the stack etc.  Then you can continue from
        !            34: the current stack position (or anywhere else) with the "redo" command.
        !            35: Or you can simply return the right answer with the "return" command.
        !            36: .pp
        !            37: When it is not immediately obvious why an error has occurred
        !            38: or how the program got itself into its current state, FIXIT
        !            39: comes to the rescue by providing a powerful debugging loop
        !            40: in which the user can:
        !            41: 
        !            42: -  examine the stack
        !            43: 
        !            44: -  evaluate expressions in context
        !            45: 
        !            46: -  enter stepping mode
        !            47: 
        !            48: -  restart the computation at any point
        !            49: 
        !            50: The result is that program errors can be located and fixed
        !            51: extremely rapidly, and with a minimum of frustration.
        !            52: .pp
        !            53: The debugger can only work effectively when extra information is kept
        !            54: about forms in evaluation by the lisp system.
        !            55: Evaluating \fI(*rset\ t)\fP tells the lisp system to maintain this
        !            56: information. 
        !            57: If you are debugging compiled code you should also be sure that the
        !            58: compiled code to compiled code linkage tables are unlinked, i.e
        !            59: do \fI(sstatus\ translink\ nil)\fP.
        !            60: 
        !            61: .Lf debug "[ s_msg ]"
        !            62: .No
        !            63: Within a program, you may enter a debug loop directly by
        !            64: putting in a call to 
        !            65: .i debug
        !            66: where you would normally put
        !            67: a call to
        !            68: .i break.
        !            69: Also, within a break loop you may enter
        !            70: FIXIT by typing 
        !            71: .i debug.  
        !            72: If an argument is given to DEBUG,
        !            73: it is treated as a message to be printed before the debug loop
        !            74: is entered.  Thus you can put \fI(debug |just before loop|)\fP into
        !            75: a program to indicate what part of the program is being debugged.
        !            76: 
        !            77: .Eb
        !            78: \fIFIXIT Command Summary\fP
        !            79: 
        !            80: TOP     go to top of stack (latest expression)
        !            81: BOT     go to bottom of stack (first expression)
        !            82: P       show current expression (with ellipsis)
        !            83: PP      show current expression in full
        !            84: WHERE   give current stack position
        !            85: HELP    types the abbreviated command summary found
        !            86:         in /usr/lisp/doc/fixit.help.  H and ? work too.
        !            87: U       go up one stack frame
        !            88: U n     go up n stack frames
        !            89: U f     go up to the next occurrence of function f
        !            90: U n f   go up n occurrences of function f
        !            91: UP      go up to the next user-written function
        !            92: UP n    go up n user-written functions
        !            93:  ...the DN and DNFN commands are similar, but go down
        !            94:  ...instead of up.
        !            95: OK      resume processing; continue after an error or debug loop
        !            96: REDO    restart the computation with the current stack frame.
        !            97:         The OK command is equivalent to TOP followed by REDO.
        !            98: REDO f  restart the computation with the last call to function f.
        !            99:         (The stack is searched downward from the current position.)
        !           100: STEP    restart the computation at the current stack frame,
        !           101:         but first turn on stepping mode.  (Assumes Rich stepper is loaded.)
        !           102: RETURN e   return from the current position in the computation
        !           103:            with the value of expression e.
        !           104: BK..    print a backtrace.  There are many backtrace commands,
        !           105:         formed by adding suffixes to the BK command.  "BK" gives
        !           106:         a backtrace showing only user-written functions, and uses
        !           107:         ellipsis.  The BK command may be suffixed by one or more
        !           108:         of the following modifiers:
        !           109:  ..F..   show function names instead of expressions
        !           110:  ..A..   show all functions/expressions, not just user-written ones
        !           111:  ..V..   show variable bindings as well as functions/expressions
        !           112:  ..E..   show everything in the expression, i.e. don't use ellipsis
        !           113:  ..C..   go no further than the current position on the stack
        !           114:         Some of the more useful combinations are BKFV, BKFA,
        !           115:         and BKFAV.
        !           116: BK.. n    show only n levels of the stack (starting at the top).
        !           117:           (BK n counts only user functions; BKA n counts all functions.)
        !           118: BK.. f    show stack down to first call of function f
        !           119: BK.. n f  show stack down to nth call of function f
        !           120: .Ee
        !           121: .sh 2 Interaction\ with\ \fItrace\fP
        !           122: FIXIT knows about the standard Franz 
        !           123: trace package, and tries to make
        !           124: tracing invisible while in the debug loop.  However, because
        !           125: of the way
        !           126: .i trace
        !           127: works, it may sometimes be the case that the
        !           128: functions on the stack are really un\fIintern\fPed atoms that have
        !           129: the same name as a traced function.  (This only happens when
        !           130: a function is traced WHEREIN another one.)  FIXIT will call
        !           131: attention to 
        !           132: .i trace's 
        !           133: hackery by printing an appropriate tag
        !           134: next to these stack entries.
        !           135: 
        !           136: .sh 2 Interaction\ with\ \fIstep\fP 
        !           137: The 
        !           138: .i step
        !           139: function may be invoked
        !           140: from within FIXIT via the STEP command.  FIXIT initially turns off 
        !           141: stepping when the debug loop is entered.  If you step through a function
        !           142: and get an error, FIXIT will still be invoked normally.  At
        !           143: any time during stepping, you may explicitly enter FIXIT
        !           144: via the "D" (debug) command.
        !           145: 
        !           146: .sh 2 Multiple\ error\ levels
        !           147: FIXIT will evaluate arbitrary LISP 
        !           148: expressions in its debug loop.  The evaluation is not done within an 
        !           149: .i errset,
        !           150: so, if an error occurs, another invocation of the debugger
        !           151: can be made.  When there are multiple errors on the stack,
        !           152: FIXIT displays a barrier symbol between each level that
        !           153: looks something like <------------UDF-->.  The UDF in
        !           154: this case stands for UnDefined Function.  Thus, the upper
        !           155: level debug loop was invoked by an undefined function error
        !           156: that occurred while in the lower loop.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.