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.
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.
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
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.
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 :)
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!
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
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.
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
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™.