1. +1 Direct to debug sounds good to me. Notifier window was for low power (in the 1980s). Don't care if it is a preference. Would prefer fewer preferences, but I can't bring myself to add a preference for it... 2. +1 Big Debugger. 3. -1 I work top-down as well and I still like the typo correction that comes from this step. 4. +1 Wish shortcuts weren't pane specific. 5. ? 6. ? 7. +1
2009/6/18 Hernan Wilkinson <[email protected]> > Hi, > I have made some changes to pharo to make it more tdd oriented. I want to > share them with you to know your opinion and then make the code public. > The changes I made are: > > 1) When there is an error, the debugger opens directly. Reason: I found > that I always press Debug when an error occurs in the Notifier window. > Question: Should this option be a preference? > 2) The debugger opens in a big window. Reason: I always want to debug! and > I want to see as much as possible when debugging. Before I found myself > making the debugger window bigger all the time > 3) When compiling a method that sends a message not defined, it does not > ask anymore if I want to change it. Reason: When doing TDD we work top-down, > so we are always sending messages that are not defined and that we are going > to define when running the test. Question: Should this option be a > preference? > 4) I added an option to save and run the test from the code pane of the > omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: > It is very handful > 5) I added an option to save and step a test from the code pane of the omni > browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not > work well with breakpoints...) > 6) I added a debugCase: message to TestResult and make some changes to the > omni browser to show the result of debugging a test. Reason: Before, when > debugging a test the browser was showing the test as not runned. > 7) When running a test, the defualtAction of the MessageNotUndertood > exception will ask you if you want to implement the method (if the receiver > is not nil) so you don't have to select that option from the debugger stack > list menu. Reason: When running a test 95% of the time a message not > understood will be implemented and answering yes or no is easier that going > to the stack menu of the debugger to select the option implement. > > What do you think? Comments welcome. > Bye, > Hernan. > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
