Becoming a contributor
dmitry.risenberg at gmail.com
Wed Sep 29 16:10:11 UTC 2010
I think there should be an easy way to distinguish between TODOs and
parser errors, because TODOs often stay in code for a long time, and I
want it to be clear if there are any parsing errors that need
immediate attention. May be integrate it into Problems and add a
BTW, is it OK to develop in 4.1 branch sources, so that I don't have
to set up KDE4.5 libraries (have 4.4 right now)?
2010/9/29 Milian Wolff <mail at milianw.de>:
> On Wednesday, 29. September 2010 17:00:14 Aleix Pol wrote:
>> It's another option.
>> The main point i proposed reading the files separatedly is because I think
>> that most time spent on parsing files is on duchain building instead of
>> file parsing itself, so that reading the files again with a regular parser
>> should be real fast ("wcgrep TODO" in kdevplatform takes 5.5 seconds in my
>> system on the first run, when it's cached it's blazingly fast, <0.1s).
> And what about bigger projects? Linux kernel? Really, I spent lots of time
> making KDevelop faster, this kind of duplicated stuff will just increase load
> immensely, just think about the lots of disk accesses! Esp. when the
> background parser is already accessing the disk a lot, having yet-another-
> multithreaded-heavy-IO plugin is simply a no-go!
>> Also using different regex would make it possible to gather information
>> also from other languages (python, bash, perl,...) where language support
>> is not as important as for c++ but we still might want to know about its
> Again, I disagree. It just starts with the fact that comments are language
> dependent. I don't want this to match:
> i18n("lines containing TODO or FIXME will showup in the problem reporter")
> So language dependent regular expressions? Really, this is not something I
> want to maintain. Lets just reuse what architecture we have!
>> Also I'm not sure we want to add Problems from the users, since they're not
>> problems, just issues we have to track down.
> I forgot that, the problem toolview would have to get revamped (it's UI is
> really bad imo). For one thing it's currently per-focused-file, no project
> overview available (which is requested!).
> Imo a parse error and a FIXME are the same, just of different importance.
> Introducing yet another toolview for TODOs and FIXMEs is imo not any good.
>> On Wed, Sep 29, 2010 at 4:03 PM, Milian Wolff <mail at milianw.de> wrote:
>> > On Wednesday, 29. September 2010 15:50:40 Aleix Pol wrote:
>> > > I agree it's a good one. I was thinking about it once, I think the best
>> > for
>> > > that one would be to process a regex all through the code for the TODO
>> > > comments, that way you don't need to mess with AST's and well, comments
>> > > usually are not there either so it's not something you would rely on.
>> > >
>> > > So I would create a plugin that on project creation parsed all files
>> > using
>> > > some simple regex to look for what the user wants and then whenever a
>> > file
>> > > is saved it should be read again.
>> > >
>> > > If you could get there I think that would be useful already and we
>> > > could still do more on that later.
>> > Sorry, but I object, and greatly so. Parsing huge projects is slow
>> > _already_
>> > no need to slow it down even further by running regexps on each and every
>> > file
>> > in the project.
>> > The correct way is to do the following:
>> > - add a TODO severity to iproblem.h
>> > - write a helper function that can be run on *single* comments (not on
>> > whole
>> > documents), best place would be
>> > kdevplatform/language/duchain/stringhelpers.cpp
>> > Than use these tools in existing builders of the languages, e.g. in
>> > cpp/DeclarationBuilder::parseComments
>> > Bye
>> > --
>> > Milian Wolff
>> > mail at milianw.de
>> > http://milianw.de
>> > --
>> > KDevelop-devel mailing list
>> > KDevelop-devel at kdevelop.org
>> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> Milian Wolff
> mail at milianw.de
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
More information about the KDevelop-devel