From: Oleg Verych <olecom@flower.upol.cz>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
Sam Ravnborg <sam@ravnborg.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Adrian Bunk <bunk@kernel.org>,
linux-kbuild@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: "Anyone who likes complexity and fuzzy logic" (Re: [PATCH] headerdep:...)
Date: Wed, 30 Apr 2008 19:57:16 +0200 [thread overview]
Message-ID: <E1JrGYO-0000Li-K6@flower> (raw)
In-Reply-To: <20080426161714.GR14990@parisc-linux.org>
Matthew Wilcox @ Sat, 26 Apr 2008 10:17:14 -0600:
> I think a more useful tool would be one which mapped something like
> 'use of down()' to 'needs to include <linux/semaphore.h>'. It needs
> to be at least somewhat done by hand because there are rules such
> as 'include linux/spinlock.h to get spinlock_t' (which is actually
> defined in linux/spinlock_types.h), but you want people to include
><linux/completion.h> directly rather than rely on it being pulled in
> through linux/sched.h, for example.
>
> It's further complicated by multi-file drivers, such as qla2xxx. Each
> file includes qla_def.h which includes a lot of the necessary header
> files for them ... but then each file will include a few more header
> files that it needs.
(gee...)
> So some implicit includes are _good_ and other implicit includes are
> _bad_ (as they hurt when trying to rationalise the header files).
> Anyone who likes complexity and fuzzy logic like this want to take a
> stab at writing such a tool?
Why? Why GNU C compiler developers didn't do such (obviously useful)
tool? C compiler (some part of it) *is* responsible for parsing,
tokenizing, etc. Why there is development of never-ending buggy
optimizations only[0]?
Matthew, i know you've asked for regular expressions ninjas once, here
simple example.
Syntax highlighting for text editors is the most notable
invention/implementation for ease of programming in last 20 years or so.
Question: why any parser, e.g. GNU/FOSS [C, SED, AWK, ELISP], Perl,
Python, do NOT have option to output OWN highlighted syntax? Don't those
parsers know what they parse, rules, syntax errors, etc.[1]? (Note: at
least framework in parser, so that trivial extending/configuring would be
possible).
Is it really so complex?
=[0]= rant =[0]=
Isn't that hardware had developed in exponential rate toward speed and
cache/RAM size, so any bloat and huge volumes of sources without flexible
configuration systems (to download and work with e.g. only one GCC or
Linux port) are handled quickly?
=[1]= rant =[1]=
No, unreadable and buggy regexp-based highlighting is everywhere with
never-ending features added WRT basic regular expressions!
For those Perl hackers out there: why mister Wall is attributed to
invent non greedy RE match, why he did so by introducing non portable
and non-readable syntax to already crappy RE?
Simple BRE based idea: '\{0, s\}'. Just like `sed` had overcame second
RE basic pronciple: first-match, by using flags 's///here'.
No, let's invent crutches!
Oh, crap....
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
next prev parent reply other threads:[~2008-04-30 17:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 13:45 [PATCH] headerdep: a tool for detecting inclusion cycles in header file Vegard Nossum
2008-04-26 13:59 ` Pekka Enberg
2008-04-26 14:17 ` Vegard Nossum
2008-04-26 14:22 ` Nick Andrew
2008-04-26 18:03 ` Jan Engelhardt
2008-04-26 15:00 ` Adrian Bunk
2008-04-26 15:21 ` Julia Lawall
2008-04-26 15:30 ` Vegard Nossum
2008-04-26 15:25 ` Vegard Nossum
2008-04-26 16:17 ` Matthew Wilcox
2008-04-26 16:38 ` Adrian Bunk
2008-04-30 17:57 ` Oleg Verych [this message]
2008-04-30 17:38 ` "Anyone who likes complexity and fuzzy logic" (Re: [PATCH] headerdep:...) Matthew Wilcox
2008-04-26 16:44 ` [PATCH] headerdep: a tool for detecting inclusion cycles in header file Adrian Bunk
2008-04-26 16:57 ` Vegard Nossum
2008-04-26 17:23 ` Adrian Bunk
2008-04-26 17:55 ` Vegard Nossum
2008-04-26 18:11 ` Jan Engelhardt
2008-04-26 18:26 ` Sam Ravnborg
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=E1JrGYO-0000Li-K6@flower \
--to=olecom@flower.upol.cz \
--cc=bunk@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=penberg@cs.helsinki.fi \
--cc=sam@ravnborg.org \
--cc=vegard.nossum@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox