GSOC2015 KDevelop ideas

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


On 3/12/2015 09:11, Kevin Funk wrote:
> On Thursday 12 March 2015 01:29:06 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-less 
>>>
>>> ons-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
> Yep. It's also cool to see you blogging about your work right away!
>
> Public exposure is good, and helps getting other people started on 
> jobs like
> this. Even if it's just to show potential users that kdev-valgrind or 
> one of
> the other tools exist, and to remind them they are usable.
>
> Like Aleix, I'd like to see some kind of road map of your plans, once 
> you've
> got a full overview over the tools and their issues, etc.
>
> Thanks
>
>
>> _______________________________________________
>> KDevelop-devel mailing list
>> KDevelop-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kdevelop-devel
I thought blogging would be good way to document for self and others. 
Also it's good advertisement for the project: The more references 
kdevelop has the greater it's exposure is in the search results of 
search engines.
I still need to study the code, but we will make up a roadmap together 
for the checker framework. The ideas I had are not related to my future 
GSOC proposal, I'd like to do them before or after GSOC. I will see how 
I can manage time.


More information about the KDevelop-devel mailing list