Becoming a contributor

[Aleix Pol]

On Wed, Sep 29, 2010 at 6:10 PM, Dmitry Risenberg <
dmitry.risenberg at gmail.com> wrote:

> 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
> "Severity" column?
>
Well you can concentrate on getting the problems to the Problem toolview and
we can figure out later a good, project-wide UI. Don't add new severity,
just create a new IProblem::Source type.


>
> 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)?
>
Sure it's fine, you can always merge with master when you move to KDE 4.5.

Good luck!
Aleix


>
> 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
> >> 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
> >
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> >
> >
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100929/6e76a6e4/attachment.html>