From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27429 invoked by alias); 30 Apr 2008 09:20:30 -0000 Received: (qmail 27336 invoked by uid 22791); 30 Apr 2008 09:20:27 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 09:20:04 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jr8Tq-0005lv-DO for gdb-patches@sources.redhat.com; Wed, 30 Apr 2008 09:20:02 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 09:20:02 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 09:20:02 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 12:20:00 -0000 Message-ID: References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18455.41299.899430.615138@kahikatea.snap.net.nz> <200804301100.21674.apoenitz@trolltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit User-Agent: KNode/0.10.5 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/msg00689.txt.bz2 André Pönitz wrote: > On Wednesday 30 April 2008 08:24:30 Vladimir Prus wrote: >> Nick Roberts 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 There's no automatic creation. Until you do -list-children, no child is created. > and one-shot 'expression evaluation' and one-shot 'children listing'. What is 'expression evaluation'. As for one-shot 'children listing' -- the idea is that you can pass the number of children to create for -list-children, and GDB won't do anything about children beyond this range. > 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. > > Complex containers may do all kind of funny stuff behind the debugger's > back (like reallocation, rebalancing, renumbering, moving stuff to and from > secondary memory) which a frontend might want to handle transparently. > I would not expect gdb to even be aware of that (let alone to handle(!) it). > > Also, hard-wiring behaviour to certain types calls for trouble on the > frontend side. E.g. if there's a std::string member somewhere I might want > to see it as something "human readable" (-> 1 child), or a byte array > (->lots of children), or maybe a structured view if it is XML (-> some children). > So whatever behaviour is hard-wired will be wrong for n - 1 use cases. I'm afraid I don't get your point. If you want funny representations of any type you can either: 1. Use Python visualizers (that can be switched on the fly) 2. Just get the raw data and show it as you see fit. - Volodya > > Regards, > Andre'