@piotrek I'm using it

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.

I’d be interested to know what the problems were and if they might be related.

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.

track-state is a CIDER middleware

but I don’t understand what’s the issue with the intellij classes

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.

seems that the ns obfuscation step done by mranderson is causing some issues

but @benedek is definitely the expert on mranderson-related stuff

When that exception is thrown, the correct classloader is still set to both Compiler/LOADER and the TCCL

Ok, the problem is in clojure.java.classpath

It assumes that every classloader in the hierarchy is a URLClassLoader

Which seems… ambitious

hehe

there’s a reason we opted to use ns rewriting instead of classloader isolation

it seems that nobody could get the classloader isolation to work properly on a non-trivial project

I’m keen to hear it

I dunno, Cursive runs Leiningen in a shim now

Although it was several weeks of pain to get it to do so

if you write some blog post about this I’d be very happy to read it

That’s unlikely to happen any time soon unfortunately, at a minimum until after the conj.

I’m not sure what to do about this.

The class of that classloader is not available inside the shim, so I can’t extend the clojure.java.classpath protocol to it.

😞

https://github.com/clojure-emacs/cider-nrepl/issues/143

btw, if you’re in the reading mood yourself you can take a look at this ticket and the once that reference it

to see how we ended up where we did

Ok, I’ll take a look when I get a chance.

In the meantime, I’d like to politely suggest that the classpath code is wrong.

You can’t make that sort of assumption about the classloaders you’re running in.

by the time I arrive mranderson is cleared. cool

@benedek: Yeah, you’re off the hook

I reported this as http://dev.clojure.org/jira/browse/CLASSPATH-7, in case anyone is interested.

@cfleming: 10x