On Sat, Oct 27, 2007 at 02:52:28AM -0400, Devin Mullins wrote:
- If it's bug-free (no space-leaks, safe-ish unsafePerformIO, etc.)
Well, after looking at some of the relevant comments in GHC/{IOBase,STRef,ST}.lhs, I feel more confident that both are true. 1. The NOINLINE should eliminate duplicate newIORefs and order of ops is safe here. 2. IORef (at least in GHC) use STRef, which uses ST, which is strict in its state. However, I'm having some other odd problems (repeatable!): - If I mod-q xmonad while xchat is the current window, xchat no longer sends urgent events. Opening prefs and hitting ok (no changes) fixes it. - If I mod-q xmonad while I've got a child dzen process open (via XMC.Dzen.dzenUrgencyHook), the new xmonad no longer responds to keyboard events. It responds to mouse events (the border moves with focus). This is not the case for dzens spawned via: spawn "(date; sleep 2) | dzen2" In fact, the behavior is a little more nuanced. After I mod-q, while the dzen is still open, I can hit mod-j, and I see the focus temporarily move, and then snap back when I keyup. After the dzen goes, 'j' gets sent to the client window. Help! Devin