Re: Python inferior control

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Oguz" == Oguz Kayral <oguzkayral@gmail.com> writes:

First, thanks for looking at this again.  This is a very important
feature; if you look at the Python API to-do list I wrote up recently,
this feature blocks any number of other nice projects... so I am very
eager to see it in the tree.

Tom> It still seems like a lot of code to define a new event. ÂBut I think we
Tom> will just live with that. ÂOr maybe there is some way to reduce its
Tom> size, through macros or something. ÂThere seems to be a fair amount of
Tom> boilerplate.

Oguz> This bothers me too, very little work is done with a lot of code.
Oguz> Actually creating an event is straightforward but it requires coding
Oguz> custom constructors, getter/setters, emit functions everytime. What
Oguz> can we do to make this easier?

I came up with two ideas.  Maybe there are more.


One is to just have a generic gdb.Event type.  It would act as a basic
wrapper around a dictionary.  A module in gdb that wants to generate an
event would make a dictionary and wrap an Event around it.

This would mean that different kinds of events would not be
differentiated by type.  To make this less troublesome we could add a
"type" field that would describe the event.


Another approach would be to take this same idea and extend it a little
to provide real event classes.  I think this could be done by having an
Event base class, as above, then individual subclasses which don't
provide any additional behavior.  Then the class objects themselves
could be wrapped up in C macros to make their definitions very short.


I don't have a very strong preference.  It seems safe to start with the
first and move to the second if needed.

Tom> I see new attributes like "stop_eventregistry". ÂI think we should drop
Tom> the "registry" part of these names.

Oguz> (not specific to stop, applies for all events.)
Oguz> A stop_eventregistry is not a stop_event. A stop_eventregistry
Oguz> contains the functions to be called when the inferior stops, a
Oguz> stop_event contains information about the event(stop_reason etc.). We
Oguz> can drop it if we can find a way to avoid confusion.

I don't think there will be much confusion if the registry name is
similar to the class name of the event that it emits.  I think this is
pretty typical in other frameworks.

In Gtk you write something like:

    object.connect ("clicked", method)

In GDB you will write something like:

    object.stop_event.connect (method)

Or am I confused about how this works?

Oguz> We decided to concentrate on thread events during GSoC. Please bring
Oguz> out any events that you can think of so I can add them.

No problem.  And FWIW I think it is completely ok for us to start with
what you wrote and add events as we go.  Actually, I would prefer that
approach.

Tom> * It seems logical to want to be able to put an event handler on a
Tom> Âbreakpoint, to notice when that breakpoint is hit.

Oguz> Can't breakpoint_stop_event already do this? I think it does *lack
Oguz> of docs* :-)

It seems to me that you might want to watch a Thread for stops, or you
might want to watch a Breakpoint.  You can achieve the latter by
watching for all stop events and then filtering -- but it seems nicer
for the user if gdb just provides the functionality directly:

    bpt = Breakpoint (...)
    bpt.stop_event.connect (callback)


And, yeah, docs and test cases are necessary.

Tom