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

[slime-devel] slime-apropos-package now sorts correctly
by Hoehle, Joerg-Cyril 20 Apr '07

20 Apr '07

Hi, slime-apropos-package now conforms to its specification and also sorts symbols printed with package prefix. I supply the patches as attachments in the hope that MS-Windows nor MS-Outlook will break the TAB and LF characters of the original diff. I hope this is fine. Regards, Jörg Höhle.

3 3

[slime-devel] comma shortcut doesn't work always
by Edi Weitz 31 Jan '06

31 Jan '06

Another minor glitch that I encountered is that the comma shortcut in the REPL doesn't always work. I can consistently reproduce it (GNU Emacs 21.3.50 and also 21.3 release) like this: 1. Make sure point is at the beginning of a REPL input line. 2. Split Emacs frame into two windows, one of them being the REPL the other one containing something else. 3. Hide REPL window with C-x 0. 4. Now type M-x slime. 5. Type the comma. At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead. Anybody else seeing this? Cheers, Edi.

10 25

Re: [slime-devel] Re: CLISP SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 21 Jan '06

21 Jan '06

Luke Gorrie <luke(a)bluetail.com> writes: > Bill_Clementson(a)peoplesoft.com writes: > > > My previous SLIME installation was a CVS install from 4/18. I've just taken > > the latest CVS install and the CLISP SLIME implementation (under Windows) > > breaks. Here is the error: > > > > COERCE: #<MACRO #<COMPILED-CLOSURE SWANK::DEFSLIMEFUN>> cannot be coerced > > to type FUNCTION > > [Condition of type SIMPLE-TYPE-ERROR] > > I can reproduce this but I've no idea what is causing it. It /looks/ > like someone is trying to call defslimefun as a function rather than a > macro, but I don't see where it could happen -- the macro is declared > at the top of the only file that refers to it. > > I did fix a different but similar problem that I got under CLISP. It > seems like I had to swap the order of a couple of macros, one of which > expanded into into code that calls the other, but that surely can't be > the reason. > > > Backtrace: > > 0: EVAL frame for form (SWANK:CREATE-SWANK-SERVER 4007) > > Mine actually gives an empty backtrace (!). I fixed the Elisp-side to > handle that incase it helps someone more CLISP-savvy find the problem. Has anybody had any luck in finding the source of this problem? CLISP still breaks for me in the latest CVS. I have had a look at all of the DEFSLIMEFUN's that were modified since 4/18 (the previous CVS version that I had which was working ok with CLISP) and haven't found any obvious clues. Any suggestions on how I might debug this issue as it occurs at startup during the slime-connect processing in Emacs (after CLISP has started up successfully)? - Bill

5 6

[slime-devel] Installing slime for clisp 2.35 - Error
by Surendra Singhi 10 Jan '06

10 Jan '06

Hello, I recently upgraded to clisp 2.35 and now when I try to start slime on a lisp file, slime gets stuck. The *inferior-lisp* buffer shows me the following restart. ** - Continuable Error INTERN("*DOCUMENTATION*"): #<PACKAGE SYSTEM> is locked If you continue (by typing 'continue'): Ignore the lock and proceed The following restarts are also available: SKIP :R1 skip (COMPILE-FILES-IF-NEEDED-SERIALLY #) STOP :R2 stop loading file C:\Program Files\XEmacs\xemacs-packages\lisp\slime-1.2.1\swank-loader.lisp ABORT :R3 ABORT Doing 'continue', doesn't starts the slime repl, nor does selecting any of the restarts help. But, the inferior lisp buffer shows a lisp prompt, which can be used. What should I do to get over this problem? The slime related contents of my init file are: (load-library "inf-lisp") (setq inferior-lisp-program "C:\\clisp-2.35\\clisp.exe -I -m 256mb") (add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t))) (require 'timer) (require 'slime) (slime-setup) Thanks. -- Surendra Singhi http://www.public.asu.edu/~sksinghi/index.html "All animals are equal, but some animals are more equal than others." - Orwell, Animal Farm, 1945

5 8

[slime-devel] Problems with M-x slime-disconnect
by Alexis Rondeau 01 Dec '05

01 Dec '05

Hi there, I have been wanting to try out to connect to a running sbcl (0.9.5 on sarge) lisp In my console, I startup slime (which I got from cvs today) and create the server: * (swank:create-server) ;; Swank started at port: 4005. 4005 This works fine. In my emacs I hit M-x slime-connect and after providing host and port, I am actually using the above started lisp. So far so good, but now the actual problem arises. Once I hit M-x slime-disconnect in Emacs I get the following error in my sbcl and cannot reconnect to the lisp: * ;; Connection to Emacs lost. ;; [end of file on #<SB-SYS:FD-STREAM for "a constant string" {AC56161}>] debugger invoked on a SIMPLE-ERROR in thread #<THREAD "auto-flush-thread" {AD822F1}>: #<SB-SYS:FD-STREAM for "a constant string" {AC5D1C1}> is closed. I have been searching all over the internet for a solution because this way I can not really work because I can only once connect to the lisp and not again. Can anyone give me a pointer on what I am doing wrong? I am totally stunned because I seem to be the only one that has this problem :( In any case, thank you for your help! Slime is working amazingly otherwise just this feature is really important to me. Alexis

2 1

[slime-devel] exited abnormally with code 256
by John J Foerch 30 Nov '05

30 Nov '05

Hi, Slime used to work for me, a couple months ago. Then I didn't touch it for a couple months and now when I «M-x slime» things load and compile for a bit, then I get the message: Lisp connection closed unexpectedly: exited abnormally with code 256 I tried updating my copy of Slime to the current CVS version. I tried deleting the .fasl files in ~/.slime/fasl. I am a total newb so I don't know what else I can try. Any suggestions? My emacs is Gnu Emacs 21.3. My lisp is SBCL 0.9.4. -John J Foerch

2 4

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

27 Nov '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.812 slime/ChangeLog:1.814 --- slime/ChangeLog:1.812 Mon Nov 21 00:30:45 2005 +++ slime/ChangeLog Tue Nov 22 21:44:14 2005 @@ -1,3 +1,21 @@ +2005-11-22 Marco Monteiro <masmxx(a)gmail.com> + + * slime.el (slime-connect): Use slime-net-coding system if the + optional arg coding-system was not supplied. + +2005-11-22 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-compile-file): Call 'check-parens before + compiling. + (slime-compile-file): Call 'check-parens before compiling. + (slime-find-coding-system): Return nil if the coding system + isn'tvalid instead of singalling an error. + (slime-repl-history-file-coding-system): Use + slime-find-coding-system to find the default. + + * swank-cmucl.lisp (accept-connection): Remove fd-handlers if the + encoding isn't iso-latin-1. + 2005-11-21 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-start): Don't set slime-net-coding-system ..

2 1

[slime-devel] .slime
by Michael 23 Nov '05

23 Nov '05

Unfortunately there is no directory ~/.slime and there are no files *.fasl other than those accompanying the common lisp install. So I am unable to use this fix.

5 10

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

[slime-devel] BUG in macroexpand
by Marco Monteiro 15 Nov '05

15 Nov '05

There is a bug in macroexpand functionality: it fails to macroexpand (using C-c <ret>, for example) a form when the point is at the end of the last line of the buffer. Add a newline, or even a space, and it works. To reproduce: In a lisp source buffer, go to the last line in the buffer, type '(+ 1 1)' and now, without adding anything and with the point after the close parentheses, macroexpand it. If there is a line after the line with (+ 1 1) form, it works. Marco

1 0

[slime-devel] New error loading slime
by Jeff Cunningham 15 Nov '05

15 Nov '05

I've been using my current combination of slime/cmucl for weeks without any trace of trouble, but when I tried to invoke a new session this evening, it gave me this error message: Any idea what would cause this? Thanks. -Jeff (load "/home/jcunningham/installed/slime/swank-loader.lisp" :verbose t) (swank:start-server "/tmp/slime.9676" :external-format :iso-latin-1-unix) Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x100168E8. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCAFC)) Source: Error finding source: Error in function LISP::%ENUMERATE-SEARCH-LIST: Undefined search list: default 0]

1 0

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

13 Nov '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.808 slime/ChangeLog:1.811 --- slime/ChangeLog:1.808 Sat Nov 12 00:47:03 2005 +++ slime/ChangeLog Sun Nov 13 23:31:43 2005 @@ -1,3 +1,15 @@ +2005-11-14 Douglas Crosher <dcrosher(a)common-lisp.net> + + * swank-scl.lisp (accept-connection): handle the :buffering argument. + +2005-11-13 Andras Simon <andras(a)renyi.hu> + + * swank-abcl.lisp: (accept-connection): New argument: buffering. + +2005-11-13 Andras Simon <andras(a)renyi.hu> + + * swank-abcl.lisp: Steal auto-flush stuff from swank-sbcl.lisp + 2005-11-11 Helmut Eller <heller(a)common-lisp.net> * swank.lisp (*dedicated-output-stream-buffering*): New variable

1 0

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

12 Nov '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.807 slime/ChangeLog:1.808 --- slime/ChangeLog:1.807 Mon Nov 7 09:30:00 2005 +++ slime/ChangeLog Sat Nov 12 00:47:03 2005 @@ -1,3 +1,25 @@ +2005-11-11 Helmut Eller <heller(a)common-lisp.net> + + * swank.lisp (*dedicated-output-stream-buffering*): New variable + to customize the buffering scheme. For single-threaded Lisps we + disable buffering because lazy programmers forget to call + finish-output. + (open-dedicated-output-stream): Use it. + + * swank-backend.lisp, swank-allegro.lisp, swank-lispworks.lisp, + swank-openmcl.lisp, swank-cmucl.lisp, swank-sbcl.lisp, + swank-clisp.lisp, swank-abcl.lisp, swank-corman.lisp, + swank-ecl.lisp (accept-connection): New argument: buffering. + + * slime.el (slime-repl-save-history): When the history exceeds + slime-repl-history-size remove the old not the new entries. + Some renaming: + slime-repl-read-history -> slime-repl-load-history, + slime-repl-read-history-internal -> slime-repl-read-history. + (slime-eval-macroexpand): Call font-lock-fontify-buffer + explicitly, because with certain Emacs versions the buffer doesn't + get fontified immediately. + 2005-11-07 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-eval-macroexpand): Use lisp-mode (and

1 0

[slime-devel] macro expansions
by Jan Rychter 12 Nov '05

12 Nov '05

Is there any fundamental reason why macro expansions (C-c C-m) do not get fontified? --J.

3 4

[slime-devel] SLIME definition location regexps
by Taylor Campbell 11 Nov '05

11 Nov '05

Some time in late August, `slime-goto-location-position' was modified to add a new regexp for searching for definitions, one that would work with Scheme definition forms and also anything else with parentheses before the name being defined. This regexp was commented out a couple weeks ago, which makes locating such definitions impossible; is there a reason that this regexp was commented out, or could it be put back into `slime-goto-location-position'?

2 1

Re: [slime-devel] patchlets on buffering.
by Fred Gilham 11 Nov '05

11 Nov '05

> By default, the connection between the lisp and the slime repl is > buffered. I would like to propose to have it unbuffered. on the > grounds that if the user has a (format t ...), he/she probably wants > the message to appear immediately on the screen :-) Isn't the proper way to make the message appear immediately to use a (force-output) or a (format t "....~%")? -- Fred Gilham gilham(a)csl.sri.com The amazing thing is, back when I was a C++ programmer, I thought that [Design Patterns] was SUCH a great book. And I guess it was, in a way: it made it possible to use C++ and get something done. In the long run, of course, that may have been a disservice... - Alain Picard

3 2