Using SLIME updated to the current CVS in XEmacs 21.4.13 with CLISP 2.33.1 on Cygwin, trying to trace a function (C-c C-t) causes XEmacs to hang. I can interrupt XEmacs with C-g, eliciting the following backtrace:
,---- | Debugger entered--Lisp error: (quit) | accept-process-output(nil 0 10000) | (while t (accept-process-output nil 0 10000)) | (let ((debug-on-quit t) (inhibit-quit nil)) (while t (accept-process-output nil 0 10000))) | (catch tag (slime-rex (tag sexp) (sexp package) (... ... ...) (... ...)) (let (... ...) (while t ...))) | (apply (function funcall) (catch tag (slime-rex ... ... ... ...) (let ... ...))) | (let* ((tag ...) (slime-stack-eval-tags ...)) (apply (function funcall) (catch tag ... ...))) | slime-eval((swank:toggle-trace-fdefinition "sum-nearest")) | (message "%s" (slime-eval (backquote ...))) | (lambda (fname-string) "Toggle trace for FNAME-STRING." (interactive (list ...)) (message "%s" (slime-eval ...)))("sum-nearest") | call-interactively(slime-toggle-trace-fdefinition) `----
The most recent entry in *slime-events* is:
,---- | (:emacs-rex | (swank:toggle-trace-fdefinition "sum-nearest") | nil t 789) `----
After interrupting XEmacs, SLIME is no longer connected to CLISP, though CLISP is still alive and accessible through the *inferior lisp* buffer.
Is this a known problem?
"Steven E. Harris" seh@panix.com writes:
Using SLIME updated to the current CVS in XEmacs 21.4.13 with CLISP 2.33.1 on Cygwin, trying to trace a function (C-c C-t) causes XEmacs to hang.
Not to me but the trace stuff has been changed recently and may require some debugging :-)
Luke Gorrie luke@synap.se writes:
Not to me but the trace stuff has been changed recently and may require some debugging :-)
Let me know if there is specific output you'd like me to capture. I don't have any experience with the SLIME<->swank<->lisp protocols as of yet, but this could be the chance to learn.
Luke Gorrie luke@synap.se writes:
"Steven E. Harris" seh@panix.com writes:
Using SLIME updated to the current CVS in XEmacs 21.4.13 with CLISP 2.33.1 on Cygwin, trying to trace a function (C-c C-t) causes XEmacs to hang.
Not to me but the trace stuff has been changed recently and may require some debugging :-)
And here is some more stuff to debug :-)
I find that the trace behaviour is inconsistent with other slime functionalities regarding its use on empty space.
The slime-edit-definition command, for example, when triggered while the cursor is over some empty space asks the user for the name to edit.
The slime-toggle-trace-fdefinition, on the other hand, just says "No symbol to trace".
I also find this behaviour a bit annoying because, even when I know the name of the function to trace, it forces me to move around in the buffers searching for the correct function definition or function call just to point at it and trace it.
I have a small change to propose that removes the inconsistency:
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.466 diff -r1.466 slime.el 5397,5401c5397,5398 < (cond ((not spec) < (error "No symbol to trace")) < (t < (let ((spec (slime-trace-query spec))) < (message "%s" (slime-eval `(swank:swank-toggle-trace ,spec)))))))) ---
(let ((spec (slime-trace-query spec))) (message "%s" (slime-eval `(swank:swank-toggle-trace ,spec))))))
5406c5403,5405 < (cond ((symbolp spec) ---
(cond ((null spec) (slime-read-from-minibuffer "(Un)trace: ")) ((symbolp spec)
Could any of the slime gurus comment on this?
Best regards,
António Leitão.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
I find that the trace behaviour is inconsistent with other slime functionalities regarding its use on empty space.
The slime-edit-definition command, for example, when triggered while the cursor is over some empty space asks the user for the name to edit.
The slime-toggle-trace-fdefinition, on the other hand, just says "No symbol to trace".
Good stuff, applied.
But please send diffs in unidiff format ('cvs diff -u'). You can also make unidiff the default by putting 'diff -u' in ~/.cvsrc (in case any readers didn't know that).
Cheers, Luke
I found what seems to be two small bugs in the new trace code. I include the patch.
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.467 diff -u -r1.467 slime.el --- slime.el 10 Mar 2005 18:43:58 -0000 1.467 +++ slime.el 11 Mar 2005 00:36:16 -0000 @@ -5412,12 +5412,12 @@ (slime-read-from-minibuffer "(Un)trace: " (prin1-to-string n))) ((:defgeneric n) (let* ((name (prin1-to-string n)) - (answer (slime-read-from-minibuffer "(Un)trace: " n))) + (answer (slime-read-from-minibuffer "(Un)trace: " name))) (cond ((and (string= name answer) (y-or-n-p (concat "(Un)trace also all " "methods implementing " name "? "))) - (prin1-to-string `(:defgeneric ,name))) + (prin1-to-string `(:defgeneric ,n))) (t answer)))) ((:defmethod &rest _) @@ -5480,7 +5480,7 @@ (slime-in-expression-p `(,name))) ;; looks like a regular call (let ((toplevel (ignore-errors (slime-parse-toplevel-form)))) - (cond ((slime-in-expression-p `(setf *)) ;a setf-call + (cond ((slime-in-expression-p `(setf (*))) ;a setf-call (if toplevel `(:call ,toplevel (setf ,name)) `(setf ,name)))
I think that there are also bugs in the allegro trace code. The following patch isn't very well tested but I've been using the patched version in the last few days without problems.
Index: swank-allegro.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-allegro.lisp,v retrieving revision 1.71 diff -u -r1.71 swank-allegro.lisp --- swank-allegro.lisp 4 Mar 2005 23:44:17 -0000 1.71 +++ swank-allegro.lisp 11 Mar 2005 00:42:37 -0000 @@ -690,11 +690,13 @@ ;; <name> can be a normal name or a (setf name)
(defimplementation toggle-trace (spec) - (ecase (car spec) + (ecase (car spec) + ((setf) + (toggle-trace-aux spec)) (:defgeneric (toggle-trace-generic-function-methods (second spec))) ((setf :defmethod :labels :flet) (toggle-trace-aux (process-fspec-for-allegro spec))) - (:call + (:call (destructuring-bind (caller callee) (cdr spec) (toggle-trace-aux callee :inside (list (process-fspec-for-allegro caller))))))) @@ -718,7 +720,7 @@ (dolist (method methods (format nil "~S is now untraced." name)) (excl:funtrace (mop:method-function method)))) (t - (eval `(trace ,name)) + (eval `(trace (,name))) (dolist (method methods (format nil "~S is now traced." name)) (excl:ftrace (mop:method-function method)))))))
Best regards,
António Leitão.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
I found what seems to be two small bugs in the new trace code. I include the patch.
Thanks, both applied.
I think that there are also bugs in the allegro trace code. The following patch isn't very well tested but I've been using the patched version in the last few days without problems.
I don't have Allegro here to test with so hopefully someone will report if tracing is broken there.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
I find that the trace behaviour is inconsistent with other slime functionalities regarding its use on empty space.
The slime-edit-definition command, for example, when triggered while the cursor is over some empty space asks the user for the name to edit.
The slime-toggle-trace-fdefinition, on the other hand, just says "No symbol to trace".
Speaking of which, would it be possible also to make macroexpansion commands prompt for a form when triggered while the cursor is over empty space?
Paolo
Paolo Amoroso amoroso@mclink.it writes:
Speaking of which, would it be possible also to make macroexpansion commands prompt for a form when triggered while the cursor is over empty space?
.. and I wonder if the macroexpand commands should look for a form before the point, like C-x C-e does, instead of after it?
Luke Gorrie luke@synap.se writes:
Paolo Amoroso amoroso@mclink.it writes:
Speaking of which, would it be possible also to make macroexpansion commands prompt for a form when triggered while the cursor is over empty space?
.. and I wonder if the macroexpand commands should look for a form before the point, like C-x C-e does, instead of after it?
... and I wonder if the macroexpand could bind *print-circle* to nil so that the macroexpansion command does not show a sexp full of #n= and #n# that I find harder to understand. OTOH, it allows us to see structure sharing in the code but that doesn't seem to be terribly useful...
António Leitão.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
... and I wonder if the macroexpand could bind *print-circle* to nil so that the macroexpansion command does not show a sexp full of #n= and #n# that I find harder to understand. OTOH, it allows us to see structure sharing in the code but that doesn't seem to be terribly useful...
You can do something like this:
(setf (cdr (assoc '*print-circle* swank:*swank-pprint-bindings*)) nil)
I haven't noticed #n# problems with CMUCL but I don't macroexpand all that often.
Luke Gorrie luke@synap.se writes:
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
... and I wonder if the macroexpand could bind *print-circle* to nil so that the macroexpansion command does not show a sexp full of #n= and #n# that I find harder to understand. OTOH, it allows us to see structure sharing in the code but that doesn't seem to be terribly useful...
You can do something like this:
(setf (cdr (assoc '*print-circle* swank:*swank-pprint-bindings*)) nil)
I haven't noticed #n# problems with CMUCL but I don't macroexpand all that often.
But that would affect all output. I've been using the following patch:
Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.286 diff -u -r1.286 swank.lisp --- swank.lisp 12 Mar 2005 16:02:04 -0000 1.286 +++ swank.lisp 13 Mar 2005 12:24:08 -0000 @@ -2138,7 +2138,9 @@ (defun apply-macro-expander (expander string) (declare (type function expander)) (with-buffer-syntax () - (swank-pprint (list (funcall expander (from-string string)))))) + (let ((*swank-pprint-bindings* + `(,@*swank-pprint-bindings* (*print-circle* . nil)))) + (swank-pprint (list (funcall expander (from-string string)))))))
(defslimefun swank-macroexpand-1 (string) (apply-macro-expander #'macroexpand-1 string))
Given the fact that *swank-pprint-bindings* is an alist, it would be better to just rebind *swank-pprint-bindings* with (acons '*print-circle* 'nil *swank-pprint-bindings*) but that would only work if call-with-bindings reversed the alist before the progv.
António Leitão.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
But that would affect all output. I've been using the following patch:
I introduced a new variable *macroexpand-printer-bindings* instead and print-circle is now nil by default.
Given the fact that *swank-pprint-bindings* is an alist, it would be better to just rebind *swank-pprint-bindings* with (acons '*print-circle* 'nil *swank-pprint-bindings*) but that would only work if call-with-bindings reversed the alist before the progv.
I also reversed the order so that the first element in the alist is bound last. This also means that (push '(var . val) alist) can be used to change a default.
Helmut.
On 10 Mar 2005 20:53:36 +0100, Luke Gorrie luke@synap.se wrote:
.. and I wonder if the macroexpand commands should look for a form before the point, like C-x C-e does, instead of after it?
That would be great. Had to force myself to learn it the other way because I'd never get the right macroexpansion....
"Steven E. Harris" seh@panix.com writes:
Using SLIME updated to the current CVS in XEmacs 21.4.13 with CLISP 2.33.1 on Cygwin, trying to trace a function (C-c C-t) causes XEmacs to hang. I can interrupt XEmacs with C-g, eliciting the following backtrace:
Sounds like Lisp is not responding to the trace request and leaves Emacs to hang. I don't get this problem in CLISP 2.33.2 from Debian.
Is it possible to SIGINT the lisp process in cygwin? With the unix build of CLISP that puts it into the debugger so you can see a backtrace of where it's stuck.
Luke Gorrie luke@synap.se writes:
Is it possible to SIGINT the lisp process in cygwin? With the unix build of CLISP that puts it into the debugger so you can see a backtrace of where it's stuck.
The stack trace isn't all to informative, but this warning from *inferior-lisp* may be:
,---- | ;; Connection to Emacs lost. | ;; [READ from #<INPUT STRING-INPUT-STREAM>: #<PACKAGE SWANK> has no external symbol with name "TOGGLE-TRACE-FDEFINITION"] `----
Actually, I think I just found the problem. I had not reloaded the updated slime.el into my long-running XEmacs instance. Upon reload, tracing works as expected.
Sorry for the noise.
"Steven E. Harris" seh@panix.com writes:
Luke Gorrie luke@synap.se writes:
Is it possible to SIGINT the lisp process in cygwin? With the unix build of CLISP that puts it into the debugger so you can see a backtrace of where it's stuck.
The stack trace isn't all to informative, but this warning from *inferior-lisp* may be:
,---- | ;; Connection to Emacs lost. | ;; [READ from #<INPUT STRING-INPUT-STREAM>: #<PACKAGE SWANK> has no external symbol with name "TOGGLE-TRACE-FDEFINITION"] `----
Actually, I think I just found the problem. I had not reloaded the updated slime.el into my long-running XEmacs instance. Upon reload, tracing works as expected.
Actually this is a useful reminder that we should handle protocol errors more gracefully. This case of the connection breaking if Emacs sends a message that is not understood makes it hard if you want to develop SLIME add-ons - you end up killing your connection if you try to call your Lisp code but forgot to load it first.
Onto the todo list for now.
-
Antonio Menezes Leitao -
Denis Bueno -
Helmut Eller -
Luke Gorrie -
Paolo Amoroso -
Steven E. Harris