The last few days, we had a joint kate and KDevelop sprint in Berlin. I finally found the time to fix up the Python language support plugin for KDevelop, which was in a quite bad shape in the last few months. Most importantly, the 1.7-py3 branch now supports Python 3.4.3, and the master branch supports KF5 (this mostly thanks to Laurent, who did most of the porting) and Python 3.5, […]
One of the things I’ve heard on every KDevelop sprint is: we should be light, like Kate but with our added value. We’ve addressed this in many ways so far: we’ve optimized the code for performance so it’s more responsive and starts reasonably fast, we’ve made sure most done is accessible using the keyboard so […]
it’s my pleasure to announce the immediate availability of KDevelop 4.7.1. This release contains many improvements and bug fixes - everyone is urged to upgrade. Distributions should already provide updated packages, otherwise you can download via:
Thanks to all contributors, users and bug reporters for making this release possible!
It’s my pleasure to finally announce the availability of KDevelop 4.7.0:
This is a special release, as it marks the end of the KDE 4 era for us in terms of feature development. We will continue to support this release in the long-term with bug fixes though. New things and fundamental changes will only happen in the frameworkified master branches from now an.
Many thanks to all contributors!
This might be old news for the more experienced programmers out there, but yes, we can script GDB to do $stuff whenever it hits a breakpoint. With GDB's logging to file feature this can be super handy when trying to get a backlog of backtraces whenever a certain event arises.
Kevin just announced it on the mailing list, the CI is still shaking it’s head, and we are all very curious about the coming weeks: KDevelop’s master branches are now depending on KF5!
For more information, see: https://www.kdevelop.org/frameworks/kdevelop-master-now-depends-kde-fram…
Cheers, happy hacking and hope to see some more patches :)
I'm already back home and now like to you let you know what I've been doing the last week during the Randa Sprint in the Swiss Alps.
Quick summay: It has been an immense event!View from our hacking room, in Randa, Switzerland
Last week I've been mostly
While we had basic support for code completion provided by Clang from the beginning (thanks to David Stevens for
just a quick announcement: KDevelop 4.7.0 Beta 1 was released! Head over to the announcement on the KDevelop website to read more:
Cheers, see you soon with a KDevelop 4.7.0 stable release :)
In the first two weeks of my GSoC I've spent time on moving out lots of code from the current C++ language support into kdevplatform (the base of KDevelop, which contains all the non-language agnostic, reusable components for the IDE).Task recap: Assistants / Refactoring
Rename assistant: When you change
I'm happy to announce that I've been accepted as student for this year's Google Summer of Code! This summer, I'll have the chance to improve the Clang integration in KDevelop, something we (the KDevelop developers) have been working on for some months already.Project Introduction KDE's Konqi and Clang's
Since the beginning of my involvement in KDE and, more specifically, my involvement with KDevelop, many people have come to me and said that what we “actually need” is an SDK. So far, I never gave this much thought. Especially given that for me, the SDK was the system I’m running on and, by extension, […]
Yesterday, Python 3.4 was finally released, so I’m now happy to announce the first stable release of kdevelop-python which supports Python 3! See below for the tarballs. As in the Python 2 series, PyQt continues to be one of the best supported frameworks. Obsolete, please use 1.6.1-py3 (see below) — 1.6.0 didn’t build on some systems kdev-python version 1.6.0-py3 http://download.kde.org/stable/kdevelop/kdev-python/1.6.0/src/kdev-python-v1.6.0-py3.tar.xz.mirrorlist SHA256:974178fa00a34c5e2a4d9f6408c7fcbf92e7933182dd59216a11c1452238ceb7 kdev-python version 1.6.1-py3 http://download.kde.org/stable/kdevelop/kdev-python/1.6.1/src/kdev-python-v1.6.1-py3.tar.xz.mirrorlist SHA256: 26b1fa25e8f24f1e0b801ece02b283a750e77543e6df1e571dd52b36778859a5 The kdev-python 1.6-py3 […]
Good news: Python 3.4 is about to be released, and with it kdevelop-python’s first version to support Python 3. Until that happens in a few days, here’s a beta: kdev-python version 1.5.80-py3 http://download.kde.org/unstable/kdevelop/kdev-python/1.5.80/src/kdev-python-1.5.80-py3.tar.xz.mirrorlist SHA256:99ca1ce97e2a7e553051be7505c17a921ab1aaf318999826ea285f771bcc538a The kdev-python 1.6-py3 series is compatible with KDevelop 4.6 (kdevplatform 1.6) and is suitable for working with Python 3.x source code. If you’re only interested in using (as opposed to packaging or developing) kdev-python, you should […]
Time flies… The extremely productive hack sprint at the friendly Blue Systems office in Barcelona is over for more than a week. I haven’t had time to blog about the last days yet which I hereby make good for!
I spent a lot of time at the sprint polishing the KDevelop Clang plugin. A up-to-now semi-secretly developed language plugin based on clang which will replace our current C++ language support in KDevelop in the long-run.
Code completion of std::string in a std::vector.
Showing a clang-generated warning inside the editor.
KDevelop’s current C++ plugin
Nested clang diagnostics with browsing support.
But a bit of history first: KDevelop’s current C++ language plugin can pull off what it does by essentially implementing (parts of) the C++ standard. We have our own C++ parser, we have our own implementation of the C++ template mechanism, we have our own share of “compiler bugs”, …. It should not surprise anyone that this is a maintenance nightmare. And indeed, with C++11 and the wealth of changes it came with our language simply fails in many areas. The current codebase is big (~55k sloc) and adding support for complicated features such as variadic templates or constexpr is extremely hard and fragile. So instead of doing that, my colleague Olivier JG started looking into using clang of LLVM fame instead. It promises an API for third-party tools to steer a C/C++/Objective-C compiler to their needs. Its the magic bullet which we waited for, and which did not exist back when KDevelop 4.0 was started initially.clang
So Olivier started hacking on kdev-clang. In his initial prototyping he experimented with the C++ API to clang but eventually found that the clang-c API suffices for our needs. The big advantage is that the latter comes with an API/ABI guarantee which is important for us as a consumer. After some failed attempts in getting clang to parse medium-sized projects at reasonable speeds, he eventually found the magic flags and options. So after the hard work was done, I started contributing by playing the plumber who massages the output of clang-c into the existing KDevelop framework.status quo
Currently, the kdev-clang plugin consists of ca. 2000 lines of code. Add a bit more than 600 lines of tests and you are still a magnitude below our current C++ plugin. Sure, if you count the lines of code in clang/LLVM this won’t stand anymore, but from a maintenance point of view this is a blessing. We can actually concentrate on making our IDE shine instead of playing catchup with the compiler.
The plugin already supports:
What’s currently missing:
I always feared that using clang instead of our hand-written parser would lead to abysmal performance. I’ve heard bad stories about XCode 4.0 which was the first IDE to use clang internally. And the Qt-Creator guys also said they don’t want to use clang for their code model as its performance was not good enough. Thankfully, all of this turned out to be false alarm: On one hand Apple invested a lot into clang and made it much faster, also for the usage in XCode apparently. Secondly, Qt-Creator’s blazingly fast status-quo comes at the cost of only supporting a (relatively small) subset of C++. So yes, clang is slower at parsing a big project than doing the same in QtCreator. But more importantly: clang is faster than the old KDevelop C++ support! The reason is that it scales far batter with multiple cores than our old language plugin. So yes, it uses more instructions to analyse a code sample. At the same time it gives us much more than we had in terms of language support and diagnostics. But since it can do so in parallel, it finishes parsing quicker!
A bit of technical background: In our parsesession.cpp we invoke clang_parseTranslationUnit(). We configure it to use a CXTranslationUnit_PrecompiledPreamble and cache the resulting translation unit for future clang_reparseTranslationUnit() when the document is currently open. Combined, this allows for extremely fast updates when the user types something in his editor. In addition, we can use our internal cache to minimize the amount of times we must invoke clang. And I plan to investigate how to generate precompiled headers, which one could then do for third-party libraries such as the STL, Qt or the KDE frameworks. This would speed up clang even more, both inside KDevelop and while parsing! Even better, eventually we’ll get C++ modules and all of this will become extremely fast and easy to handle!TAKE MY CODE
So the above is like a fairy tale come true from my pov! If you are thinking “shut up and tell me how to use this awesome stuff” despite of the shortcomings I listed above, then the following is just what you want.
But, first a big warning: The old C++ plugin and kdev-clang don’t like each other, in the sense of leading to runtime asserts when both are loaded into the same KDevelop session. See below for how to circumvent this.
AGAIN: Don’t run KDevelop with both, kdev-clang and kdevcppsupport!
Otherwise: Happy hacking and make sure to keep an eye on kdev-clang! I’m sure its going to progress nicely and I’m eagerly awaiting the day where I can close all C++-related bug reports and delete over 55 thousand lines of code :)Thanks
Many thanks to Olivier for spearheading this plugin! And thanks already to the first contributors and early-adapters. Finally, once more many thanks to Aleix for organizing this awesome KDevelop/Kate sprint in Barcelona. Looking forward to the next time! Thanks also to his employer Blue Systems for providing the hack space. And as usual my gratitude to the KDE e.V. for sponsoring this event and to all the donors.
If you like Kate and/or KDevelop, please consider Joining the Game to ensure sprits such as this one can continue to take place in the future!
Last week I have been in Barcelona at the KDevelop / Kate sprint with all the other nice people working on those projects. As always, it was very cool to meet everyone again and spend a week together improving software. A big thanks to the organizers and sponsors, too! Since most of the time I work on a fairly encapuslated subsystem (Python support for KDevelop) and only a smaller part […]
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!
Copyright 2016· All rights reserved