From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16368 invoked by alias); 3 Jan 2014 18:52:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 16352 invoked by uid 89); 3 Jan 2014 18:52:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f169.google.com Received: from mail-ve0-f169.google.com (HELO mail-ve0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 03 Jan 2014 18:52:12 +0000 Received: by mail-ve0-f169.google.com with SMTP id c14so8196830vea.14 for ; Fri, 03 Jan 2014 10:52:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V+kNnMYL4ggizdg6XcHa9aqFrGErZ4utYlWLK2I9VRk=; b=lDlV6BG0W1A76ZnadDCwXIVGrfdwuuMUa2iHWvimvWXkiSY6T+ziLH0ZIxUMkp1bLH MEEgYPS4IhvbbiJx7bnupaPjDLUpoesxlZb998hQ1RCNCUS2g3SF3jrnQq3Tzmhd+1Fl vfcTWGorH/SyLARV6U26vA12dI6i7zM9LO3uaPBe6fkh2DuZcUC/B4Sc7Rhrwk5LzGcd kTomiEEHEnwZFZP3Yxw5hOGVX2CNBuESLAJVdNqtv+lwWjOiBMBF9L2PNvXmaQQupLLF HZZ4uaCz4u2KCaHYQ+honrW7UBVnfA3EcWFkVofqhq7r6BtqojSo2DkupJbVcAD7hMYY WCqQ== X-Gm-Message-State: ALoCoQlwBLPdYA9Btvu/aX/cDyKIYyEFBKY8Y335gg3dYd9O7BG7bQaoyEqEXHgtkjpkrbl1i99R72tLZtAaRlpoIIYvt6kPQCPaEPTv1uGRntPqeO6cPoYPfO1GkPK8NzcGF8nvtmZRx0zflEsdXye9Qs5TN70Xb6K8afkau2+gDCOtpEZ12vXxvHg3vbp7aIfD6N+v6kS0Mb+N738cL9UjXfzHYXBS4Q== MIME-Version: 1.0 X-Received: by 10.58.67.9 with SMTP id j9mr54788565vet.3.1388775130624; Fri, 03 Jan 2014 10:52:10 -0800 (PST) Received: by 10.52.248.65 with HTTP; Fri, 3 Jan 2014 10:52:10 -0800 (PST) In-Reply-To: References: Date: Fri, 03 Jan 2014 18:52:00 -0000 Message-ID: Subject: Re: [PATCH] Debug Methods in GDB Python From: Doug Evans To: Siva Chandra Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00010.txt.bz2 On Wed, Jan 1, 2014 at 4:23 AM, Siva Chandra wrote: > On Mon, Dec 16, 2013 at 9:56 AM, Doug Evans wrote: >> I wonder, though, about the match method returning True/False vs the >> pretty-printer way of the lookup object returning an object that then >> does the printing. >> [In the debug method case the lookup method might want to return a >> list if the method is overloaded.] >> Unless there's a compelling reason to be different, I like >> "Consistency Is Good", so that's what I'm shooting for. >> [But if there is a compelling reason to be different, I'm not opposed >> to being different here.] > > Though I had responded to this part before, I had made a note to > revisit it. Some of the points I make are really subjective based on > my personal feel. > > In the pretty printers world, a pretty printer is a callable which > returns an object (which has a specific API) which can do the > printing. So, a pretty printer is really not doing the printing, it > returns a printer. For me, this is really odd: an object which is an > instance of PrettyPrinter does not do the printing, but returns a > printer in turn. The concept feels sufficiently useful that I cope with the naming. > I did not want debug methods to be like pretty printers. As in, a > debug method should be _the_ method and not return a method. If a > debug method were to be a match-er which returns a method, then we > would need to enforce two APIs, one for the match-er and another for > the method. Also, for debug methods, the method part will not be > purely a method as it still needs to do argument matching. That's a fair point, but we need to not conflate how things are named with how they are used / what they look like. I like having the object gdb calls to do the lookup return another object that gdb calls to implement the functionality. 1) It supports more flexibility in how the user can organize things (e.g., one "lookup" object can handle different "worker" objects). 2) The worker object can obtain state at runtime (it is constructed at lookup time). [I'm not sure I phrased that sufficiently well. I'm trying to enumerate what the pretty-printer way of doing things brings to the table, so to speak.] > As it stands in the latest patch, I feel the debug methods API is a > bit verbose. The debug method base class has a "match" method and a > "get_argtypes" method which need to be overridden by a specific debug > method implementation. To cater to templates, both these methods > currently take the "class_type" and "method_name" arguments. This > makes the debug method objects almost stateless (almost because they > have "name" and "enabled" fields). A simple way to fix this is to > rename the "match" method to "init". The "init" method will be exactly > the same as the match method. It will take exactly the same arguments > as the "match" method and return True/False based on a match/mismatch. > However, since it is named "init", it will be expected to save enough > state so that the "get_argtypes" method need not take any arguments. Note that this kind of simplification can fall out of the two step lookup+worker approach: construction of the worker could save the needed state so that it didn't have to be passed back to subsequent methods. [Blech. "method" is getting too overloaded here. :-)] ["init" is a bit too close to __init__, but that could be fixed if one went that route.] > If we can agree on the basic API, I will send out a patch which > addresses the formatting issues which Doug pointed out sometime back. > > Thanks, > Siva Chandra > [I have just noticed that it is a week shy of an year that I had sent > my v1 patch for this feature. Hope this feature lands in 2014.]