Thanks so much for that explanation Dodji, I have gotten a little feedback from the vala mailing list as well now. It was made clear to me that I could call clutter_actor_get_width(r) from within the debugger to access that particular property so I guess calling accessor methods is another approach to use. What still confuses me some is that I can print the value of the property out to the console with vala's printf statement. It seems to me that there must be some way to get the debugger (gdb) to grock what the vala printf statement does without having to rewrite the valac compiler. It looks like one user did some work on a gdb patch that might address this. I'll need to look into it.
Thanks again Brian On Sun, Dec 18, 2011 at 6:21 AM, Dodji Seketeli <[email protected]> wrote: > Hello Brian, > > Brian Duffy <[email protected]> a écrit: > > > First of all, I'm new to Vala/Clutter and Nemiver. > > You are welcome on this mailing list. > > > I'm posting here because I'm having a debugging problem but that does > > not mean it is Nemiver's fault. Still, I get no response from Clutter > > or Vala mailing lists so I'm hoping someone uses Nemiver to debug > > vala/clutter programs. > > I see. Please bear in mind that Vala, by design, doesn't generate debug > information about its type system. Rather, it generate C code that is > in turn compiled by a C compiler. One of the problems with this > approach is what I'd generally call "less than optimal integration with > the rest of the toolchain". > > One part of the toolchain that needs special integration care is the > part that deals with debug info generation. > > For instance, in C, the only types a user can create are structs. So > your instances of classes and implementations of interfaces in Vala that > are meaningful to you become a set of structs underneath, that are not > necessarily as meaningful as the abstractions you put together in Vala > in the first place. > > That is usually not a problem as compilers routinely "unroll" users' > abstractions, to make data structures better fit with the underlying > system. It can be a problem, though, when those unrolled abstractions > are presented back to you when you are debugging your own code. At that > point, there is an impedance mismatch between the source code you wrote > and what the debugger is presenting you. > > The good way to "fix" this, or rather to prevent it from happening in > the first place is to have the compiler generate binaries directly (so > that it can have an opportunity to generate the debug information that > accurately describes the abstractions that the language allows), rather > that generating C code that is later compiled by a C compiler. This is > the tough lesson that implementors of languages like C++, Ada, D, > Objective-C, etc, all learned with time. This is one of the reasons why > you'll see these languages are implemented as front-ends of a greater > compiler system that helps in taking care about things like debug info. > > History shows that, most of the time, implementors of new languages do > their experiments in their own "circles", rather than integrating with > existing compiler systems and communities to come up with something that > integrates well with a native toolchain. And some of them end up > integrating their language implementation with a greater compiler > system. > > > Specifically, I am trying to play with the Vala clutter-demo example > > from their website. The example runs fine when I execute it. I am > > compiling it with valac -g --pkg clutter-1.0 --save-temps. I notice > > when I load the executable in Nemiver and set a break point that I can > > read variables defined in the Vala language such as loop counter > > iterators with success. The problem I am having is that reading the > > properties of clutter objects in the debugger is not working as I had > > hoped. > > I see. > > > For instance if a Rectangle r is defined then it shows up in the > > context window as r and its type is defined as ClutterRectangle * and > > it has an hexadecimal value. I can't expand on the variable and if I > > highlight r.width in the code and try to inspect the variable then I > > get nothing in return. > > Right. Exactly the impedance mismatch I was talking about. When you > write "Rectangle r", I guess underneath, valac generates a pointer to a > C struct that is ClutterRectangle, whereas you, as a code writer, just > wrote Rectangle r. > > So when you ask the debugger to inspect r.width, there is nothing it can > do because nothing in the binary tells it that a type Rectangle exists, > and that it has a 'r' member, because no accurate debug info is > generated for that. The only debug info generated is about > ClutterRectangle pointers, because that is what the C compiler knows > about. > > You are taken back to 15 years ago, when, e.g, most C++ compilers where > implemented as C pre-processors, like what valac is today. > > > Is this as good as it gets for debugging Vala programs or am I doing > > something horribly wrong? Any thoughts would be welcome. > > Unfortunately I think it is as good as it can get, until the valac > implementation is changed to something that can insert accurate debug > information in the generated binaries. > > I hope this helps. > > -- > Dodji > _______________________________________________ > nemiver-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/nemiver-list > -- Duff
_______________________________________________ nemiver-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nemiver-list
