slime-devel April 2006

slime-devel@common-lisp.net

58 participants
57 discussions

[slime-devel] linux 64
by Levente Mészáros 04 Apr '06

04 Apr '06

Hi, I installed SLIME CVS version and SBCL 0.9.11 x86-64 under Ubuntu Linux 2.6.12-10-amd64-generic. I'm using xemacs 21.4.17 and when SLIME starts up I get the following error message: itimer "run-with-timer" signaled: (error "127.0.0.1/P Servname not supported for ai_socktype") SBCL works fine in standalone mode and SLIME can start SWANK without problem but cannot connect to it. I get the same result when using M-x slime-connect. I was reading stuff here and there, but I'm still lost. Is there anybody who had similar problems? Do you have any idea what's going on here? levy -- There is no perfectoin

1 1

[slime-devel] Allegro's *source-pathname*
by Gary King 04 Apr '06

04 Apr '06

Allegro generates redefinition warning when a form is evaluated in a buffer. Technically, Allegro is correct: a form that was in a file is now being redefined at the top-level. I find it irritating, however, because the form is contained in a buffer that maps to the file (using all these words in non-technical senses <smile>). If I understand Franz's documentation (see below), then binding *source- pathname* to the pathname of the current buffer would prevent these warnings. Would this be a "bad-thing" or a "good-thing"? After all, there is also the interpret / compile distinction that I believe still matters to Allegro? Opinions? > *source-pathname* > > When a function, defstruct accessor, flavor method, or macro is > defined, and when symbol-function is setf'ed, the value of this > variable is recorded as the place of definition. During a load of a > source file or during a compile-file this variable is bound to the > name of the file being loaded or compiled. Programs, such as > editors running Lisp as a subprocess, or users typing to the top- > level may themselves bind this variable to any pathname designator > (a string or a pathname object) they wish, and the information will > be recorded except when load is used to transmit the definition to > Lisp. thanks, -- Gary Warren King metabang.com http://www.metabang.com/

1 0

[slime-devel] swank-source-files defaults
by Nathan Bird 02 Apr '06

02 Apr '06

use the source-directory as the defaults for the source-file pathnames. Necessary on windows when loading swank on a different drive (device) than the lisp is on. (defun swank-source-files (source-directory) (mapcar (lambda (name) (make-pathname :name name :type "lisp" :defaults source-directory)) ;; *** here `("swank-backend" ,@*sysdep-files* "swank"))) This has been tested on - WinXP + ACL 7.0 (trial) - Linux 2.6 + SBCL 0.9.10

1 0

[slime-devel] propertize not in emacs 20.x
by Matthew D. Swank 02 Apr '06

02 Apr '06

Propertize is not in emacs 20.x, but set-text-properties is. Attached is a patch the replaces the only reference to propertize in slime.el. Tested in emacs 20.7 and 22.0.50. Matt

3 4

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

02 Apr '06

Index: slime/ChangeLog diff -u slime/ChangeLog:1.878 slime/ChangeLog:1.879 --- slime/ChangeLog:1.878 Thu Mar 30 11:42:14 2006 +++ slime/ChangeLog Sat Apr 1 17:55:28 2006 @@ -1,3 +1,8 @@ +2006-04-01 Matthew D. Swank <akopa(a)charter.net> + + * slime.el (slime-fontify-string): Use set-text-properties, not + propertize, for Emacs 20 compatibility. + 2006-03-30 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-init-command): Don't translate filenames since

1 0

Fwd: [slime-devel] propertize not in emacs 20.x
by Matthew D. Swank 02 Apr '06

02 Apr '06

Begin forwarded message: > From: "Matthew D. Swank" <akopa(a)charter.net> > Date: April 1, 2006 7:50:43 PM CST > To: Matthias Koeppe <mkoeppe+slime(a)merkur.math.uni-magdeburg.de> > Subject: Re: [slime-devel] propertize not in emacs 20.x > > > On Apr 1, 2006, at 4:59 PM, Matthias Koeppe wrote: > >> Thanks for the patch, I have applied it in CVS. > > Crud; I actually cleaned it up a little (there no need to copy the > matched string since it's freshly cons'd), and made the comment > more consistent with what was already there. Last time, I promise. > > Matt

1 0

[slime-devel] source location snippet searching
by Taylor R. Campbell 01 Apr '06

01 Apr '06

If the Lisp system provides a snippet hint for a source location, `slime-goto-source-location' uses `slime-isearch' to find the nearest occurrence of it in order to narrow down the location better, and subsequently uses `slime-search-call-site' to narrow it down even further. However, the search may send the point off into some random place in the file, even in a completely different defun, but then `slime-search-call-site' narrows itself to whichever defun it's on and searches *there*, so if `slime-isearch' got lost then the whole thing will get lost. Is there a reason that `slime-goto-source-location' does not narrow to the defun before running `slime-isearch'? The above problem is solved by this simple patch: Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.605 diff -u -r1.605 slime.el --- slime.el 26 Mar 2006 03:51:56 -0000 1.605 +++ slime.el 30 Mar 2006 23:51:34 -0000 @@ -5043,7 +5043,9 @@ (slime-goto-location-buffer buffer) (slime-goto-location-position position) (when-let (snippet (getf hints :snippet)) - (slime-isearch snippet)) + (save-restriction + (narrow-to-defun) + (slime-isearch snippet))) (when-let (fname (getf hints :call-site)) (slime-search-call-site fname))) ((:error message)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel April 2006