Re: [patch] Add an evaluation function hook to Python breakpoints.

[Phil Muldoon <pmuldoon@redhat.com>]

Doug Evans <dje@google.com> writes:

> On Thu, Jan 27, 2011 at 1:41 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
>     > Since we're now overloading the "condition" member, what happens if the
>     > user sets a condition on the breakpoint?
>     >
>     > I think we may need an additional check here, to see if the "condition"
>     > member is a callable object.
>    
>     I cannot find a way to test if an attribute is callable or
>     not. There is:  PyCallable_Check but that only refers to the object
>     itself.  I think there is only a check to see if the attribute exists
>     (which we do), but as you correctly point out, as we are overloading
>     "condition" that will always return True.  For now, as we are waiting
>     for other bits of the breakpoint puzzle to fall in place, I've returned
>     the name to "eval".  It is trivial to change it in the code and tests at
>     a later date.
>
> Hi.  I'd like to understand this better.
> I'm not advocating any particular position, I just want to make sure we don't make a mistake - it is not trivial to change the published API (if it were
> we'd get rid of SENTINEL_FRAME 1/2 :-)).

I totally agree, but this is still just work-in-progress.  This only exists in
my archer branch.  I apologies for waiting so long to reply, I thought I
had already! 

>
> AIUI, the suggestion is to have "condition" be the cli breakpoint condition and "eval" be another condition available in the python breakpoint API.  Am I
> correct?
> [Apologies, it's been awhile since I looked at this.]

This was purely a collision on naming.  There is the *attribute*
"condition" which has been in the API from the very start.  You could
just set this (IE if foo == 12) and it would be analogous to the user
typing in a condition in the GDB CLI. It accepted a string, and it was
purely a textual interface to the existing GDB CLI conditions framework.   

The new stuff was the Python written condition.  This is where you could
write your condition in Python by implementing a method  called
"condition". Tom noted that if you had an old type condition, the
current code would try to execute it (so it was faulty), as the hasAttr
function will report it exists. My note was that I could not determine
if hasAttr was reporting the condition method, or the the condition
attribute.  So I renamed it back to something I used before.  My trivial
note text just indicated  that we can call it what we like when we agree
on the breakpoint work, it is a 5 minute task to do that.

Cheers

Phil