i think @bronsa made some changes in that for cljs. and those changes are needed for cljs. but i'm not sure why the conflict happens

I'm having trouble making a minimum reproducible example. It seems to be related to something cider-jack in does differently than lein run and it only happens with certain code (which I'm trying to determine now - maybe compojure middleware).

and with cljs build otimizations on none? just hoping the offending stuff isn't being DCE

@pauld https://github.com/clojure-emacs/cider-nrepl/blob/master/project.clj#L23

Thanks @bozhidar. Now I'm having a hell of a time trying to make a minimum project to reproduce this. In a complex project it gets the error when it tries to compile (or read?) the ring.middleware.format dependency. But in a bare project I can read put this in my core namespace without issues.

Somehow on one of my projects I can get cider to use tools.reader 1.3.0-alpha and make it not find the tools.reader.impl/reader-error var in the same dependency.

It's like it has a split brain, reaching into on dependency of jar for one thing and into another for something else? Maybe deleting .m2 will help.

Keep in mind the CIDER dep is inlined and it’s ns is changed to avoid clashes with user deps. That means users can’t really override what CIDER uses internally.

Btw, @gonewest818, looking at https://github.com/clojure-emacs/clojure-mode/pull/472 I was reminded we could elint for clojure-mode as well.

@bozhidar low hanging fruit for a new contributor? 🙂

But yeah, I can look at that. I’m trying to get to the bottom of cider #1115

It doesn’t make sense to me why the spinner sometimes runs indefinitely once there is a long line of output in the repl buffer.

My hunch is no processing is actually happening (other than the spinner).

I have edebug on cider-eval-spinner-handler and it isn’t getting called.

Thanks @bozhidar Still, very interesting / strange that my error goes away when I put in an explicit tools.reader "1.2.2" dependency. This big complex project (yogthos/memory-hole) seems to be doing something unusual. Very mysterious!

> But yeah, I can look at that. I’m trying to get to the bottom of cider #1115

No rush for the elint, everything cider-related is way more important. 🙂

> My hunch is no processing is actually happening (other than the spinner).

Or some processing is happening elsewhere. But I guess the debugger will reveal this soon enough.

@gonewest818 I seem to recall something was amiss when debugging those handlers and the debugging wasn’t reliable then. Might be just my flimsy memory, but some classic print-style debugging might be a good idea just to be on the safe side. 🙂

@bozhidar that’s what I’m now doing.

🙂

@dpsutton @bozhidar debugged the test-all not running anything on windows. the root cause seems to be that orchard.NAMESPACE/ptoject-namespaces returns empty coll

reason behind that, wait for it... wait for it...

that project root returns c:\\data while stuff on the classpath is like C:\\data

notice lower/upper case diff

would you guys be open for a PR lowercasing both sides of the comparison in project-namespacesfunction?

@benedek We should be careful what we lowercase, because Unix filesystems are case-sensitive.

I guess we should do the lowercasing only on Windows.

you are right ofc

it's there any plan to support cider with tools.deps?

@bozhidar cemerick is offering me commit and deploy rights for piggieback, I'm happy to do it, but I was wondering if you guys were interested?

seems like a better long term home for it

I'm happy to do myself of course

@bhauman I was about to ask him on this ticket to make at least me a co-maintainer. As CIDER is one of the biggest users of nREPL I really want us to be able to make improvements ourselves here and there.

> it’s there any plan to support cider with tools.deps?

@doglooksgood That’s already done in 0.17 (the current development version).

@bozhidar well the easy path for now is to get commit and deploy rights for us both, and I'm thinking long term bring it over to clojure-emacs org

That’d be great! :thumbsup:

@bozhidar Thanks, it works great. but the warning (start not in a clojure project) seems to be unnecessary.

Maybe. I’ve been thinking about this as well. The warning is configurable and was added back in the day before CIDER would inject its dependencies automatically. I didn’t remove it mostly because generally people want to be starting a REPL for some project and sometimes might start it in the wrong folder accidentally.

I’m open to ideas about what makes the most sense.

and I tried cider-jack-in-clojurescript, it also launched the REPL with command clojure. what is the progress on this? is it a good idea to use cider + tools.deps + cljs at this moment?

It’s a great idea, but no one has implemented the dependency injection for ClojureScript. 🙂

Basically cider-jack-in-clojurescript should add a few more libs to the dependency vectors - clojurescript, piggieback and some REPL like figwheel.

It’s not a lot of work, but someone has to do it. 🙂

very curious about the direction about clojure develop tooling. seems like there's a lot of build tools for Clojure, now there's a new clojure command line. I think the choices between the editors and build tools become a problem for the newbie like me.

Imagine how frustrating is this for tool writers. 😄 People constantly ask for adding support for more and more tools and it’s hard for us to catch up.

But I think clojure is here to stay and we’ll certainly invest more efforts into supporting it better.

I just realized that when you run cider-load-buffer the repl values for *1, *2 are not set. Is that by design?

(+ 1 1)
(assert (= *1 2))

@bozhidar so @cemerick is on board with transferring piggieback to you guys

is this like a maintainence or consolidation plan? Just seeing bits and pieces (orchard)

I'm just curious what's sort of the new thing, also with the recent cljs churn

cemerick doesn't want it anymore

simple as that

clojure-emacs has the most nrepl code of any org right now and a vested interest so ...

it would be a good thing imho

and piggieback is still a very good solution to this problem

time to learn then i guess 🙂

just needs a few updates

yea, makes sense

last time I looked cljs repl, piggieback et al was really painful to work on with all the dynamic vars and path-munging etc, hoping that's getting better :-)

s/cljs repl/at cljs repl source/

i've only glanced at that stuff briefly. but i just remember all of the signatures for cljs stuff is arg arg map-of-every-bit-of-compiler-state

its really not too crazy, you kinda have to understand all the parts before you appreciate it. It's more sensible than it appears

@bhauman according to the many times I have run into this, Cljs' take on REPL is that if you need something fully-fledged you should implement your own ReplEnv or namespace for socket so I would really welcome positively a project containing all these

Now piggieback contains only the browser REPL env

I would add - as you know very well 🙂

this isn't actually true

it works with any repl env

well it is more of a tunnel you are right

let's call it a wrapper REPL env 😄

it provides a cljs.repl/repl compatible call and can use any repl-env

it has a repl env but thats because rhino sucks

its really not needed at all for any of the other environments

its just there to intercept calls in certain cases

the whole thing is extremely brittle and has a lot of moving parts. I guess I'm wondering if pulling all that into one project with its own shared process might help.

It solves the particular problem of tunnelling evals from nrepl....I guess we need that. Until things like socker REPL and prepl will be adopted/supported

I never heard anything about this https://github.com/bhauman/lein-figwheel/issues/593 but this was my last experience.

I have run cider-jack-in in a project with deps.edn, but without Leinginen or Boot, and got the following warning:

clj-refactor and refactor-nrepl are out of sync.
Their versions are 2.4.0-SNAPSHOT and n/a, respectively.

Should I add refactor-nrepl middleware explicitly?

To my memory it’s automatically injected by CIDER, before I look up more did you update your packages?

Hmm, I did not. Let me upgrade first.

huh that n/a is quite concerning

Yep, that's why I suspect that middleware was not injected at all.

I don’t know how to phrase this properly but what does the modeline say when you run jack-in

it should be included in *Messages*

Starting nREPL server via /usr/local/bin/clojure -Sdeps '{:deps {org.clojure/tools.nrepl {:mvn/version "0.2.13"} cider/orchard {:mvn/version "0.1.0-SNAPSHOT"} cider/cider-nrepl {:mvn/version "0.17.0-SNAPSHOT"}}}' -e '(require (quote cider-nrepl.main)) (cider-nrepl.main/init ["cider.nrepl/cider-middleware"])'...
You can run the command ‘cider-jack-in’ with M-x c-jac RET
nREPL server started on 50586
[nREPL] Establishing direct connection to localhost:50586 ...
[nREPL] Direct connection to localhost:50586 established
Connected.  Clojure isn’t a language, it’s a building material.

This is with up-to-date cider and clj-refactor

refactor-nrepl middleware is enabled:

cider-jack-in-nrepl-middlewares is a variable defined in ‘cider.el’.
Its value is
("refactor-nrepl.middleware/wrap-refactor" "cider.nrepl/cider-middleware")

Ah-ha, there's open bug about it: https://github.com/clojure-emacs/cider/issues/2226

It’s weird that it brings in Orchard

Comes from here: https://github.com/clojure-emacs/cider/blob/master/cider.el#L438

L494 is the usage of this function and it doesnt include cider-jack-in-nrepl-middlewares

https://github.com/clojure-emacs/cider/blob/master/cider.el#L494