From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27295 invoked by alias); 1 May 2008 12:15:32 -0000 Received: (qmail 27285 invoked by uid 22791); 1 May 2008 12:15:31 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 12:15:05 +0000 Received: from kahikatea.snap.net.nz (108.62.255.123.dynamic.snap.net.nz [123.255.62.108]) by viper.snap.net.nz (Postfix) with ESMTP id DF5643DA3AC; Fri, 2 May 2008 00:14:57 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 228BD8FC6D; Fri, 2 May 2008 00:14:56 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18457.46138.681282.588777@kahikatea.snap.net.nz> Date: Thu, 01 May 2008 12:15:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH:MI] Return a subset of a variable object's children In-Reply-To: <200804301109.20906.vladimir@codesourcery.com> References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18456.6496.685993.987138@kahikatea.snap.net.nz> <200804301109.20906.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 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/msg00006.txt.bz2 > > Again in scientific computing, arrays often have many more than 10000 > > elements. In image processing arrays are two dimensional 512x512 with > > over 250,0000 elements. The user would have to identify the region of > > interest for the display widget, e.g. [110:120][220:230] for a 10x10 > > square centred at (115,225). > > It seems to me that specialized widgets are more suitable for this purpose, > like image viewer, or a charting component. Especially with image data, > using varobjs is probably not going to work. Creating varobjs per each item > will be just too slow -- we need some high-bandwidth interaction way, like > the memory-reading commands. (And maybe those should have stride options). Other debuggers, e.g., Totalview have this capability and it's not slow. In England, I used it on a professional basis and found it useful. >... > > > Please feel free to implement generic list datastructure in C, or > > > rewrite gdb in C++. So far, using vector proved to be big convenience. > > > > Clearly I'm not going to do either but we could simply go back to using > > the linked list structures that were already in varobj.c. It's a question > > of whether the convenience outweighs the handicap of having to work with > > vectors all the time or not. IMHO it doesn't. > > I disagree, and I haven't yet seen a practical "handicap". We're not going > back to hand-written data structures for MI implementation. Well it's a shame that convenience should dictate the type of structures that are used because I can get this patch to work with an old Gdb using linked lists. -- Nick http://www.inet.net.nz/~nickrob