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

[slime-devel] slime-quit broken
by Chris Capel 15 Nov '04

15 Nov '04

The slime-quit function no longer works, apparently because slime-dispatch-event no longer handles that message. I checked out CVS history, and it appears this has been the case since the state machine stuff was removed around revision 198. Is there a function to use to cancel a C-xC-e calculation stuck in an endless loop besides slime-quit, or is this really broken? Chris Capel

2 1

[slime-devel] SLIME-RESET => error in process filter
by Lynn Quam 14 Nov '04

14 Nov '04

At various times while editting in Emacs and invoking SLIME functionality I get the error: error in process filter: Wrong type argument: stringp, nil and SLIME now appears to be in a corrupted state requiring killing Emacs and starting over. This is a very annoying problem. Usually this occurs as a result of invoking SLIME-RESET, which previously did not exhibit this problem. (I am not sure of the date of the most recent CVS version that was ok.) The reason I invoke SLIME-RESET is because I run my own READ-EVAL-PRINT-LOOP which appears to confuse SLIME slime-autodoc-mode unless it do a SLIME-RESET. Is there a "proper" way to make a non-standard READ-EVAL-PRINT-LOOP coexist with slime-autodoc-mode?

1 0

[slime-devel] Replacing slime-autodoc by eldoc ?
by Xavier Maillard 11 Nov '04

11 Nov '04

Hello, Is there any reason that prevent us to use eldoc when coding Lisp ? Why the choice was to reinvent the wheel by creating slime-autodoc ? Any hint on how to change that and use eldoc ? Just curious why this exists ;) Thank you guys. -- No e-patents, pas de brevets logiciels Pétition contre les brevets logiciels : http://petition.eurolinux.org

3 4

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 11 Nov '04

11 Nov '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.567 slime/ChangeLog:1.568 --- slime/ChangeLog:1.567 Tue Nov 9 23:58:23 2004 +++ slime/ChangeLog Thu Nov 11 23:30:20 2004 @@ -1,3 +1,8 @@ +2004-11-11 Raymond Toy <raymond.toy(a)ericsson.com> + + * slime.el (slime-activate-font-lock-magic): Add XEmacs support. + (slime-reader-conditional-face): New face. + 2004-11-10 Marco Baringer <mb(a)bese.it> * swank-backend.lisp (definterface): Eliminate unused variable

1 0

[slime-devel] Reader conditional highlighting for xemacs
by Raymond Toy 11 Nov '04

11 Nov '04

Here is a very gross implementation of reader conditional highlighting for xemacs. This is a really cool feature, but it should use something besides font-lock-comment-face, I think. It would also be nice if the conditional expression were also highlighed the same way. Then I could ignore it completely. Ray (defun slime-activate-font-lock-magic () (if (featurep 'xemacs) (let ((pattern '((slime-search-suppressed-forms (0 font-lock-comment-face t))))) (setf lisp-font-lock-keywords (append lisp-font-lock-keywords pattern)) (setf lisp-font-lock-keywords-1 (append lisp-font-lock-keywords pattern)) (setf lisp-font-lock-keywords-2 (append lisp-font-lock-keywords pattern))) (font-lock-add-keywords 'lisp-mode '((slime-search-suppressed-forms 0 font-lock-comment-face t))))) (when slime-highlight-suppressed-forms (slime-activate-font-lock-magic))

2 1

Re: [slime-devel] Re: sbcl regression with slime
by Helmut Eller 11 Nov '04

11 Nov '04

Christophe Rhodes <csr21(a)cam.ac.uk> writes: > Does that clear things up? I think there are more problems than just > this in the communications layer, but maybe this will do until after > dinner... :-) Well, I don't understand what the locale has to do with the SLIME coding system. Of course, the locale may have some have a multibyte coding system as default, but for SLIME we can use whatever we like. I think we should use a unibyte coding system. Simple, easy to understand, and efficient. You will not be able to send your emails with SLIME, but that's a restriction I can live with :-) We do already (set-buffer-multibyte nil) in slime-make-net-buffer. So, character positions it the *cl-connection* buffer should correspond to byte offsets. In slime-net-connect we do: (set-process-coding-system proc 'no-conversion 'no-conversion) Maybe we should use 'iso-latin-1-unix for writing. How does that sound? Helmut.

4 4

[slime-devel] SLIME to be featured in Practical Common Lisp
by Peter Seibel 11 Nov '04

11 Nov '04

I'm getting to the point in the work on my book that I'm starting to think in detail about packaging code for the accompanying CD, etc. I'm planning to use some version of the Lisp In A Box package that Matthew Danish and Mikel Evins have been working on which features SLIME heavily. I'll also be using SLIME as my example of a Lisp development environment, talking about it in the text. So, the question is, what version of SLIME do I use? I've only been loosely paying attention--have there been any changes since 1.0 that I'll want? (I've been running CVS head for pretty much forever). Are there any plans for a 1.1 or 1.0.1 or whatever? Also, is there anything that Franz could do to help us make SLIME better on Allegro? Since they're the ones who started this book project, the accompanying CD will probably contain a version of Allegro for Linux, Windows, and OS X. Are there any features of SLIME that are missing or lame on Allegro compared to other Lisp's? If there's any low-hanging fruit that could be picked off with a bit of cooperation from the folks at Franz maybe I can talk to them about it. FWIW, I'm also planning to provide SBCL for Linux and OS X, OpenMCL for OS X, and perhaps CLISP for all three platforms. (Unless either a Windows port of SBCL or CMUCL shows up in the near future.) So if there any notable SLIME defficiencies on any of those platforms that I should be aware of, feel free to let me know. Finally, are there any major holes in the current SLIME docs? I may be able to help plug them if there are so I can just refer folks to SLIME docs rather than having to explain everything in the book text proper. -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

4 4

[slime-devel] Re: CMUCL: cannot find core file after 2004-11-07
by Chisheng Huang 10 Nov '04

10 Nov '04

Brian Downing <bdowning(a)lavos.net> writes: > On Sun, Nov 07, 2004 at 02:31:48PM -0800, Chisheng Huang wrote: >> Before 2004-11-07, I could fire up CMUCL with my own lisp core image, >> pcore, this way: >> M-x dired <RET> directory-containing-pcore <RET> >> C-u M-x slime <RET> <SPC> -core pcore <RET> >> >> After I did a CVS update on 2004-11-07, doing the same thing gets me >> the following error message: >> Cannot find core file pcore >> Based on lisp binary path `/usr/local/cmucl/bin/lisp' >> >> Process inferior-lisp exited abnormally with code 1 >> >> Doing a CVS update with -D "2004-11-06" got me back a version of Slime >> that won't bark at my "C-u M-x slime <RET> <SPC> -core pcore <RET>" >> >> Is this change on 2004-11-07 a bug or feature? > > I don't believe I changed anything like this in my commit today, and I > see identical behavior between a 2004-11-06 and 2004-11-07 checkout. > Here is what I think is happening: > > The first time you run M-x slime, it makes the *inferior-lisp* buffer > with the pwd of the directory of the current buffer. So if you were to > try your experiment above and make sure you're in the right directory > before *inferior-lisp* is created, it will work. > > However, *inferior-lisp* isn't normally deleted when the Slime > connection is closed. Afterwards, M-x slime will reuse the same > *inferior-lisp* with the same old directory. I was in a frenzy to finish something at that time. What you stated above is probably right. I just did a "cvs update -A" and started up CMUCL with my own core image without any problem. Sorry about the noise. Thanks a lot to all Slime developers for this wonderful piece of software. Best, -cph

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 09 Nov '04

09 Nov '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.565 slime/ChangeLog:1.567 --- slime/ChangeLog:1.565 Sun Nov 7 16:07:00 2004 +++ slime/ChangeLog Tue Nov 9 23:58:23 2004 @@ -1,3 +1,32 @@ +2004-11-10 Marco Baringer <mb(a)bese.it> + + * swank-backend.lisp (definterface): Eliminate unused variable + received-args. + (emacs-connected, make-stream-interactive, condition-references, + condition-extras, buffer-first-change): Add (declare (ignore X)) + for unused arguments in default implementations. + (inspect-for-emacs): Remove (declare (ignore)) for inexistent + variable inspection-mode. Added T qualifiers in method arguments. + + * swank-openmcl.lisp (inspect-for-emacs): Use definterface so + SLIME knows we implement this. + (arglist function): Use ccl:arglist, not ccl::arglist-from-map. + (inspect-for-emacs): Added support for inspecting the uvector + objects under lisp datums. + +2004-11-09 Helmut Eller <heller(a)common-lisp.net> + + * swank.lisp (features-for-emacs): New function to avoid + keyword/string confusion. Case doesn't matter since Emacs will + downcase them anyway. + (connection-info, sync-features-to-emacs): Use it. Should fix + highlighting bug reported by Edi Weitz. + + * slime.el (slime-eval-feature-conditional): Convert AND, OR, and + NOT to lowercase keywords. + (slime-net-read3): Silly optimization: give char-after the offset + as argument to avoid save-excursion and forward-char. + 2004-11-07 Brian Downing <bdowning(a)lavos.net> * slime.el (slime-fuzzy-explanation): Added line to describe

1 0

[slime-devel] Re: sbcl regression with slime
by Christophe Rhodes 09 Nov '04

09 Nov '04

Alexey Dejneka <adejneka(a)comail.ru> writes: > Zach Beane <xach(a)xach.com> writes: > >> To reproduce: >> >> 1. Start SLIME with a recent CVS sbcl >> >> 2. At the slime repl, type "*features*" >> >> At that point, I get a message like "error in process filter: wrong >> type argument listp," in the minibuffer. (When I try to select it, it >> disappears, sorry for the imprecision.) > > I had the same problem when I updated SBCL to the Unicode version. But > for me removing .slime/sbcl*/*.fasl and restarting emacs has solved > the problem. Just updated SLIME and SBCL 0.8.16.35 with :SB-UNICODE > pass your test here. How odd. To me, it seems that this bug has always been there, and I have no idea why we've only just started noticing it. (Clearly I don't do enough real work in slime). The problem arises in UTF-8 locales only, with slime's emacs end treating the first three bytes or so of a connection as text (rather than binary). The attached patch fixes the problem at a certain cost in dynamic range of communications. Please advise if this is the desired solution, or if I/we need to do some more work. Cheers, Christophe

2 2