Hi Bill, thank you for your answer! There is no performance penalty on the OB. I'll think I'll add a button to the debugger to define the method. Same behavior as now but instead of going to the stack menu, just a button, much more faster. About the notifier, why did Object Arts went back? Are there any mail/info related? And I do not understand the recursive problem you mention, the debugger stops the process, why would it be different from a notifier?
Bye, Hernan. 2009/6/18 Schwab,Wilhelm K <[email protected]> > Hernan, > > (1) going straight to a debugger is a really bad idea. Object Arts tried > it, and promptly spoke out against it. If you want the option to skip the > notifier, fine, but I want to the option to keep the buffer of the > notifier. Imagine a recursive meltdown, and then make it an order of > magnitude or two worse because every mention of the problem is a full > debugger instead of a notifier. You've been warned :) > > (2) +1, maybe 2 > (3) +3 :) Those prompts are seriously annoying. I even have places in my > code that look like > > uninitializeTemp := uninitializeTemp. > > just to gag the "is it ok to remove xyz". It arises when I capture > something in a temp knowing that I will need it later but have not coded > that far yet. Not quite TTD, but not all that different. > > (4-5) options are generally good things. > > (6) Is there any impact on performance? OB is too slow as it is. > Otherwise it's probably fine. > > (7) I'm not a big fan of the default action concept, but this is probably a > good use. That said, I would probably not want to use it, and would ask > that you make it optional. From a system stability standpoint, I am a > little nervous about having an error invoke the GUI, especially if the tests > make use of #fork: etc. > > Bill > > > > ------------------------------ > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Hernan > Wilkinson > *Sent:* Thursday, June 18, 2009 4:09 PM > *To:* [email protected] > *Subject:* [Pharo-project] Making pharo more tdd oriented > > 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
