[RFA] New Event Model Prototype

[RFA] New Event Model Prototype

[Keith Seitz]

Hi,

At long last, I have gotten around to doing a little work on this.

Here is the first part of my proposal to change from "add/remove_hook 
FOO_EVENT command" to simply overloading a method inherited from GDBWin.

Comments enjoyed. More comments interspersed with patches. Look for "%%%".
Keith

I've ommitted bits and pieces of the "real" patch to help people digest 
this change a little. There are also pending changes to bpwin.it[hb] and 
srctextwin.it[hb].

2001-04-10  Keith Seitz  <keiths@cygnus.com>

        * library/interface.tcl (gdb_breakpoint_change_hook): Mark
        as deprecated and comment out definition.
        (gdbtk_tcl_breakpoint): Use new GDBWin event "breakpoint"
        to notify rest of UI about breakpoint event.
        (gdbtk_tcl_tracepoint): Ditto for "tracepoint" event.
        * library/gdbwin.ith (dispatch): New public proc.
        (breakpoint): New public proc.
        (tracepoint): New public proc.
        (update): Delete unused method. Will come
        back later.
        (_state): Delete unused variable.
        (constructor): Delete debug statement.
        (destructor): Ditto.
        * library/gdbwin.itb: New file. Implements new event
        model.
        * tclIndex: Regenerated.

Index: library/gdbwin.ith
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/gdbwin.ith,v
retrieving revision 1.2
diff -p -u -r1.2 gdbwin.ith
--- gdbwin.ith	2001/02/08 19:26:31	1.2
+++ gdbwin.ith	2001/04/10 15:54:44
@@ -13,14 +13,30 @@
 
 
 class GDBWin {
-  private variable _state
-  public method update
 
- constructor {args} {
-    debug "$args"
-  }
+  constructor {args} {}
+  destructor {}
 
-  destructor {
-    debug
+  #
+  # Events
+  #
+  public {
+    # Dispatching proc. ALL events should be funneled through this
+    # procedure.
+    proc dispatch {event args}
+
+    # Breakpiont/tracepoint creation/deletion/modification
+    # ACTION    - "create", "modify", "delete"
+    # NUM       - gdb's internal token for the bp/tp
+    # ADDR      - the address at which the breakpoint is set
+    # LINE      - line number of this address
+    # FILE      - source file name containing the address
+    # TYPE      - what gdb will do with bp/tp: "delete", "delstop",
+    #             "disable", "donttouch" (see breakpoint.h "enum bpdisp")
+    # ENABLED   - is the bp/tp enabled?
+    # THREAD    - thread number of thread-specific bp or -1 if don't care
+    # PASSCOUNT - pass count of the tracepoint
+    method breakpoint {action num addr line file type enabled thread} {}
+    method tracepoint {action num addr line file passcount} {}
   }
 }

%%% I've chosen to start with breakpoints/tracepoints. So the idea is 
that when I (a window/widget/plugin writer) want to know about some event 
FOO, is simply override a method of GDBWin which corresponds to FOO. ALL 
of these events should be defined in this header file. Right now, I am 
starting with breakpoint and tracepoint events.

gdbwin.itb (which is new):
# GDBwin class implementation for Insight.
# Copyright 2001 Red Hat, Inc
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License (GPL) as published by
# the Free Software Foundation; either version 2 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

body GDBWin::dispatch {event args} {

  # Determine what event handler to call.
  switch $event {
    breakpoint   { set handler breakpoint }

    tracepoint   { set handler tracepoint }

    default { dbug E "unknown event: \"$event\""; return }
  }

  # invoke event handlers
  foreach w [itcl_info objects -isa GDBWin] {
    dbug I "posting event \"$event\" to \"$w\""
    set err [catch {eval $w $handler $args} errMsg]
    if {$err} {
      dbug E "On $event event, $w errored:\n$errMsg"
    }
  }
}

%%% In gdbwin.itb, we simply have the all-important dispatch proc, which 
will be replacing "run_hooks" in interface.tcl (see interface.tcl patch 
below). I've included some error handling and debugging here to 
facilitate flushing out any potential problems. This is pretty defensive 
code (since I don't trust gdb ;-).

 Index: library/interface.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
retrieving revision 1.15
diff -p -u -r1.15 interface.tcl
--- interface.tcl	2001/04/05 00:04:28	1.15
+++ interface.tcl	2001/04/10 15:55:27
@@ -16,9 +16,10 @@
 global gdbtk_state
 set gdbtk_state(busyCount) 0
 
+# *** DEPRECATED: Use GDBWin::dispatch event "breakpoint" instead.
 # This is run when a breakpoint changes.  The arguments are the
 # action, the breakpoint number, and the breakpoint info.
-define_hook gdb_breakpoint_change_hook
+#define_hook gdb_breakpoint_change_hook
 
 # This is run when a `set' command successfully completes in gdb.  The
 # first argument is the gdb variable name (as a Tcl list).  The second
@@ -445,7 +446,7 @@ proc gdbtk_tcl_end_variable_annotation {
 # ------------------------------------------------------------------
 proc gdbtk_tcl_breakpoint {action bpnum addr line file bp_type enabled thread} {
 #  debug "BREAKPOINT: $action $bpnum $addr $line $file $bp_type $enabled $thread "
-  run_hooks gdb_breakpoint_change_hook $action $bpnum $addr $line $file $bp_type $enabled $thread
+  GDBWin::dispatch breakpoint $action $bpnum $addr $line $file $bp_type $enabled $thread
 }
 
 # ------------------------------------------------------------------
@@ -453,7 +454,7 @@ proc gdbtk_tcl_breakpoint {action bpnum 
 # ------------------------------------------------------------------
 proc gdbtk_tcl_tracepoint {action tpnum addr line file pass_count} {
 #  debug "TRACEPOINT: $action $tpnum $addr $line $file $pass_count"
-  run_hooks gdb_breakpoint_change_hook $action $tpnum $addr $line $file tracepoint
+  GDBWin::dispatch tracepoint $action $tpnum $addr $line $file $pass_count
 }
 
 # ------------------------------------------------------------------

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

FYI: Keith has already explained this to me personally when he visited
Toronto some time ago.

We are asking for some comments.  Keith will probably start making these
changes sometime next week.

Here is some background:

The Insight events are handled in a publish-subscribe model.  Current
you subscribe in your constructor with something like:

add_hook gdb_update_hook "$this update"

and have to explicitly unsubscribe in you destructor.

When an event happens, the "run_hooks" code (hooks.tcl) will notify all
that subscribed to that event.

Keith's idea is to use the itcl machinery as the manager of
subscriptions and the dispatcher.  You will now subscribe by overloading
a method and the dispatch will figure who subscribed by introspection in
the itcl object metadata:

 foreach w [itcl_info objects -isa GDBWin] {


As this is implemented in C, we hope that the performance will be good.


Nothing else changes: the code in interface.c still plays the "Change
Manager" (or "Mediator") role.  It will still convert GDB events, or
internally generated events, into notifications to the subscribed
observers (sent via GDBWin).


For now, we will continue with the somewhat ad hoc set of events and
confuse notion of observed subjects.  This is an independent work that
has to be done eventually. It will require a very careful planning
involving the GDB people in the discussion.

Fernando


Keith Seitz wrote:
> 
> Hi,
> 
> At long last, I have gotten around to doing a little work on this.
> 
> Here is the first part of my proposal to change from "add/remove_hook
> FOO_EVENT command" to simply overloading a method inherited from GDBWin.
> 
> Comments enjoyed. More comments interspersed with patches. Look for "%%%".
> Keith
> 
> I've ommitted bits and pieces of the "real" patch to help people digest
> this change a little. There are also pending changes to bpwin.it[hb] and
> srctextwin.it[hb].
> 
> 2001-04-10  Keith Seitz  <keiths@cygnus.com>
> 
>         * library/interface.tcl (gdb_breakpoint_change_hook): Mark
>         as deprecated and comment out definition.
>         (gdbtk_tcl_breakpoint): Use new GDBWin event "breakpoint"
>         to notify rest of UI about breakpoint event.
>         (gdbtk_tcl_tracepoint): Ditto for "tracepoint" event.
>         * library/gdbwin.ith (dispatch): New public proc.
>         (breakpoint): New public proc.
>         (tracepoint): New public proc.
>         (update): Delete unused method. Will come
>         back later.
>         (_state): Delete unused variable.
>         (constructor): Delete debug statement.
>         (destructor): Ditto.
>         * library/gdbwin.itb: New file. Implements new event
>         model.
>         * tclIndex: Regenerated.
> 
> Index: library/gdbwin.ith
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/gdbwin.ith,v
> retrieving revision 1.2
> diff -p -u -r1.2 gdbwin.ith
> --- gdbwin.ith  2001/02/08 19:26:31     1.2
> +++ gdbwin.ith  2001/04/10 15:54:44
> @@ -13,14 +13,30 @@
> 
> 
>  class GDBWin {
> -  private variable _state
> -  public method update
> 
> - constructor {args} {
> -    debug "$args"
> -  }
> +  constructor {args} {}
> +  destructor {}
> 
> -  destructor {
> -    debug
> +  #
> +  # Events
> +  #
> +  public {
> +    # Dispatching proc. ALL events should be funneled through this
> +    # procedure.
> +    proc dispatch {event args}
> +
> +    # Breakpiont/tracepoint creation/deletion/modification
> +    # ACTION    - "create", "modify", "delete"
> +    # NUM       - gdb's internal token for the bp/tp
> +    # ADDR      - the address at which the breakpoint is set
> +    # LINE      - line number of this address
> +    # FILE      - source file name containing the address
> +    # TYPE      - what gdb will do with bp/tp: "delete", "delstop",
> +    #             "disable", "donttouch" (see breakpoint.h "enum bpdisp")
> +    # ENABLED   - is the bp/tp enabled?
> +    # THREAD    - thread number of thread-specific bp or -1 if don't care
> +    # PASSCOUNT - pass count of the tracepoint
> +    method breakpoint {action num addr line file type enabled thread} {}
> +    method tracepoint {action num addr line file passcount} {}
>    }
>  }
> 
> %%% I've chosen to start with breakpoints/tracepoints. So the idea is
> that when I (a window/widget/plugin writer) want to know about some event
> FOO, is simply override a method of GDBWin which corresponds to FOO. ALL
> of these events should be defined in this header file. Right now, I am
> starting with breakpoint and tracepoint events.
> 
> gdbwin.itb (which is new):
> # GDBwin class implementation for Insight.
> # Copyright 2001 Red Hat, Inc
> #
> # This program is free software; you can redistribute it and/or modify it
> # under the terms of the GNU General Public License (GPL) as published by
> # the Free Software Foundation; either version 2 of the License, or (at
> # your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
> 
> body GDBWin::dispatch {event args} {
> 
>   # Determine what event handler to call.
>   switch $event {
>     breakpoint   { set handler breakpoint }
> 
>     tracepoint   { set handler tracepoint }
> 
>     default { dbug E "unknown event: \"$event\""; return }
>   }
> 
>   # invoke event handlers
>   foreach w [itcl_info objects -isa GDBWin] {
>     dbug I "posting event \"$event\" to \"$w\""
>     set err [catch {eval $w $handler $args} errMsg]
>     if {$err} {
>       dbug E "On $event event, $w errored:\n$errMsg"
>     }
>   }
> }
> 
> %%% In gdbwin.itb, we simply have the all-important dispatch proc, which
> will be replacing "run_hooks" in interface.tcl (see interface.tcl patch
> below). I've included some error handling and debugging here to
> facilitate flushing out any potential problems. This is pretty defensive
> code (since I don't trust gdb ;-).
> 
>  Index: library/interface.tcl
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
> retrieving revision 1.15
> diff -p -u -r1.15 interface.tcl
> --- interface.tcl       2001/04/05 00:04:28     1.15
> +++ interface.tcl       2001/04/10 15:55:27
> @@ -16,9 +16,10 @@
>  global gdbtk_state
>  set gdbtk_state(busyCount) 0
> 
> +# *** DEPRECATED: Use GDBWin::dispatch event "breakpoint" instead.
>  # This is run when a breakpoint changes.  The arguments are the
>  # action, the breakpoint number, and the breakpoint info.
> -define_hook gdb_breakpoint_change_hook
> +#define_hook gdb_breakpoint_change_hook
> 
>  # This is run when a `set' command successfully completes in gdb.  The
>  # first argument is the gdb variable name (as a Tcl list).  The second
> @@ -445,7 +446,7 @@ proc gdbtk_tcl_end_variable_annotation {
>  # ------------------------------------------------------------------
>  proc gdbtk_tcl_breakpoint {action bpnum addr line file bp_type enabled thread} {
>  #  debug "BREAKPOINT: $action $bpnum $addr $line $file $bp_type $enabled $thread "
> -  run_hooks gdb_breakpoint_change_hook $action $bpnum $addr $line $file $bp_type $enabled $thread
> +  GDBWin::dispatch breakpoint $action $bpnum $addr $line $file $bp_type $enabled $thread
>  }
> 
>  # ------------------------------------------------------------------
> @@ -453,7 +454,7 @@ proc gdbtk_tcl_breakpoint {action bpnum
>  # ------------------------------------------------------------------
>  proc gdbtk_tcl_tracepoint {action tpnum addr line file pass_count} {
>  #  debug "TRACEPOINT: $action $tpnum $addr $line $file $pass_count"
> -  run_hooks gdb_breakpoint_change_hook $action $tpnum $addr $line $file tracepoint
> +  GDBWin::dispatch tracepoint $action $tpnum $addr $line $file $pass_count
>  }
> 
>  # ------------------------------------------------------------------

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Jim Ingham]

Fernando & Keith,

This seems like a good change.  The only thing I wonder about is if 
there will ever be an agent that needs to listen to notifications that 
is NOT a GUI element?  Hanging the methods off GDBWin forces this to be 
the case.  It might be cleaner to make a GDBNotification class, and have 
GDBWin inherit from that (as well as ManagedWin).  That way, if you got 
a non-window class that needed to listen to these as well, it could also 
inherit from GDBNotification.  It also means that the place to go to 
look up the hooks has ONLY the hooks for notification, and no noise from 
other stuff that might be good to put in GDBWin.

Jim

P.S. When Martin & I first talked about the whole GDBWin thing, it was 
with the notion of using it for this sort of stuff, but I didn't at the 
time think about whether ONLY windows would want this capability...  Now 
I give it another thunk, I thought maybe tying them this closely is not 
so good.

Jim

On Thursday, April 12, 2001, at 07:11 AM, Fernando Nasser wrote:

> FYI: Keith has already explained this to me personally when he visited
> Toronto some time ago.
>
> We are asking for some comments.  Keith will probably start making these
> changes sometime next week.
>
> Here is some background:
>
> The Insight events are handled in a publish-subscribe model.  Current
> you subscribe in your constructor with something like:
>
> add_hook gdb_update_hook "$this update"
>
> and have to explicitly unsubscribe in you destructor.
>
> When an event happens, the "run_hooks" code (hooks.tcl) will notify all
> that subscribed to that event.
>
> Keith's idea is to use the itcl machinery as the manager of
> subscriptions and the dispatcher.  You will now subscribe by overloading
> a method and the dispatch will figure who subscribed by introspection in
> the itcl object metadata:
>
>  foreach w [itcl_info objects -isa GDBWin] {
>
>
> As this is implemented in C, we hope that the performance will be good.
>
>
> Nothing else changes: the code in interface.c still plays the "Change
> Manager" (or "Mediator") role.  It will still convert GDB events, or
> internally generated events, into notifications to the subscribed
> observers (sent via GDBWin).
>
>
> For now, we will continue with the somewhat ad hoc set of events and
> confuse notion of observed subjects.  This is an independent work that
> has to be done eventually. It will require a very careful planning
> involving the GDB people in the discussion.
>
> Fernando
>
>
> Keith Seitz wrote:
>>
>> Hi,
>>
>> At long last, I have gotten around to doing a little work on this.
>>
>> Here is the first part of my proposal to change from "add/remove_hook
>> FOO_EVENT command" to simply overloading a method inherited from 
>> GDBWin.
>>
>> Comments enjoyed. More comments interspersed with patches. Look 
>> for "%%%".
>> Keith
>>
>> I've ommitted bits and pieces of the "real" patch to help people digest
>> this change a little. There are also pending changes to bpwin.it[hb] 
>> and
>> srctextwin.it[hb].
>>
>> 2001-04-10  Keith Seitz  <keiths@cygnus.com>
>>
>>         * library/interface.tcl (gdb_breakpoint_change_hook): Mark
>>         as deprecated and comment out definition.
>>         (gdbtk_tcl_breakpoint): Use new GDBWin event "breakpoint"
>>         to notify rest of UI about breakpoint event.
>>         (gdbtk_tcl_tracepoint): Ditto for "tracepoint" event.
>>         * library/gdbwin.ith (dispatch): New public proc.
>>         (breakpoint): New public proc.
>>         (tracepoint): New public proc.
>>         (update): Delete unused method. Will come
>>         back later.
>>         (_state): Delete unused variable.
>>         (constructor): Delete debug statement.
>>         (destructor): Ditto.
>>         * library/gdbwin.itb: New file. Implements new event
>>         model.
>>         * tclIndex: Regenerated.
>>
>> Index: library/gdbwin.ith
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/gdbtk/library/gdbwin.ith,v
>> retrieving revision 1.2
>> diff -p -u -r1.2 gdbwin.ith
>> --- gdbwin.ith  2001/02/08 19:26:31     1.2
>> +++ gdbwin.ith  2001/04/10 15:54:44
>> @@ -13,14 +13,30 @@
>>
>>
>>  class GDBWin {
>> -  private variable _state
>> -  public method update
>>
>> - constructor {args} {
>> -    debug "$args"
>> -  }
>> +  constructor {args} {}
>> +  destructor {}
>>
>> -  destructor {
>> -    debug
>> +  #
>> +  # Events
>> +  #
>> +  public {
>> +    # Dispatching proc. ALL events should be funneled through this
>> +    # procedure.
>> +    proc dispatch {event args}
>> +
>> +    # Breakpiont/tracepoint creation/deletion/modification
>> +    # ACTION    - "create", "modify", "delete"
>> +    # NUM       - gdb's internal token for the bp/tp
>> +    # ADDR      - the address at which the breakpoint is set
>> +    # LINE      - line number of this address
>> +    # FILE      - source file name containing the address
>> +    # TYPE      - what gdb will do with bp/tp: "delete", "delstop",
>> +    #             "disable", "donttouch" (see breakpoint.h "enum 
>> bpdisp")
>> +    # ENABLED   - is the bp/tp enabled?
>> +    # THREAD    - thread number of thread-specific bp or -1 if don't 
>> care
>> +    # PASSCOUNT - pass count of the tracepoint
>> +    method breakpoint {action num addr line file type enabled 
>> thread} {}
>> +    method tracepoint {action num addr line file passcount} {}
>>    }
>>  }
>>
>> %%% I've chosen to start with breakpoints/tracepoints. So the idea is
>> that when I (a window/widget/plugin writer) want to know about some 
>> event
>> FOO, is simply override a method of GDBWin which corresponds to FOO. 
>> ALL
>> of these events should be defined in this header file. Right now, I am
>> starting with breakpoint and tracepoint events.
>>
>> gdbwin.itb (which is new):
>> # GDBwin class implementation for Insight.
>> # Copyright 2001 Red Hat, Inc
>> #
>> # This program is free software; you can redistribute it and/or modify 
>> it
>> # under the terms of the GNU General Public License (GPL) as published 
>> by
>> # the Free Software Foundation; either version 2 of the License, or (at
>> # your option) any later version.
>> #
>> # This program is distributed in the hope that it will be useful,
>> # but WITHOUT ANY WARRANTY; without even the implied warranty of
>> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> # GNU General Public License for more details.
>>
>> body GDBWin::dispatch {event args} {
>>
>>   # Determine what event handler to call.
>>   switch $event {
>>     breakpoint   { set handler breakpoint }
>>
>>     tracepoint   { set handler tracepoint }
>>
>>     default { dbug E "unknown event: \"$event\""; return }
>>   }
>>
>>   # invoke event handlers
>>   foreach w [itcl_info objects -isa GDBWin] {
>>     dbug I "posting event \"$event\" to \"$w\""
>>     set err [catch {eval $w $handler $args} errMsg]
>>     if {$err} {
>>       dbug E "On $event event, $w errored:\n$errMsg"
>>     }
>>   }
>> }
>>
>> %%% In gdbwin.itb, we simply have the all-important dispatch proc, 
>> which
>> will be replacing "run_hooks" in interface.tcl (see interface.tcl patch
>> below). I've included some error handling and debugging here to
>> facilitate flushing out any potential problems. This is pretty 
>> defensive
>> code (since I don't trust gdb ;-).
>>
>>  Index: library/interface.tcl
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
>> retrieving revision 1.15
>> diff -p -u -r1.15 interface.tcl
>> --- interface.tcl       2001/04/05 00:04:28     1.15
>> +++ interface.tcl       2001/04/10 15:55:27
>> @@ -16,9 +16,10 @@
>>  global gdbtk_state
>>  set gdbtk_state(busyCount) 0
>>
>> +# *** DEPRECATED: Use GDBWin::dispatch event "breakpoint" instead.
>>  # This is run when a breakpoint changes.  The arguments are the
>>  # action, the breakpoint number, and the breakpoint info.
>> -define_hook gdb_breakpoint_change_hook
>> +#define_hook gdb_breakpoint_change_hook
>>
>>  # This is run when a `set' command successfully completes in gdb.  The
>>  # first argument is the gdb variable name (as a Tcl list).  The second
>> @@ -445,7 +446,7 @@ proc gdbtk_tcl_end_variable_annotation {
>>  # ------------------------------------------------------------------
>>  proc gdbtk_tcl_breakpoint {action bpnum addr line file bp_type 
>> enabled thread} {
>>  #  debug "BREAKPOINT: $action $bpnum $addr $line $file $bp_type 
>> $enabled $thread "
>> -  run_hooks gdb_breakpoint_change_hook $action $bpnum $addr $line 
>> $file $bp_type $enabled $thread
>> +  GDBWin::dispatch breakpoint $action $bpnum $addr $line $file 
>> $bp_type $enabled $thread
>>  }
>>
>>  # ------------------------------------------------------------------
>> @@ -453,7 +454,7 @@ proc gdbtk_tcl_breakpoint {action bpnum
>>  # ------------------------------------------------------------------
>>  proc gdbtk_tcl_tracepoint {action tpnum addr line file pass_count} {
>>  #  debug "TRACEPOINT: $action $tpnum $addr $line $file $pass_count"
>> -  run_hooks gdb_breakpoint_change_hook $action $tpnum $addr $line 
>> $file tracepoint
>> +  GDBWin::dispatch tracepoint $action $tpnum $addr $line $file 
>> $pass_count
>>  }
>>
>>  # ------------------------------------------------------------------
>
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

Jim Ingham wrote:
> 
> Fernando & Keith,
> 
> This seems like a good change.  The only thing I wonder about is if
> there will ever be an agent that needs to listen to notifications that
> is NOT a GUI element?  Hanging the methods off GDBWin forces this to be
> the case.  It might be cleaner to make a GDBNotification class, and have
> GDBWin inherit from that (as well as ManagedWin).  That way, if you got
> a non-window class that needed to listen to these as well, it could also
> inherit from GDBNotification.  It also means that the place to go to
> look up the hooks has ONLY the hooks for notification, and no noise from
> other stuff that might be good to put in GDBWin.
> 

Very good idea.  I would call it GDBEvents to be shorter to type :-)


> Jim
> 
> P.S. When Martin & I first talked about the whole GDBWin thing, it was
> with the notion of using it for this sort of stuff, but I didn't at the
> time think about whether ONLY windows would want this capability...  Now
> I give it another thunk, I thought maybe tying them this closely is not
> so good.
> 

I don't think Keith will mind making this change.  I guess he only used the GDBWin files because they were already there, asking for some "filling" :-)


Thanks for your prompt comments.


Best regards,
Fernando



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Thu, 12 Apr 2001, Jim Ingham wrote:

> This seems like a good change.  The only thing I wonder about is if 
> there will ever be an agent that needs to listen to notifications that 
> is NOT a GUI element?

Indeed. We already have a case similar to this: the stop button needs to 
know about idle events. There is no GUI or window-specific code in 
GDBWin, so I am making an object for the stop button to use for event
reporting.

I was hesitant to rename gdbwin.ith (I *hate* deleting files), but, well, 
it seems that it really would be better to call it something like 
GDBEvent or GdbEvent (gdbevent.it[hb]).

I will make the change and repost the change before checking this in. 
(And then I'll start converting other events over to use the same 
mechanism.)

Keith

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

Keith Seitz wrote:
> 
> On Thu, 12 Apr 2001, Jim Ingham wrote:
> 
> > This seems like a good change.  The only thing I wonder about is if
> > there will ever be an agent that needs to listen to notifications that
> > is NOT a GUI element?
> 
> Indeed. We already have a case similar to this: the stop button needs to
> know about idle events. There is no GUI or window-specific code in
> GDBWin, so I am making an object for the stop button to use for event
> reporting.
> 
> I was hesitant to rename gdbwin.ith (I *hate* deleting files), but, well,
> it seems that it really would be better to call it something like
> GDBEvent or GdbEvent (gdbevent.it[hb]).
> 
> I will make the change and repost the change before checking this in.
> (And then I'll start converting other events over to use the same
> mechanism.)
> 

Keith,

Jim's suggestion is to create _another_ new file (gdbevent.it? or
whatever),
not to rename GDBWin.  He even suggested that GDBWin inherits from this,
so the objects that are windows do not have to explicitly get GDBEvents
in.  Conversely, non-windows objects can inherit GDBEvents directly.

Wasn't it that Jim?

Fernando

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Fri, 13 Apr 2001, Fernando Nasser wrote:

> Keith Seitz wrote:
> > it seems that it really would be better to call it something like
> > GDBEvent or GdbEvent (gdbevent.it[hb]).

> Jim's suggestion is to create _another_ new file (gdbevent.it? or
> whatever),
> not to rename GDBWin.  He even suggested that GDBWin inherits from this,
> so the objects that are windows do not have to explicitly get GDBEvents
> in.  Conversely, non-windows objects can inherit GDBEvents directly.

Hmmmm.... Ok, I think I see where this is headed. I can only think of one 
or two uses for this right now, but maybe more opportunities for this 
will arise in the future.

So, I'll make a new GDBEvent and have GDBWin inherit from that. Then I'll 
move the GDBWin event stuff into these files and leave GDBWin empty, 
since we don't have anything for it just yet. (I presume we intend to add 
some sort of default busy/idle handling and some such.)

Am I getting closer?
Keith

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

Keith Seitz wrote:
> 
> On Fri, 13 Apr 2001, Fernando Nasser wrote:
> 
> > Keith Seitz wrote:
> > > it seems that it really would be better to call it something like
> > > GDBEvent or GdbEvent (gdbevent.it[hb]).
> 
> > Jim's suggestion is to create _another_ new file (gdbevent.it? or
> > whatever),
> > not to rename GDBWin.  He even suggested that GDBWin inherits from this,
> > so the objects that are windows do not have to explicitly get GDBEvents
> > in.  Conversely, non-windows objects can inherit GDBEvents directly.
> 
> Hmmmm.... Ok, I think I see where this is headed. I can only think of one
> or two uses for this right now, but maybe more opportunities for this
> will arise in the future.
> 
> So, I'll make a new GDBEvent and have GDBWin inherit from that. Then I'll
> move the GDBWin event stuff into these files and leave GDBWin empty,
> since we don't have anything for it just yet. (I presume we intend to add
> some sort of default busy/idle handling and some such.)
> 
> Am I getting closer?

I think you've nailed it.

The busy/idle handling is badly needed.  Jim wanted to use BLT's "busy"
for that, but we wanted to convert out of Tix so we don't grow the
source tree too much.  The only thing that is holding us is the Tix tree
in the variables.tcl, for which we wanted to use the BLT tree (the other
Tix widgets have corresponding iwidgets available).

Cheers,
Fernando

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Jim Ingham]

Fernando & Keith,

Yes, this is what I had in mind.

One of the other things that I was thinking to handle in GDBWin was the 
logic of tracking all the windows that logically belong to a single 
thread, or a single processor - when we get to the point were gdb & 
insight can support that.  That lives above the level of ManagedWin, 
since ManagedWin doesn't know that this variable display & this register 
display & this stack display belong to thread 1, etc...  Someone needs 
to do this, since it would be great to be able to hide info about one 
thread, then reveal it again.  Ditto for processors (like the CPU & the 
DSP, or multiprocessor systems or what not...

But it is also quite appropriate for it to inherit from GDBEvent.

You can do busy-ing from plain Tk, without BLT busy, but is is much more 
labor intensive, since you have to go tell each widget not to 
respond...  This is the sort of thing that having some more 
responder-chain based framework makes really easy (like MacApp, 
PowerPlant, Cocoa, etc...)  But with Tk, you really have to go disable 
everything, AND go spin the cursor on everything...  Not as convenient.  
But "busy" makes this utterly trivial.

BTW, Ioi has surfaced recently and released an update to Tix...  I don't 
know whether this represents much work or not, but it is interesting 
anyway...

Note also that BLT is already in the Cygnus repository, IIRC.  So it is 
just a matter of adding it to the Insight slice of the tree.  AND, it 
would be kind of cool to have the graphing capabilities easily 
available.  You could really easily hook up some of the variable history 
stuff that DDD does, but in BLT it would more slick & active...  For 
instance, BLT has a strip chart, so you could do live tracing with 
breakpoints with "continue" commands that feed into the strip chart.

If we were still doing the tracepoint stuff, for instance, it would be 
neat to take all the points that a given variable was collected, plot 
them, and then allow the user to click on the plot points to put the 
rest of gdb into the state where the value was measured with that 
value...

Enough drivel for now...

Jim

> Keith Seitz wrote:
>>
>> On Fri, 13 Apr 2001, Fernando Nasser wrote:
>>
>>> Keith Seitz wrote:
>>>> it seems that it really would be better to call it something like
>>>> GDBEvent or GdbEvent (gdbevent.it[hb]).
>>
>>> Jim's suggestion is to create _another_ new file (gdbevent.it? or
>>> whatever),
>>> not to rename GDBWin.  He even suggested that GDBWin inherits from 
>>> this,
>>> so the objects that are windows do not have to explicitly get 
>>> GDBEvents
>>> in.  Conversely, non-windows objects can inherit GDBEvents directly.
>>
>> Hmmmm.... Ok, I think I see where this is headed. I can only think of 
>> one
>> or two uses for this right now, but maybe more opportunities for this
>> will arise in the future.
>>
>> So, I'll make a new GDBEvent and have GDBWin inherit from that. Then 
>> I'll
>> move the GDBWin event stuff into these files and leave GDBWin empty,
>> since we don't have anything for it just yet. (I presume we intend to 
>> add
>> some sort of default busy/idle handling and some such.)
>>
>> Am I getting closer?
>
> I think you've nailed it.
>
> The busy/idle handling is badly needed.  Jim wanted to use BLT's "busy"
> for that, but we wanted to convert out of Tix so we don't grow the
> source tree too much.  The only thing that is holding us is the Tix tree
> in the variables.tcl, for which we wanted to use the BLT tree (the other
> Tix widgets have corresponding iwidgets available).
>
> Cheers,
> Fernando
>
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Fri, 13 Apr 2001, Jim Ingham wrote:

> Yes, this is what I had in mind.

Ok, glad we're all on the same page (now).

> One of the other things that I was thinking to handle in GDBWin was the 
> logic of tracking all the windows that logically belong to a single 
> thread, or a single processor - when we get to the point were gdb & 
> insight can support that.  That lives above the level of ManagedWin, 
> since ManagedWin doesn't know that this variable display & this register 
> display & this stack display belong to thread 1, etc...  Someone needs 
> to do this, since it would be great to be able to hide info about one 
> thread, then reveal it again.  Ditto for processors (like the CPU & the 
> DSP, or multiprocessor systems or what not...

Sheesh. I disappear for a little while, and look at how much I forget. 
This seems like the right path to follow.

> But it is also quite appropriate for it to inherit from GDBEvent.

Yes, I agree. My latest incarnation (below) does just this. GDBWin 
inherits from GDBEvent.

> Enough drivel for now...

:-)

I've included the two new files, gdbevent.ith and gdbevent.itb, and given 
the small diff for gdbwin.ith.

Once this is approved by Fernando and you (Jim), I will post the changes 
to interface.tcl, bpwin.it?, and srctextwin.itb to use this for 
breakpoint/tracepoint events.

Keith

*** File: gdbevent.ith
# GDBEvent class definition for Insight.
# Copyright 2001 Red Hat, Inc.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License (GPL) as published by
# the Free Software Foundation; either version 2 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.


class GDBEvent {

  constructor {args} {}
  destructor {}

  #
  # Events
  #
  public {
    # Dispatching proc. ALL events should be funneled through this
    # procedure.
    proc dispatch {event args}

    # Breakpiont/tracepoint creation/deletion/modification
    # ACTION    - "create", "modify", "delete"
    # NUM       - gdb's internal token for the bp/tp
    # ADDR      - the address at which the breakpoint is set
    # LINE      - line number of this address
    # FILE      - source file name containing the address
    # TYPE      - what gdb will do with bp/tp: "delete", "delstop",
    #             "disable", "donttouch" (see breakpoint.h "enum bpdisp")
    # ENABLED   - is the bp/tp enabled?
    # THREAD    - thread number of thread-specific bp or -1 if don't care
    # PASSCOUNT - pass count of the tracepoint
    method breakpoint {action num addr line file type enabled thread} {}
    method tracepoint {action num addr line file passcount} {}
  }
}

*** File: gdbevent.itb
# GDBEvent class implementation for Insight.
# Copyright 2001 Red Hat, Inc.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License (GPL) as published by
# the Free Software Foundation; either version 2 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

body GDBEvent::dispatch {event args} {

  # Determine what event handler to call.
  switch $event {
    breakpoint   { set handler breakpoint }

    tracepoint   { set handler tracepoint }

    default { dbug E "unknown event: \"$event\""; return }
  }

  # invoke event handlers
  foreach w [itcl_info objects -isa GDBWin] {
    dbug I "posting event \"$event\" to \"$w\""
    set err [catch {eval $w $handler $args} errMsg]
    if {$err} {
      dbug E "On $event event, $w errored:\n$errMsg"
    }
  }
}

*** Other patches:

Index: gdbwin.ith
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/gdbwin.ith,v
retrieving revision 1.2
diff -p -u -r1.2 gdbwin.ith
--- gdbwin.ith	2001/02/08 19:26:31	1.2
+++ gdbwin.ith	2001/04/13 20:54:58
@@ -13,8 +13,7 @@
 
 
 class GDBWin {
-  private variable _state
-  public method update
+  inherit GDBEvent
 
  constructor {args} {
     debug "$args"

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Fri, 13 Apr 2001, Keith Seitz wrote:

Fudge.

>   # invoke event handlers
>   foreach w [itcl_info objects -isa GDBWin] {
                                      ^^^^^^
That should have read GDBEvent.

>     dbug I "posting event \"$event\" to \"$w\""
>     set err [catch {eval $w $handler $args} errMsg]
>     if {$err} {
>       dbug E "On $event event, $w errored:\n$errMsg"
>     }
>   }

Keith

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

It is OK with me.

If I understood right, it is OK with Jim as well.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Jim Ingham]

Keith,

I have another question about this.  How were you planning to pass all 
the details about the event?  Will there be methods in the GDBEvent 
class to get out the event data?  It almost seems like you want to have:

GDBEvent
     |
     ------> BreakpointEvent
     |
     ------> ExecutionStateEvent

and ALL you ever pass to the dispatch method is an event of the 
appropriate class.  This would really simplify the code in the event 
listeners, and we wouldn't get into the situation of the current code, 
where the event handlers have to know the order of the parameters in the 
hook call, which is very fragile.

Jim



On Friday, April 13, 2001, at 01:56 PM, Keith Seitz wrote:

> On Fri, 13 Apr 2001, Jim Ingham wrote:
>
>> Yes, this is what I had in mind.
>
> Ok, glad we're all on the same page (now).
>
>> One of the other things that I was thinking to handle in GDBWin was the
>> logic of tracking all the windows that logically belong to a single
>> thread, or a single processor - when we get to the point were gdb &
>> insight can support that.  That lives above the level of ManagedWin,
>> since ManagedWin doesn't know that this variable display & this 
>> register
>> display & this stack display belong to thread 1, etc...  Someone needs
>> to do this, since it would be great to be able to hide info about one
>> thread, then reveal it again.  Ditto for processors (like the CPU & the
>> DSP, or multiprocessor systems or what not...
>
> Sheesh. I disappear for a little while, and look at how much I forget.
> This seems like the right path to follow.
>
>> But it is also quite appropriate for it to inherit from GDBEvent.
>
> Yes, I agree. My latest incarnation (below) does just this. GDBWin
> inherits from GDBEvent.
>
>> Enough drivel for now...
>
> :-)
>
> I've included the two new files, gdbevent.ith and gdbevent.itb, and 
> given
> the small diff for gdbwin.ith.
>
> Once this is approved by Fernando and you (Jim), I will post the changes
> to interface.tcl, bpwin.it?, and srctextwin.itb to use this for
> breakpoint/tracepoint events.
>
> Keith
>
> *** File: gdbevent.ith
> # GDBEvent class definition for Insight.
> # Copyright 2001 Red Hat, Inc.
> #
> # This program is free software; you can redistribute it and/or modify 
> it
> # under the terms of the GNU General Public License (GPL) as published 
> by
> # the Free Software Foundation; either version 2 of the License, or (at
> # your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
>
>
> class GDBEvent {
>
>   constructor {args} {}
>   destructor {}
>
>   #
>   # Events
>   #
>   public {
>     # Dispatching proc. ALL events should be funneled through this
>     # procedure.
>     proc dispatch {event args}
>
>     # Breakpiont/tracepoint creation/deletion/modification
>     # ACTION    - "create", "modify", "delete"
>     # NUM       - gdb's internal token for the bp/tp
>     # ADDR      - the address at which the breakpoint is set
>     # LINE      - line number of this address
>     # FILE      - source file name containing the address
>     # TYPE      - what gdb will do with bp/tp: "delete", "delstop",
>     #             "disable", "donttouch" (see breakpoint.h "enum 
> bpdisp")
>     # ENABLED   - is the bp/tp enabled?
>     # THREAD    - thread number of thread-specific bp or -1 if don't 
> care
>     # PASSCOUNT - pass count of the tracepoint
>     method breakpoint {action num addr line file type enabled thread} {}
>     method tracepoint {action num addr line file passcount} {}
>   }
> }
>
> *** File: gdbevent.itb
> # GDBEvent class implementation for Insight.
> # Copyright 2001 Red Hat, Inc.
> #
> # This program is free software; you can redistribute it and/or modify 
> it
> # under the terms of the GNU General Public License (GPL) as published 
> by
> # the Free Software Foundation; either version 2 of the License, or (at
> # your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
>
> body GDBEvent::dispatch {event args} {
>
>   # Determine what event handler to call.
>   switch $event {
>     breakpoint   { set handler breakpoint }
>
>     tracepoint   { set handler tracepoint }
>
>     default { dbug E "unknown event: \"$event\""; return }
>   }
>
>   # invoke event handlers
>   foreach w [itcl_info objects -isa GDBWin] {
>     dbug I "posting event \"$event\" to \"$w\""
>     set err [catch {eval $w $handler $args} errMsg]
>     if {$err} {
>       dbug E "On $event event, $w errored:\n$errMsg"
>     }
>   }
> }
>
> *** Other patches:
>
> Index: gdbwin.ith
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/gdbwin.ith,v
> retrieving revision 1.2
> diff -p -u -r1.2 gdbwin.ith
> --- gdbwin.ith	2001/02/08 19:26:31	1.2
> +++ gdbwin.ith	2001/04/13 20:54:58
> @@ -13,8 +13,7 @@
>
>
>  class GDBWin {
> -  private variable _state
> -  public method update
> +  inherit GDBEvent
>
>   constructor {args} {
>      debug "$args"
>

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: [RFA] New Event Model Prototype

[Fernando Nasser]

Jim Ingham wrote:
> 
> Keith,
> 
> I have another question about this.  How were you planning to pass all
> the details about the event?  Will there be methods in the GDBEvent
> class to get out the event data?  It almost seems like you want to have:
> 
> GDBEvent
>      |
>      ------> BreakpointEvent
>      |
>      ------> ExecutionStateEvent
> 
> and ALL you ever pass to the dispatch method is an event of the
> appropriate class.  This would really simplify the code in the event
> listeners, and we wouldn't get into the situation of the current code,
> where the event handlers have to know the order of the parameters in the
> hook call, which is very fragile.
> 

I agree with your concerns that the fixed position list of arguments (different for each event) is a drag.

Being able to do like Java exception and inherit the (classes corresponding to) the events you plan to use would be nice.

But how do we circumvent the itcl limitation that you cannot use multiple inheritance if the classes you are inheriting from have common ancestors?  Maybe this restriction has already been lifted, I am only as up-to-date as the itcl book...

Cheers,
Fernando


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Mon, 16 Apr 2001, Jim Ingham wrote:

> I have another question about this.  How were you planning to pass all 
> the details about the event?  Will there be methods in the GDBEvent 
> class to get out the event data?  It almost seems like you want to have:
> 
> GDBEvent
>      |
>      ------> BreakpointEvent
>      |
>      ------> ExecutionStateEvent
> 
> and ALL you ever pass to the dispatch method is an event of the 
> appropriate class.  This would really simplify the code in the event 
> listeners, and we wouldn't get into the situation of the current code, 
> where the event handlers have to know the order of the parameters in the 
> hook call, which is very fragile.

I agree with you guys that we would like to NOT have to pass a huge list 
of arguments to the handles, but I'm not sure that this is going to work 
in Itcl anywhere as cleanly as it does in C++. 

So, the proposal is to add some Event classes (which will essentially all 
be arrays of data??). Bear with me here... read the whole thing 
before responding...

Something like:

class GdbEvent {

  protected variable _type "unknown"

  public {
    proc dispatch {} {
      foreach w [itcl_info objects -isa EVENTLISTENER] {
        catch {$w $_type $this}
      }
    }
  }
}

class FooEvent {
  inherit GdbEvent

  public {
    constructor {args} {
      set _type foo
      eval configure $args
    }

    variable varA
    variable varB
    variable varC
    variable varD
  }
}

proc gdbtk_tcl_foo_event {varA varB varC varD} {
  set e [FooEvent #auto -varA $varA -varB $varB -varC $varC -varD $varD]
  $e dispatch
  delete object $e
}

And this would call the "foo" method of every EVENTLISTENER object with 
the object as an argument. So something listening for FooEvent would look 
like:

class MyObject {
  inherit EVENTLISTENER

  public {
    method foo {event} {
      puts "varA = [$event cget -varA]"
      puts "varB = [$event cget -varB]"
      puts "varC = [$event cget -varC]"
      puts "varD = [$event cget -varD]"
    }
  }
}

OR the proposal is to do something like:

class GdbEvent {
  public method type {} { return "unknown" }
}

class FooEvent {
  public method type {} { return "foo" }
}

proc GdbEvent::dispatch {event} {
  set type $event type

  foreach w [itcl_info object -isa GdbEventListener] {
    catch {$w $type $event}
  }
}

class MyObject {
  inherit GdbEventListener

  public method foo {fooEvent} {
    puts "varA = [$fooEvent cget -varA]"
    puts "varB = [$fooEvent cget -varB]"
    puts "varC = [$fooEvent cget -varC]"
  }
}

Are either of these on target? 

Happily, both of these address a big concern: we are constantly asking 
for the same information. Now we'll have an event object to contain it 
all.

Originally, I was going to do this all with arrays, eg. event(type) = 
breakpoint, event(line) = 31, event(file) = /foo/bar/baz, etc. This way, we 
can collect the info once and everyone gets to use it. But I hadn't 
planned on making such a huge change to start with. I guess this is a 
request to do so. ;-)

My itcl is really fuzzy nowadays (having been corrupted by C++), so 
please excuse my C++-ish approaches...

Keith

Re: [RFA] New Event Model Prototype

[Jim Ingham]

Keith,

I think that the second type is more likely to be what you want.  That 
seems cleaner, all the dispatch cares about is that it is passing event 
objects to everybody who claims to listen to them.  Then the listener 
could query the event for its data - and in this case using public 
variables is probably a perfectly good mechanism, as long as you let 
people know that they really should not alter this data...

As far as I know, Itcl still doesn't allow diamond graphs.  But I don't 
think that this would cause major problems here.  It means we can't 
subclass the EventListener and for instance have a window would inherit 
from BreakpointEventListener, AND ExecutionStateChangeListener.  This 
would be nice, since then we could have the dispatch work by getting all 
the objects that derive from the listener corresponding to the event's 
most specific class.  Instead, we will have to have JUST an 
EventListener, and then the events will use single inheritance from the 
base GDBEvent class to their event type.  This is not as elegant, but it 
will work, after all, there are not that many events in gdbtk and we are 
never dealing with a fast stream of events, so this doesn't have to be 
as efficient as, say, a window server.

Jim

On Tuesday, April 17, 2001, at 09:09 AM, Keith Seitz wrote:

> On Mon, 16 Apr 2001, Jim Ingham wrote:
>
>> I have another question about this.  How were you planning to pass all
>> the details about the event?  Will there be methods in the GDBEvent
>> class to get out the event data?  It almost seems like you want to 
>> have:
>>
>> GDBEvent
>>      |
>>      ------> BreakpointEvent
>>      |
>>      ------> ExecutionStateEvent
>>
>> and ALL you ever pass to the dispatch method is an event of the
>> appropriate class.  This would really simplify the code in the event
>> listeners, and we wouldn't get into the situation of the current code,
>> where the event handlers have to know the order of the parameters in 
>> the
>> hook call, which is very fragile.
>
> I agree with you guys that we would like to NOT have to pass a huge list
> of arguments to the handles, but I'm not sure that this is going to work
> in Itcl anywhere as cleanly as it does in C++.
>
> So, the proposal is to add some Event classes (which will essentially 
> all
> be arrays of data??). Bear with me here... read the whole thing
> before responding...
>
> Something like:
>
> class GdbEvent {
>
>   protected variable _type "unknown"
>
>   public {
>     proc dispatch {} {
>       foreach w [itcl_info objects -isa EVENTLISTENER] {
>         catch {$w $_type $this}
>       }
>     }
>   }
> }
>
> class FooEvent {
>   inherit GdbEvent
>
>   public {
>     constructor {args} {
>       set _type foo
>       eval configure $args
>     }
>
>     variable varA
>     variable varB
>     variable varC
>     variable varD
>   }
> }
>
> proc gdbtk_tcl_foo_event {varA varB varC varD} {
>   set e [FooEvent #auto -varA $varA -varB $varB -varC $varC -varD $varD]
>   $e dispatch
>   delete object $e
> }
>
> And this would call the "foo" method of every EVENTLISTENER object with
> the object as an argument. So something listening for FooEvent would 
> look
> like:
>
> class MyObject {
>   inherit EVENTLISTENER
>
>   public {
>     method foo {event} {
>       puts "varA = [$event cget -varA]"
>       puts "varB = [$event cget -varB]"
>       puts "varC = [$event cget -varC]"
>       puts "varD = [$event cget -varD]"
>     }
>   }
> }
>
> OR the proposal is to do something like:
>
> class GdbEvent {
>   public method type {} { return "unknown" }
> }
>
> class FooEvent {
>   public method type {} { return "foo" }
> }
>
> proc GdbEvent::dispatch {event} {
>   set type $event type
>
>   foreach w [itcl_info object -isa GdbEventListener] {
>     catch {$w $type $event}
>   }
> }
>
> class MyObject {
>   inherit GdbEventListener
>
>   public method foo {fooEvent} {
>     puts "varA = [$fooEvent cget -varA]"
>     puts "varB = [$fooEvent cget -varB]"
>     puts "varC = [$fooEvent cget -varC]"
>   }
> }
>
> Are either of these on target?
>
> Happily, both of these address a big concern: we are constantly asking
> for the same information. Now we'll have an event object to contain it
> all.
>
> Originally, I was going to do this all with arrays, eg. event(type) =
> breakpoint, event(line) = 31, event(file) = /foo/bar/baz, etc. This 
> way, we
> can collect the info once and everyone gets to use it. But I hadn't
> planned on making such a huge change to start with. I guess this is a
> request to do so. ;-)
>
> My itcl is really fuzzy nowadays (having been corrupted by C++), so
> please excuse my C++-ish approaches...
>
> Keith
>

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb

Re: [RFA] New Event Model Prototype

[Keith Seitz]

On Wed, 18 Apr 2001, Jim Ingham wrote:

> I think that the second type is more likely to be what you want. 

I came to the same conclusion. (So I'm not losing my mind.)

> > class MyObject {
> >   inherit GdbEventListener
> >
> >   public method foo {fooEvent} {
> >     puts "varA = [$fooEvent cget -varA]"
> >     puts "varB = [$fooEvent cget -varB]"
> >     puts "varC = [$fooEvent cget -varC]"
> >   }
> > }

I have decided NOT to go this route. Instead, I'm going to use arrays. 
When an event is constructed, it builds an array of all data pertinent to 
itself. Then we ask for this data:

proc handle_foo_event {foo_event} {
  array set fooData [$foo_event get]

  puts "varA = $fooData(varA)"
  puts "varB = $fooData(varB)"
}

Ugh. I thought breakpoints would be easy. Guess again. Can anyone guess 
the difference between clear_command and delete_command (other than 
argument)? I'll give you a hint: using clear_command is EVIL.

Keith