This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Python inferior control
On Thu, Aug 26, 2010 at 1:28 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Oguz" == Oguz Kayral <oguzkayral@gmail.com> writes:
>
> Oguz> What 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.
I like this approach,
> 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?
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 ignored)
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?