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

*cider-error* buffer seem to have buffer-undo activated #1004

Closed
Arcanum-XIII opened this issue Mar 4, 2015 · 5 comments · Fixed by clojure-emacs/cider-nrepl#169
Closed

Comments

@Arcanum-XIII
Copy link

I have this error quite often :

Warning (undo): Buffer cider-error' undo info was 14111968 bytes long. The undo info was discarded because it exceededundo-outer-limit'.

(Origin of the error seem to be an issue between piggieback/weasel | boot-cljs-repl | cider, filling the cider-error buffer)

I don't think this buffer need the undo to be activated ?

@cichli
Copy link
Member

cichli commented Mar 4, 2015

I don't think there should ever be that much data in the error buffer... we should definitely disable undo regardless.

Can you share the versions of cider/cider-nrepl/clojurescript/piggieback/weasel, or (even better) a project that will let me replicate? Or share what happens if you try do what you were trying to do in a normal lein repl?

@Arcanum-XIII
Copy link
Author

latest cider from melpa | cider nrepl 9.0-snapshot | piggieback should be 0.16-snapshot and weasel-6.0 (if my understanding of the boot-cljs-repl is correct - meaning I override piggieback/weasel in my local build.boot)
Boot is updated daily with 'boot -u'

I agree that something fishy is going on - especially since most of the time the cider-error buffer is "looking" empty - the joy of clojurescript ?

@noprompt
Copy link

I think this happens because it is getting hung up on dumping the exception info which contains the entire ClojureScript compiler analyzer data (this can be enormous).

1. Unhandled clojure.lang.ExceptionInfo
   #<TypeError: Cannot read property 'call' of undefined>
   {:type :js-eval-exception,
    :error
    {:status :exception,
     :value "#<TypeError: Cannot read property 'call' of undefined>",
     :stacktrace
     "TypeError: Cannot read property 'call' of undefined\n    at eval (eval at <anonymous> (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:25:470), <anonymous>:8:36)\n    at eval (eval at <anonymous> (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:25:470), <anonymous>:22:3)\n    at eval (eval at <anonymous> (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:25:470), <anonymous>:30:3)\n    at file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:25:465\n    at file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:34:4\n    at cljs.core.MultiFn.call.G__11305__2 (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/cljs/core.js:31473:113)\n    at cljs.core.MultiFn.call.G__11305 [as call] (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/cljs/core.js:32177:20)\n    at null.<anonymous> (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/weasel/repl.js:153:71)\n    at goog.events.EventTarget.fireListeners (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/goog/events/eventtarget.js:285:23)\n    at Function.goog.events.EventTarget.dispatchEventInternal_ (file:///Users/noprompt/git/outpace/glimpse-dev/resources/public/js/out/goog/events/eventtarget.js:382:26)"},
    :repl-env
    {:cljs.env/compiler
     #<Atom@638db3d7: 
       {:cljs.compiler/compiled-cljs
...

The total number of lines is 1741812...

@cichli
Copy link
Member

cichli commented Mar 11, 2015

@noprompt you're right - cljs.repl/evaluate-form, which piggieback relies upon, used to print a stacktrace and return nil when an exception was thrown. It now throws an ExceptionInfo whose data map includes (amongst other things) the entire CLJS REPL environment (and by extension the analyzer/compiler environment). The middleware pprints this to a string here, which pegs a Java process at 100% until I kill it (I didn't stick around for it to start killing emacs).

A workaround for now is to set cider-stacktrace-print-level to a low number like 5. Adding an equivalent option for setting *print-length* helps a bit but at a depth of 13 you hit what appears to be all of the non-minified Closure library in a single string.

@bbatsov a prudent solution for now is probably to blacklist the :repl-env key. Maybe in the long term we should use the inspector for optional browsing of this data rather than always printing it.

@bbatsov
Copy link
Member

bbatsov commented Mar 11, 2015

@bbatsov a prudent solution for now is probably to blacklist the :repl-env key. Maybe in the long term we should use the inspector for optional browsing of this data rather than always printing it.

Fine by me.

cichli added a commit to cichli/cider that referenced this issue Mar 14, 2015
cichli added a commit to cichli/cider that referenced this issue Mar 14, 2015
cichli added a commit to cichli/cider that referenced this issue Mar 15, 2015
nivekuil added a commit to nivekuil/cider that referenced this issue Sep 30, 2022
Same issue as clojure-emacs#1004, huge ex-data from pathom in my case. Dramatic performance improvement.

might be worth doing the same for clojure-emacs#2561
bbatsov pushed a commit that referenced this issue Sep 30, 2022
Same issue as #1004, huge ex-data from pathom in my case. Dramatic performance improvement.

might be worth doing the same for #2561
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

Successfully merging a pull request may close this issue.

4 participants