slime-devel June 2006

slime-devel@common-lisp.net

33 participants
36 discussions

[slime-devel] Slime fails to report a compiler note
by Frédéric Jolliton 25 Jun '06

25 Jun '06

Hi, I'm new on this list. I don't know if the following problem was already reported. With Linux 2.6 (x86-32), SBCL 0.9.13 and Slime CVS (from today), I get the error below. Is there a compatibility problem between SBCL and Slime in this case ? (SBCL release vs Slime CVS) error while parsing arguments to DESTRUCTURING-BIND: invalid number of elements in ((1545 . 2005) (1988 . 2003) (1660 . 1950)) to satisfy lambda list ((SWANK-BACKEND::START . SWANK-BACKEND::END)): exactly 1 expected, but 3 found [Condition of type SB-KERNEL::ARG-COUNT-ERROR] Restarts: 0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {B1A5C69}> on #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "common" {C51DBF1}>. 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {B1A5C69}> on #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "common" {C51DBF1}> as having been successful. 2: [ABORT] Abort SLIME compilation. 3: [ABORT-REQUEST] Abort handling SLIME request. 4: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION (0 1 3 4) NIL #<HASH-TABLE :TEST EQ :COUNT 31 {BCB2321}>) 1: (SWANK-BACKEND::SOURCE-PATH-FILE-POSITION (7 1 3 4) #P"/usr/share/common-lisp/source/ironclad/common.lisp") 2: (SWANK-BACKEND::LOCATE-COMPILER-NOTE #P"/usr/share/common-lisp/source/ironclad/common.lisp" (7 1 3 4) " (LDB (BYTE 8 0) IRONCLAD::UB)") 3: (SWANK-BACKEND::COMPILER-NOTE-LOCATION #<SB-C::COMPILER-ERROR-CONTEXT >) 4: (SWANK-BACKEND::SIGNAL-COMPILER-CONDITION #<SB-INT:SIMPLE-COMPILER-NOTE {BCA1AB9}> #<SB-C::COMPILER-ERROR-CONTEXT >) 5: (SWANK-BACKEND::HANDLE-NOTIFICATION-CONDITION #<SB-INT:SIMPLE-COMPILER-NOTE {BCA1AB9}>) 6: (SIGNAL #<SB-INT:SIMPLE-COMPILER-NOTE {BCA1AB9}>) [..] -- Frédéric Jolliton

2 1

[slime-devel] connecting multiple users to one lisp process
by Joe Corneli 24 Jun '06

24 Jun '06

I am interested in connecting several uniquely-identified users to one lisp process. For example, the lisp process could be running a MUD and the users will be interacting with each other there. Someone mentioned to me that SLIME could be used to facilitate the "connection" aspect of this problem (perhaps still leaving some work in the unique identification of users). Any initial feedback or advice on how to approach this? Is SLIME the right tool for the job? If not, do you have any other suggestions? If yes, please advise on how to get started, and we'll talk more after that.

2 2

[slime-devel] BREAK in Lisp-mode buffers with OpenMCL
by graham＠gorgeous.org 24 Jun '06

24 Jun '06

Hi, When I call BREAK in a Lisp-mode buffer using OpenMCL, I don't get the Slime debugger. Instead I get OpenMCL's own debugger, which looks like this: ;;;; (break) ... > Break in process worker(7): > While executing: "Unknown" > Type :GO to continue, :POP to abort. > If continued: Return from BREAK. Type :? for other options. 1 > If I do the same thing from the REPL, I get the Slime debugger. I think I should get the Slime debugger in Lisp-mode as well. Obviously calling BREAK directly is not very useful, but when I insert breakpoints in functions by means of calls to BREAK I get the same behaviour. The behaviour depends on where the function is called, not on where it was compiled. I'm using OpenMCL Version 1.0 (DarwinPPC32) and recent CVS Slime and GNU Emacs. Emacs was started with emacs -q so I don't think there's anything funny in my setup. Graham

2 1

[slime-devel] upgraded clisp on cygwin, now slime won't load
by funkyj＠gmail.com 21 Jun '06

21 Jun '06

I had slime + clisp (on cygwin) working fine. Yesterday I decided to upgrade various cygwin packages (including clisp). Now when I try to start slime I get this error: ;; Loading file /home/jcano/.clisprc.lisp ... ;; Loaded file /home/jcano/.clisprc.lisp [1]> *** - LOAD: A file with name /c/cygwin/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp does not exist The following restarts are available: ABORT :R1 ABORT I tried picking up the latest SLIME (my previous slime was 2006-jan-20) but neither "fairly stable" nor "head" made any difference. I also blew away my ~/.slime directory in case that was stale (slime is no longer getting far enough to rebuild ~/.slime) but that didn't help. Yes, I looked in "~/elisp/slime/2006-06-21/slime" and it does indeed contain the file that Here is my current version of clisp; GNU CLISP 2.38 (2006-01-24) (built on winsteingoldlap.bluelnk.net [10.41.52.143]) Software: GNU C 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -I. -x none -lintl libcharset.a libavcall.a libcallback.a -lreadline -lncurses -liconv -L/usr/local/libsigsegv-cygwin/lib -lsigsegv -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED libsigsegv 2.2 libiconv 1.9 libreadline 5.0 Features: (READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX CYGWIN) C Modules: (clisp i18n syscalls regexp readline) Installation directory: /usr/lib/clisp/ User language: ENGLISH Machine: I686 (I686) jcano-lt [192.168.1.103] I run slime like this M-x slime and this is in my .emacs: (defun slime () "load my .emacs_slime and run M-x slime" (interactive) (load-file "~/.emacs_slime") (slime)) .emacs_slime file: ;; -*- mode: emacs-lisp -*- (message "begin .emacs_slime") (setq inferior-lisp-program "clisp") (add-to-list 'load-path ;; CVS head (concat (getenv "HOME") "/elisp/slime/2006-06-21/slime") t) (require 'slime) (slime-setup) ;;; Configuration of Erik Naggum's HyperSpec access package. ;; If you have a local copy of the HyperSpec, set its path here. (setq common-lisp-hyperspec-root "file:///c:/cygwin/home/jcano/docs/CL/HyperSpec/") (setq common-lisp-hyperspec-symbol-table (concat (getenv "HOME") "/docs/CL/HyperSpec/ilisp/map_sym.txt" )) (message "end .emacs_slime") If I run clisp and execute the following command manually: [1]> (load "/c/cygwin/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp") *** - LOAD: A file with name /c/cygwin/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp does not exist The following restarts are available: ABORT :R1 ABORT Break 1 [2]> (load "/c:cygwin/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp") *** - PARSE-NAMESTRING: syntax error in filename "/c:cygwin/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp" at position 2 The following restarts are available: ABORT :R1 ABORT ABORT :R2 ABORT Break 2 [3]> abort Break 1 [2]> abort [4]> (load "/home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp") ;; Loading file /home/jcano/elisp/slime/2006-06-21/slime/swank-loader.lisp ... ;; Compiling file /home/jcano/elisp/slime/2006-06-21/slime/swank-backend.lisp ... ;; Wrote file ;; /home/jcano/.slime/fasl/2006-06-18/clisp-2.38-unix-pc386/swank-backend.fas [... successful loading ...] I see in slime.el (eval-and-compile (defvar slime-path (let ((path (or (locate-library "slime") load-file-name))) (and path (file-name-directory path))) "Directory containing the Slime package. This is used to load the supporting Common Lisp library, Swank. The default value is automatically computed from the location of the Emacs Lisp package.")) ; ... (defun slime-init-command (port-filename coding-system) "Return a string to initialize Lisp." (let ((loader (if (file-name-absolute-p slime-backend) slime-backend (concat slime-path slime-backend))) (encoding (slime-coding-system-cl-name coding-system))) (format "%S\n%S\n\n" `(load ,loader :verbose t) `(swank:start-server ,port-filename :external-format ,encoding)))) OK, so CLisp wants file paths to be in cygwin/unix format (e.g. "/home/jcaon" and "/cygdrive/c/cygwin" etc.) but emacs (which is a win32 application) is providing a windows style "c:/cygwin/home/..." path which, somewhere along the way gets converted to "/c/cygwin/home/..." I can probably fix this by overriding slime-path (I'll try that after posting this). Does anyone know why upgrading (I think I had 2.35) to 2.38 would cause this failure? Can this be fixed so other noobs don't suffer the same problems I have? Regards, --jfc

1 1

Re: [slime-devel] Re: Unable to get SLIME working with sbcl-0.9.13
by rif 20 Jun '06

20 Jun '06

> > Ah, maybe I spoke too soon. Apparently, I need to set > > swank:*communication-style* to something other than :spawn. Is it known > > that :spawn doesn't work with sbcl? I somehow thought I'd been using > > :spawn with sbcl on my other (home) machine, but maybe I was confused. > > :spwan should work fine, but you need to build you SBCL with threads > enabled -- they are not built by default. Sorry, I'm confused. Looking at the SBCL build, the only thread relevant feature I found was :sb-thread, which does seem to me enabled by default in the x86 0.9.13 release (it's in *features*). In any case, I built a version from source where I explicitly enabled this feature. I'm not sure how to tell if I did it right, I put a customize-target-features.lisp file in the toplevel sbcl directory, right next to the base-target-features.lisp-expr file, and rebuilt. Using this version did not let SLIME work with :spawn. SLIME seems to start, and then immediately says "Process inferior-lisp hangup," and dies. rif

1 0

[slime-devel] swank reloading problem
by Cyrus Harmon 19 Jun '06

19 Jun '06

I'm trying to debug getting threads running on SBCL/x86/MacOS and in doing so I've come across a strange problem where something (presumably clim-desktop.asd) is requiring swank, which is causing swank.asd to get reloaded and swank-backend is getting recompiled, which causes current-thread to get redefined to 0. This seems to wreak havoc with some of the locking stuff, which presumably has various locks held while it's trying to output the results of the compilation. Should the definterface stuff in swank-backend have some sort of check to see if these haven't been previously implemented before overwriting the previous method definitions? Thanks, Cyrus

4 4

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 19 Jun '06

19 Jun '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.910 slime/ChangeLog:1.913 --- slime/ChangeLog:1.910 Sat Jun 17 12:11:04 2006 +++ slime/ChangeLog Sun Jun 18 14:22:30 2006 @@ -1,3 +1,20 @@ +2006-06-18 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * slime.el (slime-echo-arglist): Simplify, just use slime-autodoc. + + * swank.lisp (arglist): Distinguish between provided actual args + and required formal args using the new slot provided-args. + (form-completion): Likewise. + (decoded-arglist-to-string): Use it here to display the argument + list (make-instance 'CLASS-NAME ...) rather + than (make-instance (quote CLASS-NAME) ...). + + * swank.lisp (extra-keywords change-class): Don't drop the first + argument. + + * slime.el (slime-parse-extended-operator-name): Don't move + point; fixes infinite loop. + 2006-06-17 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-parse-extended-operator-name/cerror): Handle

1 0

[slime-devel] asdf-install kills slime
by Harald Hanche-Olsen 18 Jun '06

18 Jun '06

I was just going to try asdf-install for the very first time, and it turns out to kill slime. Or more precisely, my lisp and emacs both die (sbcl 0.9.13.21, GNU Emacs 23.0.0.1, slime from CVS as of 2006-06-04). So to get some more information, I tried again from the *inferioir-lisp* buffer (see beneath my signature, below). I figure the problem is with the debugger trying to print a string containing binary data, and somehow not using the UTF-8 encoding to do it. I have this charset specification in .emacs: (setf slime-lisp-implementations '((sbcl ("sbcl") :coding-system utf-8-unix) (cmucl ("cmucl") :coding-system iso-latin-1-unix))) - Harald PS. This is the wrong place to ask I know, but can anyone throw any light on the GPG message about "key id 0xNIL ()"? ---------------- This is SBCL 0.9.13.21, an implementation of ANSI Common Lisp. ;;; startup chatter elided * (require :asdf-install) ;;; somewhat verbose output elided * (asdf-install:install :cells) Install where? 1) System-wide install: System in /local/lib/sbcl/site-systems/ Files in /local/lib/sbcl/site/ 2) Personal installation: System in /Users/hanche/.sbcl/systems/ Files in /Users/hanche/.sbcl/site/ --> 1 Downloading 74072 bytes from http://common-lisp.net/project/cells/asdf-install/cells_2.0.tar.gz ... debugger invoked on a ASDF-INSTALL::KEY-NOT-TRUSTED: GPG warns that the key id 0xNIL () is not fully trusted Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Install the package anyway 1: [SKIP-GPG-CHECK] Don't check GPG signature for this package 2: [ABORT ] Exit debugger, returning to top level. (ASDF-INSTALL::VERIFY-GPG-SIGNATURE/STRING "-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (a whole bunch of binary data left out, all part of this humongous string) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFD1qcfl2RwVlDQtPYRApX/AKCFgsrLXsv8FllEQ1YQtC2nYRZiHACcDkJY whE3bSaRgquYThmepNzfYVc= =Pacw -----END PGP SIGNATURE----- " #P"/Users/hanche/CELLS.asdf-install-tmp")

1 1

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 18 Jun '06

18 Jun '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.908 slime/ChangeLog:1.910 --- slime/ChangeLog:1.908 Fri Jun 16 12:35:46 2006 +++ slime/ChangeLog Sat Jun 17 12:11:04 2006 @@ -1,3 +1,15 @@ +2006-06-17 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * slime.el (slime-parse-extended-operator-name/cerror): Handle + cerror and change-class with :make-instance. + (slime-extended-operator-name-parser-alist): Handle change-class. + (slime-parse-extended-operator-name) + (slime-enclosing-operator-names): Fix the case when point is + within the operator. + + * swank.lisp (operator-designator-to-form): Handle cerror and + change-class with :make-instance. + 2006-06-16 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * swank.lisp (operator-designator-to-form): Handle :cerror.

1 0

[slime-devel] Daily ChangeLog diff
by mbaringer＠common-lisp.net 17 Jun '06

17 Jun '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.907 slime/ChangeLog:1.908 --- slime/ChangeLog:1.907 Wed Jun 14 10:58:37 2006 +++ slime/ChangeLog Fri Jun 16 12:35:46 2006 @@ -1,3 +1,16 @@ +2006-06-16 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> + + * swank.lisp (operator-designator-to-form): Handle :cerror. + (extra-keywords cerror): Make it work. + + * slime.el (slime-parse-extended-operator-name) + (slime-parse-extended-operator-name/make-instance) + (slime-parse-extended-operator-name/defmethod): New functions, + factored out from slime-enclosing-operator-names. + (slime-parse-extended-operator-name/cerror): New function. + (slime-extended-operator-name-parser-alist): New variable. + (slime-enclosing-operator-names): Use them here. + 2006-06-14 Matthias Koeppe <mkoeppe(a)mail.math.uni-magdeburg.de> * slime.el (slime-goto-definition): If all definitions of a name

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel June 2006