public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Chris Moller <cmoller@redhat.com>
Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] pr10659  	pretty-printing: Display vectors of vectors as matrix--rev 2
Date: Wed, 02 Jun 2010 22:58:00 -0000	[thread overview]
Message-ID: <m3mxvd11ql.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4C0407E4.3020604@redhat.com> (Chris Moller's message of "Mon, 31	May 2010 15:03:00 -0400")

>>>>> "Chris" == Chris Moller <cmoller@redhat.com> writes:

Tom> This is not ok.  This part of the test suite ought to be independent
Tom> from the C++ compiler in use.  Instead, write some new code (C is fine)
Tom> and an associated printer to exercise the new code in GDB.  There are
Tom> other examples of this in gdb.python.

Chris> I'm not altogether sure what you meant by this, but what I did was
Chris> rename printers.py to pr10659.py and strip out everything but the
Chris> vector/matrix code and tinker pr10659.exp to match.  This seems to be
Chris> consistent with what py-prettyprint.* does--if I've guessed wrong, let
Chris> me know.

What I meant is that it is fragile for our test suite to rely on
internal details of std::vector.  Instead, our test suite ought to be as
independent of compilers and libraries as possible.  In this particular
case, there is no reason to rely on std::vector in the test case,
because it is not difficult to write some new test code and a new
printer to exercise the matrix code paths.  This is what is done
elsewhere in gdb.python.

Chris> +  if (is_matrix&&  recurse == 0)
Chris> +    fputs_filtered ("\n", stream);

Tom> I suspect this is not correct in the !pretty case.
Tom> Maybe for !pretty the matrix stuff should just be disabled, I don't see
Tom> what it would add.

Chris> A "matrix" hint turns on pretty mode--this seems to be consistent with
Chris> what an "array" hint does.

There is some confusing terminology here, in that multiple things are
called "pretty printing".

I think as a rule we should only emit newlines when asked for, either by
"set print array" or "set print pretty".  That is what I meant by the
above.

Chris> +  is_py_none = is_matrix ? 1 : print_string_repr (printer, hint, stream,
Chris> +						  recurse, options,
Chris> +						  language, gdbarch);

Tom> What is the rationale for this change?

Chris> print_string_repr() is what prints the "std::vector of length..."
Chris> stuff which I need to suppress for printing matrices, and matrix
Chris> formatting needs is_py_none set to 1.

I see.  I suppose it is ok to suppress the inner ones, but it doesn't
seem correct to suppress the outermost.

Chris> -  pretty = is_array ? options->prettyprint_arrays : options->pretty;
Chris> +  pretty = (is_array || options->prettyprint_matrix) ?
Chris> +    options->prettyprint_arrays : options->pretty;

Wrong formatting.  Also see above about the newline situation...

Chris> +  if (options->prettyprint_matrix && recurse == 0)
Chris> +    fputs_filtered ("\n", stream);

...e.g.

Chris> +      else fputs_filtered ("}", stream);

Formatting.

Chris> +      options_copy = alloca (sizeof (struct value_print_options));
Chris> +      memcpy (options_copy, options, sizeof (struct value_print_options));

Just introduce a new local and copy it unconditionally.

Chris> +  else options_copy = (struct value_print_options *)options;

As a rule, never cast away const.

Chris> +  is_py_none = options_copy->prettyprint_matrix ?
Chris> +    1 : print_string_repr (printer, hint, stream,
Chris> +			   recurse, options_copy,
Chris> +			   language, gdbarch);

Formatting.  Let me recommend reading through the GNU coding standards.
They have a decent section on how C code should be formatted.


Some other general notes..

As this is a general facility for matrix printing, I wonder how you
would handle situations like a 2-dimensional array.

A new printing hint requires an update to the manual.

Please look at how this impacts MI varobjs, if at all.

Tom

  reply	other threads:[~2010-06-02 22:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27 17:46 [patch] pr10659 pretty-printing: Display vectors of vectors as matrix Chris Moller
2010-05-27 21:14 ` Phil Muldoon
2010-05-27 22:25   ` Chris Moller
2010-05-27 21:20 ` Tom Tromey
2010-05-31 23:21   ` [patch] pr10659 pretty-printing: Display vectors of vectors as matrix--rev 2 Chris Moller
2010-06-02 22:58     ` Tom Tromey [this message]
2010-06-30 12:26     ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3mxvd11ql.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=cmoller@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).