Fork me on GitHub
#cider
<
2017-01-20
>
magnars09:01:55

Anyone know why the :cljs part of reader conditionals are colored like comments in the latest clojure-mode?

magnars09:01:22

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.

dpsutton13:01:14

yeah, a new feature from a new contributor

dpsutton13:01:27

if you change to clojurescript mode it should then "comment out" the clj path

jfntn13:01:51

The documentation says it changes depending on the connection, but AFAICT it’s the mode instead

dpsutton13:01:08

the connection is kinda determined by the mode

dpsutton13:01:21

especially if you're in a cljc buffer (which i assume you are in)

dpsutton13:01:26

i'm working on cleaning all of this up

dpsutton13:01:32

the cljc handling is a little off

dpsutton13:01:40

and how to determine what connection you are using, etc

dpsutton13:01:17

i think the change of the assumption from "there is a connection" to "there can be multiple connections" was not handled everywhere

dpsutton13:01:42

so the code reaches out to the cider-current-connection sometimes in places where its processing an alternate connection

dpsutton13:01:53

i'm working on making this connection (the repl buffer) thread through all of the code

dpsutton13:01:06

and then on the response side, making sure to grab the connection based on the session id

dpsutton13:01:16

so that there's always a connection in every function

jfntn15:01:16

@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

jfntn15:01:07

I remember trying to debug one of those current-connection issues and the whole thing was pretty janky

dpsutton15:01:53

yeah so much of the code feels entitled to ask for the current connection

dpsutton15:01:16

in fact, when running clojurescript code it doesn't trust to find a clojurescript connection and it looks for buffers by name

dpsutton15:01:49

because there was a bug where you pass in a connection to cider-map-connections but it would reach out and grab the session

dpsutton15:01:55

so this led to one repl having output from the other repl

dpsutton15:01:04

and then making that repl think it was a clj repl rather than a cljs repl

jfntn15:01:47

That's in fact the bug I looked into!

jfntn15:01:23

Didn't get very far though, did you fix that?

dpsutton15:01:01

not totally

dpsutton15:01:03

its everywhere

dpsutton15:01:07

but that's what i'm trying to fix

jfntn15:01:23

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

dpsutton15:01:43

here's the one i fixed in load file

dpsutton15:01:47

(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))

dpsutton15:01:15

the session was grabbed from (cider-current-session) but now it gets it from the connection passed in

dpsutton15:01:21

this was the bug causing the repl to lose track

dpsutton15:01:34

but the best thing is that we don't have to write the session at all

dpsutton15:01:46

at the final nrepl function that actually puts the request into the other process, it adds a session if there isn't one

dpsutton15:01:02

so we just need to make sure that the connection follows everything down the path and the last step will add the session

dpsutton15:01:16

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

jfntn15:01:34

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?

dpsutton15:01:46

so if you know how the map across connections thing works, it takes a connection

dpsutton15:01:59

but when you're making the request, that request might add the session id for the clojure repl

dpsutton15:01:07

so your clojurescript repl starts thinking its clojure

dpsutton15:01:19

and that's why you have to look for clojurescript repls by name rather than by the type

jfntn15:01:31

right, this used to drive me crazy 😛

dpsutton15:01:32

because the handler watches for state changes and records if its clojre or clojurescript repl

dpsutton15:01:40

that's my mission, to clean all that up

jfntn15:01:53

The solution sounds like a good compromise

jfntn15:01:26

Honestly the only thing that still really bugs me is the slowness of the repl when printing large data structures

dpsutton15:01:45

i think that's an emacs thing with long lines though

dpsutton15:01:49

i'm wondering what to do about that

dpsutton15:01:53

maybe turn off font-locking

jfntn15:01:00

This has always been an issue and I’ve tried various pprint workarounds etc, but it’s still an issue

jfntn15:01:06

If I remember correctly everytime I looked into this there was a clear culprit in the profiler and that was the response filter

dpsutton15:01:34

do you remember what?

dpsutton15:01:40

i know it loops over all buffers for some weird reason

jfntn15:01:01

let me look into it quickly it’s been a while

jfntn16:01:05

So I tried (range 1e5) in the repl with the profiler on.

jfntn16:01:17

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.

jfntn16:01:33

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.

jfntn16:01:44

The profiler output doesn't seem to make a lot of sense in this case, especially this part:

jfntn16:01:47

- 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%

jfntn16:01:08

That for cpu

jfntn16:01:19

Found a closed issue that seems related:

dpsutton16:01:28

yeah i think that's where it goes backwards some amount and truncates stuff before that

dpsutton16:01:38

i've heard going backwards in emacs can be kinda slow

jfntn16:01:45

The implementation seems to be doing the same thing comint does and that’s never been an issue in my experience

dpsutton16:01:57

i think there's a long-term goal to switch over to comint

jfntn16:01:51

Unclear from the last few comments in this thread: https://github.com/clojure-emacs/cider/issues/709