Re: Python inferior control

[Matt Rice <ratmice@gmail.com>]

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?