This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-27
Channels
- # announcements (2)
- # aws (17)
- # babashka (13)
- # beginners (84)
- # calva (46)
- # chlorine-clover (40)
- # cider (19)
- # clojure (27)
- # clojure-australia (1)
- # clojure-europe (84)
- # clojure-nl (2)
- # clojure-uk (49)
- # clojurescript (65)
- # core-async (6)
- # cryogen (1)
- # cursive (11)
- # datomic (13)
- # etaoin (3)
- # jackdaw (5)
- # jobs (2)
- # kaocha (34)
- # minimallist (6)
- # off-topic (17)
- # pathom (2)
- # pedestal (11)
- # re-frame (8)
- # reagent (5)
- # rewrite-clj (19)
- # shadow-cljs (30)
is there any way to make sure that if by mistake I print out a massive amount of text in the repl, I can still kill the repl without having to kill Emacs entirely
or just kill whatever is printing out?
I added the auto trimming but it doesn't really help as much sadly
@andrea.crotti
cider-interrupt
if output is from the last evaluation of an expression. Or sesman-quit
should kill the repl. Or kill the buffer and it should kill the repl (unless your code is hanging onto resources and wont shut down. I dont think there are any guarantees with any software...
yeah I know but sometimes it takes minutes to even be able to run these two commands
the whole Emacs get locked and you can't really do much
I can kill the JVM process from the outside which sometimes helps but it's not great
maybe cider could just have a limit to the size of the string it prints out by default?
since if it's bigger than a given threshold it's very likely to just be a mistake
This may only work in some cases, but if you have the cider-inspect window open, then evaluation results should all go there by default. I don't think this helps if something is forcing errors into the repl, like 3rd party Java or Scala libraries. If something is logging, it should be going to an external logging service
The output is being streamed in chunks, that's why even if Emacs rejects printing something over some limit only interrupt can potentially stop the generation of more output. That's also why we went with auto-trimming instead of putting some hard limit for the output - as new chunks get streamed the older should get deleted. Unfortunately, if something outputs an extremely long line this might mess up Emacs quite a lot.
Why is it that I only get an nrepl and not the usual cider-repl if I set cider-clojure-cli-global-options
to "-M:dev"
, which in turn uses
:dev {:extra-deps {;; Tracing, debugging etc.
com.bhauman/figwheel-main {:mvn/version "0.2.12"}
org.clojars.stumitchell/clairvoyant {:mvn/version "0.2.1"}
day8.re-frame/re-frame-10x {:mvn/version "0.7.0"}
day8.re-frame/tracing {:mvn/version "0.5.1"}}
:main-opts ["-m" "figwheel.main" "-b" "dev" "-r"]}
I think maybe, I’ve bumped into this issue before, but I don’t remember the solutionI’m not sure what you mean by an nrepl but you’re not starting the nrepl command line as required. Nrepl needs its own main to start an nrepl server. You’re specifying figwheel main to do it’s own startup
if I leave cider-clojure-cli-global-options
at nil
, move the figwheel-main dep into my top-level deps and jack in, it works just fine with the REPL, but then I don’t have re-frame-10x etc
[nREPL] Starting server via /usr/local/bin/clojure -Sdeps '{:deps {nrepl {:mvn/version "0.8.3"} cider/piggieback {:mvn/version "0.5.2"} cider/cider-nrepl {:mvn/version "0.25.4"}}}' -M:dev -m nrepl.cmdline --middleware '["cider.nrepl/cider-middleware","cider.piggieback/wrap-cljs-repl"]
This is done even though I set cli-global-options, but a REPL buffer is not connected to it