Re: [Nemiver-list] global variables support patch

[Dodji Seketeli <dodji domain hid>]

On Tue, 25 Sep 2007 01:12:23 +0200,
"A. Gordon" <agordon88 domain hid> wrote :


> >   
> You can merge the low level parts without any worries. As long as
> nobody calls "IDebugger::list_global_variables()",
> there shouldn't be any problem, as nothing new will be executed.

Okay. 
 
> However...
> > The other alternative is that I work on making variables
> > dereferencing work first, and then apply your patches.
> >   
> I Like this alternative better - no use of merging half work now,
> which will probably need modifying in the future.
> Better complete your changes, and I'll catch up with them, hopefully
> with an improved global variables support.

Oops :-) Actually, I wanted to understand where we were spending the
time so I did some profiling. At the beginning of the process, nemiver
was taking 7 minutes on my box to display the list of global variables
of fooprog. After some profiling and some optimisations, the time is
now a between 1 and 2  minutes. What I did was basically make sure to
not to use the O(n) access function of UString (as those strings are
utf8 strings), but rather O(1) access functions, mostly in the gdbmi
parser. I also optimized some things that we use for logging.

Those slow code paths were not specific to global variables parsing so
hopefully nemiver will get snappier with this work. The global
variables patch just provided us with a nice testbed to iron out those
code slow code paths.

This work applies to my private branch where I am working on
IVarWalker. I will push it when it is ready, which means either tomorrow
or the day after. I will then stick an update of your patch into
bugzilla, under the same bug as the previous instance of the patch.

When that's done, I will continue hacking on variables
dereferencing based on the IVarWalker interface.

[...]

> For the global variables, the first (major) improvement is that they
> should only be listed once (when the program loads) and not on every
> "stop" signal (inside "LocalVarsInspector::on_stopped_signal"). Once
> listed, they should be stored in a list, and only re-queried about
> their values every "stop" signal.

Yes. Please note that on my branch, global variables are listed once per
frame. If you step multiple times but stay in the same function frame,
they are listed only once. But yes, they could be listed only at startup
time.

Even better, what would you think about having a widget that lets you
query the list of globals at will ?

> 
> I'll try to do so soon and send an update.

Okay, I think you should maybe wait until I push the changes I have
made to your patch first.
 
> > Any thoughts ? if anyone has an idea about this topic, please do no
> > hesitate to jump in and comment :-)
> >   
> Let me explain my original need for viewing global variables: I
> needed a simple GUI debugging solution for a very basic course in unix
> programming for a local college. The programs written on that course
> are very simple (mostly a single "c" file, with some global
> variables) - To debug these programs, the global-variables patch was
> sufficient. But obviously, as you have shown with "fooprog", the
> current patch isn't suitable for large real-world applications.

Very interesting. So your students were using nemiver then :-) nice to
konw.

> At the moment, I'm thinking about maybe turning the global variables
> into an optional thing (Edit->Preferences?) so the user can choose
> whether he/she wants to see the global variables.

Yes. So that matches quite well the idea of hacking a widget that could
be added a new "global variables" tab at the bottom of nemiver for now.
The user could right click and update the state of global variables at
will.

Cheers,


-- 
Dodji Seketeli
http://www.seketeli.org/dodji