A deeper look at signals and slots

by ⋅ 2 Comments

That’s the title of a very useful article by Scott Collins which describes how to combine Boost and Qt in the same application. Unfortunately, Scott’s website went dark many months ago and I’d say it’s not coming back. Luckily, I was able to get a copy from Google’s cache before it was squashed forever. I’d say right now this is the only place in the web you can get this wonderful article: A deeper look at signals and slots

Update: The Wayback Machine has a copy of the article. I’m keeping the PDF in my site just in case, anyway.

Building Log4CXX 0.10.0 on Windows

by ⋅ 3 Comments

Apache Log4CXX is a logging framework for C++ patterned after Apache log4j. It also happens to be quite difficult to build on Windows if you are using Microsoft Windows SDK 1.0 (AKA Microsoft Platform SDK 6.0). If you are building software for Windows Vista or Windows Server 2008, or using Visual C++ 2008, you are using Windows SDK 1.0.

The reason Log4CXX 0.10.0 is hard to compile with Windows SDK 1.0 is a bug in APR 1.2.12 (the latest version available as of this writing) and a bug in Windows SDK 1.0 itself (a preprocessor redefinition due to including twice a header file). Here comes the recipe in case you want to build the stuff yourself:

  1. Download APR 1.2.12 and extract it. Rename to apr.
  2. Download APR Util 1.2.12 and extract it. Rename to apr-util.
  3. Download Log4CXX 0.10.0 and extract it
  4. Download GNU Sed and install it
  5. Open cmd.exe and run %PROGRAMFILES%Microsoft Visual Studio 9.0VCvcvarsall.bat
  6. Apply the apr-1.2.12-win32.patch patch to fix bug 40398 in APR 1.2.12 (this step is not needed if you are using APR 1.2.13)
  7. Apply the log4cxx-0.10.0-vc90-support.patch patch
  8. Enter directory apache-log4cxx-0.10.0
  9. Execute configure.bat
  10. Execute configure-aprutil.bat
  11. Open the log4cxx.dsw solution When asked to convert the solution to VC++9, click Yes to All.
  12. Right click on Solution log4cxx and select Build solution

Improving FreeDesktop.org

by ⋅ Leave a Comment

IMHO FreeDesktop.org is a weak organization and it’s specification are not taken seriously enough. Gnome and KDE are suggesting developers follow those specs, as opposed to strongly demanding they do. The end result of that is worse interoperativity between Gtk+/Gnome and KDE applications, therefore users get frustrated.

IMHO KDE and Gtk+/Gnome should define an “acceptflow” to follow in order for an application/library to be included. Briefly: if you are not using fd.o’s specs, you need to really convince us there is a good reason for that.

Expanding it, this is my proposed workflow:

  1. Developer John Doe writes an application/library
  2. Developer John Doe submits an application or library to KDE or Gnome/Gtk+
  3. Is the application good?
    • No => Not accepted, needs improvement
    • Yes. Next step
  4. Does the application or library follow FreeDesktop.org specs?
  5. Yes => Accepted
  6. No. Why not?
    • There is no FreeDesktop.org spec => Propose one, when there’s agreement in the fd.o community about the spec, go back to step 1 if you want your app/library in the official repository or keep it in your own repository (it will not be part of the official Gtk+/Gnome or KDE)
    • The FreeDesktop.org spec is good but John Doe is smarter than anyone in the world and does not want to use a “bad” spec => Sorry but go back to 1 if you want it to be included in the official repository, or keep your own repository. Fix your ego, too.
    • The FreeDesktop.org spec is not good enough, it’s to up to reality
      • Go to FreeDesktop.org and propose improvement of the spec. When the spec is good enough => Go back to 1 if you want it to be included in the official repository or keep your own repository.
      • Go to Freedesktop.org. Other people working on applications/libraries using that spec do not want to update the spec to be up to reality, for any or no reason => Go to next step
  7. So, there is a FreeDeskop.org spec but it’s not good enough and there’s no way the other people using that fd.o spec will update it. Is John Doe’s application/library really good? I mean, is it true that what he wants to change in fd.o spec should changed?
    • No. Sorry John Doe, you are not the smartest guy in the world => Go back to step 1 if you want your app/library in the official repository or keep it in your own repository. It will not be part of the official Gtk+/Gnome or KDE.
    • Yes => Accept John Doe’s app/library in the official repository and keep trying to update fd.o’s spec.

Guademy, day 1

by ⋅ Leave a Comment

I’m at València, Spain for Guademy 2008.

Guademy is a combined Gnome + KDE conference, hence the name (Guadec + aKademy), where developers of both desktops (actually every free desktop developer is invited) try to improve collaboration. IMHO it should be renamed to “Freedesktop.org Conferences” because that’s what it actually is.

I’ve seen some frienly faces I knew from other FLOSS events (Aleix Pol, Rodrigo Moya, Carlos Garnacho, Will Stephenson) and I’ve met people I had only read so far (Jos Poortvliet, Holger Freyther). There are some people that were not under my radar, too (Richard Hughes, Vincent Untz).

Yesterday we had talk about QtWebkit by Holger. He tried to show us how good Qt integration with Webkitwas. But he failed. Miserably. It’s not good. It’s AMAZING. Thanks to QtWebkit, he was able to wrote a browser with tabs, cookie management, bookmarks and plugin support in 7800 (seventy eight hundred) lines of code. In five days. The only thing missing was SSL certificate management. Awesome. I provided live translation to Spanish, for non-English speaks.

In the afternoon we had a couple of talks about FreeDesktop.org by Rodrigo, Will and Vicent. In the end, I think the problem with FreeDesktop.org is Gnome and KDE are just suggesting, instead of strongly demanding, their developers to work together.

After that, Aleix talked about KDevelop 4 and demoed it. I have to say I’m gratefully surprised by its progess. Last time I tested it (like 5 months ago), it was totally useless. Currently it works and it works reasonable well. I may start using it soon.

After so much talk, we were quite tired and hungry and went to Los Bestias (“The Rudes”) for dinner. It’s not the typical Spanish restaurant, it’s a “funny restaurant”: the bartender threw (literally) salted peanuts all over the our table, they brought us urinaries with beer and sangria, etc. It was quite funny, IMO.

There are two more days of Guademy, I’ll post more tomorrow.

Building Boost 1.33.1 with Visual C++ 2008

by ⋅ 11 Comments

I’m moving a large software package from Visual C++ 2003 to Visual C++ 2008. It depends on 3 years old versions of a lot of third party packages: ICE 3.0.1, ACE 5.4.3, Boost 1.33.1, Qt 4.1, etc.

Those libraries have underwent so many changes that updating the whole software to Visual C++ 2008 and the newest versions of the 3rd party libraries would be a too difficult task to be accomplished in a reasonable amount of time, therefore I’ve decided I’m going to stick to old libraries as much as possible, while moving to Visual C++ 9.0. The next step would be to move to newer versions of the 3rd party libraries or even to remove most of those dependencies and make the software depend only on Qt.

For starters, stock Boost 1.33.1 did not build with VC++ 9.0 but after some digging and tweaking, it works. Here is how:

  1. Download Boost 1.33.1 and uncompress it. It does not support VC++ 9.0.
  2. Apply patch to support VC++ 9.0
  3. Open cmd.exe and run %PROGRAMFILES%\Microsoft Visual Studio 9.0\VC\vcvarsall.bat
  4. boost_1_33_1\tools\build\jam_src and run build.bat
  5. Go to directory boost_1_33_1 and run tools\build\jam_src\bin.nt\x86\bjam.exe -sTOOLS=vc-9_0
  6. Run tools\build\jam_src\bin.nt\x86\bjam.exe -sTOOLS=vc-9_0 install to install to c:\boost

libdigest & libpam-digestfile

by ⋅ Leave a Comment

I have started a new open source project: The Digest Software Project. It’s a small project where I develop two tiny libraries, libdigest and libpam-digestfile.

libdigest is a C library which generates RFC2617-compliant digests, used by Apache and others.

libpam-digestfile is a Pluggable Authentication Module which lets you use an arbitrarily-named text file similar in structure to /etc/passwd to authenticate users but using digested passwords (see RFC 2617 for more information about the digest algorithm).

Both libraries are stable and in production.

Ruby magic

by ⋅ Leave a Comment

Richard Moore blogged about setters/getters vs direct access to member variables and why encapsulation is good today. Ruby excels in this aspect, IMHO:

With Ruby your code is the same regardless you are accessing a variable or a method. This means something that now is a variable, you can transform it in the future in a method with calculates a value and the code accessing it does not change at all.
Imagine you have a method to print the volume of a bottle and you had stored the volumes in pints (Imperial units). Your code is:

volume = get_bottle_volume_from_database() # these are pints, you would be getting the "10" value from a database

puts "The volume is " + volume.to_s
=> The volume is 10

Now you want to move to international units (litres). You can do this:


def volume
return get_bottle_volume_from_database() * 0.473176475 # Transform from pints to litres
end

puts "The volume is " + volume.to_s # See? "volume" is a method here (it was a variable in the former example) but our code has not changed!

Of course this is a contrived example but keep in mind this syntax allows for all kinds of magic. For example, it makes Ruby on Rails feasible

MinGW & exceptions

by ⋅ 1 Comment

Did you know the code the compiler generates to handle C++ exceptions is not written in stone? I did not.

Did you know there are two preponderant styles to do that, DWARF(2) and SJLJ? I did not

When most of the unit tests in ZeroC ICE failed after building it with MinGW, I suspected something was wrong. It turned out the stable MinGW version provides gcc/g++ 3.4.5, which implements exceptions using the SJLJ style but has not implemented propagatation of user exceptions across libraries. That was the reason why unit tests were failing.

I have already built third party dependencies (OpenSSL, Bzip2, Expat and BerkeleyDB) with a gcc/g++ 4.2.1 which produces SJLJ code and is able to propagate user exceptions. ICE is now building on the side (some warnings and info messages are shown, let’s see what happens as some of them are not my fault).