Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Effect of *print-length* might not be obvious #3

Open
viesti opened this issue Apr 4, 2020 · 7 comments
Open

Effect of *print-length* might not be obvious #3

viesti opened this issue Apr 4, 2020 · 7 comments

Comments

@viesti
Copy link
Contributor

viesti commented Apr 4, 2020

I had set *print-length* to a pretty conservative value (to prevent flood in general) and was wondering why data is missing from the vega graph. Could *print-length* be bound to nil for the duration of cider eval?

Coincidentally, the same thing bit me while playing with Oz, which helped in finding the cause of the problem in this situation 😅

@jackrusher
Copy link
Member

Thanks for the report! I've just pushed what should be a fix. Would you give it a try and let me know if it works for you?

@viesti
Copy link
Contributor Author

viesti commented Apr 5, 2020

Thanks! Did a quick try, but seems it didn't help. Thinking that the power of Leiningen {:global-vars {*print-length* 100}} in ~/.lein/profiles.clj seems to escape my understanding. My current workflow is the following

(ns local
   ...)

(defn vega []
   {:spec ...

;; Allow loading whole namespace, but keep a commented-out form handy for vega-view
#_(vega)

I bring cursor to end of the #_(vega) line and then hit M-x vega-view. Maybe what get's passed to vega-view this way, got evaluated somewhere else.

(set! *print.length* nil) at the repl helps though :)

@jackrusher
Copy link
Member

Hm. When I manually set the *print-length* to 100, I get the kind of shortening you'd expect, but vega-view still works properly on plots with thousands of values. Any chance you could pull the most recent version, re-eval that buffer, and give it another try?

@viesti
Copy link
Contributor Author

viesti commented Apr 6, 2020

Hmm, odd. Still getting the same behavior :/ I thought that this was a Leiningen magic thing, but seems to happen with deps.edn[1] too. Odd thing that when I hack the format to use set!, I get a full result:

(format "(do (set! *print-length* nil) %s)" clojure-form-string)

This of course leaves things a bit untidy :)

So there is probably something odd in my local setup. I did check though the other printing options in Cider, but it seems that I haven't changed the defaults. Might be that the offender dawns on me on some time later, maybe after a good night sleep (I'm fine with closing this issue also) :)

[1] Using a small deps.edn with a csv lib and pulling cider from my .clojure/deps.edn :cider alias:

           :cider {:extra-deps {cider/cider-nrepl {:mvn/version "0.24.0"}
                                refactor-nrepl {:mvn/version "2.5.0"}}
                   :main-opts ["-m" "nrepl.cmdline"
                               "--middleware" "[cider.nrepl/cider-middleware,refactor-nrepl.middleware/wrap-refactor]"
                               "--bind" "127.0.0.1"
                               "--interactive"
                               "--color"]}

@jackrusher
Copy link
Member

I've managed to replicate it here now. I'll tinker with it and let you know when it's sorted out.

@jackrusher
Copy link
Member

Further investigation suggests that the other cider printing options aren't being used (no pprint is applied to the returned text). I've temporarily added a set! in the clojure invocation code and documented that fact in the README, but I'll definitely need to circle back around later to figure out how to tell cider to do the right thing here.

@viesti
Copy link
Contributor Author

viesti commented Apr 7, 2020

Thanks for the effort! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants