This is the mail archive of the
mailing list for the Archer project.
Re: Python inferior control
- From: Oguz Kayral <oguzkayral at gmail dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, archer at sourceware dot org
- Date: Thu, 26 Aug 2010 17:02:26 +0200
- Subject: Re: Python inferior control
- References: <4C655CA0.email@example.com><firstname.lastname@example.org>
On 13 August 2010 21:49, Tom Tromey <email@example.com> wrote:
> It still seems like a lot of code to define a new event. ÂBut I think we
> will just live with that. ÂOr maybe there is some way to reduce its
> size, through macros or something. ÂThere seems to be a fair amount of
This bothers me too, very little work is done with a lot of code.
Actually creating an event is straightforward but it requires coding
custom constructors, getter/setters, emit functions everytime. What
can we do to make this easier?
> I see new attributes like "stop_eventregistry". ÂI think we should drop
> the "registry" part of these names.
(not specific to stop, applies for all events.)
A stop_eventregistry is not a stop_event. A stop_eventregistry
contains the functions to be called when the inferior stops, a
stop_event contains information about the event(stop_reason etc.). We
can drop it if we can find a way to avoid confusion.
> I see that all the existing event registries are on the Thread object.
> I think this is fine, but I think we will also want to add more. ÂIn
> * We want some way to determine that the entire inferior has exited.
We decided to concentrate on thread events during GSoC. Please bring
out any events that you can think of so I can add them.
> * It seems logical to want to be able to put an event handler on a
> Âbreakpoint, to notice when that breakpoint is hit.
Can't breakpoint_stop_event already do this? I think it does *lack of docs* :-)
> There are probably more of these. ÂI don't mind if we add them as needed
> -- but it would be nice if the first release incorporating the event
> machinery were complete enough to enable some "nice" scripts.
> I am not sure about all of the logic in emit_stop_event. ÂIs this a full
> enumeration of stop reasons? ÂAlso I am unsure about python_thread_exit.
> Looking at $_exitcode seems strange -- a thread doesn't really have an
> exit code, only the inferior as a whole does.
> One place to look for ideas here is how MI does it...
The idea originally came from MI but it's wrong. Thanks for pointing this out.