From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3423 invoked by alias); 24 Aug 2010 20:06:05 -0000 Received: (qmail 3322 invoked by uid 22791); 24 Aug 2010 20:05:51 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Aug 2010 20:05:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7OK5eOe030662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Aug 2010 16:05:40 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7OK5ea5003728; Tue, 24 Aug 2010 16:05:40 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o7OK5d4S019121; Tue, 24 Aug 2010 16:05:39 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id AE6BC3780C2; Tue, 24 Aug 2010 14:05:38 -0600 (MDT) From: Tom Tromey To: =?utf-8?B?QW5kcsOpIFDDtm5pdHo=?= Cc: gdb@sourceware.org Subject: Re: Python API plans References: <201008241138.46655.andre.poenitz@nokia.com> Date: Tue, 24 Aug 2010 20:06:00 -0000 In-Reply-To: <201008241138.46655.andre.poenitz@nokia.com> (=?utf-8?Q?=22An?= =?utf-8?Q?dr=C3=A9_P=C3=B6nitz=22's?= message of "Tue, 24 Aug 2010 11:38:46 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 2010-08/txt/msg00143.txt.bz2 >>>>> "Andr=C3=A9" =3D=3D Andr=C3=A9 P=C3=B6nitz = writes: Andr=C3=A9> I think inferior interaction (run/stop stuff) and breakpoint Andr=C3=A9> access are the big "missing" areas in Python support. From a Andr=C3=A9> frontend's point of view the missing "run control" is actually Andr=C3=A9> not that bad as it is sufficiently well supported by MI (in Andr=C3=A9> contrast to breakpoints), but from a CLI/Python user's point of Andr=C3=A9> view the priorities are probably inverted. Yeah, I think so. I am not as much an MI expert as I would like to be... feedback like this is very valuable. Tom> * Write Python wrappers for all MI commands, see: Tom> http://sourceware.org/bugzilla/show_bug.cgi?id=3D11688 Andr=C3=A9> Similar here. The effective gain seems limited, especially sinc= e quite Andr=C3=A9> a bit of the MI commands are not optimal themselves. As a reall= y awful Andr=C3=A9> example: "-data-read-memory" produces a lot of unneeded "inform= ation" Andr=C3=A9> yet is so slow that a "dump binary memory"/read-from-file combi= nation Andr=C3=A9> easily beats it by a factor of two or three. That behaviour sho= uld not=20 Andr=C3=A9> be wrapped in Python. Andr=C3=A9> I could imagine handling that item on a case-by-case base and s= pending Andr=C3=A9> an extra thought or two on each individual API might make more = sense. There are definitely MI features that, IMO, are not useful to Python. Varobj comes to mind. The idea behind this is to reuse all the existing ui-out machinery to mostly automate Python wrappers to internals. It isn't as nice as the hand-written approach. Given your comment I think a good first step would be to review the MI docs to get an idea of what is missing from the Python API. If we're close enough to full coverage then we don't really need this. Tom> * Make a new Expression object that represents a parsed expression. Tom> Add a new gdb.parse method to create these, something like: Tom> gdb.parse (EXPR, [BLOCK], [STOP_AT_COMMA]) -> gdb.Expression Tom> This functionality is handy for writing certain kinds of commands. Andr=C3=A9> What's the use case? Keeping "anything" on the inferior side? It can be handy to separate parsing from evaluation. For example if you wanted to write the "log a variable" command, you could use this to parse the expression, then keep the parsed representation around so that evaluating it at the breakpoint would be more efficient. This reminds me, another possible breakpoint-related cleanup is pushing more things into breakpoint_ops and then exposing this to Python. It would be nice for various breakpoint-like commands in Python to have more control over how their mechanics are presented to the user. Tom> * "declare $var : type" - make $var a reference to Andr=C3=A9> I have a similar construct five times in my code (creating an Andr=C3=A9> initialized gdb.Value, but that 'declare' is the first step) I Andr=C3=A9> think having it handled in gdb would be nice, especially if it Andr=C3=A9> relieves me from figuring out when to add 'class ' to the type, Andr=C3=A9> and when to quote it etc to 'survive' gdb command line parsing. Please file bugs for problems like this. I think we've made big strides in eliminating random quoting; we definitely want to know about remaining bugs. Andr=C3=A9> Another open issue in the area is to provide a way to keep Andr=C3=A9> (structure) return values of inferior calls alive in the Andr=C3=A9> inferior. Right now the only way I am aware of to chain or nest Andr=C3=A9> inferior calls is to poke data back manually. Yeah, we plan to fix this, it just isn't specifically a Python task. Tom