Re: [Nemiver-list] Variable monitor widget

[Dodji Seketeli <dodji domain hid>]

Jonathon Jongsma a écrit :
[...]

[...]

> Also, I think we definitely want to be 
> able to right-click something in the editor and add it to the monitor, 
> but that feature could probably come later since it will likely be a 
> little tricky to get right (e.g. making sure it does the right thing 
> when you right click on something like foo->bar.x).
That's a particular case of the more generic scheme that is "Be able to 
parse things from the source and determines their type somehow" - and 
that is hard, very hard.

So for a start, it'll still be better than nothing to just let the user 
try to add the "thing" to the variable monitor. If that thing is not a 
variable so nothing will show up. That might seem a bit brutal, but 
well, I am sure to see a better alternative that comes at a reasonable cost.

[...]

> Yes.  I guess the 'right' way to deal with this is probably to revamp 
> our gdb interaction a bit so that we can actually report and receive 
> errors reliably.

Yes, and that'll take some energy. We definitely need to look into that 
at some point though. I am thinking about it and will prolly write a 
little proposal for that at some point.

>  But currently we don't really have any way to do 
> this.  I suppose that one hacky workaround at the moment might be 
> something like this:
> - whenever the debugger stops, go through the list of variables in the 
> monitor and set each one's value to something like "<out of scope>"
> - query all of the variables
> - when we receive a variable undated signal, update its to the real value.
> This way, any variables that went out of scope will display an error 
> indication to the user since they won't get a response from querying gdb 
> for its new value.  The downsides of this option are that it's an ugly 
> hack and that the variable values will probably flicker between "<out of 
> scope>" and the real value on each step.  But I don't see a much better 
> option until we get some improved error reporting...

Yep, I think we can cope with the flickr for now :-) I think like you 
that it's the best alternative for now. It'll be easy to change as well, 
when we have proper error reporting in place.

> > There is also the need to be able to be able to monitor "locations" 
> > pointed to by addresses, instead of just variable names. I am not sure 
> > how to present that either.
>
> hm, what do you mean by this exactly?  Do you mean the user should be 
> able to type something like "0xbf445566" into the monitor widget and 
> have it display the data at that memory location?  or using an explicit 
> cast (e.g. "(float*)0xbf445566")? 

Yes, I am talking about being able to say "monitor the variable foo (of 
type Foo) that is located at 0xbf445566.

> How does your use case differ from 
> the memory view widget?

The difference with the memory widget is that it gives you a typed 
result. If Foo is a complex type like say, an stl vector, you will be 
able to browse it. The memory widget will just show you a flat sequence 
of bytes.

> > I am not sure this helps much, but I thought I'd be good to write 
> > about my current state of thoughts on the matter :-)
>
> Thanks.  btw, I was hoping to get a good start on this by doing some 
> hacking at GUADEC, but unfortunately I had almost no time to hack while 
> I was there, so I haven't really made any progress on this.

Hehe, no problem. We are all doing this in our free time, aren't we ?

I hope you did enjoy GUADEC and that you will recover very soon from it.

All the best,

Dodji.