@greg is there a way in racket-mode to have source level debugging? i.e. setting breakpoints, running in debug mode, etc?

@pocmatos No.

I mean, a couple years ago I got this mostly working. Including, when you hit a breakpoint, you have a full REPL at that point.

But that’s a pretty stale branch on GitHub now.

I never merged because I wasn’t sure I wanted to sign up to support that as a feature, if no one really needed it.

And I’ve only heard a few requests for that.

For myself, I find that print, racket/trace, and logging (plus of course a REPL) are all I really need — at least for what I do. ¯_(ツ)_/¯

Also there is #R and debug-repl from… dang, what’s the package…

Oh, debug :slightly_smiling_face: https://pkgs.racket-lang.org/package/debug

And of course DrRacket has a step debugger.

One caveat with DrRacket (and with my experimental stale branch) is that they work by rewriting your program — into a step- and breakpoint-able version of your program.

So it’s significantly slower.

Also there’s the question, beyond some foo.rkt file, how many other files do you — or can you — rewrite this way so that you can step through them, too? And the UX for that has always been kind of non-satisfying, in my experience.

TL;DR I decided not to add this to my list of windmills to tilt

@mflatt or @robby If you have any thoughts: https://github.com/racket/racket/issues/1916

(I’m not sure if its a DrRacket bug or a Racket module registry bug (or something else).)

That’s how Racket works I am sorry to say

When you load a file and then change the file on the disk, you need a new namespace

You could say that drr should not let you into its namespace

:’(

And that is a drr bug.

I hope to fix it someday but it isn’t simple.

@robby That makes sense. I just didn’t know what drr was doing.

But ya, if it is loading the snip into the same namespace the error makes sense.

Which I guess means it is a caching bug :wink: … just a non-trivial one to fix.

Anyway, thank you.