Planet Kate
Akademy 08: Kate Flashback
- fix: drag & drop of text
- code completion: only show group header if the group name is not empty
- reintroduction of buffer blocks in Kate's document buffer (one buffer contains up to 4096 lines). The blocks build a linked list. Editing a 500 MB file kind of works now again. It's still rather slow, though.
- more speedup in Kate's document buffer
- Kate is using KEncodingProber instead of KEncodingDetector now
- generate internal version of KatePart automatically, so developers don't have to adapt it manually each release
- python encoding detection plugin that warns if encoding is not correct while saving
- new plugin: Backtrace browser, mainly for developers
- find in files: several speed optimizations
- find in files: progress indicator while search is active
- find in files: redesign of workflow. Search happens with non-modal dialog and results are shown in toolviews.
- lots of vi mode changes
- lots of bugs closed, mainly old ones
- some real bug fixes...
- things I forgot
Kate: Fast backtrace navigation
Sometimes there are several files with the same name, e.g.
- trunk/kdegraphics/okular/generators/dvi/config.h
- trunk/kdepim/mimelib/mimelib/config.h
- dvi/config.h
- mimelib/config.h
How to configure
- Enable the plugin: go to Settings > Configure Kate > Application Plugins and enable 'Kate Backtrace Browser'
- A config page appeared, so click on it and add the directories containing the source code
- Clicking OK will start indexing. It will take some time (the index of kdesupport + kdelibs + kdepimlibs + kdebase + kdesdk + playground/plasma + plasma-addons + kdevplatform + kdegraphics is about 6MB)
Hope it's useful :)
Kate: Fast backtrace navigation
Sometimes there are several files with the same name, e.g.
- trunk/kdegraphics/okular/generators/dvi/config.h
- trunk/kdepim/mimelib/mimelib/config.h
- dvi/config.h
- mimelib/config.h
How to configure
- Enable the plugin: go to Settings > Configure Kate > Application Plugins and enable 'Kate Backtrace Browser'
- A config page appeared, so click on it and add the directories containing the source code
- Clicking OK will start indexing. It will take some time (the index of kdesupport + kdelibs + kdepimlibs + kdebase + kdesdk + playground/plasma + plasma-addons + kdevplatform + kdegraphics is about 6MB)
Hope it's useful :)
Beachvolleyball Grand Slam Klagenfurt - 2008<br />
Congratulations to the winning female team from Brazil and the winning male team from Russia !!!
Congratulations also to the seconds and thirds.
KDevelop 4: User Interface
Another leap forward in KDevelop version 4 is the interface. We've tried to make it both highly flexible (to fit most people's requirements) and reliable (kdev3 suffered from a difficult to maintain ui library, prior to a simplified rewrite), and the current state is pretty good (certainly better than kdev3). Features include:
Features likely to be implemented at some stage include split toolview areas, and drag + drop of tool views.
KDevelop 4: A New Era
I've decided to write a series of blogs detailing the work that has gone on behind the scenes for KDevelop version 4, the new IDE that is now 3 years in the making. Like KDE4, KDevelop has seen much work on essential internal mechanisms (much like the pillars of KDE), the power of which will become evident over the next year or so. Progress has been great recently, with the hackathon we had in Munich earlier this year, productive SoC projects and several more/new developers becoming active again, it's looking like we can expect to be releasing a pretty solid beta within about a month. The other developers and I use kdevelop daily to work on kdevelop 4, including writing code; version control; building, executing, debugging, and valgrinding programs; navigating the project with quick open, find in files (grep), etc.
In today's blog I'll concentrate on language support, arguably the most important feature of an IDE. I've previously blogged about the underpinnings of the new language support, which is arguably the most important cornerstone of the technology developed for this release. It consists of an extensive definition-use chain and type system; this means that KDevelop knows accurately where all of your declarations, definitions, types etc. occur, and when you use each of them. Comprehensive code completion, refactoring and other advanced tools will all flow on from this.
Two things have struck me about the definition-use chain (duchain) work recently. Firsty, our code has matured and is working well. When I was last blogging (too long ago, I know), I wrote about how it was difficult to make it all work with multithreading, and that c++ support was incomplete. Now I have learned much more about threading and locking issues, and the scheme that I finally settled on (one global read/write lock for the entire duchain) has solved the problems. This is important not only so that KDev4 can make use of dual/quad core machines, but also so that background parsing occurs without getting in the way of the user. C++ support has matured over the last year (thanks to David Nolden) to include full macro and template support (which are not easy tasks, the complexity of tracking macros accurately throughout include files caused many headaches).
The second is that we've started generalising what code we can to share between different language supports. It now takes very little effort to implement a duchain for a new language, once you have a parser in place. Java, C#, and PHP have all made encouraging starts (python too, but that effort is currently unmaintained), and I've found that the effort required to develop a duchain for a language is much less because of the shared code. All have relatively complete duchains within each file, and the c# duchain took only a few hours for me to implement. I've put some quality time into developer documentation as well, which can be found on api.kde.org. Once a language has a working duchain, it's ready to share in the features which were created initially for c++, such as code model, context browsing, and code completion [already implemented] and the sure to follow refactoring support. If you want to see your favourite language well supported by kdevelop 4, we'd appreciate your help - other than c++ and php, there are no major active maintainers. I believe C# and Java are especially important secondary languages for kdevelop to support.
DUChain performance and reliability has been the focus of David and I for the last few months, especially given David's SoC project on "Rock Solid C++ Support". Memory usage has been dramatically improved, and many bugs have been tracked down, especially with regards to text editor integration. The next step is saving everything to disk ("persistance"), because although the parsing is pretty efficient, enabling complete on the fly duchain support for a project is like trying to compile the project and all of its dependencies every time it is opened otherwise. Once we have duchain persistance, the navigation features already implemented will become much more useful.
If you want to get started using kdevelop now, checkout and compile kdevplatform and kdevelop modules from svn. Bugzilla is open, and we would especially appreciate* any reports of incorrectly parsed c++ code (you'll notice red highlighting, and the problem reporter will detail any errors (*with the exception of the known bug highlighting the first character of a document)) or crashes.
C++ Template magic
template <class T, int TSize>
class RingBuffer
{
public:
RingBuffer();
// ...
void append(int count, T* first);
private:
std::vector<T> buffer;
int start;
int end;
};
template <class T, int TSize>
RingBuffer<T,TSize>::RingBuffer()
{
buffer.resize(TSize);
start = 0;
end = 0;
}
template <class T, int TSize>
void RingBuffer<T,TSize>::append(int count, T* first)
{
// code omitted: make sure count elements fit, otherwise return
// now there are two cases: either count elements fit completely,
// or we have to wrap around at the end of the ring buffer.
// the case of a wrap around is ignored here, too
copyHelper(&buffer[start], first, count);
}Now the function copyHelper looks like this:
template <class T, int TSize>
static inline void copyHelper(T* dest, T* src, int count)
{
while (count--) {
*dest++ = *src++;
}
}copyHelper simply assigns count elements with the operator=(), as T can also be a class. But in the case of T being e.g. a simple char this code part performs really bad. However, there is a solution: Template specialization. That means, we add another function copyHelper() and the compiler then is clever enough to pick the correct one:
template <>
static inline void copyHelper<char>(char* dest, char* src, int count)
{
memcpy(dest, src, count);
}Now the code is really fast in the case of char. In other words, with template specialization we can heavily tune template code in a lot of cases. And ideally, STL implementations do exactly this, don't they? Does Qt use template specialization for its template classes?
C++ Template magic
template <class T, int TSize>
class RingBuffer
{
public:
RingBuffer();
// ...
void append(int count, T* first);
private:
std::vector<T> buffer;
int start;
int end;
};
template <class T, int TSize>
RingBuffer<T,TSize>::RingBuffer()
{
buffer.resize(TSize);
start = 0;
end = 0;
}
template <class T, int TSize>
void RingBuffer<T,TSize>::append(int count, T* first)
{
// code omitted: make sure count elements fit, otherwise return
// now there are two cases: either count elements fit completely,
// or we have to wrap around at the end of the ring buffer.
// the case of a wrap around is ignored here, too
copyHelper(&buffer[start], first, count);
}Now the function copyHelper looks like this:
template <class T, int TSize>
static inline void copyHelper(T* dest, T* src, int count)
{
while (count--) {
*dest++ = *src++;
}
}copyHelper simply assigns count elements with the operator=(), as T can also be a class. But in the case of T being e.g. a simple char this code part performs really bad. However, there is a solution: Template specialization. That means, we add another function copyHelper() and the compiler then is clever enough to pick the correct one:
template <>
static inline void copyHelper<char>(char* dest, char* src, int count)
{
memcpy(dest, src, count);
}Now the code is really fast in the case of char. In other words, with template specialization we can heavily tune template code in a lot of cases. And ideally, STL implementations do exactly this, don't they? Does Qt use template specialization for its template classes?
"I miss the applet which shows system usage"
Besides that, I'm not yet content with how the data engine publishs data. The situation is that all system monitor data is extracted in one tick, but I still would like to publish it in three categories: cpu, mem and swap. But if I do so, an applet's dataUpdated() function is called 3 times and that's not what I want. So for now I put the data into the category systemmonitor and named the items cpu-total, cpu-kernel, ..., swap-total, swap-used, mem-total, mem-kernel, mem-cached, ... However the other way of categorization would be better :) Any ideas?
"I miss the applet which shows system usage"
Besides that, I'm not yet content with how the data engine publishs data. The situation is that all system monitor data is extracted in one tick, but I still would like to publish it in three categories: cpu, mem and swap. But if I do so, an applet's dataUpdated() function is called 3 times and that's not what I want. So for now I put the data into the category systemmonitor and named the items cpu-total, cpu-kernel, ..., swap-total, swap-used, mem-total, mem-kernel, mem-cached, ... However the other way of categorization would be better :) Any ideas?
"I miss the applet which shows system usage"
Besides that, I'm not yet content with how the data engine publishs data. The situation is that all system monitor data is extracted in one tick, but I still would like to publish it in three categories: cpu, mem and swap. But if I do so, an applet's dataUpdated() function is called 3 times and that's not what I want. So for now I put the data into the category systemmonitor and named the items cpu-total, cpu-kernel, ..., swap-total, swap-used, mem-total, mem-kernel, mem-cached, ... However the other way of categorization would be better :) Any ideas?
