From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18515 invoked by alias); 26 Aug 2010 15:02:41 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 18335 invoked by uid 22791); 26 Aug 2010 15:02:38 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: References: <4C655CA0.8010205@redhat.com> Date: Thu, 26 Aug 2010 15:02:00 -0000 Message-ID: Subject: Re: Python inferior control From: Oguz Kayral To: Tom Tromey Cc: Phil Muldoon , archer@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2010-q3/txt/msg00130.txt.bz2 On 13 August 2010 21:49, Tom Tromey wrote: > It still seems like a lot of code to define a new event. =C2=A0But I thin= k we > will just live with that. =C2=A0Or maybe there is some way to reduce its > size, through macros or something. =C2=A0There seems to be a fair amount = of > boilerplate. 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". =C2=A0I think we should d= rop > 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. =C2=A0In > particular: > * 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 > =C2=A0breakpoint, 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. =C2=A0I don't mind if we add them as ne= eded > -- 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. =C2=A0Is this a = full > enumeration of stop reasons? =C2=A0Also I am unsure about python_thread_e= xit. > 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 o= ut.