Life after Akademy

Published Monday July 13th, 2009
6 Comments on Life after Akademy
Posted in Git, KDE, Qt

This year again a gaggle of geeks went to Akademy from the Qt/Troll office, most of them flew there on Friday in a too-long 14 hour travel trip (office to hotel). For next year we should really choose a location that is easy to reach for the majority of our contributors.
But this is where the complaining stops, I’ve been having a great time. I saw various thought provoking keynotes and spent hours talking to old and new friends.
I loved that the lunch-breaks were long, so you could walk to a new restaurant every day and try out all the great food. I think the worst food I had here was a bit-too-simple spaghetti with only a red sauce. But it still tasted good ๐Ÿ™‚

This is a conference of geeks and naturally this means lots of talking. And a good percentage of that about computer stuff. I’ve been talking about git migration with various people and noticed I should really get more people to help out perfecting vng.googlecode.com

For instance I opened a discussion point about kDebug() which taught me a lot. So, the assumption I always had was that kDebug (and qDebug() )will completely be gone in end-user versions of my software. Which means that I can add as many debug statements as I want and it will not have any negative result on the size or speed of the final shipped executable.
To my big surprise distros like Suse have always shipped binaries where the debugs were still executed but by default just went to /dev/null
This means that when I added a kDebug() in a loop and printed some QRectF all those floats are still converted to strings only to be discarded and slowing down execution. Which is a sad surprise as my users will see the software being much slower than it could be.
In KDE4.2 this behaviour has been committed to kdelibs as the upstream default, whereas in kde3 only distros patched it. The good think is that it lead to the discussions. The end result is a much better awareness of the issue and how it affects apps. Last I heard was that Andreas is looking into fixing all issues using an updated kdebug macro. o/

I spent a total of 9 days at Akademy at it was very tiring, but also quite satisfactory. I didn’t blog much as I use identi.ca, follow me there for more details. I still have to go though my notes and todos which I’ll get to in the coming days. This year no KOffice core developers were there so the couple of KOffice-libs discussion points I prepared didn’t get attention.

The internet connection was not great, just too many people for wifi to handle (bug in the protocol?) which had the upside that nobody felt all that guilty just wandering into town or sitting down on the beach with our great green Qt towels discussing code and community. I think that discussing code and technical stuff is only a small part of what makes these conferences successful for a community. The part where you get to know the people you work with in face to face chatter is at least as important. Its just easier to see that name on IRC or in email as a real person if you know his background and hobbies.

Random thoughts;
Its been too long since I walked on flip-flops. My toes got hurt after just one afternoon.
It took me only one day to get used to the colder (~20C) Norwegian weather. Its compatible enough in my mind ๐Ÿ˜‰
Spanair may be part of the SAS group, its not the same quality. Legspace is…painful.
Git seemed to have gotten a lot of support. The people that don’t support it are mostly in the “haven’t actually ran it” camp. (did I mention vng?)
Free software conferences gather the smartest people whom are always up for some fun discussion topics. Even after my bedtime ๐Ÿ˜‰

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Git, KDE, Qt

6 comments

Andreas says:

Yes, in fact, I have a decent solution ready now without compiler warnings about nested ifs. Still TODO: figuring out the compiler guards and maybe variants of the code that work better on certain compilers, and adding some kind of cheap and effective cache to avoid hashtable lookup in hasNullOutput*() under the assumption that several kDebug()s of the same areas usually follow each other.
WIP version for g++:
# define kDebug(…) for (bool _k_kDebugDoOutput_ = !KDebug::hasNullOutputQtDebugMsg(__VA_ARGS__);
__builtin_expect(_k_kDebugDoOutput_, false); _k_kDebugDoOutput_ = false)
KDebug(QtDebugMsg, __FILE__, __LINE__, Q_FUNC_INFO)(__VA_ARGS__)

– this avoids the in this case annoying compiler warnings about nested ifs. Scope pollution is a small downside, but probably okay. Surprisingly no additional debug info for the macro-ed code seems to bloat the resulting code significantly. Q_FOREACH also pollutes it enclosed scope btw ๐Ÿ™‚

Thiago Macieira says:

C++ is not compatible with the C99 preprocessor, so you can’t use __VA_ARGS__.

For my app, we’ve ended up with:

#ifdef KMESSDEBUG_..AREA
kDebug() << “…”;
#endif

So yes, that’s a lot of times in the code, and I wish something better can be found. So far it is working nicely though.

Andreas says:

Thiago: This is going to be ugly anyway, and g++ (and MSVC 2005-ish) happen to support __VA_ARGS__ in C++ mode. For unknown or strictly standard conforming compilers this hack probably just can’t be done.

Andreas says:

Diederik: Check kdebug.h, it demonstrates a better trick. An adapted version would be:
#ifdef KMESSDEBUG_..AREA
# define kMessDebug kDebug
#else
# define kMessDebug if (1) ; else kDebug
#endif
or to avoid warnings about nested ifs (in case you use this macro in an unbraced if):
# define kMessDebug for (; false; ) kDebug

Thomas Zander says:

@Andreas good to see you still refining it, I’m looking forward to a blog or mail of yours when its done ๐Ÿ˜‰

Commenting closed.

Get started today with Qt Download now