Debugger: Watches in nightlies

[Rosch]

Hi...

Occassionally I am using CB. Now I wanted to take a deeper look into it so I downloaded the latest nightly (20121023). I did set up a test project and compiled it using gcc. So far so good. Then I started to debug it. Basically it worked also.

But than I got very surprised. The automatic display of local variables and function call parameters in the watches window has been gone!!!

Where are they now?
Are they somewhere else now?
I have to add all vars I want to watch manually to the watches window. Absolutely not nice.

I searched the wiki (http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks). There is a statement from April 2012 saying:

"In latest nightly builds: The automatic inclusion of local variables and function arguments have not being reimplemented. Sorry about the inconvenience. "

When do the local vars/function params are coming back?
Or are they somewhere else where I couldn't find them up to now?
This way I find the debugger interface barely useable.

Thanks for your help,

Roland

[oBFusCATed]

When do the local vars/function params are coming back?

When someone decides to reimplement them. 

This way I find the debugger interface barely useable.

I'm sure you've not used the old interface for something more complex. 

Adding watches in the new interfaces is relatively easy:
1. Select the expression in the editor, right click, add watch
2. Select the empty field at the bottom, type the expression you want to watch, hit enter

[Rosch]

When do the local vars/function params are coming back?

When someone decides to reimplement them.  

This might be a good idea...

This way I find the debugger interface barely useable.

I'm sure you've not used the old interface for something more complex.  

Adding watches in the new interfaces is relatively easy:
1. Select the expression in the editor, right click, add watch
2. Select the empty field at the bottom, type the expression you want to watch, hit enter

You are right it IS easy BUT annoying and takes time. Sure it depends on the workflow habbits.
In the past I mainly used the watches windows BECAUSE it was showing the local vars/parameters.
IMHO it is very convenient to see all available local vars in the current scope. Elsewise you always have to move the mouse over the var and wait for the tooltip timeout.

I use the "see all local vars" feature all day. If the old concept of showing local vars/parameters breaks the concept of the watches at all maybe the local vars/parametes should get an own windows - like eg. it is the case in insight. There watches and local vars are seperate windows which automatically get updated after each step of execution.

Roland

[oBFusCATed]

There watches and local vars are seperate windows which automatically get updated after each step of execution.

This is the exact problem. Adding another window. Currently there are some limitations in the wx's docking API, which prevent moving one window from one notebook to another.
I've seen that wx2.9 has this feature, so someday we can do something about this missing local variables feature. Until then probably nothing would be done.

[Rosch]

There watches and local vars are seperate windows which automatically get updated after each step of execution.

This is the exact problem. Adding another window. Currently there are some limitations in the wx's docking API, which prevent moving one window from one notebook to another.
I've seen that wx2.9 has this feature, so someday we can do something about this missing local variables feature. Until then probably nothing would be done.

"someday" this sounds like very distant future.... When I dare to read between the lines this means unplanned not forseeable future... No chance to see this in the next year or maybe even later....

So the problem is that you cannot add a new dockable window for that thing... Have I got you right? Maybe it would be a viable tradeoff to turn eg. the assembly window in a normal window (like the FPU status) and bring in a local vars window instead? (I never developed with wxwidgets so I am of no help here). But I believe the local vars view is an essential feature for the debugging interface which should not easily be sacrificed. Or ... am I ... alone with this opinion.... ?

Roland

[Jenna]

Accessing unitialised variables like the most local variables are can lead to a crash, due to a "bug" in gdb, if I remember correctly.

[oBFusCATed]

Yes, the problem with designing a good gui stops me from implementing it.
Also the other two problems:
1. It slows down single stepping a lot
2. Can lead to crashes if one is using python pretty printer
*3. There is no easy way for this to  be implemented using the gdb/mi interface as far as I know.
*4. Probably you can hack it by writing something in python which iterates all frame variables and prints them...

1 and 2 make it hardly reliable, nor usable for me.

[pitti platsch]

I am with Rosch here. Having C::B not automatically show local variables currently stops me from updating my installation.

Point 1 (slowdown): When the extra "locals/function arguments" window is not visible, there should be no slowdown in single stepping
2: Warn the user when he first tries to open the "locals/function arguments" window, that gdb sucks that this is incompatible with phyton pretty printing. Disable/hide that window by default.
3: I have almost no knowledge about GDB/MI, but http://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stack-Manipulation.html suggests "-stack-list-locals" and "-stack-list-arguments"

Does this python pretty printing bug mean that GDB could crash whenever I hover over an unitialized variable?

Peter

[oBFusCATed]

Does this python pretty printing bug mean that GDB could crash whenever I hover over an unitialized variable?

Yes, it could even enter infinite loop, which is worse.