I’m not aware of an issue with this, but I do know the breakpoint finding logic for where to place the cursor is not perfect. It’s likely that there’s an issue in the function for finding the breakpoint. https://github.com/BetterThanTomorrow/calva/blob/5e124de90c70770a080d766351703c631c3699f6/src/debugger/util.ts#L20 If you’re interested in digging in, you can try running Calva in development mode and setting a breakpoint in that function and seeing if there’s an issue there. A GH issue is welcome too, and then if you or someone else who uses the debugger wants to look more into later, I’m happy to help and review a PR.

"I’m not aware of an issue with this" Yeah, I guess this behaviour is what you would expect. If you step through code that includes lazy infinite sequences and the debugger evaluates the whole sequence to display the value then you are going to get an error were as the code is valid.

Just to whittle down an example to essentials.

#dbg
(defn something [] (take 5 (repeat 1)))

(comment (something)
         ;; => Execution error (OutOfMemoryError) at java.util.Arrays/copyOf (Arrays.java:3537).
         ;;    Java heap space
)

Oh, sorry, I was not thinking correctly about it before.

I may have written that entry. 😆

Cursive doesn't display values of un-realized lazy sequences I think

I like the approach of being able to say how much of it you want to see

as Calva allows