After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 447906 - ability to inspect STL containers
ability to inspect STL containers
Status: RESOLVED FIXED
Product: nemiver
Classification: Other
Component: general
trunk
Other All
: Normal enhancement
: ---
Assigned To: Nemiver maintainers
Nemiver maintainers
Depends on: 580316
Blocks:
 
 
Reported: 2007-06-15 14:57 UTC by Jonathon Jongsma
Modified: 2011-09-04 21:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathon Jongsma 2007-06-15 14:57:56 UTC
It would be really nice to have some capability to inspect at least standard STL containers such as std::list, std::vector, std::map, etc.  This would probably need to be done as a plugin or something because it may need to be implemented differently for each STL implementation, etc.  
In addition to the standard stuff, some ability to inspect other common types (e.g. boost or Glib/Gtk stuff) would be really helpful, though that would be a lower priority.
Comment 1 Oliver Gerlich 2008-02-01 11:48:06 UTC
In addition to this, it would be nice if one could add "decoders" for own data structures. For example, if I have an own date/time data type in my project, it would be neat if I could teach nemiver how to print instances of this data type in a human readable format.

Possible extensions to this:
- write-support for these decoders (being able to specify a human-readable date/time format that is then encoded into the format of the data structure) - I don't actually see a use case for this but it comes to mind for completeness reasons
- being able to write these decoders in Python and plug them in at runtime, with less than 10 minutes work per data type :-)
- integrating this with the GetHotNewStuff project for getting decoders for all kinds of data structures (in OpenSource software) that people have contributed
- offering a way for library maintainers to ship decoders for their own data structures, that are then magically used by nemiver
Comment 2 Jonathon Jongsma 2008-02-01 14:28:21 UTC
yeah, these are all really good ideas, thanks for sharing.  We still have a bit more basic functionality to finish before this gets to the top of the priority list, so it may be a while before this actually gets implemented.  Of course, patches are always welcomed :)
Comment 3 logari81 2010-02-21 20:49:23 UTC
The following .gdbinit file could be a useful reference for the person who will try to implement this feature:
http://www.yolinux.com/TUTORIALS/src/dbinit_stl_views-1.03.txt
Comment 4 Tom Tromey 2010-08-25 15:53:05 UTC
GDB has this feature, all that is needed is to implement support in nemiver
http://sourceware.org/gdb/current/onlinedocs/gdb/Selecting-Pretty_002dPrinters.html#Selecting-Pretty_002dPrinters
Comment 5 Dodji Seketeli 2010-08-30 09:40:45 UTC
Indeed. Supporting GDB pretty printers is what we want for this. More generally I think we need a way in Nemiver to "adjust" how variables are displayed. E.g, for integral variable, the user might need to display it's value either in hexadecimal or decimal. For an aggregate variable, the user might need to display it in a pretty way or not. Thus, in response to bug https://bugzilla.gnome.org/show_bug.cgi?id=580316 too, I have created the branch http://git.gnome.org/browse/nemiver/log/?h=better-variable-format where I will be working on.
Comment 6 Dodji Seketeli 2011-01-23 00:37:37 UTC
I have just added support for pretty printing in the branch mentioned in the comment above. If you have a recent enough GDB it should just work in Nemiver. There is a preference check button to disable the feature if you like. Changing that feature does requires that you restart the debugger as GDB doesn't allow changing that mode on the fly AFAIK.
Comment 7 Tom Tromey 2011-01-24 21:47:49 UTC
(In reply to comment #6)
> Changing
> that feature does requires that you restart the debugger as GDB doesn't allow
> changing that mode on the fly AFAIK.

You can't disable the feature as a whole, but you can disable
it for any given varobj.
So, you can "-var-create ...", then "-var-set-visualizer var None"

If that is insufficient, file a gdb bug report and we can figure it
out there.
Comment 8 Dodji Seketeli 2011-01-30 10:25:43 UTC
Indeed, but that is not really practical. In a graphical environment
where you can see a bunch of variables at once (e.g in a dialog where
you are seeing the local variables of a function) it makes sense to be
able to switch the feature on and off globally. Of course being able
to enable/disable pretty printing for each varobj basis is useful as
well. I think we need both to have a nice user [and programming
;-)] experience.

Of course Nemiver could walk all the varobjs currently displayed and
change their visualizer -- and I think I am going to do that -- but
just having --disable-pretty-printing would truly rock instead.

I am going to file a GDB bug for this then.
Comment 9 Dodji Seketeli 2011-03-02 18:53:41 UTC
I have filed bug http://sourceware.org/bugzilla/show_bug.cgi?id=12530
as an enhancement request.  I have implemented workarounds in the
Nemiver branch better-variable-format for now though.
Comment 10 Dodji Seketeli 2011-03-02 18:55:39 UTC
Also, note that with the workarounds implemented for now, when trying
switching pretty-printing off and on again, I get a GDB crash.  This
is bug http://sourceware.org/bugzilla/show_bug.cgi?id=12531.
Comment 11 Dodji Seketeli 2011-09-04 21:05:25 UTC
So the branch better-variable-format has been merged into master.  So
Nemiver now supports pretty printing; you can switch on/off the
feature and see it instantly applied, i.e, without having to restart
the debugger.

#657834 reports that there is a GDB bug that makes some pretty
printers for some containers to not fire, unfortunately.  A GDB bug
has been filed upstream.

I am now closing this bug as it's purpose was to implement the
Nemiver's side of the pretty printing support.  You can track #657834
for the remaining issues.