Hernan, A separate command in the debugger sounds like a great idea; that way it is accessible with none of the down side of prompting.
There probably is a trail that I can find on OA's reaction to bypassing notifiers. IIRC, they were getting a lot of pressure to allow the option, added it, and almost immediately said "it's available - use at your own risk." The recursive situations involve another error triggered either by failing to clear some condition or simply by shaking up the display by moving windows around as the notifier/debugger opens. IMHO, any prayer of breaking out depends on having the lightweight notifiers vs. full debuggers trying to open. Bill ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Hernan Wilkinson Sent: Friday, June 19, 2009 12:32 PM To: [email protected] Subject: Re: [Pharo-project] Making pharo more tdd oriented 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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Hernan Wilkinson Sent: Thursday, June 18, 2009 4:09 PM To: [email protected]<mailto:[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]<mailto:[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
