From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5745 invoked by alias); 2 Jan 2012 16:22:17 -0000 Received: (qmail 5734 invoked by uid 22791); 2 Jan 2012 16:22:15 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Jan 2012 16:22:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EA77F2BAF9E; Mon, 2 Jan 2012 11:22:01 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fymCP70jk8re; Mon, 2 Jan 2012 11:22:01 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5FFC02BAF9D; Mon, 2 Jan 2012 11:22:01 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C8199145615; Mon, 2 Jan 2012 20:21:46 +0400 (RET) Date: Mon, 02 Jan 2012 16:22:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org, vladimir@codesourcery.com, Tom Tromey Subject: Re: RFC: how to handle mutable types in varobj? Message-ID: <20120102162146.GC2730@adacore.com> References: <20111228155943.GD2632@adacore.com> <20111229111024.GT23376@adacore.com> <4F01D098.6050206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F01D098.6050206@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2012-01/txt/msg00044.txt.bz2 Hi Pedro, Thanks for the feedback. Do you mean that the changes you are talking about are already in the tree? My interpretation of the current code was that python pretty-printing was implemented a little ad hoc, almost as an exception to the normal varobjs... That's why I am a little confused by the process your went through. That being said, It's been a few days since I looked at the code, and it took me a long time to start understanding the code better. I might simply still be missing many things - I need to study the code again in detail to comment in detail. In the meantime: > Implementing Ada mutable types support through this would mean mutable > varobjs would be exposed as dynamic=1 varobjs. I'm not sure that'd be > a problem? GDB would set the dynamic property, right? That would work for me. > With frontends that currently support dynamic varobjs, > things should simply work. Non dynamic varobjs were kind of a mistake > anyway (a !dynamic varobj that is bound to an 10000000 element array > is wholly fetched in gdb memory at once...). Agreed! > That said, if you don't want to go that way, it's fine with me. Just > putting it out there.. I would like to do what's right once and for all :-). Of course, if the "right thing" is costing too much effort, then I might look for compromises. But for now, I am still looking for guidance in terms of the varobj interface itself, and achieve compliance. For instance, I had imagined the case where some children of a varobj that has mutated might still be around. But unlike you, I thought I'd keep it as simple as possible to start, so if it was sufficient to just reset all the children, well that is an easy thing to do :-). -- Joel