This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-25
Channels
- # announcements (1)
- # beginners (338)
- # calva (41)
- # cider (19)
- # cljdoc (10)
- # cljsrn (6)
- # clojure (116)
- # clojure-europe (15)
- # clojure-italy (25)
- # clojure-nl (5)
- # clojure-spec (19)
- # clojure-uk (52)
- # clojurescript (99)
- # clojurex (14)
- # cursive (47)
- # data-science (1)
- # datomic (5)
- # duct (1)
- # figwheel (13)
- # fulcro (58)
- # graalvm (93)
- # jobs (3)
- # joker (9)
- # luminus (4)
- # nrepl (21)
- # off-topic (41)
- # pathom (25)
- # re-frame (7)
- # reitit (8)
- # ring-swagger (13)
- # tools-deps (13)
Hey guys,
Maybe somebody already asked this: Something that annoys me and I can’t find a way to change the default behavior is when I’m debugging and try to evaluate expression. It works with var bindings, but when I have function calls I get “unable to find symbol in this context”.
Apparently the debugger defaults current namespace to clojure.core
, which is weird. Found out by evaluating *ns*
. I can fix by either prepending namespaces to functions or (in-ns '<namespace>)(<code>)
. Wondering if there’s a way to reset the default namespace to the currently opened file or some other trick that could help avoid prepending namespaces every time.
ok, so thanks to @cfleming I found out that I need to be using tools.deps directly and there's no support for the cli; however when hitting the Refresh
button I'm getting locator.getService(RepositorySystem::class.java) must not be null
; this is the full exception:
locator.getService(RepositorySystem::class.java) must not be null
java.lang.IllegalStateException: locator.getService(RepositorySystem::class.java) must not be null
at cursive.artifacts.ArtifactManager.newRepositorySystem(ArtifactManager.kt:86)
at cursive.artifacts.ArtifactManager.<init>(ArtifactManager.kt:44)
at cursive.artifacts.ArtifactManager.<init>(ArtifactManager.kt:38)
at cursive.deps.DepsSystemSettingsControl$$special$$inlined$apply$lambda$5$1.run(DepsSettings.kt:389)
at com.intellij.openapi.application.impl.ApplicationImpl$2.run(ApplicationImpl.java:307)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Let me know if anyone has seen this and what are some possible reasons for that exceptionOh, I just realised what this might be - do you have the Maven support enabled? It’s possible that there’s a bug there when it’s not.
@cfleming sorry, just realized that you're the right guy to talk to about Cursive 😂; I'm using Intellij only for Clojure (and a tiny bit of Haskell) so I'm not very familiar with Maven; what is that support and how can I make sure that it is enabled?
@cfleming - I'm using intellij only for Clojure projects, so I'm not sure what Maven support enabled
means - can you elaborate on that one?
@U8XSMEQS0 There’s a Maven plugin in IntelliJ - you can go to Settings->Plugins and make sure it’s enabled, and enable it if it’s not.
@cfleming - it was enabled; disable->enable did not help; however since my intellij has not been updated for some time I've updated it and things are now working, so at least for me this is solved 🙂; thanks again for your help!
Keep getting this exception, results in the REPL being unusable, keeps trying to write over previous output, and only in a limited number of lines.
Not sure why cursive is blowing up on you, but it looks like it’s reporting a string with “\U” in it (instead of “\\U” possibly?) on line 514 of C:\Users\dave\Projects\Compute\stream-model\customer-dashboard\compute\dashboard.clj. Maybe check that line out?
An exception is being thrown there, so the output is from clojure.
There’s also an error in the cursive.filters namespace, but I suspect if you find the \U
string and replace it with \\U
or whatever you want it to be, that will fix the problem
Ah, it's because I'm running in windows, somewhere the path is not being handled correctly.
That makes sense. It’s reading the path without escaping the backslashes, and boom
Although it seems odd that it would try to eval the contents of the path as a string, hmmm
It could be a hard-coded path (or relative path) that’s missing the escaped backslashes.
Don't know for sure, but I'm guessing it has to do with the first line reporting the file in parens, maybe trying to eval that?
Can you show the code?
The code that's causing the exception? No, though I could see if I can come up with a repro. It was a pretty boring NPE, nothing interesting about the code.
And it happens for any exception, AFAICT
Hmm, that’s very odd. At this point I would try File -> Invalidate Caches & Restart, and/or re-installing Cursive. Something seems to be in a really weird state.
I suppose it could also be some kind of weird dependency conflict too.
Cache clear and restart didn't help. It would be interesting if a dependency conflict affected Cursive. I'll try inducing an exception in a different project and see if I can reproduce the errors.
It does not. Wild.
Very odd.
Think I figured it out. There was an alias in the project that explicitly called out clojure 1.10.1 as a dependency. Removing that solved the problem.
Wow, wild.
@joaohgomes I’ve seen this from time to time but haven’t been able to reproduce it. So you see this just when evaluating function calls?
Hey. Yes. Only when I’m evaluating function calls that are not part of clojure.core
namespace.
This is what happens when I try to eval a fn
….
Thank you for looking into this.
BTW, what is the expected behavior?
@joaohgomes The expected behaviour is that you should definitely be able to call your function 🙂
Thank you!
Since upgrading to 1.8.2-eap-2019.1 and 2019.1.3 I'm having a problem on my epically large project where Cursive marks virtually evertything in a namespace as undefined, even things like defn
, and all my imports are marked as unused. I fixed it the first time by restarting and clearing indexes, can't keep doing that though!
This is happening consistently, even on other projects I'm loading. I have to restart and invalidate caches.
Same thing is happening to me.
@U04VDKC4G @U066LQXPZ This is https://github.com/cursive-ide/cursive/issues/2173, which is caused by an underlying platform issue https://youtrack.jetbrains.com/issue/IDEA-211736. Usually restarting will fix the problem temporarily, but the only definitive solution is to downgrade to 2018.3.
JetBrains said this should be fixed soon and released in a 2019.1 patch, but I haven’t heard from them in a while.
I just got hit by this one during my morning commute! Is the "fix" to downgrade IntelliJ or Cursive or both?
@U0JAE119P You can downgrade IntelliJ to 2018.3, and that will fix the problem. The problem is also often temporarily fixed by just restarting IntelliJ.
Do you have any Java code? That was happening to me, I had to run lein javac
externally.
Perhaps a different issue.