From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29260 invoked by alias); 26 Aug 2010 20:28:55 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 29250 invoked by uid 22791); 26 Aug 2010 20:28:55 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: Oguz Kayral Cc: Phil Muldoon , archer@sourceware.org Subject: Re: Python inferior control References: <4C655CA0.8010205@redhat.com> Date: Thu, 26 Aug 2010 20:28:00 -0000 In-Reply-To: (Oguz Kayral's message of "Thu, 26 Aug 2010 17:02:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2010-q3/txt/msg00132.txt.bz2 >>>>> "Oguz" =3D=3D Oguz Kayral 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. =C2=A0But I t= hink we Tom> will just live with that. =C2=A0Or maybe there is some way to reduce i= ts Tom> size, through macros or something. =C2=A0There seems to be a fair amou= nt 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". =C2=A0I think we shoul= d 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> =C2=A0breakpoint, 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 =3D Breakpoint (...) bpt.stop_event.connect (callback) And, yeah, docs and test cases are necessary. Tom