* [RFA] New Event Model Prototype @ 2001-04-10 9:46 Keith Seitz 2001-04-12 7:16 ` Fernando Nasser 0 siblings, 1 reply; 17+ messages in thread From: Keith Seitz @ 2001-04-10 9:46 UTC (permalink / raw) To: Insight Maling List 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 } # ------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-10 9:46 [RFA] New Event Model Prototype Keith Seitz @ 2001-04-12 7:16 ` Fernando Nasser 2001-04-12 9:49 ` Jim Ingham 0 siblings, 1 reply; 17+ messages in thread From: Fernando Nasser @ 2001-04-12 7:16 UTC (permalink / raw) To: Keith Seitz; +Cc: Insight Maling List, Jim Ingham 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-12 7:16 ` Fernando Nasser @ 2001-04-12 9:49 ` Jim Ingham 2001-04-12 11:00 ` Fernando Nasser 2001-04-13 6:50 ` Keith Seitz 0 siblings, 2 replies; 17+ messages in thread From: Jim Ingham @ 2001-04-12 9:49 UTC (permalink / raw) To: Fernando Nasser; +Cc: Keith Seitz, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-12 9:49 ` Jim Ingham @ 2001-04-12 11:00 ` Fernando Nasser 2001-04-13 6:50 ` Keith Seitz 1 sibling, 0 replies; 17+ messages in thread From: Fernando Nasser @ 2001-04-12 11:00 UTC (permalink / raw) To: Jim Ingham; +Cc: Fernando Nasser, Keith Seitz, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-12 9:49 ` Jim Ingham 2001-04-12 11:00 ` Fernando Nasser @ 2001-04-13 6:50 ` Keith Seitz 2001-04-13 6:57 ` Fernando Nasser 1 sibling, 1 reply; 17+ messages in thread From: Keith Seitz @ 2001-04-13 6:50 UTC (permalink / raw) To: Jim Ingham; +Cc: Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 6:50 ` Keith Seitz @ 2001-04-13 6:57 ` Fernando Nasser 2001-04-13 7:37 ` Keith Seitz 0 siblings, 1 reply; 17+ messages in thread From: Fernando Nasser @ 2001-04-13 6:57 UTC (permalink / raw) To: Keith Seitz; +Cc: Jim Ingham, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 6:57 ` Fernando Nasser @ 2001-04-13 7:37 ` Keith Seitz 2001-04-13 7:44 ` Fernando Nasser 0 siblings, 1 reply; 17+ messages in thread From: Keith Seitz @ 2001-04-13 7:37 UTC (permalink / raw) To: Fernando Nasser; +Cc: Jim Ingham, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 7:37 ` Keith Seitz @ 2001-04-13 7:44 ` Fernando Nasser 2001-04-13 9:44 ` Jim Ingham 0 siblings, 1 reply; 17+ messages in thread From: Fernando Nasser @ 2001-04-13 7:44 UTC (permalink / raw) To: Keith Seitz; +Cc: Jim Ingham, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 7:44 ` Fernando Nasser @ 2001-04-13 9:44 ` Jim Ingham 2001-04-13 13:57 ` Keith Seitz 0 siblings, 1 reply; 17+ messages in thread From: Jim Ingham @ 2001-04-13 9:44 UTC (permalink / raw) To: Fernando Nasser; +Cc: Keith Seitz, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 9:44 ` Jim Ingham @ 2001-04-13 13:57 ` Keith Seitz 2001-04-13 14:00 ` Keith Seitz 2001-04-16 13:48 ` Jim Ingham 0 siblings, 2 replies; 17+ messages in thread From: Keith Seitz @ 2001-04-13 13:57 UTC (permalink / raw) To: Jim Ingham; +Cc: Fernando Nasser, Insight Maling List 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" ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 13:57 ` Keith Seitz @ 2001-04-13 14:00 ` Keith Seitz 2001-04-13 14:36 ` Fernando Nasser 2001-04-16 13:48 ` Jim Ingham 1 sibling, 1 reply; 17+ messages in thread From: Keith Seitz @ 2001-04-13 14:00 UTC (permalink / raw) To: Jim Ingham, Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 14:00 ` Keith Seitz @ 2001-04-13 14:36 ` Fernando Nasser 0 siblings, 0 replies; 17+ messages in thread From: Fernando Nasser @ 2001-04-13 14:36 UTC (permalink / raw) To: Keith Seitz; +Cc: Jim Ingham, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-13 13:57 ` Keith Seitz 2001-04-13 14:00 ` Keith Seitz @ 2001-04-16 13:48 ` Jim Ingham 2001-04-17 7:28 ` Fernando Nasser 2001-04-17 9:09 ` Keith Seitz 1 sibling, 2 replies; 17+ messages in thread From: Jim Ingham @ 2001-04-16 13:48 UTC (permalink / raw) To: Keith Seitz; +Cc: Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-16 13:48 ` Jim Ingham @ 2001-04-17 7:28 ` Fernando Nasser 2001-04-17 9:09 ` Keith Seitz 1 sibling, 0 replies; 17+ messages in thread From: Fernando Nasser @ 2001-04-17 7:28 UTC (permalink / raw) To: Jim Ingham; +Cc: Keith Seitz, Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-16 13:48 ` Jim Ingham 2001-04-17 7:28 ` Fernando Nasser @ 2001-04-17 9:09 ` Keith Seitz 2001-04-18 11:39 ` Jim Ingham 1 sibling, 1 reply; 17+ messages in thread From: Keith Seitz @ 2001-04-17 9:09 UTC (permalink / raw) To: Jim Ingham; +Cc: Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-17 9:09 ` Keith Seitz @ 2001-04-18 11:39 ` Jim Ingham 2001-04-18 11:46 ` Keith Seitz 0 siblings, 1 reply; 17+ messages in thread From: Jim Ingham @ 2001-04-18 11:39 UTC (permalink / raw) To: Keith Seitz; +Cc: Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFA] New Event Model Prototype 2001-04-18 11:39 ` Jim Ingham @ 2001-04-18 11:46 ` Keith Seitz 0 siblings, 0 replies; 17+ messages in thread From: Keith Seitz @ 2001-04-18 11:46 UTC (permalink / raw) To: Jim Ingham; +Cc: Fernando Nasser, Insight Maling List 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2001-04-18 11:46 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-10 9:46 [RFA] New Event Model Prototype Keith Seitz 2001-04-12 7:16 ` Fernando Nasser 2001-04-12 9:49 ` Jim Ingham 2001-04-12 11:00 ` Fernando Nasser 2001-04-13 6:50 ` Keith Seitz 2001-04-13 6:57 ` Fernando Nasser 2001-04-13 7:37 ` Keith Seitz 2001-04-13 7:44 ` Fernando Nasser 2001-04-13 9:44 ` Jim Ingham 2001-04-13 13:57 ` Keith Seitz 2001-04-13 14:00 ` Keith Seitz 2001-04-13 14:36 ` Fernando Nasser 2001-04-16 13:48 ` Jim Ingham 2001-04-17 7:28 ` Fernando Nasser 2001-04-17 9:09 ` Keith Seitz 2001-04-18 11:39 ` Jim Ingham 2001-04-18 11:46 ` Keith Seitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).