
On Wed, Mar 19, 2008 at 11:11:46AM -0700, Don Stewart wrote:
droundy:
WARNING: I haven't actually tested this patch. But it ought to work as advertized, and should give a good start to someone interested in making this work (right now, I don't want to wait half an hour for xmonad-contrib to recompile in order to test it). Perhaps the cabal folks could also make use of this idea (checking timestamps), so xmonad could segfault less often. Or we could jury-rig this check into Setup.lhs ourselves...
David
Wed Mar 19 09:37:38 PDT 2008 David Roundy
* make xmonad recompile if any packages are modified. I'm not going to apply this, but we can use it as more leverage on ticket:
I'm not sure how you think that reproducing this bug in xmonad, such that fixing it in ghc won't do us any good can really provide us with leverage. It seems rather to imply that we don't care about the issue.
See the faq for this issue:
http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Help.21_xmo...
No, that's not the faq for this issue. That's the faq for a related issue. The issue addressed by this bug is http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Changes_to_... Okay, actually this patch isn't fully adequate to fix this, since ghc may fail to recompile when we call it (due to the ghc bug you point out). I suppose we may need to add an additional bit of code to work around the ghc bug. But the patch I submitted has nothing to do with working around ghc bugs, and only fixes an xmonad bug. This bug cannot be fixed by any change to ghc --make, since the situation involves bypassing both those utilities based on our hokey check. -- David Roundy Department of Physics Oregon State University