From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16484 invoked by alias); 20 Sep 2010 16:13:36 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 16453 invoked by uid 22791); 20 Sep 2010 16:13:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,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: Mon, 20 Sep 2010 16:13:00 -0000 Message-ID: Subject: Re: Python inferior control From: Matt Rice To: Tom Tromey Cc: Oguz Kayral , Phil Muldoon , archer@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2010-q3/txt/msg00204.txt.bz2 On Thu, Aug 26, 2010 at 1:28 PM, Tom Tromey wrote: >>>>>> "Oguz" =3D=3D Oguz Kayral writes: > > Oguz> What can we do to make this easier? > > I came up with two ideas. =A0Maybe there are more. > > > One is to just have a generic gdb.Event type. =A0It would act as a basic > wrapper around a dictionary. =A0A 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. =A0To make this less troublesome we could add a > "type" field that would describe the event. I like this approach, > Tom> I see new attributes like "stop_eventregistry". =A0I 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. =A0I think this is > pretty typical in other frameworks. > > In Gtk you write something like: > > =A0 =A0object.connect ("clicked", method) > > In GDB you will write something like: > > =A0 =A0object.stop_event.connect (method) > > Or am I confused about how this works? i'm late to the party, nor do i really know python, with the simplified event dictionary tromey describes, and the type flag to go with it, you could just use a single stack/linked list to push/pop all types of events onto, and maybe a way to mask which events get pushed if frequency of events is a problem, maybe incrementing/decrementing a per-event type counter when events are added/removed so it could avoid looking for events that aren't there. this would allow you to easily add and remove event types without creating a specific registry and allow one to easily figure out which order the events occured in, (e.g. was the last stopped || running event a stopped or a running event?) or serialize the event stream so you could e.g. check if subsequent runs produce the same events without implementing all of the callbacks. so in general what i was thinking would look like this head->filter (list of event types that will be added or that will be ignore= d) head->bill_of_materials (event type/count to be incremented when pushing/popping) head->list_of_events or something... a callback mechanism could be added on top of this, and filter/bill_of_materials need only be implemented if (event frequency-event desire) is high i'd think it'd need to be walkable in order to implement peeking of events without removing. is this stuff on a branch somewhere?