This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-22
Channels
- # admin-announcements (29)
- # aws (2)
- # beginners (25)
- # boot (110)
- # business (15)
- # cider (39)
- # cljs-dev (3)
- # clojure (90)
- # clojure-czech (28)
- # clojure-hamburg (1)
- # clojure-japan (24)
- # clojure-poland (149)
- # clojure-russia (46)
- # clojure-sg (9)
- # clojure-uk (6)
- # clojure-ukraine (1)
- # clojurescript (105)
- # core-async (37)
- # cursive (9)
- # dato (7)
- # datomic (6)
- # emacs (10)
- # events (1)
- # hoplon (22)
- # jobs (4)
- # ldnclj (38)
- # leiningen (4)
- # off-topic (17)
- # om (173)
- # onyx (134)
- # re-frame (46)
- # reagent (35)
In case anyone is interested in GPU and other high-performance computing, new version of ClojureCL has just been released. ClojureCL 0.3.0 is available in Clojars. http://clojurecl.uncomplicate.org
Does this error look familiar to anyone?
java.lang.IllegalArgumentException:
No implementation of method: :urls of protocol:
#'mranderson045.javaclasspath.v0v2v2.clojure.java.classpath/URLClasspath
found for class: com.intellij.util.lang.UrlClassLoader, compiling:(track_state.clj:57:8)
No implementation of method: :urls of protocol:
#'mranderson045.javaclasspath.v0v2v2.clojure.java.classpath/URLClasspath
found for class: com.intellij.util.lang.UrlClassLoader
It’s an error in Cursive, but it seems to be provoked by having the CIDER nREPL plugin in the user’s profile.
If you also have refactor-nrepl middleware enabled, it may be the https://github.com/clojure-emacs/refactor-nrepl/issues/126
No, profiles.clj
is:
{:user
{:plugins [;; add plugins for all projects below
[cider/cider-nrepl "0.10.0-SNAPSHOT"]
[lein-localrepo "0.5.3"]
[lein-pprint "1.1.1"]
]
:dependencies [;; add deps for all projects below
;; [org.clojure/tools.nrepl "0.2.7"]
[org.clojure/tools.nrepl "0.2.10"]
[spyscope "0.1.5"]]
:injections [(require 'spyscope.core)]
}
}
Interesting that @benedek says there that classloader isolation didn’t work out for them, since that is what Cursive is now using.
Actually, what is happening there is that it’s picking the wrong classloader for some reason: com.intellij.util.lang.UrlClassLoader
is the root of the classloader hierarchy.
I don’t understand why it would do that - when calling this, both Compiler/LOADER and the thread context classloader are set to a DynamicClassLoader.
When that exception is thrown, the correct classloader is still set to both Compiler/LOADER and the TCCL
it seems that nobody could get the classloader isolation to work properly on a non-trivial project
That’s unlikely to happen any time soon unfortunately, at a minimum until after the conj.
The class of that classloader is not available inside the shim, so I can’t extend the clojure.java.classpath protocol to it.
btw, if you’re in the reading mood yourself you can take a look at this ticket and the once that reference it
I reported this as http://dev.clojure.org/jira/browse/CLASSPATH-7, in case anyone is interested.