slime-devel December 2006

slime-devel@common-lisp.net

43 participants
62 discussions

[slime-devel] (code-char 256), connections dies with 256
by Florian Ebeling 17 Dec '06

17 Dec '06

Hi, when I enter (code-char 256) in the repl, it dies, and in the minibuffer emacs says: Lisp connection died unexpectedly; exit code 256 (to that tune). Using sbcl 0.9.8.0-1ubuntu3 and slime HEAD from cvs on Linux 2.6.15-27-686. Known thing? Florian -- Florian Ebeling florian.ebeling(a)gmail.com

5 5

Re: [slime-devel] (code-char 256), connections dies with 256
by Anton Vodonosov 17 Dec '06

17 Dec '06

Florian Ebeling: >> Try it without slime, only in sbcl. > > Sure, there it works. (Gives the uppercase A > with a small horizontall line above.) > Looks like it relates to some code that transmits this value over network and displays it in emacs. I remember that I saw something similar in clisp untill I set configured encodings in the both lisp and emacs sides of slime, but I'm not sure exactly. Lets investigate it. Try this: (progn (setq ch (code-char 256) nil) Will it die? I suppose it will not, and you will be able to execute (char-chode ch). Regards, -Anton

1 0

[slime-devel] slime.el `slime-expand-abbreviations-and-complete'
by Madhu 17 Dec '06

17 Dec '06

[Reported to author(s) by email earlier this year] Emacs `choose-completion' (choosing a completion from the *Completions* buffer) always replaces text upto (point). So the code which figures out an `unambiguous-completion-length' and places the point there in `slime-expand-abbreviations-and-complete' causes problems: the replacement text gets garbled. (setq slime-complete-symbol-function 'slime-complete-symbol* slime-complete-symbol*-fancy nil pop-up-windows nil pop-up-frames nil) In the slime-repl buffer at the prompt, put the string "swank::c-s" and type TAB or M-TAB, and choose any item, say swank::compilation-speed. On finding your way back to the repl buffer, you see the garbled text. For eg; if the string was "(swank::c-s" M-TAB, on finding your way back to the repl buffer, you'll see: "swank::compilation-speed-s" and no paren. This has been around for ever. I believe the following Changelog entries apply. | 2004-02-29 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> | 2003-11-03 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> The fix that gets rid of the bogus `unambiguous-completion-length' is appended. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.698 diff -u -r1.698 slime.el --- slime.el 7 Dec 2006 11:08:57 -0000 1.698 +++ slime.el 10 Dec 2006 13:00:21 -0000 @@ -6096,15 +6097,10 @@ (set-window-start window (point-min) nil) (let ((other-window-scroll-buffer (window-buffer window))) - (scroll-other-window))))) - (let ((unambiguous-completion-length - (loop for c in completion-set - minimizing (or (mismatch completed-prefix c) - (length completed-prefix))))) - (goto-char (+ beg unambiguous-completion-length)) - (slime-display-completion-list completion-set - completed-prefix) - (slime-complete-delay-restoration)))))))) + (scroll-other-window))))) ; madhu + (slime-display-completion-list completion-set + completed-prefix) + (slime-complete-delay-restoration))))))) (defun slime-complete-symbol*-fancy-bit () "Do fancy tricks after completing a symbol.

4 9

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

16 Dec '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1021 slime/ChangeLog:1.1022 --- slime/ChangeLog:1.1021 Thu Dec 14 11:18:18 2006 +++ slime/ChangeLog Fri Dec 15 07:40:47 2006 @@ -1,3 +1,9 @@ +2006-12-15 Edi Weitz <edi(a)agharta.de> + + * swank-lispworks.lisp (make-weak-key-hash-table): Weak hash + tables for Lispworks. + (make-weak-value-hash-table): Ditto. + 2006-12-14 Helmut Eller <heller(a)common-lisp.net> * swank.lisp (*sldb-printer-bindings*): *PRINT-LINES* is in

1 0

[slime-devel] Slime broken on OpenMCL
by ocorrain＠yahoo.com 15 Dec '06

15 Dec '06

Hi-- CVS slime is broken on OpenMCL, as of yesterday at the latest: OpenMCL Version 1.0-p060223 Mac OS X 10.4.8 Emacs 22.0.50.1 Slime CVS ---------> Welcome to OpenMCL Version 1.0-p060223 (DarwinPPC32)! ? ;Loading #P"/Users/ocorrain/elisp/slime/swank-loader.lisp"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/swank-backend.dfsl"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/nregex.dfsl"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/metering.dfsl"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/swank-openmcl.dfsl"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/swank-gray.dfsl"... ;Loading #P"/Users/ocorrain/.slime/fasl/2006-12-14/openmcl-1.0-darwin-powerpc/swank.dfsl"... ; Warning: These Swank interfaces are unimplemented: ; (ACTIVATE-STEPPING ADD-FD-HANDLER ADD-SIGIO-HANDLER CALLS-WHO MACROEXPAND-ALL REMOVE-FD-HANDLERS REMOVE-SIGIO-HANDLERS SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN SLDB-STEP-INTO SLDB-STEP-NEXT SLDB-STEP-OUT) ; While executing: SWANK-BACKEND::WARN-UNIMPLEMENTED-INTERFACES #P"/Users/ocorrain/elisp/slime/swank-loader.lisp" ? > Error in process listener(1): Incorrect keyword arguments in (:EXTERNAL-FORMAT :ISO-LATIN-1-UNIX) . > While executing: "Unknown" > Type :POP to abort. Type :? for other options. 1 > <---------- -- Tiarnán

3 2

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

15 Dec '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.1019 slime/ChangeLog:1.1021 --- slime/ChangeLog:1.1019 Tue Dec 12 10:40:19 2006 +++ slime/ChangeLog Thu Dec 14 11:18:18 2006 @@ -1,3 +1,37 @@ +2006-12-14 Helmut Eller <heller(a)common-lisp.net> + + * swank.lisp (*sldb-printer-bindings*): *PRINT-LINES* is in + effect only if *PRINT-PRETTY* is non-NIL, so it better to enable + the pretty printer. Suggested by Madhu <enometh(a)meer.net>. + + * slime.el (slime-expand-abbreviations-and-complete): Emacs + `choose-completion' (choosing a completion from the *Completions* + buffer) always replaces text upto (point). So the code which + figures out an `unambiguous-completion-length' and places the + point there in `slime-expand-abbreviations-and-complete' causes + problems: the replacement text gets garbled. Get rid of the bogus + `unambiguous-completion-length'. Patch by Madhu <enometh(a)meer.net> + + * swank-cmucl.lisp (remove-gc-hooks): The variables + EXT:*GC-NOTIFY-AFTER* and EXT:*NOTIFY-BEFORE* should hold + functions and should be NIL. This affects the function + REMOVE-GC-HOOKS in swank-cmucl.lisp which sets them to + NIL, (should one happen to use it). Set them back to the original + parameters. Patch by Madhu <enometh(a)meer.net> + + * slime.el (slime-repl-output-mouseover-face): Fix a pair of extra + parens. Patch by Madhu <enometh(a)meer.net> + +2006-12-14 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-search-buffer-package): Remove Xemacs special + casing. There's already a compatibility defun for + match-string-no-properties. + +2006-12-13 Attila Lendvai <attila.lendvai(a)gmail.com> + + * swank.lisp: FIX: fuzzy completion for M-V-B. Fix by Madhu. + 2006-12-12 Nikodemus Siivola <nikodemus(a)random-state.net> * swank.lisp (inspect-for-emacs integer): Pad the hex formatted @@ -15,6 +49,52 @@ it was the Elisp destructure-case that failed to avoid confusion. (slime-check-eval-in-emacs-enabled): More verbose error message. +2006-12-11 Attila Lendvai <attila.lendvai(a)gmail.com> + + * swank.lisp: Added [set value] command for slot inspecting + + * slime.el: Work on repl history navigation, restore old M-p/M-n + behaviour due to #lisp demand + + Also print the current regexp in the minibuffer messages. M-p/M-n + takes the repl input up to the point not the entire input as it + did before. + slime-repl-previous/next-input-starting-with-current-input: new + names for the old M-p/M-n commands History navigation commands + jump to the end of buffer when point is before the prompt. + + * slime.el: Fix/smarten up temp-buffer-quit + + Now it tries its best to remember the original window config and + restore it at slime-temp-buffer-quit unless it was changed + meanwhile. IOW, fix "q" after macroexpand in a macroexpand buffer + not closing the temp window. + Also fix the compiler notes usage of the temp buffer. + + * swank-backend.lisp, swank.lisp: + Added inspect-slot-for-emacs to let users customize it. + + Use all-slots-for-inspector everywhere, render link to both the + effective and direct slots when both are available. Dropped + slot-value-using-class-for-inspector and friends. Added + slot-makunbound-using-class to the swank-mop package and added + a [make-unbound] action to the standard slot presentation. + + * slime.el: FIX: slime-symbol-name-at-point for symbols like + foo::|bar::baz| + + * .cvsignore, swank.lisp: FIX: Drop #\. and add #\, to escaped + symbol chars + + * slime.el: Added slime-repl-delete-from-input-history that + deletes the current history entry when no input is supplied + + * slime.el: slime-repl-kill-input kills the entire input when + point is at the prompt and resets the history navigation state + + * slime.el: + Use a hashtable to remove duplicates in slime-repl-merge-histories + 2006-12-07 Marco Baringer <mb(a)bese.it> * swank.lisp (init-inspector): Added eval parameter. If NIL we

1 0

[slime-devel] OpenGL Integration into the REPL ?
by Sean Charles 14 Dec '06

14 Dec '06

Hello, I am currently developing 'something interesting' using SBCL and OpenGL via Apple X11. I have built SBCL and OpenGLUT from source as I am lucky enough to have an Intel 20" iMac and I wanted to make sure I was getting maximum speed i.e. no Rosetta in the way. My 'project' is coming along but it bugs me that I have to keep stopping and starting the application in order to make changes to the software because once the 'glutMainLoop' gets control the SLIME session doesn't respond anymore. I had to slightly modify the cl-opengl package as it has two symbol naming problems concerning the roman fonts but that is the only change I have had to make along with the library.lisp package which needed to be coaxed into loading my OpenGLUT build on an Intel Darwin platform. Apart from that it works very well, the MESADEMOS:GEARS averages about 4900 frames per second much to my disbelief!!! I know that SBCL does not currently support threading on the intel iMac which maybe would solve all my problems in one fell swoop. Software: SLIME CVS latest as of 13-July-2006 SBCL 0.9.13 OpenGLUT 0.6.3 I have spent a few hours reading the SWANK code trying to see where I can make changes but I am just to new to it, I have used SLIME but never before had a need to modify it and right now it looks a bit intimidating to try and figure out how to do what I would like to do which is basically find a way to make the OpenGL timer function and the display function both to 'keep the SWANK backend alive' by somehow calling whatever is needed to ensure that the SLIME session remains active at the same time as my OpenGL application is running. For me this would be incredibly productive as it means (if I have understood LISP so far [used Smalltalk for about 6 years]) that I can fiddle with my application while it is running and see any changes that affect the display be effected the next time the display is rendered. Is this at all possible??? I would think that a new SWANK back end could be created. I have also toyed with the idea of hacking the SBCL source code directly to contain the OpenGL libraries and somehow making the changes at that point but id I thought SWANK / SLIME was big, SBCL is enormous by comparison and I'd rather be coding my application that fiddling with the tools. Many thanks Sean Charles www.objitsu.com

5 6

[slime-devel] swank-cmucl.lisp remove-gc-hooks
by Madhu 14 Dec '06

14 Dec '06

The variables EXT:*GC-NOTIFY-AFTER* and EXT:*NOTIFY-BEFORE* should hold functions and should be NIL. This affects the function REMOVE-GC-HOOKS in swank-cmucl.lisp which sets them to NIL, (should one happen to use it). I believe the following Changelog entry applies: | 2004-12-05 Helmut Eller <heller(a)common-lisp.net> Appended is a fix which sets them back to the original parameters. Index: swank-cmucl.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-cmucl.lisp,v retrieving revision 1.168 diff -u -r1.168 swank-cmucl.lisp --- swank-cmucl.lisp 23 Nov 2006 23:13:27 -0000 1.168 +++ swank-cmucl.lisp 10 Dec 2006 12:59:37 -0000 @@ -2178,8 +2178,8 @@ (setq ext:*gc-notify-after* #'post-gc-hook)) (defun remove-gc-hooks () - (setq ext:*gc-notify-before* nil) - (setq ext:*gc-notify-after* nil)) + (setq ext:*gc-notify-before* #'LISP::DEFAULT-GC-NOTIFY-BEFORE) + (setq ext:*gc-notify-after* #'LISP::DEFAULT-GC-NOTIFY-AFTER)) (defvar *install-gc-hooks* t "If non-nil install GC hooks")

2 1

[slime-devel] slime doesn't handle spaces in inferior-lisp-program ?
by André 14 Dec '06

14 Dec '06

Hi, My setup is. (setq inferior-lisp-program "C:/Program Files/Steel Bank Common Lisp/1.0/sbcl.exe") (add-to-list 'load-path "C:/Program Files/Emacs/site-lisp/slime-2.0") (require 'slime) (slime-setup) When I execute M-x slime I get the error message "Spawning child process: invalid argument". Experimenting a bit, I found that: (file-exists-p inferior-lisp-program) returns t (set-variable 'explicit-shell-file-name inferior-lisp-program) + M-x shell will get me a SBCL "shell". After moving SBCL to c:\sbcl and changing my config to (setq inferior-lisp-program "C:/sbcl/sbcl.exe") I tried M-x slime again and everything worked fine! I've been looking through the slime source (both 2.0 and the latest snapshot) and the split-string calls in slime-read-interactive-arg sure looks suspicious. Is this a known issue? /A

5 4

[slime-devel] swank.lisp *sldb-printer-settings*
by Madhu 14 Dec '06

14 Dec '06

This issue crops up, for example, when debugging huge strings (imagine huge text files slurped into strings), and is caused by the interactions of *PRINT-PRETTY* and *PRINT-LINES*: *PRINT-LINES* is in effect only if *PRINT-PRETTY* is non-NIL Currently swank.lisp defines |(defvar *sldb-printer-bindings* | `((*print-pretty* . NIL) [...] | (*print-lines* . 200) | (*print-escape* . t)) | "A set of printer variables used in the debugger.") So effectively *PRINT-LINES* is not obeyed, and slime prints huge strings (containing newlines) through emacs, causing much burden on all systems. I suggest changing the binding for *PRINT-PRETTY* in *SLDB-PRINTER-BINDINGS* to T if nothing else depends on it. -- Madhu

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel December 2006