I've been screwing my emacs config all day so I can't tell if it's me or cider, I'm on the most recent melpa unstable 0.18.0-snapshot. And the error stacktrace doesn't have the underline link to the source files in the trace. And when I click on the line I get

Debugger entered--Lisp error: (error "No input at point")
  signal(error ("No input at point"))
  error("No input at point")
  cider-repl--send-input(t)
  cider-repl-return(nil)
  funcall-interactively(cider-repl-return nil)
  call-interactively(cider-repl-return nil nil)
  command-execute(cider-repl-return)

I solved that issue, seemed that I can only install Cider from http://stable.melpa.org

Have you tried installing it manually?

@theeternalpulse by installing spinner manually and seeing what the issue is?

yeah, from http://melpa.org I couldn't install spinner manually

right. can you clone it and see if you can eval it?

the last commit is over 3 years old

2 years but still 🙂

> And the error stacktrace doesn’t have the underline link to the source files in the trace. And when I click on the line I get

@hlolli Can you show us some screenshot/mini video of what you’re doing exactly?

First practical question about nREPL - how do we name the deployment artefact for version 0.3. It can’t retain its old name. I was thinking of cider/nrepl for consistency with the other projects, but that would result in namespace conflicts down the road with cider/cider-nrepl unless we change the name of cider-nrepl to something like orchard-nrepl (which I’m perfectly fine with). I’ve been thinking lately that it’s probably time to decouple cider-nrepl from the release cycles of CIDER itself.

+1 for orchard-nrepl

just rename the whole artifact and re-namespace everything.

Yeah, yeah - that’s what I’ve been thinking about.

That would also underline the editor-agnostic nature of cider-nrepl I guess.

I'd like to see cider-nrepl be less coupled to cider anyway, see my recent comments about the pretty print middleware.

yep!

For nREPL 0.3 the namespaces will be the same, only the artefact id will be different, to simplify the rollout.

Sure, just as long as there's an announced migration plan.

idle thought - it'd be really cool if cider could natively tee execution output and results to a log file.

That was the original migration plan, that Chas himself announced.

On the client side?

I’ve always been wondering if we don’t need an execution log on the server side.

I've totally used cider for days-long evaluations and then had to write out a huge repl buffer at the end of it.

Servers could probably persist a log of commands too, I'm interested in more durably capturing out, err and the eval result.

but I'm definitely using cider for some weird stuff atm.

anyway. ideas for after the work deadline :white_frowning_face:

Well, we can certainly discuss this in more detail later.

For now it seems that the first step would be replacing maven with lein and cutting 0.3. Haven’t used maven in so many years, and I don’t really want to change this.

There’s also the fact that nREPL is targeting Clojure 1.2 now. 🙂

Plus I noticed another Java 9 incompatibility:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.tools.nrepl.middleware.interruptible_eval$set_line_BANG_ to field 
WARNING: Please consider reporting this to the maintainers of clojure.tools.nrepl.middleware.interruptible_eval$set_line_BANG_
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

@bozhidar if you don't change the namespaces, it's not going to work for most, due to class path collisions. I would strongly recommend against doing that.

But this was Chas’s original plan - to keep the namespace the same for the first version.

I’m fine with changing it right away, though. That’s unavoidable basically.

I fear that adding [cider/nrepl "0.3.0"] to a project wouldn't do anything, due to the already-present copy of the same files from leiningen.

classpaths suck eh 🙂

This is really the maven relocation problem, and I don't think it can be solved without org.clojure/tools.nrepl "delegating" to us.

Yeah, that’s a valid point.

OK, let’s go with the new namespace then.

Shouldn't orchard be completely nRepl agnostic so that it can run on socket as well? Maybe I misunderstood the plan 😃

Or are there gonna be two: orchard and orchard-nrepl?

They are going to be two orchard and orchard-nrepl.

The only tricky thing right now is how to make something like orchard work with the old and the new nrepl namespace. I really don’t want to have conditional checks for everything.

Likely I’ll cut a small CIDER release that just has the orchard-nrepl change, and the next CIDER release is likely going to stop using lein repl and boot repl and will instead have a couple of basic tasks that spin an nREPL server using the new nREPL.

Fun times ahead! If someone wants to help out with these transformations - there’s plenty of work to go around. 😉

@bozhidar as you know my goal is to port stuff to cljs and self-host, the cljs-tooling PR is WIP but almost there, then will try to see if I can integrate (and how) into lumo, then socket cider/`orchard` porting, dunno...I guess I will test the waters when I get there

also don't want to commit to much because I am becoming busy again at work and summer is coming 😉

I guess this applies to all of us, but it’s important we’re all trying to make things better.

OK, I’m wrapping the work on Clojure tooling for now. If someone wants to help out with some easy tasks I’d appreciate this: * tackle the eastwood warnings * add some “modern” main to nREPL so we can start it and pass it middleware (as opposed to doing this from cider-nrepl as we currently do) * create a lein and boot tasks that start the new nREPL and can be passed a list of extra middleware