From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8696 invoked by alias); 15 Jan 2009 17:17:46 -0000 Received: (qmail 8683 invoked by uid 22791); 15 Jan 2009 17:17:45 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Jan 2009 17:16:53 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0FHGocT019874; Thu, 15 Jan 2009 12:16:50 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0FHGo6T032181; Thu, 15 Jan 2009 12:16:50 -0500 Received: from opsy.redhat.com (vpn-12-7.rdu.redhat.com [10.11.12.7]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0FHGk98027769; Thu, 15 Jan 2009 12:16:50 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 5F44A3780C8; Thu, 15 Jan 2009 10:16:44 -0700 (MST) To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: Discussing the next GDB release (GDB 7.0?) References: <20090115034552.GF24105@adacore.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Thu, 15 Jan 2009 17:17:00 -0000 In-Reply-To: <20090115034552.GF24105@adacore.com> (Joel Brobecker's message of "Thu\, 15 Jan 2009 07\:45\:52 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00078.txt.bz2 >>>>> "Joel" == Joel Brobecker 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