This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-05
Channels
- # beginners (240)
- # boot (5)
- # cider (48)
- # clara (2)
- # cljs-dev (3)
- # cljsrn (66)
- # clojure (111)
- # clojure-denver (2)
- # clojure-italy (42)
- # clojure-nl (5)
- # clojure-spec (12)
- # clojure-uk (45)
- # clojurescript (138)
- # community-development (7)
- # core-async (8)
- # datomic (27)
- # emacs (21)
- # euroclojure (6)
- # figwheel (10)
- # fulcro (29)
- # graphql (5)
- # hoplon (3)
- # luminus (1)
- # lumo (7)
- # mount (4)
- # off-topic (13)
- # onyx (20)
- # parinfer (3)
- # pedestal (4)
- # precept (1)
- # proton (3)
- # re-frame (41)
- # reagent (3)
- # reitit (28)
- # ring-swagger (7)
- # shadow-cljs (88)
- # specter (1)
- # testing (10)
- # tools-deps (27)
- # vim (58)
@cemerick Nice to see you here! I’ve been meaning to ask you how are things going with nREPL 0.3 and how we can help you get it out the door?
when i update from cider 14 to 16, it creates a new elpa directory entirely; is it fine to just delete the old 14 directory?
describe-package
(bound to`C-h p` by default) would show you. Also version should be highlighted in the output of list-packages
i've been hit now by this issue, so I'm trying all the various things in there: https://github.com/clojure-emacs/cider/issues/2140
closed emacs, then i nuked cider from .emacs.d/elpa, restarted emacs and cider automatically re-appeared in elpa and worked. similar to others' experiences in that gh issue.
Is there anything I can set to make the track-state
middleware less "chatty"? I'm building a simple nrepl client into shadow-cljs and must account for the user having cider-nrepl
active. This is fine but on any eval
I get the usual results plus one :changed-namespaces
message. This message is about 830kb which is a bit much given that I do not use it.
nevermind. I'll just remove the track-state middleware completely. forgot that I control the middleware stack.
You’ll not lose much I guess - if you’re not processing those messages the way CIDER does, they don’t add much value.
hmm no can't remove it. It is connecting to the same nrepl endpoint that cider would connect to.
I do like the track-state in that it tracks the current repl-type. just the :changed-namespaces
is a bit large and for some reason the cache doesn't seem to work
The idea for track state was to reduce server round trips. We keep a lot of relevant metadata on the client-side, that gets “auto-pushed” after certain ops and the client can potentially do a lot of useful things with it (cider uses it currently just for syntax-highlighting semantically vars).
It seems to me that you removing it from the middleware stack would be fine, though. I don’t think it has touch points with anything else, except maybe the debugger.
problem is that this is a web client and reading 830kb has a noticeable delay of about 500ms
It’d very simple for us to add some “start” op that has to invoked for this to work.
I guess a better solution to be to add some “client” property to the requests so we can do different things for different clients.
Anyways, CIDER will keep working even without this - only font locking will certainly be broken. Have to check about what else would be impacted.
I'll just switch to transit so the parse doesn't take that long. I think the cache doesn't work properly because I don't send the correct nrepl messages yet. I guess it relies on clone
first (or whatever else I'm supposed to send first)
sounds like a good idea for the client to send an init
message on connect though. could send some info about itself and its capabilities. similar to https://github.com/Microsoft/language-server-protocol/blob/gh-pages/specification.md#initialize-request-leftwards_arrow_with_hook
anybody has some idea how aggressive-indent-mode can conflict with multiple cider repl connections? seeing the same issue right now as reported here: https://github.com/Malabarba/aggressive-indent-mode/issues/104
@thheller You can also take a look at the code. It’s pretty simple and it will give you a good idea how this is supposed to work https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/track_state.clj
That’s probably the most important thing - https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/track_state.clj#L220 The nREPL ops that trigger a cache update.
@kommen - @malabarba should certainly have the best idea as wrote both aggressive-indent-mode and CIDER’s dynamic indent functionality. I can’t imagine how multiple connections might be slowing down things, unless the algorithm for determining the current connection isn’t extremely slow.
It’d best to run the profiler for a bit and submit the results in the ticket you’ve created.
As a workaround you can disable the dynamic indentation, as I’m assuming it’s making aggressive-indent-mode slower. I stopped using it a while ago, as I noticed it was very inefficient on any bigger source files (with or without a connection).
@bozhidar thanks, I’ll try to gather some more info and attach it to the issue. I too was very surprised that just closing the cider repl buffers improved the aggressive indent performance significantly
It’s because when CIDER is running it augments the static indentation rules from clojure-mode
(using the indentation metadata described in CIDER’s manual). That’s an optional features that gives users a lot of flexibility over the indentation of things like complex macros.
The documentation may have a problem. It says that :repl-options {:init (set! *print-length* 50)}
to my lein profile should work, but it is ignored by cider (it only works within lein's REPL). It seems CIDER needs its own variable set, cider-repl-print-length
. The docs say only the CIDER variable will take precedence if both are set, but if only the lein profile is changed, CIDER still uses its default value of 100.