Re: Python pretty-printed output isn't pretty :-(

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Fri, Nov 7, 2008 at 3:43 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> Paul> (gdb) p foo
> Paul> $3 = {mis =
> Paul> std::map with 5 elements, [0] = 0x406068 "/home/ppluzhnikov/src/tmp/simple-stl2", [1] = 0x406188 "foe", [2] = 0x406268 "fi", [3] = 0x406348 "fu", [4] = 0x406428 "fum", msi =
> Paul> std::map with 5 elements, [0x4060b8 "/home/ppluzhnikov/src/tmp/simple-stl2"] = 0, [0x406298 "fi"] = 2, [0x4061b8 "foe"] = 1, [0x406378 "fu"] = 3, [0x406458 "fum"] = 4}
>
> Why do we get a newline after "mis ="?

I think because GDB treats the entire 'std::map...fum"' as a
single item, and since that overflows current width, wraps before it.

> Otherwise this looks reasonable-ish ... your second example was nicer,
> but the extras are just a bit more code in _format_children.
>
> Paul> But I don't see how Python pretty printer could cooperate with
> Paul> wrap_here().  It could pay attention to width though.
>
> As an aside, I'm not very fond of wrap_here.  For one thing, its state
> is global -- but it seems to me that it really ought to be per-stream.
>
> Right now we have a hack to make things print "nicely", but this hack
> more or less assumes "set print pretty on", since I didn't want to
> mess with passing a bunch more info to pretty-printers.
>
> Now that all CLI output goes through _format_children, perhaps we
> could reconsider this.  We can pass it whatever arguments we like.
> So, we could pass it 'recurse' so that it can know about the depth at
> least.  And, we could do the actual printing from _format_children
> rather than returning a string.
>
> We'd probably also need a way to wrap a ui_file, but we'll want that
> anyhow.
>
> What do you think of that?

Yes, that sounds like a good idea.

> Another (extreme) solution would be to disable pretty-printing unless
> "set print pretty" is set.  I'm not super fond of this.

Me either: we have really large composition objects here @google,
printing them with 'pretty off' already fills 2-3 screens.
Forcing 'pretty on' just so I can see reasonable output for
std::string sounds like too much.

> On a related note, I have been thinking that perhaps we need to rename
> this feature, since "pretty printing" already has a meaning in gdb.
> Perhaps "visualizing".

Sounds good to me. Although I find "pretty printing" and "python
pretty printing" easy to distinguish, this may not be so easy
for end-users.

> Also, I've been wondering if we want to drop the address when we print
> a std::string.  To me it is just noise.

I agree.

-- 
Paul Pluzhnikov