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
next prev parent 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