Recently, I often encounter errors like this:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
I found that in some situations, the error is caused by expressions like this:
(= nil 4)
I'm not sure whether this expression is intended to write like this, but it will work only if I change it to:
(eq nil 4)
However, (1) I need to replace all = to eq in that emacs lisp script (2) I'm not sure the codes should be modified like this.
I was wondering that whether I can write a few lines in the config file (.emacs) instead of modify on the source code to get things done. Does anyone have ideas about this?
Don't do this.
You're going down the path of hiding errors in code. Figure out the root
cause of why you're passing nil to = and fix that.
Related
A few times each day, I receive an ispell error (like the following) that is corrected by restarting Emacs. Any ideas on how to further troubleshoot this type of error would be greatly appreciated.
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
ispell-command-loop(("Brae" "Br ea" "Br-ea" "Bra" "Bread" "Break" "Bream"
"Brew" "Bret" "Bred" "Area" "Urea") nil "Brea" 2229 2233)
ispell-process-line("^Brea, CA ~ 92821\n" nil)
ispell-region(1 6771)
ispell-buffer()
ispell()
call-interactively(ispell nil nil)
command-execute(ispell)
The document being spell-checked is in tex-mode (built-in -- i.e., not using AUCTeX). The error (today) comes form a simple address at flush-left:
242 S. Orange Avenue\\
Brea, CA ~ 92821
Try loading ispell.el and then:
Try to provoke the error. After loading the source file (not the byte-compiled file), you will perhaps get a more detailed backtrace, which will tell you better what causes the error. (You apparently already have debug-on-error non-nil.)
If that doesn't tell you enough, then do M-x debug-on-entry ispell-command-loop, and walk through the execution in the debugger. That should show you just what goes wrong - where that function expects a number and hasnil instead.
Based on your better understanding, you will likely know what to do, to either avoid or fix the problem.
If you cannot reproduce the error easily then #2 will probably not be of much help. In that case, you can try examining the code of ispell-command-loop to see if you can figure out where the problem is.
You can also copy that code and insert calls to message at various places, to try to determine where things go wrong when they do go wrong. IOW, provide yourself with some more info than that sparse backtrace.
Maybe someone else has a better idea - mine is pretty much brute force here.
I've been seeing this a lot lately and am not sure if it is an SBCL issue, an Emacs problem, a SLIME problem, or my own understanding of what it means to "compile" a lisp file.
I will have a function, say this:
(defun some-function (x) (call-this-funcshun))
I will compile and run this, and I'll get an error that my function call-this-funcshun is not defined. Then I realize that is because there is a typo. So change it:
(defun some-function (x) (call-this-function))
In Emacs, I recompile the entire file with Control-C Control-K (Emacs saves automatically before the compile as well). Emacs then reports Compilation finished. I move to the REPL. I try it again, type (some-function whatever) and I get the same error. I search through the small lisp file and see that call-this-funcshun is clearly nowhere in it. Yet I have an error that this function is not defined.
Is there some sort of caching that Emacs or SBCL is doing that causes this to hang around? It's driving me nuts. Worth noting that if I quit SLIME and then launch it again, the issue is resolved. Also worth noting that this does not affect all my code edits, just occasionally.
Maybe the file is not loaded for some reason.
I would set *load-verbose* to T and watch that LOAD actually gets called.
Setting *load-print* to T would then also cause the printing of information about definitions loaded.
I've seen two conditions that can lead to behavior that looks like what you saw:
When the symbol in the file is not the same as the symbol at the REPL. The symbol's name is only a shorthand for identifying the symbol, and the same shorthand can identify different symbols based on which package you use it in. There are some ways to be surprised about which symbol you are referring to, so it can be worth checking with SYMBOL-PACKAGE even when you are pretty sure that they are the same.
When the buffer isn't saved. I'm not sure how C-c C-k deals with this now (because I edited it to auto-save for me), but in general compiling and loading tools tend to work from the file not the buffer.
I'm working on a program mode, which has various different calls to assemblers, programmers and other external programs. My cunning plan was to handle all of these with the compile function, passing an explicit compile-command that depends on which program is being run.
This sort of seems to work and now I want to add specific error regexps for the different external programs. One option would be to alter compilation-error-regexp-alist-alist, keyed on my major mode and then add my major mode to compilation-error-regexp-alist.
What I'd prefer to do, though, is something like the following:
(let ((compilation-error-regexp-alist
(cons <my-regexp-and-numbers> compilation-error-regexp-alist))
(compile <my-compile-command>))
What's weird is that this binding doesn't seem to affect the way the compilation buffer gets parsed / marked up. If I manually push <my-regexp-and-numbers> onto the front of compilation-error-regexp-alist and then call (compilation-mode t) on the buffer, everything gets fontified as expected (so I haven't got the regexp wrong). However, sticking the call to (compilation-mode t) inside a let form as above doesn't affect anything.
I realise this fails miserably as an easy-to-reproduce test case. If no-one has any ideas, I'll try to hack out an example, but I'm hoping that someone will go "Ah, yes! That's because doesn't get evaluated then, but rather at " or the like...
My guess is that the variable is set for the command but somehow is not passed to compile buffer.
Try your method and view the value of the variable (C-h v) inside the compile buffer for confirmation.
I'm working through Land of Lisp, using CLisp, writing the code in Vim with Slimv, then alt-tabbing to another terminal window and loading the file into the REPL with (load 'file.lisp), then running the programs at the REPL.
When I get an error in the REPL, is there any way to ascertain what line in file.lisp the error occurred on? I don't see line numbers mentioned explicitly in the REPL error output, is there any other way?
I found this similar question, but the only answer says to use something other than Clisp like sbcl, allegro, etc.:
How can I improve clisp error messages?
Thanks!
Simple answer: Just compile the code instead of loading it into the REPL: clisp -c file.lisp. Compiler error/warnings show the line numbers. Debug it that way, then load into the REPL. Good enough for now.
If you just want to know what function it occurred in, you can use ":bt" at the REPL prompt when an error happens. It'll print out a GDB-like stacktrace that you can use to figure out which function the error happened at.
The load function in clisp has an :echo option, see the implementation notes. When you use this option your files gets echoed to the output. Hence when an error occurs you can see the corresponding code. For your case the expression would be:
(load 'file.lisp :echo t)
Some extra options may be useful, such as :verbose and :print, in which case the expression would be:
(load 'file.lisp :verbose t :print t :echo t)
I just recently started experiment with SLIME, and found a problem that makes me unsure whether it is something I am doing wrong or if the current snapshot of SLIME is broken.
The problem: trying to change the package (using , !p) always throws an error, regardless of which backend is used.
The error from SBCL looks like this:
The value #("FOO" 0 3 (SWANK-IO-PACKAGE::FACE NIL)) is not of type (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING SYMBOL CHARACTER PACKAGE).
[Condition of type TYPE-ERROR]
CLISP and CCL throw the same error, though worded slightly differently.
I am running on Windows, but the same thing happens when I try it on Linux. I suspect that either there is something I am neglecting to do in my .emacs file, or there is a glitch in the current version of SLIME. I just started using SLIME yesterday, so I have no past experiences to compare it to.
Any ideas?
It's working for me. What version of slime is it? You could try grabbing the latest from source and see if that helps.