Fork me on GitHub
#cursive
<
2019-09-09
>
currentoor00:09:40

ah i figured it out, it was disabled in the preferences

currentoor00:09:08

i didn’t know it was something you could turn off, and downgrading my intelliJ disabled it

cfleming05:09:36

PSA: there’s a new dev build out of the updated deps integration, if you’re using the first one check it out here: https://groups.google.com/d/msg/cursive/D4yCqNC6iiM/Bc4-EKbaAQAJ

👍 8
kenny17:09:16

I have been getting this message fairly often when using the dev build. I don't remember getting it before switching to the dev build so this may be a regression.

kenny17:09:02

It usually only happens when I alt+enter to require a ns.

tony.kay20:09:10

Sometimes that happens if you accidentally have classes on classpath twice..e.g. if you’ve built an uberjar to target and the classes in there end up on classpath.

kenny20:09:56

Pretty sure nothing has changed in these projects besides updating to the Cursive dev build.

cfleming00:09:40

If you do Navigate | Namespace… and search for clojure.test.check or clojure.test.check.clojure-test, do you see multiple copies of either of them?

cfleming01:09:27

It’s possible that the new integration has some differences around how it handles excluded folders.

kenny01:09:34

Will try this tomorrow.

kenny20:09:23

This is what shows up

cfleming22:09:23

Hmm, it looks like you have a bunch of different test.check versions there.

kenny22:09:52

No idea why. There can only be one on the classpath.

cfleming00:09:34

That’s probably the reason for the spurious dependency cycle error. I’ll add some code that logs some debug information when cycles happen so we get a clearer idea of what’s going on.

kenny00:09:33

Still getting this message. Does the latest build have that debug info?

cfleming01:09:56

Yes - go to Help | Debug log settings…, then add #cursive.repl.actions to the box there. Then reproduce, and check your log. You should see some debug log at the end showing the dependency cycle and the files which those namespaces are found in.

kenny21:09:10

It just occurred and I don't see anything obvious in the logs. What should I look for?

cfleming22:09:53

You should see something like this:

2019-09-20 10:32:24,984 [  74368]  DEBUG -          #cursive.repl.actions - Namespace cycle: clj:dependency-loop-log.core (/Users/colin/dev/cursive-bugs/dependency-loop-log/src/dependency_loop_log/core.clj) -> clj:dependency-loop-log.core2 (/Users/colin/dev/cursive-bugs/dependency-loop-log/src/dependency_loop_log/core2.clj) -> clj:dependency-loop-log.core (/Users/colin/dev/cursive-bugs/dependency-loop-log/src/dependency_loop_log/core.clj) 

cfleming22:09:49

Oh, actually - don’t think you’re getting that message when I thought you were. When is that occurring?

kenny22:09:14

I don't see that. It happens when auto-importing something.

cfleming22:09:32

Right, I see. I’ll add the log in that case too - that error usually appears when trying to load a file in the REPL. One thing you could try is opening the clojure.test.check namespace and trying to load it into your REPL. That should show the current log.

kenny23:09:08

How would I open that namespace?

kenny23:09:39

Simply ctrl+clicking into it and trying to load it in the REPL results in "It is not in scope ... "

cfleming00:09:05

Ugh, ok. Sorry, I’ll add that extra logging and it’ll be in the next build.