Howdyo,
Feels good to be hacking again :-)
Helmut, list-callers is great! The inspector too!
This backend integration is groovy too.
I've been hacking on the Elisp source-path support a bit more just now. It turns out backquote is really hard (see ChangeLog for details). We probably should push resolving source-paths into Lisp to use their reader for compiler notes too. Maybe `forward-source-path's days are numbered?
Also hacked the batch-mode test suite a bit. There's a little 'test.sh' in CVS for running it. I drive it with different lisp/emacs versions with this script:
#!/bin/bash
tester="/home/luke/hacking/slime/test.sh" emacsen="emacs21 emacs20" lispen="sbcl-cvs cmucl-snapshot cmucl-cvs"
echo "(Removing old output.)" rm *.dribble* *.results* &>/dev/null
for emacs in $emacsen; do for lisp in $lispen; do tag=${emacs}_${lisp} echo -en "Testing $tag:\t" $tester $emacs $lisp $tag.dribble $tag.results && echo "passed." done done
which then prints output like:
$ ./slime-test.sh (Removing old output.) Testing emacs21_sbcl-cvs: 6 test(s) failed. Testing emacs21_cmucl-snapshot: 1 test(s) failed. Testing emacs21_cmucl-cvs: 1 test(s) failed. Testing emacs20_sbcl-cvs: 6 test(s) failed. Testing emacs20_cmucl-snapshot: 1 test(s) failed. Testing emacs20_cmucl-cvs: 1 test(s) failed.
The details/results and dribble output are saved in files.
One test they all failed is placing a compiler note inside a backquote. The extra failed SBCL cases are on tests where we currently assume we're looking things up in CMUCL's codebase.
Cheers, Luke
Luke Gorrie luke@bluetail.com writes:
Howdyo,
Feels good to be hacking again :-)
Helmut, list-callers is great! The inspector too!
What do you think about the window for selecting a caller? I had some trouble to figure out how to reuse the xref window, so I came up with my own, and tried to imitate the w3m-select-buffer window. Should I switch to the xref window?
This backend integration is groovy too.
I've been hacking on the Elisp source-path support a bit more just now. It turns out backquote is really hard (see ChangeLog for details). We probably should push resolving source-paths into Lisp to use their reader for compiler notes too. Maybe `forward-source-path's days are numbered?
Yes, I think that would be good. At least worth at try. Would it be efficient enough to send the entire buffer as a string to Lisp and resolve the source path there? Or should we drop source paths entirely and only send buffer offsets across the wire? It's a bit difficult for compiler notes, because we don't want to slow down compilation, but we need the buffer offsets for the annotations immediately after the compilation. Perhaps we could do the annotation and source path resolution lazily, only when M-n or M-p are pressed.
Also hacked the batch-mode test suite a bit. There's a little 'test.sh' in CVS for running it. I drive it with different lisp/emacs versions with this script:
The script works great for Emacs. XEmacs crashes in batch mode, but works fine interactively.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
What do you think about the window for selecting a caller? I had some trouble to figure out how to reuse the xref window,
My data structure is a bit funky. I'll change it to use a property list and make the filename optional.
so I came up with my own, and tried to imitate the w3m-select-buffer window. Should I switch to the xref window?
Dunno - I think your window looks cool, but it doesn't fit my personal window-management scheme (not enough frame width). For people who use wider windows it might be ideal, so perhaps we could have a configurable to use either scheme for both xref and list-callers.
Would it be efficient enough to send the entire buffer as a string to Lisp and resolve the source path there? Or should we drop source paths entirely and only send buffer offsets across the wire? It's a bit difficult for compiler notes, because we don't want to slow down compilation, but we need the buffer offsets for the annotations immediately after the compilation. Perhaps we could do the annotation and source path resolution lazily, only when M-n or M-p are pressed.
I have no real answers :-). It might even be hard to handle source-paths correctly in Lisp code. We're using "(read-delimited-list #( ...)" currently and I don't think it will handle this awkwardness with ,@ in backquotes. Really it seems you need to use a full READ and then break out at a certain point in the call graph -- at least, I think source-paths really are recording a point in the READ call graph rather than something more "lexical".
Also hacked the batch-mode test suite a bit. There's a little 'test.sh' in CVS for running it. I drive it with different lisp/emacs versions with this script:
The script works great for Emacs. XEmacs crashes in batch mode, but works fine interactively.
The workaround to test xemacs is batch-mode is to use -nw instead of --batch. Since output goes to a file it runs non-interactively, but the contents of the dribble file are pretty useless (lots of screen-positioning codes :-)
I hacked the script to handle total crashes better.
Cheers, Luke
-
Helmut Eller -
Luke Gorrie