From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14237 invoked by alias); 21 Dec 2007 22:45:14 -0000 Received: (qmail 14180 invoked by uid 22791); 21 Dec 2007 22:45:13 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Dec 2007 22:45:05 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J5q8G-00045B-2X for gdb@sources.redhat.com; Fri, 21 Dec 2007 22:14:16 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Dec 2007 22:14:16 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Dec 2007 22:14:16 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: use of python to pretty-print STL structures, etc. Date: Fri, 21 Dec 2007 22:45:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 X-IsSubscribed: yes 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: 2007-12/txt/msg00160.txt.bz2 Doug Evans wrote: > Hi. Python scripting support will eventually be added to gdb. I'd > like to better understand folks's views on if/how Python will help > with one sore spot in gdb, namely the printing of c++ data structures > in a way that is useful to the programmer, instead of the raw dump > that is done today. > > e.g. instead of > > #include > string s ("hello"); > int main () { return 0; } > > (gdb) p s > $1 = {static npos = 4294967295, > _M_dataplus = {> = > {<__gnu_cxx::new_allocator> = {}, fields>}, _M_p = 0x9783014 "hello"}} > > and staring at the output to find what one wants, or doing "p > s._M_dataplus._M_p", programmers would often rather just do something > like "p s" and get "hello". Similarily for vectors, etc. > > As I understand it, and I'm sure you'll correct me if I'm wrong :-), > the plan is to solve this problem with the new Python scripting > support. > > I realize there's no real design as of yet (at least that I'm aware > of), but my question is whether folks have thought about what it would > look like from the command line. > > At a very basic level, do folks envision keeping the current cli u/i > (*1) and enhancing it to provide python-providable extensions? Have > folks thought about how they would like the above problem to be solved > (with python or without)? > > --- > (*1): One can replace the implementation as desired, it's the u/i I'm > concerned with in this message. As you mention, no real design exists yet. What I personally plan to try is to implement MI support -- where one can have "smart" variable objects, such that the list of children is computed by Python code. For my purposes, it would be sufficient if GUI could say "use this Python" code to compute children of this variable object (or type)". For strings, we'd probably need to customize how a varobj is actually converted to text, as opposed to customizing getting children, but customizing conversion to text is easier. Anyway, the biggest part of this project appears to be exposing all the necessary functionality to python -- the value machinery, first of all. - Volodya