From: Paul Bolle <pebolle@tiscali.nl>
To: Michal Marek <mmarek@suse.cz>
Cc: Valentin Rothberg <valentinrothberg@gmail.com>,
akpm@linux-foundation.org,
Stefan Hengelein <stefan.hengelein@fau.de>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] checkkconfigsymbols.sh: reimplementation in python
Date: Mon, 29 Sep 2014 18:21:42 +0200 [thread overview]
Message-ID: <1412007702.6334.71.camel@x220> (raw)
In-Reply-To: <5429711C.4060008@suse.cz>
Hi Michal,
[This point I already conceded to Valentin, so my remarks are moot for
Valentin's script.]
On Mon, 2014-09-29 at 16:47 +0200, Michal Marek wrote:
> On 2014-09-29 12:28, Paul Bolle wrote:
> >> +STMT = r"^\s*(?:if|select|depends\s+on)\s+" + EXPR
> >
> > Could please make that "depends on"? Yes, it seems the yacc grammar
> > accepts any amount of whitespace, but that doesn't make it right to use
> > anything other than a single space.
>
> But then lines that violate coding style would not be checked for real
> errors.
Perhaps my dislike of this element of the grammar won here. There are
probably better ways to enforce proper use of "depends on".
> > (Can the yacc grammar be tweaked to
> > see "depends on" as one, well, token?)
>
> I don't think this is a good idea. This is a style issue, why make it a
> grammar issue.
Well, a grammar that allows one of its keywords to be written in
different ways makes style and grammar issues overlap. Whatever. I guess
it's just me being annoyed with writing
git grep -w "depends\s\+on\s\+FOO"
instead of
git grep -w "depends on FOO"
Ditto for writing a parser for Kconfig files. (Real world examples are
more complicated, but you catch my drift.)
Paul Bolle
next prev parent reply other threads:[~2014-09-29 16:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 14:15 [PATCH] checkkconfigsymbols.sh: reimplementation in python Valentin Rothberg
2014-09-21 19:39 ` [PATCH v2] " Valentin Rothberg
2014-09-21 19:53 ` [PATCH v3] " Valentin Rothberg
2014-09-21 21:28 ` Paul Bolle
2014-09-22 7:43 ` Valentin Rothberg
2014-09-22 8:24 ` Paul Bolle
2014-09-22 8:45 ` Valentin Rothberg
2014-09-22 9:06 ` Paul Bolle
2014-09-22 14:58 ` [PATCH v4] " Valentin Rothberg
2014-09-23 16:45 ` Paul Bolle
2014-09-27 12:57 ` [PATCH v5] " Valentin Rothberg
2014-09-27 14:30 ` [PATCH v6] " Valentin Rothberg
2014-09-28 15:55 ` [PATCH v7] " Valentin Rothberg
2014-09-29 10:28 ` Paul Bolle
2014-09-29 12:08 ` Valentin Rothberg
2014-09-29 12:45 ` Paul Bolle
2014-09-29 14:47 ` Michal Marek
2014-09-29 16:21 ` Paul Bolle [this message]
2014-09-29 17:05 ` [PATCH v8] " Valentin Rothberg
2014-10-01 14:58 ` Michal Marek
2014-10-04 9:29 ` Valentin Rothberg
2014-10-08 13:39 ` Michal Marek
2014-10-19 15:30 ` Valentin Rothberg
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=1412007702.6334.71.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=stefan.hengelein@fau.de \
--cc=valentinrothberg@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.