From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22577 invoked by alias); 28 Feb 2011 20:30:17 -0000 Received: (qmail 22568 invoked by uid 22791); 28 Feb 2011 20:30:16 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Feb 2011 20:30:11 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p1SKU9HP015508 for ; Mon, 28 Feb 2011 12:30:09 -0800 Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz21.hot.corp.google.com with ESMTP id p1SKTrVv008249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Feb 2011 12:30:08 -0800 Received: by gxk8 with SMTP id 8so2270500gxk.5 for ; Mon, 28 Feb 2011 12:30:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.96.2 with SMTP id y2mr7990207agl.140.1298925007708; Mon, 28 Feb 2011 12:30:07 -0800 (PST) Received: by 10.90.20.3 with HTTP; Mon, 28 Feb 2011 12:30:07 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Feb 2011 21:19:00 -0000 Message-ID: Subject: Re: [patch] [python] Implement stop_p for gdb.Breakpoint From: Doug Evans To: pmuldoon@redhat.com Cc: gdb-patches@sourceware.org, tromey@redhat.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2011-02/txt/msg00937.txt.bz2 [apologies for the dup] On Thu, Feb 24, 2011 at 1:03 AM, Phil Muldoon wrote: > Doug Evans writes: > > >> I believe I have implemented all of the requests from the previous patch > >> discussion. I eventually renamed eval to stop_p. Also, recently, Tom > >> wrote a log_printf Python command that uses this feature. I've included > >> it here, along with a few alterations Tom had to make to Breakpoint > >> initialization to make that work. > >> > >> Here it is. What do you think? > > > > Hi. > > Some nits and comments: > > > > - "consistency is good", so if we go with _p for stop_p we need to go > > with _p for all predicates > > - are we prepared for that? > > - are there any existing predicates that don't have _p? > > - does python have an existing convention? > > [I used stop_p at the time for clarity's sake. But I think these > > questions need to be asked.] > > There are two instances that I can think of where we allow the user > to implement methods that we supply the interface for. One is the > pretty-printer string, children and hint methods. The other is the > patch I sent last week for the redesign of parameters. None of those > use the _p for predicate style. As far as I can tell (with the express > disclaimer I am don't hack on actual Python code that much), there does > not seem to be a convention. I'll defer to real Python hackers > here. For my part, I don't have much of an opinion what we call it, or > if we should have a convention; I'll rely on the maintainers being > directive here ;) > The only thing I would insist on is consistency (and documentation of it). > [...] Anyway apologies for the confusion! > No worries. > - is the logic for deciding whether to stop correct? > > E.g. if stop_p says "don't stop" and a condition says "stop" will > > execution continue? It looks like it, but maybe I'm misunderstanding > > something. > > The case of the user having an old-style GDB condition, and an > implementation of a "stop_p" is an odd one. I was inclined to disallow > it, but eventually decided against it. There will be conflict if stop_p > and condition disagree. My first thoughts are "stop" should always > trump "don't stop". What do you think? For things like this I like to start slow: "It's easier to relax restrictions than it is to impose them after the fact." If it turns out there's a reasonable use for having both and the first release doesn't support that, we can easily add the support later (I think!). But if it turns out that supporting both causes a lot of trouble/confusion/wasted-time/whatever, and there's no real need for the feature anyway, then removing it later will be a lot harder (if not impossible). So my vote would be to not support both in the first pass. It kinda makes intuitive sense too (to me anyway). i.e. the default implementation of "stop_p" uses the command-line condition, and if overridden then uses the python-provided addition. This would mean changes to the u/i, I think, in order to disallow setting a condition if there is a python stop_p override, and possibly providing a note in the output of info breakpoints when there is a stop_p override (question: do these python breakpoints appear in the output of "info breakpoints?).