Chapter 1 
Introduction

• Source level debugger (highlight in a source window the code being executed).
• Lisp form oriented not line oriented (function call is highlighted not the line).
• Multisource debugging is possible (the system will switch to another source if needed).
• Controls :
• Step (execute the current form and stop before the next form ).
• Step over (execute the current form and stop before the next form in the current list).
• Next (execute the current form and stop at the highlighted form).
• Continue (execute the current form and don't stop anymore)
• Breakpoints and conditional breakpoints are placed on lisp forms (not on lines).
• Placement of watch points on variables and lisp forms is possible.
• Evaluation of lisp expressions is possible during debugging.
• Time traveling (the debugger keeps track of the lisp forms executed + their environment , this makes it possible to step backwards and forwards through time).
• Profiling (count how many times a lisp form is executed).
• Halting is possible before and after executing of a form.
• If halted after execution of a form then:
• The result of the execution of the form is displayed
• It is possible to change the value of the execution.
• Extensible (you can extend the lisp control structures the debugger recognizes by use of syntax definitions).
• If programs loaded in the debugger encounter, during execution, a continuable error, the lisp debugger is entered, the call causing the error is highlighted and you can give the correct result of the call and continue executing the program (this feature doesn't work in gcl because gcl lacks handler-case , needed for this feature).

1. A temporary file is created, this file  contains the lisp source with debug code added to it (essentially code to call the debugger, to save position info and to save the environment of the function call).
2. The temporary file is loaded in the LISP system (you can ask to compile it before the load).
3. The source code is loaded in a source window to be displayed during the debug process.
4. You can now use the source window to set breakpoints , watch points ... . When you run now code in the LISP system the execution will stop at the breakpoints and the lisp form which should be executed next is highlighted in the source window. From then on, you can fully control the execution of the code.
5. If during execution of the debugged code a continuable lisp error happens, the debugger is entered and the call causing the error is highlighted. If needed you can give the result of the call to the faulty code and continue running your program.
6. When you close a source, the source will be removed from the source window and the original code (without instrumentation code) is loaded in the LISP system.

1.1  Warnings

• Adding instrumentation code has some risks associated with it.
• Bugs in the debugger can cause malfunction of your code (I have done my best to avoid bugs but nobody is perfect :().
• Bugs in the debugger can make that not every part of your program is available for debugging.
• Bugs in the compiler/optimizer of lisp can make that there is a different behavior of debugged programs and non debugged programs.
• Debugged code is much slower then non debugged code.
• If you work with recursive data which is impossible to print in LISP, the debugger will also go in a infinite loop to try to print this data. Turning off recursive printing in LISP will also solve the problem for the debugger (as he uses the print functions of LISP) as long as the results are not displayed in a separate window.
• Macros are not easy to debug , given a macro call the system will try to expand it and then try to add debugging code to the expanded code. System macro's which represents a special control structure (like cond,if ...) are handled in a special way. If you define your own control structures you can extend the debugger to handle them in the correct way.
• Breakpoints can be placed on every lisp form you can evaluate (with the exception of atomic expressions and some macros (example (defgeneric ...), (function ...)).
• If you can't place a breakpoint on a form it is usually possible to place a breakpoint on certain sub forms.
• If you make changes to the source , you have to reload the source in the debugger (you can use copy/paste to load sources in the debugger if you use emacs or xemacs).
• If there are bugs in your source code which causes a halt during loading , the debugger will halt when he loads the modified source code and you will enter the native debugger. If you exit the native debugger the rest of your code will be loaded. Always make sure that you can load code before you try to debug the code.
• The debugger sits in package &pi0;&pi0;DEBUGGER'' , don't use this package.
• In the &pi0;&pi0;USER'' package the function name &pi0;&pi0;debug'' (&pi0;&pi0;deb'' in ACL) is exported , so you may not use this name for a function.
• Allegro uses the name &pi0;&pi0;debug'' so I used &pi0;&pi0;deb'' in the case of Allegro.
• If you choose to compile the debugged code in CMUCL it can take a long time and lots of memory because the addition of the extra debugging code.
• If you choose to compile the debugged code in ACL you can get errors because the not correct (in my opinion) handling of ACL of macros used in optional parameters of functions.

Chapter 2 
Overview of the debugger.

2.1  Quick procedure to get you running.

1. Make sure that X Windows is running,
2. Start LISP (standalone or as a process in emacs (xemacs).
3. Type (debug) at the lisp prompt ((deb) for Allegro). A separate debug window should open (see Figure: Starting Debugger) . You control debugging using this window.

 

 
 




















Figure 2.1: Start Debugger






4. Load a lisp source in the debugger using < File > < Open > .

 

 
 



















Figure 2.2: File Selection






5. After loading the source, you can set a breakpoint by first selecting a lisp form and then clicking on < Breakpoint > . If a breakpoint is possible the break pointed code will have another foreground color (default red). Using the middle mouse button you select a whole function , double clicking select a list.

 

 
 
















Figure 2.3: Source Window






6. Return then to the lisp prompt in the LISP system and type an expression. If the execution of the expression causes the break pointed code to run , the currently executed code will be highlighted in the source window and the debugger waits for your commands. You can now step through the code , set watch points , evaluate expressions ... .

 

 
 



















Figure 2.4: Executing Code







7. For more detailed information of using the debugger go to the user manual.
8. To stop debugging , use < File > < Exit > , the original source (without debugging code) will be loaded back in the LISP system.

2.2  Using the debugger

2.2.1  Starting the debugger.

2.2.2  Debugging programs.

• A menu line ('File','Source','Edit','Options','Tools') to Open/Close sources, to switch between loaded sources, to paste code to the debugger, to configure the debugger and to do profiling.
• A button panel containing the most used functions of the debugger (Stepping , Break pointing , Watching , Evaluating and time traveling).
• A source pane which shows the source code, during debugging the debug points have a red foreground color, the code to be executed is highlighted in light blue and if you do profiling, code called the specified amount of times is highlighted in yellow.
• A watch pane, contains the watched variables and expressions in addition to their values (this info can also be displayed in a separate window). The watch pane can also display the result of an expression evaluation or the result of a call before stepping to the next call.
• Command pane, used to type in an expression that can be used as a watch expression , that can be evaluated ,that can be returned as the value of call or that can be used in a conditional breakpoint.

1. Load the source code of the function in the debugger , this can be done in two ways:
1. The code is defined in a source file on the hard disc, you use then < File > < Open > to load the whole source file in the debugger. This is the preferred way of working because you can then debug all related functions in the source file.
2. The code is defined in an editor (like emacs , xemacs ...), select then the code, use the < Copy > function of the editor to put the code in the copy buffer. and use then < Edit > < Paste > on the debug window to load the code in the source window. (There is a change that this is not working because Copy/Paste is not well defined in X Windows).
3. Once code is loaded in the debugger the debugger will be activated in the following cases:
1. By a continuable lisp error during executing of the debugged code. The call causing the error is then displayed and you can try to finish the execution of the code by giving a result for the faulty call (this is not working in gcl).
2. By executing a piece of code with a breakpoint on it (for conditional breakpoints the condition must be full filled as well).
3. As the result of < Step > , < Step Over > and < Step Next > .
4. Because you didn't use < Continue > to stop debugging the previous lisp expression.
2. Set a breakpoint , this can be done in two ways :
1. Select a form in the source pane and press then 'Breakpoint' to set a breakpoint. The color of the text in the form changes then to red to indicate a breakpoint set on this form. The color will only change if you can really set a breakpoint . Example : in (defgeneric fac (n) (:method ((n integer)) (if (zerop n) 1 (* n (fac (1- n))))) (:method ((n string)) (concatenate n "!''))) you can set a breakpoint on (:method ((n integer)) (if (zerop n) 1 (* n (fac (1- n))))), (if (zerop n) 1 (* n (fac (1- n)))) , (zerop n) , (* n (fac (1- n))) , (fac (1- n)) , (1- n) , (: method ((n string)) (concatenate n "!'')) , (concatenate n "!'') but not on the (defgeneric ....) form. It should be clear that a breakpoint is not set on a line but on a form like a function call ((function arg1 .... argn) , ...) , a special function call ((cond (( ....) ...) ...) , (defun ...) , (let ...) , (do ....) ....) or a macro call. Breakpoints just like forms can be nested. The 'Breakpoint' act as toggle if you select a form which already has a breakpoint selected with it you remove the breakpoint.
2. Type in an expression in the command pane , select a form in the source pane and press 'Break If' , this sets a conditional breakpoint , execution is halted only if the evaluation of the condition gives true as a result. An error during the evaluation is considered false (a dialog box explaining the error is displayed in this case). The 'Break If' button act as a toggle, just like the 'Breakpoint' button.
3. Set a watch point , this can be done in two ways :
1. Select a variable in a function and then press 'Watch' . In the watch pane you will see now the variable followed by an arrow to its value. If the variable is not defined the value will be 'Undefined'.
2. Select a form in the source pane, type a expression in the command pane and press 'Watch exp'. This will set a watch point on the expression in the command pane, which is evaluated when forms in the selected code are executed (otherwise 'Undefined' is used as value). A common mistake is to forgot to make a specific selection.
4. To unset a watch point. Press the results of the watch point in the watch pane, a dialog box pops up to ask if you want to display the results in a separate window or delete the watch point. If you work with separate results windows, then deleting these windows causes the display of the results in the watch pane.
5. You can go now to the LISP system and type in some lisp expressions. If a breakpoint is encountered then the execution of the function will be paused and the code to be executed will be highlighted in the source pane of the debug window (if needed the corrected source will be loaded or a repositioning will take place so that the executing code is always visible). You can react now in the following ways :
1. Press the 'Step' button and execute the highlighted form, pausing at the next form to be executed (this could be a sub form of the highlighted form).
2. Press the 'Step Over' button, execute the highlighted form, pausing at the next form within the parent form (so we will not step through code called during execution of the highlighted form (unless breakpoints are placed of course)).
3. Select the code where the debugger should pause next and press then the 'Next' button. The debugger will then start executing the code until a breakpoint is encountered or the selected code is reached.
4. Press the 'Continue' button , the debugger will then start executing the code until a breakpoint is encountered or nothing has to be executed.
5. Press the 'Back' or 'Forward' button to do time traveling (look at the previous/next executed code and variable context at that point).
6. If you have used Step or Step Over and all code is executed, then the system stays in a stepped state, if you execute another debugged function from the lisp prompted then the system pauses execution waiting on you to press 'Step' , 'Step Over' , 'Continue' or 'Eval'.
7. If you have enabled the option 'Display result last call', then the debugger stops also just after execution of a call. If stopped after execution of a call, the result of this call is displayed and the button 'Change Result' is enabled. If you type in a expression in the command pane and press 'Change Result' this expression is evaluated and returned as result of the call instead of the original result.
8. Select a source via < Source > .
9. You stop debugging of a source by selecting the source and then < File > < Close > . The original source code is then loaded in the LISP system.
10. Another way of stopping of debugging is the < Tools > < Interrupt > menu, this puts the executed code in the native debugger and stops debugging of the code with the lisp debugger. The original code is not reloaded in the LISP system. Use this option with care (it can cause problems in certain lisp systems).
11. You stop the debugger via < File > < Exit > . Before exiting , the debugger will load the original sources of all debugged code back in the LISP system.

Chapter 3 
Reference Manual

3.1  Menus

3.1.1  Overview

• < File > < Open >
• < File > < Close >
• < File > < Exit >
• < Source >
• < Edit > < Paste >
• < Edit > < Find >
• < Options > < Color Break >
• < Options > < Color After Break >
• < Options > < Color Breakpoint >
• < Options > < Color Breakpoint If >
• < Options > < Color Profiling >
• < Options > < Font >
• < Options > [Compile debugged code]
• < Options > [Display result last call]
• < Options > < Save Options >
• < Options > [Save on exit]
• < Tools > < Start profiling >
• < Tools > < Stop profiling >
• < Tools > < Interrupt Program >

3.1.2  Detailed description of menu items

< File > < Open >

< File > < Close >

< File > < Exit >

< Source >

< Edit > < Paste >

< Edit > < Find >

• Case , case sensitive search.
• No Case , case insensitive search.
• Regular expression , allows you to use regular expressions in the search.

< Options > < Color Break > , < Options > < Color After Break > , < Options > < Color Breakpoint > , < Options > < Color Breakpoint If > , < Options > < Color Profiling >

< Options > < Font >

< Options > [Compile debugged code]

< Options > [Display result last call]

< Options > [Enter debugger in case of error]

NOTE: This feature doesn't work for GCL , even if enabled (this is because handler-case is missing in GCL).

< Options > < Save Options >

• (DEBUGGER::setting "COMPILE_CODE" 0)
• (DEBUGGER::setting "SAVE_ON_EXIT" 0)
• (DEBUGGER::setting "DISPLAY_RESULT" 0)
• (DEBUGGER::setting "DEBUGPOINT_COLOR" "#ff0000")
• (DEBUGGER::setting "DEBUGPOINTIF_COLOR" "#808000")
• (DEBUGGER::setting "CURRENT_COLOR" "#00ffff")
• (DEBUGGER::setting "AFTER_COLOR" "#008080")
• (DEBUGGER::setting "PROFILE_COLOR" "#ffff00")
• (DEBUGGER::setting "FONT" "-*-helvetica-medium-r-normal-*-120-*-*-*-*-*-*")

• DEBUGGER::setting is a LISP function which when called change the configuration of the debugger in a way defined by the first string (=parameter), the last arg is the value of the parameter.
• COMPILE_CODE if equal to 1, enable < Options > [Compile debugged code], otherwise disable this option.
• SAVE_ON_EXIT if equal to 1, enable < Options > [Save on Exit], otherwise disable this option.
• DISPLAY_RESULT if equal to 1, enable < Options > [Display result last call], otherwise disable this option.
• DEBUGPOINT_COLOR is in rgb values the foreground color of a breakpoint.
• DEBUGPOINTIF_COLOR is in rgb values the background color of a breakpoint.
• CURRENT_COLOR is the color used to highlight a call just before it gets executed.
• AFTER_COLOR is the color used to highlight a call just after it gets executed.
• PROFILE_COLOR is the color used to highlight code fullfilling the profile count.
• FONT is the font used in the debugger.

< Options > [Save on Exit]

< Tools > < Start Profiling >

< Tools > < Stop Profiling >

< Tools > < Interrupt Program >

3.2  Source Pane

3.2.1  Content.

• If you open a new source , then this is the source displayed.
• You can change the source displayed via the < Source > menu.
• If you close a source , the first opened source is displayed.
• If the system encounters a breakpoint , the source containing the breakpoint is displayed, the window on the source is also repositioned so that the executing code is visible.

3.2.2  Selection

• Dragging. Click with the mouse in the source pane (use the left button), drag the mouse to an other point and release the button.
• Click somewhere in a function definition with the middle mouse button. This selects the whole function.
• Double click with the left button , this selects a whole list.

3.2.3  Highlighting.

• Red foreground , this is a breakpoint.
• Dark green foreground , this is a conditional breakpoint.
• Light blue background, this code will be executed next.
• Dark blue background, this is just executed code.
• Yellow background , this code fulfills the profile count (is at least as many times executed).

3.3  Watch Pane

3.3.1  Content.

3.4  Command Pane

3.4.1  Content.

• Conditional breakpoints (NIL or non NIL of the evaluated expression determines if the system stops or not).
• Watch Expression (the expression to watch).
• Eval (the expression to evaluate).
• You want to change the result of a call (with the 'Change Result' Button).

3.5  Buttons

3.5.1  Overview.

• < Step >
• < Step Over >
• < Next >
• < Continue >
• < Breakpoint >
• < Break If >
• < Watch >
• < Watch Exp >
• < Change Result >
• < Eval >
• < Back >
• < Forward >

3.5.2  Detailed description of the buttons.

<  Step >

< Step Over >

• A breakpoint is encountered.
• A lisp form in the same enclosing list as the highlighted form must be executed.

<  Next >

• A breakpoint is encountered.
• The highlighted code must be executed.

<  Continue >

<  Breakpoint >

<  Break If >

Errors during evaluating the condition counts as a NIL and a message detailing the error is displayed. Also the condition is only evaluated in the highlighted code.

<  Watch >

<  Watch Exp >

< Change Result >

< Eval >

<  Back >

< Forward >

Chapter 4 
Extending the debugger

4.1  Introduction.

If you want to modify the debugger keep in mind the following points :

• Function calls are handled correctly by the debugger, you don't have to do anything at all for this.
• Macro's are the problem . The standard lisp macros are covered in the debugger and he tries to make the best of the ones you define (first he expands the macro call and then tries to add debugging code to the expanded code) but the result is not always what you expect. It is here that you can modify the behavior of the debugger.
• Modifying the debugger can stops it working, so be careful. Nothing can go wrong if you make sure that you have made backup copies of the following files:
• lispsyntax (this is the source file defining the working of the current debugger).
• debugcode.o,debugcode.x86f , debugcode.fas or debugcode.fasl (this is the core of the debugger for GCL,CMUCL,CLISP or ACL5, loaded when you start (debug) or (deb)).

4.2  Modifying the debugger

1. Create a source file defining how the lisp debugger should transform sources. You can take the file delivered with the debugger as a base and extend it. This file is '/usr/local/lib/lispdebug/lispsyntax' (if you have done a default installation of the debugger). Remember, this file will redefine the way how the debugger transform sources to debugged sources, if you make errors or forget things the debugger can act strangely. The syntax and semantics of the language to use is described in the next chapter.
2. Use the lisp function DEBUGGER::process-definition-file to compile this file to lisp code containing the parse and convertion code of the debugger. The syntax to use is either :
1. (DEBUGGER::process-definition-file < Source-file > ) , the source file is compiled to a lispfile (debugcode.lisp) which is then compiled by the lisp system and then loaded in the lisp system modifying the behavior of the debugger.
2. (DEBUGGER::process-definition-file < Source-file > < Out > ) , the source file is compiled to a lispfile (with filename < out > .lisp) which is then compiled by the lispsytem and then loaded in the lisp system modifying the debugger.
3. Once 2 is finished you can test the debugger to see if he handles the new definitions well (to test the normal lisp constructs look at the testgcl.lisp,testcmucl.lisp,testclisp.lisp and testacl5.lisp files). If you are convinced that the debugger is working correctly you can make your modifications permanent by copying the object file generated in (2) to /usr/local/lib/lispdebug or to the value of the LISPDEBUG environment variable. (If you use 2.a. the object files are either debugcode.o,debugcode.x86f,debugcode.fas or debugcode.fasl for gcl,cmucl,clisp or acl).

4.3  Extension Language Of the Debugger.

4.3.1  The default file used by the debugger.

4.3.2  Syntax of the language.

[comments]

Everything on a line after a ';' is considered a comment and is neglected.

[white spaces]

Used as separators , the following is a white space :

• blank
• new line
• tab
• return

[definitions]

These are of the form :

• symbol = expression

[expressions]

These are of the form :

• symbol
• _symbol
• ~symbol
• #symbol
• @
• [ expression ... expression ]
• [ expression ... expression ]*
• {expression ... expression}
• {expression ...|....|...| expression... }*
• ( expression expresion ...)
• "text''

[symbols]

Any string of characters with the exception of white spaces , @ , _ ,~,#,(,),[,]

4.3.3  Semantics of the language.

1. The expression recognizes the lisp expression consuming part of it and producing another lisp expression.
2. The expression does not recognize the expression an it generates a throw, no lisp expression is produced.

Symbol.

Let P=() , L=(defun f (n) (princ n)) and E=defun then applying E on L gives L=(f (n) (princ n)) and P becomes (defun).

Let P=(), L=(defun f(n) (princ n)) and E=let then applying E on L gives a throw.

"text''

_symbol

Let P=() , L=(a b c d) and E=_sym then applying E on L gives L=(b c d) , P=(a).

Let P=(),L=((a b) c d) and E=_sym then applying E on L gives L=(c d) , P=((a b))

Let P=(),L=() and E=_sym then applying E on L gives a throw.

~symbol

Let P=() , L=(a b c d) and E=^sym then applying E on L gives L=(b c d) , P=(a).

Let P=(),L=((a b) c d) and E=^sym then applying E on L gives a throw.

Let P=(),L=() and E=^sym then applying E on L gives a throw.

#symbol

Let P=() , L=(a b c d) and E=^sym then applying E on L gives L=(b c d) , P=((add-debug-code a)).

Let P=(),L=() and E=^sym then applying E on L gives a throw.

@symbol

[expression1 ... expressionn]

E=[a b] c , L=(a b c d) and P=() then applying E on L gives L=(d) , P=(a b c)

E=[a b] c , L=(c d) and P=() then applying E on L gives L=(d) , P=(c)

E=[a b] d , L= (c d) and P=() then applying E on L gives a throw

{e11...e1n|...| em1....emk}

Example 1 E={a b} c , L=(a c d) and P=() then applying E on L gives L=(d),P=(a c)

E={a b} c, L=(b c d) and P=() then applying E on L gives L=(d),P=(a b)

E={a b} c, L=(c d) and P=() then applying E on L gives a throw

[expression1 | ... | expressionn]* , {expression1 ... expressionn}*

E=[a b]* c, L=(a b a b c) and P=() then applying E on L gives L=(c) , P=(a b a b)

(expression1 ... expressionn)

Example 2 E=(a b c) , L=((a b c) d) , P=() then applying E on L gives L=(d) , P=((a b c))

E=(a b c),L=((a b c d) d), P=() then applying E on L gives a throw.

definitions (name = expression)

4.3.4  Cavecats.

• When using recursive definitions make sure that you do not introduce infinite looping.
• Be careful when using #,_,or ~and [],{}* and []* , the effect is not always what you want. Look at the following expression
• ["string'' | (declare [_declaration])}] {#exp}*
• This will when applied to ("description'' (declare (string a)) (princ x)) apply with success {#exp}* to "Description'' and (declare ..) and add debug code to "Description'' and (declare ...) which gives in the case of (declare ..) a syntax error in lisp. The way out of this problem is using some extra {}, our code becomes then something like :
• {"string'' {#exp}* | "string'' (declare [_declaration]) {#exp}* | (declare [_declaration]) {#exp}* | (declare [_declaration]) "string'' {#exp}* | {#exp}*}

Chapter 5 
Porting of the debugger

5.0.5  Conditions.

1. The lisp adheres to ANSI LISP.
2. TCL/TK version 8.x (previous versions could work also but I have not tested them) is installed in the OS together with its libraries. In contrast to the previous version of the debugger , LISP must not support TCL/TK (except for GCL).
3. The OS and LISP supports sockets.

5.0.6  Overview of the debugger.

• The user interface , this is the GUI of the debugger and it is written in C using the TCL/TK system as a graphical library.
• A extension of lisp containing the code to parse and change sources, generate a new parser/generator and code called by the debugged functions.

The GUI interface.

• interface.c , this contain the main body of the interface.
• hash.c , hash.h , this contains some extensions for hashing and list manipulation used in interface.c.
• tclinvoke.c , code to call TCL/TK in a more efficient way.

1. 'interface', the communication takes place via a Unix socket with address '/tmp/lispdebugger' (this is the method used by CMUCL).
2. 'interface pid' , pid is the process-id of the parent of this progam (the lisp system). This pid is then used by 'interface' to send a signal SIGUSR1(=10) to the lisp system each time it has output for the lisp system and thus let the lisp system act on the input. The communication still takes place via Unix sockets with address '/tmp/lispdebugger' (this is the method used for GCL).
3. 'interface -port' , port is the port number to use , communication takes place via stream oriented tcp/INET sockets on the port indicated (this is used ACL and CLISP).

• (debug-open-file < filename > < compile-t-nil > ) to add debug code to the program (if needed compile it) and load the changed code in the lisp system.
• (debug-delete-watchpoint < tag > ) delete the watch point identified by < tag >
• (debug-separate-watchpoint < tag > ) display the watch point identified by < tag > in a separate window
• (debug-set-watchpoint < tag > < begin > < end > < source > < exp > ) sets a watch point identified by < tag > , < begin > , < end > , < source > indentifies the place of the watch point in the source and < exp > is the exp to watch.
• (display-result-exp < exp > ) evaluates < exp > and displays the result
• (display-watchpoints) display all current watch points
• (if-breakpoint < exp > ) checks if we must stop in a watch point because of a conditional breakpoint
• (end-debug-eventloop) to end the eventloop at a debugpoint
• (return-result-exp < exp > ) returns < exp > as the result of a evaluating a lisp form
• (step-back-in-time) causes the debugger to step back in time
• (step-forward-in-time) causes the debugger to step forwards in time
• (stop-interface) stops and cleans up the lisp system socket part of the interface.

• First a number followed by a blank indicating the function to call in the 'interface' is send, this number implicit says also how to handle the arguments. The following functions must be implemented in the interface (function together with function-code and description). Positions are expressed in number of bytes from the beginning of the source.
• 0=hightlight-source , arguments begin(integer),end(integer),type(string),color(string) , should highlight the source text in the indicated color from position=begin to position=end. type is used to make a distinction between selection.
• 1=display-message, arguments message(string) , displays the message string.
• 2=highlight-error, arguments begin(integer) highlights the line containing the position begin.
• 3=set-possible-breakpoints , arguments source(string),begin(integer),end(integer) gives the debugger information about the begin and endpoints of breakpoints in the source.
• 4=give-control-to-interface , arguments source(string),begin(integer),end(integer) called from the debugged code to allow the debugger to intervine. In the 'interface' give-control-interface blocks until the user steps or press continue ... .
• 5-display-result, arguments nr-args(integer) = no of args to follow, the args next comes always in groups of five args: type(integer)(0=variable,1=exp,10=variable in separate window,11 exp in separate window),tag(string),exp(string),value(string).
• 6=display-exp-in-interface, arguments exp(string),result(string) used to display the result of evaluating a expression.
• 7=if-breakpoint, arguments none , check for conditional breakpoints.
• 8=display-time-env, arguments begin(integer),end(integer),source(string) equivalent as give-control-to-interface but used in time traveling.
• 9=setting, arguments var(string),value(string) used to set the options settings in the debugger.
• 10=give-control-to-interface-after, arguments source(string),begin(integer),end(integer) called from the debugged code to allow the debugger to intervine. In the 'interface' give-control-interface blocks until the user steps or press continue ... .
• 11=lisp-goes-to-debug called if evalling debugged code in lisp gives continuable error, the interface will then display this error and highlight the problem code.
• The arguments of the functions are send as follows :
• integers, in printed format followed by a blank character so they can be read with scanf.
• strings, first the length of the string is send, then a blank character followed by the string followed by a blank character.

The lisp code.

• The main body of the debugger (debugger.lisp).
• The interface to the 'GUI interface' (cmucl.lisp,gcl.lisp,acl5.lisp,clisp.lisp).

• (start-interface) , to start 'interface' and make a socket connection.
• (stop-interface) , to clean up everything after 'interface' is stopped.
• (send-command command &arg-list) , to send the command function code followed by the arguments to the interface.
• (process-incoming) see if there is input waiting on the socket read this in and evaluate it.
• A way of detecting input on the socket and then call process-incoming.