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

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

01 Jun '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.700 slime/ChangeLog:1.706 --- slime/ChangeLog:1.700 Tue May 31 20:38:58 2005 +++ slime/ChangeLog Wed Jun 1 19:00:13 2005 @@ -1,3 +1,45 @@ +2005-06-01 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-load-system, slime-oos): Fix bug related to file + locking. Don't bind the variable system-name. system-name is a + predefined Emacs variable and is used among other things for lock + filenames. + +2005-06-01 Joerg Hoehle <hoehle(a)users.sourceforge.net> + + * swank-clisp (getpid): Updates for current CLISP versions. Use + defimplementation. Define always (slime needs it). + +2005-06-01 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-background-activities-enabled-p): Return nil + instead of signalling an error if there is a open but no default + connection. + (slime-current-connection): New helper function. + (slime-connection): Use it. + (slime-first-change-hook): Only run when + slime-background-activities-enabled-p. + +2005-06-01 Joerg Hoehle <hoehle(a)users.sourceforge.net> + + * swank-cmucl.lisp, swank-sbcl.lisp, swank-clisp.lisp + (describe-symbol-for-emacs): Distinguish macro and special + operators from functions. + + * slime.el (slime-print-apropos): Must keep in sync with above, + therefore added :macro and :special-operator properties. + + * swank.lisp (present-symbol-before-p): Make it conform to its + specification -- sort first by package and then by symbol name. + + * swank-clisp.lisp (describe-symbol-for-emacs): Report :alien-type + when the name is known as foreign type. + +2005-06-01 Espen Wiborg <espenhw(a)grumblesmurf.org> + + * swank-loader.lisp: Redefine compile-files-if-needed-serially for + Corman Lisp to load everything from source. + 2005-05-27 Espen Wiborg <espenhw(a)grumblesmurf.org> * swank-corman.lisp: New file, swank for Corman Lisp.

1 0

[slime-devel] LOAD-SYSTEM and stealing file locks
by Peter Seibel 01 Jun '05

01 Jun '05

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. -Peter -- Peter Seibel peter(a)gigamonkeys.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

4 3

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