- slime-devel - mailman3.common-lisp.net

Re: [slime-devel] .slime
by Jeff Cunningham 23 Nov '05

23 Nov '05

On Wed Nov 23, 2005 at 08:38:07AM +0200, Nikodemus Siivola wrote: > On Tue, 22 Nov 2005, Jeff Cunningham wrote: > > >I'm running Gentoo and creating ~/.slime is definitely about the first > >thing it does. No problems there. > > Are you running vanilla Slime, or one from Gentoo? > > Cheers, > > -- Nikodemus Schemer: "Buddha is small, clean, and serious." > Lispnik: "Buddha is big, has hairy armpits, and laughs." > Currently, I'm running SLIME 2005-10-31. I update it about once a month when the list seems 'quiet. ;) --Jeff

1 0

[slime-devel] Bug in slime-connect.
by Marco Monteiro 22 Nov '05

22 Nov '05

When I execute slime-connect, I get an error about an invalid coding system. The slime-connect function in slime.el calls slime-check-coding-system with nil as argument. The following hack solves the problem: diff -u -r1.565 slime.el --- slime.el 22 Nov 2005 10:36:22 -0000 1.565 +++ slime.el 22 Nov 2005 18:21:50 -0000 @@ -1317,7 +1317,7 @@ (when (and (interactive-p) slime-net-processes (y-or-n-p "Close old connections first? ")) (slime-disconnect)) - (slime-check-coding-system coding-system) + (slime-check-coding-system (or coding-system slime-net-coding-system)) (message "Connecting to Swank on port %S.." port) (let* ((process (slime-net-connect host port coding-system)) (slime-dispatching-connection process)) cvs server: Diffing doc Marco

2 1

[slime-devel] Different lisps, different coding systems
by Harald Hanche-Olsen 22 Nov '05

22 Nov '05

I have this in my .emacs: (setf slime-lisp-implementations '((sbcl ("sbcl") :coding-system utf-8-unix) (cmucl ("cmucl") :coding-system iso-latin-1-unix))) (setf slime-default-lisp 'sbcl) This works mostly, but not if I first run a slime with sbcl and then run another with cmucl in the same emacs. (It doesn't matter if I quit the slime one or not.) Before I tell you what happens, let me lay the blame at the feet of the global variable slime-net-coding-system. It is set iso-latin-1-unix after I start a cmucl slime. It becomes utf-8-unix after I run an sbcl slime, and is not reset to iso-latin-1-unix when I run a cmucl slime. But if I reset it manually, the problem does not occur. So what IS the problem, then? What I see in the *inferior-lisp* buffer is as follows: ;; Swank started at port: 54163. nil ;;; COMMON-LISP-USER: Error in function lisp::assert-error: The assertion (eq swank-backend::ef ':iso-latin-1-unix) failed. [Condition of type simple-error] Restarts: 0: [continue] Retry assertion. 1: [abort ] Return to Top-Level. Debug (type H for help) (lisp::assert-error (eq swank-backend::ef ':iso-latin-1-unix) nil nil) Source: Error finding source: File-error in function lisp::fd-open: Error opening #P"target:code/macros.lisp", Permission denied. 0] Error in function lisp::assert-error: The assertion (eq swank-backend::ef ':iso-latin-1-unix) failed. Error flushed ... 0] Error in function lisp::assert-error: The assertion (eq swank-backend::ef ':iso-latin-1-unix) failed. Error flushed ... and this repeats forever until I kill the Lisp. - Harald

2 4

[slime-devel] CVS version fails in xemacs21-nomule
by Liam M. Healy 22 Nov '05

22 Nov '05

The new CVS slime.el has a function (defcustom slime-repl-history-file-coding-system (cond ((featurep 'xemacs) (cond ((find-coding-system 'utf-8-unix) 'utf-8-unix) (t (coding-system-name default-buffer-file-coding-system)))) ((coding-system-p 'utf-8-unix) 'utf-8-unix) (t 'emacs-mule-unix)) "*The coding system for the history file." :type 'symbol :group 'slime-repl) but find-coding-system and coding-system-name are nonexistent in xemacs21-nomule and thus slime fails to load. There are conditionalizations elsewhere in the file on coding system functions, but not here. Liam

2 1

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 21 Nov '05

21 Nov '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.811 slime/ChangeLog:1.812 --- slime/ChangeLog:1.811 Sun Nov 13 23:31:43 2005 +++ slime/ChangeLog Mon Nov 21 00:30:45 2005 @@ -1,3 +1,27 @@ +2005-11-21 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-start): Don't set slime-net-coding-system .. + (slime-read-port-and-connect): .. read it from the inferior lisp args. + (slime-connect): Take the coding-system as third argument. + (slime-repl-history-file-coding-system): New user option. + (slime-repl-safe-save-merged-history): New function. Use it in + hooks so that bad coding systems don't stop us from exiting. + (slime-repl-save-history): Include the coding-system which was + used to save the buffer. + (repl-shoctut change-package): Add alias ,in and ,in-package. + (slime-eval-macroexpand): Error out early if there's no sexp at + point. + (slime-compiler-macroexpand): New command. + (slime-inspector-pprint): New command. + + * swank-cmucl.lisp (inspect-for-emacs): Add support for + funcallable instances. + + * swank.lisp (pprint-inspector-part, swank-compiler-macroexpand): New. + + * swank-backend.lisp (compiler-macroexpand) + (compiler-macroexpand-1): New functions. + 2005-11-14 Douglas Crosher <dcrosher(a)common-lisp.net> * swank-scl.lisp (accept-connection): handle the :buffering argument.

1 0

[slime-devel] Coding systems and .slime-history.eld
by Harald Hanche-Olsen 21 Nov '05

21 Nov '05

Of course I had to start playing with utf-8-unix as the coding system for communications between emacs/slime and the sbcl backend, and of course I had to test it by trying some commands with non-latin-1 characters in them. Everything went fine until I quit slime, when it wanted to save the history to .slime-history.eld with the latin-1 charset (I have not yet converted to utf-8 for everything I do). This failed of course, which makes me wonder whether slime-repl-save-history ought to have anticipated this problem, and specified the coding system, perhaps to be the same as communicating with the lisp? Of course, slime-repl-read-history-internal runs into the same snag. I could fix this for my own part by adding ("\\.eld$" . utf-8) to file-coding-system-alist or some other trick like that, or even moving to utf-8 as the default coding for all operations, by setting coding-system-for-write and coding-system-for-read both to utf-8. But slime users should not be forced to such measures just because they use utf-8 to talk to their lisp. - Harald

2 2

[slime-devel] Slime fails to load
by Michael 21 Nov '05

21 Nov '05

Slime suddenly stopped working, cause unknown. Using either the Gentoo version or using the latest CVS downloaded today, when attempting to start Slime in emacs I end up with the following output. The REPL prompt never appears. Please advise how I may restore a functioning slime. Thank you. ; registering #<SYSTEM SB-BSD-SOCKETS {1000B7FBC1}> as SB-BSD-SOCKETS STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS (T) in DEFMETHOD STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS (T) in DEFMETHOD STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST NIL in DEFMETHOD STYLE-WARNING: redefining ARGLIST (T) in DEFMETHOD STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY (T) in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK (T T) in DEFMETHOD STYLE-WARNING: redefining FORMAT-SLDB-CONDITION (T) in DEFMETHOD STYLE-WARNING: redefining CONDITION-REFERENCES (T) in DEFMETHOD STYLE-WARNING: redefining UNPROFILE-ALL NIL in DEFMETHOD STYLE-WARNING: redefining BUFFER-FIRST-CHANGE (T) in DEFMETHOD STYLE-WARNING: implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P STYLE-WARNING: implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS STYLE-WARNING: implicitly creating new generic function INSPECT-WHOLE-THING-ACTION STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION STYLE-WARNING: implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION T * ;; Swank started at port: 32769. ; Adding fd handler: 5 NIL * ; Adding fd handler: 6

2 1

[slime-devel] slime-space not working, both in slime repl and inferor lisp
by Samium Gromoff 21 Nov '05

21 Nov '05

SLIME is CVS from Nov 19 2005 Lisp is ubuntu CLISP 2.35-2 running on x86 emacs is emacs21 21.4a-1ubuntu1 first of all: the symbol i test it on is 'defpackage' i have (slime-setup :autodoc t) in my .emacs C-h k says that SPC is bound to slime-space (slime-busy-p) => nil slime-reset doesn`t help running slime-insert-arglist on the symbol produces: "Arglist not available adding (add-hook 'inferior-lisp-mode-hook (defun my-inferior-lisp-mode-hook () (add-to-list (make-local-variable 'comint-output-filter-functions) (lambda (string) (unless (get-buffer-window (current-buffer) t) (display-buffer (current-buffer) t)) (comint-postoutput-scroll-to-bottom string))))) into my .emacs, to popup the *inferior-lisp* buffer, doesn`t pop up anything when i press SPC

2 1

[slime-devel] Test.
by Marco Monteiro 18 Nov '05

18 Nov '05

Is this getting throw? Marco

2 1

[slime-devel] Error on startup: Servname not supported
by Peter Gijsels 16 Nov '05

16 Nov '05

> ..., when I went to start slime, I ran > into some problems. > Specifically, the command buffer in emacs states: > itimer "run-with-timer" signaled: (error "127.0.0.1/(^W1^H& Servname > not supported for ai_socktype") > I'm running XEmacs 21.4.17, and my clisp --version reports Software: > GNU C 4.0.2. I'm running on the "breezy" version of Kubuntu Linux > (Ubuntu). I'm seeing the same problem with the same XEmacs, also on Kubuntu (5.10). It seems that open-network-stream won't work with a number as a port argument. As a work-around you can add the following function to your slime.el and replace the 2 calls to open-network-stream with my-open-network-stream: (defun my-open-network-stream (name buffer host port) (open-network-stream name buffer host (if (numberp port) (number-to-string port) port) 'tcp)) When you google around a bit it seems that there was indeed a problem with open-network-stream in that XEmacs version. Regards, Peter

1 0