Changes proposal on Pre debugger
Hi, After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees. Context: The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ... Before, both views were managed via the same UI class. Yesterday I slitted this class. Proposed change: In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings. Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings. In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger? Possible future changes: In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :) -- Cyril Ferlicot https://ferlicot.fr
On 10 Jul 2019, at 20:21, Cyril Ferlicot D. wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
The community agrees! ;)
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
Yes please.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
I agree, remove the setting.
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
Maybe not to the exception itself but to an optional handler than can be installed in the exception? Cheers, Max
-- Cyril Ferlicot https://ferlicot.fr
Go go go! Stef
On 10 Jul 2019, at 20:21, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
-- Cyril Ferlicot https://ferlicot.fr
Thatâs definetely worth a try Norbert
Am 10.07.2019 um 20:21 schrieb Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
-- Cyril Ferlicot https://ferlicot.fr
On Thu, 11 Jul 2019 at 02:22, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
I'm not sure how I feel. I usually click in the Pre-Debugger stack rather than click the <Debug> button. When doing TDD I'll often know that the method I want to open is four down in the stack rather than where the library method bombed out. But really at worst its one additional click and probably easy enough to adapt so I'm willing to give it a go. cheers -ben
On Thu, Jul 11, 2019 at 7:17 AM Ben Coman <btc@openinworld.com> wrote:
I'm not sure how I feel. I usually click in the Pre-Debugger stack rather than click the <Debug> button. When doing TDD I'll often know that the method I want to open is four down in the stack rather than where the library method bombed out. But really at worst its one additional click and probably easy enough to adapt so I'm willing to give it a go.
Hi Ben, In your case there will be no change. You will still click one time four down in the stack. Or did I miss something?
cheers -ben
-- Cyril Ferlicot https://ferlicot.fr
On Thu, 11 Jul 2019 at 16:42, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Thu, Jul 11, 2019 at 7:17 AM Ben Coman <btc@openinworld.com> wrote:
I'm not sure how I feel. I usually click in the Pre-Debugger stack rather than click the <Debug> button. When doing TDD I'll often know that the method I want to open is four down in the stack rather than where the library method bombed out. But really at worst its one additional click and probably easy enough to adapt so I'm willing to give it a go.
Hi Ben,
In your case there will be no change. You will still click one time four down in the stack.
Or did I miss something?
doh! of course you are right. I didn't think that through. So no objection from me. cheers -ben
https://github.com/pharo-project/pharo/pull/3883 On Wed, Jul 10, 2019 at 8:21 PM Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
-- Cyril Ferlicot https://ferlicot.fr
-- Cyril Ferlicot https://ferlicot.fr
Go for it Cyril, the only drawback I can see it's that maybe for a newbie the whole Debugger can be intimidating with all the options it provides. The pre-debug window may feel safer to close. For my own use I'm always setting the full debugger to be open on errors. On Wed, Jul 10, 2019 at 3:22 PM Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
-- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, I had a particular use-case in Sentry Logger (adopted from old ShoreLine reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it. What I am wondering more is whether eliminating the pre-debugger would make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people. Not all users of Pharo are Pharo developers, so dropping on them the full debugger is not good. Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images? Or did you have some other alternatives in mind? Peter On Thu, Jul 11, 2019 at 3:00 PM Gabriel Cotelli <g.cotelli@gmail.com> wrote:
Go for it Cyril, the only drawback I can see it's that maybe for a newbie the whole Debugger can be intimidating with all the options it provides. The pre-debug window may feel safer to close.
For my own use I'm always setting the full debugger to be open on errors.
On Wed, Jul 10, 2019 at 3:22 PM Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
Hi,
After talking with Steven (in copy) we agreed on possible improvements around the pre debugger. I would like to share our vision and check if the community agrees.
Context:
The pre debugger is the window opening when an exception is signalled and not catched. This window currently has two views: - On warnings it display a text explaining the encountered problem. You can the proceed, abandon or debug. For example, this happens on Deprecations. - On other exceptions it display a short stack of the context in which the error was raised. You can abandon, open a full debugger, ...
Before, both views were managed via the same UI class. Yesterday I slitted this class.
Proposed change:
In our opinion, the pre debugger displaying a stack is useless. All the options it proposes are in the full debugger within one click reach. The only value we see for the pre debugger is about warnings.
Thus, we propose to remove the stack pre debugger and display directly the full debugger for anything else than a warning. This will save everyone one click each time we want to debug something. We would keep the textual view for warnings.
In case we do this, I wonder if we should keep the setting "Open full debugger". I think most users of this option are using it in order to not see the stack pre debugger and not to skip warnings. So, do someone have an opinion about keeping or removing this setting in case we remove the stack pre debugger?
Possible future changes:
In the future I would also like it if the opening of the pre (or full) debugger would be delegated to the raised exception in order to allow the introduction of different pre debuggers. But it's just an idea and not the scope of this mail. :)
-- Cyril Ferlicot https://ferlicot.fr
On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak@gmail.com> wrote:
Hi Cyril,
I had a particular use-case in Sentry Logger (adopted from old ShoreLine reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it.
What I am wondering more is whether eliminating the pre-debugger would make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people.
Not all users of Pharo are Pharo developers, so dropping on them the full debugger is not good. Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images?
Or did you have some other alternatives in mind?
Hi Peter, With changes introduced with the GTDebbuger it is possible to register alternative debuggers. They have a priority and know if they need to open depending on the context. We discussed with Steven and Thomas from the RMoD team and we think this is cool like that we can register alternative debuggers. On top of that, we would like to add the concept of fallback in case there is a problem. Currently, when the debugger bug, the emergency evaluator is open. We would like to open the next available debugger instead of the emergency evaluator. Then the emergency evaluator would be the last in the list. Also, an another subject, the button report can still be added to the full debugger.
Peter
-- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, thanks for the info! Being able to specify a top priority production debugger is definitely a better solution (instead of me trying to hack around pre-debugger :)). Thanks! Peter On Thu, Jul 11, 2019 at 4:30 PM Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak@gmail.com> wrote:
Hi Cyril,
I had a particular use-case in Sentry Logger (adopted from old ShoreLine
reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it.
What I am wondering more is whether eliminating the pre-debugger would
make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people.
Not all users of Pharo are Pharo developers, so dropping on them the
full debugger is not good.
Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images?
Or did you have some other alternatives in mind?
Hi Peter,
With changes introduced with the GTDebbuger it is possible to register alternative debuggers. They have a priority and know if they need to open depending on the context.
We discussed with Steven and Thomas from the RMoD team and we think this is cool like that we can register alternative debuggers.
On top of that, we would like to add the concept of fallback in case there is a problem.
Currently, when the debugger bug, the emergency evaluator is open. We would like to open the next available debugger instead of the emergency evaluator. Then the emergency evaluator would be the last in the list.
Also, an another subject, the button report can still be added to the full debugger.
Peter
-- Cyril Ferlicot https://ferlicot.fr
On Thu, 11 Jul 2019 at 22:30, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak@gmail.com> wrote:
Hi Cyril,
I had a particular use-case in Sentry Logger (adopted from old ShoreLine reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it.
What I am wondering more is whether eliminating the pre-debugger would make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people.
Not all users of Pharo are Pharo developers, so dropping on them the full debugger is not good. Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images?
Or did you have some other alternatives in mind?
Hi Peter,
With changes introduced with the GTDebbuger it is possible to register alternative debuggers. They have a priority and know if they need to open depending on the context.
We discussed with Steven and Thomas from the RMoD team and we think this is cool like that we can register alternative debuggers.
That would be cool - especially if it comes with a good Settings UI to make it more discoverable and good in-Image Help on how to create such an alternative debugger ;) cheers -ben
participants (8)
-
Ben Coman -
Cyril Ferlicot -
Cyril Ferlicot D.
-
ducasse -
Gabriel Cotelli -
Max Leske -
Norbert Hartl -
Peter Uhnak