Krazy2 plugin for KDevelop

[Daniel Calviño Sánchez]

2012/10/29 Aleix Pol <aleixpol at kde.org>:
> Hi!
> First of all, cool stuff! :)

Thanks :)

> It might be interesting to integrate it with the language Problems? I
> don't really like the idea of having another toolview for finding
> problems.

When I started writing the plugin my idea was to integrate it with the
language Problems. But after giving it a thought I realized that I had
not enough time to properly integrate it with the language Problems,
and that a custom view was better than nothing.

The main reason is that Krazy2 needs a lot more time to analyze a
project than the time needed by the current problem providers. For
example, it takes around 14-15 minutes to analyze KTutorial (other of
my projects ;) ), which contains around 450 files. And that only with
the default checkers, with no extra checker. I felt that such a wait
didn't fit with the rest of language Problems, which are analyzed
quite fast.

Of course, that wait might only happen the first time the project was
analyzed. A cache could be used so the next analysis would only check
the files that changed since the last analysis. But even if there was
a caching system already available in KDevelop, I felt that making
everything work together would have taken me more time than what I had
available. Besides, there would have been other things to tackle, like
how to configure the Krazy2 analysis when using the language Problems.

> Maybe you can create an ILanguageChecksProvider plugin there? This
> could start bringing the pieces together...

I'm afraid that I don't have time right now for further development of
this plugin :(



2012/10/29 Andreas Pakulat <apaku at gmx.de>:
> Hi,
>
> On Mon, Oct 29, 2012 at 9:30 PM, Daniel Calviño Sánchez
> <danxuliu at gmail.com> wrote:
>> That is pretty much what the plugin does. Not very impressive, I know
>> :P
>
> I think its impressive enough, in particular knowing the scarceness of
> our API docs and the steep learning curve to understand how the
> plugins work and finding how to write one.

Thanks, although it was just a matter of taking a look to some plugins
whose code I was already familiar with ;)

>> Besides those ideas, there is a problem that should also be tackled:
>> if a directory with a lot of files (hundreds of thousands) happens to
>> be selected to be analyzed, the KDevelop GUI will freeze while the
>> plugin is getting the list of files. Probably no one would need to run
>> a Krazy2 analysis from KDevelop on a directory with hundreds of
>> thousands of files, but even if it is selected by mistake, a freezed
>> GUI does not look good from a user perspective :)
>
> Sounds like that task is currently triggered from a UI element, i.e. a
> button or so and then directly executed inside the function. Instead
> you could run the "fetch the list of files" in a separate thread,
> either by utilizing the ThreadWeaver API or QtConcurrent.

Thanks for the advice. I'll take that into account for the future.

> If possible
> it would be good to have all the code that is executed to fetch files,
> run them through krazy and generate the analysis data inside of a KJob
> subclass and make it cancellable as far as possible so such long runs
> can be aborted if done by mistake. Thats just guesswork on my part, so
> if thats already whats happening just ignore me :)

The code to fetch the files is not in a KJob, although the analysis
and the parsing of the results are ;) And it even has a
KDevelop::IStatus to show the progress! :P



2012/10/30 Allen Winter <winter at kde.org>:
> On Monday 29 October 2012 09:30:52 PM Daniel Calviño Sánchez wrote:
>> Hi all,
>>
>> I would like to inform you about a GPLv2+ licensed Krazy2 plugin for
>> KDevelop that I have been working on.
>>
> Neat stuff.  I look forward to seeing improvements in the future.

Thanks :)

> I cheat.  I have an extension (that can run only 1 file at a time)
> From my kdeveloprc:
> [External Scripts][script 15]
> command=krazy2 --export=textedit %n
> errorMode=0
> inputMode=0
> name=krazy2
> outputMode=0
> saveMode=0
> shortcuts=
> showOutput=true
>
> But it doesn't let me select a line in the results output and have the editor jump to that line in the code.
> Other than that, it's easy enough to use :)

That's a good trick, though :)