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

[slime-devel] slime-apropos-package now sorts correctly
by Hoehle, Joerg-Cyril 20 Apr '07

20 Apr '07

Hi, slime-apropos-package now conforms to its specification and also sorts symbols printed with package prefix. I supply the patches as attachments in the hope that MS-Windows nor MS-Outlook will break the TAB and LF characters of the original diff. I hope this is fine. Regards, Jörg Höhle.

3 3

[slime-devel] slime-display-edit-hilights
by Marco Baringer 23 Dec '06

23 Dec '06

for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details. 1 - http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e1d0b7bf… -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

8 20

[slime-devel] [patch] closing connections with :fd-handler style
by Stephen Compall 15 Mar '06

15 Mar '06

As far as I can tell, the only way a Swank connection object with style :fd-handler will ever be closed due to EOF (with close-connection) is if either the fd-handler implementation detects the EOF state and knows how to destroy Swank connections, or a condition is raised in the dynamic context of with-reader-error-handler. Looking at the topmost form in that context, however, it can only happen if (listen socket) answers T, so that the attempt to read can proceed and raise an eof-error, which gets wrapped up, etc. I modified process-available-input to test (listen socket) only after calling FN at least once; after all, it always returns T when the handler is called for a normal input state. Without this patch, my fd-handler backend gets into an endless loop calling the handler in install-fd-handler (with the :eof state); with this patch, the socket is closed, removed from *connections*, and from the fd-handler backend properly. Attached is the patch. -- Stephen Compall http://scompall.nocandysoftware.com/blog

2 4

[slime-devel] Odd bug - heads up
by Alan Ruttenberg 15 Mar '06

15 Mar '06

I found that presentations which were in my repl input history, weren't being recalled as presentations when I recalled previous history - they were coming back as text, and so would generally trigger a reader error when I tried the command. I tracked this down to (defun slime-repl-replace-input (string) (slime-repl-delete-current-input) (setq it string) (insert-and-inherit string)) If one uses insert, instead of insert-and-inherit then repl history works correctly for presentations, for me. No idea why this is problematic. It looks like this function has been this way for a long time - perhaps a bug in the emacs I am using (OS X tiger, fink installed, I think). Anyways, thought I'd post this in case anyone else was having the same problem, or had some insight as to why this is happening. -Alan

2 1

[slime-devel] SLIME+Allegro on Windows
by mikel 06 Mar '06

06 Mar '06

Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol? What issues am I not thinking of in my naive view of this problem?

10 11

[slime-devel] News from the stepper ?
by Didier Verna 27 Feb '06

27 Feb '06

Hi ! I was wondering about the status of the slime stepper: I've seen one or two posts about it on this list, but it was like 17 weeks ago. So is it still an active project ? Is it usable ? Thanks a lot. -- Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org

1 0

[slime-devel] Minor problem
by Antonio Menezes Leitao 26 Feb '06

26 Feb '06

Hi, I would like to report a small problem in Slime. Here is the scenario: 1. On a lisp file, change one definition and slime-compile-defun it (C-c C-c). 2. Save the changed buffer. 3. Kill the saved buffer. 4. slime-edit-definition for the changed definition. 5. Emacs complains that it is trying to set-buffer on a non-existent buffer. This occurs with, at least, SBCL, CMUCL, and Allegro. As far as I can see, the problem is that the implementation of swank-compile-string (which is used by slime-compile-defun) ignores the buffer's filename-directory and this makes it impossible for emacs to recover the correct file. I agree that when we are using a buffer that is not connected to a file, that's the proper behavior. However, IMHO, that's not a frequent situation. To solve this problem for Allegro, I made the following quick (and ugly) hack in swank-allegro.lisp: (defimplementation swank-compile-string (string &key buffer position directory) ;; We store the source buffer in excl::*source-pathname* as a string ;; of the form <buffername>;<start-offset>. Quite ugly encoding, but ;; the fasl file is corrupted if we use some other datatype. (with-compilation-hooks () (let ((*buffer-name* buffer) (*buffer-start-position* position) (*buffer-string* string) (*default-pathname-defaults* (if directory (merge-pathnames (pathname directory)) *default-pathname-defaults*))) (compile-from-temp-file (format nil "~S ~S~%~A" `(in-package ,(package-name *package*)) `(eval-when (:compile-toplevel :load-toplevel) (setq excl::*source-pathname* ,(format nil "~A~A;~D" (or directory "") buffer position))) string))))) Then, to recover the source pathname, I changed the following function: (defun find-definition-in-buffer (filename) (let ((directory-p (find #\/ filename :from-end t))) (let ((pos (position #\; filename :from-end t))) (multiple-value-bind (name position) (values (subseq filename 0 pos) (parse-integer (subseq filename (1+ pos)))) (make-location (if directory-p (list :file name) (list :buffer name)) (list :position position)))))) As I said before, it's not a pretty solution :-) Best regards, António Leitão.

1 0

[slime-devel] slime-macroexpand-in-place
by Marco Baringer 26 Feb '06

26 Feb '06

hi, the attached patch provides a function, slmie-macroexpand-in-place, which does exactly what slmie-macroexpand-1 does but replaces the text of the form with its expansion. i've found this very usefull in a *SLME Macroexpansion* buffer and i plan on commiting it. however i don't know what keys to bind it to. is there a way to create a minor-mode such that the slime-macroexpand-1-in-place and slime-macroexpand-all-in-place are bound to the same keys as what the user has bound slime-macroexpand-1 and slmie-macroexpand-all to? -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

4 5

[slime-devel] Unimplemented slime function and sbcl
by Jonathon McKitrick 25 Feb '06

25 Feb '06

Hi all, I'm just wondering... there are a handful of functions SLIME provides that are not implemented under sbcl. Is this going to happen anytime soon or at all? Several would be useful, but if sbcl ever implementes single-stepping, that feature would be invaluable. -Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"

1 0

[slime-devel] *slime-repl nil*
by Austin Haas 25 Feb '06

25 Feb '06

When starting slime (latest from CVS), the repl buffer is being shown with name: *slime-repl nil* It's also showing: ; Adding fd handler: 5 at the end of the *inferior-lisp* buffer, and: ; Adding fd handler: 6 CL-USER> CL-USER> at the start of the repl. I am using SBCL 0.9.9 on a Xen server. Is this a sign of a problem? I'm having trouble running a tbnl application (which runs fine on my local server) and this seemed to be the first clue towards something unusual. Thanks. -austin

1 1