Hey everyone! The PHP & PHP-Docs plugins for KDevelop now moved to Extragear! The new locations are:
Or the anonsvn equivalent:
Today I want to abuse the fact, that my blog is aggregated on some planets, to bring a project of a friend of mine into the spotlight:
The Linux-Minidisc project
It’s a project to bring Read/Write access on mini discs to Linux. It consists of a CLI and a Qt Gui. All code is licensed under the GPL and can be accessed via Git.
To get a nice introduction about the project, read this excerpt from a recent Linux Journal edition: http://users.physik.fu-berlin.de/~glaubitz/minidisclj.pdf
The project itself has a wiki under the following address: https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php
As every other FOSS project, Adrian and his fellow developers need more man power. Especially someone who can spruce up the Qt GUI is needed. Help them!
Ha, what a bit of a bribe can do to me… Someday earlier today a user of the PHP plugin for KDevelop brought up the flickering issue in it again. Well as I told him: I myself find it very annoying and wanted to fix it since quite some time, but never got around to it… Usually that would be it and I’d go watch some more FamilyGuy until I’m in the mood to track this bugger down. But well, thankfully Phlogi wasn’t so easy to dispatch:
milian: ok… I’ll send you pizza and beer if you fix this!
gdb sessions later, I finally committed a fix. So Phlogi, if you read this: You owe me ;-)
To all others: If you tried the PHP plugin out and the flickering was too much for you: Give it a try again! I’m personally totally overwhelmed, the difference is huge! I often perceived the PHP plugin to be magnitudes slower than the C++ one. Well, looks like most of this was only due to the flickering. Now things are much smoother.
Just a quick note: Niko and me moved PHP & PHP-Docs to
kdereview, we hope to move both plugins to
extragear/sdk/kdevelop-plugins. So, if I understood things correctly, after a two week period the plugins will get moved there (well, if we pass the review, but I think we can do that).
So for anybody that uses the plugins from SVN, you’ll have to relocate. The new addresses are:
See you in two weeks :)
So, it’s been roughly a year since my first commit to kdelibs. According to Ohloh it’s been in November 2008. And boy have I learned much in this year. I learned C++ just to be able to contribute to KDE, since I thought it would be awesome to be able to “fix your own itch”. I have to say: It was the best decision I ever made.
I really came to appreciate FOSS in a whole new light: Contributing to a big project like KDE gets you in contact with lots of nice people. And they will help you get things done. What’s better is that in the process you learn lots of things. And I mean lots. I can now use GDB, Valgrind, now my way around some parts of the KDE/Qt API, can investigate performance related questions… And since these are such huge topics, there’s always more to learn, much more!
I doubt someone could learn that much by reading books or writing his own little application without the help of a community. The wealth of possibilities inside KDE will increase your horizon constantly. And there is tons of very good code to study! Want to know why something is not working? Look at the source. Still not helping? Ask your fellow developers. I really have to say it’s an awesome feeling to be part of this big community.
Well, I have to admit: I didn’t spent much time developing the PHP plugin for KDevelop these past weeks. Instead I hacked on Kate:
I added another Kate interface, this time to access some of the highlighting information:
- what’s the Attribute for a given default style right now? Default styles are those known from syntax files, e.g.
- what are used Attributes in a given line and what range do they occupy?
- what mode is used at a given Cursor position?
This made it possible to port the “Export to HTML” action to a real plugin. If you come up with other output formats I might add them, I wondered about LaTeX support… might do this at some point.
This should also make it possible to use KatePart in other applications and than export the highlighting to a different format, e.g. a Flake shape for Koffice. Afaik this is actually planned by The_User - lets see if it works out!
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:
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
Good news everyone :)
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):
Quassel is really a cool program. I like how I can use it from everywhere and access the same set of data. Now using IMAP and Quassel I’d really look forward for similar shared access to other IMs, but that’s not the topic of this blog post.
What I want to introduce is a new addition to my set of shell helpers, called quassellog:
$ quassellog -u milian -b "#kdevelop" | tail -n 1
[2009-08-27 13:09:11] milian > hi all
$ quassellog -b "#kdevelop" | tail -n 1
[2009-08-27 16:43:35] Fersis!n=Fersis@188.8.131.52 > yeah i did
quassellog [-u USER] [-b BUFFER] [PATTERN]
-u USER show only messages from users, who have USER at
the start of their sender name.
-b BUFFER show only messages in this buffer
valid buffers are:
##linux #khtml &IMP ...SNIP...
PATTERN a simple pattern, use * for wildcard matching
NOTE: order of options is not exchangable, i.e. first -u, then -b then pattern...
So, I kinda messed up my desktop right after the upgrade to karmic, because I was too greedy for performance and converted my root file system to ext4. Well, that worked like a charm on my laptop, but it broke my desktop. This is in no way karmic’s fault, it’s my own misbehavior. Thankfully I could rescue most of my data.
Since I’d had to reinstall anyways, I decided to finally try out Archlinux. I find the rolling release mantra very intriguing. Together with a “simpler” packaging, namely no splitting between
-dbg packages like debian/ubuntu does, this is destined to be a good environment for a developer. I always hated it to track down missing
-dev packages when compiling software. And don’t get me started on outdated software in repos… I just compiled kdelibs and the only missing build dependency was hspell, that I don’t need anyways. Under Jaunty I had to compile stuff from kdesupport to fulfill updated dependencies. And the list of not-found optional dependencies was huge, since I did not spent time to install all those
-dev packages by hand…