A short update on the progress of my student Piyush Verma, who’s hard working on the python parser. We finally managed to fix all bugs in the parser we could encounter. That is we both ran the parser on real world projects we had lying around and it didn’t fail parsing any of the files. That means pretty much all of the Python 2.4 language can be parsed (I guess somebody can find corner cases if he wants to). Additional support for Python 2.5 (I don’t think Python 2.3 is worth the effort) will be added after SoC (hopefully ;).
Also during the last week we started to use acunote.com for managing the work in SoC and it has proved itself helpful to communicate tasks (in this case mostly the bugs) and patches this way. More about acunote.com can be found in my recent KDevelop blog. The parser also is now usable as a shared library making it possible to write unit tests for it with the Qt Test framework and use it later on in the KDevelop4 language support.
The upcoming tasks for Piyush include creating a suitable AST by annotating the kdevelop-pg grammar and then starting to look into duchain and integration with KDevelop4. So the progress he’s making is quite good, although the harder parts are comming now. I’m pretty confident that he’ll succeed bringing Python support into KDevelop4
The last two weeks I’ve done quite a bit of KDE4 stuff, partly due to the fact that the first week of june was a week without “real life work”. The reason being that I couldn’t get to my workplace easily. I’m living about 40 km from Rostock and about the same distance from Heiligendamm where the G-8 conference was held from Jun 6th till June 8th. During that time the streets to Rostock (where my workplace is) where blocked by demonstrators. So I’ve had quite some time to hack
The first thing that happened was filling the new KDE4 module named kdevplatform, the code for that comes from KDevelop’s lib subdirectory and a few of its plugins. The KDevelop Platform is a building base for IDE-like applications much like Eclipse SDK is. It provides various parts for an application, among them integration with an editor (using the KTextEditor interface), language support interfaces, project management facilities and a user interface library. This is completed by a very extensible plugin and extension interfaces architecture which allows plugins to break binary compatibility without breaking the application.
Also the OutputView interface in KDevPlatform got an overhaul, its now truly a MVC architecture. Any plugin can register itself with the outputview and give it a model to be displayed. The plugin can then feed its output into the model and it will be displayed in a separate tab in the outputview. There are still a few issues to be resolved wrt. fact that in KDevPlatform applications you can have multiple instances of a toolview and for the outputview this means having multiple views for the same data. This introduces a few problems when it comes to navigating the output. This is something that is unified for KDevPlatform, there will be 2 to 4 shortcuts that will work on a selected outputview’s current tab and move forward/backward through the output. Everytime the shortcut is activated a special action can be taken, for example in the make output the file with an error/warning is opened at that position. This will be fixed during this week, hopefully.
On the weekend Alexander Dymo presented a nice way to keep track of the SoC projects: acunote.com. Everybody doing a SoC or mentoring it can create an acunote account and project and track the progress there. Its a really nice application developed by Pluron the firm that Alexander works for. It allows to review commits and patches easily, to define tasks that should be done within specified amount of time and it predicts wether these tasks are likely to be done within that time.
The last week was not that productive, as I had to catch up with work again. However I managed to implement the various version control helper classes in the KDevPlatform vcs library. This library provides interfaces and a few helper classes currently to implement version control plugins. The interfaces define a basic set of actions that the plugin needs to fulfill and a set of optional actions (for example remote move/copy, cat, ls). The helper classes are mostly straight-forward, except the VcsRevision class. This one needed to be subclassable and it also needs to allow to pass it by value around using QVariant. The approach I took was to implement a private dictionary with proteced members which would store the information that the subclass wants to add. This way its possible to easily create a SubversionRevision out of a VcsRevision because the data that is needed on top of the standard things is still in the class. This part of KDevPlatform would greatly benefit from an implementation in Python (or probably Ruby or Perl as well), because those don’t have static type-checking.
Also in the last week Oswald Buddenhagen introduced a new class to kdelibs, KProcess. This is mainly a convenience wrapper around QProcess and obsoletes K3Process and its subclasses. Unfortunately, with this change Ossi also broke the win32 port, because he disabled K3Process for win32. So Christian and myself had to sit down and start porting kdelibs, kdepimlibs and kdebase to KProcess. It turned out that QProcess is not always as easy to use as the rest of Qt, but with the help of Ossi we figured everything out. Some changes couldn’t be comitted until today because they broke BC, due to the fact they changed installed headers (yes some classes in kdelibs could benefit from a API review). There are still a few things left in kdelibs and kdebase that need porting sooner or later, because K3Process and KProcess don’t mix well within one application. I’ve prepared a wiki page to coordinate porting efforts for the whole of trunk/KDE (I just realize this doesn’t include koffice, yet): http://wiki.kde.org/tiki-index.php?page=K3ProcessPorting
Last but not least I fixed an annoying shortcoming of the cmake macro kde4_add_test. It only created a target to build the application, but it didn’t add the target to the test-target. So one always needed the add_test macro additionally to have the test run by make test. To fix this the kde4_add_test macro was renamed kde4_add_test_executable and a new macro kde4_add_unit_test was introduced. The first one will just create a target that is only added to the “all” target when KDE4_BUILD_TESTS is defined at cmake time, the latter will also add the test to the “test” target just like add_test() does. More information for both macros can be found in the FindKDE4Internal.cmake file installed by kdelibs. Of course this also needed a port of all trunk modules to the new macros and along the way I fixed a lot of old stuff that still used if(KDE4_BUILD_TESTS) and set the EXECUTABLE_OUTPUT_PATH manually.
So the last two weeks where rather productive, the next things on my todo: include-directory-support for the QMake Manager, fix project file reading/writing and the settings dialog, look into KNewStuff2 for application templates (for starters), think about debug/run API. And hopefully some new screenshots (maybe with the oxygen stuff, although that still has quite some bugs for me)