July 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #474: 3891-Rename-method-refactoring-does-not-work-anymore

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #474 was: FAILURE. The Pull Request #3892 was integrated: "3891-Rename-method-refactoring-does-not-work-anymore" Pull request url: https://github.com/pharo-project/pharo/pull/3892 Issue Url: https://github.com/pharo-project/pharo/issues/3891 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Peter Uhnak

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(a)gmail.com> wrote: > On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak(a)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 > >

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Cyril Ferlicot

On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <i.uhnak(a)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

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Peter Uhnak

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(a)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(a)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 >> >>

July 11, 2019

[Pharo 8.0] Build #473: Revert to GradientFillStyle class>>sample

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #473 was: FAILURE. The Pull Request #3887 was integrated: "Revert to GradientFillStyle class>>sample" Pull request url: https://github.com/pharo-project/pharo/pull/3887 Issue Url: https://github.com/pharo-project/pharo/issues/3886 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Gabriel Cotelli

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(a)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 > >

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Ben Coman

On Thu, 11 Jul 2019 at 16:42, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Thu, Jul 11, 2019 at 7:17 AM Ben Coman <btc(a)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

July 11, 2019

[Pharo 8.0] Build #472: Cleanup SHRBTextStyler

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #472 was: FAILURE. The Pull Request #3885 was integrated: "Cleanup SHRBTextStyler" Pull request url: https://github.com/pharo-project/pharo/pull/3885 Issue Url: https://github.com/pharo-project/pharo/issues/3884 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 11, 2019

[ANN] Pharo TechTalk July 18th

by Marcus Denker

A regular chat about Pharo. Happens on Discord. Topic: How to report and fix bugs for Pharo. In a live coding session, we will together have a look at some simple fixes for Pharo8 and learn how to report bugs and do Pull Requests. - We will send an information to all subscribers of this event some hours before the talk starts. - Or just hangout in Discord, we post everything there, too https://association.pharo.org/event-3419542

July 11, 2019

Re: [Pharo-dev] Changes proposal on Pre debugger

by Cyril Ferlicot

https://github.com/pharo-project/pharo/pull/3883 On Wed, Jul 10, 2019 at 8:21 PM Cyril Ferlicot D. <cyril.ferlicot(a)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

July 11, 2019