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

[slime-devel] Bug report
by Ignas Mikalajunas 07 Jan '04

07 Jan '04

I am feeling lucky today ;) I was trying to profile one function that runs pretty long then got an error telling me that 589 ... ... ... is not a fixnum. After pressing enter on a [return to slime top level] a few times i got back to my lisp code. Then i tried to execute (profile:profile-all) (was compiling clis at that moment so PC was under a pretty heavy load) and got this (the report is attached). Ignas Mikalajunas

2 1

[slime-devel] Usable multiple session support
by Luke Gorrie 07 Jan '04

07 Jan '04

Howdyo, The multiple session support should be usable now. Each connection gets its own REPL, and if you do `C-u M-x slime' you get the option of firing up an extra *inferior-lisp* to connect to. Note that currently if you bring up two inferior-lisps, the first one will be called *inferior-lisp*<1> and the second *inferior-lisp*. As before, `slime-next-connection' will cycle the "default" connection that will be used for commands in your lisp-mode buffers. The REPL, SLDB, apropos-results, etc buffers are all "sticky" -- they keep using the connection that created them. Currently there isn't much to help you keep track of matters, except that repl/sldb buffers have the connection number in their buffer name. Obligatory screenshot (slightly gimp-mangled, I'm no Dan Barlow :-) http://www.bluetail.com/~luke/misc/lisp/slime-multisession.png Bug reports or usability suggestions would be welcome. Cheers, Luke

1 1

[slime-devel] Crash when invoking restarts in break loop view
by Paolo Amoroso 06 Jan '04

06 Jan '04

After updating SLIME half a dozen hours ago from the latest CVS head sources, and I have found a reproducible way of crashing it with CMUCL 18e and GNU Emacs 20.7.2 under Debian Woody. Do the following: 1) Create a file such as the following, which contains a Lisp form that generates an error: (defun toward-infinity () (/ 1 0)) (toward-infinity) 2) Evaluate each form with `C-x C-e' 3) When SLIME's break loop and backtrace view appears, press `q' or invoke another restart with the corresponding numer. The following message is displayed: ------------------------------------------------------------------------ You have encountered a bug in SLIME. The communication state machine received an event that was illegal for its current state, which means that the communication between Emacs and Lisp has lost synchronization. The connection to Lisp has therefore been closed. You can open a fresh connection with `M-x slime'. Please report this problem to your friendly neighbourhood SLIME hacker, or the mailing list at slime-devel(a)common-lisp.net. Please include in your report: A description of what you were doing when the problem occured, the version of SLIME, Emacs, and Lisp that you are using, the Lisp backtrace, if one was printed, and the information printed below: The event was: (:aborted) The state stack was: (slime-debugging-state slime-evaluating-state slime-idle-state) The content of the *slime-events* buffer: (:emacs-evaluate "(swank:getpid)" nil (:catch-tag slime-result-80998)) (activate) ; slime-evaluating-state (:%apply "slime-open-stream-to-lisp" (32806)) (:new-features ("PCL-STRUCTURES" "PORTABLE-COMMONLOOPS" "PCL" "PYTHON" "PENTIUM" "I486" "LINKAGE-TABLE" "MP" "GENCGC" "GLIBC2.1" "CMU18" "CMU18E" "RELATIVE-PACKAGE-NAMES" "CONSERVATIVE-FLOAT-TYPE" "RANDOM-MT19937" "HASH-NEW" "X86" "LINUX" "GLIBC2" "UNIX" "COMMON" "CMU" "NEW-COMPILER" "COMMON-LISP" "ANSI-CL" "IEEE-FLOATING-POINT")) (:ok 574) (activate) ; slime-idle-state (:emacs-evaluate "(swank:interactive-eval \"(defun toward-infinity ()\n (/ 1 0))\n\")" nil (:function (lambda (&rest --cl-rest--) (apply '(lambda (G81043 value) (save-current-buffer (set-buffer (symbol-value G81043)) (slime-show-evaluation-result value))) '--buffer-- --cl-rest--)))) (activate) ; slime-evaluating-state (:ok "TOWARD-INFINITY") (activate) ; slime-idle-state (:emacs-evaluate "(swank:interactive-eval \"(toward-infinity)\")" nil (:function (lambda (&rest --cl-rest--) (apply '(lambda (G81081 value) (save-current-buffer (set-buffer (symbol-value G81081)) (slime-show-evaluation-result value))) '--buffer-- --cl-rest--)))) (activate) ; slime-evaluating-state (:debug 1 ("Arithmetic error DIVISION-BY-ZERO signalled.\nOperation was KERNEL::DIVISION, operands (1 0)." " [Condition of type DIVISION-BY-ZERO]") (("ABORT" "Return to Slime toplevel.") ("ABORT" "Return to Top-Level.")) ((0 "(KERNEL::INTEGER-/-INTEGER 1 0)") (1 "(/ 1 0)") (2 "(SWANK:INTERACTIVE-EVAL \"(toward-infinity)\")") (3 "(SWANK:INTERACTIVE-EVAL 1 \"(toward-infinity)\")[:EXTERNAL]") (4 "(SWANK:EVAL-STRING \"(swank:interactive-eval \\\"(toward-infinity)\\\")\" NIL)") (5 "(SWANK:EVAL-STRING 2 \"(swank:interactive-eval \\\"(toward-infinity)\\\")\" NIL)[:EXTERNAL]") (6 "(SWANK::CALL-WITH-SLIME-STREAMS #<SWANK::SLIME-INPUT-STREAM {484CB23D}> #<Stream for descriptor 8> #<Two-Way Stream, Input = #<SWANK::SLIME-INPUT-STREAM {484CB23D}>, Output = #<Stream for descriptor 8>> #<Function FUNCALL {10060F79}> ...)") (7 "(SWANK::CALL-WITH-SLIME-STREAMS 5 #<SWANK::SLIME-INPUT-STREAM {484CB23D}> #<Stream for descriptor 8> #<Two-Way Stream, Input = #<SWANK::SLIME-INPUT-STREAM {484CB23D}>, Output = #<Stream for descriptor 8>> ...)[:EXTERNAL]") (8 "(SWANK::READ-FROM-EMACS)") (9 "(SWANK::READ-FROM-EMACS 0)[:EXTERNAL]") (10 "(SWANK::SERVE-ONE-REQUEST #<Stream for descriptor 6> #<Stream for descriptor 8> #<SWANK::SLIME-INPUT-STREAM {484CB23D}> #<Two-Way Stream, Input = #<SWANK::SLIME-INPUT-STREAM {484CB23D}>, Output = #<Stream for descriptor 8>>)") (11 "(SWANK::SERVE-ONE-REQUEST 4 #<Stream for descriptor 6> #<Stream for descriptor 8> #<SWANK::SLIME-INPUT-STREAM {484CB23D}> ...)[:EXTERNAL]") (12 "(\"DEFUN REQUEST-LOOP\" #<unused-arg>)") (13 "(\"DEFUN REQUEST-LOOP\" 1 #<unused-arg>)[:EXTERNAL]") (14 "(COMMON-LISP::SUB-SERVE-EVENT 1 0)") (15 "(SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)") (16 "(COMMON-LISP::DO-INPUT #<Stream for Standard Input>)") (17 "(COMMON-LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL (COMMON-LISP::*EOF*))") (18 "(COMMON-LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL (COMMON-LISP::*EOF*))") (19 "(COMMON-LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL (COMMON-LISP::*EOF*))"))) (activate) ; slime-debugging-state (:emacs-evaluate "(swank:throw-to-toplevel)" nil (:function (lambda (_)))) (activate) ; slime-evaluating-state (:aborted) (activate) ; slime-debugging-state (:debug-return 1) (:aborted) The content of the *cl-connection* buffer: ------------------------------------------------------------------------ The *inferior-lisp* buffer contains: * ;; Swank started at port: 32804. #<Handler for INPUT on descriptor 5: #<Closure Over Function "DEFUN ACCEPT-LOOP" {484C2D71}>> * ;; Connection to Emacs lost. ;; [End-of-File on #<Stream for descriptor 6>] After the error message is displayed, SLIME becomes unusable even after starting a fresh session. Incidentally, the error message has a typo: A description of what you were doing when the problem occured, ^^^^^^^ Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 1

[slime-devel] sldb is not working in windows version of Allegro CL
by Ignas Mikalajunas 06 Jan '04

06 Jan '04

I have managed to track down the issue to these changes betwen two versions of swank-allegro.lisp (defmethod debugger-info-for-emacs (start end) - (list (debugger-condition-for-emacs) + (list (format-condition-for-emacs) (format-restarts-for-emacs) (backtrace start end))) (defmethod frame-locals (index) (let ((frame (nth-frame index))) (loop for i from 0 below (debugger:frame-number-vars frame) - collect (list :name (to-string (debugger:frame-var-name frame i)) + collect (list :symbol (debugger:frame-var-name frame i) :id 0 :value-string (to-string (debugger:frame-var-value frame i)))))) If i am not changing the file everything works perfectly yet after applying changes to the function frame-locals slime puts nil's instead of variable names. And modifying debugger-info-for-emacs effectively disables the debuger ... Ignas Mikalajunas

2 2

[slime-devel] Patch proposal
by Ignas Mikalajunas 06 Jan '04

06 Jan '04

To solve the portability issues (i am running slime in windows) i think the following source should be included into the slime distribution: --- swank-loader.lisp 2 Jan 2004 08:16:46 -0000 1.11 +++ swank-loader.lisp 5 Jan 2004 13:24:05 -0000 @@ -66,11 +66,10 @@ (defun user-init-file () "Return the name of the user init file or nil." (let ((home (user-homedir-pathname))) - (and (probe-file home) - (probe-file (format nil - #-mswindows "~A/.swank.lisp" - #+mswindows "~A\\_swank.lsp" - (namestring (truename home))))))) + (when (probe-file home) + (probe-file (merge-pathnames (truename home) + #-mswindows (make-pathname :name ".swank" :type "lisp") + #+mswindows (make-pathname :name "_swank" :type "lsp")))))) (compile-files-if-needed-serially (list* (make-swank-pathname "swank-backend") *swank-pathname* I am not sure whether the part with #-mswindows and #+mswindows is necessary windows at least win2K handles the .swank.lisp without any problems at all. The old version of this function was not working in windows anyway ;) i had to remove the "\\". Ignas Mikalajunas

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 06 Jan '04

06 Jan '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.183 slime/ChangeLog:1.184 --- slime/ChangeLog:1.183 Fri Jan 2 13:24:21 2004 +++ slime/ChangeLog Mon Jan 5 15:51:50 2004 @@ -1,3 +1,43 @@ +2004-01-05 Luke Gorrie <luke(a)bluetail.com> + + * slime.el: Multiple session support, i.e. Emacs can open + multiple connections to Lisps. The guts is there, but + user-interface is currently minimal. + (slime-net-process): Replaced with slime-net-processes. + (slime-net-send): Take process as argument. + (slime-process-available-input): Poll all connections. + (slime-connection): Current connection (process) to use for + talking to Lisp. Can be bound dynamically or buffer-local. + (slime-with-connection-buffer): Macro to enter the process-buffer + of `slime-connection' to manipulate the local variables. + (slime-stack-stack): Now buffer-local in the process-buffer of + each connection. + (slime-push-state, slime-pop-state): Operate on the stack inside + `slime-connection's process-buffer. + (slime-dispatch-event): Take optional process argument, to bind + `slime-connection' appropriately when events arrive from the + network. + (slime-def-connection-var): Macro to define variables that are + "connection-local". Such variables are used via (setf'able) + accessor functions, and their real bindings exist as local + variables in the process-buffers of connections. The accessors + automatically work on `slime-connection'. + (slime-lisp-features, slime-lisp-package, slime-pid, sldb-level): + These variables are now connection-local. + (slime-read-from-minibuffer): Inherit `slime-connection' as + buffer-local so that we complete towards the right Lisp. + (sldb-mode): Inherit `slime-connection' as buffer-local so that we + debug towards the right Lisp. + (get-sldb-buffer): New function to return (optionally create) the + SLDB buffer for the current connection. Since multiple Lisps can + be debugged simultaneously, the buffername now includes the + connection number. + (slime-connection-abort): New command to abort a connection + attempt (don't use `slime-disconnect' anymore - that closes all + connections). + (slime-execute-tests): Honor `slime-test-debug-on-error'. + (slime-next-connection): Cycle through open Lisp connections. + 2004-01-02 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * slime.el (slime-display-output-buffer): Move the output markers @@ -98,6 +138,7 @@ (slime-open-inspector): Minor indentation fixes. (slime-net-output-funcall): Removed. Was unused. +>>>>>>> 1.183 2003-12-19 Alan Ruttenberg <alanralanr(a)comcast.net> * slime.el 1.157 fix bug in sldb-princ-locals I introduced when adding fonts to sldb

1 0

[slime-devel] Beginnings of multiple session support
by Luke Gorrie 05 Jan '04

05 Jan '04

Ahoyhoy, Glad to see you all again in 2004, and what a lovely swag of christmas patches to find under our tree :-) I've checked in basic support for Emacs to have multiple connections to Lisps simultaneously. Today this means you can connect to several Lisps at the same time, and even concurrently debug different programs like Peter described. For the future the plan is to try Gary Byers's idea of using this as the basis of multithreading support. The current user-interface is very minimal, only really usable for testing. `M-x slime-connect' now gives you the option of keeping your existing connections alive. If you have multiple connections, you can cycle your "primary" connection (used for REPL, C-c :, and so on) with `M-x slime-next-connection'. Various buffers, e.g. the debugger, apropos results, etc, are "sticky" -- they will always use the connection that they were created by. Methinks the next step is to allow multiple REPLs and have `M-x slime' support multiple *inferior-lisp*s. For now it's best to wait before trying this out as a user. The purpose of this mail is really to describe what I've done to the code, not to advertise features that actually work well :-) So - down to the code: Previously we had just one "process" (socket), used for everything: (defvar slime-net-process nil "The process (socket) connected to the CL.") But now we have many processes, one of which is in use at a time: (defvar slime-net-processes nil "List of processes (sockets) connected to Lisps.") and (defvar slime-connection nil "Network process currently in use.") `slime-net-processes' is for the low-level networking code to know what connections we have so that we can poll them for input and so on. `slime-connection' is the process that we should actually use to send commands to Lisp. We also recorded information about Lisp in global variables, like: (defvar slime-pid nil "The process id of the Lisp process.") But globals don't cut it with multiple Lisps, so now these become "connection-local variables". These variables are only used via accessor functions, and are really kept as buffer-local variables inside the process-buffer of each connection. For example: (slime-def-connection-var slime-pid nil "The process id of the Lisp process.") Then we can say (slime-pid) to get the value for the current connection (looked up in the process-buffer of `slime-connection' - the currently active connection), and use (setf (slime-pid) ...) to write it. The cute part: because all connection-specific state is in connection-local variables looked up indirectly, to "context-switch" between connections we only have to rebind `slime-connection'. This also means you can make a particular connection "sticky" for commands in a given buffer just by making a buffer-local binding of `slime-connection'. This is done in e.g. SLDB buffers to debug the right Lisp. My current plan is something like: More usable UI. Another round of backend refactoring, to pave the way for - Automatic connection-per-thread multiprocessing support. Other notes/confessions: Each connection has a separate SLDB buffer. All connections share a REPL, but this is possibly wrong and definitely not working right. Cheers, Luke

1 0

[slime-devel] Key sequence C-c C-v ] uses invalid prefix characters.
by Dirk Gerrits 05 Jan '04

05 Jan '04

Hi. I've downloaded SLIME from CVS, edited my .emacs as per the README file, and I can now use SLIME. It's great! :) There is a bit of a nag though. When I type M-x cmulisp RET, I get the error message "Key sequence C-c C-v ] uses invalid prefix characters". Only after typing M-x cmulisp RET the second time will CMUCL actually start. And then I can do M-x slime RET and all is well. I didn't get this behaviour with ILISP, so I think it's SLIME's doing. I thought it might have something to do with my GNU Emacs being a CVS version (21.3.50.2), but it happens in 21.3.1 as well. Also, there was a previous message on this list with a similar error message: http://article.gmane.org/gmane.lisp.slime.devel/227/ I've attached the debug output GNU Emacs generates. Any idea what's going on? BTW, I'm using Debian GNU/Linux unstable with XFree86 4.3.0 and GNOME 2.4, if it makes any difference. (GNU Emacs with Gtk+ 2 support is great. :)) Regards, Dirk Gerrits

2 2

[slime-devel] OpenMCL freezing emacs in slime?
by Peter Seibel 03 Jan '04

03 Jan '04

Sorry for this vague report but I'm mostly just wondering if anyone else has seen this: from time to time my Emacs on OS X (10.3) will just freeze while I'm using slime with OpenMCL. At least once, killing the dppccl process has gotten it unstuck. I'll try to get more details on what causes this but if anyone has any ideas about what's going on or how to gather more information, I'd love to hear them. My OpenMCL is 0.14.mumble and Slime is CVS as of a few days ago. -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

2 1

[slime-devel] swank-clisp, bug report, stream encoding proposal, and a few bugfixes
by sedachv 03 Jan '04

03 Jan '04

Hello, I sent mail to Luke about this a few days ago, but I guess he's busy partying like it's 2003 :) (if not, then please check your common-lisp.net mailbox and disregard it!). Anyway, I've gotten the swank backend mostly working on CLISP. The file is attached. On the way, I've also discovered that the slime state machine generates an error on :read-string (and gives the "you've encountered an error in SLIME" message). This should probably be fixed (and I'm not man enough to do it), as it means that interactive restarts (and probably anything else that does query-io) doesn't work. I also have a proposal stemming from potential problems with the current message-length and character encoding schemes. The stream character encoding should be specified by a slime variable (which defaults to something like "iso-8859-1"), whose value gets passed to a swank function on initialization, which then converts it to internal representation and binds it to a special variable, which is used when opening slime sockets. The message length should then be represented by arabic numerals - the first character in a message is 0-9 and indicated how many (1+) subsequent chars to read to get the message length (giving maximum message length of 10 9s). This is a lot less efficient than the current method, but it'll work with any character encoding scheme supporting arabic numerals (which the ANSI spec says are part of standard characters and so must be provided by every conforming implementation). I propose character encoding should be specified by ASCII strings like "UTF-8", with standard names used so you can just run find-symbol or equivalent on them to get at the encoding object in Lisp and Emacs. Also, here are some patches for things I've changed along the way: In slime.el (the RE doesn't work for CLISP's output, and I belive this type of formatting should be done in swank): *************** *** 3689,3697 **** for (number string) = frame do (let (label framestring) ! (setq label (format "%s" number) ! framestring string) ! (slime-insert-propertized `(frame ,frame) " " (in-sldb-face frame-label label) " " (in-sldb-face frame-line framestring) "\n"))) (let ((number (sldb-previous-frame-number))) --- 3689,3699 ---- for (number string) = frame do (let (label framestring) ! (if (string-match "\\([0-9]*:\\)?\\s *\\(.*\\)" string) ! (setq label (match-string 1 string) ! framestring (match-string 2 string)) ! (setq label "" framestring string)) ! (slime-insert-propertized `(frame ,frame) " " (in-sldb-face frame-label label) " " (in-sldb-face frame-line framestring) "\n"))) (let ((number (sldb-previous-frame-number))) In swank-backend.lisp: *************** *** 134,141 **** (defgeneric call-with-compilation-hooks (func) (:documentation "Call FUNC with hooks to trigger SLDB on compiler errors.")) ! (defmacro with-compilation-hooks ((&rest ignore) &body body) ! (declare (ignore ignore)) `(call-with-compilation-hooks (lambda () (progn ,@body)))) (defgeneric compile-string-for-emacs (string &key buffer position) --- 134,140 ---- (defgeneric call-with-compilation-hooks (func) (:documentation "Call FUNC with hooks to trigger SLDB on compiler errors.")) ! (defmacro with-compilation-hooks (() &body body) `(call-with-compilation-hooks (lambda () (progn ,@body)))) (defgeneric compile-string-for-emacs (string &key buffer position) In swank.lisp (CLISP didn't like the for loop, and neither did I :) *************** *** 434,455 **** (defun eval-region (string &optional package-update-p) "Evaluate STRING and return the result. ! If PACKAGE-UPDATE-P is non-nil, and evaluation causes a package ! change, then send Emacs an update." ! (let ((*package* *buffer-package*) ! form ! (pos 0) ! return-values ! (end-symbol (gensym))) (unwind-protect ! (loop (multiple-value-setq (form pos) ! (read-from-string string nil end-symbol :start pos)) ! (if (eq form end-symbol) ! (return return-values) ! (setq return-values ! (multiple-value-list (eval form))))) (when (and package-update-p (not (eq *package* *buffer-package*))) ! (send-to-emacs (list :new-package (shortest-package-nickname *package*))))))) (defun shortest-package-nickname (package) "Return the shortest nickname (or canonical name) of PACKAGE." --- 434,452 ---- (defun eval-region (string &optional package-update-p) "Evaluate STRING and return the result. ! If PACKAGE-UPDATE-P is non-nil, and evaluation causes a package ! change, then send Emacs an update." ! (let ((*package* *buffer-package*)) (unwind-protect ! (with-input-from-string (stream string) ! (loop for form = (read stream nil stream) ! until (eq form stream) ! for - = form ! for values = (multiple-value-list (eval form)) ! do (force-output) ! finally (return (values values -)))) (when (and package-update-p (not (eq *package* *buffer-package*))) ! (send-to-emacs (list :new-package (shortest-package-nickname *package*))))))) (defun shortest-package-nickname (package) "Return the shortest nickname (or canonical name) of PACKAGE." Happy New Years! Vladimir

3 4