[slime-devel] Restart Numbering

[Tobias C. Rittweiler]

Madhu <enometh at meer.net> writes:

> * "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
> as possible).

Yes, I meant that you can easily define keybindings to functions which
use sldb-invoke-restart-by-name. E.g. you could use the Fnn keys.


> |> 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
> implementations. 
> If you have concentric circles, you start numbering the innermost one 0
> and the next circle 1 etc.

I'm not sure there really has been given much thought to this. It's more
likely that implementations just numbered the return value of
COMPUTE-RESTARTS without a detailed decision making process.


> 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

You really orientate yourself on the actual numbers? I orientate myself
on the order of appearance -- i.e. what comes on top has a more recent
binding.


> | 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.

No that does not seem to be right. I'll demonstrate old and new
behaviour with examples below.


>   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!)
> dungeon-User Interface,

Yeah, that's why I suggest to to solidify the interface with custom Fnn
bindings and not to rely on the order. (Fnn bindings on top of
invoke-restart-by-name would of course always invoke the most recently
established restart -- dunno if you actually tend to have lots of
identically-named restart at the same time.)


> |> 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
> | continue".
>
> 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

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
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."

Placing

  ;; Keys 0-9 are shortcuts to invoke particular restarts.
  (dotimes (number 10)
    (let ((fname (intern (format "sldb-invoke-restart-%S" number)))
          (docstring (format "Invoke restart numbered %S." number)))
      (eval `(defun ,fname ()
               ,docstring
               (interactive)
               (sldb-invoke-restart number)))
      (define-key sldb-mode-map (number-to-string number) fname)))

into your .emacs should get you back the old behaviour.


> | The point of the change is that the numbering of restarts is almost
> | static for errors resulting from similiar code paths. Does this make
> | sense?
>
> No, I cannot see how this changed from previous behaviour. SLIME
> established restarts always had consistent numbers.

That's unfortunately not true. Let me demonstrate:


Old behaviour:

  > (length 12)

  The value 12 is not of type SEQUENCE.
     [Condition of type TYPE-ERROR]

  Restarts:
   0: [RETRY] Retry SLIME REPL evaluation request.
   1: [ABORT] Return to SLIME's top level.
   2: [TERMINATE-THREAD] Terminate this thread (...)

  > (with-simple-restart (TCR-RESTART "Foof.")
      (length 12))

  The value 12 is not of type SEQUENCE.
     [Condition of type TYPE-ERROR]

  Restarts:
   0: [TCR-RESTART] Foof.
   1: [RETRY] Retry SLIME REPL evaluation request.
   2: [ABORT] Return to SLIME's top level.
   3: [TERMINATE-THREAD] Terminate this thread (...)


New behaviour:

  > (length 12)

  The value 12 is not of type SEQUENCE.
     [Condition of type TYPE-ERROR]

  Restarts:
   2: [RETRY] Retry SLIME REPL evaluation request.
   1: [ABORT] Return to SLIME's top level.
   0: [TERMINATE-THREAD] Terminate this thread (...)

  > (with-simple-restart (TCR-RESTART "Foof.")
      (length 12))

  The value 12 is not of type SEQUENCE.
     [Condition of type TYPE-ERROR]

  Restarts:
   3: [TCR-RESTART] Foof.
   2: [RETRY] Retry SLIME REPL evaluation request.
   1: [ABORT] Return to SLIME's top level.
   0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {C115E01}>)


As you can see, in the new behaviour, shared restarts established in the
same code-path will now be numbered identically. It's true that I'm
screwing you, but I hope I was able to give reason for doing so.

  -T.