[Pydev-code] Another good feature to have

[Bill B. <wb...@gm...>]

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 th=
e
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 <wb...@gm...> wrote:
>
> Hi there,
>
> On 2/17/06, Fabio Zadrozny <fa...@es...> wrote:
> >
> >
> > - New feature in the debugger: the console is available for probing whe=
n
> > 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-i=
n
> like that, but unfortunately it's not connected in any way to your execut=
ing
> 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) li=
ke
> 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 w=
hen
> 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 c=
an
> 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 d=
ata
> 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