[Pydev-code] Another good feature to have

[Bill Baxter]

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).

--bb

On 2/17/06, Bill Baxter <[EMAIL PROTECTED]> wrote:

Hi there,

On 2/17/06, Fabio Zadrozny < [EMAIL PROTECTED]> wrote:

- New feature in the debugger: the console is available for probing when
in 'suspendend mode'

This is a pretty great addition.  How hard would it be to make it act more like a full-featured shell?  I.e.,
- 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.

Regards,
Bill Baxter

--
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380