This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-13
Channels
- # announcements (10)
- # aws (1)
- # babashka (8)
- # babashka-circleci-builds (1)
- # beginners (67)
- # calva (4)
- # cljs-dev (42)
- # clojars (4)
- # clojure (213)
- # clojure-dev (4)
- # clojure-europe (18)
- # clojure-nl (1)
- # clojure-uk (8)
- # clojurescript (13)
- # conjure (6)
- # cursive (63)
- # data-science (5)
- # datomic (11)
- # events (1)
- # graalvm (2)
- # graalvm-mobile (1)
- # honeysql (4)
- # kaocha (3)
- # leiningen (19)
- # lsp (32)
- # malli (3)
- # meander (13)
- # news-and-articles (3)
- # off-topic (8)
- # polylith (5)
- # re-frame (47)
- # reitit (2)
- # shadow-cljs (28)
- # sql (3)
- # tools-build (4)
- # tools-deps (51)
- # uix (9)
- # xtdb (3)
hello, @cfleming, I love the test runner on Cursive, but currently it seems quite limited to only basics of clojure.test, I'm recently migrating to use the check library (https://gitlab.com/mauricioszabo/check), this library uses all the same constructs of clojure.test under the hood (its under deftest, and the reporters use the same do-report
, as the is
macro does), Cursive is able to correctly identify the test line and it's results as in the image attached (it gets green if the test is succeed). the real issue is that in this case I'm unable to see the error, clicking on the marker doesn't do anything (expect trying to add a debug point on that line). Also, if I run the check
assertion directly (evaluating on the REPL), in case of error I get a nice diff report, but seems like Cursive does swallow that, and when I run from Cursive I get no report back. Could that be improved? If clicking on the !
just opened the reported data, it would be great!
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)
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.)
@U0HJA5ZQT That’s probably https://github.com/cursive-ide/cursive/issues/2574, which is fixed in the latest Cursive EAP
I'm having trouble with Cursive + deps.edn + git coordinates. Whenever I supply a specific git coordinate in deps.edn (ie, :git/url
and :sha
), Cursive does not recognize that library and it does not get included in a launcher classpath. The same deps.edn file works flawlessly using clojure
directly from the linux shell. Some (possibly) relevant info:
• In Settings, I have selected "Use CLI tools" and the path points to the same location for clojure
as I have from the shell
• When I specify a git library in deps, I do not see it in the Project->External Libraries list but I do see all of my maven libraries there
• clj -Sdescribe reports:
{:version "1.10.3.933"
:config-files ["/home/markaddleman/.linuxbrew/Cellar/clojure/1.10.3.933/deps.edn" "/home/markaddleman/.config/clojure/deps.edn" "deps.edn" ]
:config-user "/home/markaddleman/.config/clojure/deps.edn"
:config-project "deps.edn"
:install-dir "/home/markaddleman/.linuxbrew/Cellar/clojure/1.10.3.933"
:config-dir "/home/markaddleman/.config/clojure"
:cache-dir ".cpcache"
:force false
:repro false
:main-aliases ""
:repl-aliases ""}
• I have tried deleting ~/.gitlibs
but that does not seem to help
I'm not sure what additional information would be helpful to debug this problemthis could be related https://clojurians.slack.com/archives/C0744GXCJ/p1628700544077600
Hello! I am playing with https://github.com/cognitect-labs/day-of-datomic-cloud which uses <name>.repl
files, which I mapped to Clojure. I use clojure.main
type of REPL. Now when I Cmd-Shift-P, the current top form is not sent to the REPL. Is that something that simply does not work with clojure.main REPLs and I need to get a nREPL? 🙏
Update: I switched to an externally started nrepl but the same problem persists. Using the Tools > REPL > Send '..' menu has the same, i.e. none, result
Associating .repl file with the Clojure file type and restarting IntelliJ fixed it (not all the steps might have been necessary thoug hte restart was likely crucial)
Downgrading to 0.10.889 worked! Thanks!
Associating .repl file with the Clojure file type and restarting IntelliJ fixed it (not all the steps might have been necessary thoug hte restart was likely crucial)
Does Cursive provide a way to break a long-running program, without having set a break point, and examine locals up and down the stack from the point of the break?
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.
Thanks @U2FRKM4TW! Where and how does one provide `-Dclojure.compiler.disable-locals-clearing=true` in advance?
It's an option for Java. All the build tools out there support providing arguments to the java
executable.
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:
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?
Huh -- even with the locals clearing disabled, no matter when I pause it I don't see the frames or locals I'm expecting.
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.
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})
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.
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...
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.