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

Re: [slime-devel] Re: SLIME User Survey
by Bill_Clementson＠peoplesoft.com 21 Jun '04

21 Jun '04

>>> Which Lisp versions do you use SLIME with? >> >> Allegro 6.2 and 7.0beta, LispWorks 4.3, CLISP 2.33, and ABCL (cvs) - all on >> Win2000 [...] >> bug: the "v"iew source option in sldb doesn't work for any implementation >> I'm using > Not even in LispWorks? It should work there, with > defun-granularity. Likewise ACL in CVS now. Works in both ACL (with Helmut's patch) and LW now (might have worked previously in LW, but I was pretty sure it wasn't working at one point) at defun-granularity. Still doesn't work in CLISP. Thanks for the quick turn-around! - Bill

1 0

Re: [slime-devel] SLIME User Survey
by Bill_Clementson＠peoplesoft.com 21 Jun '04

21 Jun '04

Klaus Harbo <klaus(a)harbo.net> writes: > Luke Gorrie <luke(a)bluetail.com> writes: > > How well does SLIME work for you? > > Well, it worked flawlessly for me on cmucl, but I have never been able > to get it work properly with Lispworks. See below. I have a set of instructions for setting up slime with LW Personal on Windows at http://home.comcast.net/~bc19191/blog/040315.html My .slime.lisp file has the following for LW: #+lispworks (swank::create-swank-server 4005 :spawn #'swank::simple-announce-function t) These instructions have been tested and work on standard LW Enterprise as well. Are you using the standard LW executable (with IDE and patches) or have you created a console executable? - Bill

1 0

[slime-devel] What is the difference between different ways to evaluate lisp forms?
by Anders Conradi 21 Jun '04

21 Jun '04

Hi, If I start slime using openmcl 0.14.2-p1 on jaguar (mac os 10.2) I get different behaviours that I can't explain when I evaluate lisp forms fin different ways. I get one behaviour when I type C-x C-e after the form in the *slime-repl* buffer or when I type the form at the prompt and press enter and another behaviour when I type C-x C-e after the form in the *inferior-lisp* buffer. The form in question opens a cocoa-window using a window-controller that is supposed to release the window when the window is closed. The problem is that the window is only released and deallocated when I evaluate the form to open the window from the inferior-lisp buffer by typing C-x C-e, not in the other cases. Could you please give me some hints about the differences in evaluating forms in the various ways I described so that I might get to the bottom of this annoying bug I have. I have torn my hair out for almost a week trying to locate this bug in my code and now I am quite desperate. The bug only manifests itself with very particular combinations of the lisp-code that drives the gui and the nib-file that defines the gui. I am sorry if this is off topic but I don't know how else to proceed. // Anders

4 6

[slime-devel] LispWorks OS X create-swank-server
by Brian Downing 21 Jun '04

21 Jun '04

I need this patch to make create-swank-server work on Mac OS X LispWorks Personal (v.4.3.7). It works fine on the same version on Windows without it. Without it I get a network error condition: CL-USER 2 > (swank:create-swank-server) Error: BIND failed: (Can't assign requested address) (49) 1 (abort) Return to level 0. 2 Return to top loop level 0. Type :b for backtrace, :c <option number> to proceed, or :? for other options Obviously this is not the solution, but it demonstrates that there's a problem with the :address keyword argument on Mac OS X, at least on my machine. diff -ur slime-pristine/swank-lispworks.lisp slime/swank-lispworks.lisp --- slime-pristine/swank-lispworks.lisp 2004-06-17 10:59:46.000000000 -0500 +++ slime/swank-lispworks.lisp 2004-06-18 14:51:37.000000000 -0500 @@ -37,8 +37,7 @@ (defimplementation create-socket (host port) (multiple-value-bind (socket where errno) - #-lispworks4.1(comm::create-tcp-socket-for-service port :address host) - #+lispworks4.1(comm::create-tcp-socket-for-service port) + (comm::create-tcp-socket-for-service port) (cond (socket socket) (t (error 'network-error :format-control "~A failed: ~A (~D)" -bcd

2 1

[slime-devel] SBCL I/O streams broken?
by Brian Downing 21 Jun '04

21 Jun '04

I've been having a lot of trouble with I/O to SBCL through slime recently. This is on PPC, using either :sigio or :fd-handler communication style, and dedicated-output-stream either t or nil. It's easy for me to reproduce (Slime as of fifteen minutes ago, SBCL 0.8.11.14): CL-USER> (inspect nil) The object is a SYMBOL. 0. Name: "NIL" 1. Package: #<PACKAGE "COMMON-LISP"> 2. Value: NIL 3. Function: "unbound" 4. Plist: NIL > 0 0 0 00 0 0 90 <C-c C-c, select the second to bottom-most reset> ; Evaluation aborted The second to bottom-most one (usually an abort, but not TOPLEVEL) seems the most reliable to clear it up. What's worse is when (as happens on SBCL/PPC sometimes) you get a recursive debug when the backtrace fails, it drops you into a TTY debugger in the Slime REPL. Since you can't interact with it, and it's difficult to get another SLDB debugger to come up, this is kind of bad. I'm not sure when this started. Also, is there any way to get the slime version anymore? The date no longer appears at the top of a repl, which is kind of annoying since it was easy to identify what era of slime you were working with. -bcd -- *** Brian Downing <bdowning at lavos dot net>

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 21 Jun '04

21 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.411 slime/ChangeLog:1.417 --- slime/ChangeLog:1.411 Sat Jun 19 22:49:08 2004 +++ slime/ChangeLog Sun Jun 20 23:27:24 2004 @@ -1,3 +1,57 @@ +2004-06-21 Luke Gorrie <luke(a)bluetail.com> + + * swank-loader.lisp (*lisp-name*): Add version number to + Lispwork's fasl directory. We should do this for ACL and OpenMCL + too, but for some reason my ACL 5.0 gets an error when trying to + create a directory with a version number in its name, and I don't + have OpenMCL to test with. + + * swank-backend.lisp, swank.lisp (add-hook, run-hook): Moved the + hook mechanism and all hooks to swank.lisp (from + swank-backend.lisp). There is no compelling use for the hooks in + backends yet and I want to pass swank.lisp-internal data + structures in the existing hooks. + (notify-backend-of-connection): Call `emacs-connected' with the + user-io stream for its argument. Should fix previous breakage + where the connection structure was passed instead. + (*globally-redirect-io*): New configurable: when true the standard + streams are globally redirected to Emacs. That way even + e.g. SERVE-EVENT handlers will print to Emacs. Currently does not + handle standard input -- that is trickier since the Lisp's native + REPL can be trying to read from that. + + * slime.el (slime-complete-maybe-restore-window-configuration): + Only restore the window configuration if the completions buffer is + currently visible in the window that we popped it up in. + (slime-complete-maybe-save-window-configuration): Don't save the + window configuration if the completions buffer is already visible. + (slime-repl-return): Make sure the newline goes at the end of the + input, not at point. + (slime-complete-restore-window-configuration): Wrap the + `set-window-configuration' call in (run-at-time 0 ..). XEmacs does + not allow us to set the window configuration from inside + pre-command-hook. + +2004-06-20 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-sbcl.lisp (emacs-connected): Set *invoke-debugger-hook* to + our debugger hook. Not optimal, but at least BREAK will then + invoke our debugger. + (*trap-load-time-warnings*): New variable. If it is true, + conditions, most notably redefinition warnings, signalled at load + time are not trapped. + (swank-compile-file, swank-compile-string): Use it. + + * swank.lisp (guess-buffer-package): Don't signal a continuable + error if the package doesn't exists; that's too annoying. + + * slime.el: Fix outline structure. + (slime-maybe-list-compiler-notes): Fix thinko. + (break): New test. Reorganize the test-suite a bit to support + "expected failures". + (slime-eval-feature-conditional, slime-to-feature-keyword): Add a + ?: to the symbol-name if needed. + 2004-06-20 Luke Gorrie <luke(a)bluetail.com> * swank.lisp (changelog-date): Removed unneeded function.

1 0

[slime-devel] *new-connection-hook*
by Marco Baringer 21 Jun '04

21 Jun '04

*new-connection-hook* passes the connection struct to emacs-connected which expects a stream argument. something has to be changed. should emacs-connected be changed to take a connection object or should the elements in *new-connection-hook* be passed the stream? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

3 5

[slime-devel] swank:*globally-redirect-io*
by Luke Gorrie 21 Jun '04

21 Jun '04

Ahoy, I added a new configurable called swank:*globally-redirect-io*. If you set this to true in your ~/.swank.lisp then we hijack the standard streams globally for the duration of the SLIME connection. That way e.g. serve-event handler output will go to the REPL instead of *inferior-lisp*. Currently it doesn't redirect *standard-input*. That's trickier since we can get the Lisp's native REPL trying to read its input from our SLIME REPL :-). You can also globally install SLDB as the debugger like this: (setq *debugger-hook* #'swank:swank-debugger-hook) But that's old news.. Cheers, Luke (who just found his first use for synonym streams)

1 0

[slime-devel] Error when typing `(in-package' in Lisp mode buffer
by Paolo Amoroso 20 Jun '04

20 Jun '04

As soon as I type the "e" of "(in-package" in a Lisp mode buffer, SLIME stops with the error message included below, and reissues the error until I delete enough characters to make the string no longer recognizable as a package setting form. I use SLIME CVS sources updated a few hours ago with GNU Emacs 20.7.2 and CMUCL 18e under Debian Woody. Paolo ----------------------------------------------------------------- Error in function SWANK::GUESS-BUFFER-PACKAGE: Package nil not found. [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Use current package. [COMMON-LISP-USER] 1: [ABORT] Abort handling SLIME request. 2: [ABORT] Return to Top-Level. Backtrace: 0: (SWANK::GUESS-BUFFER-PACKAGE "nil") 1: (SWANK::EVAL-FOR-EMACS (SWANK:ARGLIST-FOR-ECHO-AREA '("in-package")) "nil" 11) 2: ("DEFUN HANDLE-REQUEST") 3: (SWANK::CALL-WITH-REDIRECTED-IO #S(SWANK::CONNECTION :SOCKET-IO #<Stream for descriptor 6> :DEDICATED-OUTPUT #1=#<Stream for descriptor 7> :USER-INPUT #2=#<SWANK-BACKEND::SLIME-INPUT-STREAM {48607ECD}> :USER-OUTPUT #1# :USER-IO #<Two-Way Stream, Input = #2#, Output = #1#> ...) #<Function "DEFUN HANDLE-REQUEST" {4845C931}>) 4: (SWANK::HANDLE-REQUEST #S(SWANK::CONNECTION :SOCKET-IO #<Stream for descriptor 6> :DEDICATED-OUTPUT #1=#<Stream for descriptor 7> :USER-INPUT #2=#<SWANK-BACKEND::SLIME-INPUT-STREAM {48607ECD}> :USER-OUTPUT #1# :USER-IO #<Two-Way Stream, Input = #2#, Output = #1#> ...)) 5: (SWANK::PROCESS-AVAILABLE-INPUT #<Stream for descriptor 6> #<Closure Over Function "DEFUN INSTALL-SIGIO-HANDLER" {48682EB1}>) 6: (SWANK::HANDLER) 7: (SWANK-BACKEND::SIGIO-HANDLER #<#1=unused-arg> #<#1#> #<#1#>) 8: ("Foreign function call land") 9: ("Foreign function call land") 10: ("Foreign function call land") 11: ("Foreign function call land") 12: ("Foreign function call land") 13: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 14: (COMMON-LISP::DO-INPUT #<Stream for Standard Input>) 15: (COMMON-LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (COMMON-LISP::*EOF*)) 16: (COMMON-LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (COMMON-LISP::*EOF*)) 17: (COMMON-LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (COMMON-LISP::*EOF*)) 18: (READ-CHAR #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (COMMON-LISP::*EOF*) #<unused-arg>) 19: (READ-PRESERVING-WHITESPACE #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) T) 20: (READ-PRESERVING-WHITESPACE #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) NIL) 21: (READ-PRESERVING-WHITESPACE 4 #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) ...)[:EXTERNAL] 22: (READ #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (:EOF) NIL) 23: (COMMON-LISP::%TOP-LEVEL) 24: (COMMON-LISP::RESTART-LISP) ----------------------------------------------------------------- -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 1

[slime-devel] Compilation policy in and out of Slime
by Brian Downing 20 Jun '04

20 Jun '04

[Slime 2004-06-18, SBCL Darwin/PPC 0.8.11.14+many hacks, an oldish Emacs CVS] Once thing I noticed when working on some SBCL internals tonight is that Slime is compiling things for SBCL with very little debug. This can be seen by compiling: (defun bar (x y) (zot x y)) from the Slime REPL and the *inferior-lisp* REPL. The Slime-compiled one has a very short disassembly, and tail-calls the FDEFINITION. The REPL-compiled one is quite long, and doesn't. This is strange, though, since sb-c::*policy* evaluates to the same in either environment. While this was sort of nice for me (Slime's low debug made my find and fix a nasty stack-destroying bug), it seems bad that Slime-compiled code is defaulting to low debug levels, and seems to not be respecting the *policy*. Is this happening on anyone else's installation, and does anyone have an idea why this is happening? (I've not CCed sbcl-devel on this - I figure enough of the SBCL developers who know anything about Slime are on this list.) -bcd

1 1