Glenn Ehrlich <glenn.ehrlich.lists@cox.net> writes:

Helmut,

I've emailed you separately, but thanks for the comments. If no one else thinks it would be useful, I can easily be persuaded to work on something else. I've got a rough design floating around in my head that would use the existing definition support in swank plus some additional functionality from imenu. I looked at the way Franz eli does it and it's sort of similar to the way I was thinking of doing it. I don't think it would be too difficult to implement, but I would like to spend my time working on something that others would find useful. As I said to Helmut, I'm more in the mindset of "I'd like to contribute in ways folks will find useful", rather than "I've got to get feature X into slime".

Just in case people run out of ideas, here are some from my TODO/half baked ideas list: - rename throw-to-toplevel as restart-toplevel - unify compiler warnings buffer with xref buffer - think about :lisp filename in compilation notes - stepper - better handling of segfaulted cmucl - debugger-limit - implement inspector history and use a "path" instead of a stack. - better describe-function. With clickable text that brings you to the source of the function. - better source location handling in sbcl, probably with sb-introspect. - support for redirecting the output of C-x C-e to the current buffer; like Emacs built-in C-x C-e. - support polling of the redirected input stream. - multiple listners (low priority). This should be relatively easy for multi-threaded Lisps but is a bit strange for CLISP and CMUCL. - better scrolling. Ideally similar to term-mode. - implement sldb-show-source for Allegro; at least a bit. - OpenMCL: Make M-. work for functions compiled with C-c C-c. Probably involves setting *loading-file-source-file* in swank-compile-string. Might be similar to the kludge used in swank-lispworks.lisp. - CLISP: produce better backtraces; requires C hacking. Improve source location recording/defintion finding. Perhaps the easiest to fall back to TAGS. - LispWorks: idea to improve sldb-show-source: first READ the toplevel form for the frame then find the location of a form that looks like a call to the callee (the next-frame). LispWorks graphical debugger is somehow able to highliht (/ 1 0) in the following form: (defun foo () (print (/ 1 0))) I wonder how they do it. - implement restart-frame and return-from-frame in CMUCL. The major problem is that CMUCL uses 4 stacks to represent the dynamic environment -- Control Stack, Binding Stack, Eval Stack and Alien Stack (Non x86 have a Number Stack but no Alien stack.) -- but it isn't easy to reconstruct all stack pointers by the debugger. SBCL implements return-from-frame with some relatively inefficient mechanism: every function is rewritten as a (defun ... (...) (catch (make-symbol "SB-CATCH-TAG") ...)) and the debugger searches the tag (with string comparision) in that frame and throws to it. This approach isn't particularly appealing, because it is expensive to allocate a symbol for each call, it's expensive to save the dynamic environment on each call, it infers with tail call optimization, is not "pay as you go". Relatively simple way to avoid allocating a symbol for each catch, is to use a special unwind function. All we need to do is to set the current-catch-block (or whatever) to the target catcher. Throwing will then execute all unwind blocks and skip all catchers event if they have the same catch tag. I think it should be possible to reconstruct the dynamic environment if we safe the spill locations for stack pointers in the debugging info. Stack pointers are saved on the control stack in the following situations: catch, unwind-protect, all sort of NLXs, alien allocations, evaluations, and dynamic lets. It seems that Allegro saves the dynamic binding stack pointer at function entry if the function binds a dynamic variable. This would be quite a robust way to reconstruct the dsp. I don't know all the details needed for an actual implementation, but I assume it would similar to the handling of nfp on the RISC ports. Another problem are the restart entry points and the locations for the arguments for the to be restarted function. This might be very difficult. - test the scalability of the xref fasl dumping. saving callers _and_ callees seems like a redundancy (especially since the compiler only sees callees). think about xref and compile-defun and compile-from-stream. Also think about the usefulness of precise callsite recording, probably only feasible for small projects. Should xref info be attached to function objects? A lot of the stuff is already there in particular callees (and callers can be reconstructed by memory/symbol-groveling). We could add a bitvector indicating which fdefn or symbol in the constant pool is a callee, a referenced/set/used variable ... How useful is this xref stuff anyway? Isn't grep good enough? The interesting/hard cases like indirect calls to function objects stored in tables aren't covered by xref. Should we record where a function escapes? Again, funcalling symbols will not be covered. - Zmacs and ELI have a concept of "changed definitions". Sounds difficult to implement in the presence of toplevel macros and eval-when. perhaps we could deal with toplevel forms insteaod of definitions? or some shortcut like forms starting in the first column with "(def". Worth to bother? http://bitsavers.org/pdf/ti/explorer/2243192-0001A_Zmacs_Jun87.pdf - enhance the disassembler so that we can find the code location of references to fdefn objects and use that as approximation for the call-site. [difficult]

The way it works in LispWorks is exactly the same way it works on the Lisp Machine, same keystroke bindings, too, I think. Basically, meta shift e evaluates all changed definitions in the current buffer (yes, I know that emacs doesn't recognize the shift modifier, but zmacs does) and meta shift c compiles the changed defintions in the current buffer. There's similar commands for doing the same for all buffers, but they aren't bound to any keystrokes. The definition of changed is roughly "edited since last sent to Lisp".

And what's the definition of "definition"? Helmut.