[xmonad] [mailing_list@istitutocolli.org: [Haskell-cafe] ANN xmobar-0.9.2]

Norbert Zeh nzeh at cs.dal.ca
Sun Apr 12 10:16:55 EDT 2009

>  - Norbert Zeh tracked and fixed a longstanding bug that made xmobar
>    leak X resources. This alone makes it worth this release and its
>    public announcement, with the advice to users to upgrade.[*]
> [*] I tend to believe the same issue affects xmonad, even though it
> should be visible only after a huge number of restarts. Things get far
> worse when it comes to the xmonad-contrib library, especially if you
> use fancy decorations in your layouts: if you see colors you are
> probably leaking them.

After discussing this with Andrea, I looked briefly into fixing this
(for xmonad core right now).  The reason why I didn't do it was that (a)
as Andrea points out, only a huge number of restarts will make this
problem show and (b) it seems much harder to fix than in xmobar, the
reason being that the usage of allocated colors in xmobar is *much* more
localized than in xmonad.  Fixing this in xmonad would require small
changes throughout the code base, I believe---minor ones, but still.

In fact, I strongly believe that the whole issue should in fact be fixed
in the haskell bindings for X11.  One thing I like about high-level
languages such as Haskell is that I don't have to worry about allocating
memory etc.  The garbage collector takes care of it.  Along the same
line, it would have been nice if the Haskell binding for XAllocNamedColor
(and its relatives) returned a Haskell object that calls XFreeColors
automatically once the garbage collector gets rid of the object.


More information about the xmonad mailing list