Sent from my iPad
> On Jan 10, 2016, at 06:08, Ben Coman <b...@openinworld.com> wrote: > > > >> 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 > +1 > >> 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. >
