From: Vladimir Prus <vladimir@codesourcery.com>
To: Nick Roberts <nickrob@snap.net.nz>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH:MI] Return a subset of a variable object's children
Date: Wed, 28 May 2008 19:15:00 -0000 [thread overview]
Message-ID: <200805281122.52651.vladimir@codesourcery.com> (raw)
In-Reply-To: <18469.3657.466721.123119@kahikatea.snap.net.nz>
On Saturday 10 May 2008 06:54:01 you wrote:
> > > > Clearly I'm not going to do either but we could simply go back to using
> > > > the linked list structures that were already in varobj.c. It's a
> > > > question of whether the convenience outweighs the handicap of having to
> > > > work with vectors all the time or not. IMHO it doesn't.
> > >
> > > I disagree, and I haven't yet seen a practical "handicap". We're not going
> > > back to hand-written data structures for MI implementation.
> >
> > Well it's a shame that convenience should dictate the type of structures that
> > are used because I can get this patch to work with an old Gdb using linked
> > lists.
>
> As you've made your decision, the patch below isn't a RFA or RFC but a record
> for the archives to ensure it's not lost like other patches that I've left
> lying around. I feel sure that one day the issue will arise again, probably
> when Eclipse finds a requirement for it.
>
> It's against current Gdb and uses the old linked lists. This means that the
> size of the data structure is only proportional to the number of children
> created and not the total number of possible children. Unlike the previous
> patch, children are listed in sequence for both creation and update. Also
> children can be deleted. Searching for a location to insert a child in the
> list is linear (as before) but I anticipate that a front end would only ever
> create a small number at any one time and delete children (that are not
> visible) if the number became too great. In any case the search could be made
> binary (O(log N)), if necessary.
>
> Oh, yes, and it's a unified diff!
I think that the current data structures surely allow to implement the behaviour
that is useful for frontends. I raise some questions about the original version
of your patch in
http://article.gmane.org/gmane.comp.gdb.patches/40676
which you did not respond to. Did you miss that email? Do you plan to have the
original version of your patch adjusted and checked in?
For the record, the usecases that I think will benefit from this new functionality
are outlined in:
http://article.gmane.org/gmane.comp.gdb.patches/40726
Thanks,
Volodya
next prev parent reply other threads:[~2008-05-28 7:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-27 15:34 Nick Roberts
2008-04-29 15:58 ` Marc Khouzam
2008-04-30 7:02 ` Nick Roberts
2008-04-30 9:20 ` Vladimir Prus
2008-04-30 9:25 ` Nick Roberts
2008-04-30 9:39 ` Vladimir Prus
2008-04-30 16:29 ` Marc Khouzam
2008-05-01 15:56 ` Vladimir Prus
2008-05-01 17:29 ` Marc Khouzam
2008-05-01 12:15 ` Nick Roberts
2008-05-10 14:45 ` Nick Roberts
2008-05-28 19:15 ` Vladimir Prus [this message]
2008-05-29 12:01 ` Nick Roberts
2008-04-30 16:22 ` Marc Khouzam
2008-05-01 15:54 ` Vladimir Prus
2008-05-01 18:14 ` Marc Khouzam
2008-05-01 18:40 ` Vladimir Prus
2008-05-01 20:49 ` Daniel Jacobowitz
2008-05-01 23:38 ` Nick Roberts
2008-05-02 0:58 ` Marc Khouzam
2008-05-11 17:45 ` Vladimir Prus
2008-04-30 10:47 ` André Pönitz
2008-04-30 12:20 ` Vladimir Prus
2008-04-30 12:53 ` André Pönitz
2008-04-30 13:11 ` Vladimir Prus
2008-04-30 12:44 ` Nick Roberts
[not found] ` <200804301244.55116.apoenitz@trolltech.com>
2008-04-30 13:16 ` André Pönitz
2008-05-01 6:27 ` Nick Roberts
2008-05-05 11:46 ` André Pönitz
2008-04-30 14:59 ` Marc Khouzam
2008-05-01 12:06 ` Nick Roberts
2008-05-01 14:22 ` Marc Khouzam
2008-05-01 20:41 ` Daniel Jacobowitz
2008-04-30 8:59 ` Vladimir Prus
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=200805281122.52651.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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