Fwd: GDB Variables/Watches

[Niko Sams]

On Sat, Jun 13, 2009 at 19:47, Vladimir Prus<ghost at cs.msu.su> wrote:
> 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.
As I said - it's not just about getting local variables.

>> - 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.
I was talking about WatchHandler and WatchData. Those would be instead of
Variable and VariableCollection. So if we use the current code we would have
to make Variable and VariableCollection generic.

>> 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?
yes, but not variables. That's the main thing missing.

>> 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.
sounds good, but continue that poking :D

I'll leave my experiment for now and try to get into the current variable code.


Niko

PS:
Just played around with the qstring pretty printer you sent - works great!
Soo much simpler than this debug helper.