[slime-devel] Restart Numbering

[Madhu]

* Attila Lendvai
Wrote on Mon, 26 Oct 2009 11:39:10 +0100:

|> If you read carefully upthread I've stated in this thread is MY
|> experience and MY usage scenario, which I have been carefully qualified.
|> What makes you think I've extrapolated anything?
|
| the fact that you speak up zealously after reading a commit log and
| admitting that you not even tried the patch. 

No, I tried it. In fact I'm running it from the the CVS sources of 24th,
(unpatched)

| because it's either the result of extrapolation of you preferences to
| others, or ignoring the fact that there are other preferences. i don't
| think you ignore others, so i kinda assume the former. (but don't
| worry, the latter is also very human, i also do that sometimes,
| unfortunately).
|
|
|> Tobias seems to recognize that the others usage scenarios are results
|> of miscoding/not understanding how restart contours work.
|
|
| sure. so you say that it's a mistake that stefil installs some restart
| when a test (an instrumented defun) is invoked, like rerun that
| specific test.

Dont you think a test framework is the idiosyncratic application here
with different requirements from other applications?

Aren't you extrapolating from a test framework to all other apps? (just
asking rhetorically)

If you were not running the tests but the actual function, Wouldnt you
want the restarts (provided in the actual function being tested)
reversed? so you get the innermost restart at lower numbers? So similar
code paths always gave the same innermost restart at the same low
number?

Shouldnt you assume that the user is actually interested in invoking the
restarts that are provided closest to the error?

| keep in mind that tests (defun's) can call each other to any number of
| times, and i in no ways want to keep track of the available restarts
| to wrap places where an error can from with a reversed (restart-case
| ...). let alone it's not possible either because errors can come from
| anywhere, not only from stefil's own assertion macros.

| for me, tcr's example of the restart-case around the error call was
| meant to be irony. errors can come from just about anywhere, not only
| from your own error calls.

Actually I did think of your point of view.  However I think the point
is about what you consider an error and how you recover from it.  Either
I am debugging a function, or I am running the tests.  On error, If I am
debugging the function I want the functions restarts.  If I am running
the tests I want the restarts provided by the test framework.  Then the
test framework would wrap up the entry points (which actually run a
test) with its own restarts, and HANDLE the error, and resignal an
error.

I think this really has to be handled thoughtfully at the application
level, by ignoring the issues in the app and hacking the deficiencies in
the debugger, I'd think you are discouraging the use of the restarts as
a useful interface in a meaningful way!


[In my applications I've gone to great extents to get restarts in the
 right order, and it involves catching and handling errors like tcr
 posted and extensive use of visible-p, lots of GOs and PROGs and
 dynamic state.  These are not pretty to code or look at.  The same
 ERROR call may need different restarts when called under different
 dynamic circumstances.  Macros help some, when you use the same
 (with-XXX-restarts) to cover different entry points...]

|> |> And if we are at it, why does SLDB give a number for restarts which do
|> |> already have a 1 keystroke keybinding?
|> |> q, a, c could just be written in place of the numbers, and those
|> |> numbers could be saved for other restarts... but this would be my
|> |> personal taste and I'm sure you can find arguments in your taste
|> |> against it.
|>
|> Because of consistency, you always want to invoke the innermost restart
|> with 0. This is not always Q.
|
| no, sorry, but i don't. :)
|
| because of consistency *i* always want the kill-thread restart be 0.

I suggest that this means you dont really want to use restarts provided
by an app, but almost always just want to get out of the debugger.

--
Madhu