[slime-devel] Daily ChangeLog diff
Index: slime/ChangeLog diff -u slime/ChangeLog:1.1880 slime/ChangeLog:1.1882 --- slime/ChangeLog:1.1880 Wed Oct 21 10:37:08 2009 +++ slime/ChangeLog Fri Oct 23 15:40:14 2009 @@ -1,3 +1,23 @@ +2009-10-23 Tobias C. Rittweiler <tcr@freebits.de> + + Restarts in SLDB are now numbered reversely. The rationale is that + always-existing restarts are likely to be associated with the same + number now. + + * slime.el (sldb-insert-restarts): Number restart reversely. + (sldb-restart-number-for-swank): New; recompute the unreversed + number for the swank side. + (sldb-restart-number-at-point): Previously `sldb-restart-at-point'. + (sldb-invoke-restart): Adapted accordingly. + +2009-10-23 Tobias C. Rittweiler <tcr@freebits.de> + + When ever Slime seems to get stuck (e.g. after some character + encoding confusion), `M-x slime-reset' should hopefully bring it + into a functional state again. + + * slime.el (slime-reset): Erase connection buffer. + 2009-10-21 Tobias C. Rittweiler <tcr@freebits.de> Make M-x slime-changelog-date work.
| diff -u slime/ChangeLog:1.1880 slime/ChangeLog:1.1882 | | +2009-10-23 Tobias C. Rittweiler <tcr@freebits.de> | + | + Restarts in SLDB are now numbered reversely. The rationale is that | + always-existing restarts are likely to be associated with the same | + number now. | + | + * slime.el (sldb-insert-restarts): Number restart reversely. | + (sldb-restart-number-for-swank): New; recompute the unreversed | + number for the swank side. | + (sldb-restart-number-at-point): Previously `sldb-restart-at-point'. | + (sldb-invoke-restart): Adapted accordingly. I see 2 issues here, but I think the idea is bad for several reasons including: 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. 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). 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.') -- Madhu
Madhu <enometh@meer.net> writes:
| diff -u slime/ChangeLog:1.1880 slime/ChangeLog:1.1882 | | +2009-10-23 Tobias C. Rittweiler <tcr@freebits.de> | + | + Restarts in SLDB are now numbered reversely. The rationale is that | + always-existing restarts are likely to be associated with the same | + number now. | + | + * slime.el (sldb-insert-restarts): Number restart reversely. | + (sldb-restart-number-for-swank): New; recompute the unreversed | + number for the swank side. | + (sldb-restart-number-at-point): Previously `sldb-restart-at-point'. | + (sldb-invoke-restart): Adapted accordingly.
I see 2 issues here, but I think the idea is bad for several reasons including:
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.
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. 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. [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.]
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". 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? Quick example: Slime's RETRY restart which is wrapped around REPL requests will now always be numbered 2 on SBCL. -T. PS. Notice that you can easily add your own symbolic bindings for your application-specific restarts by means of `sldb-invoke-restart-by-name'.
* "Tobias C. Rittweiler" <87k4yjeuhl.fsf@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). |> 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. 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!) dungeon-User Interface, |> 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 | 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. -- Madhu
Madhu <enometh@meer.net> writes:
* "Tobias C. Rittweiler" <87k4yjeuhl.fsf@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.
* "Tobias C. Rittweiler" <87pr8bd84f.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 12:29:36 +0100: | Madhu <enometh@meer.net> writes: | |> * "Tobias C. Rittweiler" <87k4yjeuhl.fsf@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. No, my Fnn and other keys are bound to other things. I come from CMUCL where I hit a single digit (a number) to invoke a restart. In this scheme if I'm facing 10+ restarts, the restart the sldb user gets the dick. he have to hit 2 digits, 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. |> 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. The implementations work as expected when designing nested RESTART-CASES. |> 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. Top is always 0. Next is 1, next 2. Stack grows down. [example snipped, I'll check maybe next month] | 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.) No, I want to use digits. I need all other keys for other purposes. The argument applies against your change: Can't you just use a custom Fnn binding for the RETRY-RESTART is so important instead of messing with the restart order supplied from the implementation? | 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. | 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. -- Madhu
Madhu <enometh@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. -T.
* "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 19:12:08 +0100: | Madhu <enometh@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. -- Madhu
Madhu <enometh@meer.net> writes:
| 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.
So instead of writing (restart-bind ((a ...) (b ...)) (run-test (find-test foo))) they should probably write (handler-bind ((serious-condition (c) (restart-bind ((a ...) (b ...)) (error c)))) (run-test (find-test foo))) Hmm. Seems like I learned something from the thread indeed. :-) Thank you, -T.
On Sun, Oct 25, 2009 at 7:26 PM, Madhu <enometh@meer.net> wrote:
* "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 19:12:08 +0100:
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.
-- Madhu
It's really weird to read this discussion. You seem to be so sure about how others use slime/lisp (what they like or dislike) by extrapolating your own usage scenarios. Why don't you put a variable there? Then both of you will be ok, and others can also choose according to their own preference. Keep the old behavior as default, and it's done. 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. levy -- There's no perfectoin
Am 26.10.2009 um 08:56 schrieb Levente Mészáros:
On Sun, Oct 25, 2009 at 7:26 PM, Madhu <enometh@meer.net> wrote:
* "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 19:12:08 +0100:
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.
-- Madhu
It's really weird to read this discussion.
You seem to be so sure about how others use slime/lisp (what they like or dislike) by extrapolating your own usage scenarios. Why don't you put a variable there? Then both of you will be ok, and others can also choose according to their own preference. Keep the old behavior as default, and it's done.
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.
levy
-- There's no perfectoin
Very well said. Thanks! Now back to the other two ... ;-) Frank
* Frank Goenninger <B6E7E58B-2238-413F-855D-B266D96B04D6@me.com> : Wrote on Mon, 26 Oct 2009 09:29:34 +0100: | Am 26.10.2009 um 08:56 schrieb Levente Mészáros: | |> On Sun, Oct 25, 2009 at 7:26 PM, Madhu <enometh@meer.net> wrote: |>> |>> * "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : |>> Wrote on Sun, 25 Oct 2009 19:12:08 +0100: |>> |>> 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. |>> |> It's really weird to read this discussion. |> |> You seem to be so sure about how others use slime/lisp (what they like |> or dislike) by extrapolating your own usage scenarios. 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? Tobias seems to recognize that the others usage scenarios are results of miscoding/not understanding how restart contours work. | Why don't you |> put a variable there? Then both of you will be ok, and others can |> also choose according to their own preference. Keep the old behavior |> as default, and it's done. |> |> 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. | Very well said. Thanks! Now back to the other two ... ;-) Back to this one! -- Madhu
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. 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. 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.
|> 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. -- attila ps: but i'll number restarts the way i prefer in my own copy of slime on my hard drive, so...
* 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
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? Do you mean this?
Tobias seems to recognize that the others usage scenarios are results of miscoding/not understanding how restart contours work. It is not only impractical to do what you suggest even within a single
"Even then, the motivation is both bogus and wrong and the design goes against basic debugger sense which ALL implementations have implemented!" or this? "No, I think this is a general design consideration for all those implementations." maybe this? "If you had tried the old way instead of rewriting it, you would have liked that too, AND not screwed all other usages." library, but try to do this cross library! levy -- There's no perfectoin
The assumption I did make is that users WILL WANT to invoke innermost restarts more often, and so numbers should be from 0 outwards. I assumed If someone is going to the trouble of wrapping an errorable form in a restart-case, they expect you will want to call _those_ restarts more than someone lower in the call chain. (i.e. someone wrapping a call at a bigger number in the stack backtrace), since this is what error recovery is all about. I'm just going to quibble below: * Levente Mészáros Wrote on Mon, 26 Oct 2009 12:11:38 +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? | Do you mean this? | | "Even then, the motivation is both bogus and wrong and the design goes | against basic debugger sense which ALL implementations have | implemented!" Apart from the motivation part which was `attitude', I was stating a fact I knew: Slime's new behaviour numbered the restarts in an order that is the reverse of how it is done in every Common Lisp implementation that I've seen so far. Is there a lisp implementation that doses it the other way? | or this? | | "No, I think this is a general design consideration for all those | implementations." This has to do with the fact as before. ALL debugger environments I'VE SEEN SO FAR have done it that way, and I saw good reasons for doing it that way. I thought explained the reasons, without extrapolating! (the numbering matches the contours, inner restarts, growing downwards) | maybe this? | | "If you had tried the old way instead of rewriting it, you would have | liked that too, AND not screwed all other usages." This was a snide remark to tcr. But isnt it trivially true? In reversing the numbering of restarts you have screwed everybody who counts on the innermost restarts getting a 0 number. |> Tobias seems to recognize that the others usage scenarios are results of |> miscoding/not understanding how restart contours work. | It is not only impractical to do what you suggest even within a single | library, but try to do this cross library! I agree that a new variable is the best way to go. Good luck getting helmut to agree though! -- Madhu
Levente Mészáros <levente.meszaros@gmail.com> writes:
On Sun, Oct 25, 2009 at 7:26 PM, Madhu <enometh@meer.net> wrote:
* "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 19:12:08 +0100:
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.
-- Madhu
It's really weird to read this discussion.
You seem to be so sure about how others use slime/lisp (what they like or dislike) by extrapolating your own usage scenarios. Why don't you put a variable there? Then both of you will be ok, and others can also choose according to their own preference. Keep the old behavior as default, and it's done.
I reverted the change on two and a half grounds: a) software (like stefil) can, and arguably should make sure that the most appropriate restarts are on top of the stack, b) that the reverse numbering truly sucks for the case when the total number of restarts exceeds 10 -- and somewhat c) I see the point that lower numbers are more convenient to reach if one has a numpad available (which I happen not to have.) -T.
[Replying again to Levente, same message but proofread] * Levente Mészáros Wrote on Mon, 26 Oct 2009 08:56:19 +0100: | On Sun, Oct 25, 2009 at 7:26 PM, Madhu <enometh@meer.net> wrote: |> |> * "Tobias C. Rittweiler" <87r5srbax3.fsf@freebits.de> : |> Wrote on Sun, 25 Oct 2009 19:12:08 +0100: |> |> 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. | | It's really weird to read this discussion. | | You seem to be so sure about how others use slime/lisp (what they like | or dislike) by extrapolating your own usage scenarios. If you read carefully upthread, you should note that everything I've stated in this thread is about MY experience and MY usage scenarios, which I have been careful to qualify as such. What makes you think I've extrapolated anything? The parts where I try to provide the rationale for the behaviour I outline? Tobias seems to recognize that the `other's usage scenarios' are results of miscoding and/or not understanding how restart contours work. |> Why don't you put a variable there? Then both of you will be ok, and |> others can also choose according to their own preference. Keep the |> old behavior as default, and it's done. |> |> 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. -- Madhu
* Tobias C. Rittweiler [2009-10-25 09:41+0100] writes:
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.
An argument could be made that the hot end of the stack is more important and that the good keys should be used for the top of the stack. I can see that quickly accessible restarts at the bottom are nice too but Slime has keys for those already. Why then burn all keys for the bottom?
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.
Forth's PICK numbers stack items starting from the top and it would be completly useless if the numbering were reversed. Starting from the top obviously makes more sense to Forthers.
[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.]
Look up sldb-initial-restart-limit, you bunch of whiners. [...]
Quick example: Slime's RETRY restart which is wrapped around REPL requests will now always be numbered 2 on SBCL. [...] Notice that you can easily add your own symbolic bindings for your application-specific restarts by means of `sldb-invoke-restart-by-name'.
Maybe sldb-invoke-restart-by-name should have an option to start the search from the bottom so that you can invoke your RETRY restart more easily. Helmut
Helmut Eller <heller@common-lisp.net> writes:
* Tobias C. Rittweiler [2009-10-25 09:41+0100] writes:
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.
An argument could be made that the hot end of the stack is more important and that the good keys should be used for the top of the stack.
I can see that quickly accessible restarts at the bottom are nice too but Slime has keys for those already. Why then burn all keys for the bottom?
It's not about making the restarts at the bottom quickly accessible (they mostly are already due to q,a,c), and it's not about the RETRY restart, it's about _fixing_ the numbering for code that share the same code-path. E.g. to expand on the example I gave to Madhu: (defun application (cont) (with-simple-restart (APP-R1 "Application restart 1") (with-simple-restart (APP-R2 "Application restart 1") (funcall cont)))) Old:
(application #'(lambda () (error "An error")))
An error [Condition of type SIMPLE-ERROR] Restarts: 0: [APP-R2] Application restart 1 1: [APP-R1] Application restart 1 2: [RETRY] Retry SLIME REPL evaluation request. 3: [ABORT] Return to SLIME's top level. 4: [TERMINATE-THREAD] Terminate this thread (...)
(application #'(lambda () (cerror "Frob!" "An error")))
An error [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Frob! 1: [APP-R2] Application restart 1 2: [APP-R1] Application restart 1 3: [RETRY] Retry SLIME REPL evaluation request. 4: [ABORT] Return to SLIME's top level. 5: [TERMINATE-THREAD] Terminate this thread (...) As you can see, the application restarts were all renumbered. And in past you had to carefully look at the restart list to choose the right restart. New:
(application #'(lambda () (error "An error")))
An error [Condition of type SIMPLE-ERROR] Restarts: 4: [APP-R2] Application restart 1 3: [APP-R1] Application restart 1 2: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 0: [TERMINATE-THREAD] Terminate this thread (...)
(application #'(lambda () (cerror "Frob!" "An error")))
An error [Condition of type SIMPLE-ERROR] Restarts: 5: [CONTINUE] Frob! 4: [APP-R2] Application restart 1 3: [APP-R1] Application restart 1 2: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 0: [TERMINATE-THREAD] Terminate this thread (...) In the new numbering, the application restarts (as they're established within the same code path) will be associated with the same numbers. If, now, you know that an error came from the same code path (often the case when you're interactively writing some part of your application), you can develop a good sense how restarts are numbered. -T.
* Tobias C. Rittweiler [2009-10-25 12:44+0100] writes:
If, now, you know that an error came from the same code path (often the case when you're interactively writing some part of your application), you can develop a good sense how restarts are numbered.
If it's from the same code path it will be numbered just the same because you will hit the same error again. Helmut
Helmut Eller <heller@common-lisp.net> writes:
* Tobias C. Rittweiler [2009-10-25 12:44+0100] writes:
If, now, you know that an error came from the same code path (often the case when you're interactively writing some part of your application), you can develop a good sense how restarts are numbered.
If it's from the same code path it will be numbered just the same because you will hit the same error again.
Yes, of course. I meant to say "similiar code path". -T.
* Tobias C. Rittweiler [2009-10-25 13:22+0100] writes:
If, now, you know that an error came from the same code path (often the case when you're interactively writing some part of your application), you can develop a good sense how restarts are numbered.
If it's from the same code path it will be numbered just the same because you will hit the same error again.
Yes, of course. I meant to say "similiar code path".
You mean, similar but yet different enough to trigger a different error but many restarts are still the same? How important is that case and how many restart would stay the same anyway? Seems odd to optimize that case at the expense of making the top restarts harder to access. Helmut
If it's from the same code path it will be numbered just the same because you will hit the same error again.
Yes, of course. I meant to say "similiar code path".
You mean, similar but yet different enough to trigger a different error but many restarts are still the same? How important is that case and how many restart would stay the same anyway?
in a web server: retry-handling-request, retry-rendering, etc... we are using slime with the same ordering for 1+ years now and it was a clear win for us. -- attila
Helmut Eller <heller@common-lisp.net> writes:
* Tobias C. Rittweiler [2009-10-25 13:22+0100] writes:
If, now, you know that an error came from the same code path (often the case when you're interactively writing some part of your application), you can develop a good sense how restarts are numbered.
If it's from the same code path it will be numbered just the same because you will hit the same error again.
Yes, of course. I meant to say "similiar code path".
You mean, similar but yet different enough to trigger a different error but many restarts are still the same? How important is that case and how many restart would stay the same anyway?
SBCL does it, Slime does it, CLPython does it, unit test frameworks do it (stefil quite heavily, but also others live 5am or lift), web frameworks like UCW do it, probably others too.
Seems odd to optimize that case at the expense of making the top restarts harder to access.
It probably depends on how much you make use of frameworky stuff. At the moment the cursor is placed at the first frame of the backtrace; we could make the cusor be placed at the first restart instead. (Perhaps also making TAB switch between restart list and backtrace.) This would make the restarts at the top easily accessible. -T.
* Tobias C. Rittweiler [2009-10-25 14:53+0100] writes:
Helmut Eller <heller@common-lisp.net> writes: [...]
You mean, similar but yet different enough to trigger a different error but many restarts are still the same? How important is that case and how many restart would stay the same anyway?
SBCL does it, Slime does it, CLPython does it, unit test frameworks do it (stefil quite heavily, but also others live 5am or lift), web frameworks like UCW do it, probably others too.
Does what?
Seems odd to optimize that case at the expense of making the top restarts harder to access.
It probably depends on how much you make use of frameworky stuff.
At the moment the cursor is placed at the first frame of the backtrace; we could make the cusor be placed at the first restart instead. (Perhaps also making TAB switch between restart list and backtrace.) This would make the restarts at the top easily accessible.
At the cost of making the first frame harder to find and wasting keys 0..3 for stuff that's already covered by q. If the restart at the bottom are so important those people could just make their custom keybindings. Obviously my sense for aesthetics is just odd. I'll shut up now. Helmut
* "Tobias C. Rittweiler" <871vkrd1fx.fsf@freebits.de> : Wrote on Sun, 25 Oct 2009 14:53:54 +0100: | SBCL does it, Slime does it, CLPython does it, unit test frameworks do | it (stefil quite heavily, but also others live 5am or lift), web | frameworks like UCW do it, probably others too. I've been using CL day in day out for 3+ years and I cannot use this behaviour. |> Seems odd to optimize that case at the expense of making the top |> restarts harder to access. | | It probably depends on how much you make use of frameworky stuff. Even then, the motivation is both bogus and wrong and the design goes against basic debugger sense which ALL implementations have implemented! I do not see the stated `technical advantage', and it seems to you like it because it handles a SPECIFIC restart for a SPECIFIC combination of Lisp (SBCL) and a specific application framework. which you have used. I do not encounter those paths, and it pessimises my sldb experience. In particular when I provide restarts, I want the user to be able to choose 0 as the first restart. -- Madhu
participants (6)
-
Attila Lendvai -
Frank Goenninger -
Helmut Eller -
Levente Mészáros -
Madhu -
Tobias C. Rittweiler