[xmonad] [firstname.lastname@example.org: [Haskell-cafe] ANN
dons at galois.com
Sun Apr 12 12:51:18 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.
Right, the last thing sounds like the right approach.
More information about the xmonad