From: Tom Tromey <tom@tromey.com>
To: Tom de Vries <tdevries@suse.de>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [gdb/cli] Add a progress meter
Date: Fri, 11 Dec 2020 12:21:01 -0700 [thread overview]
Message-ID: <87k0togndu.fsf@tromey.com> (raw)
In-Reply-To: <5506b198-c504-0046-0559-bcc24538d31c@suse.de> (Tom de Vries's message of "Fri, 11 Dec 2020 18:51:45 +0100")
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> I've taken a look, and think that this code is more in line with gdb cli
Tom> setup, so I've reimplemented on top of this.
Tom> Here is the first patch, adding the progress meter infrastructure
Tom> factored out from your patch.
Not sure if I ought to review a patch that I largely wrote, but I did
find some things I think should be done differently nowadays.
Tom> +void
Tom> +cli_ui_out::do_progress_start (const std::string &name, int should_print)
should_print should probably be a bool, throughout this patch.
Tom> + /* Don't actually emit anything until the first call notify us
I think s/notify/notifies/
Tom> + if (!stream->isatty ())
Tom> + {
Tom> + fprintf_unfiltered (stream, "%s...", meter.name.c_str ());
This is probably fine but I suppose the meaning of "should_print" ought
to be described somewhere, since otherwise this could seem like a bug --
it is printing something even when should_print==false.
Tom> + m_meters.push_back (meter);
std::move(meter) would be more efficient here, since it would avoid
another string copy.
Tom> + progress_meter (struct ui_out *uiout, const std::string &name,
Tom> + int should_print)
Tom> + : m_uiout (uiout)
Here's probably where should_print should be documented.
Tom> +get_chars_per_line (void)
Just "()", not "(void)", now.
Tom> +++ b/gdb/utils.h
Tom> @@ -364,6 +364,10 @@ extern void wrap_here (const char *);
Tom> extern void reinitialize_more_filter (void);
Tom> +/* Return the number of characters in a line. */
Tom> +
Tom> +extern int get_chars_per_line (void);
Here too.
Tom
next prev parent reply other threads:[~2020-12-11 19:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 11:43 [PATCH] gdb: print size of downloaded debuginfod binary Martin Liška
2020-12-07 17:07 ` Simon Marchi via Gdb-patches
2020-12-08 10:16 ` Martin Liška
2020-12-08 14:28 ` Simon Marchi via Gdb-patches
2020-12-09 10:51 ` Martin Liška
2020-12-09 23:26 ` Tom de Vries
2020-12-10 8:26 ` Martin Liška
2020-12-10 19:21 ` Tom Tromey
2020-12-11 17:51 ` [gdb/cli] Add a progress meter Tom de Vries
2020-12-11 17:54 ` [PATCH] gdb: print size of downloaded debuginfod binary Tom de Vries
2020-12-11 19:23 ` Tom Tromey
2020-12-12 16:43 ` Tom de Vries
2020-12-15 20:29 ` Tom Tromey
2020-12-11 19:21 ` Tom Tromey [this message]
2020-12-12 16:35 ` [gdb/cli] Add a progress meter Tom de Vries
2020-12-15 20:28 ` Tom Tromey
2020-12-09 20:16 ` [PATCH] gdb: print size of downloaded debuginfod binary Tom Tromey
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=87k0togndu.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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