This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-30
Channels
- # announcements (14)
- # aws (2)
- # beginners (167)
- # calva (25)
- # cider (124)
- # cljs-dev (2)
- # cljsrn (7)
- # clojars (2)
- # clojure (113)
- # clojure-europe (2)
- # clojure-italy (6)
- # clojure-spec (30)
- # clojure-uk (90)
- # clojurescript (20)
- # code-reviews (16)
- # cursive (28)
- # data-science (2)
- # datomic (89)
- # duct (97)
- # emacs (4)
- # figwheel-main (12)
- # fulcro (37)
- # graphql (3)
- # java (3)
- # jobs (2)
- # juxt (3)
- # kaocha (37)
- # leiningen (2)
- # luminus (2)
- # off-topic (30)
- # onyx (2)
- # pathom (3)
- # qlkit (1)
- # re-frame (7)
- # reagent (2)
- # reitit (62)
- # remote-jobs (9)
- # shadow-cljs (26)
- # tools-deps (19)
- # vim (1)
- # yada (8)
someone had asked about an issue here but did they delete it? I'm looking into what is going on
if you posted here about oz.core, i think you can fix this issue by adding [org.clojure/tools.reader "1.3.2"]
to your project.clj file. CIDER-nrepl is requiring 1.2.2 and causing your issue. I'm surprised that this is an issue as I thought Mr. Anderson would take care of this
so I’m trying to eval clojurescript
blocks in org-mode
without having to narrow into them, but cider-read-and-eval
does not evaluate on the correct REPL. Any ideas how I would go about this?
i suppose you can't really do that due the way messaging is implemented between the nrepl server and client. but can't quite remember the details
Yes nrepl is not. But tools reader is and it is resolving to the 1.2.2 version of tools reader from nrepl (which is inline) rather than the 1.3.4 that enlive declares
it seems to me that since 0.19 the cider-nrepl jar is published on clojars with all its deps
1. Unhandled clojure.lang.ExceptionInfo
A build with id "dev" is already running.
{}
core.clj: 4739 clojure.core/ex-info
core.clj: 4739 clojure.core/ex-info
main.cljc: 1959 figwheel.main$start_STAR_/invokeStatic
main.cljc: 1936 figwheel.main$start_STAR_/doInvoke
RestFn.java: 445 clojure.lang.RestFn/invoke
main.cljc: 1939 figwheel.main$start_STAR_/invokeStatic
main.cljc: 1936 figwheel.main$start_STAR_/invoke
It looks like figwheel-main is trying to start the figwheel-main repl server by itself...
that's what you expect to happen with (figwheel.main.api/start {:mode :server} "dev")
correct?
@dpsutton I'm trying to validate that my team members that are using vscode will be able to connect the repl.
ok. so your confusion comes from the fact that cider-connect-cljs
tries to start another :dev repl is that correct?
@dpsutton no, they haven't tried yet. We were using lein-figwheel previously and I'm changing it to figwheel-main
and I want to be sure that everything goes smoothly.
hm.. not at my laptop atm :/ @dpsutton you mean that when you run make install you still see the the full (wrong) dep tree?
i released refactor-nrepl snapshot lately, same mrandeson version. looks ok on clojars
ah i think i was making 0.20.1-snapshot and checking against 0.20.0 so i was not seeing my test
this basically means tho that cider-nrepl 0.19 and 0.20 is broken deps wise in a very subtle way
eg deps are still inlined i guess (have not checked) but these versions are messing with projects' deps trees
@dpsutton @U0508JT9N i tracked the cause to this commit: https://github.com/clojure-emacs/cider-nrepl/commit/f2b83f8af8def64b8e140fc590b5230d69152201
I will revert and push a new snapshot now
wonder if we should release a 0.20.1 and modify the machinery in cider tho pull that rather than 0.20.0
I’m not sure why it’s causing it, but reverting it fixes it locally
Yeah it’ll be a 0.20.1-SNAPSHOT
I’m not sure r.e. the cider release. I don’t know how the jack-in deps injection works these days – I only use cider-connect
. I’ll take a look at the code
Likely it doesn’t affect most people but will get worse as more people bump their tools.reader deps
if you put cider-nrepl in your project you can step on toes with all cider-nrepl toes
Yeah, it does, but I mean I don’t know enough about how jack-in works to know if we’ll need to release a 20.1 of the elisp client
Looks like we’ll need to bump cider-latest-middleware-version
[cider-nrepl "0.20.1-SNAPSHOT"]
is built now if you want to test
and bumping the middleware version means we need a release if we want this fixed in stable quickly
@achikin is it feasible to let your coworkers start up from the console like that and you just cider-jack-in-cljs
and let CIDER start the figwheel server itself?
@dpsutton yes, I usually do like that. Was just wondering if I can just connect without starting anything...
i copied the startup that CIDER uses to crank up a repl so it will have the cider nrepl guts in it but made it not a headless repl
/home/dan/bin/lein update-in :dependencies conj \[nrepl\ \"0.5.3\"\] -- update-in :dependencies conj \[cider/piggieback\ \"0.3.10\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.20.0\"\] -- repl
from there, do your incantation of requiring the api and starting the {:mode serve}
(not server)
then cider-connect
and run (figwheel.main.api/cljs-repl "dev"))
or cider-connect-cljs
and when it asks you for the init form give it (figwheel.main.api/cljs-repl "dev")
it looks like there is no good way to do a custom repl with dir locals right now. it just asks the minibuffer for input
Does CIDER have middleware to aid in the selection of text objects? e.g. finding top-level form at cursor, finding element at cursor, and so forth? Or is this done all in elisp?
For context, I'm kind of rebuilding CIDER for kakoune... So I'm trying to figure out what I can reuse.
but you'll run into issues of what does the process think the source code looks like versus what are you evaluating
ie redefining defuns. if you ask the middleware for the thing at point it would be the last thing that was evaluated and not some potentially unsaved code
I mean, the source has to be sent to nREPL for that to work. So you send a 'code' key and an 'op' of 'find-toplevel' or some such.
yes. which means the text editor that does the sending needs to be the one that is aware of the bounds of the defun, what is at point, etc
but if there are top level things and you're sending and reading the entire file content every time you have problems
you also won't be sending what you are currently seeing but what is currently saved which could be very surprising and frustrating
I'm not sure how sending the entire file when the user requests selecting a top-level form is a problem. Seeing vs. saved seems easy to solve, as the editor needs to send what you are seeing to the middleware.
I have no freaking idea why the approach described here https://nrepl.org/nrepl/usage/misc.html#_hot_loading_dependencies does not work for me. For instance I can see that indeed the clojure.core.memoize was added to classpath but for some reason when I try to require it I receive an error :thinking_face: