sprint Syndicate content

warning: Creating default object from empty value in /www/htdocs/w0065fc9/milianw/modules/taxonomy/taxonomy.pages.inc on line 33.

» KDevelop 5.0.0 Beta 1 available!

Tue, 10/27/2015 - 16:42

Hello all,


displaying size meta data of classes and members in KDevelop thanks to Clang

I’m very glad to finally announce the first beta of KDevelop 5.0.0, based on Qt 5, KF 5 and Clang: https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available

Like I’ve said previously, I’m very thankful of the tons of contributors that made this step possible. From the early testers, over the many new KDevelop contributors who helped a lot in porting our code base to Qt 5 and KF5, to the people that worked on improving kdev-clang and all the other areas. It’s a great feeling to finally release this beast. A year ago, just after we started in this process, I still wasn’t too sure we can pull it all off. Now, look where we are :) “Just” a few more weeks of polishing and I’m positively sure KDevelop 5.0.0 will be a really good milestone.

That said, I also want to express my thanks towards the KDE e.V. which graciously sponsored our recent KDevelop/Kate sprint in Berlin. We rented a flat for the 8 hackers that visited Berlin and had a productive five days directly after the Qt World Summit. Personally, I worked on kdev-clang and polished it a bit more in the preparation of the first beta release. One handy feature I added is the display of size information about classes and member variables, displayed in the image to the right.

If you want to give back to the KDevelop community, please consider a donation to the KDE e.v., which is used for our yearly developer sprints and the Akademy conference.

» Kate/KDevelop Sprint 2014: First Days

Tue, 01/21/2014 - 19:24

Hey all! Greetings from the joint Kate/KDevelop sprint at the Blue Systems office in Barcelona!

I only arrived yesterday but already I have great news for you: After months of work I finally merged the sharedurls branches into master for KDevelop/KDevplatform etc. pp. There I worked on a optimization in our handling of file paths.

The status quo up until know was the following: When importing a folder as a project in KDevelop, we filled a model with every file and folder in the project (recursively). For every item we also stored its path as a KUrl to the potentially remote location. KUrl and QUrl are awesome when you have to work with paths and urls, but as soon as you store potentially thousands of them at the same time it becomes quite inefficient. Assume e.g. you open /foo/bar/blub/ which contains /foo/bar/blub/bla.h. When you use KUrl/QUrl to store these paths, you cannot share any memory between the two, as internally basically a QString is used. Thus, when you import deep folder trees or folders with many files, you’ll waste a lot of memory for common sub-paths. Furthermore, due to the amount of allocations required, reading the tree is pretty slow.

So in the sharedurls branch I worked on a internal replacement for KUrl in KDevelop: It’s called KDevelop::Path and is a glorified QVector<QString> with convenience API to simulate a KUrl and simplify porting. Every entry in the vector contains a path segment. It leverages QStrings implicit sharing to minimize the memory overhead. Furthermore, when you parse a tree structure recursively, all you do is copying vectors and appending strings to them - which is rather cheap as a QString is a small handle structure.

So all in all this should greatly improve the performance of opening projects in KDevelop. Especially for large sessions containing thousands of files (eg.: Qt 4, multiple Qt 5 modules, LibreOffice, Kernel, WebKit, …) the new code is much faster and consumes less memory. I’ve seen time savings in the order of multiple seconds in total as well as memory consumption going down in the order of 100MB.

While this sounds like a fairy-tale, I have to admit that it was/is a lot of work: By using a custom class, you have to convert to KUrl/QUrl or QString quite often when interacting with existing API. This of course is costly and potentially marginalizes or even pessimises the potential performance gains. Hence one needs to pay special attention and port code such that it minimizes these conversions. As such I can only recommend anyone doing something like that when you have similar extreme usecase. For a normal file browser or web browser I doubt the you’ll gain much if anything.

So please compile the current master branches and take a look for yourself. My tests and benchmarks look all good, yet I might have overlooked something. If you spot any regressions, please shout!

Now that this is mostly done and polished, I’ll continue working on Clang integration in KDevelop. Stay tuned for the next blog entry about that topic :) And already a huge thank you to Aleix Pol for organizing this sprint, to Blue Systems for having us, and to the KDE e.V. for sponsoring the trip and accommodation!

» Random new stuff from the KDevelop sprint

Sun, 10/28/2012 - 15:18

Before I continue blogging about actual coding achievements, I must mention something else: Many many thanks to Niko’s company Vivid Planet for sponsoring one awesome dinner here at the KDevelop/Kate sprint in Vieanna. The Schnitzel and beer was much appreciated :)

So besides the promising work towards a JavaScript/QML plugin for KDevelop, what have I been up to in the past days?

Merging Code
Static Code Analysis

I spent a considerable amount of time to review some feature branches and working towards integrating them. This means that now Aleix’s master thesis work was merged. This one is about a static analysis framework, which he has implemented for C++. This should allow his other work to be merged as well eventually, showing control flow graphs or writing checkers like finding inquired include statements. I hope he’ll blog about that eventually.

File & Project Templates

Furthermore, I’ve finally merged Miha’s GSOC Code which gives us a much better project template support. Furthermore, you can now create (and share!) file templates. A few good examples are the existing QTestLib template e.g. I’m pretty sure that what we have right now is quite cool already. It needs to be polished though to make it nicer to use. Suggestions and bug reports welcome!


Rename file after renaming a class
Unit testing

Another feature that Miha worked on was unit test integration for KDevelop. The branches for that are now also merged into master, awaiting testing and feedback. Aleix and Niko also worked on improving it already, so I hope they will all blog about it.

Rename File Assistant

Aleix had a pending review request which renames the host file when you used ‘Rename Declaration’ on a class. I’ve included that and fixed the implementation. Furthermore, I’ve integrated it into the existing rename assistant, fixing a few bugs there while at it. This is a quite nice addition I think! Please test it and report bugs or suggestions.

Other Stuff

Besides merging other people’s work and improving it, I actually spend some time on new stuff on my own :)

Uses in Tool View

Have you ever tried the “show uses” action from the context browser tooltip? It worked but you had to be really careful in not moving the mouse anywhere such that the tooltip was closed… That just sucked. I now fixed this to always use the tool view instead to show the uses. Looking at that code part though made me realize that some serious cleanup work should be done there eventually… And the UI also could use a serious make over, it looks pretty ugly imo. But while at it, I’ve also fixed the bug where the uses in the uses widget where marked with a yellow background without overwriting the foreground color. This yielded unreadable results (white text on bright yellow) for dark color scheme users.


Cleaned Up Open With
Open With

Triggered by a review request I decided to cleanup our Open With plugin. Now, the actions are properly grouped and show whether they open an external app or whether they have an embedded editor. I also took the liberty to rename “Advanced Embedded Text Editor” (i.e. Katepart) to “Default Editor”. Oh and see how it’s bold-fonted? Thats the currently configured option by the user. For .ui files e.g. the designer is usually selected. I think the new UI is so simple that we don’t need any extra configuration dialog for that.

Now… back to hacking and enjoying the last day in Vienna :)

» QML/JavaScript language plugin for KDevelop

Sun, 10/28/2012 - 13:40

Wow… the last days are a blur. I hoped to blog more but once more failed at doing so. What an awesome sprint this is… Once again, many thanks to Joseph for organizing this! But lets now blog about really noteworthy stuff!

Inline Syntax Errors for QML in KDevelop
Inline Syntax Errors for QML in KDevelop
QML/JS language support

Aleix was doing quite some QML work-work recently. Sadly KDevelop has no language support for that, so to stay productive you start to use Qt Creator for the QML files sooner or later. This is of course perfectly fine, except for those people that love to use Kate e.g. or for those that prefer our interpretation of the IDE metaphor and C++ language support. So what should we do about that? Right, lets write a QML/JS Plugin.

Cannot Parse

But writing a KDevelop language plugin is not an easy task. To get something useful, probably the most essential ingredient is a proper language parser. And of course that is nothing you do over night. Furthermore, you should always try to not write that stuff on your own, instead leverage the work done by others. This is what Aleix did. We now use an internal copy (not a fork, see below) of the QML/JS parser from Qt Creator. I’ve wrapped that in the basic KDevelop language plugin code. Without much work we are now already able to show syntax errors inside the editor for JavaScript and QML files!

Inline Syntax Errors for JavaScript in KDevelop
Inline Syntax Errors for JavaScript in KDevelop
The Future

Of course it is still a long long way until we even get close to the feature set offered by Qt Creator for QML files. I’m quite sure though that we will continue to work on that. Considering more and more people relying on QML/JS for their UI work, or looking at the role of JS in the web, I think this is an essential step towards a better KDevelop.

So what are the next steps? Personally, I think we should try to whip up a basic DUChain integration that gives you some context browsing. Once that is done, try to support imports such that we can figure out the QML API for Qt built in files. Then, we can think about kick-ass code completion. It’s going to take time but we can do it!

Legalese

Now I said this is not a fork, and I mean it. We copied the code since there is no reusable library (and that just makes sense, you don’t want to keep a stable API for a language AST). I’ve added a README to the copy though, that reads the following:

This code here is copied from Qt Creator:

http://qt.gitorious.org/qt-creator/qt-creator

This contents of this folder can be found in src/libs/. For license information see LICENSE.LGPL and LGPLG_EXCEPTION.TXT.

NOTE: This is not a fork! Do not touch anything beside the CMake build files. Everything else must stay in sync. If you find a bug or have an improvement, make sure to contribute it back to Qt Creator! This plugin would not be possible without their work, so that is the least we can do.

I mean what I wrote there. Many many thanks to the work done by the diligent Trolls and Nokia for creating a reusable parser for QML/JS. I’ve talked with a few Qt Creator developers over the years, and they are a nice bunch of talented developers. I tip my virtual hat and bow to their achievements.

And last but not least: Thanks Aleix for doing the dirty lib import and CMake build system so I could concentrate on the KDevelop language plugin integration :) Without you I wouldn’t have done that! And once more many thanks to the KDE e.V. and Joseph for making the sprint possible!

Cheers

» Kate/KDevelop Sprint Vienna 2012 Take 1

Thu, 10/25/2012 - 13:37

Hello everyone!

Finally I take some time to blog again. I’m currently in Vienna for the joint KDevelop/Kate sprint together with lots of other hackers. Many thanks to Joseph for planning and partially financing this sprint! And of course as usual many thanks to the KDE e.V. and all the donors for bringing in the rest of the money required to pull something like this off!

Anyhow, considering that the sprint is running since Tuesday, I need to catch up quite a bit… Actually, I have to start even before that since I committed something quite noteworthy in KDevelop and KMail last week.

Reducing Memory Consumption
KMail
Shared Data References

I attended the recent Akonadi sprint that took place at the KDAB office in Berlin (where I work btw.). I heard that Alex Fiestas would come and show us his memory problems in KMail, which sooner or later was eating multiple GBs of memory for him. That sounded like a fun task to improve, fixing performance issues is what I love to do :) So I investigated it with Valgrind/Massif and my pmap script. After quite some time I came up with a patch to fix the memory increase, which is waiting for Stephen Kelly to review. It should be merged into master very soon™.

Now some technical background: What was the issue here? Why wasn’t it found earlier? Usually developers run e.g. KMail through Valgrind with the leak checker and fix all issues. The same was done lots of times in KMail, there where no problems reported. Why then is the memory still increasing over time? The issue is, that this is technically not a “leak”, i.e. when you close the application all memory is properly released. Instead, there was a logical error that resulted in KMail’s ETM (basically the item model for mails and stuff) push shared data items into a QHash without ever deleting them. If you close the app though, the QHash is cleared automatically and all shared data is properly freed, hence Valgrind won’t report any leaks.

How does one find such an issue then, though? Actually, this is really hard… I ran KMail through Valgrind and looked at the top allocation, which relates to the shared data item. But Massif will only show you where the data is being allocated, not where the shared data items are still referenced and thus prevent a proper deallocation. What now? GDB! Yes, the best way I found was adding a breakpoint in the copy constructor of the shared data class and looking at the surrounding code to see whether it behaves properly… Does anyone have a more efficient way to debug such issues? I could imagine that this can potentially take ages to figure out… In KMail at least I could find the problematic place quite fast.

Implicit Sharing

Now while this apparently fixes the ever increasing memory consumption of KMail somewhat, I thought we could do some more improvements. Take a look at https://git.reviewboard.kde.org/r/106836/ e.g. This patch is similar to what I also did for Massif Visualizer once. By creating a central cache we can leverage Qt’s implicit sharing for common strings (in this case email e.g. adresses, domains, …). This way, if you load a folder containing e.g. a mailing list, you will have the main email address (like list@domain.org) only once in memory. Before, that address would be loaded into memory once for every email in the folder…

Now the above was an interesting detour into a project that I don’t usually contribute to. Since I use KMail all the time though, it is just fair to give back and help out the few KDEPIM people a bit.

KDevelop

Back to my favorite pet project: KDevelop :) In the spirit of the memory fixes above, I took another look at the memory consumption of KDevelop. Turns out, we had a similar issue where we did not reuse implicit sharing properly. This resulted in quite some useless allocations blowing up the memory consumption (in this case, KUrl’s of every file in the projects loaded for a session). The fix is already in master. Not only should that decrease the memory consumption considerably for kdevelop sessions with many files in it. No, it actually should save quite a few instructions and thus be much faster as well. Enjoy!

So… quite a long blog post again - sorry for that :) Expect some more KDevelop news the next days - we have lots of interesting stuff happening here at the sprint! Cheers and many thanks to Joseph and the KDE e.V. again!