Turning off trace messages

[Rangarajan]

When I execute some code in the editor, trace messages appear in the Listener pane. Is there any way to disable the printing of these messages?  When I run a large piece of code, it seems to me that these debug messages introduce some delay before the actual code is executed. Of course, these are very useful for debugging, but, it would be nice to have an option to turn these off when not required.

 

- Rangarajan

[opmo]

I will have a look what I can do.

[torstenanders]

Just evaluate this.

 

(defparameter *do-verbose* nil "Enable or disable traces printed by do-verbose.")

 

For some context see 

 

[opmo]

For some recent is not working if in Extensions folder.

[torstenanders]

BTW: Common Lisp has built-in tracing mechanisms, which happen to be more fine-grained and work automatically without any need to sprinkle explicit function calls like do-verbose in any definition at all.

 

For example, there is the builtin trace:  

CLHS: Macro TRACE, UNTRACE

CLHS.LISP.SE

 

In case of an error (and only in case of an error), a full stack trace is usually automatically printed. This happens to be disabled in the standard Opusmodus editor, but works as normally in Common Lisp when using the Emacs Slime interface. For example, consider the following code.

 

(defun function-causing-error (x)
  (/ x 0))

(defun test (x)
  (function-causing-error x))

(test 1)

 

When I evaluate the code above in Slime, I get not only a stack trace showing which function called which, I can also get interactively further information on the function calls, like looking at which arguments they were called. Best of all, I can evaluate arbitrary code for testing in the context of any function of the stack trace, where all its local variations are bound, which can be very helpful for debugging.

 

Here is a screenshot of the stack trace I get. You can see that the function test (frame 3 -- the leading number in the trace) calls the function function-causing-error (frame 4) which just a few frames up causes the error DIVISION-BY-ZERO.

 

 

Now, in this case the error is rather obviously, but in case you have some local variables in the function that might contain a bug, it would be useful to be able to look at these. Indeed, you can. Just click on any frame, and all local variables are shown. Here it is simply the argument x, which we already know, as arguments are shown in the stack trace as well.

 

 

 

Now, sometimes just seeing the local variables is not enough, you want to play with them a bit. Again, you can do that. Move the cursor into/on the frame, press the shortcut e (for evaluate), and you are prompted to enter an arbitrary expression that is executed in the context of this frame (e.g, can use the local variable x). I cannot easily show this in a screenshot and would instead need to do a little video. Let me know if the explanation so far is not sufficient.

 

Best,

Torsten

 

 

[Rangarajan]

Thanks a lot Torsten. The *do-verbose* trick works for me.

 

- Rangarajan