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

[slime-devel] Hang with cmucl 20c
by Harald Hanche-Olsen 04 Oct '12

04 Oct '12

I am running cmucl 20c (unicode version) under slime, with coding-system set to utf-8-unix and quicklisp loaded. All seems to work well, including loading various quicklisp packages, until I try this: CL-USER> (ql:quickload "ironclad") To load "ironclad": Load 1 ASDF system: ironclad ; Loading "ironclad" ... and the slime-repl buffer hangs with the cursor at the last line above. In the *inferior-lisp* buffer I find this: ;; swank:close-connection: No matching method for the generic function #<STANDARD-GENERIC-FUNCTION STREAM-ELEMENT-TYPE (1) {59232FA9}>, when called with arguments (#<Stream for descriptor 5>). Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. There is nothing untoward in the *slime-events* buffer. Any idea what could be the problem? I'll be happy to provide backtraces, etc. if you can only tell me how to get them. I supposed there is something odd about the stream for descriptor 5. Perhaps someone who knows the internals well can tell me what stream that is, and how it is different from other streams? (Oh, loading ironclad in the *inferior-lisp* buffer works like a charm, after I tweaked the source code a little so it could find libcrypt. All this is on ubuntu, BTW, linux kernel 3.2.0-31-generic.) - Harald

2 3

[slime-devel] stuck polling on windows
by mike 03 Oct '12

03 Oct '12

Hi I'm trying to get slime and slime-mode working with acl82express (Allegro CL 8.2). Here is the relevant part of my .emacs: ; This is sample code for starting and specifying defaults to the ; Emacs-Lisp interface. (push "c:/acl82express/eli" load-path) (load "fi-site-init.el") (setq fi:common-lisp-image-name "c:/acl82express/alisp") (setq fi:common-lisp-image-file "c:/acl82express/alisp.dxl") (setq fi:common-lisp-directory "c:/acl82express/") (add-to-list 'load-path "c:/Users/Mike/Downloads/slime-current/slime-current/slime-2012-09-27/") ; your SLIME directory (setq inferior-lisp-program "c:/acl82express/allegro-express.exe") ; your Lisp system (require 'slime) (slime-setup) When I do 'M-x slime' this is at the top of *inferior-lisp*: (progn (load "c:/Users/Mike/Downloads/slime-current/slime-current/slime-2012-09-27/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "c:/Users/Mike/AppData/Local/Temp/slime.8336")) and this from *Messages*: Loading paren...done Loading c:/acl82express/eli/fi-site-init.el (source)... Loading c:/acl82express/eli/fi-vers.elc...done Loading c:/acl82express/eli/fi-utils.elc...done Loading c:/acl82express/eli/fi-keys.elc...done Loading c:/acl82express/eli/fi-modes.elc...done Loading c:/acl82express/eli/fi-indent.elc...done Loading c:/acl82express/eli/fi-gnu.elc...done Loading c:/acl82express/eli/fi-subproc.elc...done Loading c:/acl82express/eli/fi-sublisp.elc...done Loading c:/acl82express/eli/fi-basic-lep.elc...done Loading c:/acl82express/eli/fi-lep.elc...done Loading c:/acl82express/eli/fi-dmode.elc...done Loading c:/acl82express/eli/fi-composer.elc...done Loading c:/acl82express/eli/fi-lze.elc...done Loading c:/acl82express/eli/fi-changes.elc...done Loading c:/acl82express/eli/fi-db.elc...done Loading c:/acl82express/eli/fi-stream.elc...done Loading c:/acl82express/eli/fi-ring.elc...done Loading c:/acl82express/eli/fi-filec.elc...done Loading c:/acl82express/eli/fi-shell.elc...done Loading c:/acl82express/eli/fi-rlogin.elc...done Loading c:/acl82express/eli/fi-telnet.elc...done Loading c:/acl82express/eli/fi-su.elc...done Loading c:/acl82express/eli/fi-manual.elc... Loading c:/acl82express/eli/fi-manual-data.elc...done Loading c:/acl82express/eli/fi-manual.elc...done Loading c:/acl82express/eli/fi-emacs21.elc...done Loading c:/acl82express/eli/fi-site-init.el (source)...done package specification is `USER' Loading dired...done Loading vc-cvs...done Loading prolog...done Wrote c:/Users/Mike/.emacs.desktop.lock Desktop: 14 buffers restored. For information about GNU Emacs and the GNU system, type C-h C-a. call-interactively: Beginning of buffer Slime mode enabled Quit Polling "c:/Users/Mike/AppData/Local/Temp/slime.8336".. (Abort with `M-x slime-abort-connection'.) [95 times] Mark set Polling "c:/Users/Mike/AppData/Local/Temp/slime.8336".. (Abort with `M-x slime-abort-connection'.) [132 times] and it just keeps polling and when I check in c:/Users/Mike/AppData/Local/Temp/, slime.8336 isn't there. Can someone tell me what I'm doing wrong? I can repost if more/different output is needed. FWIW, I'm running under an account with admin privs. Thanks in advance. Cheers, Mike

3 3

[slime-devel] Daily ChangeLog diff
by Helmut Eller 05 Sep '12

05 Sep '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2348 slime/ChangeLog:1.2349 --- slime/ChangeLog:1.2348 Sat Aug 18 09:34:06 2012 +++ slime/ChangeLog Tue Sep 4 08:03:22 2012 @@ -1,3 +1,9 @@ +2012-09-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-loader.lisp (lisp-version-string): Add "s" to Allegro with + SMP support. + Patch by Dave Cooper. + 2012-08-18 Stas Boukarev <stassats(a)gmail.com> * swank-abcl.lisp (find-definitions): Call ext:resolve before

1 0

[slime-devel] updated lisp-version-string in swank-loader.lisp for Allegro CL 9.0 with SMP
by Dave Cooper 04 Sep '12

04 Sep '12

Hello, I made a proposed change to swanker-loader.lisp to make the unique-dir-name for fasl files be unique for Allegro CL 9.0 with SMP which was released in late July. The fasls produced by the SMP version of Allegro are incompatible with the non-SMP version, so the unique-dir-name for fasls should be named differently. Here is my version of lisp-version-string --- it has just the additional ~@[~A~] in the format, for the possible inclusion of "s" for smp, and the conditional (and (member :smp *features*) "s") as a format argument to match this new format directive. This is compatible with the way the current asdf (2.24) is handling the naming for this new fasl distinction between SMP and non-SMP Allegro. (defun lisp-version-string () #+(or clozure cmu) (substitute-if #\_ (lambda (x) (find x " /")) (lisp-implementation-version)) #+(or cormanlisp scl) (lisp-implementation-version) #+sbcl (format nil "~a~:[~;-no-threads~]" (lisp-implementation-version) #+sb-thread nil #-sb-thread t) #+lispworks (lisp-implementation-version) #+allegro (format nil "~A~A~@[~A~]~A~A" excl::*common-lisp-version-number* (if (eq 'h 'H) "A" "M") ; ANSI vs MoDeRn (and (member :smp *features*) "s") (if (member :64bit *features*) "-64bit" "") (excl:ics-target-case (:-ics "") (:+ics "-ics"))) #+clisp (let ((s (lisp-implementation-version))) (subseq s 0 (position #\space s))) #+armedbear (lisp-implementation-version) #+ecl (ecl-version-string) ) Please advise if this is the correct place and format to submit proposals like this. Best Regards, Dave Cooper Genworks Support

2 1

Re: [slime-devel] unexpected behavior of eval-when with CCL when compiling with C-c C-k
by Faheem Mitha 31 Aug '12

31 Aug '12

Hi Helmut, Thanks very much for the detailed and helpful reply. May I post this as an answer to the SO question? If you don't want to post it yourself, that is. On Thu, 30 Aug 2012, Helmut Eller wrote: > On Thu, Aug 30 2012, Faheem Mitha wrote: > >> Hi, >> >> I recently posted a question at >> >> http://stackoverflow.com/questions/12156902/unxpected-behavior-with-eval-wh… >> >> Brief summary: >> >> The following code should (I think) set *read-default-float-format* to >> double float. Well, it does compile with C-c C-k, but running >> >> *read-default-float-format* >> >> in the REPL afterwards gives SINGLE-FLOAT. >> >> So the value of *read-default-float-format* in the REPL has not changed >> from the default value of SINGLE-FLOAT. >> >> Note, however, that the >> >> (print *read-default-float-format*) >> >> in the code does return DOUBLE-FLOAT. >> >> Rainer Joswig, in his answer to this question, says that this is >> because the compilation and the REPL are on different threads (if I >> understand him correctly), but I'd like some evidence of this. > > SLIME creates a new thread for C-c C-k. As compiling could potentially > take a long time, using a new thread seems like a reasonable thing to > do. Therefore the code that compiles and loads your code is a different > thread than the REPL thread. > > For evidence, evaluate (princ ccl:*current-process*) in the REPL and > inside the eval-when form. Ah. I tried the function "all-processes". *current-process* is better. >> Also, this code works fine with SBCL. >> In addition to wanting to understand why this is happening, I'd like >> to know whether it is possible to work around this, and set >> *read-default-float-format* in a file, rather than having to set it on >> the command line. >> >> I'm not sure whether this issue has something to do with SLIME, so I'm >> posting here first. >> >> Platform and versions. I'm using Debian squeeze x86. The version of >> SLIME is from Debian unstable, 1:20120525-2. CCL is the 1.8 release. I >> tried it both with the upstream binaries from >> http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl, and >> a binary package created by me - see Package ccl at >> mentors.debian.net. The result was the same in each case. >> >> Thanks in advance. Please CC me on any reply. > > When CCL creates a new thread it binds some special variables in the new > thread. *READ-DEFAULT-FLOAT-FORMAT* is one of them. You can see the > full list of those variables with (ccl::standard-initial-bindings). > Also look at the documentation of MAKE-PROCESS[1]. I think > CCL:DEF-STANDARD-INITIAL-BINDING can be used to change those variables > for future thread, but I know no easy way to change them in all existing > threads. When it says MAKE-PROCESS here, it actually means thread, right? This terminology is a little confusing. The documentation says "See DEF-STANDARD-INITIAL-BINDING" but there is no further information about DEF-STANDARD-INITIAL-BINDING that I could find. It seems this is a function. I found one example of usage which looks like (ccl::def-standard-initial-binding *read-default-float-format* 'double-float) Is this correct usage? So, this changes the default value of *read-default-float-format* for all future threads? Should this be called in CCL's init file or somewhere else? One last question, which is tangentially related. Is there some easy way to find out what CCL (or, more generally, any CL implementation) function is called by C-c C-k? Regards, Faheem > Helmut > > [1] http://ccl.clozure.com/ccl-documentation.html#f_make-process

2 1

[slime-devel] unexpected behavior of eval-when with CCL when compiling with C-c C-k
by Faheem Mitha 30 Aug '12

30 Aug '12

Hi, I recently posted a question at http://stackoverflow.com/questions/12156902/unxpected-behavior-with-eval-wh… Brief summary: The following code should (I think) set *read-default-float-format* to double float. Well, it does compile with C-c C-k, but running *read-default-float-format* in the REPL afterwards gives SINGLE-FLOAT. So the value of *read-default-float-format* in the REPL has not changed from the default value of SINGLE-FLOAT. Note, however, that the (print *read-default-float-format*) in the code does return DOUBLE-FLOAT. Rainer Joswig, in his answer to this question, says that this is because the compilation and the REPL are on different threads (if I understand him correctly), but I'd like some evidence of this. Also, this code works fine with SBCL. In addition to wanting to understand why this is happening, I'd like to know whether it is possible to work around this, and set *read-default-float-format* in a file, rather than having to set it on the command line. I'm not sure whether this issue has something to do with SLIME, so I'm posting here first. Platform and versions. I'm using Debian squeeze x86. The version of SLIME is from Debian unstable, 1:20120525-2. CCL is the 1.8 release. I tried it both with the upstream binaries from http://svn.clozure.com/publicsvn/openmcl/release/1.8/linuxx86/ccl, and a binary package created by me - see Package ccl at mentors.debian.net. The result was the same in each case. Thanks in advance. Please CC me on any reply. Regards, Faheem ####################################################################### (eval-when (:compile-toplevel :load-toplevel :execute) (require :asdf) (require :cl-rmath) (setf *read-default-float-format* 'double-float)) (print *read-default-float-format*)

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 19 Aug '12

19 Aug '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2347 slime/ChangeLog:1.2348 --- slime/ChangeLog:1.2347 Sat Aug 4 16:48:19 2012 +++ slime/ChangeLog Sat Aug 18 09:34:06 2012 @@ -1,3 +1,8 @@ +2012-08-18 Stas Boukarev <stassats(a)gmail.com> + + * swank-abcl.lisp (find-definitions): Call ext:resolve before + finding definitions, for the symbol may be not autoloaded yet. + 2012-08-04 Stas Boukarev <stassats(a)gmail.com> * swank-sbcl.lisp (call-with-debugging-environment): Use

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 14 Aug '12

14 Aug '12

Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.549 slime/contrib/ChangeLog:1.550 --- slime/contrib/ChangeLog:1.549 Sat Aug 4 15:35:13 2012 +++ slime/contrib/ChangeLog Mon Aug 13 13:50:34 2012 @@ -1,3 +1,9 @@ +2012-08-13 Stas Boukarev <stassats(a)gmail.com> + + * swank-arglists.lisp (extra-keywords/slots): Check for + slot-definition-initfunction being present before calling + slot-definition-initform. + 2012-08-04 Stas Boukarev <stassats(a)gmail.com> * swank-arglists.lisp (test-print-arglist): bind

1 0

[slime-devel] Strange scores in slime-fuzzy-completion / feature request.
by pjb＠informatimago.com 10 Aug '12

10 Aug '12

In a new lisp file type: (defpackage :slime-fuzzy-misfeature (:use :cl)) (in-package :slime-fuzzy-misfeature) (defun f () (let ((pos 4) (siz 2)) (+ pos siz))) (defstruct pt h v) (defun g (p) (let ((pos-h (pt-h p)) (pos-v (pt-v p))) (+ ))) C-x C-s C-c C-l Then move after the + in g, and type po M-TAB We get these fuzzy completion choices: For help on how the use this buffer, see `slime-fuzzy-completions-mode'. Flags: boundp fboundp generic-function class macro special-operator package Completion: Flags: Score: ----------------------------------------------------------- -------- -------- pop -f---m-- 24.70 pos -------- 24.70 pos-h -------- 22.20 pos-v -------- 22.20 position -f------ 21.13 position-if -f------ 20.70 position-if-not -f------ 20.41 … 1- pop is bound to a function not a variable, we're completing a variable: it should not be proposed at all! 2- pos is not in scope it should not be proposed at all. In general it looks like shorter symbols are proposed with higher scores. Instead, symbols in scope (taking account namespaces) should have higher scores. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 05 Aug '12

05 Aug '12

Index: slime/ChangeLog diff -u slime/ChangeLog:1.2345 slime/ChangeLog:1.2347 --- slime/ChangeLog:1.2345 Fri Jul 13 06:52:45 2012 +++ slime/ChangeLog Sat Aug 4 16:48:19 2012 @@ -1,3 +1,11 @@ +2012-08-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-sbcl.lisp (call-with-debugging-environment): Use + sb-debug::resolve-stack-top-hint instead of just + sb-debug:*stack-top-hint*, because now it can contain things other + than just frames. + * clean up: (signal (make-condition ...)) => (signal ...) + 2012-07-13 Helmut Eller <heller(a)common-lisp.net> * slime.el: Don't compile functions that are now in other files. Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.548 slime/contrib/ChangeLog:1.549 --- slime/contrib/ChangeLog:1.548 Wed May 23 13:55:43 2012 +++ slime/contrib/ChangeLog Sat Aug 4 15:35:13 2012 @@ -1,3 +1,9 @@ +2012-08-04 Stas Boukarev <stassats(a)gmail.com> + + * swank-arglists.lisp (test-print-arglist): bind + *print-right-margin* to 1000 instead of NIL, because the default + value on ABCL is less than the length of the tested arglist. + 2012-05-23 Christophe Rhodes <csr21(a)cantab.net> * swank-media.lisp: add provide.

1 0