Thanks, but actually I think my problem was that I wasn't invoking the
function in the repl itself.
;; myfile.rkt
...
(f 123) ;; top-level invocation doesnt produce proper stacktraces in repl
but when I typed it in the repl it was ok
> ,en "myfile.rkt"
"myfile.rkt"> (f 456)
;
errortrace with ,en should work as normal, as long as you ensure that
there are no pre-compiled bytecode files (compiled/*.zo):
$ ls
myfile.rkt
$ racket -l errortrace -i
Welcome to Racket v7.2.
> ,en "myfile.rkt"
"myfile.rkt"> (f 123)
; g: 123 [,bt for context]
"myfile.rkt"> ,bt
; g: 123
;
Thanks! This one was what is needed.
racket -l errortrace -l racket -i
Actually, I tried this on my own before but I kept on getting "(no
backtrace)" when I would run my file.
Turns out, you can only get the stacktrace if you run the code via the repl
input rather than running code within
In DrRacket, the "preserve stack trace" button actually corresponds to a
mode in the compiler that disables some optimizations [*]. The radio
buttons at the top (specifically the debugging one) control errortrace.
Robby
[*]
If you are using DrRacket, you can go to the "Language/Choose Language..."
menu, click on "Show Details", than make sure the "Preserve Stack Trace"
checkbox is ticked.
If you are using racket-mode in Emacs, you can evaluate the current buffer
using "C-u F5" which will do the same thing.
If
Would using 'racket/trace' be a valid way to do this?
(require racket/trace)
(define (foo) ...)
(trace foo)
;; in repl (foo) then ,bt
Would it be correct to say that the error traces functionality has been
delegated to libraries in order to make things more flexible? (Rather than
baked
6 matches
Mail list logo
