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

[slime-devel] Standard output no longer appears in REPL
by Steven E. Harris 25 Jun '11

25 Jun '11

It's been a couple of months since I last used SLIME. Today I noticed that when I evaluate expressions in the REPL that write to *standard-output*, the output appears in the *inferior-lisp* buffer, but not in the REPL as it used to. I'm using GNU Emacs on Windows atop the CLISP Cygwin build. SLIME is up to date with CVS. Is there some new configuration required to restore the old behavior with output streams feeding into the REPL output? -- Steven E. Harris

5 12

[slime-devel] broken clojure REPL
by Cyrus Harmon 21 May '10

21 May '10

FWIW, the following patch broke the clojure REPL (*inferior-lisp* still works, but not the fancy REPL): commit addc5be70a489cdc8ed555a2fed7273040da196e Author: Tobias C. Rittweiler <trittweiler(a)common-lisp.net> Date: Sat Oct 31 22:13:55 2009 +0000 * slime.el (slime-inside-string-p, slime-inside-comment-p) (slime-inside-string-or-comment-p): New. * swank-match.lisp: New file. Contains very simple pattern matcher from the CMU AI archive. * swank-loader.lisp: Compile swank-match.lisp. * swank.lisp: Make SWANK package use new SWANK-MATCH package. * slime-autodoc.el, swank-arglists.lisp: Large parts were rewritten. Autodoc is now able to highlight &key parameters, and parameters in nested arglists. * slime-parse.el, slime-c-p-c.el, slime-highlighting-edits.el: Adapted to changes. the symptom is the following: ; SLIME 2009-10-31 user> 3 3 user> (+ 3 4) at which point it just hangs... nothing (helpful) in *messages* or *inferior-lisp*. Reverting to the previous commit fixes the problem. It's really nice to be able to use git to quickly bisect the history to find the offending commit. Not so nice when that commit is >2k lines :( TCR, any ideas? thanks, cyrus

9 33

[slime-devel] bug with image saving while swank is loaded
by Attila Lendvai 14 Jan '10

14 Jan '10

hi! fyi, without these lines in swank.lisp (or something equivalent): (defun after-saved-image-initialized () (setf *log-output* nil) (init-log-output)) #+sbcl(pushnew 'after-saved-image-initialized sb-ext:*init-hooks*) trying to start a swank server after loading a saved image where swank has been loaded in before saving, dies an ugly and not too helpful death: https://bugs.launchpad.net/sbcl/+bug/444427 -- attila

2 2

[slime-devel] Proposed patch for asdf-loading under ALLEGRO
by Robert Goldman 05 Jan '10

05 Jan '10

ASDF operations using SLIME and SWANK won't work under Allegro's Modern (case-sensitive) lisp, because the symbol names are not in all caps as in ANSI lisp. Here's a small patch that makes it work under ACL mlisp as well as under normal ANSI lisps: Index: swank-asdf.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/contrib/swank-asdf.lisp,v retrieving revision 1.7 diff -b -u -F '^(def' -r1.7 swank-asdf.lisp --- swank-asdf.lisp 23 Oct 2008 21:28:03 -0000 1.7 +++ swank-asdf.lisp 25 May 2009 16:40:10 -0000 @@ -26,7 +26,9 @@ (defun operate-on-system (system-name op Example: \(operate-on-system \"SWANK\" \"COMPILE-OP\" :force t)" (with-compilation-hooks () - (let ((operation (find-symbol operation-name :asdf))) + (let ((operation (or (find-symbol operation-name :asdf) + #+allegro + (find-symbol (string-downcase operation-name) :asdf)))) (when (null operation) (error "Couldn't find ASDF operation ~S" operation-name)) (apply #'asdf:operate operation system-name keyword-args))))

2 1

[slime-devel] slime bug: hang when execute command "(sys:call-system '("explorer.exe" "http://www.g.cn") :wait nil)" in slime-repl with lispworks windows 32 bit, 5.1, professional version.
by jingtao xu 01 Dec '09

01 Dec '09

Hi developers: I use slime with a console version of lispworks windows 32 bit,5.1,professional version. when i type command: CL-USER> (sys:call-system '("explorer.exe" "http://www.g.cn") :wait nil) then the input hangs there,without any response. my slime version is cvs server with date 2009.11.26 my lispworks console is generated with codes in attacment file resave.lisp my emacs version is 23.0.94. Best wishes and thanks for your work. Jingtao

2 2

Re: [slime-devel] random returning the same value
by Tobias C. Rittweiler 30 Nov '09

30 Nov '09

Patrick May <pjm(a)spe.com> writes: > Hi, > > I'm using Slime in Aquamacs with CCL. When I evaluate (random > 100) repeatedly in CCL started from a shell, I get a randomly > generated number between 0 and 99 inclusive. When I do the same with > C-x C-e within Slime, I get the same number every time. (random 100 > (make- > random-state)) gives the same behavior, but (random 100 (make-random- > state t)) works properly. > > Is Slime caching something or have I hosed up my environment? Sorry for the late response. CCL's swank backend uses threads by default, and threads inherit values from the global environment. *RANDOM-STATE* probably becomes thread-local automatically in CCL, resulting in the behaviour you described. It should work when you type in the form at the Slime REPL which evaluates all forms in the same thread. -T.

4 4

[slime-devel] cleanups related to setting up keymaps
by Attila Lendvai 30 Nov '09

30 Nov '09

dear list, after the new xref patches, i had a clash with my copy-sexp key bindings (M-C-, and friends on a kinesis keyboard). the resolution was to set the binding in several slime keymaps. but somehow my bindings got clobbered always here and there, so i ended up cleaning up the code around how slime sets up its keymaps. or rather, it's more like finishing a previously started cleanup as i see it from the code. the result is attached in separate patches and is also available at: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.slime;a=summary. main features are: - it's introducing an extra slime-editing-map keymap, and uses set-keymap-parent to chain the bindings as needed. - uses [remap function-name] as key binding to mimic bindings even if they are rebound (and drops the old mimic-key-bindings from fuzzy.el) the patch description from our repo is available at the beginning of each .diff file. -- attila

2 1

[slime-devel] Daily ChangeLog diff
by Helmut Eller 27 Nov '09

27 Nov '09

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1921 slime/ChangeLog:1.1922 --- slime/ChangeLog:1.1921 Thu Nov 26 02:06:50 2009 +++ slime/ChangeLog Thu Nov 26 05:58:08 2009 @@ -3,7 +3,7 @@ * swank-abcl.lisp (arglist): Fixes for functions with non-nil arglist and for generic functions with empty argument lists. - Contributed by Matthias. + Diagnosed and cured by Matthias Hölzl. 2009-11-23 Stas Boukarev <stassats(a)gmail.com>

1 0

[slime-devel] Daily ChangeLog diff
by Helmut Eller 26 Nov '09

26 Nov '09

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1920 slime/ChangeLog:1.1921 --- slime/ChangeLog:1.1920 Mon Nov 23 14:54:55 2009 +++ slime/ChangeLog Thu Nov 26 02:06:50 2009 @@ -1,3 +1,10 @@ +2009-11-26 Mark Evenson <evenson(a)panix.com>> + + * swank-abcl.lisp (arglist): Fixes for functions with non-nil + arglist and for generic functions with empty argument lists. + + Contributed by Matthias. + 2009-11-23 Stas Boukarev <stassats(a)gmail.com> * slime.el (slime-set-connection-info): Set slime-current-thread to t

1 0

[slime-devel] [patch] ABCL arglist display
by Matthias Hölzl 26 Nov '09

26 Nov '09

The current implementation of swank::arglist for ABCL seems to be not quite correct. The attached patch fixes two problems: 1. In the form (multiple-value-bind (arglist present) (or (sys::arglist ...) ...) the value of "present" is always nil if sys::arglist returns a non-nil arglist (since, for any form but the last, "or" returns the primary value only). Hence swank::arglist always returns :not-available if sys::arglist returns a non-nil primary value, therefore no arglist info is displayed for non-generic functions. The attached patch fixes this. 2. The current implementation returns :not-available for generic functions with empty argument list. This does not seem to be quite correct since generic functions without parameters are allowed according to Section 3.4.2 of the HyperSpec. The attached patch changes this by always setting "present" to true when the function is of type "standard-generic-function"; this seems to be correct according to the definition of generic-function-lambda-list in AMOP, p. 216. Best regards, Matthias

2 1