This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-20
Channels
- # arachne (11)
- # aws (2)
- # beginners (33)
- # boot (167)
- # cider (71)
- # clara (2)
- # cljs-dev (28)
- # cljsrn (3)
- # clojars (1)
- # clojure (83)
- # clojure-austin (21)
- # clojure-dev (24)
- # clojure-russia (19)
- # clojure-spec (33)
- # clojure-uk (108)
- # clojurescript (114)
- # component (1)
- # core-async (1)
- # cursive (7)
- # datomic (13)
- # editors (1)
- # emacs (15)
- # hoplon (10)
- # lein-figwheel (4)
- # leiningen (3)
- # mount (2)
- # om (134)
- # om-next (4)
- # onyx (42)
- # pedestal (41)
- # quil (2)
- # re-frame (29)
- # reagent (4)
- # remote-jobs (6)
- # ring-swagger (5)
- # untangled (9)
Anyone know why the :cljs
part of reader conditionals are colored like comments in the latest clojure-mode?
From messing around with it a bit, it "comments out" the code that isn't active for the current repl connection. Makes sense, I guess. It felt a bit odd, but it's probably only a case of habit.
The documentation says it changes depending on the connection, but AFAICT it’s the mode instead
i think the change of the assumption from "there is a connection" to "there can be multiple connections" was not handled everywhere
so the code reaches out to the cider-current-connection
sometimes in places where its processing an alternate connection
i'm working on making this connection (the repl buffer) thread through all of the code
and then on the response side, making sure to grab the connection based on the session id
@dpsutton that sounds great and would be a very welcome addition! I’ve learned not to rely on the current behavior and always use the assoc buffer with connection command and force the mode, but obviously that’s a workaround
I remember trying to debug one of those current-connection issues and the whole thing was pretty janky
in fact, when running clojurescript code it doesn't trust to find a clojurescript connection and it looks for buffers by name
because there was a bug where you pass in a connection to cider-map-connections
but it would reach out and grab the session
If I remember correctly I gave up after realizing how much code would have to change to pass the connection around, great to hear someone is looking at improving that
(defun cider-request:load-file (file-contents file-path file-name &optional connection callback)
"Perform the nREPL \"load-file\" op.
FILE-CONTENTS, FILE-PATH and FILE-NAME are details of the file to be
loaded.
If CONNECTION is nil, use `cider-current-connection'.
If CALLBACK is nil, use `cider-load-file-handler'."
(cider-nrepl-send-request (list "op" "load-file"
"session" (if connection
(cider-session-for-connection connection)
(cider-current-session))
"file" file-contents
"file-path" file-path
"file-name" file-name)
(or callback
(cider-load-file-handler (current-buffer)))
connection))
the session was grabbed from (cider-current-session)
but now it gets it from the connection passed in
at the final nrepl function that actually puts the request into the other process, it adds a session if there isn't one
so we just need to make sure that the connection follows everything down the path and the last step will add the session
and then on the back end, we'll recover the connection from the session in the message and do the same thing as we bubble back up
Oh because as the op made its way down to the backend, different functions would reach for the current-session and get different results along the way?
but when you're making the request, that request might add the session id for the clojure repl
and that's why you have to look for clojurescript repls by name rather than by the type
because the handler watches for state changes and records if its clojre or clojurescript repl
Honestly the only thing that still really bugs me is the slowness of the repl when printing large data structures
This has always been an issue and I’ve tried various pprint workarounds etc, but it’s still an issue
If I remember correctly everytime I looked into this there was a clear culprit in the profiler and that was the response filter
At first I had pprint and font-lock enabled and the profiler reported nrepl-client-filter
taking 60% of the cpu time, mostly in font-lock.
Then I turned cider font-lock off in the repl and tried again, to my surprise it got a lot slower and updated much less frequently.
The profiler output doesn't seem to make a lot of sense in this case, especially this part:
- cider-repl-emit-result 1,056,360,816 82%
- cider-repl--show-maximum-output 130,501,736 10%
+ recenter 439,608 0%
+ insert-before-markers 34,208 0%
+ add-text-properties 13,488 0%
+ cider-set-buffer-ns 3,755,575 0%
yeah i think that's where it goes backwards some amount and truncates stuff before that
The implementation seems to be doing the same thing comint does and that’s never been an issue in my experience
Unclear from the last few comments in this thread: https://github.com/clojure-emacs/cider/issues/709