David,
Re (1), I must respectfully disagrree - Object Arts'
experience was much more recent than the 80's, and they have never been shy
about keeping up on hardware. They reached a surprisingly rapid
and passionate conclusion in favor of the notifier. If you want an option
to go straight to the debugger, that's fine by me, just warn me so I can turn it
off.
Bill
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
<hernan.wilkinson@gmail.com>
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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project