cider 2020-11-27 | Slack Archive

andrea.crotti12:11:54

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

andrea.crotti12:11:59

or just kill whatever is printing out?

andrea.crotti12:11:24

I added the auto trimming but it doesn't really help as much sadly

practicalli-johnny12:11:53

@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...

andrea.crotti12:11:41

yeah I know but sometimes it takes minutes to even be able to run these two commands

andrea.crotti12:11:57

the whole Emacs get locked and you can't really do much

andrea.crotti12:11:12

I can kill the JVM process from the outside which sometimes helps but it's not great

andrea.crotti12:11:02

maybe cider could just have a limit to the size of the string it prints out by default?

andrea.crotti12:11:13

since if it's bigger than a given threshold it's very likely to just be a mistake

practicalli-johnny16:11:16

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

bozhidar10:11:53

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.

bozhidar10:11:07

I still don't have any better solutions in mind than what we currently have.

hkjels20:11:46

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 solution

dpsutton20:11:28

I’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

hkjels20:11:17

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

hkjels20:11:15

[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

hkjels20:11:29

everything works in the browser as it should though

dpsutton20:11:21

Not sure how to setup the 10x stuff. I think there are some preloads to register or something like that? The documentation shows how to do it I think

hkjels20:11:53

Yeah.. That works with cider-clojure-cli-global-options set

2020-11-27

Channels