darcs patch: make xmonad recompile if any packages are modified.

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

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: http://hackage.haskell.org/trac/ghc/ticket/1372 See the faq for this issue: http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Help.21_xmo... Things have been improving in this area, but there's still a couple of scenarios that cause problems: * packages changing their ABI * source changes in a partially compile directory If either of these happen cabal should require a recompile. -- Don

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

droundy:
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.
We can continue to point out that there are issues, which helps escalate the priority.
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.
Well, it modifies the policy, as stated, which is currently only to check the xmonad.hs file. Not to attempt package magic. I'd like to see the package handling done in cabal or ghc --make first, or as an extension module, so that once we have a robust, efficient solution here, we could just use that logic.
This bug cannot be fixed by any change to ghc --make, since the situation involves bypassing both those utilities based on our hokey check.
Do you want to redo your patch, test it, and we can include it as an extension module? Then, once we have confidence in the solution, we can decide on how to support this in the core. -- Don
participants (2)
-
David Roundy
-
Don Stewart