Jump to content

Recommended Posts

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

Link to post
Share on other sites

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:  

 

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.

 

293775498_ScreenShot2020-11-19at19_06_45.png.6ad110cb6e16a5c8c39ee43e790b1379.png

 

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.

 

84399631_ScreenShot2020-11-19at19_12_06.png.cd267adc3ad4e5a4d39f95a7738ab09c.png

 

 

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

 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

Terms of Use Privacy Policy