Fork me on GitHub
#cider
<
2018-01-23
>
stardiviner09:01:09

I got an error in CIDER REPL buffer when CIDER try to complete.

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/stardiviner/.m2/repository/org/slf4j/slf4j-nop/1.6.2/slf4j-nop-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/stardiviner/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See  for an explanation.
SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]
SLF4J: The following set of substitute loggers may have been accessed
SLF4J: during the initialization phase. Logging calls during this
SLF4J: phase were not honored. However, subsequent logging calls to these
SLF4J: loggers will work as normally expected.
SLF4J: See also 
SLF4J: clojure.tools.nrepl.server

stardiviner09:01:34

Maybe it is not CIDER issue. Curious how to debug this issue?

stardiviner09:01:46

Based on this: https://www.slf4j.org/codes.html#multiple_bindings Should I remove logback-classic or slf4j-nop ?

stardiviner09:01:45

After I remove logback-classic, and launch lein repl. It is installed back again. How can I find out which package is depending on logback-classic?

jmayaalv09:01:45

@stardivineryou can run lein deps :tree. and that would give you a tree view of your dependencies.

jmayaalv09:01:02

you can then check where logback-classic is being used.

stardiviner09:01:36

@jmayaalv I'm using global Leiningen dependencies. not in a project.

stardiviner09:01:49

If so, might I need to bisect all Leiningen :deps ?

jmayaalv09:01:39

it’s a better practice to avoid global dependencies. it’s very easy to forget what you have on there. so yes, i think it would be better to divide them.

stardiviner09:01:09

@jmayaalv I see. Thanks for your help.

carkh11:01:13

hum when i C-x C-e in a cljc file, with a clojurescript repl, i get the result nicely pretty-printed in an overlay in my source file....but when i do this in a clojure repl, it's not pretty-printed ... any idea how to have it looking nice ?

bozhidar11:01:09

@carkh I need a bit more context, but this sounds like some bug. The results should look the same regardless of the REPL type.

bozhidar11:01:24

You might want to report this upstream together with some repro steps.

carkh11:01:57

is the overlay output supposed to be pretty printed ?

carkh11:01:53

(i'm pretty new to this workflow ... i've been using the repl exclusively for years when doing evaluations)

bozhidar11:01:45

I don’t think it is supposed to be pretty-printed.

bozhidar11:01:55

Without consulting the code I don’t remember to be honest.

carkh11:01:43

bah that's no big deal anyways =) looks like c-c c-p opens a window with a pretty printed output...so I'm good

bozhidar11:01:15

I’m just curious where you’re getting those differences from, as this certainly shouldn’t be happening.

carkh11:01:46

probably somethign in the chain for clojurescript does the pretty printing...there are quite a few moving parts between sidecars figwheel devcards re-frame etc

carkh12:01:06

Bunch of stuff in my project.clj

:plugins [[lein-figwheel "0.5.14"]
            [lein-cljsbuild "1.1.7" :exclusions [[org.clojure/clojure]]]]
....
{:dev {:dependencies [[binaryage/devtools "0.9.8"]
                                  [figwheel-sidecar "0.5.14"]
                                  [com.cemerick/piggieback "0.2.2"]
                                  [re-frisk "0.5.3"]
                                  [devcards "0.2.4"]
                                  [org.clojure/test.check "0.10.0-alpha2"]]
                   :source-paths ["src" "dev"]
                   :repl-options {:nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]}
                   :clean-targets ^{:protect false} ["js/compiled"
                                                     :target-path]}}

carkh12:01:46

ah but pretty-printing works in the repl without issue

carkh12:01:52

that's only when evaluating inside my source file with C-x C-e (cider-eval-last-sexp)

genmeblog13:01:51

@bozhidar looks like current (today's) snapshot is not working, after lein repl I have tons of stacktrace

genmeblog13:01:15

I mean cider-nrepl

orlandow14:01:41

I'm getting this:

orlandow14:01:44

SEVERE: Unhandled REPL handler exception processing message {:op init-debugger, :print-level 10, :print-length 10, :session 112e0813-ae55-42ce-b46c-df3c40783c07, :id 8}
java.lang.RuntimeException: No such var: ns-find/sources-in-jar, compiling:(orchard/namespace.clj:98:48)

bozhidar14:01:00

Seems the latest snapshot of orchard didn’t get downloaded or something like this.

mhcat17:01:52

looks like cider still injects a non-alpha version of tools.namespace. That didn't stop this error disappearing when I changed the version of tools.namespace already in my :dev profile deps to 0.3.0-alpha4 to match - doing that made my repl start correctly

bozhidar14:01:29

I don’t have time to check what went wrong now, though.

bozhidar14:01:07

Basically some code was moved from cider-nrepl to orchard.

bozhidar14:01:30

(we’ve got this initiative to extract the core logic from cider-nrepl to orchard, so other clients can use it and we can eventually use it via the socket repl, which we hope to support one day in CIDER)

genmeblog14:01:44

@bozhidar in my problem it looks that dependency to net.littleredcomputer/sicmutils started to causing problem...

genmeblog14:01:40

so it's not directly related to nrepl...

andrea.crotti14:01:16

anyone got this error

ERROR clojure.tools.nrepl.server - Unhandled REPL handler exception processing message {:op eval, :ns user, :code (do (require 'figwheel-sidecar.repl-api)
               (require 'integrant.repl)
               (integrant.repl/go)
               (figwheel-sidecar.repl-api/cljs-repl)), :session 1d155db9-57f2-47ac-baeb-277b45f7f7fe, :id 12}
clojure.lang.Compiler$CompilerException: java.lang.Exception: namespace 'orchard.namespace' not found, compiling:(orchard/meta.clj:1:1)
?

andrea.crotti14:01:45

I upgraded cider today but I can't find any reference of orchard anywhere

pablore14:01:46

I’m having this problem with the latest cider package update on elpa: java.lang.Exception: namespace 'orchard.namespace' not found, compiling:(orchard/meta.clj:1:1) When trying to evaluate some code in the repl

dpsutton14:01:58

there seem to be some issues right now, @andrea.crotti

pablore14:01:14

Is this happening with the latest package version?

andrea.crotti14:01:18

I can try to downgrade if I remember how to do it

dpsutton14:01:32

probably best to install cider from melpa-stable right now

dpsutton14:01:54

this will ensure you have a non snapshot version

pablore14:01:02

How do i do that? Im a emacs noob. Using spacemacs developer branch

dpsutton14:01:08

i have no idea in spacemancs

jmayaalv14:01:55

no idea how to do it in spacemacs, but if u use use-package you can do somethng like:

(use-package cider
          :ensure t
          :pin melpa-stable)

jmayaalv14:01:01

remove the existing package from the ~/.emacs.d/elpa and then exeucute that expression or restart emacs and the stable version would be installed

dpsutton14:01:39

if you can find where this code is in your init directory you can add that :pin code

bozhidar15:01:57

@andrea.crotti I’m really puzzled by this failure.

bozhidar15:01:18

Both the latest snapshot of orchard and cider-nrepl are on clojars, so the deps should be fine.

dpsutton15:01:49

i just changed the cider-version back to 0.16.0 until the snapshots are updated

(defconst cider-version "0.16.0"
  "Fallback version used when it cannot be extracted automatically.
Normally it won't be used, unless `pkg-info' fails to extract the
version from the CIDER package or library.")

bozhidar15:01:14

I’m guessing for some reason lein/`boot` is not pulling the latest snapshots. I recall there was a way to force this (maybe lein -U).

dpsutton15:01:27

yes -U will get latest snapshots

bozhidar15:01:28

@dpsutton There’s nothing to be updated though. 😄

dpsutton15:01:48

when i jacked in just now for work eval would just spin and not complete

dpsutton15:01:56

no error message or anything, just spinning

bozhidar15:01:31

Hmm, that’s odd. I see all the tests are passing for both projects.

dpsutton15:01:17

i've been out of work with the flu recently so its my first day back otherwise i would have spent some time looking at the nrepl logs

dpsutton15:01:22

gotta get things done this morning 🙂

andrea.crotti15:01:52

yeah also quite puzzled, the last commits in cider don't seem related at all

andrea.crotti15:01:03

but it only happened today for me at least @bozhidar

bozhidar15:01:35

That doesn’t puzzle me at all - today I pushed an updated version of cider-nrepl to clojars. 🙂

bozhidar16:01:07

When it rains it pours - something odd’s happening with my Emacs and I can’t update my installed packages. 😄

bozhidar16:01:58

Is someone having problems with MELPA right now? I consistently get “Failed to download MELPA archive.”

pablore16:01:00

I switched from spacemacs develop to master branch and Cider is now working as intended. But the parinfer layer is not available in this branch :C

pablore16:01:00

@bozhidar have you tried a mirror?

bozhidar16:01:23

I didn’t even know there was a mirror.

bozhidar17:01:40

By the time I saw this the standard MELPA started working for me.

bozhidar17:01:44

A mystery…

bozhidar17:01:38

@andrea.crotti @dpsutton I tried reproducing your problems, but I couldn’t. The latest snapshot works just fine for me. I guess adding a -U to your jack-in commands will fix those dep issues.

dpsutton17:01:02

i'll try again over lunch break and let you know

dpsutton17:01:06

thanks for looking into it

mhcat17:01:17

I noticed that orchard master branch has a dependency on tools.namespace version 0.3.0-alpha4. I had a project dependency for a non-alpha version in my :dev profile which I think caused my problem here

bozhidar17:01:08

Ops, let me rebuild cider-nrepl with an obfuscated version of the orchard.

mhcat17:01:17

when I updated it to the alpha version, my startup exception (not finding the var (see @orlandow's thing)

mhcat17:01:25

went away

mhcat17:01:43

even though cider seems to be trying to inject the non-alpha version still

mhcat17:01:59

(maybe injected deps are lower precedence?)

bozhidar17:01:37

@j0ni yeah, my bad. Just pushed a new build which processes orchard with MrAnderson, so such problems won’t occur.

mhcat17:01:01

ah cool, so I can revert my dep back to non-alpha?

mhcat17:01:08

(not that I'm concerned lol)

xiongtx19:01:21

@bozhidar I’m getting

Caused by java.lang.ClassNotFoundException
   com.sun.javadoc.ClassDoc
When trying to evaluate orchard.java. This is Java 1.8.0_151.

xiongtx20:01:29

Looks like I needed to use https://github.com/pallet/lein-jdk-tools to add tools.jar to the path

bozhidar20:01:14

hmmm, that’s odd - was working just fine for me in my “initial” tests. To my knowledge tools.jar is bundled with the JDK, or at least it was bundled back in the day when I was still a Java developer. 🙂

xiongtx20:01:16

Can someone on a Linux machine verify that (System/getProperty "java.io.tmpdir") returns a value w/out a trailing slash? B/c on OS X it gives something like /var/folders/rb/7tf4fbvs0f941dbsl1kwctbj1cz9rj/T/, which does have a trailing slash.

dpsutton20:01:49

(System/getProperty "java.io.tmpdir")
/tmp

xiongtx20:01:58

@bozhidar I wonder if Orchard should more clearly separate clj and cljs functionality. From https://github.com/clojure-emacs/orchard/pull/7 it seems that the cljs stuff is heavily tied to nREPL / Piggieback, whereas the clj stuff isn’t.

xiongtx21:01:27

:thinking_face: Presumably a cljs client for e.g. unREPL would need to have a Piggieback-like wrapper that, also exposes the cljs compiler state.

jfntn21:01:23

I don’t understand in which cases does the implementation of cider-test-ediff does the right thing Running this test:

(t/deftest =-test
  (t/is (= (range 0 10) (range 0 11))))
Gets me the following report:
Fail in =-test
expected: (= (range 0 10) (range 0 11))
actual: (not (= (0 1 2 3 4 5 6 7 8 9) (0 1 2 3 4 5 6 7 8 9 10)))
All good, but cider-test-ediff tries to diff (= (range 0 10) (range 0 11)) against (not (= (0 1 2 3 4 5 6 7 8 9) (0 1 2 3 4 5 6 7 8 9 10))), which seems useless since we’d want to diff the actual expressions inside the = form. Am i missing something?

jfntn14:01:08

@xiongtx awesome PR and great timing, except I had to revert to melpa-stable yesterday because I was experiencing some breakage with the orchard refactoring. Will give it another shot

jfntn15:01:19

@xiongtx tried melpa and it worked this time, however the new diff functionality introduced a regression in case where the test throws with Uncaught exception, not in assertion the actual error is now swallowed

jfntn15:01:28

Cider stable instead shows error: clojure.lang.ExceptionInfo: ... and hit can hit e to see the stacktrace, both of which are critical to resolving these kinds of issues

xiongtx18:01:58

Yikes…coding is harder than I thought 😉

xiongtx19:01:10

Actually, this is a pretty easy fix: https://github.com/clojure-emacs/cider/pull/2179#issue-291332761 It’s small enough that you can apply it yourself to cider-test.el until the PR is merged.

xiongtx21:01:45

PR is now merged.

xiongtx21:01:46

@benedek It seems this issue is b/c I removed the ^:source-dep on clojure.java.classpath. But we no longer use clojure.java.classpath directly in cider-nrepl. So what’s going on? https://github.com/clojure-emacs/cider/issues/2176

benedek21:01:18

let me have a look

benedek21:01:34

hm… @xiongtx looks a bit weird. suppose both orchard and tools.namespace are using clojure.java.classpath and somehow mranderson got confused

benedek21:01:06

just guessing here really. did @bozhidar’s latest commit (mrandersoning orchard) fix this tho?

xiongtx21:01:55

@bozhidar Have you released the latest changes in Orchard to clojars?

benedek21:01:26

wow nice icon for clojars 🙂

dominicm21:01:58

Cider could now do a jack in for clj/deps.edn. The parameters are there.

bozhidar22:01:58

@dominicm which are those?

dominicm22:01:29

-Sdeps is deps.edn as a string to be merged in

bozhidar22:01:22

@xiongtx Yes, I did. I see on tickets like https://github.com/clojure-emacs/cider/issues/2176 people are submitting backtraces with inlined deps. Seems something went wrong with the MrAnderson step - maybe because cider-nrepl still depends on c.t.n. and something got messed up with the namespace rewriting.

bozhidar22:01:10

> @bozhidar I wonder if Orchard should more clearly separate clj and cljs functionality. From https://github.com/clojure-emacs/orchard/pull/7 it seems that the cljs stuff is heavily tied to nREPL / Piggieback, whereas the clj stuff isn’t.

bozhidar22:01:49

There’s very little cljs code in cider-nrepl - most of it just deals with piggieback and can’t really be extracted. A long time ago we’ve created cljs-tooling, but it didn’t get far and it should probably be merged into orchard, as back in the day cljc didn’t exist yet.

bozhidar22:01:17

I think the only thing that we extract of the piggieback session is the cljs compiler environment, which is used here and there.

dominicm22:01:29
replied to a thread:@dominicm which are those?

-Sdeps is deps.edn as a string to be merged in

bozhidar22:01:36

There’s also a bit of cljs code for macroexpansion and I think that’s pretty much all of it. Lots of things were never implemented for it, as most of the maintainers (like me) don’t know much about cljs.

bozhidar22:01:53

I’m pretty sure that’s not hard, but it still requires someone to do it. 🙂

andrea.crotti22:01:50

@bozhidar just upgraded everything on my Linux box and it doesn't give the same orchard error

andrea.crotti22:01:56

the other machine is a Mac

andrea.crotti22:01:17

(even if don't think that's the actual cause of the problem)

andrea.crotti22:01:30

(well Emacs sucks on OSX sadly compared to Linux, but should not make a difference in this case in theory)

benedek22:01:41

@bozhidaractually if you put back ^:source-dep [org.clojure/java.classpath "0.2.3"] that should fix it

benedek22:01:06

see my comment on 2176

bozhidar22:01:19

@benedek Thanks. I’ve shipped a new snapshot and I’m off to bed.

bozhidar22:01:26

Too much CIDER drama today! 🙂

bozhidar22:01:41

I need to drink a lot more cider tomorrow. 😉