I think there is a bug in slime-load-file.
I have noticed that when a file has its *.lisp extension in the parameter to slime-load-file, swank/xref is not able to find its callees (with slime-list-callees).
When called interactively, the extension is stripped and slime-list-callees works. So, shouldn't the extension be stripped by slime-load-file when called non-interactively, as well?
--Jonathan Meeks
Jonathan Meeks jdmmmmm@sbcglobal.net writes:
I think there is a bug in slime-load-file.
I have noticed that when a file has its *.lisp extension in the parameter to slime-load-file, swank/xref is not able to find its callees (with slime-list-callees).
When called interactively, the extension is stripped and slime-list-callees works. So, shouldn't the extension be stripped by slime-load-file when called non-interactively, as well?
Most implementations load the fasl file if the filename has no extension (and if there is a fasl file in the directory). I think the problem you are seen is more related to interpreted functions. When you load the .lisp file, the loaded functions are usually interpreted and not compiled. That's at least the situation for CMUCL.
slime-list-callees currently only works for compiled and byte-compiled functions; interpreted functions are basically ignored. Also CMUCL doesn't record the source location for interpreted functions.
To support slime-list-callees for interpreted functions we probably need to walk the IR code. To record the source location we would need a little change to CMUCL itself. Not sure if interpreted code is important enough for the added complexity.
Helmut.
At Sun, 01 Aug 2004 09:02:13 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
Most implementations load the fasl file if the filename has no extension (and if there is a fasl file in the directory). I think the problem you are seen is more related to interpreted functions. When you load the .lisp file, the loaded functions are usually interpreted and not compiled. That's at least the situation for CMUCL.
slime-list-callees currently only works for compiled and byte-compiled functions; interpreted functions are basically ignored. Also CMUCL doesn't record the source location for interpreted functions.
To support slime-list-callees for interpreted functions we probably need to walk the IR code. To record the source location we would need a little change to CMUCL itself. Not sure if interpreted code is important enough for the added complexity.
Yes, that appears to be the issue.
Would it be worth adding a load/compile/re-xref command from within the lisp-mode buffer? I have my own hacked up elisp for personal use but could generalize it if anyone is interested.
Also, I am not sure if this has been mentioned before, but how difficult would it be to add some sort of specially bound variable that has the output from the last command in the REPL? An comparable example exists in ipython.
--Jonathan
Jonathan Meeks jm@jmeeks.com writes:
Would it be worth adding a load/compile/re-xref command from within the lisp-mode buffer? I have my own hacked up elisp for personal use but could generalize it if anyone is interested.
How is that different from a re-compile with C-c C-k?
Also, I am not sure if this has been mentioned before, but how difficult would it be to add some sort of specially bound variable that has the output from the last command in the REPL? An comparable example exists in ipython.
Depends what you mean with "output". SLIME already sets the variables *, **, and *** to the last three return values; that's not SLIME specific it's CL standard (+,++, +++ and /,//,/// are similar). gdb-like $<n> variables have been discussed, but I think no actual code was written. Remembering the text that is send to the output stream would probably rather messy to implement. Some people have talked about CLIM-like presentation types where objects are presented as clickable text, but it was also considered rather difficult.
Helmut.
-
Helmut Eller -
Jonathan Meeks -
Jonathan Meeks