This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-23
Channels
- # aws-lambda (5)
- # beginners (212)
- # boot (3)
- # cider (130)
- # cljs-dev (24)
- # clojars (2)
- # clojure (287)
- # clojure-dusseldorf (23)
- # clojure-italy (11)
- # clojure-russia (10)
- # clojure-spec (9)
- # clojure-uk (45)
- # clojurescript (59)
- # core-async (1)
- # cursive (13)
- # datascript (1)
- # datomic (46)
- # emacs (12)
- # events (9)
- # fulcro (196)
- # graphql (3)
- # hoplon (79)
- # jobs (5)
- # jobs-discuss (7)
- # jobs-rus (2)
- # keechma (26)
- # keyboards (9)
- # leiningen (2)
- # luminus (9)
- # off-topic (20)
- # om-next (1)
- # onyx (15)
- # re-frame (16)
- # reagent (18)
- # reitit (1)
- # remote-jobs (2)
- # rum (3)
- # shadow-cljs (13)
- # sql (135)
- # unrepl (46)
- # vim (1)
- # yada (23)
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
Maybe it is not CIDER issue. Curious how to debug this issue?
Based on this: https://www.slf4j.org/codes.html#multiple_bindings Should I remove logback-classic
or slf4j-nop
?
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
?
@stardivineryou can run lein deps :tree.
and that would give you a tree view of your dependencies.
@jmayaalv I'm using global Leiningen dependencies. not in a project.
If so, might I need to bisect all Leiningen :deps ?
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.
@jmayaalv I see. Thanks for your help.
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 ?
@carkh I need a bit more context, but this sounds like some bug. The results should look the same regardless of the REPL type.
(i'm pretty new to this workflow ... i've been using the repl exclusively for years when doing evaluations)
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
I’m just curious where you’re getting those differences from, as this certainly shouldn’t be happening.
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
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]}}
@bozhidar looks like current (today's) snapshot is not working, after lein repl I have tons of stacktrace
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)
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
That’s the relevant PR https://github.com/clojure-emacs/cider-nrepl/pull/486/files
(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)
@bozhidar in my problem it looks that dependency to net.littleredcomputer/sicmutils
started to causing problem...
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)
?I upgraded cider today but I can't find any reference of orchard anywhere
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
ah yes same thing @pablore
there seem to be some issues right now, @andrea.crotti
I can try to downgrade if I remember how to do it
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)
remove the existing package from the ~/.emacs.d/elpa
and then exeucute that expression or restart emacs and the stable version would be installed
it looks like spacemacs is built on use-package
https://github.com/syl20bnr/spacemacs/blob/master/layers/%2Blang/clojure/packages.el#L19
if you can find where this code is in your init directory you can add that :pin
code
@andrea.crotti I’m really puzzled by this failure.
Both the latest snapshot of orchard
and cider-nrepl
are on clojars
, so the deps should be fine.
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.")
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
).
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
yeah also quite puzzled, the last commits in cider don't seem related at all
but it only happened today for me at least @bozhidar
That doesn’t puzzle me at all - today I pushed an updated version of cider-nrepl
to clojars. 🙂
When it rains it pours - something odd’s happening with my Emacs and I can’t update my installed packages. 😄
Is someone having problems with MELPA right now? I consistently get “Failed to download MELPA archive.”
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
there are several https://github.com/melpa/melpa
@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.
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
when I updated it to the alpha version, my startup exception (not finding the var (see @orlandow's thing)
@j0ni yeah, my bad. Just pushed a new build which processes orchard
with MrAnderson, so such problems won’t occur.
@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
.Looks like I needed to use https://github.com/pallet/lein-jdk-tools to add tools.jar
to the path
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. 🙂
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.
@bozhidar I wonder if Orchard should more clearly separate and functionality. From https://github.com/clojure-emacs/orchard/pull/7 it seems that the stuff is heavily tied to nREPL / Piggieback, whereas the stuff isn’t.
:thinking_face: Presumably a client for e.g. unREPL would need to have a Piggieback-like wrapper that, also exposes the compiler state.
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?Yes, you’re missing this: https://github.com/clojure-emacs/cider/pull/2172
And my take on why cider-test-ediff
is not useful: https://github.com/clojure-emacs/cider/pull/2172#issuecomment-359522009
@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
@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
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
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.
@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
hm… @xiongtx looks a bit weird. suppose both orchard and tools.namespace are using clojure.java.classpath
and somehow mranderson got confused
just guessing here really. did @bozhidar’s latest commit (mrandersoning orchard) fix this tho?
@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.
> @bozhidar I wonder if Orchard should more clearly separate and functionality. From https://github.com/clojure-emacs/orchard/pull/7 it seems that the stuff is heavily tied to nREPL / Piggieback, whereas the stuff isn’t.
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.
I think the only thing that we extract of the piggieback session is the cljs compiler environment, which is used here and there.
-Sdeps is deps.edn as a string to be merged in
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.
@bozhidar just upgraded everything on my Linux box and it doesn't give the same orchard error
the other machine is a Mac
(even if don't think that's the actual cause of the problem)
(well Emacs sucks on OSX sadly compared to Linux, but should not make a difference in this case in theory)