Fwd: GDB Variables/Watches

[Mario Chacon]

Hello, I'm out of this conversation but, Is it going to work with GDB 6.8.5?

On Sat, Jun 13, 2009 at 4:28 PM, Niko Sams <niko.sams at gmail.com> wrote:

> 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.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090613/ac7c7ec4/attachment.html>