From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25126 invoked by alias); 5 May 2008 09:56:07 -0000 Received: (qmail 25114 invoked by uid 22791); 5 May 2008 09:56:05 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 May 2008 09:55:46 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id A745520B38 for ; Mon, 5 May 2008 11:55:42 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 85F7F20A77 for ; Mon, 5 May 2008 11:55:42 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb-patches@sources.redhat.com Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Mon, 05 May 2008 11:46:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <200804301249.08039.apoenitz@trolltech.com> <18457.25278.307960.37400@kahikatea.snap.net.nz> In-Reply-To: <18457.25278.307960.37400@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805051157.39626.apoenitz@trolltech.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00198.txt.bz2 On Thursday 01 May 2008 08:27:10 you wrote: > > > Are you arguing against the general concept of variable objects? > > > > Erm... yes. Could be seen as such. > > With respect, I'm not sure that you know what you are talking about. > > The concept of variable objects predates MI and was take from Insight. It hasn't > been developed overnight but over a long time by experienced Gdb developers, > i.e, not the likes of me. [With respect, I never was very fond of "proof by authority". Anyway, maybe I should have mentioned "for my usage pattern" or "in my environment" a bit more often. Sorry for that. Having said that, it's not uncommon that new approaches render venerable code once deviced by venerable people obsolete. For me it looks like the new Python interface has a huge potential in this direction...] > > > ... > > > Presumably your one-shot 'children listing' requires all values to be > > > printed each time. Variable objects work by just printing the values > > > which have changed. > > > > I am fully aware of that. It has a very limited utility, though... > > > > I basically have to fill, say, 20 lines in the typical 'Locals & Watchers' > > view. > > > > With a one-shot approach I can fire off 20 simple request, getting back > > 20 simple results (say, a total of 1000 bytes of data) compare them with > > the previous results myself, re-populate the view, mark changes etc. > > No big deal as it happens at most once per user interaction. Easy and > > predictable. > > How do you know if an expression is still in scope? How do you know that > an original variable is not currently shadowed by another with the same name? > How do you know how many elements are in an array, members in a structure? > These are some of the questions that variable objects address. Well, given that I have a 'program counter position' in each stack frame on the current stack and that I do 'one-shot' evaluations I would expect an expression to be evaluated in that context. Not being able to access shadowed variables does hurt _me_ not much. It's definitely less harmful than, say, getting no local variable information for constructor bodies. Apart from that, I do not even know whether a C++ object has already been constructed and whether it's safe to access it's members. Lately a coworker had a funny case (gdb 6.5 on MinGW IIRC) that accessing a variable in one stack frame and a reference to it in another yielded different values (same address, non-reproducable but witnessed by half a dozen people). I also better do a stack down and up before asking any hard questions about the current frame on MinGW as the information then just has a tendency to look better. Not to mention that I grow accustomed to ignore any reports for frames at line 150 in stl_algobase.h. Etc... I am not complaining. At all. Gdb is much more reliable and fun to work with than some other debuggers. Believe me, If I had the impression I could do your job (or even a part of that part that I am aware of) I would have probably tried ;-) So really no offense meant. I am just trying to illustrate my point that I do not expect a 100% perfect solution, and that I am therefore willing to trade _the potential_ of getting a 100% perfect solution (which I consider a non-achievable illusion anyway) for an easy-to-use solution that is not too far off. I mean, nobody uses _debugger output_ to actually _steer_ mission critical applications. The debugger is just a means to collect information. If one piece of information is missing or even wrong, well, so be it. The application itself can still be fixed. Mission accomplished ;-) > > With the 'update notifications' I get an unpredictable amount of data > > (there could be an array with a few thousand children after all, all > > being changed, stalling my communication line for an unpredicatable > > amount of time), > > This is what we're currently discussing: ways to ensure that thousands of > variable objects aren't created when viewing arrays with thousands of elements. > > > _and_ the data I get is insufficient as it, for instance, > > does not tell me that a std::string has changed somewhere in the middle. > > So I need to do a few 'one-shot evaluations' anyway to get the desired > > results. All in all, less satisfactory. > > And maybe the Python interface can address this. Indeed. But deploying the Python interface "for everything" starting with listing the locals, running custom visualizers on all of them etc basically means "no need for varobjects anymore". Which fits, more or less, into my (limited, as you noticed) view of the world ;-) Regards, Andre'