This code drops me into the LDB in SBCL from SLIME but not the termial:
(declaim (optimize debug)) ;; inhibit tail-call optimization
(defun stackoverflow () ;; infinite recursion
(stackoverflow))
(unwind-protect
(stackoverflow)
(stackoverflow)) ;; called during handler for the first stack overflow
Why does this crash SBCL from SLIME but not the terminal?
Notice that a valid (ANSI) Common Lisp implementation is allowed to ignore any declarations except the special declaration. I guess the SLIME REPL has slightly different behavior here (since it is not the same as the sbcl toplevel - it adds some things like reuse of previous results)
Related
I use paredit on emacs with SLIME's repl. This means that at any point during my typing on the repl, my s-expressions are balanced.
However, they may not be complete, and I might want to continue typing inside them in another line, as follows:
CL-USER> (defun print-hello ()
)
When I start a new line by pressing the enter key, however, the SLIME repl executes my incomplete expression. I want it to wait for me to complete the expression, as follows:
CL-USER> (defun print-hello ()
(format t "Hello, world"))
How do I make this happen please?
For that situations, when writing long s-expressions in REPL I think that the best way is to use the slime scratch buffer. you can edit it and after that execute with
C-j
No problem pressing enter inside the buffer, I'm using sly but the capture could be like this:
(defun print-hello ()
(format t "Hello, world"))
; => PRINT-HELLO
Also another alternative is working without the last parent :-(
or as suggested in a comment by #jkiisky, type the expression and add in the middle of the s expression C-j
CL-USER> (defun
)
Related to your question, lispy provides integration with SLIME.
I typically never type anything into the REPL buffer. Instead, I edit all code in place in the source file, and use e to eval the current sexp.
lispy is also a super-set of paredit, if compatibility is your concern.
When I enter this at the REPL prompt:
(setf (readtable-case *readtable*) :invert)
I get this error message:
Error in SETF [or a callee]: Cannot expand the SETF form (READTABLE-CASE
*READTABLE*).
Why do I get this error?
(format nil "~A ~A" (lisp-implementation-type) (lisp-implementation-version)) says "Kyoto Common Lisp GCL 2.6.2". The result of (eq 'readtable-case 'cl:readtable-case) is T. What does this all mean please?
The second expression means you're using the correct symbol. The first indicates which Lisp implementation you're using: That should be GNU Common Lisp 2.6.2
After some search I found this message on the gcl-devel list saying ...
The problem appears to be this line:
(setf (readtable-case *readtable*) readcase)
in randomly-check-readability. I'd recommend this as the next
ansi issue to resolve, since it's blocking the tests.
... with a subject line "ansi-tests in 2.7.0". The message is from 2004.
Bottom line: I guess you need a more recent or even* a different Lisp implementation.
(* as mentioned by Rainer Joswig the issue also affects the current 2.6.12 release)
I guess all major Lisp implementations support this. CLISP 2.49 does, SBCL and CCL probably do, as far as I know ECL does also.
I'm starting to play with CLisp, and therefore Emacs too, including the "SLIME" plugin (or whatever it's called. How is it called?)
So I've been playing with the REPL for quite some time now, and defined a lot of functions in there with (defun).
Unfortunately, none of these functions have been written in a text file, and I don't fancy retyping all that. Is there a way I could dump or otherwise save the work that has been done in the REPL to a file? (bonus points if the file is Lisp source code :) )
SLIME is an elisp program for interacting with Lisp.
There's no simple option to recover functions you've typed only into the repl into a file. function-lambda-expression can sometimes return code, but it often does not.
If the repl is still in a buffer, you could copy the whole thing into a file and then use string or regexp replacement to isolate the function definitions.
It's not too hard to avoid this problem in the future.
Most people work by writing definitions into a file, and then using a key combination to send them to Lisp, bypassing the REPL. I use the C-c C-c combination when the cursor is on a function to compile and load the expression. C-x C-e also works. Then I switch the the REPL to actually use the function.
See also the function DRIBBLE, which makes sure a log is written.
foo:~$ clisp
...
[1]> (dribble "foo.text")
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo.text">
[2]> (+ 3 4)
7
[3]> (defun bar (baz) (* baz baz))
BAR
[4]> (bar 10)
100
[5]> (quit)
Bye.
Let's look at the file:
foo:~$ more foo.text
;; Dribble of #<IO TERMINAL-STREAM> started on 2015-05-08 21:38:48.
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo.text">
[2]> (+ 3 4)
7
[3]> (defun bar (baz) (* baz baz))
BAR
[4]> (bar 10)
100
[5]> (quit)
Bye.
The last paragraph in Xach's answer is what it is all about.
When programming in Lisp, typing function definitions directly into the REPL is the wrong way to do it. The right way is to set up your text editor (emacs) so that with certain keystrokes, the expression at the cursor (the entire function definition) is sent to the REPL. Then to invoke a function, you switch to the REPL. This is what SLIME is for.
Strictly speaking, the text in your emacs buffer doesn't have to be written to a disk file, in which case it will be gone after you close the editor. But normally you save it to a file.
You can search through your REPL history for the function definitions. If you have the beginning of an expression already typed in, then SLIME will only cycle through previous entries that begin with the same thing:
CL-USER> (defun
Press M-P from there, and you'll cycle through all the defuns you've typed in.
I get this message when starting SLIME:
; loading #P"d:/lisp/slime-2.12/swank-loader.lisp"
STYLE-WARNING: redefining EMACS-INSPECT (#<SB-PCL:SYSTEM-CLASS T>) in DEFMETHOD
The REPL works normal.
I am totally new to EMACS and SLIME and I'd like to know what does this mean and how to fix it.
I use Windows 8 (64-bit), GNU Emacs 25.0.50.1 (x86_64-w64-mingw32), SLIME 2.12, and SBCL 1.2.7
I addressed folks in GitHub and jackcarrozzo replied
with this post:
Good question - it took a bit of spelunking to find a full answer. The short answer is that emacs-inspect stores handlers for inspecting objects; when a particular object is inspected, the relevant generic function (based on type) will match and be evaluated. From http://lisp-book.org/contents/chslime.pdf page 16, you can run this to see the currently-attached generics:
M-. swank-backend:emacs-inspect
That pdf also describes creating your own inspector as well as additional features that look pretty cool.
Regarding your second point: lots of stuff gets printed to the slime-events buffer; unless you're having a slime-specific issue, you probably don't need to even have it open in a window. Warnings and so forth relevant to your code and interactions will come out either directly in the REPL, in the inferior-lisp buffer, or in one of a few other buffers that emacs/slime will auto-open for you when needed.
CL-USER> (use-package :elk)
; Evaluation aborted on #<SB-KERNEL:SIMPLE-PACKAGE-ERROR "The name ~S does not designate any package." {1002C9D683}>.
CL-USER> (defun moose (a) (+ a 7))
MOOSE
CL-USER> (defun moose (a) (+ a 8))
STYLE-WARNING: redefining COMMON-LISP-USER::MOOSE in DEFUN
MOOSE
CL-USER>
So, in summary: don't worry about it. Slime makes interfacing Common Lisp in emacs simple, and it does a great job of staying out of the way. Slime does admittedly have a ton of features but it doesn't force you to use them. Note to self: I should really get around to learning them some day...
I am trying to inspect the value of a variable at a determined breakpoint. Here is my simplified code:
(defun foo ()
(maplist (lambda (var)
(break)
var)
'(a b c)))
slime goes into debugger mode at this point. So I try to eval by pressing either the ":" or the "e" key and then I type "(car var)", but slime keeps on saying:
The variable VAR is unbound.
[Condition of type UNBOUND-VARIABLE]
I am confused as to why it's saying this since "(break)" is within the anonymous function and within the scope of "var".
That works for me under CCL and CLisp. I think whether this works depends on your implementation, and maybe your OPTIMIZE settings. You could try:
(declaim (optimize (debug 3)))
You'll have to recompile your code afterwards for it to take effect.
Or maybe, if your implementation supports interpretation, you could try that, since some implementations provide better debugging possibilities for interpreted than for compiled code.