Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-09

Channels

#cider
<
2019-05-09
>
fmnoise08:05:08

hi everyone, I'm getting 

Caused by java.lang.RuntimeException
   Unable to resolve symbol: STATE__ in this context
while trying to eval defn with #light tag

fmnoise08:05:33

cider trace 

Util.java:  221  clojure.lang.Util/runtimeException
             Compiler.java: 7414  clojure.lang.Compiler/resolveIn
             Compiler.java: 7358  clojure.lang.Compiler/resolve
             Compiler.java: 7319  clojure.lang.Compiler/analyzeSymbol
             Compiler.java: 6768  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 3881  clojure.lang.Compiler$InvokeExpr/parse
             Compiler.java: 7109  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 3888  clojure.lang.Compiler$InvokeExpr/parse
             Compiler.java: 7109  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 3888  clojure.lang.Compiler$InvokeExpr/parse
             Compiler.java: 7109  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 6118  clojure.lang.Compiler$BodyExpr$Parser/parse
             Compiler.java: 7107  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 6120  clojure.lang.Compiler$BodyExpr$Parser/parse
             Compiler.java: 5467  clojure.lang.Compiler$FnMethod/parse
             Compiler.java: 4029  clojure.lang.Compiler$FnExpr/parse
             Compiler.java: 7105  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java:   38  clojure.lang.Compiler/access$300
             Compiler.java:  596  clojure.lang.Compiler$DefExpr$Parser/parse
             Compiler.java: 7107  clojure.lang.Compiler/analyzeSeq
             Compiler.java: 6789  clojure.lang.Compiler/analyze
             Compiler.java: 6745  clojure.lang.Compiler/analyze
             Compiler.java: 7181  clojure.lang.Compiler/eval
             Compiler.java: 7132  clojure.lang.Compiler/eval
                  core.clj: 3214  clojure.core/eval
                  core.clj: 3210  clojure.core/eval
                 debug.clj:  584  cider.nrepl.middleware.debug/instrument-and-eval
                 debug.clj:  579  cider.nrepl.middleware.debug/instrument-and-eval
                  Var.java:  384  clojure.lang.Var/invoke
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  665  clojure.core/apply
                  core.clj:  660  clojure.core/apply
                regrow.clj:   18  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   79  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   55  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  142  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  171  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  170  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  745  java.lang.Thread/run

bozhidar08:05:02

@fmnoise Seems like you’ve encountered a bug. File a report with CIDER or cider-nrepl.

fmnoise08:05:13

ok, thanks

borkdude12:05:00

Not sure where to discuss this, but since @bozhidar is around here: I think this style guide rule is a bit ambiguous. https://github.com/bbatsov/clojure-style-guide#else-keyword-in-cond Should I read that as: always use :else in cond, or only when you intend the last clause as a catch-call?

borkdude12:05:36

so: 

(cond (< x 5) .. (< x 10) ..)
returns nil for (=> x 11), that doesn’t require an :else?

bozhidar12:05:15

@borkdude Yeah, I see what you mean. You should use :else when you need a catch all. Depending on the conditions that’s not always necessary.

bozhidar12:05:03

I think we discussed something similar with you and @alexmiller recently on Twitter.

borkdude12:05:55

yeah, that was a slightly different one though, about case

bozhidar13:05:12

I remember now.

bozhidar13:05:46

For cond having an :else in definitely necessary in some scenarios as if you don’t have any matches it returns nil, which is not exactly great.

bozhidar13:05:48

I use it almost all the time, but it really depends on the nature of the clauses.

borkdude13:05:40

some people are relying on nil so I wasn’t sure about this. right now clj-kondo complains every time you have no :else. I haven’t had any complaints from users so far. but after this conversation I made this issue: https://github.com/borkdude/clj-kondo/issues/147

dominicm17:05:52

I rely on this in lots of projects

dominicm17:05:24

I think the rule should be looking for other truthy values which should instead be :else

borkdude17:05:59

that’s indeed what this conversation is about and since I’ve heard both opinions, it’s probably going to be configurable

dominicm17:05:50

I'd like the linter to fail when someone does 1 or something though, I don't think the default should encourage the including of :else nil

borkdude17:05:19

yes. if you’re using a constant, it should be :else.

borkdude17:05:58

I’m inclined to make that the default, since it leads to less false positives without any config

borkdude13:05:44

maybe it’s already fine as it is.

bozhidar13:05:51

Well, some times nil might be ok, but I definitely think that some explicit return value would be better most of the time.

bozhidar13:05:14

I guess you can make this configurable and keep the current behaviour as the default.

dpsutton13:05:18

now the classic: where do you configure? Source comment. project file, global settings, etc

borkdude13:05:56

I don’t like changing the source code because of a linter, so I’m inclined in a project .clj-kondo/config.edn file

👍 4
bozhidar13:05:10

That’s usually the best approach.

bozhidar13:05:36

That’s how I do it in RuboCop (https://github.com/rubocop-hq/rubocop) and it has worked out really well.

bozhidar13:05:26

Most linters support some default file in the home folder and per project configuration.

borkdude13:05:42

yeah, that’s totally possible

borkdude13:05:44

Here's an example global configuration file:

nrepl/nrepl.edn
that should read .nrepl/nrepl.edn yes?

bozhidar13:05:16

Yep. Thanks for spotting that typo!

bozhidar13:05:43

Basically I just get if there’s global config map and merge it with a project config map if present. Works out really well in practice.

borkdude14:05:27

yeah. what I’m having right now is that you have a project config in .clj-kondo/config.edn and you can override it with a CLI argument --config which accepts either a file path or a literal EDN expression

borkdude14:05:41

but a more global config in the home dir is a good addition probably

borkdude14:05:59

(override = merge)

borkdude14:05:25

maybe I should also name the config.edn clj-kondo.edn, but that would be a breaking change…

borkdude14:05:10

on an unrelated, but more on topic note. I’ve been using Java 11 for a while. when I start my project I see this: 

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval2845$fn__2846 to method java.net.URLClassLoader.addURL(java.net.URL)

bozhidar15:05:28

The warning is harmless. We’ve addressed this in the upcoming Orchard 0.5.

madstap20:05:27

On a fresh install of ubuntu and emacs prelude I'm getting user-error: The clojure executable isn’t on your ‘exec-path’ and user-error: The lein executable isn’t on your ‘exec-path’ when I try to cider-jack-in. I do have both installed. How do I debug this? 

$ which lein
/usr/bin/lein
$ which clojure
/usr/local/bin/clojure

(describe-variable 'exec-path)
=>
Its value is
("/app/bin/" "/usr/bin/" "/app/libexec/emacs/26.2/x86_64-pc-linux-gnu/" "/usr/local/bin/")
Original value was 
("/app/bin" "/usr/bin" "/app/libexec/emacs/26.2/x86_64-pc-linux-gnu")

dpsutton20:05:34

emacs starts up without the path of your shell

madstap20:05:45

I'm using emacs installed via flatpak, if that makes a difference

madstap20:05:02

ok, that makes sense

dpsutton20:05:48

i think there's a package that loads your shells path. but not sure

madstap21:05:20

Thanks! Now that I know what the problem is I'll look for that package (and install from source if I can't find and use it easily ¯\(ツ)/¯).

richiardiandrea22:05:04

Has anybody ever looked into this for Clojure/ClojureScript? https://github.com/emacs-lsp/dap-mode

hkjels07:05:51

I tried setting it up a while back, but got frustrated and killed it before actually getting anywhere