[slime-devel] Restart Numbering

Madhu enometh at meer.net
Sun Oct 25 18:26:55 UTC 2009

* "Tobias C. Rittweiler" <87r5srbax3.fsf at freebits.de> :
Wrote on Sun, 25 Oct 2009 19:12:08 +0100:

| Madhu <enometh at meer.net> writes:
|> When I design a nested restart-cases or restart binds for the sldb user,
|> I want to provide a consistent restart mechanism. I have code where the
|> innermost restarts always stay the same. However the total number of
|> restarts may vary. Earlier I could count on the user not having to look
|> and pick out a number to get atthe innermost restart. Now the user gets
|> dick, For any restart provided by restart-case he has to READ all
|> restarts, and pick a number, which is NOT the easiest number to type.
| It is funny that this is at cross with my typical restart
| experience. The reason is probably because I'm mostly used to scenarios
| with "generally available" restarts rather than "punctually specific"
| restarts.
| The problem at hand is that the total number of restarts may vary, and
| the same restart is likely to be associated with a different number in
| each case.
| By reversed numbering, numbering is fixed for parts that share
| restart-establishing code paths. At the expensive of other cases.
| I think I can live with a somewhat smarter
| `sldb-invoke-restart-by-name', and unit test frameworks like stefil
| should probably get a contrib which adds keybinding to sldb.
|> | Ah. Yes, I can see your point now. OTOH, the new behaviour does have a
|> | technical advantage (see below) and, while it's probably true that if I
|> No I cant see it. Really.
| I wonder why. Really.
|> | had been accustomed to the old way as much as you, I wouldn't have made
|> | the change. So, erm, this kind of boils down to: "Sorry that I've
|> | screwed you, but I haven't screwed me, and I like the new way."
|> more like `I invented the new way so I like it.'  If you had tried the
|> old way instead of rewriting it, you would have liked that too, AND not
|> screwed all other usages. 
| No that is not the case. I wonder how I'm supposed to make use of the
| old way when the unit test framework provides generally-available
| restarts like skipping a test case, debugging a test case, etc. and
| these restarts get associated different numbers depending on whether the
| test case signalled just an error, or signalled a continuable error.
| Please tell me.

I'm not sure what youre asking, perhaps the flaw is in the way restarts
were designed by the writers of the framework, who probably gave no
thought to the issue and you are changing slime to fit that flawed view
of the world. 

I have not used those frameworks or looked at those tests.


More information about the slime-devel mailing list