This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-05
Channels
- # announcements (7)
- # beginners (10)
- # calva (14)
- # clj-otel (8)
- # clojure (42)
- # clojure-europe (20)
- # clojure-nl (1)
- # clojure-norway (22)
- # clojure-spec (8)
- # clojure-uk (7)
- # core-async (10)
- # cursive (1)
- # events (1)
- # hyperfiddle (20)
- # introduce-yourself (1)
- # jobs-discuss (11)
- # lsp (48)
- # missionary (3)
- # music (1)
- # off-topic (7)
- # overtone (9)
- # pedestal (21)
- # rdf (1)
- # releases (3)
- # shadow-cljs (22)
- # specter (13)
- # squint (1)
- # yamlscript (3)
Dear Calva friends. In the ^previous thread^ the issue with the flat representation of variables in the Calva debugger frames was brought up. I now have a dev build of Calva that presents a tree-thing for structured values. I would love some help putting it to some tests so that we at least can shake out any crashy things I may have introduced. If you want to help with this please https://output.circle-artifacts.com/output/job/f833653d-4f20-4c15-896c-d59a751dbcb6/artifacts/0/tmp/artifacts/calva-2.0.436-2494-structured-debugger-variables-83f2a684.vsix Thanks in advance! ❤️ 🙏
I have changed how we build the structure to use the TokenCursor instead of doing the cljs.edn/parse -> clj->js
thing. Because too much was lost in the translation to a JS object. Here’s the latest VSIX: https://output.circle-artifacts.com/output/job/6ae01bb7-cc72-4f61-a6bc-85808e87ee70/artifacts/0/tmp/artifacts/calva-2.0.436-2494-structured-debugger-variables-f0dc9661.vsix
I suspect it would be tons of work to try get metadata to be preserved, whichever way we go, so skipping even trying that for now.
Hi @U0ETXRFEW! I gotta say I'm very satisfied with the changes in the debugger frame. It comes really handy as a tree structure. However, when I was testing it, I found a pair of issues not only in WSL2, but also in Windows 10. These issues are not related to the debugger frame, I believe. In the first case, I pressed by chance F11 (debug step by step) when declaring an atom within a let binding and it hanged. If I press F10 it runs normally (picture 1). In the second case, I debugged a function that makes an async HTTP request using the Hato library. Since it returns a MinimalFuture, I was dereferencing the call and eventually it hanged showing the following message (picture 2). In this case it does not matter if I hit F10 or F11. I guess the must be an issue with Futures and Atoms. Maybe this is not the usual way to raise an issue, please let me know...
Hi! Glad you like the changes. As for the issues, it would be great with a minimal repro project. And also if instead of F10 and F11, you say which commands you are using.
I only managed to reproduce the issue with atoms. Here is the link to the repo: https://github.com/javierrweiss/calva-debugger-issues
Thanks for the repro! Please file an issue about it. And include some repro steps either in the README of the project or in the issue. Preferably both. 😃
+ links: project <-> issue. I have tons of tabs and stuff open and I easily lose my track (it’s how my brain works, lots of things going on, while it only really can deal with one at the time, haha). Links helps me a lot.
I have changed how we build the structure to use the TokenCursor instead of doing the cljs.edn/parse -> clj->js
thing. Because too much was lost in the translation to a JS object. Here’s the latest VSIX: https://output.circle-artifacts.com/output/job/6ae01bb7-cc72-4f61-a6bc-85808e87ee70/artifacts/0/tmp/artifacts/calva-2.0.436-2494-structured-debugger-variables-f0dc9661.vsix