Diary of a CrazyFrench

I just committed some code in libopenraw that allow displaying digital camera RAW files in eog (or anything else using GdkPixbuf). The colors and the gamut are still off, that's because I only perform the demosaic.

Just to be clear, I haven't changed a single line of code in eog. It is the stock version from openSUSE 10.3.

Just released a bug fix version of exempi. Version 2.0.1 address issues with error handling and some building issues on non-Linux systems.

This is likely to be the last 2.0.x release. 2.1.0 is on its way.

Just because I won't be at LGM 2008 to show this in a corner, here is a teaser screenshot:

It is still pretty much a work in progress, and is not actually up to the point where I can use it. Some keywords: XMP, digital camera RAW, non-destructive, asset management, GNOME, C++

I finally released exempi 2.0.0 The changes from previous versions are only for endian detection (I let autoconf do it) and some missing includes.

Now I'll branch, keep the 2.0 branch for eventual fixes, and master will stick for 2.1.

Using Cheese, here is a shot of my forehead after a trip to the ER.

Funny... NOT!

No I won't be presenting a Gtk+ HelloWorld, but just the valgrind output of one. It actually does not matter what program.

==28869== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==28869==    at 0x40007F2: (within /lib/ld-2.6.1.so)
==28869==    by 0x483A7A2: sigaction (in /lib/libpthread-2.6.1.so)
==28869==    by 0x5562321: google_breakpad::ExceptionHandler::SetupHandler(int) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x556242D: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==  Address 0xbec4e5f4 is on thread 1's stack
==28869== 
==28869== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==28869==    at 0x40007F2: (within /lib/ld-2.6.1.so)
==28869==    by 0x483A7A2: sigaction (in /lib/libpthread-2.6.1.so)
==28869==    by 0x5562321: google_breakpad::ExceptionHandler::SetupHandler(int) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5562445: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==  Address 0xbec4e5f4 is on thread 1's stack

Apparently this is a known bug.

Also when quitting, --leak-check=full is revealing:

==28869== 2,048 bytes in 1 blocks are definitely lost in loss record 143 of 184
==28869==    at 0x4022AD8: malloc (vg_replace_malloc.c:207)
==28869==    by 0x55623E5: google_breakpad::ExceptionHandler::SetupHandler() (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x55626D7: google_breakpad::ExceptionHandler::ExceptionHandler(std::string const&, bool (*)(void*), bool (*)(char const*, char const*, void*, bool), void*, bool) (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x5561DE2: gtk_module_init (in /usr/lib/gtk-2.0/modules/libgnomebreakpad.so)
==28869==    by 0x41AB1EC: (within /usr/lib/libgtk-x11-2.0.so.0.1200.0)
==28869==    by 0x46472E9: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463A918: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464D9EC: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F63E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x464F988: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463ECC0: (within /usr/lib/libgobject-2.0.so.0.1400.1)
==28869==    by 0x463B68E: (within /usr/lib/libgobject-2.0.so.0.1400.1)

Hint: this is not in Gtk+.

Hint2: neither is it because it is written in C++

I have been using Gtkmm a lot for a personal project.

I discovered that you can pass boost::bind to Gtkmm signals (that use sigc), thanks to the magic of templates.

Something like that:

m_selection->signal_selected
    .connect(boost::bind(&LibraryMainView::on_selected,
        m_mainview, _1));

Why? Because I'm more familiar with Boost.Bind and for me it looks more flexible. Also because you can pass a shared_ptr<> to it, unlike with sigc::mem_fun.

A new linker for GNU binutils, gold, targetting ELF, has been announced. It is apparently 5 times faster to run than the regular GNU ld. It is written in C++, and Tom Tromey praise it for its performance and its coding style.

Off course it is still pre-release and will probably need a lot of testing as well as being ported to new target architectures, as it currently only support i386 and x86_64.

And I actually need to give it a try.

10 years ago, almost, Mozilla was released as Free Software under the NPL. It was supposed to be Netscape 5. I built it on a K6-200 with 64MB of RAM which was powerful at the time (running Debian)

Yesterday, I finally rebuilt it for the second time, using the Firefox 3.0b4 code base. I'm not sure how much code is in common either. The build was smooth and, by far, much easier than OOo. Actually the fun part is that in some configuration OOo leads to building xulrunner :-)

Now let's learn XPCOM the hard way.

... and none of my circuits are functioning properly.

R.I.P. Arthur C Clarke.

Gary Gygax passed away today. R.I.P. For those who don't know who he was, Gary Gygax invented a game, and a game concept in 1974: Dungeons & Dragons and the concept of Roleplaying Games.

I think that this time I can say "I told you so".

In 2005/09 I posted this to rant about the use of hidden and undocumented MacOS X API in WebKit.

In 2008/02, the Mozilla folks post this, this and this where they denounce that issue.

The difference is that at that time I didn't bother to provide data like performance comparison, probably because I decided that it was someone else problem.

To add the these post, Microsoft actually got sued, back in the early 90s, for using undocumented APIs in order to be ahead of their competition in the space of... office applications. And Apple employees still continue to drink the KoolAid claiming that one need to file a bug... or that these are not API bit SPI (sic)^[1].

This is just one of the many frustration I no longer get by choosing only Free Software.

Federico: concerning Spamassassin in Evolution, I filed that bug a while back. Enjoy.

Just released libopenraw 0.0.5.

Here is the announce mail.

Download it.

Sometime you have to check for different versions of a packages with pkg-config because of new APIs. I had to query the lazyweb and I ended up finding something. Here is the configure.ac snippet I wrote:

GNOMEVFS_VER=0
PKG_CHECK_MODULES(GNOMEVFS, [gnome-vfs-2.0 >= 2.14],
[
  GNOMEVFS_VER=214
],
[
  PKG_CHECK_MODULES(GNOMEVFS, [gnome-vfs-2.0 >= 2.12])
  GNOMEVFS_VER=212
])
GNOMEVFS_CFLAGS="$GNOMEVFS_CFLAGS -DGNOMEVFS_VER=$GNOMEVFS_VER"

Something I haven't seen often is that PKG_CHECK_MODULES allow found and not found action blocks (yes this is in pkg-config main page). The default not found action is to fail. The above code works as follow: check the highest version you need, if not found check the one you can eventually go away with. Define a symbol with a numeric version and pass it to the modules CFLAGS.

Then in the code do:

#if GNOMEVFS_VER >= 214
...
#endif