From time to time I get a "nesting exceeds `max-lisp-eval-depth'" error.
What does it mean?
When I get one, is there something I can do, other than "killall emacs"?
Edit:
You can get the error if you evaluate:
(defun func ()
(func))
(func)
However, in this case emacs remains responsive.
An immediate remedy can be to simply increase the maximum. Its default value is 500, but you could set it to, say, 10000 like this:
(setq max-lisp-eval-depth 10000)
But that's generally not a great idea, because the fact that you run into a nesting exceeds `max-lisp-eval-depth' error in the first place is a sign that some part of your code is taking up too much stack space. But at least increasing the maximum temporarily can help you analyze the problem without getting the same error message over and over again.
Basically, it means that some Lisp code used up more stack than Emacs was compiled to permit.
In practice, it's a sign of a bug in Lisp code. Correctly written code should avoid nesting this deeply, even if the algorithm and the input data were "correct"; but more frequently, it happens because of an unhandled corner case or unexpected input.
In other words, you have probably created an endless loop via recusion, or perhaps e.g. a regular expression with exponential backtracking.
If you are lucky, repeated control-G keypresses could get you out of the conundrum without killing Emacs.
If you are developing Emacs Lisp code, you might want to tweak down the value of max-lisp-eval-depth artificially to help find spots where your code might need hardening or bug fixing. And of course, having debug-on-error set to t should help by showing you a backtrace of the stack.
Related
as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.
I've Emacs setup for Verilog, SystemVerilog and UVM.
I use auto-complete, solarize theme and verilog-mode as add-ons.
I need to work on C once in a while, however with C Emacs feels very laggy (takes a while for auto-complete suggestions) and it creates bunch of 0 byte files in my working directory (with names containing symbols -- not letters).
I'm not sure about the cause or how to debug and solve the issue. I would appreciate if someone can help me with finding and solving this issue.
[EDIT]: I understand this can be lacking in information, however right now I'm not sure what type of information I should be providing, I will provide information as required
[EDIT2]:
I've commented following portion of init file and my c editing is working well, What part of loading auto-complete can cause these?
The problems I was facing:
1. Creating random symbol files with 0 bytes of size in working directory (name would look like ?/??UR...)
2. Laggy: takes a while for character to show up when typed
;; This section is required to enable autocomplete and verilog dictionary
;;(add-to-list 'load-path "/home/user/.emacs.d/")
;;(require 'auto-complete-config)
;;(add-to-list 'ac-dictionary-directories "/home/user/.emacs.d//ac-dict")
;;(ac-config-default)
;;ac-modes - mojor modes ac can run on
;;(add-to-list 'ac-modes 'verilog-mode 'c-mode)
;;toggle auto complete in all buffers
;;(global-auto-complete-mode t)
I understand this can be lacking in information, however right now I'm not sure what type of information I should be providing, I will provide information as required
That's the right attitude, and yes, you sensed correctly that the problem description is currently too broad for people to be able to help (unless you are lucky and find someone who recognizes the same combination of setups etc.).
The first step is to isolate the cause of the problem, at least to one (instead of 3) feature that you are using. IOW, break down your "setup for Verilog, SystemVerilog and UVM" which uses "auto-complete, solarize theme and verilog-mode as add-ons", so that you can report that the problem is only in using, say, auto-complete. Or is only in the combination of, say, theme solarize with verilog-mode.
IOW, at the highest level this is no different from any other debugging scenario.
As it stands now, you are, in effect, telling us that you have this big sack of stuff and you want someone to guess what is going on.
To narrow the problem, recursively bisect your init file, commenting out bigger and bigger chunks, until you know what part(s) of it are really causing the problem. Comment out 1/2, then 3/4, then 7/8,... You can use command comment-region to comment or (with prefix arg C-u) uncommment the selected text.
Once you have a better idea of what is causing the problem, report back here with the refined problem statement and the additional info you've learned.
At that point you will also want to specify what you mean by this or that being "laggy". You will hopefully be able to give others a recipe to reproduce the effect you see, and you will be able to describe better what you expected to see, but didn't.
I do really like key-chord.el but I'd need it to only trigger when I start pressing keystrokes after a short delay during which I didn't do anything elapsed. I'd like to know if it's easy to modify key-chord.el to do that.
Why I want that is simple and I'll try to explain it as easily as I can:
I do want keychords to be assigned to keys that are on my "strong" fingers (no pinky) and that are on my home row (I do touch-type). Hence I'm potentially creating quite a few keychords which may clash with common words / code when I'm typing.
I realized that everytime there's a clash (i.e. keychords kicking in while I didn't want to) it's because I'm in the process of frenziedly modifying the buffer.
Here's an example...
I'm a fast typist so if I'm entering, say, "held", there is never going to be a long delay between when I add the 'e' of "held" and when I then type the 'l'. So in this case it should be "obvious" that I do not want key-chord to kick in when I type 'ld'. However if there's a pause and if 'ld' is an assigned key-chord and then I hit 'ld', then it is very unlikely that I'm writing code / text that would be starting with 'ld'. So in this later case (and because I have assigned 'ld' to a key-chord), I do want it to kick in.
Now don't get me wrong: I'm not sayin this would eliminate every single possible clash in every single case. All I'm saying is that, in my case, this would probably eliminate 99.9% of the (already rare) clashes. The "time lost" should one clash still occur after this change to key-chord would be negligible compared to the amount of time key-chord is making me gain.
The code to key-chord.el is very small so maybe such an addition wouldn't be too hard?
Does anyone have an idea as to how if it would be easy to modify key-chord.el to provide such a feature? (I hope I explained correctly what I want to do)
Here's the code to key-chord.el and half of it is comments:
http://emacswiki.org/emacs/key-chord.el
The Idle Timer mechanism should be able to facilitate this.
C-hig (elisp) Idle Timers RET
I'll leave it to you (or someone else) to figure out the details. Offhand thoughts are:
enable the Key Chord functionality via an idle timer
use post-command-hook to disable it again
That might be all that is needed?
I see two timings at play here
time before the chord (between the letter before the chord and the chord. If short enough, no chord)
time after the chord (if new letter quickly typed, no chord)
The second type of timing is probably more natural, and easy to get used to. If one type the chord, a short timeout before it executes can be accepted. (This is not what you asked for and would not solve the "ld" example. But it could potentially solve the problem with letter combinations that may appear in the beginning of words.)
The first type of timing is probably harder to get used to. When one have completed typing a word and the next thing is to type a chord, I suspect it is not a natural instinct to make a short pause. If one uses the chord often, one is likely to type it quickly, and get annoyed if it is not recognized (and the two chars are inserted into the text instead). What I want to say is, I am not sure a timing before the chord will solve the problem to a satisfactory degree.
As for the implementation of such a timing. The way the state machine in the key-chord-input-method function is currently structured, it would grow exponentially with the number of timers to consider (if I recall correctly). I.e. there would be at least about a dozen new lines of code.
To experiment with the functionality, try phils suggestion in the other answer: a post command that disables chords, and an idle timer that, after a fraction of a second, enables them again. A quick and dirty way to disable and enable chords, without actually changing minor mode, would be to set the input-method-function variable.
Code for test purpose only. It assumes, but does not check, that key-chord-mode version 0.5 is loaded and enabled:
;; Helper functions to be used in timers and hooks
(defun my-enable-chords () (setq input-method-function 'key-chord-input-method))
(defun my-disable-chords () (setq input-method-function nil))
;; Start test
(add-hook 'post-command-hook 'my-disable-chords)
(setq my-timer (run-with-idle-timer 0.3 'repeat 'my-enable-chords))
;; Finish test
(remove-hook 'post-command-hook 'my-disable-chords)
(cancel-timer my-timer)
My clojure repl started throwing a "Variable binding depth exceeds max-specpdl-size" error and I've gotten thrown into the debugger.
I am currently accessing slime via clojure-jack-in and I am executing a reduce on a reasonable sized dataset. A bit of googling leads me to believe that the error is because I'm generating too many temporary variables, specifically:
User Option: max-specpdl-size
This variable defines the limit on the total number of local variable bindings and unwind-protect cleanups (see Cleaning Up from Nonlocal Exits) that are allowed before Emacs signals an error (with data "Variable binding depth exceeds max-specpdl-size").
This limit, with the associated error when it is exceeded, is one way that Lisp avoids infinite recursion on an ill-defined function. max-lisp-eval-depth provides another limit on depth of nesting. See Eval.
The default value is 1000. Entry to the Lisp debugger increases the value, if there is little room left, to make sure the debugger itself has room to execute.
found here.
I have little experience with debugging clojure-swank/slime so I hope someone can help.
EDIT:
I'm using clojure-mode 1.11.4 with emacs 24 and clojure 1.3.0, I've not installed swank-clojure, I'm using the one that comes bundled with clojure-mode via clojure-jack-in as I explained earlier.
Just in case someone is looking for a possible answer to this questions....
This error, as outlined, does often mean a problem, but not always. You can legitimately exceed the default depth setting in situations where you have large data structures or where you are usiing some emacs features, such as defadvice, which can result in deep bindings etc. You can increase the depth and see if that helps (for example, double it), but in this case it probably is an error.
One of the problems with swank-clojure is that it is tightly coupled with an old version of slime. This means improvements and bug fixes in slime are not available. It is because of this tight binding that the coljure community has moved away from using slime to using cider and I'd strongly recommend switching to using cider rather than slime and swank-clojure.
I'm relatively new to Lisp (I just know the very basics) and I'm currently trying to run an algorithmic composition program created by David Cope. It runs in MCL 5.0, and I keep getting the following error:
Error in process play: Stack overflow on value stack.
To globally increase stack space, increase *minimum-stack-overflow-size*
Does anyone know what function I would use to increase the stack overflow size and how I would calculate the best stack overflow size for my computer? I'm running MCL on an old Powerbook with 512 MB of RAM.
Thanks for your time,
Eddie
Originally memory options were edited with ResEdit.
One can also use the SAVE-APPLICATION function and use the :MEMORY-OPTIONS keyword to specify various values. This is described in the MCL reference manual. This function saves a new MCL application. Typically one starts vanilla MCL, sets various options, loads some libraries and then saves a new application. This new application is then used during development.
The necessary stack size depends on the program you want to run.
If a stack overflow happens, in MCL you can continue with a larger stack in many cases. Just choose the right restart option.
It seems to say that you simply need to modify the special variable *minimum-stack-overflow-size*. When you are at the REPL (CL-USER> prompt or similar), inspect this variable by evaluating its name:
CL-USER> *minimum-stack-overflow-size*
Then, set it to a bigger value (the 1234567 is just a placeholder) with setf:
CL-USER> (setf *minimum-stack-overflow-size* 1234567)
However, this might not be the real issue. I do not know MCL well, but it might be necessary to (declaim (optimize (speed 3) (safety 0))) or similar to enable tail call elimination, if the program you want to run uses a tail recursive function which depends on such optimization.