<div class="gmail_quote">On Wed, Sep 29, 2010 at 6:10 PM, Dmitry Risenberg <span dir="ltr"><<a href="mailto:dmitry.risenberg@gmail.com">dmitry.risenberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think there should be an easy way to distinguish between TODOs and<br>
parser errors, because TODOs often stay in code for a long time, and I<br>
want it to be clear if there are any parsing errors that need<br>
immediate attention. May be integrate it into Problems and add a<br>
"Severity" column?<br></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
BTW, is it OK to develop in 4.1 branch sources, so that I don't have<br>
to set up KDE4.5 libraries (have 4.4 right now)?<br></blockquote><div>Sure it's fine, you can always merge with master when you move to KDE 4.5.</div><div><br></div><div>Good luck!</div><div>Aleix</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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