Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <alves.ped@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, vladimir@codesourcery.com,
	 Tom Tromey <tromey@redhat.com>
Subject: Re: RFC: how to handle mutable types in varobj?
Date: Mon, 02 Jan 2012 16:48:00 -0000	[thread overview]
Message-ID: <4F01DFC8.9040105@gmail.com> (raw)
In-Reply-To: <20120102162146.GC2730@adacore.com>

On 01/02/2012 04:21 PM, Joel Brobecker wrote:
> Hi Pedro,
>
> Thanks for the feedback. Do you mean that the changes you are talking
> about are already in the tree?

No sorry.  I was talking about changes that were never posted.

> 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.

Yeah, something like that, but I think it'll need a bit more than
just one line setting a flag.

>
>> 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 :-).

It may well be the best in the end.  Let me see if we can get
them to you, so you can see and decide whether it's a path you
want to take.

-- 
Pedro Alves


  reply	other threads:[~2012-01-02 16:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-28 16:13 Joel Brobecker
2011-12-29 11:13 ` Joel Brobecker
2012-01-02 15:43   ` Pedro Alves
2012-01-02 16:22     ` Joel Brobecker
2012-01-02 16:48       ` Pedro Alves [this message]
2012-01-02 21:03 ` Tom Tromey
2012-01-03 17:11   ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F01DFC8.9040105@gmail.com \
    --to=alves.ped@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    --cc=vladimir@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox