darcs patch: XMonad.Core: rw recompilation

1 patch for repository community.haskell.org:/srv/code/xmonad: Sat May 8 15:57:25 EDT 2010 gwern0@gmail.com * XMonad.Core: rw recompilation This diverts the intermediate *.o *.hi files to /tmp, so they don't clutter up ~/.xmonad/

What's the motivation? And does this confuse GHC when we restart a session (and /tmp is cleared). gwern0:
1 patch for repository community.haskell.org:/srv/code/xmonad:
Sat May 8 15:57:25 EDT 2010 gwern0@gmail.com * XMonad.Core: rw recompilation This diverts the intermediate *.o *.hi files to /tmp, so they don't clutter up ~/.xmonad/
Content-Description: A darcs patch for your repository!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
New patches:
[XMonad.Core: rw recompilation gwern0@gmail.com**20100508195725 Ignore-this: 27a40e58851c92c296382b7a5e80a0cf This diverts the intermediate *.o *.hi files to /tmp, so they don't clutter up ~/.xmonad/ ] { hunk ./XMonad/Core.hs 446 recompile :: MonadIO m => Bool -> m Bool recompile force = io $ do dir <- getXMonadDir + tmp <- getTemporaryDirectory let binn = "xmonad-"++arch++"-"++os bin = dir > binn base = dir > "xmonad" hunk ./XMonad/Core.hs 461 -- temporarily disable SIGCHLD ignoring: uninstallSignalHandlers status <- bracket (openFile err WriteMode) hClose $ \h -> - - waitForProcess =<< runProcess "ghc" ["--make", "xmonad.hs", "-i", "-ilib", "-fforce-recomp", "-v0", "-o",binn] (Just dir) + waitForProcess =<< runProcess "ghc" ["--make", "xmonad.hs", "-i", "-ilib", "-fforce-recomp", "-outputdir", tmp, "-v0", "-o",binn] (Just dir) Nothing Nothing Nothing (Just h)
-- re-enable SIGCHLD: }
Context:
[fix haddock comment being assigned to constructor instead of field Tomas Janousek
**20100415173936 Ignore-this: 55ac1c5dadc88a0d7635d8952feb40a0 ] [Less refreshing in mouse-2 binding (thanks aavogt) Spencer Janssen **20100503155017 Ignore-this: 5d61d6fd9a7663d0a7a1c8e2526230f7 ] [HCAr.tex: update with additions and versions gwern0@gmail.com**20100502201321 Ignore-this: 5724b4d52ce0e748ef36c4a6f343dcfd ] [+original HCAR entry gwern0@gmail.com**20100502200252 Ignore-this: 9b13691977a4e96d14ebf79c8d98cfd6 ] [Replaced custom forever_ by library function Daniel Schoepe **20090114215556] [reveal: don't insert non-clients into the set of mapped windows Tomas Janousek **20100327214243 Ignore-this: 68c0a43d761e626cb9544ca386f4846d In xmonad-core, this fixes a small bug that caused doIgnored windows to get into `mapped' and never being removed from there.
In the context of xmonad-contrib, this fixes a tremendous memory leak that could be triggered by using MouseResizableTile and UrgencyHook at the same time. MRT would create dummy windows that would get added to `mapped' by the reveal call in `windows'. As these were not removed (removal from `mapped' is filtered by `isClient'), they'd stay there forever and due to an inefficiency in UrgencyHook would eat up all memory sooner or later. ] [loc.hs: hlintify gwern0@gmail.com**20100213231537 Ignore-this: c447928ce68d0a968b55af3539c979fa ] [Various clean-ups suggested by HLint Spencer Janssen
**20100214025750 Ignore-this: ccaa6e774f2f8169e6083eddcffe31b6 ] [Make the --replace docs consistent Spencer Janssen **20100213002647 Ignore-this: c99526bce66ae1154fbf5713622f035d ] [Add --replace flag with documentation (issue 99). Adam Vogt **20091220183529 Ignore-this: c56000295b75c66309913e29e1671d88 ] [Fix compile error when using base-3 (thanks bogner). Adam Vogt **20100211063938 Ignore-this: 60ba65613bc746e7e88f11a7e30b050f ] [Broadcast PropertyChange events (needed for layouts with decoration) Daniel Schoepe **20100113204017 Ignore-this: c8315f438fed66b12282c9bfe70a4d0b ] [Rename numlockMask to numberlockMask to help users of the template config. Adam Vogt **20100118162256 Ignore-this: 4050ed2d1ad373386c2e2b44145f07d9 Without the change, the errors are like:
[ 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 ]
] [Correct warnings with ghc-6.12 Adam Vogt
**20100118181532 Ignore-this: a48ed095b72aedec9eeb88781ace66dc 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 ] [Add xfork: a forkProcess that works around process global state Spencer Janssen
**20091223061623 Ignore-this: 3f968260d8c1b6710c82566520c47c43 ] [Determine numlockMask automatically, fixes #120 Spencer Janssen **20091216012140 Ignore-this: d80c82dd0a23dc7a77fdc32fd2792130 ] [A few tweaks to --verbose-version Spencer Janssen **20091208040729 Ignore-this: cf3d6a904d23891829c10f4966974673 ] [Generalize the type of (<+>). It can be used for keybindings too. Adam Vogt **20091205233611 Ignore-this: af15248be5e483d1a6e924f786fcc1c4 ] [Main.hs +--verbose-version flag gwern0@gmail.com**20091128144840 Ignore-this: 61a081f33adb460ea459950a750dd93f This resolves http://code.google.com/p/xmonad/issues/detail?id=320 by adding a --verbose-version option yielding output like "xmonad 0.9 compiled by ghc 6.10 for linux/i386" ] [Swap the order that windows are mapped/unmapped. Addresses #322 Spencer Janssen **20091119025440 Ignore-this: 22087204f1b84dae98a3cf2b7f116d3f ] [Support for extensible state in contrib modules. Daniel Schoepe **20091106115050 Ignore-this: d04ee1989313ed5710c94f9d7fda3f2a ] [TAG 0.9.1 Spencer Janssen **20091216233643 Ignore-this: 856abdca8283155bbb8bdf003797ba34 ] [extra-source-files for the new manpage Spencer Janssen **20091216232005 Ignore-this: 919d964238198dd56d96a5052c2419c7 ] [Bump to 0.9.1 Spencer Janssen **20091216231110 Ignore-this: 8a03850d758e1e4030d930cd8bf08ba9 ] [Update for X11 1.5.0.0 Spencer Janssen **20091216011700 Ignore-this: 669c764c4c0ca516c8bdc1dfa35cd66 ] [Safer X11 version dependency Spencer Janssen **20091216010330 Ignore-this: 8297f7a6a65c5c97f83f860f642fc25 ] [man/xmonad.hs: remove reference to deprecated 'dynamicLogDzen' function Brent Yorgey **20091126053908 Ignore-this: 7aeeac9791ffd3e6ac22bf158ea86536 ] [Add GPL warning to GenerateManpage Spencer Janssen **20091111000106 Ignore-this: ea24691b8198976a4088a2708e0b4c94 ] [Add a basic header to the html manpage output Adam Vogt **20091028033042 Ignore-this: 2641e0fb3179616075fa7549b57740f3 ] [Use pandoc to convert a markdown manpage tranlation to html and man. Adam Vogt **20091028030639 Ignore-this: cdf7cdc8e44b21de8fc7725bde299792 ] [Set SIGPIPE to default in forked processes Spencer Janssen **20091106223743 Ignore-this: f73943e4fe6c5f08967ddb82afad3eaa ] [TAG 0.9 Spencer Janssen **20091026004641 Ignore-this: 80347d432f3b606c8d722536d0d729aa ] Patch bundle hash: 62861d162f91d965fb00d4b2f21ede3f6f74db06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkvlwl0ACgkQvpDo5Pfl1oIhSgCfSGgwv/P6v4WNghzx/MD9gidd wCoAoJvR0zuKn7cD/8gq+8yIrkkp2XV+ =fk/J -----END PGP SIGNATURE-----
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

On May 8, 2010, at 16:03 , Don Stewart wrote:
What's the motivation? And does this confuse GHC when we restart a session (and /tmp is cleared).
ghc's only going to get confused if they're removed *during* compilation. Otherwise, the worst that happens is ghc has to recreate them during xmonad --recompile -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

* On Saturday, May 08 2010, Brandon S. Allbery KF8NH wrote:
On May 8, 2010, at 16:03 , Don Stewart wrote:
What's the motivation? And does this confuse GHC when we restart a session (and /tmp is cleared).
ghc's only going to get confused if they're removed *during* compilation. Otherwise, the worst that happens is ghc has to recreate them during xmonad --recompile
And xmonad's recompilation checking only compares when the generated executable and the xmonad.hs were modified. Not the .o or .hi file. -- Adam

Hello, On Sat, May 08, 2010 at 05:02:40PM -0400, Brandon S. Allbery KF8NH wrote:
ghc's only going to get confused if they're removed *during* compilation. Otherwise, the worst that happens is ghc has to recreate them during xmonad --recompile
But those .o files stay there, don't they? What happens if a second user --recompiles and ghc can't rewrite/delete those files due to ownership? -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

On May 9, 2010, at 07:10 , Tomáš Janoušek wrote:
On Sat, May 08, 2010 at 05:02:40PM -0400, Brandon S. Allbery KF8NH wrote:
ghc's only going to get confused if they're removed *during* compilation. Otherwise, the worst that happens is ghc has to recreate them during xmonad --recompile
But those .o files stay there, don't they? What happens if a second user --recompiles and ghc can't rewrite/delete those files due to ownership?
If you're putting them in /tmp with fixed names, you're asking for trouble anyway (I smell a security hole). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2010/5/9 Tomáš Janoušek
Hello,
On Sat, May 08, 2010 at 05:02:40PM -0400, Brandon S. Allbery KF8NH wrote:
ghc's only going to get confused if they're removed *during* compilation. Otherwise, the worst that happens is ghc has to recreate them during xmonad --recompile
But those .o files stay there, don't they? What happens if a second user --recompiles and ghc can't rewrite/delete those files due to ownership?
That's a good point; I hadn't thought of the name conflict. Between that and Brandon's security point (ghc might not reuse those files depending on how it checks for existing files, and one could probably solve it by forcing recompilation), I guess this isn't a good idea; I've marked it rejected on darcswatch. So, we could either wait until GHC implements and widely releases some -remove-intermediates option, or we could just go with Joachim's old strategy of manually removing the intermediates in .xmonad/: http://darcswatch.nomeata.de/bundles/8e8ad2f4b141e33c06490e60b15f3191f84a5cc... + hi = base ++ ".hi" + o = base ++ ".o" lib = dir > "lib" libTs <- mapM getModTime . Prelude.filter isSource =<< allFiles lib srcT <- getModTime src hunk ./XMonad/Core.hs 424 then do -- temporarily disable SIGCHLD ignoring: uninstallSignalHandlers + -- remove old interface files, just in case ghc6 was upgraded and does not + -- like the new ones. Ignore any errors while doing so. + try $ removeFile hi + try $ removeFile o So. Thoughts on *that*? -- gwern

On 9 May 2010 06:03, Don Stewart
What's the motivation?
Still haven't seen anyone answer this question (and I don't see the point in this either; the only advantage is it might make it easier when doing GHC upgrades or something). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Thu, May 13, 2010 at 8:02 PM, Ivan Miljenovic
On 9 May 2010 06:03, Don Stewart
wrote: What's the motivation?
Still haven't seen anyone answer this question (and I don't see the point in this either; the only advantage is it might make it easier when doing GHC upgrades or something).
It removes one less variable in possible recompilation errors (I think this was already mentioned as part of making upgrades less liable to issues); it means tab-completion is not stymied by 2 extraneous files with the same prefix as 'xmonad.hs' and makes it easier to see what is what in ~/.xmonad (should users really need to know about .hi and .o files?); and it's a small change, which I think would be justified by either benefit. (If customization is the raison d'etre of xmonad, anything which removes an irritant is a benefit.) The objection that it won't catch stuff in .xmonad/lib is not significant, I don't think. Do many users use that? And if the compilation cleanup is incomplete, does it hurt anything? It would be nice to eliminate *all* the intermediates, but it seems like another 'perfect is the enemy of the good' issue. -- gwern
participants (7)
-
Adam Vogt
-
Brandon S. Allbery KF8NH
-
Don Stewart
-
Gwern Branwen
-
gwern0@gmail.com
-
Ivan Miljenovic
-
Tomáš Janoušek