slime-devel

slime-devel@common-lisp.net

4231 discussions

Re: [slime-devel] LOAD-SYSTEM and stealing file locks
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

>On 5/26/05, Peter Seibel <peter(a)gigamonkeys.com> wrote: >> I've recently noticed that when I do a ,load-system and Emacs offers >> to save modified files, it complains about the files being locked by >> another process and asking if I want to steal the lock etc. However >> the PID it gives is in fact my Emacs process. So I wonder if SLIME is >> doing something funny under the covers--I can't imagine what but I >> finally correlated this with usin ,load-system so I'm hoping someone >> here might just know what's going on. Me too, and I hadn't even noticed that this misbehaviour involved slime, I thought my UNIX box was misconfigured! I'm using Emacs-21.3 with slime-1.2.1 on Ubuntu/Hoary/Debian Linux-686. I want to test slime with clisp-native-win32 as well, but I fear I'll have to wait until I have resources to build a new win32-clisp, because the one I have there may be too old. Regards, Jörg Höhle

1 0

[slime-devel] swank-clisp getpid simplified
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Hi again, this one comes in two parts (that's how it got into my local RCS). The WIN32 package is not needed anymore in newer #+win32 clisp, since sys::process-id is now always present on UNIX and Win32. On a related note, would it be useful to have a comment in the source about what interfaces need be defined (e.g. getpid) and which are there for nice functionality only (e.g. stepping)? Regards, Jorg Hohle

2 1

[slime-devel] bug report: slime gets in the way even outside slime mode
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Hi, I have just had the following case using slime-1.2.1 with Emacs-21.3 on a Ubuntu/Hoary/Debian box: after my clisp went unresponsive (probably some FFI stuff), allocating a 750MB heap, I had to really kill -KILL it. Now, I'm in a .lisp buffer, and want to insert anything into it. It fails, I can't edit that buffer, and there's an error message "No default connection selected" which looks like it comes from SLIME. Why is slime trying to do anything here? What is it trying to do? I used M-x slime-mode, which reported "Slime mode disabled" (and slime disappeared from the modeline). Still I can't edit the buffer and get the same message. Note that the file buffer is currently saved, i.e. inserting something would do losts of things to happen in Emacs (create lock and backup file, change modified-p status etc.). And it's in RCS minor mode. I then selected a running cmucl using M-x slime-list-connections, and now things seem back to normal. Hmm, maybe the crash was due to slime trying to print a circular list structure (more precisely, an array with circular references, i.e. containing itself). Running clisp a second time inside slime, I managed to ^C it while in PRINT, when it had only allocated 350MB RAM... Regards, Jörg Höhle.

2 1

Re: [slime-devel] slime-apropos-package now reports FFI types
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Helmut Eller wrote: >I didn't apply the "Alien type" -> "Alien / Foreign type" change, >because I think it's annoying to both CMUCL and CLISP users; "Alien" >only annoys CLISP users. And Lispworks, the day it gets similar functionality. And CormanLisp (I just checked). My opinion was that the name hint was ok (look behind the fence), given that only a few symbols will have such a property. But it's a minor point. I have one more patch in the line. Regards, Jorg Hohle.

1 0

[slime-devel] slime-apropos-package now reports FFI types
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Hi, I found the slime-apropos-output on cmucl quite informative, so I extended it for clisp: FFI type definitions are now mentioned. Try out M-s slime-apropos-package FFI On a related note, I'm tired of having all contants report as "variable" in the slime apropos list. But I haven't written a patch for that yet :-) Please tell me if there's a problem with any of my patches. Due to my problems with unavailable CVS access to common-lisp.net, I cannot afford to consistently use the latest and greatest and plan to stick with 1.2.1 or for a while, or some snapshots of FAIRLY-STABLE here and then and only occasionaly peek at slime-devel@... Regards, Jörg Höhle.

2 1

[slime-devel] slime-apropos now reports macros as such, not as functions
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Hi all, Thank you for putting up the 1.2.1 release of slime (with many improvemements over 1.0). Thank you for having done it just recently so that I can send in patches based on that, without having trouble with CVS (I cannot connect to the CVS server from behind a corp. firewall). Nevertheless, I checked with both a FAIRLY-STABLE and a daily snapshot that the regions I patched haven't been modified since then. Here's the first of a series of patches. I was tired of having SLIME report loads of macros and special operators as functions, so I changed it for sbcl, cmucl and clisp. sbcl is untested, because I only have 0.8.17 here, but the code is identical to cmucl. I'm sorry not to have provided blind patches for allegro, mcl, lw etc. Separating special-operators from macros requires some implementation-dependent tweaking. For example, LOCALLY and WHEN both declare themselves as macro-function and special-operator-p in CLISP, and this is conforming to CL. I chose to have them both report as macros in CLISP. I believe the cmucl code is the most generic and can serve as a model for the other implementations. Regards, Jörg Höhle.

2 1

[slime-devel] single keystroke debugging with clisp?
by Hoehle, Joerg-Cyril 01 Jun '05

01 Jun '05

Hi, a few month ago, I tried out slime-1.0 with either Emacs-20.7 on MS-Windows or some other Emacs on Suse Linux 8.0/1, and enjoyed the single keystroke step mode with clisp. I.e., where normally one would type step#\Return or next#\return, a single s or n sufficed: stepping became enjoyable. Now I installed slime-1.2.1 on a Debian box and even looked at slime-cvs?tag=FAIRLY-STABLE and silme-cvs?HEAD from a couple of days ago, and found nothing like this much appreciated functionality anymore. Did I dream that whole story while awake? I just started again Emacs-20.7 with the slime-1.0 there on the MS-Windows box and got no single keystroke stepping. Invoking CLISP's STEP macro did not make anything special happen in slime or sldb. Invoking (defun foo(n)(if (zerop n) 1(* (progn (break) n) (foo (1- n))))) with (foo 3) caused sldb to open, but hitting s raised the error NO-APPLICABLE-METHOD: When calling #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:SLDB-STEP> with arguments (0), no method is applicable. What happened? I'm pretty sure I once experienced single keystroke stepping in CLISP. Does anybody know about that? Thanks for your help, Jörg Höhle

2 1

[slime-devel] Compilation woes
by Espen Wiborg 01 Jun '05

01 Jun '05

It turns out that Corman Lisp has real difficulties dealing with compilation. Sometimes the compilation fails, other times the loading of compiled files falls over. My proposed fix: Add the following to swank-loader.lisp just before the call to compile-files-if-needed-serially: #+cormanlisp (defun compile-files-if-needed-serially (files) "Corman Lisp has trouble with compiled files, so load them from source instead." (dolist (file files) (load file :verbose t))) Thus loading swank from source. This works just fine (and is just as fast, if not faster, than loading fasl files). Is this accepted style, or should I do this some other way? And if it is accepted style, should I #-cormanlisp the first definition of compile-files-if-needed-serially? -- Espen Wiborg <espenhw(a)grumblesmurf.org> Meddle not in the affairs of wizards, it makes them soggy and hard to light

2 2

[slime-devel] Additional source location information for SBCL
by Nikodemus Siivola 01 Jun '05

01 Jun '05

Development environments such as Slime benefit from being able attach additional source location information (eg. buffer associations) to functions. Currently Slime does this by patching SBCL in order to be able to attach its own plists to SB-C::DEBUG-SOURCE structures. I propose we add :SOURCE-PLIST option to WITH-COMPILATION-UNIT, with the following tentative spec: :SOURCE-PLIST Plist-Form Attaches the value returned by the Plist-Form to internal source location information of functions and definitions compiled in within the dynamic contour. Primarily for use by development environments, in order to eg. associate function definitions with editor-buffers. Can be accessed as SB-INTROSPECT:DEFINITION-SOURCE-PLIST. If multiple, nested WITH-COMPILATION-UNITs provide :SOURCE-PLISTs, they are appended togather, innermost left, unless :OVERRIDE is true, in which case previous :SOURCE-PLISTs are ignored. The space-costs of this are nominal: size of DEBUG-SOURCE structures is increased by one slot/word, but there is only one of those per compiled file -- though one per function loaded from source or entered at the toplevel. I think calling it a :SOURCE-PLIST is a reasonable compromise between more abstract names such as :INFO, the documentary nature of the -PLIST vrt. the appending behaviour, by YMMW. To illustrate the usage, the significant part of SWANK-COMPILE-STRING[*] could eg. become (with-compilation-unit (:source-plist (list 'emacs-buffer buffer 'emacs-string string 'emacs-position position)) (with-input-from-string (s string) (load s)))))) I've the SBCL parts of this implemented in my local tree, and most of swank-sbcl adapted for this. The questions to SBCL and Slime folks respectively: 1. Does the interface seem sane and something we would be happy to support? Are the non-slime use cases this doesn't reasonably cover? 2. Does this fit the needs of Slime? If this existed on other platforms as well, would you be tempted to use this instead of whatever you currently use? [*] To nitpick, I venture the opinion that SWANK-COMPILE-STRING is a misnomer, as as far as I can tell the intention is something like "evaluate the forms contained in this string as if they had been entered at the toplevel, but making sure all functions are compiled". Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."

2 3

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 31 May '05

31 May '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.699 slime/ChangeLog:1.700 --- slime/ChangeLog:1.699 Tue May 24 21:10:08 2005 +++ slime/ChangeLog Tue May 31 20:38:58 2005 @@ -1,3 +1,14 @@ +2005-05-27 Espen Wiborg <espenhw(a)grumblesmurf.org> + + * swank-corman.lisp: New file, swank for Corman Lisp. + + * swank.lisp (simple-announce-function): force-output after + announcing. + (symbol-external-p): Be extra paranoid about the symbol's package; + find-symbol barfs on a nil package in Corman Lisp. + + * swank-loader.lisp: Add Corman Lisp support. + 2005-05-24 Alan Ruttenberg <alanr-l(a)mumble.net> * slime.el text-property-default-nonsticky not defined in @@ -178,6 +189,7 @@ slime-complete-symbol* and slime-simple-complete-symbol. 2005-05-06 Alan Ruttenberg <alanr-l(a)mumble.net> + * swank-openmcl.lisp specializer-name didn't handle structure-class which caused meta-. of methods specialized on defstruct arguments to fail.

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