I'm hacking in Racket and I keep getting errors.
The default error handler shows a stack trace. At the end of the stack trace, it shows the "top level" evaluation as "/path/to/file/my_module.rkt: [running body]"
How do I show the line number for the running body part?
If you use DrRacket, it will highlight the error location in the source. To get similar functionality in the racket REPL, see the errortrace tool.
Related
I am trying to use Clojure with emacs and cider for a project of mine, and often exceptions occur while executing my code. When an exception occurs, cider provides me a stack trace, but often that is not sufficient to quickly identify what went wrong. I am looking for some way to make CIDER initialize a REPL when the exception occurs, that will allow me to examine the values of locals at the point of occurring of exception and perhaps even change some of the values and continue execution from that point. Is it possible with Clojure, Emacs and Cider?
AFAIK, such feature is not available neither in CIDER nor in other IDEs (Cursive, LightTable).
The most you can do is to insert a breakpoint before erroneous form and, when debugger has popped up, inspect locals there.
On most instances of MATLAB I've used, whenever I had a bug in my code the error message in the command window would show the line number.
However on the computer I am currently using, it shows me only the following:
??? Subscripted assignment dimension mismatch.
Is there anyway to get the line number to show again instead of ?????
What you are doing is using Run Section or Run and Advance as #canzar said. If you run scripts like this there is no 'line number', just as when you copy-paste code and run it in the command-window will not show you the line number on the error.
If you run the script using run or by pressing F5 it does know the line number and then prints that on the error statement. Good to know for debugging is to go to the tab editor->breakpoints->dbstop on error. If you press that it will keep your variables as present when the memory occurs, as opposed to throwing everything out when debugging functions.
I am writing a program with SBCL and building it with Buildapp.
Currently when error occurs it starts debugger. I want it to die in the same manner as other simple (C) programs do. What can I do for this?
One option is to put (sb-ext:disable-debugger) early in your startup function. When an error occurs and there is no handler, SBCL will print an error and a backtrace and exit.
Another option is to write a function that does what you want on error and set it as your debugger hook; see command-line-debugger in buildapp itself for an example.
I wonder what the difference is between entering a few lines in the command window, or letting a script execute them.
In the question Escape from nested try - catch statement I have an example function. I have put the selected code in a script and called it, however then it does not work properly. On the other hand, when I
select the lines and hit f9, it works as expected.
The lines are:
dbclear all
dbquit
dbstop if caught error
I call the example function as such:
dbstop if caught error
mytestmain
And the example function is:
function mytestmain
try
mytestsub
catch
end
% Definition of subfunction, may or may not be in the same .m file
function mytestsub
try
a=b; %Intentionally generate an error as b is not defined
catch
end
I think it's related to MATLAB's just-in-time (JIT) compiler, which compiles functions before it runs them.
It seems that it compiles functions differently if dbstop is set or not (see here for reference). As it currently stands, MATLAB can not recompile a function while it is run (just try saving a changed function during a dbstop, and you will get a message informing you). As you can add and remove breakpoints during a dbstop I think you can also do so programmatically, but it should be impossible to "turn on" debugging if it wasn't turned on at "compile time"
So in your cases:
Using F9 it's just pasted and parsed as if you input it manually. So first dbstop is set, then mytestmain gets compiled and executed.
Running as a script will first compile the script and mytestmain and then execute it - so dbstop would be set after compilation and therefore not in effect.
Depending on what you mean by "doesn't work", it could just be because the debugger is a special context and certain debugger commands - dbup, dbdown, and dbquit - only work when you're at a debugger "K>>" prompt. Once you call a script, you're no longer at the debugger prompt but in normal code execution - inside a nested M-code call stack - and they just don't work there. When you F9, it does the lines individually, so each one is done from the prompt.
As a workaround, if you really want to execute a sequence of debugger commands like this, you could write a little Java Swing widget to enter the text in to the command window just as though you were typing it in.
I am wrote the code with bugs.
Example:
(print (/ 1 0))
I am trying compile with C-c C-c.
And catch the error with stack frame.
I want see line in the code where an error occured. Clicked 'v' on line in stack frame and catched error.
Error: Cannot find source location for: #<COMPILED-CODE-LOCATION
(SB-C::VARARGS-ENTRY /)>
How can I go to the line in my code?
Screenshot:
As you can see from the error, the line you want to jump to, is somewhere in package SB-C, which is part of SBCL. If you don't have SBCL sources (you've installed a binary or deleted them), you should get them (relevant to your current SBCL version) and then link them up in .sbclrc like this (according to http://www.cliki.net/SLIME%20Features):
(setf (logical-pathname-translations "SYS")
'(("SYS:SRC;**;*.*.*" #P"/opt/sbcl/src/**/*.*")
("SYS:CONTRIB;**;*.*.*" #P"/opt/sbcl/contrib/**/*.*")))
Or just compile SBCL from source and it will know, where they are.
Do you have (proclaim '(optimize debug)) above that line somewhere? This function will ensure that your system has all the debugging data it can get.