GSOC2015 KDevelop ideas

Laszlo Kis-Adam dfighter1985 at gmail.com
Thu Mar 12 15:37:16 UTC 2015


On 3/12/2015 01:29, Aleix Pol wrote:
> On Wed, Mar 11, 2015 at 8:28 PM, Laszlo Kis-Adam <dfighter1985 at gmail.com> wrote:
>> Here's the patch to do that:
>> https://git.reviewboard.kde.org/r/122905/
>>
>> I've also made some blog posts about my experiences:
>> https://dfighter1985.wordpress.com/2015/03/10/upgrading-kdevelops-valgrind-plugin-to-kf5/
>> https://dfighter1985.wordpress.com/2015/03/10/kdevelop-plugins-debug-lessons-learned/
>> https://dfighter1985.wordpress.com/2015/03/11/kdev-valgrind-at-work/
>>
>> I have some further ideas for the plugin btw:
>> * Memcheck output should show both the line that deleted the block, and the
>> line of the invalid read/write.
>> * Helgrind could also be integrated, as that's a quite useful tool as well.
>> * Callgrind output could show the number of calls.
>>
>> On 3/7/2015 16:56, Kevin Funk wrote:
>>> Regarding starting points: I'm already having something in mind that you
>>> could work on: kdev-valgrind isn't even ported to KF5 yet, and it'd be a
>>> great starter task to get that ready for KF5-based KDevelop. You could check
>>> the git logs of kdev-cppcheck to learn how to do that.
>>> ps://mail.kde.org/mailman/listinfo/kdevelop-devel
>>
>> _______________________________________________
>> KDevelop-devel mailing list
>> KDevelop-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kdevelop-devel
> Good work, Laszlo.
>
> You are definitely on the right track.
>
> With regard to what you are proposing, I think these points you
> propose are interesting indeed and I'd like to see them developed.
> Furthermore, it will be interesting if you can explain what's your
> vision on how the user will be triggering and interacting with these
> tools.
>
> Cheers!
> Aleix
>
In the short term, helgrind could just be added like the rest of the 
valgrind tools, and used the same way:
Set helgrind in the settings, start the valgrind run, see the result in 
the valgrind toolview.
On medium to long term: The checker framework would receive the messages 
from the valgrind plugin, and show it in the problems view.
Only helgrind would be actually new in the plugin, the other two ideas 
are just improvement of the current tool.



More information about the KDevelop-devel mailing list