From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25707 invoked by alias); 1 May 2008 15:54:52 -0000 Received: (qmail 25696 invoked by uid 22791); 1 May 2008 15:54:51 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 15:54:33 +0000 Received: (qmail 20309 invoked from network); 1 May 2008 15:54:31 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 May 2008 15:54:31 -0000 From: Vladimir Prus To: "Marc Khouzam" Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Thu, 01 May 2008 15:54:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: "Nick Roberts" , gdb-patches@sources.redhat.com References: <6D19CA8D71C89C43A057926FE0D4ADAA042910B6@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA042910B6@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805011954.31277.vladimir@codesourcery.com> 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/msg00010.txt.bz2 On Wednesday 30 April 2008 18:12:10 Marc Khouzam 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. > > > In Qt, item data is requested only when item is drawn. I think SWT's Tree > > > can be configured the same way. However, I don't think I saw any way, in > > > either, to detect than an item is no longer visible. Marc, can you tell if > > > SWT allows that? > > > > In Emacs I would just find the first and last line numbers and work out > > which elements were displayed from that. > > I'm not sure what SWT allows... > In DSF-GDB, we have a LeastRecentlyUsed queue which allows us to know which > varObj is the oldest (which implies it is not visible), and we can deleted > once we have reached our limit of 1000 varObjs. What is the practical measured advantage of that? > I still think that GDB should avoid having the requirement of 'deleting > old varObjs' toward the frontend. There's no concept of 'old varobjs' in MI protocol. You should delete variable objects as soon as whatever GUI thing you have no longer need to display the date the varobj corresponds to. > It would be nicer if GDB would keep > its efficiency, not matter what the frontend did in this case. Let's clarify what varobjs are for, in my opinion. They are primarily for implementing the 'variables' widget -- that shows local variables of a function, expressions that user wishes to be always visible, and some auxillary values. There are natural scalability bounds in the UI -- if there are no arrays involved, and you try to show 1000 items (backed by 1000 variable objects), the UI is already useless. GDB is not the problem here. Speaking about arrays, I also don't understand which use cases are been considered. I can think about those: 1. "Oops". User, without much though, opens an item in variable tree. The item happens to be array of 10000 elements. We don't want UI to block until those elements are fetched -- we want to show a few (say 10) and allow the user to get some more in case he really wanted to see something. 2. "Subset". Probably, there's some local subset of array elements that the user wants to look at. I think in that case, we should have a way to create only children in the range that user is interested in. And I think Nick's patch is just fine. 3. "Data analysis". User actually wants to make some sense of all 10000 element. Maybe, well, draw a chart. Or just look at the data. The data is integer, or some other atomic type. Then, either some specialized widget, or merely the memory view, is quite adequate. What I don't see as a valid use case is one where: 1. The size of array is too large to keep all varobj always created. 2. User would like to just scroll though all the array items, without clear intentions. Am I missing something, and this use case is actually valid? - Volodya