* Variable errors @ 2001-04-11 11:14 Keith Seitz 2001-04-11 11:23 ` Fernando Nasser 0 siblings, 1 reply; 8+ messages in thread From: Keith Seitz @ 2001-04-11 11:14 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight Maling List Hi, The recent changes to variables.tcl to deal with changing types in variables is not quite correct: -821,8 +824,22 @@ class VariableWin { set ChangeList {} set variables [$Hlist info children {}] foreach var $variables { - # debug "VARIABLE: $var ($Update($this,$var))" - set ChangeList [concat $ChangeList [$var update]] + # debug "VARIABLE: $var ($Update($this,$var))" + set UpdatedList [$var update] + if {[lindex $UpdatedList 0] == $var} { + debug "Type changed." + # We must fix the tree entry to correspond to the new type + $Hlist delete offsprings $var + $Hlist entryconfigure $var -text [label $var] + if {[$var numChildren] > 0} { + $Tree setmode $var open + } else { + $Tree setmode $var none + } + } else { + set ChangeList [concat $ChangeList $UpdatedList] + # debug "ChangeList=$ChangeList" + } } There are two problems here. We'll start with the easy one. When the type of a variable changes, this code (correctly) deletes the offsprings of the variable and configures the existing entry to correspond to the latest version of the variable. However, it does not add itself to the ChangeList, so it never appears to be updated (its value changes in the window, but the value is never highlighted in blue). The (obvious?) fix is to add "set UpdatedList $var" in the "type changed" block. Now the tougher one. This statement is incorrect: + if {[lindex $UpdatedList 0] == $var} { + debug "Type changed." This means that ANY root variable whose value changes is going to have its offspring deleted and the variable (if it has any displayed children) will also be collapsed. So if I change the value of a struct* which I was viewing, all the children go away. The other side affect is that simple variables like integers also never show up in the ChangeList. Adding the "set UpdateList $var" fix above will work around this, though, as kludgy as it is. Is there a better way to find out if the type has changed?? Can we add a new gdbtk-varobj variable method to check this, i.e., let the variable explicitly tell us that its type has changed? Then we could do something like: if {[$var typeChanged]} { debug "Type changed" This would be a much more definitive test. Keith ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-04-11 11:14 Variable errors Keith Seitz @ 2001-04-11 11:23 ` Fernando Nasser 2001-04-11 11:31 ` Keith Seitz 0 siblings, 1 reply; 8+ messages in thread From: Fernando Nasser @ 2001-04-11 11:23 UTC (permalink / raw) To: Keith Seitz; +Cc: Fernando Nasser, Insight Maling List Keith Seitz wrote: > > Hi, > > The recent changes to variables.tcl to deal with changing types in > variables is not quite correct: > No, it is correct. It may require some extra comment, as I can conclude from your message ;-) > -821,8 +824,22 @@ class VariableWin { > set ChangeList {} > set variables [$Hlist info children {}] > foreach var $variables { > - # debug "VARIABLE: $var ($Update($this,$var))" > - set ChangeList [concat $ChangeList [$var update]] > + # debug "VARIABLE: $var ($Update($this,$var))" > + set UpdatedList [$var update] > + if {[lindex $UpdatedList 0] == $var} { > + debug "Type changed." > + # We must fix the tree entry to correspond to the new type > + $Hlist delete offsprings $var > + $Hlist entryconfigure $var -text [label $var] > + if {[$var numChildren] > 0} { > + $Tree setmode $var open > + } else { > + $Tree setmode $var none > + } > + } else { > + set ChangeList [concat $ChangeList $UpdatedList] > + # debug "ChangeList=$ChangeList" > + } > } > > There are two problems here. We'll start with the easy one. > > When the type of a variable changes, this code (correctly) deletes the > offsprings of the variable and configures the existing entry to > correspond to the latest version of the variable. However, it does not > add itself to the ChangeList, so it never appears to be updated (its > value changes in the window, but the value is never highlighted in blue). That is intentional. It is another variable, with the same name but nevertheless another one. The blue thing is for when the _value_ of a variable changes. > The (obvious?) fix is to add "set UpdatedList $var" in the "type changed" > block. > > Now the tougher one. This statement is incorrect: > + if {[lindex $UpdatedList 0] == $var} { > + debug "Type changed." > > This means that ANY root variable whose value changes is going to have > its offspring deleted and the variable (if it has any displayed children) > will also be collapsed. So if I change the value of a struct* which I was > viewing, all the children go away. > Nope. The only root variable that will ever show up in there is a new incarnation of a type_changed varobj -- which will have the same name. I will add some extra comments to this code. -- 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] 8+ messages in thread
* Re: Variable errors 2001-04-11 11:23 ` Fernando Nasser @ 2001-04-11 11:31 ` Keith Seitz 2001-04-11 11:58 ` Fernando Nasser 0 siblings, 1 reply; 8+ messages in thread From: Keith Seitz @ 2001-04-11 11:31 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight Maling List On Wed, 11 Apr 2001, Fernando Nasser wrote: > No, it is correct. It may require some extra comment, as I can conclude > from your message ;-) Note that I said "not _quite_ correct", not entirely correct. > That is intentional. It is another variable, with the same name but > nevertheless another one. The blue thing is for when the _value_ of a > variable changes. I can buy that. My bad. > > + if {[lindex $UpdatedList 0] == $var} { > > + debug "Type changed." > > > > This means that ANY root variable whose value changes is going to have > > its offspring deleted and the variable (if it has any displayed children) > > will also be collapsed. So if I change the value of a struct* which I was > > viewing, all the children go away. > > > > Nope. The only root variable that will ever show up in there is a new > incarnation of a type_changed varobj -- which will have the same name. Try this: int main (int argc, char *argv[]) { int i; i++; i++; i++; exit (0); } As you step over the "i++;" in Insight, the value of i changes but the variable is never highlighted. Let's say that the variable "i" is in the variable object "var6". Now, when you do "var6 update", it returns either an empty list if its value has not changed since the last check OR it returns "var6" if its value has changed. Or look in the debug window and it prints "Type changed" all the time. Keith ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-04-11 11:31 ` Keith Seitz @ 2001-04-11 11:58 ` Fernando Nasser 2001-04-11 12:13 ` Keith Seitz 0 siblings, 1 reply; 8+ messages in thread From: Fernando Nasser @ 2001-04-11 11:58 UTC (permalink / raw) To: Keith Seitz; +Cc: Insight Maling List, Jim Ingham Keith Seitz wrote: > > Let's say that the variable "i" is in the variable object "var6". Now, > when you do "var6 update", it returns either an empty list if its value > has not changed since the last check OR it returns "var6" if its value > has changed. Or look in the debug window and it prints "Type changed" all > the time. > I guess you're right, I forgot the scalars. Try this patch (*UNTESTED*) for now. I will flag the varobj name if the type has changed over the weekend. Until I do this, variables that change type from scalar to scalar (different types) will be highlighted. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 Index: variables.tcl =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/variables.tcl,v retrieving revision 1.7 diff -c -p -r1.7 variables.tcl *** variables.tcl 2001/03/29 22:42:17 1.7 --- variables.tcl 2001/04/11 18:55:08 *************** class VariableWin { *** 825,832 **** set variables [$Hlist info children {}] foreach var $variables { # debug "VARIABLE: $var ($Update($this,$var))" set UpdatedList [$var update] ! if {[lindex $UpdatedList 0] == $var} { debug "Type changed." # We must fix the tree entry to correspond to the new type $Hlist delete offsprings $var --- 825,837 ---- set variables [$Hlist info children {}] foreach var $variables { # debug "VARIABLE: $var ($Update($this,$var))" + set numchild [$var numChildren] set UpdatedList [$var update] ! # FIXME: For now, we can only infer that the type has changed ! # if the variable is not a scalar; the varobj code will have to ! # give us an indication that this happened. ! if {([lindex $UpdatedList 0] == $var) ! && (numchild > 0)} { debug "Type changed." # We must fix the tree entry to correspond to the new type $Hlist delete offsprings $var ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-04-11 11:58 ` Fernando Nasser @ 2001-04-11 12:13 ` Keith Seitz 2001-04-11 12:27 ` Lewin A.R.W. Edwards 2001-05-07 17:33 ` Fernando Nasser 0 siblings, 2 replies; 8+ messages in thread From: Keith Seitz @ 2001-04-11 12:13 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight Maling List, Jim Ingham On Wed, 11 Apr 2001, Fernando Nasser wrote: > Keith Seitz wrote: > > > > Let's say that the variable "i" is in the variable object "var6". Now, > > when you do "var6 update", it returns either an empty list if its value > > has not changed since the last check OR it returns "var6" if its value > > has changed. Or look in the debug window and it prints "Type changed" all > > the time. > > > > I guess you're right, I forgot the scalars. Try this patch (*UNTESTED*) > for now. I will flag the varobj name if the type has changed over the > weekend. Until I do this, variables that change type from scalar to > scalar (different types) will be highlighted. That should do the trick. You need not hurredly do anything, I just wanted to let readers (do we have any?) know that this buglet exists (and offer some simple workarounds until an "official" response can be made by us). Thanks! Keith ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-04-11 12:13 ` Keith Seitz @ 2001-04-11 12:27 ` Lewin A.R.W. Edwards 2001-05-07 17:33 ` Fernando Nasser 1 sibling, 0 replies; 8+ messages in thread From: Lewin A.R.W. Edwards @ 2001-04-11 12:27 UTC (permalink / raw) To: Insight Maling List >That should do the trick. You need not hurredly do anything, I just >wanted to let readers (do we have any?) know that this buglet exists (and I'm listening :) === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ Fly like a beagle. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-04-11 12:13 ` Keith Seitz 2001-04-11 12:27 ` Lewin A.R.W. Edwards @ 2001-05-07 17:33 ` Fernando Nasser 2001-05-10 17:25 ` Keith Seitz 1 sibling, 1 reply; 8+ messages in thread From: Fernando Nasser @ 2001-05-07 17:33 UTC (permalink / raw) To: Keith Seitz; +Cc: Fernando Nasser, Insight Maling List, Jim Ingham Keith Seitz wrote: > > On Wed, 11 Apr 2001, Fernando Nasser wrote: > > > I guess you're right, I forgot the scalars. Try this patch (*UNTESTED*) > > for now. I will flag the varobj name if the type has changed over the > > weekend. Until I do this, variables that change type from scalar to > > scalar (different types) will be highlighted. > Well, it took a while, but I now have the patch to address Keith's concerns. The indication that the type of the variable has changed (well, it is another variable with the same name actually) is now returned and can be tested regardless of the old variable being a scalar or a complex type. It seems to work in all cases now. Please give it a spin and let me know if you like it. Cheers, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 Index: gdbtk/generic/gdbtk-varobj.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v retrieving revision 1.6 diff -c -p -r1.6 gdbtk-varobj.c *** gdbtk-varobj.c 2001/03/29 22:17:45 1.6 --- gdbtk-varobj.c 2001/05/08 00:27:16 *************** variable_update (interp, var) *** 463,475 **** Tcl_Obj *changed; struct varobj **changelist; struct varobj **vc; changed = Tcl_NewListObj (0, NULL); /* varobj_update() can return -1 if the variable is no longer around, i.e. we stepped out of the frame in which a local existed. */ ! if (varobj_update (var, &changelist) == -1) return changed; vc = changelist; while (*vc != NULL) --- 463,487 ---- Tcl_Obj *changed; struct varobj **changelist; struct varobj **vc; + int numchanged; changed = Tcl_NewListObj (0, NULL); + + numchanged = varobj_update (var, &changelist); /* varobj_update() can return -1 if the variable is no longer around, i.e. we stepped out of the frame in which a local existed. */ ! if (numchanged == -1) return changed; + + /* varobj_update() can return -2 if the variable type changed, + i.e. we are looking at a different variable with the same name. */ + if (numchanged == -2) + { + /* Add a type changed mark to the result list */ + Tcl_ListObjAppendElement (NULL, changed, + Tcl_NewStringObj ("*", -1)); + } vc = changelist; while (*vc != NULL) Index: gdbtk/library/variables.tcl =================================================================== RCS file: /cvs/src/src/gdb/gdbtk/library/variables.tcl,v retrieving revision 1.8 diff -c -p -r1.8 variables.tcl *** variables.tcl 2001/04/17 16:14:23 1.8 --- variables.tcl 2001/05/08 00:27:17 *************** class VariableWin { *** 827,846 **** # debug "VARIABLE: $var ($Update($this,$var))" set numchild [$var numChildren] set UpdatedList [$var update] ! # FIXME: For now, we can only infer that the type has changed ! # if the variable is not a scalar; the varobj code will have to ! # give us an indication that this happened. ! if {([lindex $UpdatedList 0] == $var) ! && ($numchild > 0)} { debug "Type changed." # We must fix the tree entry to correspond to the new type ! $Hlist delete offsprings $var $Hlist entryconfigure $var -text [label $var] if {[$var numChildren] > 0} { $Tree setmode $var open } else { $Tree setmode $var none } } else { set ChangeList [concat $ChangeList $UpdatedList] # debug "ChangeList=$ChangeList" --- 827,852 ---- # debug "VARIABLE: $var ($Update($this,$var))" set numchild [$var numChildren] set UpdatedList [$var update] ! ! # A '*' indicates the the type of the following variable has changed. ! if {[lindex $UpdatedList 0] == "*"} { debug "Type changed." + # We must fix the tree entry to correspond to the new type ! if {$numchild > 0} { ! # If previous type had children remove them. ! $Hlist delete offsprings $var ! } $Hlist entryconfigure $var -text [label $var] if {[$var numChildren] > 0} { $Tree setmode $var open } else { $Tree setmode $var none } + + # Must remove the type changed indicator + set ChangeList [concat $ChangeList [lrange $UpdatedList 1 end]] + } else { set ChangeList [concat $ChangeList $UpdatedList] # debug "ChangeList=$ChangeList" ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Variable errors 2001-05-07 17:33 ` Fernando Nasser @ 2001-05-10 17:25 ` Keith Seitz 0 siblings, 0 replies; 8+ messages in thread From: Keith Seitz @ 2001-05-10 17:25 UTC (permalink / raw) To: Fernando Nasser; +Cc: Insight Maling List, Jim Ingham On Mon, 7 May 2001, Fernando Nasser wrote: > Keith Seitz wrote: > > > > On Wed, 11 Apr 2001, Fernando Nasser wrote: > > > > > I guess you're right, I forgot the scalars. Try this patch (*UNTESTED*) > > > for now. I will flag the varobj name if the type has changed over the > > > weekend. Until I do this, variables that change type from scalar to > > > scalar (different types) will be highlighted. > > > > Well, it took a while, but I now have the patch to address Keith's concerns. > > The indication that the type of the variable has changed (well, it is > another variable with the same name actually) is now returned and can be > tested regardless of the old variable being a scalar or a complex type. > It seems to work in all cases now. Yep, works well. I just have one small nitpick... Can we *please* not return numbers which mean things? Or can we #define the return values? -2 and -1 don't mean much to me. Thank you for looking into (and fixing) this. Keith ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-05-10 17:25 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-11 11:14 Variable errors Keith Seitz 2001-04-11 11:23 ` Fernando Nasser 2001-04-11 11:31 ` Keith Seitz 2001-04-11 11:58 ` Fernando Nasser 2001-04-11 12:13 ` Keith Seitz 2001-04-11 12:27 ` Lewin A.R.W. Edwards 2001-05-07 17:33 ` Fernando Nasser 2001-05-10 17:25 ` 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).