You are a student, you would like to contribute to an Open Source project, and get paid for it ?

Then I may have something for you.
At my job at Fraunhofer in Kaiserslautern we are using the CDash testing server for testing the software we develop - various different High Performance applications for Linux clusters.

Since I don't have an account to reply there http://blog.rburchell.com/2011/12/why-i-avoid-qregexp-in-qt-4-and-so.html, I'll do it here.

Recently somebody benchmarked regexp libraries as potential candidates for use in CMake.
Short version: PCRE was not exactly much faster than what is in CMake, re2 and TRE were magnitudes faster: [cmake-developers] Re: slow regex implementation in RegularExpression.

Welcome to the third part of this small series about new stuff in CMake 2.8.6, following the first and the second part.
Most non-trivial projects, whether built with CMake or something else, depend on multiple other packages, which can be either optional or required.
In CMake-based projects all these packages are searched using the find_package() command.

After introducing the automoc feature in my last blog, here comes the next part of this series. More will follow.

The new --find-package mode of CMake

Typically, in projects which are built using autotools or handwritten Makefiles, the tool pkg-config is used to find whether and where some library, used by the software, is installed on the current system, and prints the respective command line options for the compiler to stdout.

Starting with version 2.8.6 CMake supports what is known as automoc, i.e. automatic handling of moc when using Qt4.

As you know, when adding signals and slots to a class using Qt, this source code (typically the header) has to be processed by the moc preprocessor. This invocation of moc during the build is what we are talking about.

When using plain CMake, you had to use the macro

   qt4_wrapp_cpp(srcsVar ${filesToBeMocced}).

Hi,

you like KDE and you want to support it ?

Here's an easy way to do it:

The german bank ING DiBa is giving away 1000 Euro each to 1000 associations.
Selecting the 1000 winning associations is done via voting.
So, if you vote for the KDE eV there, we have a good chance to be one of the winners :-)

The money will be used by the eV to fund sprints, cover travel costs, run servers, etc.

This is how to do it:
1) go to https://verein.ing-diba.de/sonstiges/10115/kde-ev and click "Stimme abgeben"

Hi,

the KDE buildsystem BoF/meeting/whatever you want to call it/ will be Monday, at 8:00 PM (i.e. in the evening) in the restaurant/cafe St.Oberholz:
http://www.sanktoberholz.de/?page_id=13

According to Claudia they are used to geeks sitting around and discussing :-)

The address is
Sankt Oberholz
Rosenthaler Straße 72a
10119 Berlin

Places are reserved for us on my name (neundorf).

St. Oberholz should be 15 to 30 minutes walking from here.

So, to make it short, I'll be also in Berlin at the Desktop Summit, from Saturday to Wednesday evening.

So if you have wishes, questions, want to contribute to the KDE buildsystem or CMake, just look around for me :-)
There'll be a KDE buildsystem BoF . If you want to attend, please enter here when it is suitable for you in this doodle poll .

What will we be talking about there:

• modular kdelibs
  

I'm back now (since two weeks already) from the KDE Platform sprint in Randa and I have to say it was great.

Randa is located very nice in the Swiss mountains, next to Matterhorn, and very well suited not only for KDE sprints, but also for cycling (I had my bike with me there) :-)

I'm everytime impressed by the exceptional passion and extraordinary talent of the people in our community.
Probably this is because our community is "self-filtered": you don't get in for the money,
but because of personal motivation. ... and so only people who are highly motivated and
"obsessed" by software find their way to us.
David, Stephen, Milian, Sune, Aaron, Volker, Kevin (to name just a few) -- what an amazing list of people.

Until last week I was still running good old Slackware 12.1 with KDE 3.5.something.

I had skipped Slackware 13.0, because it had still no support for virtual screens in X/xrandr, and the KDE 4.4 in Slackware 13.1 crashed a few times while playing around with it. So I stayed with 12.1. For building current KDE, it doesn't matter what desktop you're running, so that was fine for me.

Now last week the new Slackware 13.37 was released and I gave it a try. Virtual screens are back in xrandr (now called "panning"), good.
And it comes with KDE 4.5.5.