Valgrind’s massif tool tracks how much memory an application uses over time, allowing you to see leaks. Previous versions produced pretty graphs. For instance, see the graph in this out-dated GNOME tutorial about massif.

However, massif’s behaviour has changed and those graphs are no longer generally appropriate. But they were nice. So I hacked a copy of the current ms_print perl code, producing massif_grapher. Forgive me for my perl code.

I used perl’s GD::Graph module. It worked but it’s a little eccentric. The image size is hard-coded and needs to be increased in the code when Gd::Graph complains that the vertical or horizontal space is too small, if you have too many data points.

massif_grapher.pl outputs a massif_pretty.png file:

• There’s a simple graph (the default) that just shows the stack and heap allocations, splitting the heap up into useful and extra (allocated as an optimization) . It doesn’t mention any functions. See this example.
• And there’s a detailed graph (via –detailed) that tries to show the old-style cumulative graph, with color for each allocating function. See this example. I won’t put it directly in my blog because their’s some obviously weird stuff happening at the top. Also, the legend needs to be reversed so it’s easier to associate the functions with the blocks on the graph. Patches welcome. You’ll get weird results if you don’t specify–detailed-freq=1 to massif.

Time will tell if this is useful.

Other useful massif tools:

• Eclipse Linux Tools’ valgrind support: Scroll down to see the video for their massif support. This allows you to jump right to the code. Useful if you are using Eclipse.
• massiftool: A Qt-based application for navigating massif snapshot data.

Until this week I was not familiar with qmake and CMake because I am a fairly satisfied user of autotools. I have not forgotten how strange it was when I first learned it, when there was no decent documentation, but things are much better now. I feel at home with it and I like how other systems and distros expect the standard “configure;make all install” steps. I am definitely biased against the use of other build systems.

However, these days I have to deal with code that uses qmake and CMake and I can’t just be stubbornly ignorant. So I tried an experiment. I created branches of a little (but real-world) project that uses Qt and an extra library via pkg-config: qlom with qmake, and qlom with cmake. The master branch uses non-recursive autotools.

I was not impressed. Please do add comments to correct me. I’d particular like patches that make my errors crystal clear and prove that it’s all much better than I think. I am capable of admitting error and changing my mind when appropriate.

Bad Documentation. Weird Syntax

Just like autotools, neither were easy to get started with. The documentation is fragmented, unclear, and incomplete. I found qmake easier than CMake, but that’s probably just because qmake does much less. Nevertheless, CMake has a real problem with documentation and in general, as a widely-used open-source project, it deserves a better infrastructure.

They both suffer from one major problem shared by autotools: They have evolved over enough time that Google will happily return out-of-date examples and documentation, making the syntax seem more varied than it really is. I wish that autotools could force me not to use deprecated syntax. I don’t know if qmake and CMake can.

As with autotools there’s a heavy dose of arbitrariness:

• File names: autotools’s configure.ac and Makefile.am seem more logical than SomeProject.pro (qmake) or CMakeLists.txt (CMake)
• Syntax: m4 (used by autotools) is a crappy language, but at least it’s a mature one that’s used outside of autotools. I understand the wish to have no dependencies, but “invent a programming language” is always a bad design decision.
  And autotools don’t require anything but make when building from a tarball. qmake and CMake seem to require that they are installed even when building from a tarball. I would have liked to see Python used because it’s easily available on all machines that would create source tarballs.
  CMake’s non-case-sensitive function names and keywords are personally annoying to me, because I like code to have a consistent style.

No Respect For pkg-config

I am dismayed that CMake expects people to write code for “Find” modules for each library they might use, while having poor support for the generic pkg-config solution. A project’s list of dependencies is data, not an excuse to write code. More code means more problems.

In fact, after several days of trying, I still can’t figure out how to use pkg-config with cmake, so my glom_cmake branch is not finished yet.

Most libraries provide the simple .pc files these days. The autotools PKG_CHECK_MODULES() macro makes it very easy to check for several dependencies at once. CMake feels too much like the bad old 90s when we suffered fragile copy-paste-hacked config scripts, custom m4, macros and verbose build files with separate CFLAGS and LIBS variables for each dependency, and inconsistent release-version and API-version checking.

I understand that pkg-config is not popular on Windows or MacOS, and that those are awkward platforms to work with, but:

• The real solution to poor dependency information on Windows and MacOS is to encourage the use of pkg-config, so it can fix the problem there like it fixed the problem for Linux. That’s entirely possible for the cross-platform libraries that are typically open source. And pkg-config would be easy to port.
• The platform-specific libraries on Windows and MacOs don’t need any cross-platform support in the build system.

CMake’s use of scripts just spreads the chaos to Linux instead of keeping things simple on Linux and improving the other platforms too.

No Configure Stage

With qmake, I really miss having a proper configure stage, with the resulting config.h so my code can use ifdefs. I like seeing a list of documented build options from configure –help, which neither qmake or cmake offer.

CMake can generate a config.h, at least. However,

• There are no default checks, so you must specify the common stuff always, making the build file more verbose.
• You can’t just generate the config.h.in, as you can with autoheader when using autotools. There’s no reason to specify the defines in both CMakeFiles.txt/configure.ac and config.h.in.
• Arbitrarily, the config.h.in uses “#cmakedefine SOMETHING 1” instead of #undef SOMETHING as in autotools (now deprecated, unnecessary) config.h.in files. For anything other than booleans, there’s an undocumented syntax such as #cmakedefine “@PACKAGE_NAME@”.

Install is an Afterthought

Both CMake and qmake require explicit extra syntax to actually install the built executable. With autotools you get this for free when using the regular bin_PROGRAMS to specify the executable name, though libraries do need more explicit instructions to install the correct headers in the correct place.

• With qmake, this typically means that paths are hard-coded in the build files. That way lies pain.
• With CMake, it’s easier, but you have to do “make -DCMAKE_INSTALL_PREFIX=/opt/mystuff” instead of autotool’s simpler ./configure –prefix=/opt/mystuff. autotools lists that option via “configure –help”.

Also, qmake and CMake have no make distcheck for making source tarball releases.

This makes sense slightly because CMake (and maybe qmake) aim to support Windows, Mac, and Linux equally, and Windows has no real convention for installation of built-from-source binaries. CMake (and maybe qmake) generate convenient Visual Studio and X-Code project files, for instance. But the end results it that Linux and Linux conventions are not fully supported, so they feel like major regressions compared to autotools.

(note: removed my nonsense with the TODO about the location of .o files.)

Summary

In summary, I think:

• qmake would only be used by Trolltech (now called Qt Development Frameworks) for their own projects, out of habit, or by users of Qt who are so unaware of other systems that they would just do whatever Qt’s developers recommend.
• CMake isn’t simpler, so it doesn’t solve autotool’s steep learning curve. It makes many thinks worse than autotools and its documentation is disconcertingly vague and incomplete. It’s cross-platform dependency checking adds complication without solving the real problem. The best CMake experience is probably with a large monolithic project rather than a large dependency tree of modules. But I like modularity and reuse.

I understand the wish to support Windows and Mac-specific build systems such as Visual Studio and X-Code. I just don’t like how qmake and cmake do that, and for me it’s not worth making things worse on Linux. Still, I’ll have to use these in some existing projects, so I’m glad that I’m more familiar with them now.

I use Qt again these days in addition to gtkmm and the rest of the GNOME stuff. Things have improved lots since I last used it seriously, though it’s still a little eccentric.

Not long ago there was no public Qt bug tracker whatsoever, but now there almost is. And Qt now uses a public git repository for (most of) its ongoing work. And it’s LGPL now. Still, when there’s a real bug tracker (just use bugzilla, please) and real open development on a mailing list then I will be much happier. I hope they get there.

Successful Open Source Needs More Than Just a License

Regular Bugzilla’s such as GNOME’s or Maemo.org’s allow people to report problems, see previously-reported problems, and generally see how problems are dealt with. People can help other users and provide improvements to the software in a structured environment. Even without the aid of a bugmaster, the system gathers valuable information. You just register, login, and use it.

When the developers (or the bugmaster) are not responsive then bugzilla provides the necessary public pressure to fix things. When developers are responsive it makes users happy and loyal. Being open increases quality. Being closed hides lack of quality.

Qt’s public bug tracker is not open like that, even if you manage to find a link to it. I’ve only used it a little, but it’s been disappointing so far.

Bug Reporting Is Not Open

To file a bug you must:

• Click “Open a new Task” and fill in the resulting web form. So far so good.
• Receive an email saying “We have read your email but require more time to deal with it. We have assigned it the issue number …”. That email arrived immediately for my first bug. For my last bug report it took a couple of weeks.
• If you are lucky you will then get a real reply from the company. It might tell you that you are mistaken and kindly help you past your problem. But that information is just in your inbox, instead of available for the next person who has the problem. And you can’t disagree or reassign it as a documentation issue.

Even if you manage to get your bug accepted, there’s no “My bugs” list where you can track the progress of your issues. One of my email conversations just ended with a promise that it would be fixed, but no bug report was ever opened for that work to be tracked and confirmed.

Bug Reports are Read-Only

You can view some open (and accepted) bugs, but you can’t add any comments to them. So you can’t offer advice or a patch, or even give a clue about when to reproduce the problem. That’s a massive lost opportunity.

Bad Habits

Unfortunately, the early code-drop of the new Maemo 6 UI Framework and Homescreen shows the same old problem. There are promises to start “working openly” in the near future, and there’s reason to believe those promises. But why wait – in the meantime it’s under a license that forbids distribution or modification and there’s not the slightest suggestion of how people might provide feedback, as Michael Hasselmann noticed. “You’ll take it and like it” is not open development.

Maybe I should close comments on this bug report to make it clear how frustrating it can be.

Maemo Summit 2009

The Maemo Summit was fun and very productive. The organization was excellent, obviously thanks to a generous budget and a dedicated hard-working maemo.org team. I met several interesting new people with whom I hope to work closely in future.

I’m very glad that this was timed with important public announcements from Nokia, so people were actually allowed to talk to each other. And the generous loan of 300 pre-release N900s made our conversations realistic.

Nokia N900 running Maemo 5 (Fremantle)

This is the first chance I’ve had to actually use an N900 in daily life. I’m not quite the target customer, because I like tiny phones and I don’t have a flat-rate data plan, but for the past couple of years I’ve been using a N95 and then a N85 (a newer model than the N95), both Symbian S60 phones, just so I can use their good cameras to snap Liam and easily upload the pictures to Flickr.

The N900 is already vastly better for my simple uses:

• The Symbian UI is incredibly awkward, even when you discover the voodoo button presses to manage multi-tasking applications and remember all the hacks to make things work properly. The UI frequently stalls for a minute at at time.
• My N85 camera crashes/hangs on every 3rd or 4th picture, or when switching between camera and video mode. So I frequently have to do a reboot to take a picture. 2 fumbling minutes is not a good camera reaction time when photographing a speeding child. My N900 camera never crashes.
• The N85 lets me upload to Flickr easily, but then the uploads get stuck in an Outbox, that’s really hard to find. Repeated requested to “Upload Now” eventually get it onto Flickr, but it’s a tedious process and I often don’t notice that a photograph hasn’t really uploaded. My N900 uploads painlessly to Flickr, offering a quick way to tag the photos as I do so.
• The N85 still refuses to upload videos to Flickr, though Flickr has supported this for a year and a half.  My N900 uploads videos to Flickr as easily as photographs.
• Symbian doesn’t seem to have any general system-level concept of networks:
  Individual Symbian applications often have their own network settings, so, for instance, an application will often do one of the following:
  • Ask you to choose an internet connection, though you are already connected.
  • Just complain that it can’t connect at all, though you are already connected. In these cases it’s generally trying to connect to some wireless network that’s hundreds of miles away.
    This seems to be improving with each (infrequent) Symbian update – for instance the Flickr updater now seems to use the already-connected network, though it’s hard to know because of the Outbox problems mentioned above.

  My N900 and its applications don’t have these network problems.

As well as solving these daily frustrations, the N900 has an amazing address book, which ends up being the main starting point for all communication. It brings all my SIM/phone, GoogleTalk, Jabber, Skype, SIP, and ovi.com chat contacts together in one list, allowing me to merge them together. Its use of the Telepathy framework means that even more backends will be added later – you can add some now though you risk breaking your phone by using unstable software. I do miss syncing contacts to ovi.com, though I feel sure that the feature will be added. This allows me to communicate easily with my friends via several methods, without using multiple fragmented applications when jumping between SMS or IM.

And those conversations (even SMS) are actually presented as individual conversations, instead of just a jumble of messages in an inbox. It’s great to see the conversation’s history when writing a new message.

I generally find that the Symbian phones don’t warn you when they are using the expensive 3G data connection , though this is again dependent on the application rather than being a system-level thing. I have not yet allowed my N900 to use the 3G connection, so I can’t say if it’s better. I anticipate that the use of a real operating system (Linux) can make this manageable. Unfortunately, network operators don’t want to help users with this. At some point they might realize that cheating customers is not a good strategy.

Less buggy, and bugs can be reported

I’ve found a few bugs – after all, this is not the final stable software. But even this pre-release is far less buggy than my awful Symbian phones. As a developer, I believe that Linux and its commonly-used tools has made this possible, though software development remains incredibly difficult for even the best people on any platform.

Best of all, I can report the bugs at bugs.maemo.org and track their progress. For Symbian, all I can do is whine on my blog. People like companies that listen to their needs instead of hiding from their customers. André will be swamped by new feedback – don’t try this without a bugmaster.

I love how full-on Nokia has launched the new N900 handset. We work so much on the underlying technology that it’s a welcome reminder how users feel emotionally about the whole product. The enthusiastic response is real encouragement for our developers. But don’t be confused by Nokia’s odd emphasis on “mobile computing” in their text – this is a highly capable smartphone that’s about communication and lifestyle rather than mere computing for the sake of it. This is their latest greatest phone – the one that people will hunger for.

For a year or so we’ve had to keep the secret that Nokia want to make phones with Linux, though every other major handset company was already doing it, because it make so much more sense than fighting the eccentricities of all those in-house proprietary platforms. I’m glad we can talk about it now, though we have vague orders to not to go into too much detail until Nokia World 2009 next week.

This product has been the major part of our work at Openismus, and is the reason for our growth, keeping Mathias, Jan Arne, Daniel B, Karsten, and André very busy and determined, with the others helping and learning so we can build on our success. Soon the code will be in our hands.

Going Home

I’ve spent the weekend at GUADEC in Gran Canaria but I fly back today to be at home for wee Liam who I really miss. I’ve noticed that people didn’t really understand that for the past year and a half I’ve spent half the week taking care of him, and the rest of the week running the company and doing just a little coding. We should have a place in a crèche in our street starting in October so things will eventually get back to normal.

In the meantime it’s been great to see old friends but I can’t talk about doing much public work in GNOME recently, or promise to help with things.

Maemo and Qt

It’s a relief that Nokia finally announced, via Quim, that they will use Qt instead of GTK+ in future versions of Maemo, though the next version, Fremantle (Maemo 5) is still entirely GTK+. Openismus have known about this for some time and have been preparing for it, but we couldn’t talk about it. As enthusiastic C++ developers, this is less disappointing to us than to other GNOME companies, and it’s been great to see Qt’s development gradually open up to the outside world.

However, it’s clearly a rather arbitrary and disruptive decision. I suspect that some managers are dictating the Nokia-wide use of Qt even in projects that don’t otherwise share code, without understanding the difficulty of the change. UI code is never just a thin layer that can be replaced easily, even if it looks like just another block in the architecture diagram. Likewise, hundreds of C coders cannot become capable C++ coders overnight. I expect great difficulties and delays as a result of the rewrites, but Openismus will be there to help.

Openismus T-Shirts

The economy has affected the traditional GUADEC T-shirt supply, making the Openismus T-shirts even more desirable. Introduce yourself to David King if you’d like one of the last ones from his backpack before he leaves on Tuesday. André, Karsten, and Johannes are here too.

This cross-desktop conference is ideal for David because he’s been intensely learning about all of GTK+, gtkmm, and Qt in the past few months.