public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH] debuginfod-find: Be a bit less verbose with -v
Date: Tue, 17 Nov 2020 14:38:14 +0100	[thread overview]
Message-ID: <67cfdfd59981628f148201d700388c54e912e05e.camel@klomp.org> (raw)
In-Reply-To: <82a4da0822b0cc1f69562769cd14498f07c71cf8.camel@klomp.org>

On Wed, 2020-11-11 at 22:24 +0100, Mark Wielaard wrote:
> On Wed, 2020-11-11 at 15:57 -0500, Frank Ch. Eigler wrote:
> > On Wed, Nov 11, 2020 at 09:31:38PM +0100, Mark Wielaard wrote:
> > > debuginfod-find -v enables a progressfn that prints the Progress
> > > every
> > > time the callback is called. [...]
> > > [...]
> > > -  fprintf (stderr, "Progress %ld / %ld\n", a, b);
> > > [...]
> > 
> > Another option is to use something close what the builtin env
> > DEBUGINFOD_PROGRESS=1 code does: print self-overwriting messages with
> > \r rather than \n.  That way many messages can come, but they don't
> > overpower the screen.  Really, the main reason I put in this
> > progressfn into debuginfod-find was to help test that API within the
> > testsuite.  Maybe now, we don't need that option to do anything but
> > set the env var, therby using the common code.
> 
> It was indeed the specific testcase that made me keep the messages as
> is. And it seems a good idea to have a code path that explicitly uses
> the api calls instead of relying on the environment variable. Also I
> found it a bit more difficult to combine the self-overwriting messages
> with other verbose output. See my followup patch for producing verbose
> output. I think the "per line" verbose/progress for debuginfod-find -v
> works out well.

Assuming I totally convinced you with the above speech I pushed this
patch. On irc you said you also like the followup
debuginfod_set_verbose_fd/DEBUGINFOD_VERBOSE patch, but I am waiting a
bit longer with that one to see if there is any other feedback (also
because that one exports a new interface).

Cheers,

Mark

      reply	other threads:[~2020-11-17 13:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11 20:31 Mark Wielaard
2020-11-11 20:57 ` Frank Ch. Eigler
2020-11-11 21:24   ` Mark Wielaard
2020-11-17 13:38     ` Mark Wielaard [this message]

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=67cfdfd59981628f148201d700388c54e912e05e.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    /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).