From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb@sourceware.org
Subject: Re: Discussing the next GDB release (GDB 7.0?)
Date: Thu, 15 Jan 2009 17:17:00 -0000 [thread overview]
Message-ID: <m363kglcas.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20090115034552.GF24105@adacore.com> (Joel Brobecker's message of "Thu\, 15 Jan 2009 07\:45\:52 +0400")
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
Joel> To me, the only major deciding factor will be Python support.
Joel> We decided to delay a bit the release to give our Python support
Joel> a little bit of time to mature. I think that a little status
Joel> report on this project, and maybe suggestions as to what we'd
Joel> like to add to the FSF tree would be a nice starting point for
Joel> discussion.
There is a lot of code on the Python branch, but in my opinion not all
of it is merge-worthy yet.
I think a reasonable goal would be to ship the Python-based
pretty-printing feature. My reason for this particular goal is that
this code has been through a number of iterations, is in actual use by
various groups, and is an actually useful user-visible feature
(frequently requested in the last year, in fact :-)
This can be broken down into a number of patches:
* The VALUE_ADDRESS -> value_address patch. Though honestly I forget
why I wrote this.
* The struct type reference counting patch.
(This one is optional if you do not mind memory leaks in some
scenarios.)
* The gdb.Type class
(A somewhat slimmed down form, since I am not sure that the wrappers
for blocks and symbols are ready.)
* Thiago's "get string" patch (pending on gdb-patches)
* More gdb.Value methods (also pending on gdb-patches)
* The gdb.Objfile class
* The "source -p" patch
* Finally, the hooks into printing and MI, and the actual
pretty-printing glue
As a "stretch" goal we could consider support for new commands and
parameters implemented in Python, or convenience functions. I think
that code is also reasonably mature, useful, and independent from the
other Python bits.
I'm happy to start submitting the remaining patches from the list.
I'm also happy to explain what they are, in case you haven't been
following the archer list :).
Getting through them all may take a while. The good news is that a
lot of the infrastructure has already gone in.
Joel> I also propose that the next release has version number 7.0.
Joel> If everyone agrees, I'll try to create a wiki page for this
Joel> release, and move the action items from the "next release"
Joel> page to this page.
Sounds good to me.
Tom
next prev parent reply other threads:[~2009-01-15 17:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-15 3:46 Joel Brobecker
2009-01-15 4:18 ` Eli Zaretskii
2009-01-15 10:43 ` Vladimir Prus
2009-01-15 17:12 ` Joel Brobecker
2009-01-15 17:17 ` Tom Tromey [this message]
2009-01-15 17:24 ` Daniel Jacobowitz
2009-01-15 17:31 ` Joel Brobecker
2009-01-28 3:49 ` Thiago Jung Bauermann
2009-01-30 0:43 ` Joel Brobecker
2009-02-02 13:48 ` Thiago Jung Bauermann
2009-02-04 19:17 ` Tom Tromey
2009-02-06 0:48 ` Joel Brobecker
2009-01-15 17:24 ` David Daney
2009-01-15 17:37 ` Joel Brobecker
2009-01-15 23:54 ` teawater
2009-01-16 2:29 ` teawater
2009-01-16 3:40 ` Joel Brobecker
2009-01-16 6:32 ` teawater
2009-01-16 16:24 ` Tom Tromey
2009-01-16 14:30 ` Marc Khouzam
2009-01-20 18:25 ` Jakob Engblom
2009-01-21 0:18 ` teawater
2009-01-21 3:16 ` teawater
2009-01-27 5:09 ` Michael Snyder
2009-01-27 5:01 ` Michael Snyder
2009-01-30 0:48 ` Joel Brobecker
2009-01-16 3:47 ` Joel Brobecker
2009-01-16 5:48 ` Paul Pluzhnikov
2009-01-16 8:46 ` Eli Zaretskii
2009-01-16 14:55 ` Daniel Jacobowitz
2009-01-16 14:30 ` Joel Sherrill
2009-01-17 3:09 ` Joel Brobecker
2009-01-20 8:09 ` Nathan Sidwell
2009-01-20 10:41 ` Joel Brobecker
2009-01-20 11:25 ` Nathan Sidwell
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=m363kglcas.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
/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