I totally agree. 2009/3/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:
So we should proceed that way:     - Put a big warning + the expression to switch debugger in the pharo- dev     - then we follow what dale is saying         - I will produce a list of important features we need to have             -- copy stack             -- chase pointer             ... in OT
some raw ideas... - "implement in" when dnu - switchable pre-debug window - consistent way of changing var values (+ refreshing) - toggling haltOnce or equivalent from within the debugger --- putting break points (or return points) in the debugger - slow proceed - step by step at low speed just to see the execution and eventually pause it wherever we want - ... - something I find annoying (but might be a bad use of debugger) is when iterating over a collection, I go into the internal of the collection loop, and have to click "into" when the debugger is at the "value:" of the internal implementation... Is it me ? -... We could even enforce the debugger as the "writing code" tool... which is possible but tricky for now... Cheers,
Is is ok for your community?
Stef
Begin forwarded message:
From: Dale Henrichs <dale.henrichs@gemstone.com> Date: March 3, 2009 6:57:36 PM CEST To: stephane.ducasse@inria.fr Subject: On the OTDebugger... Reply-To: dale.henrichs@gemstone.com
Steph,
This note isn't about your 'disable OB-debugger for now message', but it is a response, of sorts to the ensuing discussion.
If you want a '120% debugger' then folks working on Pharo need to use the debugger and eat their own dogfood. It's the only way to ensure that a tool like the debugger gets enough coverage to ensure that it is stable. With that said, I wouldn't want to commit to using a tool that was broken or that I couldn't depend upon.
With that in mind, I am willing to commit to the following things:
1. fix any bugs or implement any features that are deemed as show stoppers with the current OTDebugger - i.e., the things that are preventing folks from getting work done today.
2. I also promise a quick response to any show stopper bugs that folks come across while doing development with the OTDebugger (or any other of the OB-Tools).
I came to maintain the OB-Tools through the 'back door'. I use a branch the OB-Tools in GLASS and have decided to maintain the OB- Tools for the Squeak/Pharo community as a way to contribute back to the community. What that means specifically is that next to Lukas, I probably know more about the OB-Tools than anyone else, however, I don't have a laundry list of features that need to be added to the debugger.
I could go through the Squeak debugger and duplicate all of the 'missing features', but my personal sense is that some of those features aren't useful - I know that I have not even read all of the menu items in the old Squeak debugger, let alone tried to figure out what they do...
Getting a list of important/missing features from a small group is important to me (at least at the start). I don't have a personal sense of "what's missing" from the current OTDebugger, since I have not used the old Squeak debugger extensively. So getting feedback from "old hands" is important, but I also know that I won't be able to respond correctly to a general query for "what's missing from the debugger?"
For direction towards the "120% debugger", I think it makes sense that you and rest of the Pharo leadership team make a list of "debugger franchise features" - i.e., a list of features that are a must have for the Pharo debugger and the other OB-Tools as well (BTW, if that list is to "duplicate all of the 'missing features'" then that's fine and I'm willing to do it).
The debugger along with browsers are the face of the development environment and I don't want to bloat the debugger without at least a second opinion and I trust the opinions of you and the rest of the Pharo leadership team.
Thanks,
Dale
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Cédrick