[Bug python/12806] New: multi-level pretty-printing

[Bug python/12806] New: multi-level pretty-printing

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12806

           Summary: multi-level pretty-printing
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tromey@redhat.com


A frequently requested feature is the ability to do
"multi-level" pretty-printing.  The idea here is that a printer
can return a child which is of some synthetic type not existing
in the inferior; that way it can specify a multi-level display
of some kind.

One way to achieve this would be to make it possible for a
printer's child to itself be a printer; then use that printer
directly rather than attempting to convert to a value.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[poenitz at htwm dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12806

Andre' Poenitz <poenitz at htwm dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |poenitz at htwm dot de

--- Comment #1 from Andre' Poenitz <poenitz at htwm dot de> 2012-11-28 22:06:38 UTC ---
Another option would be to move over to the "fat script" approach of pretty
printing (i.e. "do all in one go, top-down"). In that case the pretty printer
for an object can directly and easily decide by itself which real or which
artificial children, or grand-children, or completely unrelated data, it would
like to print and recursively invoke the "main" pretty print function to get
"standard behaviour" for the subitems. 

This would also solves issues related to missing MI variable updates for items
whose pretty print result takes global state or unrelated data into account
(see the example give in the thread triggered by
http://sourceware.org/ml/gdb-patches/2012-11/msg00027.html).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[poenitz at htwm dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12806

Andre' Poenitz <poenitz at htwm dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://sourceware.org/bugzi
                   |                            |lla/show_bug.cgi?id=14854

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthew.mcallister.0@gmail.
                   |                            |com

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
*** Bug 24201 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |30816
                 CC|                            |tromey at sourceware dot org


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=30816
[Bug 30816] [meta] Pretty-printing v2
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Andre' from comment #1)
> Another option would be to move over to the "fat script" approach of pretty
> printing (i.e. "do all in one go, top-down").

I want to do something that's also relatively useful to DAP.
In DAP, the child of a variable may itself be a variable.
So separate objects are probably the most straightforward.
This is similar to varobj but not as bizarre.

A one-shot, full-tree approach loses laziness, which is part of DAP.
However it could be done "either direction", either by having an
object that hands tearoffs to gdb, or by eagerly iterating over
children.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|30816                       |
         Depends on|                            |30816


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=30816
[Bug 30816] [meta] Pretty-printing v2
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Also see https://sourceware.org/bugzilla/show_bug.cgi?id=30816#c2
Natvis has a similar feature to this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806
Bug 12806 depends on bug 30816, which changed state.

Bug 30816 Summary: [meta] Pretty-printing v2
https://sourceware.org/bugzilla/show_bug.cgi?id=30816

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Now that the new base class is in, this could be done by
changing the varobj (and generic printing) code to recognize
when the 'children' method returns a ValuePrinter, and then
simply use that object.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[pedromsilva.git at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

Pedro Silva <pedromsilva.git at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedromsilva.git at gmail dot com

--- Comment #6 from Pedro Silva <pedromsilva.git at gmail dot com> ---
From the discussion on this bug, it seems that the hardest part has already
been implemented. Are there any plans to complete the required set of changes
so that a gdb.ValuePrinter object could also be returned?

It would be great to have this feature available and be able to what Natvis
already can do without any hacks.

In case there are no plans or there are other topics with higher priority,
would it be possible to provide some pointers/references to the source code on
how this can be done by someone new to GDB?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Pedro Silva from comment #6)
> From the discussion on this bug, it seems that the hardest part has already
> been implemented. Are there any plans to complete the required set of
> changes so that a gdb.ValuePrinter object could also be returned?

As far as I know, nobody is working on it.

> In case there are no plans or there are other topics with higher priority,
> would it be possible to provide some pointers/references to the source code
> on how this can be done by someone new to GDB?

Sure.

The basic pretty-printing code, used by the CLI, is in
gdb/python/py-prettyprint.c.  I think the idea here would
be to add a new case in the body of print_children to
check if the value ("py_v") inherits from the tag type.
If so, special handling would be done.

Next is varobj.  Unfortunately this code is a crazy mess.
Mostly it is in varobj.c.  Figuring out how to make this
work correctly might be difficult, though it may not be
terrible considering that there's already a way for a varobj
to just wrap a Python pretty-printer.  So I guess the idea
would be to notice when some child implements this tag
type, and construct a new child varobj -- but pre-configured
to use that returned printer.

Tests for the basic stuff would go somewhere in
gdb/testsuite/gdb.python.  varobj in gdb.mi.

Docs for the new feature would go in the pretty-printing
node in gdb/doc/python.texi.

For a truly complete patch you also need a small entry in NEWS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12806] multi-level pretty-printing

[pedromsilva.git at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12806

--- Comment #8 from Pedro Silva <pedromsilva.git at gmail dot com> ---
(In reply to Tom Tromey from comment #7)
> (In reply to Pedro Silva from comment #6)
> > From the discussion on this bug, it seems that the hardest part has already
> > been implemented. Are there any plans to complete the required set of
> > changes so that a gdb.ValuePrinter object could also be returned?
> 
> As far as I know, nobody is working on it.
> 
> > In case there are no plans or there are other topics with higher priority,
> > would it be possible to provide some pointers/references to the source code
> > on how this can be done by someone new to GDB?
> 
> Sure.
>

First of all, thank you for your kind and promptly reply.

> The basic pretty-printing code, used by the CLI, is in
> gdb/python/py-prettyprint.c.  I think the idea here would
> be to add a new case in the body of print_children to
> check if the value ("py_v") inherits from the tag type.
> If so, special handling would be done.
>

My understanding is that, roughly speaking, there is a recursion loop starting
in "gdbpy_apply_val_pretty_printer", passing through "print_children" and
ending in "common_val_print". Once I figured that out, I just extracted the
print section from "gdbpy_apply_val_pretty_printer" to a different function (no
need to find the pretty-printer from a value because it is already provided)
and called it directly from "print_children" in case a child node is a
"gdb.ValuePrinter". Apart from corner cases that I may be missing, it seems to
do the trick.

Do you mind if I start sharing here patch proposals in chunks so that they can
be discussed and properly shaped? I mean, a patch for the CLI, and another for
the GDB/MI (varobj). Same for unit tests and documentation.

> Next is varobj.  Unfortunately this code is a crazy mess.
> Mostly it is in varobj.c.  Figuring out how to make this
> work correctly might be difficult, though it may not be
> terrible considering that there's already a way for a varobj
> to just wrap a Python pretty-printer.  So I guess the idea
> would be to notice when some child implements this tag
> type, and construct a new child varobj -- but pre-configured
> to use that returned printer.
>

As you mentioned, this one is way tougher to implement. If my analysis is
correct, indeed, there are already "gdb.ValuePrinter" objects ("struct varobj",
"dynamic" field ["struct varobj_dynamic"]), but it is assumed that child
elements are always values. Let me explain why I think that is the case.

From "varobj_list_children" function, and in case there is a pretty-printer
configured ("varobj_is_dynamic_p"), "update_dynamic_varobj_children" function
ends up being called. Within "update_dynamic_varobj_children" function, child
elements are retrieved as "std::unique_ptr<varobj_item>" objects from a
"varobj_iter" iterator. A "varobj_item" only has a name and a value
("value_ref_ptr"), there is currently no way to save a "gdb.ValuePrinter"
object ("PyObject*"). I still don't have a clear picture on how all the pieces
fit together, therefore, I still need to spend more time analyzing what
"install_dynamic_child" and "install_new_value" functions are doing.

Any hints are more than welcome. :)

> Tests for the basic stuff would go somewhere in
> gdb/testsuite/gdb.python.  varobj in gdb.mi.
> 
> Docs for the new feature would go in the pretty-printing
> node in gdb/doc/python.texi.
> 
> For a truly complete patch you also need a small entry in NEWS.

Once the other two are in place, these can be tackled as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.