Re: Define python hooks

On Wed, Nov 5, 2014 at 8:50 AM, nojhan <[email protected]> wrote:
> Here are the three complete examples, I hope this will be more clear.
>
> Or in a gist:
> https://gist.github.com/nojhan/c3bc28e2fa0608f21551

Hi.

I looked at examples 1 and 2.
Re: #1: The command is executed twice, as expected, but the hook isn't
executed twice,
also as expected

Re: #2: We currently don't provide a way to access the "previous" version
of a command if it is overridden.  That would be a good enhancement alright.

I didn't have time to look at #3.

> On Wed, Oct 29, 2014 at 7:39 PM, Doug Evans <[email protected]> wrote:
>> On Tue, Oct 28, 2014 at 6:17 AM, nojhan <[email protected]> wrote:
>>> The documentation states that "It is valid for a hook to call the
>>> command which it hooks. If this occurs, the hook is not re-executed,
>>> thereby avoiding infinite recursion."
>>> But this does not seems to be true for the python API.
>>>
>>> Here what I tried:
>>> 1) Defining the hook as a python function that would gdb.execute the
>>> same command. Failed, because then the command is executed twice.
>>
>> You mean the hook is executed twice, right?
>> The docs say the hook won't be executed twice, but executing the
>> command twice is ok.
>>
>> I tried a trivial example and couldn't reproduce symptoms of the hook
>> being executed twice.
>> This is with current sources and 7.8 (release and branch).
>>
>> (gdb) define foo
>> echo Hi there.\n
>> end
>> (gdb) define hookpost-foo
>> echo Me again.\n
>> python gdb.execute("foo")
>> end
>> (gdb) foo
>> Hi there.
>> Me again.
>> Hi there.
>> (gdb)
>>
>>> Additionally, I did not find how to access the arguments of the
>>> command.
>>
>> I'm not sure what you mean here.
>> Access the arguments of the command from the hook?
>> I don't think we support that.
>>
>>> 2) Overload the existing command with a python class binded on the
>>> same command name. Failed because of infinite recursion.
>>
>> Infinite recursion because command -> hook -> command -> hook -> ...
>> or something else?
>> Just trying to understand if and how this is different from (1).
>>
>> If it's easy, providing an example so that we can see it for ourselves
>> will help.
>>
>>> 3) Use a named pipe to communicate. Failed (sort of) because one
>>> should sleep a variable amount of time waiting for the pipe to be
>>> consumed before returning to the prompt.
>>
>> I don't understand how this relates to (1) and (2).
>> Communicate what between whom?