slime-devel July 2007

slime-devel@common-lisp.net

25 participants
36 discussions

[slime-devel] Saving *slime-scratch*
by Nikodemus Siivola 11 Oct '08

11 Oct '08

The attached patch associates *slime-scratch* with a file if you name one as "slime-scratch-file". I've been running slime with this a while, and rather like it. Something like this was talked about a while ago, and dropped because of what looked like an ideologinal objection to scratch-buffers in my mind. Is the consensus still against this? Cheers, -- Nikodemus Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.784 diff -u -r1.784 slime.el --- slime.el 16 Apr 2007 14:42:33 -0000 1.784 +++ slime.el 27 Apr 2007 13:26:17 -0000 @@ -4570,10 +4570,15 @@ (set-keymap-parent map lisp-mode-map) map)) +(defvar slime-scratch-file nil) + (defun slime-scratch-buffer () "Return the scratch buffer, create it if necessary." (or (get-buffer "*slime-scratch*") - (with-current-buffer (get-buffer-create "*slime-scratch*") + (with-current-buffer (if (not slime-scratch-file) + (get-buffer-create "*slime-scratch*") + (find-file slime-scratch-file)) + (rename-buffer "*slime-scratch*") (lisp-mode) (use-local-map slime-scratch-mode-map) (slime-mode t)

4 5

[slime-devel] Operating on the swank readtable?
by Alberto Riva 17 Jan '08

17 Jan '08

Hello, I'm trying to define a few macro characters for use in the slime top-level, but I can't figure out where to put the SET-DISPATCH-MACRO-CHARACTER calls so that they affect the swank readtable instead of the default one. I've tried putting them both in my lisp initialization file and in .swank.lisp, but in both cases the macro character is defined in the initial readtable and not in the slime one (so it works in the *inferior-lisp* buffer, but not in the slime-repl buffer). Thanks! Alberto Riva University of Florida

2 2

[slime-devel] defining LISP functions in Emacs
by Joe Corneli 11 Jan '08

11 Jan '08

I want to create a variant of `defun' that takes arguments from Emacs and assembles a body to be evaluated by SLIME. It seemed to me that this macro definition w ould work: (defmacro ldefun (name arglist &rest body) `(defun ,name ,arglist (slime-eval (progn ,@body)))) For example, here is how it expands in a simple case: (macroexpand '(ldefun testslime (first second) (list first (+ 1 second)))) ;=> (defun testslime (first second) ;=> (slime-eval (progn (list first (+ 1 second))))) But that didn't turn out. In fact, even the `slime-eval' form just above does not work in a stand-alone fashion: (slime-eval (progn (list 2 (+ 1 6)))) Gives this error: Execution of a form compiled with errors. Form: (2 7) Whereas from the REPL, I get this behavior: CL-USER> (progn (list 2 (+ 1 6))) (2 7) So, I find this behavior surprising. Can anyone help me out? Note: I'm running Slime CVS from 2007-06-16 and SBCL 1.0.5.

3 3

[slime-devel] slime apparently mis-reporting closed connection
by Samium Gromoff 26 Oct '07

26 Oct '07

After well into the second decade of slime-disconnect/slime-connect loop iteration (interweaved with normal operation) the emacs side of slime stopped recognising connection status. I`m doing a slime-disconnect, restarting swank and slime-connect, however immediately after this either a slime-load-file or a (load ...) in slime repl result in a message "Connection closed." i have some time before i will have to reboot the machine, and until then i can provide various forensics upon request... regards, Samium Gromoff

5 5

[slime-devel] Inspector: inspect-bigger-piece and inspect-whole-thing broken.
by Madhu 23 Sep '07

23 Sep '07

Here are two test cases for exposing the bugs: ;; In ~/.swank.lisp: (setq SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* 10) ;; ;; CASE I ;; (defvar *ht* (make-hash-table :test #'eql)) (loop for i below 20 do (setf (gethash i *ht*) (princ i))) Then M-x slime-inspect *ht* (C-c I *ht*) : The inspector window show: |Contents: |10 elements shown. Prompt for how many to inspect... |Inspect all 20 elements. Choosing either of these two (bigger pieces action and entering the value in the REPL) or inspect whole pieces action, does not change the contents displayed in the inspector window, i.e. the number of items displayed does not change. ;; ;; CASE II ;; (defvar *array* (make-array 100 :initial-element nil)) Then M-x slime-inspect *array* (C-c I *array*) The variable SWANK::*SLIME-INSPECT-CONTENTS-LIMIT* is not respected and the whole contents of the array is printed. I'm guessing the following Changelog entry may apply, but haven't checked or fixed the problem against HEAD. |2007-04-19 Tobias C. Rittweiler <tcr(a)freebits.de> | | * swank-backend.lisp (label-value-line): Add :newline as &key | argument; if true (the default) inserts a newline. | | * swank.lisp (inspect-for-emacs-list): Don't add a newline after | the last value of the list. | -- Madhu

1 2

[slime-devel] Autodoc mode and the typeout frame
by Geoff Wozniak 01 Sep '07

01 Sep '07

When the typeout frame is active, autodoc output is sent to the frame using a call to SLIME-TYPEOUT-MESSAGE in SLIME-AUTODOC-MESSAGE. In turn, SLIME-TYPEOUT-MESSAGE applies FORMAT to the string to display it. This causes a fair number of errors when the string contains the % character and eventually autodoc-mode shuts off. I've attached a patch to fix it against the latest version. All it does is call REPLACE-REGEXP-IN-STRING before the string is sent to SLIME-TYPEOUT-MESSAGE. I'm not convinced this solution is at all elegant, but I'm not familiar with the architecture of Slime enough to know what a better solution might be. It's a hack since it's not terribly robust: right now no format arguments are passed to SLIME-TYPEOUT-MESSAGE but if they are, then the hack provided (likely) won't work. Anyway, this patch solves my immediate problem and I thought it was a point worth bringing up. And am I one of the only people to use a typeout frame? :) -- Geoff

4 5

[slime-devel] slime-reindent-defun broken?
by Andreas Fuchs 30 Aug '07

30 Aug '07

Hi there, I've recently updated my slime, and find that slime-reindent-defun in a lisp-mode file buffer is no longer working: it tries to call slime-repl-at-prompt-start-p, which tries to compare a number and the value of slime-repl-input-start-mark, which is nil. This patch fixes the symptoms, but it looks a bit wrong to me. Maybe somebody who knows more about the constraints involved can come up with a better fix. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.794 diff -u -r1.794 slime.el --- slime.el 28 Jun 2007 12:27:51 -0000 1.794 +++ slime.el 16 Jul 2007 12:43:02 -0000 @@ -10047,7 +10047,8 @@ (fill-paragraph nil) (let ((start (progn (unless (or (and (zerop (current-column)) (eq ?\( (char-after))) - (slime-repl-at-prompt-start-p)) + (and slime-repl-input-start-mark + (slime-repl-at-prompt-start-p))) (slime-beginning-of-defun)) (point))) (end (ignore-errors (slime-end-of-defun) (point)))) Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

3 2

[slime-devel] Patch to support CMUCL x86-darwin
by Jon Allen Boone 30 Aug '07

30 Aug '07

Folks, CMUCL now has an x86-Darwin port as well as the PPC-Darwin version. Here is a patch that conditionalizes on the presence of darwin instead of ppc so that slime works with both Darwin versions of CMUCL. diff -u -r1.170 swank-cmucl.lisp --- swank-cmucl.lisp 10 Jan 2007 23:53:47 -0000 1.170 +++ swank-cmucl.lisp 27 Jul 2007 22:17:24 -0000 @@ -76,7 +76,7 @@ (defimplementation preferred-communication-style () :sigio) -#-(or ppc mips) +#-(or darwin mips) (defimplementation create-socket (host port) (let* ((addr (resolve-hostname host)) (addr (if (not (find-symbol "SOCKET-ERROR" :ext)) @@ -85,7 +85,7 @@ (ext:create-inet-listener port :stream :reuse-address t :host addr))) ;; There seems to be a bug in create-inet-listener on Mac/OSX and Irix. -#+(or ppc mips) +#+(or darwin mips) (defimplementation create-socket (host port) (declare (ignore host)) (ext:create-inet-listener port :stream :reuse-address t))

2 1

[slime-devel] Evaluate forms from within Lisp buffers and displaying the result in the REPL
by Rainer Joswig 26 Aug '07

26 Aug '07

Hi, I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar. MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most. If the cursor is behind a Lisp form in a Lisp editor window, one can press Enter (or control-return) and the form will be enqueued into the REPL of the front most listener. Doing this in a listener, the form will be displayed at the prompt and enqueued in the listener's REPL. Pressing Enter only has the effect that the form and the result is shown in the listener. In the Editor window, nothing happens (no cursor moved, no character entered, no window focus changed). The listener REPL gets the forms from its queue and displays the form and the result at the end of the current buffer. This way you get interaction histories in the listener. Currently SLIME lets me evaluate a form in a text buffer and the form gets printed into the listener and the result gets printed in the mini-buffer. I can see then in the listener the history of evaluated forms, but not the history of results. Additionally the form will be printed with additional characters before and after. SLIME displays several forms evaluated from a text buffer in the REPL like this: ;;;; (+ 1 2) ... ;;;; (+ 1 2) ... ;;;; (+ 1 2) ... The normal REPL interaction display would be like: CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 Both ways look different. Why not use the latter for both interactions? Useful is then also a command to rotate between the various listeners (next, previous) and Lisp buffers (next, previous). Advantages I see for MCL: * With MCL you get the same REPL listener display if you evaluate forms from the Lisp editor buffer (via RETURN) or if you use the REPL in the listener. * Using the enter key (vs. Return) to evaluate code in the editor gets rid of one complex keystroke. * One gets reusable interaction histories in the listener where form and result are displayed together. Is SLIME already providing something similar? Would others find this way of interaction between Lisp buffers and a REPL buffer useful? Regards, Rainer Joswig -- http://lispm.dyndns.org

9 21

[slime-devel] slime-eval-last-expression scrolls buffer
by Austin Haas 29 Jul '07

29 Jul '07

When I run (c-x c-e), the whole buffer scrolls down so that point is positioned at the last line on the screen. Is this the expected behavior? Is there any way to prevent it? -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel July 2007