Becoming a contributor

[Milian Wolff]

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
> TODO's.

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
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100929/d8aaa399/attachment.sig>