From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30379 invoked by alias); 13 Dec 2010 14:56:27 -0000 Received: (qmail 30370 invoked by uid 22791); 13 Dec 2010 14:56:26 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Mon, 13 Dec 2010 14:56:21 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBDEuBTO007068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 09:56:11 -0500 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBDEuAO2020325; Mon, 13 Dec 2010 09:56:10 -0500 From: Phil Muldoon To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch] Add an evaluation function hook to Python breakpoints. References: <201012131433.44512.pedro@codesourcery.com> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 13 Dec 2010 14:56:00 -0000 In-Reply-To: <201012131433.44512.pedro@codesourcery.com> (Pedro Alves's message of "Mon, 13 Dec 2010 14:33:44 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-12/txt/msg00184.txt.bz2 Pedro Alves writes: > Can you factor out the PyObject manipulations and the actual evaluation > of the condition to pythong/py-breakpoint.c? Say, to a > new "py_breakpoint_evaluate (struct breakpoint_object *, ...)" function. > The driving idea being to get rid of the need to now include > python-internal.h. Sure I've no problem with that. I think we would still have to include python.h (but not python-internal.h) inside a HAVE_PYTHON conditional, as the function would be exposed from py_breakpoint.c via python.h. Is that ok? Or maybe I misread your intentions. > My first reaction was 'why not call the field "condition"? "evaluate" > sounds like it's about watchpoint evaluation or some such to me. Point > being, that there are several different things that are evaluated, and > so it kind of sounds ambiguous. OTOH, there's chance of confusion with > the condition expression set with the "condition" command. Is that one > exposed to python? It may be worth it to think a bit about that, so to > make sure the docs and api doesn't end up confusing when you end up > exposing that condition too. I'm okay with whatever you guys come up > with, just pointing it out. We do expose the "condition" API currently, but it is a read-only attribute that exposes any conditions set via the CLI. I've no opinion what we should call the Python conditional evaluation. I picked "evaluate" for no particular reasons (and we are evaluating code). I'm open to ideas; changing the name is pretty trivial. Cheers, Phil