public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Galvan <martin.galvan@tallertechnologies.com>
To: Roland McGrath <roland@hack.frob.com>
Cc: libc-alpha@sourceware.org,
	 Daniel Gutson <daniel.gutson@tallertechnologies.com>,
	"Carlos O'Donell" <carlos@redhat.com>,
	 Siddhesh Poyarekar <sid@reserved-bit.com>,
	Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH v5] Add pretty printers for the NPTL lock types
Date: Mon, 11 Apr 2016 21:56:00 -0000	[thread overview]
Message-ID: <CAOKbPbausROA=TM1K8Up=ttc9sHxaLtBWUsi7KPxDiS77+Jiig@mail.gmail.com> (raw)
In-Reply-To: <20160411213057.92EE82C3B22@topped-with-meat.com>

On Mon, Apr 11, 2016 at 6:30 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I'm sorry I didn't participate in the earlier review threads.  I don't know
> what Siddhesh's rationale for that was.  But it's just not the modular
> thing to do.  Not every configuration includes every subdir, so things just
> break if one subdir always assumes that others exist.

I thought Depend took care of that. In any case, Sid remarked that It
would be clumsy to have the printers in different module directories
now and then putting them all into the same directory during
installation. It also makes sense to have them tested separately
through a single Makefile, and it's the right place to put things like
test_common.py and the pretty printers README.

>> > I noticed several lines (perhaps all comments) that were a bit too long.
>> > No line should have column 80 occupied.
>>
>> We discussed this with Sid, here:
>
> Whatever you discussed before, this is a straightforward part of the glibc
> coding style and you don't get to ignore it for new code.

It's a technical issue, actually, and it's explained in all the test
programs. Basically, I saw that having 'if' conditions split in more
than one line seems to confuse gdb to the point where we need to issue
a (somewhat random) number of 'next' commands to advance. This
complicates testing quite a bit.

>> Really? I though I had fixed them all. Could you point out where?
>
> (re-search-forward "\\. \\S ")

Found a couple, will fix them.

>> All my files have a descriptive comment, though it's after the
>> copyright notice. I can move it up if you want to.
>
> That is a nonnegotiable standard for new files added to the source tree.

Ok. Is it ok if I place a single line of comment above the license,
then leave a more detailed explanation below it? E.g. for
nptl-printers.py we'd have:

# Pretty printers for the NPTL lock types.
# Copyright (C) 2016 Free Software Foundation, Inc.
...

"""This file contains the gdb pretty printers for the following types:
...
"""

  reply	other threads:[~2016-04-11 21:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 20:09 Martin Galvan
2016-04-11 20:38 ` Roland McGrath
2016-04-11 20:52   ` Martin Galvan
2016-04-11 21:31     ` Roland McGrath
2016-04-11 21:56       ` Martin Galvan [this message]
2016-04-11 22:17         ` Roland McGrath
2016-04-12  3:04           ` Siddhesh Poyarekar
2016-04-12  5:59             ` Siddhesh Poyarekar
2016-04-12 13:20               ` Martin Galvan
2016-04-12 14:55                 ` Martin Galvan
2016-04-12 15:59                   ` Siddhesh Poyarekar
2016-04-12 18:48                     ` Martin Galvan
2016-04-12 18:56                       ` Siddhesh Poyarekar
2016-04-12 19:05                         ` Martin Galvan
2016-04-12 21:28                           ` Martin Galvan
2016-04-18 14:10                             ` Martin Galvan
2016-04-20 12:44                               ` Martin Galvan
2016-04-25 21:59                                 ` Martin Galvan

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='CAOKbPbausROA=TM1K8Up=ttc9sHxaLtBWUsi7KPxDiS77+Jiig@mail.gmail.com' \
    --to=martin.galvan@tallertechnologies.com \
    --cc=carlos@redhat.com \
    --cc=daniel.gutson@tallertechnologies.com \
    --cc=libc-alpha@sourceware.org \
    --cc=roland@hack.frob.com \
    --cc=sid@reserved-bit.com \
    --cc=tom@tromey.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).