From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14223 invoked by alias); 7 Oct 2011 15:40:22 -0000 Received: (qmail 14013 invoked by uid 22791); 7 Oct 2011 15:40:19 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 07 Oct 2011 15:40:01 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p97Fe0Jt025685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 11:40:00 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p97Fe0WB010844; Fri, 7 Oct 2011 11:40:00 -0400 Received: from barimba (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 p97FdxYN015852; Fri, 7 Oct 2011 11:39:59 -0400 From: Tom Tromey To: GDB Development Subject: Re: Python and structured output from breakpoint_ops References: Date: Fri, 07 Oct 2011 15:40:00 -0000 In-Reply-To: (Tom Tromey's message of "Fri, 07 Oct 2011 09:15:35 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2011-10/txt/msg00040.txt.bz2 Phil> So in print_one's case, the parent does not call the child function Phil> until it has already populated all of the fields before address. So Phil> there are only two fields left to fill: "address", and "what". They Phil> have to be a long and a string. [...] Phil> Given that all one can return in the above context is Phil> essential a long and a string, I'm not sure what value we can add by Phil> letting the user return anything else? We would have to convert any list Phil> within the tuple to a string anyway. I'd prefer users just do this Phil> themselves in Python. Phil> The same goes for print_stop_action. This tells GDB what to print (via Phil> an enum) when the breakpoint stops. Phil> So again we are limited to a string and a constant. I guess we could, Phil> if the user passed a list within a list, call ui_out_list there. But to Phil> me, you will only ever want this output on one line (in fact, it may be Phil> a requirement, I am not to sure). I don't think it has to be. Phil> There seems to be more room to maneuver with print_mention, and Phil> print_one_detail. They are currently implemented as pure strings. But Phil> again, both I believe (and really, I want) to be implemented as a single Phil> string. print_mention is called when a breakpoint is created. Is there Phil> an example of what kind of structured output we could use here? I think I was hoping that we could unify some of the print methods. It seems strange to have 4 different method to print more or less the same basic information. This might mean constraining the output a little bit in order to provide a simpler API. I think that would be good, but that is just my opinion; however, if it turned out to be too limiting we could always extend the options later. Even if all the methods can't be unified it seems that at least print_one and print_one_detail could be. Phil> print_one_detail is an optional detail line below each entry for "info Phil> breakpoints". This has to be limited to a single line, to remain Phil> constant with "info breakpoints" output. It seems like it could have multiple lines, just nothing does this yet. This is a good example of where structured output is useful: right now the code has to know how to format the continuation lines (e.g., start with a tab) -- but it seems like it would be better not to bake this into Python scripts everywhere, in case we want to change the "info break" formatting in the future. Some kind of structured result would let us do this. Phil> In fact, if you look at the mi command -break-list, it just maps Phil> to info break and captures that output. Maybe that conversation Phil> is what Jan was talking about when there is an explicit mention Phil> that any field change has to be made by Vlad? I wouldn't worry about the field name thing in this discussion. We're already talking about extensions to gdb from third parties, nothing in the core. However, another important thing is that the print_* methods work from both MI and the CLI. Otherwise, -break-list is going to print garbage when someone installs one of these Python-created breakpoints. Tom