From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11128 invoked by alias); 30 Apr 2008 10:47:50 -0000 Received: (qmail 11115 invoked by uid 22791); 30 Apr 2008 10:47:47 -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; Wed, 30 Apr 2008 10:47:28 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 6662420A49; Wed, 30 Apr 2008 12:47:25 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 4E45C202EB; Wed, 30 Apr 2008 12:47:25 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: =?iso-8859-1?q?Andr=E9_P=F6nitz?= Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 13:16:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18456.15089.160899.659599@kahikatea.snap.net.nz> <200804301244.55116.apoenitz@trolltech.com> In-Reply-To: <200804301244.55116.apoenitz@trolltech.com> Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804301249.08039.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-04/txt/msg00693.txt.bz2 [Sorry Nick for the private reply... I am still fighting the Mail client ;-}] On Wednesday 30 April 2008 11:25:05 you wrote: > > > > I was thinking that only a small number of children would ever exist > > > > simultaneously. Scrolling might make that a larger number but maybe > > > > it could be arranged to delete children that go out of view. > > > > > > I wonder if deleting children that are not visible is possible/desirable. > > > > Well, I would still prefer a simple toggle that would allow me to switch off > > any automatic creation of children and one-shot 'expression evaluation' > > > > and one-shot 'children listing'. > > Are you arguing against the general concept of variable objects? Erm... yes. Could be seen as such. Variable objects are really nice and useful for displaying C-like structure if you want a 1:1 display in the frontend when all (or at least most of) the state you need can be kept in the debugger. However, anything beyond that gets ugly and as soon as one arrives at the point where one basically duplicates a lot of the internal backend state in the frontend one develops the desire not to need to care for the backend state at all... > > I would expect this to be much simpler to implement on the gdb side and > > gives all the flexibility needed (as far as I am concerned) on the > > frontend side. > > 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. 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), _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. Andre' >