Well, I’d really love it for us to fix this. In the mean time I’ve added a section in “Troubleshooting” about refactor-nrepl, which probably no one read. 🙂

The problem is that refactor-nrepl does this injection, not CIDER. I think the simple solution would be for refactor-nrepl to check the CIDER version before injection itself and just skipping this injection for incompatible versions.

Anyways, my involved in the refactor-nrepl project is almost 0, which is another reason for this state of affairs. I would have synched the releases, but I don’t have time for more projects.

@bhauman We don’t have dep injection for cljs, as it’s a bit more involved. Currently the code is written in a way that you get asked about the REPL to start fairly late in the init process and because of this you don’t really know what to inject (after a clj REPL has already started). Another nice way to solve this would be to add some hotloading functionality to CIDER, so you’d be able to add the cljs deps after you’ve started a clj REPL.

@benedek Is this functionality in refactor-nrepl complex? Would it be feasible to move it?

well it is not that bad as it leans on a dependency, alembic to do the heavy lifting. but alembic is unmaintained not compatible with java9 +

There's a function in tools deps alpha that does it now

I would guess it works with 9

And you also need to retriebe libs you want to load via http i guess

Seen that @dominicm

My plan is to rewrite it the feature

Could go to cider but yeah it is pretty complex

Sorry for the typos. On my phone

Got it.

@dominicm I also saw this feature and I was wondering whether we can just take this and stuck into some middleware.

I find it odd that adding libs at runtime is still not a solved problem in Clojure after all those years.

I thought it was? Chas' library offered this functionality for maven

You mean alembic, right?

https://github.com/cemerick/pomegranate/blob/master/README.md has the Loading too

Just call the add class path function

But this stopped working Java 9+.

(the classloader changes)

I think this is what @benedek referred to.

I don't understand the problem yet. TDA just uses the closest Clojure dynamic class loader. Why don't people running cider have one of those?

Clojure's addUrl is private and I think always has been.

All the code I’ve seen for dynamic loading libraries used an URLClassLoader.

Previously reflection was used to hack it public, which stops working in 9/10.

Boot and some other things have their own bootstrap runtimes precisely to inject their own dynamic class loader as high as they can.

At least that's my understanding from some poking at this issue and build tooling

https://github.com/cemerick/pomegranate/commit/8d964e35cfc1ba0d8c46e30da8c424fb8a541f85

I haven’t played with that much, I just know what we were doing got fucked up recently. 🙂

The one in Clojure seems public https://github.com/clojure/tools.deps.alpha/compare/add-lib doesn't seem too complex

But I seemed to recall it (currently) doesn’t work with nREPL properly (or something like this).

Probably because of a different classloader hierarchy.

I suspect we will need to look there to find a solution then.

yup, this issue starts with researching this a bit i suppose. and checking out in detail what the core team is coming up with re. @dominicm and clj tooling support for this

True. So, did I get this right - @dominicm is our volunteer to research this? 😉

Pretty much 🙂

That's fine by me though.

hahaha, that would be super nice. i intend to do the same if I by same luck/miracle get some time for it

so @dominicm would be very grateful here if you have/time energy

You've given me a puzzle now, there's no way I'm not going to figure it out

this is how far i got with it: https://github.com/clojure-emacs/refactor-nrepl/issues/206

see specially https://github.com/clojure-emacs/refactor-nrepl/issues/206#issuecomment-359267034

@dominicm Good man! 🚀

if it is an nrepl problem, then t.d.a.r/add-lib wouldn't work with nrepl

tdar sounds like ta-da

😄

I don’t what problems is it or if there’s even a real problem - just remember seeing some Twitter thread after Alex Miller announced this feature.

http://insideclojure.org/2018/05/04/add-lib/

this is what we are talking about, right?

wonder if this works under java9+ at all…

and https://github.com/clojure/tools.deps.alpha/tree/add-lib

tools.deps.alpha is tested on openjdk 9 so i guess it should work

but it is all down to the classloader hierarchy really…

@bozhidar it seems like it would be safe to add piggiback to the deps and place it in the middleware if a cider-jack-in-cljs is called. Simply because its a no-op until you execute the piggie/cljs-repl call

It's only extra dependency is clojurescript ... and that is required anyway

isn't there only one repl (shadow) that doesn't need it?

Yeah, that’s easy - I was mostly referring to what to do with the actual deps like figwheel. Ideally we’d have to change the current logic now to first ask for the actual cljs REPL to run, inject all the deps, start and convert the clj REPL.

oh I'm not talking about requiring figwheel

but I what you are saying

> isn’t there only one repl (shadow) that doesn’t need it? Yeah, it doesn’t use it, but probably it won’t be a problem to have it around regardless.

I think getting piggieback in there early would be a big boon, and would get rid of the complexity here: https://cider.readthedocs.io/en/latest/clojurescript/

Also, I'd love to know how to decorate cljs errors so that you can get line, column and stack info. I can make an issue on piggieback?

> I think getting piggieback in there early would be a big boon, and would get rid of the complexity here: https://cider.readthedocs.io/en/latest/clojurescript/

I agree. It’s not a complete solution, but it’s a good (and simple first step).

> Also, I’d love to know how to decorate cljs errors so that you can get line, column and stack info. I can make an issue on piggieback?

Sure. Basically you just have to get them in the same format as the Clojure errors in terms of line structure.

You mean format the error message text.

Yeah, exactly.

How do they look right now?

oh they are all over the place, as there are many different kinds and it depends on the context

I have a way to turn them into data

(defun cider-extract-error-info (regexp message)
  "Extract error information with REGEXP against MESSAGE."
  (let ((file (nth 1 regexp))
        (line (nth 2 regexp))
        (col (nth 3 regexp))
        (type (nth 4 regexp))
        (pat (car regexp)))
    (when (string-match pat message)
      ;; special processing for type (1.2) style
      (setq type (if (consp type)
                     (or (and (car type) (match-end (car type)) 1)
                         (and (cdr type) (match-end (cdr type)) 0)
                         2)))
      (list
       (when file
         (let ((val (match-string-no-properties file message)))
           (unless (string= val "NO_SOURCE_PATH") val)))
       (when line (string-to-number (match-string-no-properties line message)))
       (when col
         (let ((val (match-string-no-properties col message)))
           (when val (string-to-number val))))
       (aref [cider-warning-highlight-face
              cider-warning-highlight-face
              cider-error-highlight-face]
             (or type 2))
       message))))

well thats helpful

That’s the code in CIDER that processes errors/warnings and maps them to the source buffers.

And that’s the regexp:

(defvar cider-compilation-regexp
  '("\\(?:.*\\(warning, \\)\\|.*?\\(, compiling\\):(\\)\\(.*?\\):\\([[:digit:]]+\\)\\(?::\\([[:digit:]]+\\)\\)?\\(\\(?: - \\(.*\\)\\)\\|)\\)" 3 4 5 (1))
  "Specifications for matching errors and warnings in Clojure stacktraces.
See `compilation-error-regexp-alist' for help on their format.")

(which we can obviously change if we have to)

would it be a bad idea to have a data protocol?

where we send this info directly, and then fall back to parsing the string?

I'm sure that's a bigger change

A data protocol would certainly be preferable - when I was starting out I was limited by the fact that no one wanted to make changes neither on Clojure or nREPLs side. 🙂 (and we didn’t use middleware back then)

I totally get you there

there is also Throwable->map which is interesting

is there any word on getting nrepl under the clojure-emacs team?

I've just created a new project (Luminus template +cider etc.). I updated the cider dep to 0.17.0 and jacked in from a ClojureScript file. I updated all my Emacs packages. I'm getting "WARNING: CIDER's version (0.17.0-snapshot) does not match cider-nrepl's version (0.17.0). Things will break!" I can't see who is loading the snapshot version.

Hmm, in [Messages] I see "Starting nREPL server via lein update-in :dependencies conj \[org.clojure/tools.nrepl\ \"0.2.13\"\ \:exclusions\ \[org.clojure/clojure\]\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.17.0-SNAPSHOT\"\] -- repl :headless :host ::..."

You could try lein deps to see if that explains anything. Traditional culprits are profile.clj

@benedek Clojure adds a dynamic class loader when it starts.

@deg How did you do the update?

@dpsutton No, I guess @cemerick is busy and he hasn’t seen the ticket.

@dpsutton lein deps :tree shows only 0.17..0. And nothing interesting in my ~/.lein/profies

that's weird that it shows that. do you know why?

this should be injected solely by CIDER. ie, your project shouldn't have any knowledge of it

Came from the Luminus template

Actually, the template had 0.15.1 and I updated it when warned by lein ancient

delete it from the tmeplate

let cider manage it

What brings in Cider?

i thought you said it was in the template

Yes. I think we are talking past each other. ....

Luminus template created project.clj project.clj now contains

:dependencies [...    [cider/cider-nrepl "0.17.0"] ...

All mentions of Cider in project are:

./src/clj/diffusion/core.clj:6:            [cider.nrepl :refer [cider-nrepl-handler]]
./src/clj/diffusion/core.clj:31:                   :handler cider-nrepl-handler }))
./project.clj:7:                 [cider/cider-nrepl "0.17.0"]
./project.clj:52:   [cemerick.piggieback/wrap-cljs-repl cider.nrepl/cider-middleware]}

Ah... should line 52 go away? Was it needed in 0.15.1?

no. it hasn't been needed since 9 or so i believe. just strip out all mentions of cider-nrepl. CIDER has been configured to inject its own dependencies so that you don't have to worry about keeping the behind the deps and the emacs version in sync

Hmm, I'm surprised that Luminus gets this wrong. So, you are saying that I should kill both lines in core.clj, right? And in project.clj, I assume I need to keep line 7, but should kill 52?

(fixed major typo there ... read edited version)

I don’t think that’s a problem - I’m more curious why you’ve got CIDER 0.17-snapshot on the Emacs side.

Ah, I see. You really meant to remove all 4 lines. What magic you wizards weave! 🙂

That’s why I asked how exactly did you do the upgrade. Maybe you didn’t restart Emacs afterwards?

I did an update i M-X List Packages... one sec, I'll check details.

And, definitely did a restart. My UPS battery died last week and we had a power blip so, umm, yeah, I did a restart. 😞

This is the Cider listed in List Packages: cider 20180509.109 installed Clojure Interactive Development Environment that Rocks

(my text reads funny. Meant to say that the battery died last week, I have't replaced it yet; and had a power blip today right after updating Emacs)

Hmmm... My Cider is 0.18.0snapshot in the header comment. I wonder if you updated to 0.18 and put in the word snapshot, but left "17" someplace?

I don’t think so.

Just checked this.

But at any rate - if you’re using MELPA the chance is that you’d be either 0.17-snapshot or 0.18-snapshot. It’s unlikely you’ll be on 0.17 stable.

Ah, I didn’t read the message carefully - yeah, you had installed 0.17-snapshot and from luminos you had the wrong middleware overriding the one CIDER injects itself. Mystery solved. 🙂

I still don't see where I had installed 0.17-snapshot. As far as I can see, I had 0.17 from my edit of Luminus, and 0.18-snapshot from MELPA.

Oh I misunderstood the confusion sorry. Have you restarted emacs since upgrading? And you could grep the elpa directory for the version string. Also check mx cider-version

Ok, I am trying to switch to use-package so I can have most things come from melpa-stable and get clj-refactor from melpa. I think I have that mostly set up, but for some weird reason I do not see any versions of clj-refactor from melpa. I only see the ancient 2.3.1 from melpa-stable!

@deep-symmetry What does your package-archives look like? Use package pulls from there, so unless you have ("melpa" . "") in there, it won’t know about it.

Sorry, my fault… I did have melpa in there and was seeing other snapshots, but I had accidentally pinned clj-refactor to melpa-stable in overzealous use of my keyboard macro to change to using use-package.

@bozhidar Chas just transfered the repo!

welcome https://github.com/clojure-emacs/nREPL

Sigh. But now I have CIDER 0.17.0 and refactor-nrepl 20180420.223 installed, and am still seeing this crash trying to jack in:

error in process sentinel: Could not start nREPL server: Could not find artifact refactor-nrepl:refactor-nrepl:jar:2.4.0-SNAPSHOT in central-mirror ()
Could not find artifact refactor-nrepl:refactor-nrepl:jar:2.4.0-SNAPSHOT in clojars-mirror ()
Could not find artifact refactor-nrepl:refactor-nrepl:jar:2.4.0-SNAPSHOT in releases ()
Could not find artifact refactor-nrepl:refactor-nrepl:jar:2.4.0-SNAPSHOT in snapshots ()
This could be due to a typo in :dependencies, file system permissions, or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment variable.

Ah, that looks local.

Temporarily turning off our clojars mirror allowed me to download the snapshot, I will have to talk to the person who set that up to find a more permanent solution.

I am trying to get cider to work with clj 1.9, but I keep hitting this error: Error loading cider.nrepl.middleware.test: java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures

I have looked at various issues reporting this or things very close to it and have tried many combinations of cider/n-repl and tools.nrepl. It has defeated me at every step. If I go back to 1.8 things just work - no matter what combination of those I use. I know this has something to do with a change in 1.9 that now enforces an intent on :: keywords, but at this point I would have thought cider/n-repl 17 and tools.nrepl 2.13 would have the changes to fix this. Does anyone have any suggestions?

that was due to a change in keywords. in 1.8 ::fully-qualified-namespace/var was legal. in 1.9 it no longer is. now its ::alias/var. This was updated in cider-nrepl a long time ago. can you tell me what version of cider you are on?

https://github.com/clojure-emacs/cider-nrepl/commit/b2d04f95c1d59bf8dc0df08f1b7273e914597763

wow. comments in that thread talk about a 0.15.1 release which will publish the fix. how old is your cider?

(assuming its the same issue @jsa-aerial)

As I mentioned - I know this has to do with a change in :: keyword processing and that I have tried all combinations of cider/n-rrepl from 0.13 up through and including 0.17.0 with both tools.nrepl 0.2.12 and 0.2.13

can you delete the artifact in ~/.m2/repository/cider and make sure you're on a recent cider?

You mean delete the entire directory recursively?

i want to make sure you pull a new cider-nrepl artifact. the hope is that its one with that fix. i would just remove ~/.m2/repository/cider

OK, something does seem weird - when I look in there I do see 0.15.1 and 0.16.0, but not things like 0.13 and 0.17 - despite having put those in the project.clj and saw what appeared to be dowload messages first time used.

cider injects its own dependencies. just change your emacs cider version and you should get the correct (and matching) cider-nrepl

(cider-add-to-alist 'cider-jack-in-lein-plugins
                    "cider/cider-nrepl" (upcase cider-version))

I'm not even running emacs cider at this point - just tying to get lein repl to run

oh. well then grab the latest cider-nrepl and try that then

but if you're not using CIDER why do you have a dep on cider-nrepl?

I have - I used both 15.1 and 0.17 - neither worked. But as I say, oddly 17 wasn't even in the repo (?!?)

i'm not sure that you have tried 0.17 then

it was in the project.clj when lein repl was invoked ...

I've cleaned up the repo area - let me see if things are any better now

OK, maybe this has something to do with where I'm putting these in the project.clj. I have them in [:profiles :dev], and maybe the ~/.lein/profiles.clj stuff is overriding that?

yeah lein profile merging is complicated i've heard. why do you want to put cider-nrepl into any of those?

do you use vim fireplace or something?

OK, putting those at the 'top level' fixes the original problem but now introduces Error loading refactor-nrepl.middleware: java.io.FileNotFoundException: Could not locate cider/nrepl/middleware/util/misc__init.class

Generally I would only put the dependencies in ~/.lein/profiles.clj, but in this particular case I was trying to see if things would actually work before committing to moving to 1.9

why do you want to put an explicit dependency on cider-nrepl? I still don't follow your use case

I never use jack in - I always start separate servers and connect. I have found that to be far more useful and productive

ah ok. i follow you.

I'm guessing I now have some odd mismatch with refactor-nrepl. I suppose I could get rid of that altogether - I find I don't really use if much

Yeah, refactor-nrepl is just broken - if I remove it from plugins things now work - and I was using the most recent version 2.3.1. I've had a lot of problems with it in the past as well. There are some nice things in it but it just doesn't seem to play well with the rest of the stack

^^^ If you use 2.4.0-SNAPSHOT of refactor-nrepl it works - there are multiple issues on this and suggestion to use the snapshot with latest cider-nrepl...

Yeah, as I mentioned a few times - the development of refactor-nrepl is mostly independent from CIDER and the releases are sometimes out of sync.

Not much I can do about this.

@arrdem

Now it’s time to figure out how to handle the first release. Likely I’ll follow the original plan and just release nREPL 0.3 with a new coordinate and the old namespace and afterwards we have to decide how to handle the ns transition.

Changing the namespaces in our projects is easy, but that’s we might have to create new tasks for boot and lein until the dep gets changed upstream.