How to keep vars

[Leon Pollak]

Dear friends,
Just to remind - the only simple thing I asked was for the debugger interface 
to remember that my structure X was expanded previously!
That is all!

On Thursday June 11 2009, Andre Poenitz wrote:
> On Thu, Jun 11, 2009 at 09:35:14PM +0200, Andreas Pakulat wrote:
> > > It is surely possible with any debugger as long as the GUI remembers
> > > what is open and re-create it as needed.
> >
> > Well, the problem here is to know wether an item in the tree still exists
> > in the actual application. Which means we'd have to ask gdb for each
> > variable on all open subtree's if it still exists.
>
> One can just assume it's gone and delete/recreate it. That's wasteful
> but robust, and from what I can tell pretty much the best approach the
> current MI implementation "offers". The MI variables are not very well
> suited to handle C++ at all. (Who is _really_ interested in what MI
> considers a "child" of a std::vector? - not to mention that intermediate
> public/ protected/private level that MI spits out).
>
> > And as far as I know the last GDB MI version that KDevelop3 was
> > adjusted to use was anything but fast when retrieving tons of
> > variables.
>
> The expensive part does not really seem to be the number of commands,
> but the number of roundtrips through gdb, i.e. the times where you need
> to wait for a result of a response before formulating the next question.
> I've never seen a roundtrip below 30ms, even on the fastest machines,
> and things start feeling sluggish at ~150ms per step...
>
> > Hence doing that can be really expensive, especially if the
> > debugger doesn't tell you when a variable goes out of scope, you have
> > to do this refetching on each single step.
>
> Yes, would be nice if MI variables did their job, but at least from
> my perspective they don't..
>
> Andre'
>
> _______________________________________________
> kdevelop mailing list
> kdevelop at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop


-- 
Leon