This happened:
CL-USER> (/4 5.)
Invoking restart: Retry applying /4 to (5).
Invoking restart: Reset this thread
; Evaluation aborted on #<CCL::UNDEFINED-FUNCTION-CALL #x302000B0B6AD>.
CL-USER> (/ 4 5.)
sljk
No matter what I type, the CL-USER> prompt does not return. Obviously, I had a typo and didn't include a space after the / which gave me the error screen (what's that REPL screen called?). I must have chosen an option that was one of the abort options, but while it gave me the CL-USER> prompt right after that, it is somewhat "inactive" as you can see here.
How to exit out of this situation?
This happens to me when I manage to fry the underlying Lisp instance. Alternatively, if I manage to kill the thread that SLIME is interactive with... that also damages the instance.
Check the *inferior-lisp* buffer for clues; if it's hung, M-x slime-restart-inferior-lisp will restart your underlying Common Lisp.
Related
I'm on ubuntu 19.
Using emacs, slime and sbcl to practice some lisp.
Currently I have one buffer in slime mode in one window and the slime-description in the other window.
When I want to execute a line, I write it on the buffer and press C-c C-p.
But when I try to do the same for the line
(defvar *name* (read))
to set the the name var with the user input, nothing is happening.
Why ?
Also I would like to execute the whole script and not one line at a time, how do I do that ?
'Nothing is happening' because read is waiting for you to type something at the REPL. If you look at the REPL you will be confused because the form you are evaluating is not displayed, so all you see is ... nothing, but you need to type something at it. Further, it's not clear from your description what buffers you have displayed, but I suspect the REPL is not one of them, which is going to make things even worse.
I don't know how other people use SLIME, but what I do is to have at least the REPL (the thing you get after typing M-x-slime in one window, and a file I am working on in another. You can then interact with the REPL just by typing at it, and send code to the running lisp from the file with C-M-x or any of the other commands (in particular things like C-c C-k which compiles & loads the file.
However you almost never want a file you are compiling or loading to include anything which causes read to be called at compilation or load time: the results are going to be mysterious to put it mildly: the system will just stop with no prompt waiting for you to type something. It makes much more sense to do that in the REPL:
CL-USER> (defvar *name* (read))
(here is the data I am typing in)
*NAME*
Indeed, even when you go to some lengths to make calls to read non-mysterious in files being loaded, you have to go to yet further lengths to make them safe. Consider this file, toxin.lisp:
(defvar *my-thing*
(progn
(format *query-io* "~&thing? ")
(finish-output *query-io*)
(read *query-io*)))
Now:
$ lisp
[...]
(load "toxin" :verbose t)
;Loading #P"toxin"...
thing? #.(quit)
Of course there are much worse things I could have said than that to the Lisp.
When I accidentally make an infinite loop by evaluating a form in emacs with geiser + racket, after a minute or so of waiting, eventually emacs will start to respond again. Unfortunately, every eval after that takes at least a minute. Usually, after the second or third eval, emacs will stop responding at all, and the fastest thing to do at that point it to restart the Ubuntu machine.
Is there some setting to prevent this in geiser, or a way to tell emacs to kill geiser?
Here's what I do when something hangs up.
Over the years, I don't recall Emacs being stuck in an unrecoverable state.
Use C-g. Repeatedly if needed. It calls keyboard-quit.
This should break any stuck loop and give you the ability to enter commands.
Now if geiser or any other process is misbehaving, just kill the buffers
that correspond to this process.
C-x C-b will give you the list of all buffers.
If you don't recognize the one that belongs to geiser, just restart Emacs
and open only geiser and see the buffer list again.
Now mark the misbehaving buffers with d.
Execute the deletion with x. That's it. You can
now restart geiser or whatever else. This approach is completely generic.
By the way, restarting the Ubuntu machine is too drastic.
When nothing works to stop the application with a window, but X still works,
use xkill utility. I've bound it to Ctrl-Alt-F12 for instance.
Then you just click on a window you don't like and it's gone.
If xkill doesn't work, switch to a virtual terminal with
Ctrl-Alt-F1 and use htop to kill the application.
According to the REPL documentation, you should be able to use C-c C-q to kill the REPL. From the link to the REPL documentation, go to the First Aids section; it's near the bottom of it.
Geiser hangs on loops here also. In emacs 24.3.1 running on Debian 7 updated two days ago; M-x run-geiser; Then one gets a window with a REPL prompt. All is good, but then say > (define f (* f (- n 1))), then > (f 3) and the process in the buffer is locked up. C-c C-c and C-c C-q do nothing. Killing the buffer, answering yes to the query of killing subprocesses, and then restarting does get one to a REPL prompt with all definitions gone.
I'm trying to write an emacs function that executes a shell command every 5 seconds. However, I can't get the pause to work. Here's what I have:
(while '(test)
(insert (format "echo hello"))
(comint-send-input))
(sleep-for 0 5000)
I suspect that the sleep is ignored for reasons related to functional evaluation of Lisp. Any advice on how to get the pause to occur after each command evaluation?
As mentioned in the comment, the issue is with a paren.
Also, I've just tried sit-for in *scratch* and it performs smoother compared to sleep-for.
(while 1
(insert "hello")
(sit-for 1))
But both lock up Emacs, since it's single threaded, so you should be careful with this sort of activity.
Consider using async package or something similar instead.
I'm in search for a better technique for doing it. My general struggle is with the fact that debugger enters either too late or too early to be able to catch the value of the variables.
What I tried first:
(loop for i from 0 to 10 do
(break))
When debugger enter on break, I can't access i :( So it's a wasted effort. I've tried e option of debugger (eval in frame), but SLIME generally just bugs out, and I have to reconnect to SWANK. v or t don't help, because the variable just "isn't there".
What I ended up doing:
(loop for i from 0 to 10 do
(signal i))
This is stupid, but works, because it puts i on the stack of the frame I can examine in debugger. But this is just... well, it's hackish in the worst sense of the word. Isn't there some way to "watch" a variable, or have a more meaningful way to put a breakpoint, such that I can see more variables around the place the breakpoint is entered?
Your first snippet works just fine for me with CCL (default optimize settings), Emacs 24, and a recently pulled Slime:
Break
[Condition of type SIMPLE-CONDITION]
Restarts:
0: [CONTINUE] Return from BREAK.
1: [RETRY] Retry SLIME REPL evaluation request.
2: [*ABORT] Return to SLIME's top level.
3: [ABORT-BREAK] Reset this thread
4: [ABORT] Kill this thread
Backtrace:
0: (#<Anonymous Function #x186F9B7E>)
Locals:
I = 0
1: (CCL::CHEAP-EVAL (LOOP FOR I FROM 0 TO 10 DO (BREAK)))
⋮
sldb-eval-in-frame works fine for me, too. Maybe you should try a different Lisp implementation or a different version of Slime.
Also, note that different optimize settings might be important here, and some implementations give better debugging results for interpreted code (if an interpreter is available, that is). Try something like (declaim (optimize (debug 3) (speed 0) (space 0))).
I need a check for whether or not a process is still running in my emacs term; started via (term "/bin/bsh") and then renamed to, eg. term-A.
I have tried (term-check-proc "term-A"), but it doesn't show what I what I need, or at least, I don't see how I can use it.
Trying to chase it down by a shell call to ps afx (or the like), is problematic if there is more than one emacs term active and running the same program, (which in my case, is quite quite possible)...
I really need to know if a process in a specific emacs term buffer, term-A, is running or not.
You can get a buffer's process with get-buffer-process:
(get-buffer-process "*shell*") -> #<process shell>
(get-buffer-process "*scratch*") -> nil
After I exit the shell in *shell*, I get nil for that buffer too.