Hi,
AFAICS, slime can only select symbols for trace. This has several problems and limitations.
The first problem is that tracing setf-definitions such as
(setf foo)
and/or more complex definitions such as
(method foo (bar baz))
can only be done by writing the extended name on the '(Un)trace: ' line.
A more serious problem is that is impossible to untrace such definitions via slime. This happens because slime (or more properly, swank) identifies traced functions using eql (in the tracep predicate). Obviously, this is trivial to solve but I think that it is possible to improve this situation a lot.
I extended slime trace in a way that (I hope) makes it more helpful.
The idea is to identify the context of the symbol being traced. Here are a few examples (the '|' shows the cursor) with the intended meaning of the trace/untrace command:
(defun fo|o (a) -> (trace foo) ...)
(defun (setf fo|o) (a b) -> (trace (setf foo)) ...)
(defgeneric b|ar (a b)) -> (trace bar) and, possibly, all its methods
(defmethod b|ar ((a cons) (b cons)) -> (trace (method bar (cons cons))) ...)
(defun deep (x) -> (trace deeper) but, possibly, only when (de|eper ...)) called from deep
(defun myfunc (a b c) -> (trace (labels myfunc squareit)) (labels ((squar|eit (arg) ...)) ...))
(defmethod bax ((a foo) b c) -> (trace (labels (method bax (foo t t)) squareit)) (labels ((squar|eit (arg) ...)) ...))
The flet case is identical to the labels case.
...(fo|o ...)... -> (trace foo)
(setf ... ... (fo|o ...) ... -> (trace (setf foo)) ... ...)
In all other situations, the trace/untrace works just like in current slime.
Obviously, not everything can work in every CL. Also, the specific trace commands depend on the CL we are using. This, I think, should not stop us from using it (and strongly encourage CL implementors to provide the missing bits).
I implemented all of the above for Allegro 7.0 (everything works except the last due to one Allegro bug), SBCL (everything except local functions) and CMUCL (everything except local functions). People who use/implement other CLs might want to provide swank implementations for those CLs.
If you're interested, here's the patch:
BTW, it also includes two small changes to allow the CL process to comunicate with the Emacs process. They are not needed for trace but are useful for refactoring operations that I'm implementing in Slime.
Any comments/corrections/improvements are very welcome.
Best regards,
António Leitão.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
Obviously, not everything can work in every CL. Also, the specific trace commands depend on the CL we are using. This, I think, should not stop us from using it (and strongly encourage CL implementors to provide the missing bits).
unfortunetly it's not so simple, getting the "vendors" to implement it is hard enough (time being the scarce reource that it is), getting users to upgrade is even more difficult. i think it's important that this degrade gracefully on lisps where the support doesn't exist (i'll provide such support for openmcl). if nothing else the default implementations should trace the outer function (sans setf) as trace currently does.
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
BTW, it also includes two small changes to allow the CL process to comunicate with the Emacs process. They are not needed for trace but are useful for refactoring operations that I'm implementing in Slime.
Any comments/corrections/improvements are very welcome.
I haven't tried your tracing improvements, but they sound like a really good idea.
BTW, I didn't know anyone was actively working on a refactoring browser for SLIME. How's your progress?
Kind regards,
Dirk Gerrits
Dirk Gerrits dirk@dirkgerrits.com writes:
Antonio Menezes Leitao aml@gia.ist.utl.pt writes:
BTW, it also includes two small changes to allow the CL process to comunicate with the Emacs process. They are not needed for trace but are useful for refactoring operations that I'm implementing in Slime.
Any comments/corrections/improvements are very welcome.
I haven't tried your tracing improvements, but they sound like a really good idea.
BTW, I didn't know anyone was actively working on a refactoring browser for SLIME. How's your progress?
Most of the stuff that I had a few years ago with eli + allegro is now running in Slime + whatever CL I'm using. Some of the refactoring operations need more work. I'll spend a few more weeks working with it (while I'm finishing a project) and then I'll try to provide a patch. But don't expect anything special. They are very simple and are mostly helpful for dealing with legacy code.
Best regards,
António Leitão.