I think we’re back in business with 0.22.0-SNAPSHOT of cider-nrepl. Hopefully this first build with the new MrAnderson was some isolated incident.

> i wish the names were inverted. ie, melpa and melpa-beta or something but it is what it is

Historical reasons - originally there was only MELPA and it was for snapshots. MELPA Stable was born much later after some users asked for it. I don’t think it was something the original creator of MELPA ever envisioned. Afterwards you’re bound by backwards compatibility. 🙂

@bozhidar shall i close the my PR then or you still want the other project file changes apart from the version upgrade?

@benedek Just rebase it and I’ll merge it. I had changed just the version number.

ok, good. will do

with recent cider updates, sometimes when launched, cider will prompt for Lisp expression:, and close cider will raise an error error in process sentinel: Wrong type argument: stringp, nil. is there anyone run into the same issue?

@doglooksgood Make sure you’re using the latest cider-nrepl snapshot. There was one bad build that made it to clojars over the weekend.

can I refresh the snapshot by remove the one in .m2?

looks like it works! thanks! @bozhidar

You’re welcome!

cider 0.22.0 use cider-nrepl 0.21.1, this is not a snapshot version.

how do I prevent the cider debugger from trying to fully realize lazy sequences?

(let [n 5]
  #dbg
  (take (inc n) (repeat n)))

this hangs indefinitely trying to evaluate (repeat n)

whereas eg. cider-eval on an infinite sequence doesn't have that issue

Have anyone experienced problems with running tests in latest CIDER?

The test runner sometimes just hangs

jstack shows this. Can it be related?

"nRepl-session-6d174f6f-fb70-42ca-be1b-8742ba9f97ec" #1394 daemon prio=5 os_prio=31 tid=0x00007fea4a089800 nid=0x2445b waiting for monitor entry [0x0000700008eef000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.io.PrintWriter.println(PrintWriter.java:738)
        - waiting to lock <0x000000064f731640> (a java.io.BufferedWriter)
        at com.sun.tools.javac.util.Log.printRawLines(Log.java:528)
        at com.sun.tools.javac.util.Log.writeDiagnostic(Log.java:622)
        at com.sun.tools.javac.util.Log$DefaultDiagnosticHandler.report(Log.java:600)
        at com.sun.tools.javac.util.Log.report(Log.java:562)
        at com.sun.tools.javac.comp.Resolve.logResolveError(Resolve.java:3514)
        at com.sun.tools.javac.comp.Resolve.accessInternal(Resolve.java:2219)
        at com.sun.tools.javac.comp.Resolve.accessBase(Resolve.java:2262)
        at com.sun.tools.javac.comp.Resolve.accessBase(Resolve.java:2272)
        at com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:2383)
        at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:3170)
        at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2011)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576)
        at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638)
        at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631)
        at com.sun.tools.javac.comp.MemberEnter.visitVarDef(MemberEnter.java:649)
        at com.sun.tools.javadoc.JavadocMemberEnter.visitVarDef(JavadocMemberEnter.java:103)
        at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:852)
        at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437)
        at com.sun.tools.javac.comp.MemberEnter.signature(MemberEnter.java:385)
        at com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:581)
        at com.sun.tools.javadoc.JavadocMemberEnter.visitMethodDef(JavadocMemberEnter.java:75)
        at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778)
        at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437)
        at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:449)
        at com.sun.tools.javac.comp.MemberEnter.finishClass(MemberEnter.java:459)
        at com.sun.tools.javac.comp.MemberEnter.finish(MemberEnter.java:1404)
        at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1199)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)
        at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:493)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:471)
        at com.sun.tools.javadoc.JavadocEnter.main(JavadocEnter.java:78)
        at cider.nrepl.inlined_deps.orchard.v0v5v0_20190329v191815_1.orchard.java.parser$parse_java.invokeStatic(parser.clj:81)

@alexyakushev I haven’t seen any problems myself yet, but I don’t think there were any changes related to tests between the previous middleware snapshot and the current one.

Looking at the commits almost nothing has changed https://github.com/clojure-emacs/cider-nrepl/commits/master

Thanks. It might be because I launched C-c C-t C-t once, then it seemingly hanged (put perhaps were working too slow) so I C-c C-b to cancel it and then launched again.

I’m actually surprised to see anything related to Javadoc in your stacktrace. Pretty weird.

I guess the first test run didn't complete but was blocking some shared resource.

Hmm, that use case you described should be fine (at least in theory).

Alright, I'll try to make something reproducible if it happens again.

I'm having trouble with connecting to nrepl in a docker version of our project. Usually I use cider-jack-in and that works fine, but with the docker version I have to do a cider-connect so nrepl isn't getting injected automatically. I put [nrepl "0.6.0"] in the project file (and my profiles.clj!) but when I connect I'm getting

WARNING: CIDER requires nREPL 0.4.4 (or newer) to work properly
         More information.WARNING: CIDER requires cider-nrepl to be fully functional. Many things will not work without it!
         More information.

error in process filter: user-error: ‘nil’ requires the nREPL op "classpath" (provided by cider-nrepl)

@soulflyer What’s your lein there?

I’d venture a guess it’s older than 2.8.3.

2.9.0

are you sure that's the version of lein inside docker?

No, that's the version in my home environment.....

👍

if I run cider-jack-in-clj with a deps.edn in the root directory it can't find the project and asks to continue without one. What am I missing?

couple things to check. you can walk through cider-project-type to see what's going on. make sure clojure-project-dir reports the correct project directory. there's a cache that can get busted so restart emacs and make sure clojure-cached-project-dir is nil in the buffers.

I can't find cider-project-type or clojure-project-dir with M-x describe-variable. Where can I find these?

those are functions

from CIDER and clojure-mode respectively

😅 Didn't see them as interactives so I assumed they were variables

Yeah, cider-project-type is clojure-cli but clojure-project-dir is nil. How should it be set?

can you step through clojure-project-dir? it ends up in clojure-project-root-path looking up the directory tree for one of the project files

Ok, first time using step through in emacs debugger, but it gets to a point where while running locate-dominating-file it runs * mapcar(#f(compiled-function (fname) #<bytecode 0x443ce435>) ("project.clj" "build.boot" "build.gradle")) .. conspicuously no deps.edn

nice! those come from clojure-build-tool-files var which makes me think you need to update your clojure-mode

(defcustom clojure-build-tool-files
  '("project.clj"      ; Leiningen
    "build.boot"       ; Boot
    "build.gradle"     ; Gradle
    "build.gradle.kts" ; Gradle
    "deps.edn"         ; Clojure CLI (a.k.a. tools.deps)
    "shadow-cljs.edn"  ; shadow-cljs
    )

(defcustom clojure-build-tool-files '("project.clj" "build.boot" "build.gradle")
  "A list of files, which identify a Clojure project's root.
Out-of-the box `clojure-mode' understands lein, boot and gradle."
  :type '(repeat string)
  :package-version '(clojure-mode . "5.0.0")
  :safe (lambda (value)
          (and (listp value)
               (cl-every 'stringp value))))

clojure-mode-display-version gives version 5.7.0-snapshot)

looks like i'm on 5.10. but just update that so its nows about the new project file type adn you should be good

Awesome, that worked! Glad I didn't get the 'just update your version' response and that I learned a bit more about clojure-mode and emacs debugger 🙂

well... had i known that was the problem i wuld have said that lol

but its good to know how to step through stuff. because i didn't know where that stuff was but i have to tools to figure out where it is. and now you do too 🙂

@soulflyer i see your message on mobile but not on teh desktop. i recently fixed a bug in cider-nrepl. does the project stipulate a clojure version below 1.8 and uses a supported clojure version above 1.8 in a profile?

the cider plugin can erroneously decide not to inject the guts middleware

Not sure what you mean there. project.clj specifies clojure 1.9 in the dependencies and that's what cider-describe-connection shows. As far as I know there is nothing in the profiles specifying any other version of clojure. Certainly not in project.clj or my own .lein/profiles.clj.

ok. its not related then. but my example was like nippy, where the dep is 1.5 or so in the dependencies and in the dev profile clojure 1.9 is specified

but i would still start up the project where you can observe the output and see if cider-nrepl is logging anything

I guess that means modifying the docker setup as that is where the nrepl server gets started. Not sure how to go about doing that.

will try tomorrow. Thanks for your help @dpsutton