Fork me on GitHub

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


if I didn't delete it, how would I know which version of cider is getting used?


Yeah, you can remove it completely.


Normally package.el should ask about deleting the old packages after an upgrade.


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:


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.


so, should be good now


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.


looking at the cache it appears that this is supposed to be cached


nevermind. I'll just remove the track-state middleware completely. forgot that I control the middleware stack.


I was going to suggest this.


You’ll not lose much I guess - if you’re not processing those messages the way CIDER does, they don’t add much value.


But it’s a valid point we should be able to start/stop it explicitly I guess.


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


hmm maybe I just switch it to transit. that should be faster


It’d very simple for us to add some “start” op that has to invoked for this to work.


yeah problem is when I remove it on my end it won't be available to cider


which is bad for my users that expect cider to work properly


could spin up a secondary nrepl server without that middleware I guess


I guess a better solution to be to add some “client” property to the requests so we can do different things for different clients.


Or something along those lines.


Anyways, CIDER will keep working even without this - only font locking will certainly be broken. Have to check about what else would be impacted.


yeah thats not acceptable. things must work as expected 🙂


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


anybody has some idea how aggressive-indent-mode can conflict with multiple cider repl connections? seeing the same issue right now as reported here:


@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


That’s probably the most important thing - 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).


Reindenting big buffers is simply too expensive.


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


ah, that’s what you referred to as “dynamic indentation” I guess


thanks for the pointers, I’ll need to read up on that


You’re welcome!


I'm worried about when they depend on different artefact names, for the new nrepl

Michael Fiano23:04:07

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.