From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11825 invoked by alias); 10 Mar 2011 04:41:17 -0000 Received: (qmail 11657 invoked by uid 22791); 10 Mar 2011 04:41:15 -0000 X-SWARE-Spam-Status: No, hits= required= tests= Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Mar 2011 04:41:10 +0000 Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p2A4f8kM014149 for ; Wed, 9 Mar 2011 20:41:08 -0800 Received: from yxk8 (yxk8.prod.google.com [10.190.3.136]) by hpaq3.eem.corp.google.com with ESMTP id p2A4f62K031260 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 9 Mar 2011 20:41:07 -0800 Received: by yxk8 with SMTP id 8so619238yxk.4 for ; Wed, 09 Mar 2011 20:41:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.61.8 with SMTP id o8mr398405ybk.415.1299732065275; Wed, 09 Mar 2011 20:41:05 -0800 (PST) Received: by 10.90.20.3 with HTTP; Wed, 9 Mar 2011 20:41:05 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Mar 2011 06:47:00 -0000 Message-ID: Subject: Re: [patch] [python] Implement stop_p for gdb.Breakpoint From: Doug Evans To: Tom Tromey Cc: pmuldoon@redhat.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-03/txt/msg00627.txt.bz2 On Mon, Mar 7, 2011 at 12:48 PM, Tom Tromey wrote: >>>>>> "Doug" =3D=3D Doug Evans writes: > > Doug> - "consistency is good", so if we go with _p for stop_p we need to = go > Doug> with _p for all predicates > Doug> =A0 - are we prepared for that? > Doug> =A0 - are there any existing predicates that don't have _p? > Doug> =A0 - does python have an existing convention? > Doug> =A0 [I used stop_p at the time for clarity's sake. =A0But I think t= hese > Doug> questions need to be asked.] > > I don't think we should use _p on predicates. =A0That is not a Python > convention. "works for me" > Doug> - is the logic for deciding whether to stop correct? > Doug> =A0 E.g. if stop_p says "don't stop" and a condition says "stop" wi= ll > Doug> execution continue? =A0It looks like it, but maybe I'm misunderstan= ding > Doug> something. > > Phil> The case of the user having an old-style GDB condition, and an > Phil> implementation of a "stop_p" is an odd one. I was inclined to disal= low > Phil> it, but eventually decided against it. =A0There will be conflict if= stop_p > Phil> and condition disagree. =A0My first thoughts are "stop" should alwa= ys > Phil> trump "don't stop". What do you think? > > My view is that the conditions should be separate, and that if either > one indicates "stop", then the breakpoint should stop. > > My reason is that the Python method is an implementation detail of some > kind of "stop point" provided by a Python script. =A0It is not readily > mutable by the user. =A0On the other hand, the condition is something > explicitly under the user's control. That sounds a bit weird. The python method is part of an API. APIs are not implementation details. > If we really need to let the Python programmer prevent users from > setting a condition on one of these breakpoints, we can provide a > mechanism for doing that. =46rom my point of view it's not about letting the Python programmer prevent users from ... It's about us preventing/prohibiting a breakpoint from having both (at least for now). > Doug> For things like this I like to start slow: "It's easier to relax > Doug> restrictions than it is to impose them after the fact." > > Doug> So my vote would be to not support both in the first pass. =A0It > Doug> kinda makes intuitive sense too (to me anyway). =A0i.e. the default > Doug> implementation of "stop_p" uses the command-line condition, and if > Doug> overridden then uses the python-provided addition. > > These two statements are contradictory. =A0Or, maybe I didn't understand > one of them. > > If we unify stop_p and the user condition now, it will be hard to > separate them later -- because we will have documented that this is how > they work. > > I think the most conservative approach is to make it an error for the > user to set a condition on a breakpoint that has a stop_p method, and > vice versa. =A0That preserves the ability to make a different decision > later. That's what I'd do. I don't see the contradiction. [Remember I'm talking about an *intuitive* sense here, not any literal sense ("literal" as in something I might intend we document). If my intuitive sense doesn't work for you, you don't have to use it. :-) We seem to both agree on the end result.]