Hey everybody!
If you are a KDevelop and/or Kate/Kwrite developer and do not read the mailing lists: There’s a hack sprint coming up in Berlin in 2010. I think there’ve been enough sprints in Berlin already so that you know it’s a great city for such an event. Though this time it won’t be at KDAB or Nokia offices, but at the Physics Faculty of the FU-Berlin. Since I (currently) work there as an IT admin, it was my first choice and worked out. I hope it will be a good location for the meeting. If you want to attend, vote on doodle:
http://www.doodle.com/vkyh9up9794zr4s8
But you probably also should register either on the KDevelop or KWrite mailing lists so I have some kind of way to contact you.
PS: in unrelated news I’ll do an internship at KDAB next year! yay
continue reading...
Good news everyone :)
Documentation
After years of pretty much no documentation (except looking at the sources… ), The_User aka. Jonathan Schmidt-Dominé started documenting the parser generator that is used for most KDevelop language plugins (java, python, php, …). You can find it here: http://techbase.kde.org/Development/KDevelop-PG-Qt_Introduction
It has to be improved and more examples have to be put in there, but it’s already a huge improvement over the situation before…
In related news I did some profiling on the parsing of the quite big file that includes all internal PHP declarations (i.e. all functions, classes, definitions,…). It drops in at a whopping 1.9M, with ~80k lines. Well, turns out that this showed a pretty easy to fix bottleneck in KDevelop-PG’s LocationTable, which used to use a linear lookup algorithm. Profiling showed that nearly 75% was spent in that function. But I used the past tense for a reason:
I replaced it with an algorithm that combines a relative search (i.e. relative to the last lookup) with a binary search fallback. That’s comparatively blazingly fast. I added some benchmarks to KDevelop-PG-Qt that proofs that (benchmark below run with release mode build):
continue reading...
Hi there again! I’ve been silent again on my blog, but didn’t rest on development. In the one and a half months since the last digest, I started writing a PHP application This finally made me eat my own dog food :). It resulted in lots of polishing and quite a few bug fixes for the PHP plugin in KDevelop. Here’s a list of what I think are the notably changes since the last digest:
(Note: to view screenshots, go to the bottom of this article.)
- refactoring of parts of the Code Completion code, should already result in faster code under certain situations
- properly mark constants as “Kind: Constant” in the declaration tooltips
- offer argument hints for ctors during code completion in class init statements
- greatly improve the generate inline documentation of built-in PHP functions, classes, properties etc. pp.
- add documentation of public properties
- support aliased functions (thanks to Victor Grischenko for his patch)
- show more/all documentation, and not only the first paragraph
- fix type-lookup
- don’t get confused when a documentation file documents both, a method and a function (greatly improves e.g. MySQLi documentation)
- don’t offer “jump to declaration” for built-in PHP declarations
- add support for
list(...) statement - cleanup code-completion list, esp. show the return type of functions in the prefix field, and not something a la “function ReturnType ($arg1, $arg2, …)”
- improve the code-completion for include/require statements
- add language constructs to code completion (e.g. class, while, foreach, print, …)
- show declaration tooltip for magic constants, showing their current value
- make functions, methods and classes case-insensitive, just like PHP handles them
- some performance improvements, especially in code completion and parsing of the generated file containing php-internal declarations
- lots of bug fixes, don’t want to iterate them all ;-)
continue reading...
Just a quicky: I wrote a little plugin for KTextEditor which supplies you with basic error checking when you save documents. Currently only PHP (via php -l) and JavaScript (via JavaScript Lint) are supported.
Screenshots
Requirements
- usual tools for compiling C++, e.g. gcc.
- cmake
- Qt development packages, i.e. under Ubuntu:
sudo aptitude install libqt4-dev - KDE 4.2 with development packages for kdelibs and kdebase, i.e. under Ubuntu:
sudo aptitude install kdebase-dev kdebase-workspace-dev kdelibs5-dev. Note: You’ll need the experimental KDE 4.2 packages activated as of now, see for example the Kubuntu news on KDE 4.2 RC1 for hints. - proper setup of environment variables, read this techbase article for more information. the
.bashrc linked there should be enough for most people - For PHP support: a PHP executable which supports the
-l switch for linting - For JavaScript support: a JavaScript Lint executable, you could download and compile the sources for example.
continue reading...
So, after a period of silence I present you an unsorted list of features and bug fixes I did to the PHP plugin for KDevelop in the last few weeks:
added support for path autocompletion after require / include statements: This shares code with the Cpp plugin and it’s completion after #include. I plan to use this autocompletion eventually also for functions accepting filenames or paths. Think of fopen, file_get_contents etc. pp. So far only URLs that are covered by an open project can be completed. We will need support for custom include paths so we can support e.g. global PEAR or framework installations.
worked around a bug where the “schedule all project files for parsing” had no affect. Apaku is currently working on making some internal changes so I can remove the workaround and fix this properly. With this fixed/worked around you should retry the PHP plugin along with frameworks or similar to see how well it works. Just make sure to have the framework inside your project so it gets parsed.
continue reading...
Has been a time since I wrote the last update for PHP / webdevelopment related work in KDevelop4…
XDebug
First of all, Niko (nsams) is working diligently on the general debugger framework for KDevelop4. Of course gdb is still the main focus so far yet he always has his XDebug plugin (which is currently unusable) in mind. So expect some great debugging features once he’s done with the framework.
Remote Projects
Another thing I’ve not yet written about is a bunch of commits I did just after the Hackaton: Remote Projects! Yes, finally you can work directly on the server with KDevelop. I still have to make sure that the user does not try to open a remote cmake project (or similar), because that is of course not supported. Only the Generic Project Manager (basically a list of files in a dir) works. There’s for sure some things to polish, yet I’d like to see user feedback for that use-case at least.
Note : There is still some functionality missing in other areas, like creating a new remote project from a template etc.
continue reading...
Ok, just a quick update on what we are doing / have done the last two days except drinking beer and eating quite a lot of food (though it never seems to be enough somehow….)
- Apol was polishing CMake support, speeding up KDevelop startup time when you enabled the QtHelp plugin, making sure that Kross plugins get loaded properly and some other things
- Adymo started some refactoring of Sublime in an experimental branch (actually they had quite a long discussion right now about things in the UI which should be changed/fixed). Besides that he also fixed some little bugs in the includepath resolver for CMake
- Nsams is fixing PHP support and adding new features here and there. Esp. completion inside a foreach over a Iterator class works now!
- and as always ZWabel did fix quite a lot of bugs, most of them which only were discoverable in a few corner cases, very nice indeed.
- shaforo who sadly already left us again to attend university fixed the sorting in the Project view among other things
- With Apols help I managed to get started with a documentation plugin which (currently) integrates PHP.net. I plan to make it possible to use the downloadable PHP.net documentation as well to speed things up. Actually setting up a documentation plugin is very easy! Maybe I’ll take a look at writing a documentation plugin for Zend, Symfony, etc. pp. as well - should be fairly easy. Maybe I can come up with a generic documentation plugin which makes it possible to include any kind of
.html documentation with some configurable mapping… lets see! Or maybe I should take a look at writing Kross plugins (Apol could help me here as well) for that purpose.
continue reading...
Ok, a short blog about the first day of our KDevelop Hack Sprint at Mykolayiv (see my first blog post). First up, being in the Ukraine is a very interesting experience since it’s totally different from any place I have ever been to. And thanks to the great hospitality of Alexander (adymo) we already had a city tour of Odessa and Mykolayiv.
Tomorrow will be the first real day of our hack sprint: Today we only hacked at our flat for a few hours. Before that we had the city tour through Mykolayiv. And tomorrow David Nolden (zwabel) and Nick Shaforostoff will arrive which will make the list complete.
Today I personally worked on making KDevelop support dark color schemes better which is still a work in progress (nothing comitted so far). Actually for a real good experience I’ll have to extend KTextEditor to make it’s color configuration available for the parent application (i.e. KDevelop). Let’s see when I get to that. Though I plan to push my patches to KDevplatform beforehand for an intermediate solution.
continue reading...
Huzza! The KDevelop Hack Sprint 09 is now official.
Thanks to the huge engagement of Alexander Dymo we will meet from the 19th to 26th April 2009. The meeting will take place at Alexander’s university, the national university of shipbuilding in Odessa Mykolayiv, Ukraine. Thanks to the people there responsible for making this sprint possible by providing us with the premises, internet, power etc.
Since this is my very first Hack Sprint and considering that I only recently started contributing to KDE in general and KDevelop in particular I am very excited. The topics I will plan to hack on include (all related to PHP language support plugin):
- add auto completion after
require(_once) and include(_once), just like it works for #include in CPP - add auto completion of PHP statements (think
echo, exit, require(_once, include(_once) etc. pp.) - add auto completion for build-in PHP keywords
- fix auto completion of interfaces / classes after the keywords
implements and extends (working on that right now) - fix KDevplatform and the Generic Plugin Manager to support remote projects, i.e. via
fish or ftp (or anything else supported by KIO)
continue reading...
In a follow up to my last post about the PHP plugin for KDevelop and Quanta I want to detail how I setup my build environment. Since I’m only working on KDevelop I only want to compile that. For all other applications, I use the packages my distribution makes available. Below you this is possible.
Note: I use Kubuntu and hence some commands like aptitude and the package names etc. will have to be adapted to your specific distribution. But the general idea should be the same and the packages should be called at least somewhat similar. You could always take a look at the techbase article on compilation of KDE 4 to get a more general HowTo.
It is generally a very good idea to read some articles on the techbase. Especially in the Getting Started section.
getting the dependencies
First, you’ll need to install some packages to satisfy dependencies and to get a working compile chain (think cmake, gcc and stuff). The following command only lists very few packages but they have a huge list of dependencies which your package manager will take into account automatically. Don’t be suprised by a possibly huge list of packages ;-) So some disk space will be required (though I doubt it’s more than 250MB in total).
continue reading...
