Six swank back-ends implement the RESTART-FRAME interface. Yet only two of these back-ends implements FRAME-RESTARTABLE-P, which is used by the BACKTRACE slimefun to identify whether a frame is restartable.
Allegro and SBCL implement both restart-frame and frame-restartable- p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
For consistency, perhaps back-ends that implement restart-frame also could implement frame-restartable-p?
-- Terje Norderhaug terje@in-progress.com
* Terje Norderhaug [2010-03-21 20:39+0100] writes:
Six swank back-ends implement the RESTART-FRAME interface. Yet only two of these back-ends implements FRAME-RESTARTABLE-P, which is used by the BACKTRACE slimefun to identify whether a frame is restartable.
Allegro and SBCL implement both restart-frame and frame-restartable- p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
ABCL doesn't support it; the code is just a comment. CCL only on PPC. CLISP or LispWorks have no documented debugger API and without knowing the internals it's hard to say anything other than "may or may not work".
For consistency, perhaps back-ends that implement restart-frame also could implement frame-restartable-p?
They can but it shouldn't be required. The default implementation seems good enough to me.
Helmut
On Mar 22, 2010, at 6:54 AM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-21 20:39+0100] writes:
Six swank back-ends implement the RESTART-FRAME interface. Yet only two of these back-ends implements FRAME-RESTARTABLE-P, which is used by the BACKTRACE slimefun to identify whether a frame is restartable.
Allegro and SBCL implement both restart-frame and frame-restartable- p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
ABCL doesn't support it; the code is just a comment. CCL only on PPC. CLISP or LispWorks have no documented debugger API and without knowing the internals it's hard to say anything other than "may or may not work".
Hence there are really three answers to the question of whether a frame is restartable: "yes", "no" and "maybe". Yet the BACKTRACE slimefun only allows FRAME-RESTARTABLE-P to return T or NIL:
(ecase (frame-restartable-p frame) ((nil) nil) ((t) `((:restartable t))))
I suggest BACKTRACE passes on the "maybe" semantics to the client, for example by returning the :restartable if and only if it definitely can be determined whether or not a frame is restartable. As in:
(ecase (frame-restartable-p frame) ((nil) `((:restartable nil))) ((t) `((:restartable t))) (:maybe nil))
For consistency, perhaps back-ends that implement restart-frame also could implement frame-restartable-p?
They can but it shouldn't be required. The default implementation seems good enough to me.
The default implementation of frame-restartable-p always returns NIL, even for back-ends that implement restart-frame. The consequence is that swank clients are unable to determine whether a frame definitely cannot be restarted or whether the frame might be restarted.
This has usability implications as swank clients cannot adapt to whether a frame certainly is restartable, might possibly be restartable, or definitely isn't restartable.
-- Terje Norderhaug terje@in-progress.com
* Terje Norderhaug [2010-03-22 18:20+0100] writes:
On Mar 22, 2010, at 6:54 AM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-21 20:39+0100] writes:
Six swank back-ends implement the RESTART-FRAME interface. Yet only two of these back-ends implements FRAME-RESTARTABLE-P, which is used by the BACKTRACE slimefun to identify whether a frame is restartable.
Allegro and SBCL implement both restart-frame and frame-restartable- p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
ABCL doesn't support it; the code is just a comment. CCL only on PPC. CLISP or LispWorks have no documented debugger API and without knowing the internals it's hard to say anything other than "may or may not work".
Hence there are really three answers to the question of whether a frame is restartable: "yes", "no" and "maybe". Yet the BACKTRACE slimefun only allows FRAME-RESTARTABLE-P to return T or NIL:
(ecase (frame-restartable-p frame) ((nil) nil) ((t) `((:restartable t))))
I suggest BACKTRACE passes on the "maybe" semantics to the client, for example by returning the :restartable if and only if it definitely can be determined whether or not a frame is restartable. As in:
(ecase (frame-restartable-p frame) ((nil) `((:restartable nil))) ((t) `((:restartable t))) (:maybe nil))
What next? A probability that it might work?
For consistency, perhaps back-ends that implement restart-frame also could implement frame-restartable-p?
They can but it shouldn't be required. The default implementation seems good enough to me.
The default implementation of frame-restartable-p always returns NIL, even for back-ends that implement restart-frame. The consequence is that swank clients are unable to determine whether a frame definitely cannot be restarted or whether the frame might be restarted.
Then implement the predicate for those backends if you know how to do it.
This has usability implications as swank clients cannot adapt to whether a frame certainly is restartable, might possibly be restartable, or definitely isn't restartable.
There's no definive answer to this question without unwinding the stack and executing unwind-protected handlers.
Helmut
On Mar 22, 2010, at 11:26 AM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-22 18:20+0100] writes:
On Mar 22, 2010, at 6:54 AM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-21 20:39+0100] writes:
Six swank back-ends implement the RESTART-FRAME interface. Yet only two of these back-ends implements FRAME-RESTARTABLE-P, which is used by the BACKTRACE slimefun to identify whether a frame is restartable.
Allegro and SBCL implement both restart-frame and frame- restartable- p. ABCL, CCL, CLISP and LispWorks only implement restart-frame.
ABCL doesn't support it; the code is just a comment. CCL only on PPC. CLISP or LispWorks have no documented debugger API and without knowing the internals it's hard to say anything other than "may or may not work".
Hence there are really three answers to the question of whether a frame is restartable: "yes", "no" and "maybe". Yet the BACKTRACE slimefun only allows FRAME-RESTARTABLE-P to return T or NIL:
(ecase (frame-restartable-p frame) ((nil) nil) ((t) `((:restartable t))))
I suggest BACKTRACE passes on the "maybe" semantics to the client, for example by returning the :restartable if and only if it definitely can be determined whether or not a frame is restartable. As in:
(ecase (frame-restartable-p frame) ((nil) `((:restartable nil))) ((t) `((:restartable t))) (:maybe nil))
What next? A probability that it might work?
I don't think that would be neither useful nor feasible.
The default implementation of frame-restartable-p always returns NIL, even for back-ends that implement restart-frame. The consequence is that swank clients are unable to determine whether a frame definitely cannot be restarted or whether the frame might be restarted. [...]
This has usability implications as swank clients cannot adapt to whether a frame certainly is restartable, might possibly be restartable, or definitely isn't restartable.
There's no definive answer to this question without unwinding the stack and executing unwind-protected handlers.
There is at least a definite answer to the question when the back-end does not implement a restart-frame function. When the frame definitely cannot be restarted, the swank client should obviously not present the user with the option to restart the frame.
Are you saying a back-end never can determine without actual execution that a frame on the stack for practical purposes is restartable?
-- Terje Norderhaug terje@in-progress.com
* Terje Norderhaug [2010-03-22 20:14+0100] writes:
This has usability implications as swank clients cannot adapt to whether a frame certainly is restartable, might possibly be restartable, or definitely isn't restartable.
There's no definive answer to this question without unwinding the stack and executing unwind-protected handlers.
There is at least a definite answer to the question when the back-end does not implement a restart-frame function. When the frame definitely cannot be restarted, the swank client should obviously not present the user with the option to restart the frame.
Are you saying a back-end never can determine without actual execution that a frame on the stack for practical purposes is restartable?
Yes.
Helmut
On Mar 22, 2010, at 1:59 PM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-22 20:14+0100] writes:
This has usability implications as swank clients cannot adapt to whether a frame certainly is restartable, might possibly be restartable, or definitely isn't restartable.
There's no definive answer to this question without unwinding the stack and executing unwind-protected handlers.
There is at least a definite answer to the question when the back-end does not implement a restart-frame function. When the frame definitely cannot be restarted, the swank client should obviously not present the user with the option to restart the frame.
Are you saying a back-end never can determine without actual execution that a frame on the stack for practical purposes is restartable?
Yes.
If so, frame-restartable-p should return NIL only when the frame definitely cannot be restarted and T when the frame possibly can be restarted. This makes the current default frame-restartable-p, which always returns NIL, unusable as default for back-ends that have a working restart-frame.
Either back-ends that implement restart-frame also need to implement frame-restartable-p, or the default frame-restartable-p should return T for back-ends that provide a restart-frame function.
With this in place, the backtrace slimefun will more consistently inform the client whether a frame potentially can be restarted or definitely can't be restarted.
-- Terje Norderhaug terje@in-progress.com
* Terje Norderhaug [2010-03-22 22:52+0100] writes:
If so, frame-restartable-p should return NIL only when the frame definitely cannot be restarted and T when the frame possibly can be restarted. This makes the current default frame-restartable-p, which always returns NIL, unusable as default for back-ends that have a working restart-frame.
Either back-ends that implement restart-frame also need to implement frame-restartable-p, or the default frame-restartable-p should return T for back-ends that provide a restart-frame function.
With this in place, the backtrace slimefun will more consistently inform the client whether a frame potentially can be restarted or definitely can't be restarted.
Whatever frame-restartable-p returns it doesn't stop the client from calling restart-frame.
Helmut
On Mar 22, 2010, at 3:15 PM, Helmut Eller wrote:
- Terje Norderhaug [2010-03-22 22:52+0100] writes:
If so, frame-restartable-p should return NIL only when the frame definitely cannot be restarted and T when the frame possibly can be restarted. This makes the current default frame-restartable-p, which always returns NIL, unusable as default for back-ends that have a working restart-frame.
Either back-ends that implement restart-frame also need to implement frame-restartable-p, or the default frame-restartable-p should return T for back-ends that provide a restart-frame function.
With this in place, the backtrace slimefun will more consistently inform the client whether a frame potentially can be restarted or definitely can't be restarted.
Whatever frame-restartable-p returns it doesn't stop the client from calling restart-frame.
No, but a proper value for frame-restartable-p will allow swank clients to consistently inform users about whether a backtrace frame might be restartable or definitely isn't. That's a usability improvement.
BTW, now we're on the topic, let me throw this idea in from a previous related discussion:
On Sat Jul 18 04:37:10 EDT 2009, Tobias C. Rittweiler wrote:
I think FRAME-RESTARTABLE-P should become a FRAME-ATTRIBUTES function with :RESTARTABLE, and :NON-RESTARTABLE being the currently specified values.
-- Terje Norderhaug terje@in-progress.com
* Terje Norderhaug [2010-03-22 23:40+0100] writes:
No, but a proper value for frame-restartable-p will allow swank clients to consistently inform users about whether a backtrace frame might be restartable or definitely isn't. That's a usability improvement.
BTW, now we're on the topic, let me throw this idea in from a previous related discussion:
On Sat Jul 18 04:37:10 EDT 2009, Tobias C. Rittweiler wrote:
I think FRAME-RESTARTABLE-P should become a FRAME-ATTRIBUTES function with :RESTARTABLE, and :NON-RESTARTABLE being the currently specified values.
Seems like renaming exercise to me.
Helmut
-
Helmut Eller -
Terje Norderhaug