My emacs stops working when I try to evaluate a piece of lisp code in the scratch buffer (with eval-last-sexp) or the minibuffer, with the above error. I cannot recover from this, I have to kill the emacs process.
The function is:
(defun add-to-list (val list-of-numbers)
(mapcar #'(lambda (num) (+ val num))
list-of-numbers))
I have tried on a fresh spacemacs installation to exclude that there is something wrong with my configuration file but I get the same problem.
This seems like a well formed function and the function name displays in the minibuffer after evaluation, so it seems to be evaluated fine. But then the above error occurs.
Can somebody explain based on this information?
add-to-list is a Emacs build-in function. Maybe the redefinition is here the source of your problem?
What happens if you choose another function name?
Related
I am trying to trace a function in emacs lisp. I am trying to use trace-function and friends, but no trace is produced. The *trace-output* buffer gets created, but nothing is written in it.
Here is a minimal example of the problem:
(progn
(require 'trace)
(untrace-all)
(defun f () 'hello)
;(trace-function 'f)
;(trace-function-background 'f)
(trace-function-foreground 'f)
(f))
Executing this from within *scratch* returns 'hello, but not trace information is written to either *trace-output* or *scratch*.
I have tried it with each of the three trace functions above without success.
Am I doing something wrong?
How can I get trace information to be produced?
Package trace.el defines the global variable inhibit-trace, which is initially nil.
However, entering the debugger set inhibit-trace to 't,
which remains in effect until the debugger is explicitly quit.
Simply closing the *Backtrace* buffer does not exit the debugger.
My problem was that I had entered the debugger earlier in my sesion and not quit it explicitly.
This behaviour deserves to be better known :)
Is it possible to update the program code while it is being interpreted by csi, the Chicken Scheme Interpreter? If so, how?
So that I can interactively change part of the code and immediately see the effects of that changes.
For example, suppose I have written the following program:
(define (loop)
(print "Ciao")
(rest 1)
(loop))
(loop)
(assume (rest 1) has the effect of pausing the program for a second).
If I run this program, trough csi, it prints the string "Ciao" every second. If I change the string "Ciao" into something else, for example into "else", and I save the program code file, then csi continue interpreting the old program code, so I continuously see the string "Ciao". I'd like, in this case, that when I save the modified code with the string "Ciao" replaced by "else", csi continue its interpretation job by looking into the modified file, instead of the old file.
So that I obtain as output some "Ciao" followed by some "else": the "else" start to appear when I replace "Ciao" by "else" in the source code.
In general, the answer is "don't". The way you're supposed to use the REPL is by evaluating piecemeal changes against it, then evaluating a function or two to make sure everything went as expected. Part of this approach is structuring your program so that it can be easily tested in pieces, which implies not automatically starting any infinite loops. In the specific case you're asking about, you could instead write
(define (do-stuff)
(print "Ciao"))
(define (main-loop)
(do-stuff)
(rest 1)
(main-loop))
(define (start) (main-loop))
You can now incrementally develop do-stuff, periodically evaluating new versions to your interpreter and calling them to make sure they work, then eventually calling start once you're confident that it's doing the right thing.
You may get mileage out of this similar question asked about Common Lisp.
As an aside, if you were using Common Lisp and SLIME, you could now do more or less what you proposed:
(defun do-stuff ()
(format t "Ciao~%"))
(defun main-loop ()
(loop (progn (do-stuff)
(sleep 1))))
(main-loop)
Starting that up would start printing Ciao on separate lines in your SLIME REPL. If you changed do-stuff to
(defun do-stuff ()
(format t "else~%"))
then hit it with C-c C-c (the default binding for slime-compile-defun), you'd see your SLIME REPL start printing else lines in-flight.
CL-USER> (main-loop)
Ciao
Ciao
Ciao
; compiling (DEFUN DO-STUFF ...)else
else
else
else
else
else
; Evaluation aborted on NIL. User break.
CL-USER>
I'm not sure how to accomplish the same thing in Scheme, but I'm reasonably sure it's possible.
All that being said, you sometimes want to run a program part of which is an infinite loop. A real world example would be while testing a TCP server of some sort. If you're in such a situation, and your desired workflow is
Write file
Run csi my-file.scm
Edit file
Kill csi
Run csi my-file.scm
goto 3
and you basically just want to automate steps 4 through 6, you'll need an external tool to do it for you. Take a look at entr or hsandbox (the latter doesn't have Scheme support out of the box, but it doesn't look like it would be too hard to add).
There is no common way to make a running program check its source for changes but you there seems to be enough feratures available in Chicken to roll your own:
(use posix)
(use srfi-18)
(define (watch-reload! file)
(define (tsleep n)
(thread-sleep! (seconds->time (+ n (time->seconds (current-time))))))
(define (get-time)
(file-modification-time file))
(thread-start!
(lambda ()
(let loop ((filetime '()))
(let ((newtime (get-time)))
(when (not (equal? filetime newtime))
(load file))
(tsleep 10)
(loop newtime))))))
Now all you have to do is to use watch-reload! instead of load and it will check and reload every 10 seconds if the file has been modified.
If you save when the file is not valid scheme it stops working until you call watch-reload! on it again.
It may be that chicken programmers might have a better solution.
I am using Guile in conjunction with Geiser under Emacs while learning how to program in Scheme. I find it actually a hindrance that Guile drops into a debugger each time I make a typo or enter a wrong piece of code. How can I make Guile more tolerant of my typos/errors and skip the debugger, while using it through Geiser under Emacs?
As I get more advanced in Scheme programming, how would I restore the default behavior or else how can I toggle between having the debugger always start vs start only on demand?
You can set the on-error option to report, and it will simply report the error without dropping you in the debugger (that's the default value, debug); e.g.
scheme#(guile-user)> ,option on-error 'report
scheme#(guile-user)> (/ 1 0)
ERROR: Throw to key `numerical-overflow' with args `("/" "Numerical overflow" #f #f)'.
scheme#(guile-user)>
See: https://www.gnu.org/software/guile/manual/html_node/System-Commands.html
I don't really write a lot of Scheme, but it seems that you can just ignore the debugger.
If you're using lispy to do the
eval with e, you don't even see the REPL window, you just
get messages in the echo area with the result.
If you set (setq geiser-impl--implementation 'guile), and press
e in lispy-mode, it will start a Geiser REPL
automatically (if there isn't a live one) and eval the expression.
I got strange error from SBCL compiler, so may be someone can explain to me what is going on there. For information the package uses optima and drakma. I really tried to minify posted code, but this amount required to understand the problem.
(defun signal-vk-error (code)
(error ;; <--- HERE IS THING
(case code
(100 'parse-error)
(otherwise 'error))))
(defmacro match-with-error (response matcher)
`(match ,response
((alist (:ERROR . code))
(signal-vk-error code))
,matcher))
(defun api-call-response (resp)
(match-with-error
resp
((alist (:RESPONSE . data)) data)))
Compiling this file I got:
; caught ERROR:
; don't know how to dump CODE (default MAKE-LOAD-FORM method called).
Unhandled TYPE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
{1002BF6F03}>:
The value NIL is not of type (AND ATOM (NOT NULL)).
So there it looks like sbcl (1.2.4) can't create binary representation, but I can't underestand why.
If I just change ERROR to SIGNAL in signal-vk-error - everyhing compiles, loads and works as expected. I can also just load file in slime and eval is, it will work without errors and warnings.
So, the question is, what is wrong with error? What is major difference between error and signal?
UPDATE 1: Interesting observation, if I remove signal-vk-error function, and just put this code inside macro defenition it will compile ok.
UPDATE 2: Thanks to #RainerJoswig, declaring signal-vk-error not to be inlined fixes the problem. Reported to SBCL team, looks like they doing some optimization, which brokes compilation in this case.
Smallest way to reproduce the problem:
(defun signal-vk-error ()
(error 'error))
(defun api-call-response ()
(optima:match 1
((not 2)
(signal-vk-error))))
If I macroexpand or walk the match form, the problem disappears.
The following also makes the problem to disappear.
(declaim (notinline error))
As it came out, there is a problem in compiler, in fact two of them, one of which is allegedly a feature. Anyone interested can read the conversation between one of SBCL hackers and the author of optima in bugtracker.
For now this fixed in optima side by not revealing pattern object during macroexpasion, commit d7ec93d0df4920b9a7b4a492e7aadf52480f437c
I am trying to dynamically find the name of the current function (this-function) running i.e.
(defun my-func ()
(remove-hook 'some-hook this-function)
(do-something))
I haven't tested this, but why not write a macro to encapsulate what you want? Something like the following, maybe?
(defmacro one-shot-hook (name hook &rest body)
`(defun ,name ()
(remove-hook ',hook ',name)
,#body)
Then, for example
(macroexpand-all-1
'(one-shot-hook test c-mode-hook
(message "Yay!")))
gives
(defun test nil
(remove-hook (quote c-mode-hook) (quote test))
(message "Yay!"))
(when I've reformatted it).
This removes the problem of needing to know the name of the function you're in, which would need nasty macrology anyway (I'm not sure whether it's possible).
One more thing, I'd probably suggest just having a flag variable set to nil initially which your code tests to decide whether to run. Then you don't have to mess around adding and removing hooks all the time: the result will probably be much easier to customise and understand for anyone else using your code.