@greg I guess there’s no easy way to use -l errortrace -t <prog> when my program needs command line arguments? (I get a racket: bad switch error regarding my program’s command line flags)

So i’m past the raco test issue, but i’m just trying out errortrace a bit. I’ve modified my source to (require errortrace) and watching as i get an error in one of my functions. The function starts like this: (define (select-new-goals deliberator) (printf "WOO ~s\n" deliberator) (let* ([kb (deliberator-kb deliberator)] ... and i know that the error is in that call to deliberator-kb. even with errortrace loaded, the stack trace gives me the line number of the define. Is that all i can expect from racket? is there an optimization i can turn off to get better line number resolution?

fwiw, errortrace works by inserting instrumentation into your code as part of compilation, so it won’t work if your code is already compiled to .zo files

i don’t think i have any .zo files, and in this case at least the (require errortrace) is in the same file as the (define (select-new-goals...)), so the .rkt should be newer than any .zo, and it sounds like that function should get instrumented

(require errortrace) won’t do anything from inside a module (though it might do something to modules transitively required by that module) because it works by adjusting the compiler handler, but by the time a module has been expanded enough to see the (require errortrace) call, it’s too late—the module is already being compiled.

actually, it won’t do anything for transitive requires, either, but it would affect dynamic-require.

hm, interesting.

(require errortrace) is meant to be used from the top level, before a module is compiled.

(doing racket -l errortrace -t mod-file.rkt has the same effect)

@jjwiseman I think you can use #lang errortrace <lang> to add instrumentation to a single module. So if you have #lang racket, you’d use #lang errortrace racket instead.

ok, i modified my program to not need its own command line flags for a test, and racket -l errortrace ... was able to zero in on the exact line number with the error.

ah, that #lang trick sounds like it might be easiest then.

It’d be nice if there were a better story for turning on errortrace without so much fiddling.

it felt like i must have some misconception about how things worked. and i did, to some extent, so thanks for illuminating that, but yeah, at the least i didn’t see anything about #lang errortrace in the errortrace docs.

and just to be explicit, adding (require errortrace) to my (module+ test ...) does not cause raco test -t … to give me a stack trace if a test gets an error. it seems like it tries: i now see an extra line of output: errortrace…:, but no actual stack trace.

that in particular is annoying: no stack traces if there’s an error while running a test, which seems like the kind of thing that every person who uses rackunit would run into constantly? running unit tests seems like the time you’re more likely to get errors, and would find a stack trace useful.

@jjwiseman it might be a regression (caused by my changes to rackunit over the last few releases)

could you open an issue in the racket/rackunit github repo?