Variable errors

Variable errors

[Keith Seitz]

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

Re: Variable errors

[Fernando Nasser]

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

Re: Variable errors

[Keith Seitz]

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

Re: Variable errors

[Fernando Nasser]

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

Re: Variable errors

[Keith Seitz]

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

Re: Variable errors

[Lewin A.R.W. Edwards]

>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.

Re: Variable errors

[Fernando Nasser]

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"

Re: Variable errors

[Keith Seitz]

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