[slime-devel] Restart Numbering
enometh at meer.net
Sun Oct 25 09:35:34 UTC 2009
* "Tobias C. Rittweiler" <87k4yjeuhl.fsf at freebits.de> :
Wrote on Sun, 25 Oct 2009 09:41:10 +0100:
[quoting you out of order]
| Notice that you can easily add your own symbolic bindings for your
| application-specific restarts by means of `sldb-invoke-restart-by-name'.
The point is for invoking a restart with a single (or as few keystrokes
|> 1. It fails to meet the stated purpose. Always existing restarts
|> (provided by slime already had the same number); If the goal was to
|> match the order of presentation with what the implementation debugger
|> would provide consider
|> Inner restarts have lower numbers than outer restarts. See how
|> implementations number the restarts in
|> (with-simple-restart (barf-outer "barf") (with-simple-restart
|> (foo-inner "foof") (error "bARF")))
|> Every implementation's debugger numbers a restart for FOO-INNER at a
|> smaller number than the restart for BARF-OUTER. SLDB now reverses
|> this ordering.
| I think this is a true complaint for the case when you're used to use
| the native debugger equally often as the Slime debugger. I'm eager to
| say that this is probably the unusual case for users of Slime, but I'm
| solely extrapolating from my own.
No, I think this is a general design consideration for all those
If you have concentric circles, you start numbering the innermost one 0
and the next circle 1 etc.
If I have several restarts with same name, they all look the same when
printed. Then one would rely on the numbering to determine which is the
correct `continue' restart (say) to invoke. This order should not be
messed up with
|> 2. Reversing the printed order of restarts means, when you have more
|> than a handful of restarts, you cannot restart 0 or 1 (the "first
|> restart the user would want to invoke"), because it is hidden; SLDB
|> only lists the first few restarts, you have to move the cursor down
|> to the "--more--" button and hit RET to see more restarts. (This
|> slime UI element is an intensely painful part of slime, subject of a
|> different rant).
| There's a slight misunderstanding of my change, I think: The restarts
| _themselves_ are _not_ reversed, just their numbering is reversed; it's
| done this way exactly for reasons of giving importance to locality.
I have not updated slime to your latest changes, so maybe I'm missing
something, but I see the slime established restarts at the bottom of the
list hidden by --more--, while application restarts are at top.
| And if you think of it, the reversed numbering actually does make sense
| (beyond its technical advantage) as it reflects the stack-like behaviour
| of binding.
Does it? I'm not sure Earlier the slime established restarts (the first
circle) numbered 0 at the top. (first circle), then application
established restarts, etc.
Right now, (as usual :) I am working on reverting these changes for my
setup to get the old behaviour back, I'll check again]
| [I think I agree on the --more-- part, but I don't see it that often
| myself. I'd feel content with a keybinding which shows full detail of
| the restart list and the backtrace.]
I see it all the time, I use the debugger as a (damn useful!)
|> 3. This is confusing to my muscle memory which has been trained to
|> hitting 0 for the first restart expected from the lisp program being
|> evaluated (an argument i started making in 2008-08-25, but did not
|> complete). Consider the the numeric keypad. However I assume you did
|> want to ensure the restart 0 was `return to slime top-level.')
| No not because of that: notice that `q' is bound to "return to
| toplevel", and `a' is bound to "invoke abort", and `c' to "invoke
Not q, 0. We are talking of numbers (reachable in the numkeypad) here
besides the `continue' i want may not be the `continue' restart which
slime would invoke with `c', and now I cannot use the numbering to
decide which is earlier and which is later
| The point of the change is that the numbering of restarts is almost
| static for errors resulting from similiar code paths. Does this make
No, I cannot see how this changed from previous behaviour. SLIME
established restarts always had consistent numbers.
More information about the slime-devel