Another one:
I'm using latest CVS slime + Lispworks on Linux.
If I compile and load my system from scratch, I can use M-. to jump around function definitions. but if I go to a function, hit C-c C-c to recompile the function, jump to a different emacs buffer and try M-. on the newly compiled function, I now get:
make-single-line (:error The file #P"/tmp/filecLlfIH.lisp" does not exist.) (:location (:file /home/kooks/XOS/Bullseye/src/Common/generic-utilities.lisp) (:function-name MAKE-SINGLE-LINE))
in the *XREF buffer.
Cheers,
Alain.Picard@memetrics.com writes:
If I compile and load my system from scratch, I can use M-. to jump around function definitions. but if I go to a function, hit C-c C-c to recompile the function, jump to a different emacs buffer and try M-. on the newly compiled function, I now get:
make-single-line (:error The file #P"/tmp/filecLlfIH.lisp" does not exist.) (:location (:file /home/kooks/XOS/Bullseye/src/Common/generic-utilities.lisp) (:function-name MAKE-SINGLE-LINE))
in the *XREF buffer.
This is not easy to fix. For C-c C-c we write the text of the function to a temporary file, compile and load it and remove the file afterwards. This means Lispworks records the wrong source location for the function. See swank:compile-string-for-emacs.
CMUCL has an extension ext:compile-from-stream which allows us to attach our custom source info. M-. in CMUCL works nicely in combination with C-c C-c.
I'm sure Lispworks has something similar, but I couldn't find it in the documentation. Patches welcome :-)
Helmut.
make-single-line (:error The file #P"/tmp/filecLlfIH.lisp" does not exist.) (:location (:file /home/kooks/XOS/Bullseye/src/Common/generic-utilities.lisp) (:function-name MAKE-SINGLE-LINE))
if swank-openmcl knows that the file doesn't exist, is there any reason to add it to the list of locations?
it there is one, M-. should probably pick the obvious choice if there is only one non-error location.
the patch below implements the first.
...bryan
Index: swank-openmcl.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-openmcl.lisp,v retrieving revision 1.64 diff -u -r1.64 swank-openmcl.lisp --- swank-openmcl.lisp 24 Feb 2004 23:31:34 -0000 1.64 +++ swank-openmcl.lisp 26 Feb 2004 18:02:15 -0000 @@ -390,8 +390,7 @@ (labels ((frob (pathname position) (multiple-value-bind (truename c) (ignore-errors (truename pathname)) - (cond (c - (push (list :error (princ-to-string c)) locations)) + (cond (c nil) (t (push (make-location (list :file (namestring truename)) position)
"bryan o'connor" bryan-slime@lunch.org writes:
make-single-line (:error The file #P"/tmp/filecLlfIH.lisp" does not exist.) (:location (:file /home/kooks/XOS/Bullseye/src/Common/generic-utilities.lisp) (:function-name MAKE-SINGLE-LINE))
if swank-openmcl knows that the file doesn't exist, is there any reason to add it to the list of locations?
The only reason I can think of, is this: when people see obvious shortcomings, they seem to be more motivated to invent a proper solution for the problem.
Thinking about it, could we use the temporary filename to patch the recorded source info? IIUC, OpenMCL records the source location in the hashtable %source-files%. The idea is that swank:compile-string-for-emacs replaces all entries for the temporary file with something like (:emacs-buffer <buffer-name>).
Is this approach too naive?
Helmut.
Helmut Eller writes:
Alain.Picard@memetrics.com writes:
make-single-line (:error The file #P"/tmp/filecLlfIH.lisp" does not exist.) (:location (:file /home/kooks/XOS/Bullseye/src/Common/generic-utilities.lisp) (:function-name MAKE-SINGLE-LINE))
in the *XREF buffer.
This is not easy to fix. For C-c C-c we write the text of the function to a temporary file, compile and load it and remove the file afterwards. This means Lispworks records the wrong source location for the function. See swank:compile-string-for-emacs.
I'm sure Lispworks has something similar, but I couldn't find it in the documentation. Patches welcome :-)
I've been reading the DSPEC manual; there seems to be something called:
at-location Macro Summary
Tells the dspec system of the source location. Package
dspec Signature
at-location ( location ) &body body => result Arguments
location
A pathname or a keyword.
body
Forms, including defining forms. Values
result
The result of body . Description
The macro at-location informs the dspec system that the source for definitions done during the execution of body are at the location location .
location is usually a pathname, for definitions occuring in a file or editor buffer with that pathname.
I'm wondering (off the top of my head) if it would work to wrap the form being compiled into a (at-location (path which slime/emacs knows we got this form from) from)
?
Alain.Picard@memetrics.com writes:
I'm wondering (off the top of my head) if it would work to wrap the form being compiled into a (at-location (path which slime/emacs knows we got this form from) from)
?
This doesn't seem to work:
(dspec:at-location (:emacs-buffer) (defun foo ())) (dspec:name-definition-locations '(function) 'foo)
Returns nothing particularly useful.
In newest version, I tried to patch the recorded source info, basically by groveling through the hashtable returned by
(dspec::dc-database (dspec::find-dc 'function))
This seems to work a bit better. Some problems are:
- you get multiple entries in the table if the function is compiled multiple times.
- only the function database is patched, defclass and others are left alone.
- the Lispworks editor may get confused by the emacs buffer entries.
Let's see how it works.
Helmut.
Helmut Eller writes:
Alain.Picard@memetrics.com writes:
I'm wondering (off the top of my head) if it would work to wrap the form being compiled into a (at-location (path which slime/emacs knows we got this form from) from)
?
This doesn't seem to work:
(dspec:at-location (:emacs-buffer) (defun foo ())) (dspec:name-definition-locations '(function) 'foo)
Returns nothing particularly useful.
Yeah, I noticed. :-(
In newest version, I tried to patch the recorded source info, basically by groveling through the hashtable returned by
SNIP
Let's see how it works.
I'll give it a bash.
On a somewhat tangential topic; I have a support contract with Xanalys, and have a number of "incident reports" which are of the "use 'em or lose 'em" nature. I would be willing to spend 1 or 2 of them on issues related to getting slime better integrated with Lispworks.
If you (or anyone else) can specify to me _exactly_ what would be neat/required to get some missing features implemented, I could see what I could do about getting some patches and/or code from Xanalys.
Since I don't have much time to actually code for SLIME, you can consider this my modest contribution. :-)
BTW--- THANK YOU to you and all other uber-cool slime developers. In just a few months, it's turned into a very pleasant developing environment.
--ap
Alain.Picard@memetrics.com writes:
This doesn't seem to work:
(dspec:at-location (:emacs-buffer) (defun foo ())) (dspec:name-definition-locations '(function) 'foo)
Returns nothing particularly useful.
Yeah, I noticed. :-(
I figured out how at-location is supposed to be used:
(dspec:at-location (:emacs-buffer) (funcall (compile nil (lambda () (defun foo ()))))) (dspec:name-definition-locations '(function) 'foo) => (((defun foo) :emacs-buffer))
The macroexpansion of at-location reveals that dspec::*location* is the interesting variable. dspec:location is probably a compiler-macro that expands to the compile-time value of dspec::*location*.
I patched compile-string-for-emacs again and set dspec::*location directly. Seems to work quite nicely.
On a somewhat tangential topic; I have a support contract with Xanalys, and have a number of "incident reports" which are of the "use 'em or lose 'em" nature. I would be willing to spend 1 or 2 of them on issues related to getting slime better integrated with Lispworks.
That would be very useful.
If you (or anyone else) can specify to me _exactly_ what would be neat/required to get some missing features implemented, I could see what I could do about getting some patches and/or code from Xanalys.
I think a nice feature would be a function to get the precise position of dspecs in a stream. Currently we use some regexp kludges in Emacs for that. This fails sometimes and can't work if the definition is generated by a macro. I imagine a function like:
(dspec-stream-position DSPEC STREAM) => CHARACTER-OFFSET
DSPEC can be any dspec returned by NAME-DEFINED-DSPECS or by the compiler. In particular, the function should return reasonable values for stuff like (LW:TOP-LEVEL-FORM 16), for dspecs for local functions (from FLET or LABELS) and functions generated by macros (e.g., DEFSTRUCT or user defined macros).
It would also be useful if someone from Xanalys could have a look at swank-lispworks.lisp and document/export the internal symbols we use there, or tell us what we should use instead.
Since I don't have much time to actually code for SLIME, you can consider this my modest contribution. :-)
Thank you. Your bug reports where also very useful.
BTW--- THANK YOU to you and all other uber-cool slime developers. In just a few months, it's turned into a very pleasant developing environment.
Glad to hear.
Helmut.
-
Alain.Picard＠memetrics.com -
bryan o'connor -
Helmut Eller