[Pharo-users] [ann] gtdebugger in pharo 5.0

John Pfersich jpfersich at gmail.com
Sun Jan 10 20:19:06 EST 2016



Sent from my iPad

> On Jan 10, 2016, at 06:08, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> 
>> On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tudor at 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.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160110/6ef63314/attachment.html>


More information about the Pharo-users mailing list