This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-12-22
Channels
- # adventofcode (12)
- # announcements (6)
- # aws (5)
- # babashka (57)
- # beginners (40)
- # calva (17)
- # clojure-europe (10)
- # clojure-nl (1)
- # clojure-norway (21)
- # clojure-uk (3)
- # clojuredesign-podcast (4)
- # cursive (3)
- # datomic (9)
- # etaoin (5)
- # fulcro (12)
- # hyperfiddle (42)
- # missionary (2)
- # off-topic (11)
- # reagent (6)
- # scittle (131)
- # squint (3)
- # tools-deps (4)
- # uncomplicate (1)
- # vscode (1)
I found today that if I evaluate namespace on save then it ignores all of my #dbg
and #break
hints. But if I evaluate a single form containing them, they’re active. Is this expected?
This is expected behavior: https://calva.io/debugger/#loading-the-file-and-eval-on-save
I had some odd behavior on eval on save. On file load, it would fail and say a certain name was not found. Then if i evaled that form , the. Then whole file would load. It was a macro definition form, but other ones are working. In general, i feel like i’m getting unreliable behavior for dependant namespaces to load/reload. Need to try to explicitly reproduce though.
When you attempt reproduction, @U09D96P9B, have nREPL logging enabled so that we can see what’s being sent and received.
Found one bug on my side where i had a def
of place. (called it before i defined it)
Why would it (re)evaluate file without error though..?
If I understand correctly you satisfied the requirement for the thing to be defined by defining it.
Yeah, i think in this case i had a def out of place.
This is expected behaviorCan it be changed? I. e. if I have eval on save, I would nearly always eliminate all the breakpoints from my code when I try to debug it. Sounds like I should avoid using eval on save to successfully use debugger. Is this what’s recommended?
They don’t play well together, for sure. Can’t really be changed. It’s the way cider-nrepl works.
I guess I will try working with eval on save disabled.
But wouldn’t it make sense to detect breakpoints and do some other type of evaluation of a file on save that preserves the breakpoints?
(Or not detect and always do it such that breakpoints are preserved). What is the fundamental limitation around this?
I now checked how we do evalOnSave and it is not out of reach, I think. We currently use the load-file
op of cider-nrepl, and then breakpoints are simply not honored, but if we would roll our own evauate-file thing using the eval
op, I think it should honor the #dbg
and #break
instructions. You could experiment with this yourself by disabling Calva’s evalOnSave with a #C03DPCLCV9N script. Remembering instrumented vars would take more work, but should be possible too.
For now I just disabled the evalOnSave in settings.json. Oh, I see. You suggest to write a joyride script to conditionally eval on save depending on the file content?
I think that it is the load-file
op that evaluates the file in such a way that the debugger readers are ignored. But if you evaluate all code in the file, those reader tags should be honored. I’d test that first (select all code and evaluate the selection). If that works, then a joyride script can be made that watches for file save and if it is a Clojure file it then evaluates the code in the file towards the repl. The Calva extension API exposes a function for evaluating code. https://calva.io/api/
We could also consider just changing Calva’s eval on save to evaluate the content of the file rather than using load-file
. I’m not sure what the implications are, though, I think load-file may reload dependencies, while eval selection will only do that if the requires have :reload
or :reload-all
specified.
Interesting. Thanks for the details.