On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. > Can we do it the other way for Pharo 5 "Release"? Keeping the existing debugger as default and as desired people can enable GTDebugger. I know this limits exposure and slows uptake and feedback, but prior to this announcement there has been *zero* community discussion of making this the default. I can't find the Pharo 5 roadmap/plan, but I don't remember GTDebugger being mentioned at all. I worry how it looks to people considering Pharo for big changes like this to be dropped out of the sky without *public* forward *planning*. A big UI change like this should happen *early* in a release cycle - because then you have a *long* time for it to become stable for documentation. Even though Dimitris is keen, I can understand why its disheartening for Stef. I'd hope the way is to introduce such big changes is as a technology preview and have the *default* match the recently developed documentation. Note my problem is only with the default for the Pharo 5 "Release", so it could be default now to kick start its exposure and revert the default a few weeks before the Pharo 5 Release. And its not like you lose a whole year of feedback by not being default in Pharo 5 Release. The documentation using newcomers who are most likely to use Pharo 5 "Release" probably wouldn't have the confidence (or care) to provide the feedback you want anyway. Many of those in the community who would normally provide feedback will be follow Pharo 6 bleeding edge anyway, so they'll that won't be stuck with the old debugger. Making GTDebugger the default early in Pharo 6 should still get plenty of feedback from those that usually contribute. btw, I am looking forward to using it for myself. cheers -ben > However, please do take the time to provide us feedback if something does > not work out for you. We want to know what can be improved and we try to > react as fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > > While the first thing that will capture the attention is the default > generic interface, the real power comes from the moldable nature of the > debugger. Like all other GT tools, GTDebugger is also moldable by design. > This means that we can construct custom debuggers for specific libraries at > small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links > for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > > > >
