I have installed LispBox on Windows and it's running great. I do however have some trouble with debugging code : when I try and compile code and it contains an error such as a syntax error, the error message output (printed below) is not very useful.
Serious errors encountered during compilation of
"d:/Jervis/Documents/Programming/LISP/hw1.lisp"
[Condition of type SIMPLE-ERROR]
0: (CCL::%COMPILE-FILE "d:/Jervis/Documents/Programming/LISP/hw1.lisp" "d:/Jervis/Documents/Programming/LISP/hw1.wx64fsl" T NIL T T NIL T :DEFER NIL #<BACKEND WIN64 #x21001C6FCD> :DEFAULT NIL 0)
1: (COMPILE-FILE #P"d:/Jervis/Documents/Programming/LISP/hw1.lisp" :OUTPUT-FILE #P"d:/Jervis/Documents/Programming/LISP/hw1.wx64fsl" :VERBOSE T :PRINT NIL :LOAD NIL :FEATURES NIL :TARGET :WIN64 :SAVE-LOC..
2: (SWANK-BACKEND:CALL-WITH-COMPILATION-HOOKS #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK-BACKEND:SWANK-COMPILE-FILE) #x2100C2730F>)
3: ((:INTERNAL SWANK:COMPILE-FILE-FOR-EMACS))
Does anyone know how to get the line number of the code that is causing the compilation errors?
I have tried to follow the advice here of opening the Compiler Input buffer but that did not work. (The buffer was unavailable, and thus couldn't be opened).
Any Ideas?
A clarification first: the *Compiler Input* buffer you mention has nothing to do with Common Lisp and Slime, it is about errors that Emacs encountered when compiling Emacs Lisp (its internal lisp, quite different from CL).
As for your problem (determining a file name/line number to narrow down the problem): when I enter a broken piece of code in a file (say test.lisp):
(defun fact (n)
(if (= 0 n)
1
!(* n (facto (1- n)))))
, then try to send it to CCL via Slime by pressing C-c C-k in the test.lisp buffer, I get an error and a list of restarts (below the list of restarts there's also a backtrace similar to what you got). Select restart 0 by pressing 0, then 'n' to not load the broken compiled file into CCL. The buffer with the error should be replaced with a buffer named *slime-compilation*, which in my case contains:
cd d:/tmp/lispbox-0.7/
2 compiler notes:
test.lisp:2:5:
warning: Extra arguments in (IF (= 0 N) 1 ! (* N (FACTO (1- N)))) don't match lambda list (CCL::TEST CCL:TRUE &OPTIONAL CCL:FALSE).
style-warning: Unused lexical variable N
Compilation failed.
, which looks like it's what you wanted.
My hand-installed Linux CL setup doesn't need selecting the 0 restart and there's also a slime setting to avoid the 'load fasl file anyway (y/n)' prompt, so the experience can get better with some customization.
Related
I have the following code in a buffer (file ~/firsts.lsp):
(defun firsts (l)
(cond
((null l) ())
(T (cons (car (car l)) (firsts (cdr l))))))
(firsts '((A B) (C D) (E F)))
I would like to "run" this script and see the following output (or a reasonable variant thereof):
(A C E)
My buffer shows this mode:
(Lisp [COMMON-LISP-USER cmucl] adoc)
In trying to run it, I tried C-c C-k, which created a buffer slime-compilation that showed the file was "compiled" without errors, but I do not see a way to get the compiled code to execute or run the entire script through the interpreter.
Slime is installed and running (it's what coordinates the compilation). I know that I can run the forms through the repl, in a form by form manner, but I would like to run the entire script interactively.
Software Environment:
Mac OS X 10.12.3
GNU Emacs 25.1.1
Slime ChangeLog dates 2016-04-19
CMU Common Lisp 21b (21B Unicode) but same result with SBCL 1.3.14
One can imagine various ways how a Lisp source editor and a Listener (a read-eval-print-loop) work together. While SLIME is generally quite good, some of the interaction is slightly clumsy.
In this case there I use three ways to evaluate a buffer with SLIME/Emacs:
select the region, then evaluate the region using SLIME
SLIME eval buffer
save buffer, load buffer or compile-and-load buffer using SLIME
Note that if you evaluate things, results are printed in the mini buffer.
You also want to actually print something, so that you can see what happens.
Compiling things before loading/executing can help find errors. I use that often.
The actual list of key-commands for a buffer is seen on control-h m.
Side notes about interaction when evaluating a buffer
Another interaction style would be to feed each expression to a listener/repl buffer, have the results print there, until an error happens or there are no more expressions. But I don't think SLIME supports that in a direct way.
The LispWorks IDE lets you evaluate a buffer and the output (incl. the evaluation results) is displayed in a corresponding output pane.
The Clozure CL IDE lets you evaluate a buffer and the expressions are evaluated in the top most listener. Printed is the output and the last result.
if this is a duplicate please delete.
I was just editing my .emacs file and after i had my changes done. I
restarted emacs. But whet it comes up again it claims that the config
file has some errors. And i should start with "--debug-init" thats what
i also have done. But it did not helped me to solve nor find the syntax error.
So is there a way to find the lines which have syntaxerror. Or even better if
there would be something like a (e)lisp lint like you have for e.g xml, json, js
and so on. Thanks in advance
Edit
Managed to get the dump:
Debugger entered--Lisp error: (void-variable whitespace-mode)
redisplay_internal\ \(C\ function\)()
delete-process(#<process server-client-test>)
Someunicodefoo" [("server") server-use-tcp server-auth-dir server-socket-dir generate-new-buffer " *temp*" funcall make-byte-code 0 "Someunicodefoo" vconcat vector [buffer-name kill-buffer] 2 "\n\n(fn)" insert-file-contents-literally expand-file-name looking-at "127\\.0\\.0\\.1:[0-9]+ \\([0-9]+\\)" comm process-attributes string-to-number match-string 1 t :other delete-process make-network-process :name "server-client-test" :family local :server nil :noquery :service] 14 "\n\n(fn)"])
server-running-p("server")
byte-code("Someunicodefoo" [load-file-name buffer-file-name recentf-menu-before user-emacs-directory recentf-save-file server-name add-to-list load-path file-name-directory "../packages" tool-bar-mode 0 load "ergoemacs-keybindings/ergoemacs-mode" ergoemacs-mode 1 "init_load_packages" "init_version" "init_functions" "init_settings" "init_aliases" "init_abbrevs-lisp-mode" "init_keybinding" "init_mouse" "init_clean_menus" require recentf "Close" ".recentf" recentf-mode server server-running-p t server-start] 4)
load("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/../ergoemacs/init")
eval-buffer(#<buffer *load*-842275> nil "/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil t) ; Reading at buffer position 1432
load-with-code-conversion("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" "/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil nil)
load("/home/dirk/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el" nil nil t)
load-file("~/.emacs.d/ergoemacs_1.9.3.1/site-lisp/site-start.el")
eval-buffer(#<buffer *load*> nil "/home/dirk/.emacs" nil t) ; Reading at buffer position 2883
load-with-code-conversion("/home/dirk/.emacs" "/home/dirk/.emacs" t t)
load("~/.emacs" t t)
command-line()
normal-top-level()
One way to do it is to open the file and mark the first half of it and apply eval-region. If an error is reported, mark half of it and repeat. If an error isn't reported, apply it to the other half.
This way you could narrow down the problem and once you have found it you can hopefully figure out the problem.
Another technique I use to find incorrect parentheses is to add an extra parenthesis to the beginning and end of the file, respectively and run C-M-f and C-M-b from the beginning and end, respectively. If there are incorrect parentheses, they will match the newly added ones, and the point will move to the incorrect ones.
EDIT: You can use M-x check-parens to check for unmatched parentheses.
For "lint"-like checking, there's elint.el, but more importantly, there's the byte-compiler: M-x byte-compile-file RET lets you byte-compile a file and will give you all kinds of warnings about syntax and style.
But your backtrace indicates that the problem is probably not one of syntax. Most like there's a whitespace-mode that appears somewhere in a menu (i.e. in an :enable property of a menu entry), and that signals an error because the whitespace-mode variable happens not to be defined yet. So as Phils suggests, loading whitespace would probably work around the problem.
I am an hour new into programming in Emacs lisp. I have a little experience with scheme so I understand the big picture of lisps in general. However, I have only used the "pure functional" subset of scheme and do not know how to do practical tasks.
Write now, I know that C-x C-e will evaluate the code enclosed by the parentheses' by the current cursor position.
I wish to loop from i = 1 to 10 and print the values of i out. How is this done? I tried the following:
(defvar i 1)
(while (< i 11)
(print "i: " i)
(setq i (+ i 1)))
Emacs tells me: invalid function 0.
How do I do this correctly?
Why is emacs telling me invalid function 0
Feel free to give me tips about how to use the scratch buffer (all I know is C-x C-e evaluates) in emacs. Thanks for all the help!
EDIT1: Could someone tell me how to print out sequential values of i using a while loop?
EDIT2: When I evaluate the code, it opens up another tiny buffer showing each value of i one at a time. However, it is not a large buffer and only shows values of i from 13 to 19. When I try to get into that buffer, it closes immediately. How do I "scroll" through that tiny buffer? Note that I use emacs 24.3 through the terminal
EDIT3: I figured out that the tiny buffer is the Messages buffer. Is there a better way to view the output of my elisp code? The Messages buffer is full of other junk from evaluating things in emacs.
First and foremost, enable "Enter debugger on error" from the Options menu now and add (setq debug-on-error t) or (custom-set-variables '(debug-on-error t)) to your ~/.emacs.el.
Then you will get a *Backtrace* buffer on C-x C-e:
Debugger entered--Lisp error: (invalid-function 1)
1(10)
print("i: " 1)
(while (< i 11) (print "i: " i) (setq i (+ i 1)))
eval((while (< i 11) (print "i: " i) (setq i (+ i 1))) nil)
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
which shows that the error comes from print.
C-h f print RET will tell you why, but the upshot is that you want to use insert instead of print here.
Just as an added note, since you mentioned knowing some scheme -- if you like the interactive REPL that you can use in typical scheme environment, you might like ielm -- I think it probably stands for Interactive Emacs Lisp mode. Not sure. Anyway, M-x ielm RET will open up an emacs lisp REPL. Sometimes it is actually useful -- for example, when you want to inspect the content of a variable with a lot of data in it, ielm will print the whole thing out. Ielm is built in to my Emacs. Not sure when it was added to the standard distribution, but the earliest copyright in the source says 1994, so it is probably in your Emacs.
You can evaluate Emacs-Lisp sexps in *scratch* or in any other buffer in the same mode or (my preference) in mode emacs-lisp-mode.
In *scratch* you need only hit C-j (newline) after a sexp to evaluate it. In an emacs-lisp-mode buffer you can, as you said, use C-x C-e after a sexp. Or you can use M-x evaluate-region after selecting one or more sexps. As always, C-h m in any mode tells you about it, and usually lists important key bindings.
You can also check a global variable value using C-h v SOME-VAR. And you can evaluate any sexp on the fly from the minibuffer, using M-:. For example: M-: (setq foo (+ 42 (length bar)))
Wrt the debugger:
As #sds mentioned, debug-on-error puts you in the debugger when an error is raised. You can also set debug-on-quit and then enter the debugger using C-g to quit (e.g., during a loop).
If you know the function you want to debug, you can use M-x debug-on-entry.
Step through the debugger using d, or skip to the end of a step using c. Use q to quit the debugger.
You can also insert calls to function debug in source code, as debugger entry points: (debug).
The backtrace in the debugger is always more informative if you load the relevant source file e.g., foo.el, instead of the byte-compiled file, e.g., foo.elc. So before you use M-x debug-on-entry use C-h f to find out which file the function is defined in, and then load that file using M-x load-file /path/to/the/file.el.
There is also another debugger, besides debug -- look for edebug in the Elisp manual. Some people prefer edebug; I prefer debug.
According to this question, I can customize the variable *DEBUGGER-HOOK* so that it falls back to toplevel (in REPL) instead of the debugger. I've added this line to my ~/.sbclrc and it's all fine when I start sbcl from command line.
(setf *debugger-hook* #'(lambda (c h) (declare (ignore h)) (print c) (abort)))
But, the above doesn't work for Emacs SLIME. Whenever I compile/load a file (C-c C-k), it still invokes the debugger (with options like abort calculation, restart, enter new value etc.). How can I ask SLIME to just print the error message and throw me back to toplevel? Yea, it's with SBCL and the same ~/.sbclrc as before. Looks like SLIME doesn't respect a user's setting of *DEBUGGER-HOOK*.
As per http://common-lisp.net/project/slime/doc/html/Other-configurables.html setting SWANK:*GLOBAL-DEBUGGER* to nil in ~/.swank.lisp file should force SLIME to not replace *DEBUGGER-HOOK* to SWANK:SWANK-DEBUGGER-HOOK (which shows list of restarts etc.), but it somehow doesn't work for me, i.e. SWANK:*GLOBAL-DEBUGGER* is nil but anyway *DEBUGGER-HOOK* is replaced by SLIME. Maybe you'll be more lucky.
As a workaround I can propose to set *DEBUGGER-HOOK* to whatever you want in the slime-repl buffer manually, which is worked for me.
I've been randomly getting the following error in emacs:
Variable binding depth exceeds max-specpdl-size
...and I've been getting it at very random moments. After researching this, it seems as though some elisp somewhere is recursing too deeply. Are there any strategies for tracking this down? I'm totally at a loss as far as what is actually causing this.
I've gotten some errors indicating something along the lines of infinite recursion with ropemacs (but these are usually Python errors). Could something be misconfigured with ropemacs?
Update: Interestingly enough, I've found that I always get this error if I do a "C-h a" for "speedbar" but not for "rope-".
To track the problem down, you can try this:
(setq max-specpdl-size 5) ; default is 1000, reduce the backtrace level
(setq debug-on-error t) ; now you should get a backtrace
C-h a ; in speedbar
You should get a backtrace upon the error, and at that point, you can track down the offending routine.
I'd also try loading emacs w/out your configuration file (emacs -q), to see if there's something in your .emacs that is affecting things. (I don't get the infinite loop using C-h a). And if it is your .emacs, then the best way I've found to track that down is either binary search (put an error (error "frog") or somesuch in the middle of your .emacs, load, test, if no problems, put the error at 3/4, otherwise at 1/4, repeat...), or manually evaluate your .emacs line by line (region by region), testing after each portion. Those settings should help.
For me too it did not work. I found with C-h+v that actually max-specpdl-size was not changed to 5 at all by the setq. I then tried to set it interactively with M-x set-variable. That too did not change its value. Finally I managed to set it with M-x customize-variable.
Btw, on my system max-specpdl-size was 140 and thus to small. I had to increase it to 1000, not in order to get a backtrace and debug it, but to make it work.
The kind of bug still exists 10 years after the report, in XEmacs 21.4 (patch 24) "Standard C" [Lucid] (x86_64-linux-gnu, Mule). I get it from M-x vm (trying to read my e-mail, which I do many times every day).
Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
signal(error ("Variable binding depth exceeds max-specpdl-size"))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/home/brech/mail/folders/INBOX")
byte-code("..." [f full-startup access-method remote-spec buffer-file-coding-system folder string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
ad-Orig-vm(nil nil nil)
(setq ad-return-value (ad-Orig-vm folder read-only access-method))
(let (ad-return-value) (if (and ... mail-archive-file-name folder ... ...) (setq read-only ...)) (setq ad-return-value (ad-Orig-vm folder read-only access-method)) ad-return-value)
(lambda (&optional folder read-only access-method) "$ad-doc: vm$" (interactive (list nil current-prefix-arg)) (let (ad-return-value) (if ... ...) (setq ad-return-value ...) ad-return-value))(nil nil)
call-interactively(vm)
command-execute(vm t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
A crude work-around is quitting XEmacs and starting all over. Only quitting and re-starting vm does not help.