From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26894 invoked by alias); 28 Dec 2011 16:00:16 -0000 Received: (qmail 26854 invoked by uid 22791); 28 Dec 2011 16:00:10 -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; Wed, 28 Dec 2011 15:59:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7862B2BADF6; Wed, 28 Dec 2011 10:59:56 -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 ULGtmrTklL0j; Wed, 28 Dec 2011 10:59:56 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F0C712BADA9; Wed, 28 Dec 2011 10:59:55 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C5A3E145615; Wed, 28 Dec 2011 07:59:43 -0800 (PST) Date: Wed, 28 Dec 2011 16:13:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org, vladimir@codesourcery.com Cc: Tom Tromey Subject: RFC: how to handle mutable types in varobj? Message-ID: <20111228155943.GD2632@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2011-12/txt/msg00873.txt.bz2 Hello, I'd like to discuss how mutable types should be handled in varobj. Here is one example involving Ada, but perhaps some other languages have them too. So, consider the case of a variant record, declared as follow: type Variant (Disc : Boolean := True) is record A : Integer; case Disc is when True => Yes : Boolean; No : Boolean; when False => D : Integer; end case; end record; This is a record where the number of components depends on the value of the discriminant (`Disc' in this case). If the discrimant is True, it has 4 components: `Disc', `A', as well as `Yes' and `No'. But if the discriminant is False, it only has 3 components now: `Disc' and `A', as before, and now `D'. The trouble with varobj starts when the value of the discriminant changes during the lifetime of the variable, which is legal in this case. If I create a varobj with a variable whose discrimant is True, then step a few lines until the discriminant changes, and then request an update, what should happen? In particular, if I had also listed the varobj's children, what should happen of them? In this situation, we go from a varobj with 4 children, to a varobj with 3 children, 2 of them still having the same type, two old children having disappeared, and one new child having appeared. At the front-end level, what should we display at the end of the -var-update command? We have several elements to consider: (1) The root varobj itself I imagine that this varobj should be listed in the changed list. As far as I can tell from the documentation, probably with the `type_changed' attribute, and probably the new number of children. (2) The "unchanged" children `Disc' and `A', whose type have changed. (3) The children varobj that have now disappeared. Should the front-end be told somehow that they have disappeared? Or do they infer this from the `type_changed' attribute? (4) The new children varobj I don't think they should be listed in the changed list, since their value is new. The thing is, I am wondering if we should include any of the varobj's children at all. Whether listing (1) with `type_changed' would be sufficient. Purely based on the reading of the documentation and then the code, I think that mutable types haven't been considered in the original design - although perhaps the authors of the original design aren't around anymore. It also seems that support for Python pretty-printing has been crafted on to varobj, and indirectly introduced the notion of dynamicity, which is probably similar in some ways to our mutability. But I am also guessing that this support was implemented in a way that kept things compatible at the GDB/MI level. As a result, I am having a hard time building a good overal picture of how things work, partly because there are so many flags: children_requested, from, to, type_changed, updated, changedm children_changed, etc. Rather than redesign the whole thing, I am wondering if we can expand a little bit on the Python dynamic properties and create the notion of mutability that we could use for both types that have a pretty-printer as well as types that are genuinely mutable. Thoughts? Thanks! -- Joel