Hey... Did you already put those as feature requests? It is the best
place to put those, otherwise your requests might be 'forgotten' when
someone actually has time to go and implement them...
Another excellent feature is to have is the ability to postmortem debug in the console if the app throws an exception. IPython lets you do this by automatically invoking pdb when there's an exception in the program, and the matlab debugger has similar functionality.
(I mention it because I just noticed that the new 'probe in suspend mode' feature of pydev doesn't let you do that).
--bbOn 2/17/06, Bill Baxter <email@example.com> wrote:Hi there,On 2/17/06, Fabio Zadrozny < firstname.lastname@example.org> wrote:This is a pretty great addition. How hard would it be to make it act more like a full-featured shell? I.e.,
- New feature in the debugger: the console is available for probing when
in 'suspendend mode'
- have a promt so you can tell tell that it's waiting for your input,
- respond after just one 'enter' instead of two,
- print out the value of variables by just typing the variable name (instead of having to type "print variable_name")
- cycle through your command history with keys like up/down-arrow or ctrl-up/down-arrow
- auto-completion of symbols
Ideally it would be nice to just have something like pycrust right there in a tab instead of "Console". Stani's Python Editor has pycrust built-in like that, but unfortunately it's not connected in any way to your executing program, so it's not so useful.
The ultimate debugger, based on debuggers I'm familiar with, would be a hybrid of that in VisualStudio crossed with Matlab. VisualStudio does variable and watches nicely. It's got a list (several lists actually) like Eclipse's 'Expressions', but you can double click to add a new expression or edit an expression. Eclipse is pretty close there, just needs a more efficient way to edit the expressions. The Matlab debugger, on the other hand, completely lacks an expression list, but its best feature is that when you hit a breakpoint, you just have your normal interactive shell prompt there with all it's features, plus all your program's state loaded in memory. This is an excellent debugging model for a dynamic programming language in my opinion. If there's some error on the current line, you can quickly try out a bunch of variations to figure out what the proper expression is to get the result you want, using the actual data from your program, without having to cook up a stand-alone test case that creates data similar to what's in your program.
William V. Baxter III
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan 154-0023
+81 (3) 3422-3380