Index: slime/ChangeLog diff -u slime/ChangeLog:1.1928 slime/ChangeLog:1.1934 --- slime/ChangeLog:1.1928 Mon Dec 7 00:55:37 2009 +++ slime/ChangeLog Thu Dec 10 22:37:17 2009 @@ -1,3 +1,69 @@ +2009-12-11 Stas Boukarev stassats@gmail.com + + * swank-allegro.lisp: Use new function `make-error-location'. + (find-fspec-location): Handle errors. + Patch by Tobias C. Rittweiler. + +2009-12-11 Tobias C. Rittweiler tcr@freebits.de + + Add `M-x slime-toggle-debug-on-swank-error'. + + In "Debug on SWANK error" mode, errors which are normally caught + to not annoy the user, will now drop into the debugger. + + Additionally, the backend won't do any backtrace magic so you'll + see the full backtrace with all its glory details. (SBCL only so + far.) + + * slime.el (slime-toggle-debug-on-swank-error): New. + + * swank.lisp (toggle-debug-on-swank-error): New slimefun. + (debug-on-swank-error): New function. SETFable. + (invoke-default-debugger): Use CALL-WITH-DEBUGGER-HOOK so we're + trapped into the native debugger on SBCL (previously we weren't + due to SB-EXT:*INVOKE-DEBUGGER-HOOK*.) + + * swank.lisp: Rename SWANK-ERROR to SWANK-PROTOCOL-ERROR. + +2009-12-11 Tobias C. Rittweiler tcr@freebits.de + + * swank-sbcl.lisp (call-with-debugger-hook): Oops, removed the + binding for *DEBUGGER-HOOK*. Fix that. + (make-invoke-debugger-hook): Do nothing if hook is NIL. + +2009-12-10 Tobias C. Rittweiler tcr@freebits.de + + * swank-backend.lisp (*debug-swank-backend*): New variable. If + true, backends should not catch internal errors (e.g. during + definition finding), and should not perform backtrace magic. + (make-error-location): New helper. + (find-definitions [interface]): Default to error location. + + * swank-sbcl.lisp (converting-errors-to-location): New helper + macro. Regards new *DEBUG-SWANK-BACKEND*. + (find-definitions [implementation]): Use it. + (find-source-location [implementation]): Ditto. + (functiond-spec): Ditto. + (frame-source-location [implementation]): Ditto. + (*debug-definition-finding*): Removed. + (make-source-location-specification): Removed. + (safe-function-source-location): Removed. + (safe-source-location-for-emacs): Removed. Not needed anymore. + + (call-with-debugging-environment): Do not perform stack hinting + depending on *DEBUG-SWANK-BACKEND*. + +2009-12-10 Tobias C. Rittweiler tcr@freebits.de + + * swank-sbcl.lisp (set-break-hook): New. + (call-with-break-hook): New, too. Both extracted from elsewhere. + (install-debugger-globally, call-with-debugger-hook): Use them. + (make-invoke-debugger-hook): Adapted not to call *debugger-hook* + on its own; it should rather decline because *debugger-hook* is + tried after *invoke-debugger-hook* anyway. Previously, a + custom *debugger-hook* (which declines itself) would have been + executed twice. + 2009-12-07 Stas Boukarev stassats@gmail.com
* slime.el (slime-parse-toplevel-form): Use Index: slime/contrib/ChangeLog diff -u slime/contrib/ChangeLog:1.296 slime/contrib/ChangeLog:1.300 --- slime/contrib/ChangeLog:1.296 Thu Dec 3 20:15:22 2009 +++ slime/contrib/ChangeLog Fri Dec 11 01:35:20 2009 @@ -1,3 +1,34 @@ +2009-12-11 Stas Boukarev stassats@gmail.com + + * slime-fuzzy.el (slime-fuzzy-choices-buffer): Don't + show cursor in *Fuzzy Completions*. + Patch by Tobias C. Rittweiler. + +2009-12-11 Stas Boukarev stassats@gmail.com + + * slime-presentations.el (slime-reify-old-output): Quote + the CL expession behind presentations, so _(1 2 3)_ (representing a + presentation) is not tried to be evaluated. + (slime-copy-presentation-to-repl): Use `looking-back' for looking back. + Apply De Morgan's law to conditions. + Patch by Tobias C. Rittweiler. + +2009-12-11 Stas Boukarev stassats@gmail.com + + * swank-asdf.lisp (find-operation): New function for + finding asdf operations independent of readtable + case sensitivity (read Allegro Modern Mode). + (operate-on-system): Accept symbols instead of strings for + operation-name, and use the above function. + + * slime-asdf.el: Replace strings with operation names + for `slime-oos' with symbols. + +2009-12-11 Tobias C. Rittweiler tcr@freebits.de + + * swank-arglists.lisp (*swank-debug-arglists*): Removed. + (arglist-for-echo-area): Use DEBUG-ON-SWANK-ERROR instead. + 2009-12-04 Stas Boukarev stassats@gmail.com
* swank-arglists.lisp (find-subform-with-arglist): Return
On Fri, Dec 11, 2009 at 12:33 AM, Helmut Eller heller@common-lisp.net wrote
Index: slime/ChangeLog +2009-12-11 Stas Boukarev stassats@gmail.com
- * slime-presentations.el (slime-reify-old-output): Quote
- the CL expession behind presentations, so _(1 2 3)_ (representing a
- presentation) is not tried to be evaluated.
[...]
- Patch by Tobias C. Rittweiler.
I do not agree with this change. It causes breakage when presentations are used within quoted lists, for instance.
CL-USER> (find-class 'standard-object) #<STANDARD-CLASS STANDARD-OBJECT> CL-USER> '(1 2 #<STANDARD-CLASS STANDARD-OBJECT> 3 4) (1 2 '#<STANDARD-CLASS STANDARD-OBJECT> 3 4) CL-USER>
Best, Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
On Fri, Dec 11, 2009 at 12:33 AM, Helmut Eller heller@common-lisp.net wrote
Index: slime/ChangeLog +2009-12-11 Stas Boukarev stassats@gmail.com
- * slime-presentations.el (slime-reify-old-output): Quote
- the CL expession behind presentations, so _(1 2 3)_ (representing a
- presentation) is not tried to be evaluated.
[...]
- Patch by Tobias C. Rittweiler.
I do not agree with this change. It causes breakage when presentations are used within quoted lists, for instance.
CL-USER> (find-class 'standard-object) #<STANDARD-CLASS STANDARD-OBJECT> CL-USER> '(1 2 #<STANDARD-CLASS STANDARD-OBJECT> 3 4) (1 2 '#<STANDARD-CLASS STANDARD-OBJECT> 3 4) CL-USER>
Can you think of a way to make it work for either case? Evaluating lists-as-presentations is annoying.
-T.
On Fri, Dec 11, 2009 at 11:58 AM, Tobias C. Rittweiler tcr@freebits.de wrote:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
On Fri, Dec 11, 2009 at 12:33 AM, Helmut Eller heller@common-lisp.net wrote
Index: slime/ChangeLog +2009-12-11 Stas Boukarev stassats@gmail.com
- * slime-presentations.el (slime-reify-old-output): Quote
- the CL expession behind presentations, so _(1 2 3)_ (representing a
- presentation) is not tried to be evaluated.
[...]
- Patch by Tobias C. Rittweiler.
I do not agree with this change. It causes breakage when presentations are used within quoted lists, for instance.
CL-USER> (find-class 'standard-object) #<STANDARD-CLASS STANDARD-OBJECT> CL-USER> '(1 2 #<STANDARD-CLASS STANDARD-OBJECT> 3 4) (1 2 '#<STANDARD-CLASS STANDARD-OBJECT> 3 4) CL-USER>
Can you think of a way to make it work for either case? Evaluating lists-as-presentations is annoying.
Unfortunately not, though I have been thinking about this since 2006 (well, OK, not every day!), when we discussed this issue first on this list.
Definitely not on the level of presentation reification, but see below.
I think this is basically just something for the documentation. "Remember, standard quoting rules still apply." and show the example with lists.
Here are two reasons why the non-quoting behavior should be considered a design feature actually.
* Presentations sometimes just go away (when the objects are no longer stored) and revert to plain text. It would be very unfortunate if the semantics magically changed in these situations from unevaluated to evaluated.
* Presentations right now only *extend* the behavior of the reader, they don't change the reader syntax. Only some otherwise unreadable objects are made "readable" by presentations; some objects are reused (keeping the same identity) rather than being recreated.
That said, it may be useful to experiment with a heuristic on the level of *pasting* the presentations in editor commands such as slime-copy-presentation-at-point-to-repl. Basically, try to find out (1) whether the current context at the insertion is evaluated, (2) whether the object is a list; only then insert a ' in front of the pasted presentation. Because this is transparent to the user, it can always be corrected by the user. Of course, this creates a difference between dedicated presentation pasting commands and ordinary kill&yank commands (which, as you know, work just fine for text containing presentations). So this adds some complexity, which is why I am not sure it will pay off...
Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Can you think of a way to make it work for either case? Evaluating lists-as-presentations is annoying.
Unfortunately not, though I have been thinking about this since 2006 (well, OK, not every day!), when we discussed this issue first on this list.
I think we found a case for *EVALHOOK*.
The Slime repl evaluator would have to be advised about which objects came from presentations; in the evalhook, it'd test if the arg is same to such an object -- if it is, it'd not evaluate that object.
The advising part would probably be a bit involving because we'd have to guarantee EQness.
I'm almost tempted to hack in *EVALHOOK* into SBCL's interpreter... ;-)
-T.
On Fri, Dec 11, 2009 at 1:02 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Can you think of a way to make it work for either case? Evaluating lists-as-presentations is annoying.
Unfortunately not, though I have been thinking about this since 2006 (well, OK, not every day!), when we discussed this issue first on this list.
I think we found a case for *EVALHOOK*. [...]
Ouch, please don't.
Here's a completely different direction how to spend hacking energy on SLIME. I'd love to have a version of slime-eval-last-expression that works as well as the REPL for long-running computations, asynchronously inserting the output of the process into the buffer at this point. This would make slime-scratch much more useful. It could look like this over the course of the computation:
(long-computation) C-x C-e
(long-computation) #<still-computing...>
(long-computation) Some output #<still-computing...>
(long-computation) Some output More output #<still-computing...>
(long-computation) Some output More output Result
Of course, several computations (maybe even in different Lisp processes) would be allowed to be active at the same time in different parts of the buffer. And it should work with presentations.
Matthias
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Here's a completely different direction how to spend hacking energy on SLIME. I'd love to have a version of slime-eval-last-expression that works as well as the REPL for long-running computations, asynchronously inserting the output of the process into the buffer at this point. This would make slime-scratch much more useful. It could look like this over the course of the computation:
(long-computation) C-x C-e
(long-computation) #<still-computing...>
(long-computation) Some output #<still-computing...>
(long-computation) Some output More output #<still-computing...>
(long-computation) Some output More output Result
Of course, several computations (maybe even in different Lisp processes) would be allowed to be active at the same time in different parts of the buffer. And it should work with presentations.
Sure, would be nice. Would even be nicer if slime-repl gets cleaned up on the way.
A way that better matches existing infrastructure would be to have a function (SWANK:EMACS-BUFFER-STREAM "*FOOF*") which returns a stream that sends output into an emacs buffer. IIRC, you can almost have that today.
-T.
On Sat, Dec 12, 2009 at 12:04 AM, Tobias C. Rittweiler tcr@freebits.de wrote:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
I'd love to have a version of slime-eval-last-expression that works as well as the REPL for long-running computations, asynchronously inserting the output of the process into the buffer at this point. This would make slime-scratch much more useful. It could look like this over the course of the computation:
(long-computation) C-x C-e
(long-computation) #<still-computing...>
(long-computation) Some output #<still-computing...>
(long-computation) Some output More output #<still-computing...>
(long-computation) Some output More output Result
Of course, several computations (maybe even in different Lisp processes) would be allowed to be active at the same time in different parts of the buffer. And it should work with presentations.
Sure, would be nice. Would even be nicer if slime-repl gets cleaned up on the way.
A way that better matches existing infrastructure would be to have a function (SWANK:EMACS-BUFFER-STREAM "*FOOF*") which returns a stream that sends output into an emacs buffer. IIRC, you can almost have that today.
Yes, that's what the target argument in :write-string and the hash table slime-output-target-to-marker are for. slime-redirect-trace-output is implemented like this.
So to implement what I describe one basically just needs to put markers at the right places in the buffer and create corresponding streams (for output & result) with make-output-stream-for-target.
Matthias
-
Helmut Eller -
Matthias Koeppe -
Tobias C. Rittweiler