darcs patch: Correct warnings with ghc-6.12 (and 1 more)

Mon Jan 18 11:20:58 EST 2010 Adam Vogt
[ unrelated error messages ] No constructor has all these fields: `numlockMask', `terminal', [every other field set]
With the change:
`numlockMask' is not a record selector [ context where numlockMask is named ]

Excerpts from Adam Vogt's message of Mon Jan 18 17:26:14 +0100 2010:
Mon Jan 18 11:22:56 EST 2010 Adam Vogt
* Rename numlockMask to numberlockMask to help users of the template config.
Since configs will be broken with regard to numlockMask anyway, wouldn't it be more prudent to rename it to filterModifiersMask or something along that line, since users of e.g. Ukranian keyboard layouts had to add more modifier bits to numlockMask to get various things like Prompt to work properly. So something like filterModifiersMask would resemble its usage more closely.

* On Monday, January 18 2010, Daniel Schoepe wrote:
Excerpts from Adam Vogt's message of Mon Jan 18 17:26:14 +0100 2010:
Mon Jan 18 11:22:56 EST 2010 Adam Vogt
* Rename numlockMask to numberlockMask to help users of the template config. Since configs will be broken with regard to numlockMask anyway, wouldn't it be more prudent to rename it to filterModifiersMask or something along that line, since users of e.g. Ukranian keyboard layouts had to add more modifier bits to numlockMask to get various things like Prompt to work properly. So something like filterModifiersMask would resemble its usage more closely.
The field moving from XConfig to XState is still supposed to contain a numlockMask... or at least it does once (setNumlockMask :: X ()) is run when xmonad starts up. Users could still modify that field once xmonad is running. However, the actual name of the field doesn't matter to me, so long as it isn't numlockMask (since that leads to very confusing error messages by ghc for users who will try an old template config).... so send an amended patch if this is important to you? -- Adam

Adam Vogt
- compatibility with base-4 or 3 (base-2 untested) by using extensible-exceptions. This adds an additional dependency for users of ghc<6.10)
From memory, extensible-exceptions needs >=GHC-6.8, so using it means
there's no more base-2 compatability. On the other hand, do we really
need to keep support for

* On Monday, January 18 2010, Adam Vogt wrote:
Mon Jan 18 11:20:58 EST 2010 Adam Vogt
* Correct warnings with ghc-6.12 Changes include: - compatibility with base-4 or 3 (base-2 untested) by using extensible-exceptions. This adds an additional dependency for users of ghc<6.10) - list all dependencies again when -ftesting (change in Cabal-1.8.0.2) - remove unnecessary imports - suppress -fwarn-unused-do-bind, with appropriate Cabal-1.8 workaround, described here: http://www.haskell.org/pipermail/xmonad/2010-January/009554.html
Attached is an amended patch that re-throws ExitSuccess, fixing a regression where you could not exit xmonad (without killing it or calling exitFailure). The other patch in this bundle is not re-sent. -- Adam

This 1-patch bundle was just applied to http://code.haskell.org/xmonad:
20100118181532 Adam Vogt
participants (4)
-
Adam Vogt
-
Daniel Schoepe
-
darcswatch@nomeata.de
-
Ivan Lazar Miljenovic