This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-09
Channels
- # announcements (5)
- # aws (5)
- # babashka (7)
- # beginners (152)
- # cider (10)
- # clj-kondo (30)
- # clj-on-windows (1)
- # cljs-dev (14)
- # cljsrn (19)
- # clojure (94)
- # clojure-australia (4)
- # clojure-europe (43)
- # clojure-nl (2)
- # clojure-uk (11)
- # clojurescript (16)
- # clojureverse-ops (5)
- # code-reviews (7)
- # community-development (6)
- # core-async (29)
- # cursive (50)
- # datomic (22)
- # docker (10)
- # figwheel-main (3)
- # fulcro (4)
- # graalvm (1)
- # introduce-yourself (2)
- # kaocha (9)
- # lambdaisland (2)
- # lsp (19)
- # malli (37)
- # off-topic (50)
- # polylith (8)
- # portal (1)
- # reagent (10)
- # rum (1)
- # shadow-cljs (24)
- # spacemacs (14)
- # yada (2)
Hey everyone, what is the keybinding for evaluating current form that my cursor is on? Alt Shift P evaluates the top level form but I cannot find the binding for current form
You can move your cursor to the end of the form, after the paren, like so (+1 2)|
and invoke Send form before caret to REPL
. There isn't a Send current form under caret to REPL
, I'm guessing, since it'll be literals or symbols 95% of the time that'll be the current "form".
Or you could just select the form you want to evaluate and call either Send form before caret to REPL
or Send Top form to REPL
.
Thanks @UMPJRJU9E. I'll go with using Ctlr + W to semantically choose the form I want to evaluate and use Send Top form to REPL
. Gets the job done :thumbsup:
There is expand selection and shrink selection, if you haven’t already used it, which works quite nicely with s-expressions and will allow you to easily select the desired form.
Can anyone provide me with more insight as to why this happens: https://github.com/cursive-ide/cursive/issues/2266 ? I am not the original requestor, but my team all received the same sort of error from Cursive when we upgraded a library version (In our case it was time.clj -> time.clj -> time.clj
. Again, turning off Load out-of-date file dependencies transitively
seems to have fixed the error, but I don't understand why, or what is causing that error in the first place. It seems to be incorrect, as the code compiles and runs fine, and Emacs/CIDER doesn't have any issues.
This tends to be something funky with cljc. Do you know where the time.clj file comes from?
I don't, unfortunately. This occurred in pure clj code, rather than cljc. The issue arose when we upgraded the version of manifold
we were using from the one that caesium
bundles to 0.1.9-alpha5
(via an exclusion on caesium
in deps.edn
and an addition of the new version)
If you use Navigate->File…, set the filename to time.clj
and set the scope to “All Places”, what does it find?
It's finding a whole load of time.clj
instances in libs, as well as the one in my actual project. It is finding 2 different versions of it in manifold
(the lib we upgraded), both in the m2 cache, one for version 0.1.8
and one for 0.1.9-alpha5
. Is it potentially getting confused between the two versions?
Where’s it coming in from? You should be able to see that in either your deps or lein toolwindow
So clj -Stree
and the lein toolwindow both say it's within byte-streams
, which in turn is within caesium
, but that's what's excluded:
clj -Stree
...
com.github.arohner/manifold 0.1.9-alpha5-top
...
caesium/caesium 0.13.0
. com.github.jnr/jnr-ffi 2.1.12
. com.github.jnr/jffi 1.2.23
. com.github.jnr/jffi$native 1.2.23
. org.ow2.asm/asm 7.1
. org.ow2.asm/asm-commons 7.1
. org.ow2.asm/asm-analysis 7.1
. org.ow2.asm/asm-tree 7.1
. org.ow2.asm/asm-util 7.1
. com.github.jnr/jnr-a64asm 1.0.0
. com.github.jnr/jnr-x86asm 1.0.2
X commons-codec/commons-codec 1.14 :use-top
. byte-streams/byte-streams 0.2.4
. primitive-math/primitive-math 0.1.6
. clj-tuple/clj-tuple 0.2.2
X manifold/manifold 0.1.8 :excluded
. org.clojure/math.combinatorics 0.1.6
X medley/medley 1.2.0 :use-top
X com.taoensso/timbre 4.10.0 :use-top
...
Actually, you could try this: go to Help | Diagnostic Tools | Debug Log Settings…. In the box that opens, enter #cursive.namespace
. Then repro the problem and check your log (Help | Show Log in Finder/Explorer) for a “Dependency cycle” log that should have more information about the actual files involved.
But for some reason if I delete the directory for 0.1.8 from ~/.m2/repository
it still pulls it in again the next time I run lein repl
But wait - are you using lein or deps? Or are you using lein with dependencies from deps.edn?
That’s interesting. I wonder if that’s a bug in Cursive because it’s not expecting to receive excluded deps back in the tree.
... huh. It doesn't. At all. caesium
is there, but no version of manifold
, 0.1.8
or 0.1.9-alpha5
, is mentioned (for lein classpath
)
lein deps :tree
output:
...
[byte-streams "0.2.4"]
[manifold "0.1.8"]
[caesium "0.13.0" :exclusions [[manifold]]]
...
So because manifold
is a sub-import of byte-streams
, it's not correctly outputting/handling the exclusion? Or is that just a display thing
Ok, so I think that’s the problem. I’d have to go back and check the code, but from memory Cursive uses that to work out which libs to sync. Or at least the API under the hood that produces that tree. So with a bit of luck I might be able to shunt the blame onto the lein plugin 🙂
Although it’s entirely possible that it’s a bug in Cursive and that’s just a visual thing.
Well lein deps
outside of Cursive also pulls in 0.1.8
, so I would guess it's not just a display oddity?
Just getting one with minimal cruft. I had a load of IntelliJ namespaces at trace level in there before
2021-08-13 11:35:22,676 [ 90382] DEBUG - #cursive.namespace - Dependency cycle /Users/meyersd/.m2/repository/com/github/arohner/manifold/0.1.9-alpha5/manifold-0.1.9-alpha5.jar!/manifold/time.clj -> /Users/meyersd/.m2/repository/manifold/manifold/0.1.8/manifold-0.1.8.jar!/manifold/time.clj -> /Users/meyersd/.m2/repository/com/github/arohner/manifold/0.1.9-alpha5/manifold-0.1.9-alpha5.jar!/manifold/time.clj
Ok, I need to go to bed - it looks to me to be a problem in the lein-deps plugin, but I can’t rule out a Cursive bug there. Could you create a small repro repo that I could look at (I’m assuming the real one is a work thing?) and then I can debug the API coming back from lein to be sure.