Fwd: GDB Variables/Watches

[Vladimir Prus]

On Saturday 13 June 2009 Niko Sams wrote:

> On Sat, Jun 13, 2009 at 14:51, Vladimir Prus<ghost at cs.msu.su> wrote:
> > On Saturday 13 June 2009 Niko Sams wrote:
> >
> >> Resending mail because the attachment is too large.
> >>
> >> uploaded the patch here:
> >> www.vivid-planet.com/upload/dbg.diff
> >
> > As I've said on IRC, I have two concerns about this patch:
> >
> > 1. It's big.
> True. It's not just a patch to fix locals - it's a replacement for the whole
> locals/watches/tooltip implementation. (locals are just the first
> thing I got working)
> And as the code is taken from an well working application (they even
> released a stable version)
> I think it should be not that bad.

It's probably not that bad, but I would not call it strictly better
than either KDevelop 3 or KDevelop 4.

> > 2. Substantial parts of it deal with debug helpers for display of
> > STL and other things, and we'll get that mostly for free in GDB 7.0.
> That debug helper stuff in my patch is all commented out. I'd love to drop
> that if we can use gdb python scripts for that.
> 
> > I've tried to hack something myself, and the patch is attached. While
> > it presently crashes due to me messing up order of destruction somewhere,
> > I think it will give us >50% of what we want from local variables display,
> > and it's much more smaller. As for remaining <50%, it's probably a UI
> > issue that I'll post about separately.
> If you want to complete the current code I'm of course fine with that and will
> drop the qt-creator code.
> 
> However if I will work on that we should consider using qt-creator code:
> - imho it's much easier to understand (I lost motivation when looking at
> those Variable* classes - there are so many of them related to each other)

I see only 2 (Variable and VariablesRoot) :-)

> - it's easier to port something that works
> - it's maintained by nokia, we can integrate their patches

I am not actually convinced that grabbing a bigger codebase
in order to get local variables is the best idea. And porting
patches for 500K codebase is a problem in itself.

> - we don't need to take everything (debug helper)
> - there are debugger independent classed we can just put into the platform and
> let other plugins use it

What are those debugger independent classes? If they are worthwhile and independent,
we certainly can grab them.

> We have two possibilities:
> 1. Use my patch and continue working on it
> 2. Use the current implementation, refactor debugger independent classes out 

I though you have already did some kdevplatfrom/kdevelop split. Am I misunderstand
you?

> and make it work.

After poking at debugger yesterday and today, I get the impression that "make it work"
is past, what is needed now is making it work good.

- Volodya