slime-devel

slime-devel@common-lisp.net

4231 discussions

[slime-devel] slime-create-filename-translator revisted.
by Nathan Bird 07 Mar '06

07 Mar '06

I really liked the new slime translation stuff that went in a few days ago... except that tramp is a little bit different on xemacs. Part of it though, tramp has lots of functions for manipulating filenames. If we are going to depend on tramp for this feature, the automatic creation of translation functions, then lets use the tramp stuff that already has this configuration and functions built in. Here is a lisp paste showing what can be done with the new configuration. http://paste.lisp.org/display/17592 If you like, I can go link this from Cliki as well. Nathan Bird nathan(a)acceleration.net ? foo.el ? swank-loader.fas ? swank-loader.lib Index: ChangeLog =================================================================== RCS file: /project/slime/cvsroot/slime/ChangeLog,v retrieving revision 1.852 diff -u -r1.852 ChangeLog --- ChangeLog 4 Mar 2006 20:13:25 -0000 1.852 +++ ChangeLog 7 Mar 2006 04:46:46 -0000 @@ -1,3 +1,8 @@ +2006-03-06 Nathan Bird <nathan(a)acceleration.net> + + * slime.el: (slime-create-filename-translator): use the tramp + methods for dissecting and building filenames. + 2006-03-04 Wojciech Kaczmarek <wojtekk(a)kofeina.net> * slime.el (slime-filename-translations): Typo in example. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.593 diff -u -r1.593 slime.el --- slime.el 4 Mar 2006 20:13:51 -0000 1.593 +++ slime.el 7 Mar 2006 04:46:49 -0000 @@ -1285,7 +1285,7 @@ remote-host username) "Creates a three element list suitable for push'ing onto -slime-filename-translations which uses tramp to load files on +slime-filename-translations which uses Tramp to load files on hostname using username. MACHINE-INSTANCE is a required parameter, REMOTE-HOST defaults to MACHINE-INSTANCE and USERNAME defaults to (user-login-name). @@ -1294,23 +1294,20 @@ which is just the value returned by cl:machine-instance on the remote lisp. REMOTE-HOST is the fully qualified domain name (or just the IP) of the remote machine. USERNAME is the username we -sholud login with." - (setf remote-host (or remote-host machine-instance) - username (or username (user-login-name))) - (lexical-let ((tramp-prefix (concat "/ssh:" username "@" remote-host ":"))) +should login with. +The functions created here expect your tramp-default-method or + tramp-default-method-alist to be setup correctly." + (lexical-let ((remote-host (or remote-host machine-instance)) + (username (or username (user-login-name)))) (list (concat "^" machine-instance "$") - `(lambda (emacs-filename) - (subseq emacs-filename (length ,tramp-prefix))) + (lambda (emacs-filename) + (tramp-file-name-localname + (tramp-dissect-file-name emacs-filename))) `(lambda (lisp-filename) - (concat ,tramp-prefix lisp-filename))))) - -(defun* slime-add-filename-translation (&key machine-instance - remote-host - username) - (push (slime-create-filename-translator :machine-instance machine-instance - :remote-host remote-host - :username username) - slime-filename-translations)) + (tramp-make-tramp-file-name nil + ,username + ,remote-host + lisp-filename))))) ;;;; Starting SLIME

2 3

[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] Error signalling and handling in DEFINTERFACE methods?
by Peter Seibel 05 Mar '06

05 Mar '06

After being bit for about the billionth time by trying to ,cd to a file rather than a directory with the result of leaving *default-pathname-defaults* set to something that doesn't merge will with others, I decided to see if I could make SLIME protect me from myself. As a quick proof of concept, I made this change to swank-allegro.lisp: Index: swank-allegro.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-allegro.lisp,v retrieving revision 1.82 diff -u -r1.82 swank-allegro.lisp --- swank-allegro.lisp 10 Feb 2006 16:54:01 -0000 1.82 +++ swank-allegro.lisp 5 Mar 2006 18:09:36 -0000 @@ -85,6 +85,8 @@ "allegro") (defimplementation set-default-directory (directory) + (unless (excl:probe-directory directory) + (break "~a not a directory." directory)) (let ((dir (namestring (setf *default-pathname-defaults* (truename (merge-pathnames directory)))))) (excl:chdir dir) @@ -500,7 +502,7 @@ (defmethod inspect-for-emacs ((o standard-object) (inspector acl-inspector)) inspector - (values (format "~A is a standard-object." o) (allegro-inspect o))) + (values (format nil "~A is a standard-object." o) (allegro-inspect o))) (defun allegro-inspect (o) (loop for (d dd) on (inspect::inspect-ctl o) (Hmmm, the last chunk of that patch looks like some minor bug fix that I've had lying around that could usefully be applied to the mainline.) But that raises two questions: 1) Is there a standard protocol for signalling errors from functions that are invoked via comma shortcuts? At the moment simply BREAKing does the trick in the sense that I can then abort out of the debugger with no harm done but it seems a bit gross. 2) Is there some clever way to provide a *partial* default implementation. That is, I'd like in swank-backend.lisp to do the error checking (using a suitably portable replacement for EXCL:PROBE-DIRECTORY) before doing the moral equivalent of a CALL-NEXT-METHOD to get to the implementation-specific version. A literal CALL-NEXT-METHOD won't work, it seems, since although DEFIMPLEMENTATION expands to a method, it always expands to a method with default (i.e. T) specializations on all its parameters. -Peter -- Peter Seibel * peter(a)gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/

1 0

[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

Re: [slime-devel] SLIME+Allegro on Windows
by Edi Weitz 24 Feb '06

24 Feb '06

On Thu, 23 Feb 2006 14:47:20 -0800, mikel evins <mevins(a)mac.com> wrote: > Thanks very much, Edi. I'll start with this. Bill Clementson reminded me that I forgot to post the contents of my ~/.slime.lisp file, so here it is: (load "c:/emacs/site-lisp/slime/swank-loader.lisp") #-clisp (swank::create-swank-server 4005 :spawn #'swank::simple-announce-function t) #+clisp (swank::create-swank-server 4005) The first line loads the stock swank-loader.lisp from SLIME. Thanks Bill... :)

2 1

Re: [slime-devel] SLIME+Allegro on Windows
by Bill Clementson 23 Feb '06

23 Feb '06

Hi Edi, > (start-lisp-and-wait "c:/PROGRA~1/acl80/alisp.exe +B +cm -L ~/.slime.lisp&")) You neglected to mention the contents of the .slime.lisp file. It should contain at least the following 2 lines: (load "/path/to/slime/swank-loader.lisp") (swank::create-swank-server 4005) Cheers, Bill

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel