Sat, 07/20/2013 - 01:23
I’ve been gone for eight days and returned just a few hours ago to Berlin. It doesn’t feel like that. The last days went by in a blur of awesomeness! The reason why I didn’t write a single blog post in between is just that I never had a spare minute for that. I arrived on Thursday and instantly enjoyed the warmth of Spain / the Basque country and had a tasty and cheap Menu del Dia at a local Restaurant with fellow KDABians and other KDE friends. Then just a few hours later the first party started, near the old district of the city - amazing! More and more hackers and helpers arrived, the atmosphere was once again so good. The social aspect of this years Akademy was without comparison in my opinion - seriously: Hats off to the local team, you did an amazing job!
While the social events on the following days have been just as awesome or even awesomer to awesomest - I especially enjoyed the day trip and jumping into the ocean! - the technical side of Akademy delivered just as well: My favorite talks this year where Mirko’s about ThreadWeaver, which we heavily use in KDevelop. His roadmap and polished API looks much better than what we have nowadays and should allow for much nicer code which might even perform better - kudos!
Similarily, I liked Volker’s talk about Expression Templates and Kevin Krammer’s presentation of Declarative Widgets a lot. Both of them are colleagues of mine, so the contents weren’t that new to me - yet hearing it all in a concise and entertaining manner is always worth it. The crowd also seemed to enjoy it. Martin Grässlin’s talk about being the 1% corner case was also highly entertaining and gave a very interesting insight into the problems he tackles day to day.
There have been other, less technical talks, which I also appreciated greatly: Kevin Otten’s visionary roadmap for KDE as a community or Till’s highly entertaining presentation of BlackBerry. Which brings me to the sponsors - many thanks! Without them, this year’s event would surely not have been as good as it was!
Oh boy, I already wrote a lot, yet only covered the first three days… After the AGM and presentations on the week end followed a full week of highly educational BoF’s - both around KDE topics (such as KF5, KDevelop, …) or “plain” Qt during the Qt Contributor Summit. This was my first time attending the QtCS and I definitely want to see more of this! Discussing the future of QtWebKit and learning more about whats cooking in QtCore was certainly worth it. Being in contact to the QtCreator and QML guys also helps from a tooling point of view in general and from a KDevelop pov in particular. Oh and we got a nice BlackBerry Z10 phone - many thanks for that!
The afternoons are mostly a blur - I mostly remember lots of Foosball, Socializing, Drinking, meeting Friends of Old and New, Eating, Partying etc. pp.
Anyhow, I think I need to stop here.
tl;dr; Thank you local KDE team for organizing such an awesome Akademy + QtCS 2013! Thank you Sponsors for making this possible!
PS: All of you who attended talks on the weekend: Go and rate them! The speakers will love you and provide you with even better talks next year! Go to either the page for the talks on saturday or the talks on sunday, then pick the sessions you attended and finally hit the “Feedback” link!
PPS: I definitely have to come back to the Basque country, the country side looked beautiful and Bilbao alone is worth the trip! And I didn’t even have time to visit the Guggenheim…
Cheers, see you next year you insane awesome crowd of KDE people!
Sat, 01/26/2013 - 17:06
During the sprint in Vienna last year, Aleix and me laid the ground work for a QML/JS language support plugin for KDevelop. Sadly we two only have very limited time working on fancy new features such as that.
Anyone else out there who wants to help? Or maybe someone wants to work on our QML support? We KDevelop hackers would be happy to help!
Thu, 11/29/2012 - 21:10
Cheers, and again many thanks to the KDE sysadmin crew!
Sun, 11/25/2012 - 17:53
I’m investigating the feasibility of allowing a subset of C++11 in the KDevelop code base, starting after the branch of 4.5 in a few weeks. I do not want to blindly start going that route just to realize afterwards that I’ve alienated a large portion of our user base. Thus I’d very much welcome if you could read through this blog post and give some feedback which we can build our decision on top.
Here’s the email I sent to the KDevelop development mailing list:
Is anyone opposed to open KDevelop 4.6 for C++11? I.e. that means we continue to work as-is and provide a kick-ass KDevelop 4.5. Once we branch 4.5, we enable C++11 mode globally and start using it in master.
KDevelop is a free time project and it should be fun to work on it. C++11 is quite a lot of fun, if not only because it’s new. This is actually the main reason for me to go down the C++11 route. This would also allow us to learn C+11 which is a benefit for those of us who do professional work-work programming.
Tons of potential performance benefits thanks to constexpr, noexcept, r- value references etc. pp.
Much easier to read code thanks to auto, lambdas, alias templates, defaulted functions, etc. pp. This also leads to better maintainability.
Improved compiler analysis thanks to e.g. static assert, override, final, nullptr, explicit conversion operators, deleted functions, etc. pp.
Personally I’d say we should just require these compiler versions and above:
clang 3.1 - required for constexpr, lambda, initializer lists, …
GCC 4.7 - 4.6 might even be enough, but 4.7 has some more stuff like delegating constructors, override, final and non-static data member initialization.
msvc ctp november 2012 (http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-…)
FreeBSD situation? http://wiki.freebsd.org/NewC%2B%2BStack <— I’m not sure how far they are. But quite frankly, I’d say they can stick to KDevelop 4.5 until they have a modern compiler like clang 3.1.
Debian? Wheezy should come with GCC 4.7 if I’m not mistaken: http://packages.debian.org/wheezy/gcc Imo it’s fine if we only support that version of Debian. All other distros probably already have GCC 4.7 available, or will have it in their next distro release in time for KDevelop 4.6
Windows? If anything breaks on MSVC it’s imo not an issue as KDevelop is defacto dead on Windows (noone is working on it there). Also considering that the windows team is actually working on proper C++11 support (see link above) its only a matter of time until it has everything we need.
Backporting: Now this is imo a potential issue, but considering that we don’t do such a good job in that regard anyways, it’s not that big a deal… And most of the fixes we do backport are oneliners which could be done in the 4.5 branches and forward ported to 4.6.
So far a few more concerns where raised:
Mac OSX: only “recent” Mac OSX come with a clang that is new enough. Question is: Which version is that exactly? Do people use KDevelop on an older Mac OS? My personal impression was that most Mac users upgrade asap to the newest OS version, thus this should not be an issue?
Windows: While the team around Herb Sutter is doing a tremendous job in advancing the compiler to provide kick-ass standard support, apparently the Windows users are reluctant to upgrade… But the obvious question is: Should we be held back by an imaginary Windows user base? KDevelop does compile on Windows, and mostly works but afaik there are still some very sore spots, esp. in the CMake project management and the lack of a MSVC debugger integration. Anyhow, would allowing C++11 in the KDevelop code base make it considerably harder for potential contributors? Considering that even now we do not get any contributions from Windows users, I doubt it can get any worse… But I do see that it’s a hen/egg problem.
BSD: FreeBSD is in the process of using Clang. But is that process already finished? If not, is there any ETA? Will there be Clang 3.1? What about other BSDs and Unixoids?
What about unsupported platforms?
Personally, I think KDevelop is currently in a pretty good shape. If some platforms would have to stick to KDevelop 4.5, I don’t see such a big issue in that. We could also think about making it our first “LTS” release and backport essential bug fixes for a longer period.
Why not the Qt way?
Qt 5 makes use of C++11 features where possible in a backwards compatible way. It is of course the correct choice for a library that wants to support multiple platforms. But imo, KDevelop does not have such strict requirements. Rather, it should offer maintainable code that is fun to work on. Thus I am stricly against introducing
Q_DECL_CONSTEXPR in our code, instead of using
constexpr directly. And of course, in Qt you cannot use auto, nor lambdas, nor many other things as you always have to provide a C++03 fallback.
Lets try it out, no?
As Aleix pointed out, I’ll probably just start a new branch and introduce some C++11 features there. Then we can see whether the gain in code readability or performance is worth the introduction of the mandatory C++11 requirement.
Thu, 11/08/2012 - 15:15
Hey all, just a quickie: KDevelop 4.4.1 is available!
It comes with mostly crash fixes and a few other bug fixes. I’d say: use it!
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 :)
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
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.
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
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 :)
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
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.
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!
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:
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!
Thu, 10/25/2012 - 13:37
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™.
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.
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
firstname.lastname@example.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.
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!
Tue, 10/23/2012 - 17:32
A first broadcast from the joint KDevelop/Kate sprint! Many thanks already to Joseph for planning this all. As you can see, we also have net access and thus nothing can prevent a very productive week :)
Anyhow, back to the actual news: I finally announced the release of KDevelop 4.4.0. Many thanks to all involved again.
Mind you though, the change list is a bit sparse this time. Yet I’m really looking forward to the 4.5 release already. I’ll blog about it in the next days during the sprint. Stay tuned!
Tue, 08/14/2012 - 18:01
After quite some slacking on my side, I’ve finally managed to drop the good news: KDevelop 4.4.0 Beta 1 is released!
Our 4.4 branch already contains some more interesting changes for the next beta, stay tuned. Oh and yeah, we’ll try to release 4.4.0 final sometime in September, I hope.