I’ll have a look and see if I can extend that. Cursive monkey-patches clojure.test at a pretty low level so these things sometimes are tricky, but I’ll see what I can do.

for anyone in the same situation, I notice I cna see the error report when mousing over the error with the red underscore, in the dialog it displays the result (a bit weird due to the ASCII color codes, but still readable)

Actually, could you file an issue about check support so I don’t lose it?

This became true of even clojure.test for me after IDEA updated to 2021.2.

(That I have to mouse over the redline in order to see the expected/actual results.)

https://github.com/cursive-ide/cursive/issues/2584

@U0HJA5ZQT That’s probably https://github.com/cursive-ide/cursive/issues/2574, which is fixed in the latest Cursive EAP

this could be related https://clojurians.slack.com/archives/C0744GXCJ/p1628700544077600

Downgrading to 0.10.889 worked! Thanks!

You’d have to have started the JVM process with the debug options set - there’s no way to stop the process otherwise.

That sounds promising. How do I start the JVM process with the debug options set? Then how do I trigger a break? Then how can I see the locals at the point of the break?

Pretty sure you just hit the Debug button in IDEA instead of the Run button to do that, assuming your run configuration supports it (i.e. IDEA knows that it's a Java application and not e.g. a bash script that's wrapped around it). Then, during the run time, you just hit the Pause button in the Debug panel. Locals should be there then - but you should also provide -Dclojure.compiler.disable-locals-clearing=true in advance.

It's pretty much identical to debugging a regular Java application.

Thanks @U2FRKM4TW! Where and how does one provide `-Dclojure.compiler.disable-locals-clearing=true` in advance?

Depends on the way you run your code.

It's an option for Java. All the build tools out there support providing arguments to the java executable.

And if you run it simply via Cursive REPL, then there's that small green bug icon.

I'm using lein. So this goes in project.clj?

Yes.

In :jvm-opts? I'm always unsure of what goes in there...

Currently I have:

:jvm-opts ^:replace []

https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#setting-jvm-options

That specification, I think, was to turn OFF some default configuration that we found out was slowing our runs... so I'm guessing I should change it to:

:jvm-opts ^:replace ["-Dclojure.compiler.disable-locals-clearing=true"

I'll give that a shot.

That particular -D option is for debug only - don't use it in production.

Okay thanks -- so I have to remove or comment it out in my project.clj when I'm done debugging? The consequence of not doing so is what?

Lein has profiles that can override certain options.

Huh -- even with the locals clearing disabled, no matter when I pause it I don't see the frames or locals I'm expecting.

What do you see? Can you share a screenshot of the Debug panel?

All of my functions would be in "propeller" namespaces, and I should be nested within a couple of functions in there when I'm pausing.

If I poke around in that one frame I see some constants but nothing with a name that I recognize.

And when you click on one of those non-grayed-out rows with propeller.core, do you get redirected to the main editor, with the line that's currently executed but paused being highlighted?

It always takes me to propeller.core, which doesn't even contain any code that I am running. I start my session (after pressing the Debug button) by switching into another namespace and running the -main that is defined therein.

Could this message that I see in the Variables pane when I click on the propeller.core invokeStatic item have anything to do with it? Target VM is not paused by breakpoint request. Evaluation of methods is not possible in this mode

I suspect it might be in a different thread then - there's a thread dropdown above the callstack, try looking in there. Take that message at face value - it's not that important to you. Is your code in some busy loop when you pause it? Or is it waiting on e.g. some future or an async operation or something like that?

So I just tested what I preached in one of my apps - a multi-threaded web service that I start in a similar via REPL during development. Pausing took me to the code that runs the REPL itself, kinda expected. Other threads were either something internal or something that had my code running that was waiting on something.

It's in a loop of intensive computation (running a genetic programming system), some of which is indeed multi-threaded. It's not waiting.

Are you not able to find the relevant code by going through all the treads?

FYI it's this system https://github.com/lspector/propeller that I'm running with

(require 'propeller.problems.valiant)
(in-ns 'propeller.problems.valiant)
(-main :population-size 100 :variation {:umad 1.0})

Where would I see all of the threads?

(fixed the link above)

I just found this busy code that I wrote specifically to try it on, running in one of the threads on my end, so it's definitely there:

> Where would I see all of the threads? As I mentioned before - the dropdown above all the lines in the stacktrace.

The thing in red.

wow that looks great! checking for threads dropdown...

Ah -- found that and now understand more! However, when I dig in, it's really hard to find actual values... lots of LazySeq@4295 and such...

You can expand such values to at least try to understand what's there. But getting beyond looking at Java objects would require for the JVM to be paused on a proper breakpoint, I'm afraid. What you can do is to pause your code, set a breakpoint at a place that should be hit either next or soon after, wait for it to get that checkmark that means that JVM now knows about that breakpoint, and hit Resume. Then you'll be able to see more.

... and PersistentHashMap@4947, etc... though I can indeed now drill down far enough to get, for example, to an actual symbol that is in a vector that's in a map that's in a sequence... but it seems like it would be a lot of work to actually see the data structure as one would in a REPL...

If I set breakpoints then will I be able to see data structures in a normalish way?

Indeed - because debugging is fundamentally different on JVM than using an interactive REPL.

Well, I would think so but I for some reason get this. @cfleming any clue why? It's just paused on a breakpoint, nothing special, and I haven't started any evaluation.

@U06BV1HCH FWIW, in general it is my impression that Clojure people don't really like working with the debugger and prefer doing each and every experiment via using REPL with generous usages of tap> and some neat tool to view the results, like Reveal. But I understand that it might be unfeasible in some contexts.

In my work I often hit situations where something seems to be going wrong and I want to stop it and look around, see if something has gotten weirdly big, or weird in some other way (maybe gigantic numbers). These situations are hard to predict and hard to recreate, because there's lots of randomness. In Common Lisp I'd just break execution and look at the locals up and down the stack, which would look like they do in the REPL. To use tap for this, I might have to add taps of everything everywhere, right? It seems like we're close to getting what I'm aiming for via Cursive's debugger, except for not actually being able to see data structures without digging and reconstructing them bit by bit.

Perhaps there are some tricks that help with inspecting a running program with a REPL... If you're interested in that, it would be worthwhile asking in the #clojure channel. Along with a question on such run-time debugging in general - there very well might be other tools there that allow that, I'm not familiar with JVM enough to just discard that hope.

Thanks -- I learned a bunch here and may take that question to #clojure