* 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