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

[Don Stewart]

nzeh:
> >  - 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.

Right, the last thing sounds like the right approach.

-- Don