July 2013 - ghc-devs - Haskell.org

Re: defunctionalization
by Carter Schonwald 19 Jul '13

19 Jul '13

naively, it might really blow up compilation times perhaps? (i'm speculating on the compilation time possibility) Large haskell projects do take a while to build as is, so any changes that can blow up compilation times really merit being thoughtful. On Thu, Jul 18, 2013 at 6:20 PM, Andrew Farmer <xichekolas(a)gmail.com> wrote: > Maybe this is a good time to ask, since I've always been curious... is > there a reason -fexpose-all-unfoldings is not the default? > > That is, is there a strong reason to not include the original RHS of > *every* exported function in the interface file, regardless of its > INLINE/NOINLINE status? This would greatly benefit HERMIT users, for > example... or other plugins that do some form of partial evaluation. > > I realize interface files would be bigger, but disk is cheap. They would > also change more often, maybe triggering more recompilation? Thoughts? > > Drew > On Jul 18, 2013 3:10 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> So the idea here to make it possible to have a function that can be >> specialized at certain types, and explicitly inlined at specific use >> sites, but ghc otherwise will not inline it? Cool! >> >> one thought: might it be simpler to instead have something like >> EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas >> which "seem" contradictory? >> >> >> >> On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby <nicolas.frisby(a)gmail.com >> > wrote: >> >>> This table outlines my plan for the compatibility of the pragmas. >>> >>> Each cell is formatted as "x/y", where "x" answers "Is the original RHS >>> in the interface file?" and "y" answers "Will GHC try to inline it?". >>> >>> NOINLINE INLINABLE INLINE >>> <none> no/no yes/yes yes/enthusiastically >>> >>> NOINLINE error yes/no error >>> INLINABLE - error error >>> INLINE - - error >>> >>> The proposed new "yes/no" option gives the GHC user more control. It >>> prevents GHC from inlining a function while still supporting the ability to >>> use the annotated function's RHS in another module, via SPECIALISE or the >>> special "inline" function. Moreover, the presence of the RHS in the .hi >>> file could be used by tools other than GHC like plugins or a super-compiler. >>> >>> >>> On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones < >>> simonpj(a)microsoft.com> wrote: >>> >>>> It seems a little weird, but the internal data types can express it, >>>> so if you can make the front end do the right thing I’d be happy to take >>>> it. (Don’t forget the manual.)**** >>>> >>>> ** ** >>>> >>>> SImon**** >>>> >>>> ** ** >>>> >>>> *From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Nicolas >>>> Frisby >>>> *Sent:* 16 July 2013 21:29 >>>> *To:* ghc-devs(a)haskell.org >>>> *Subject:* Re: defunctionalization**** >>>> >>>> ** ** >>>> >>>> Ah, I misread that TidyPgm function.It looks like if I build the >>>> CoreUnfolding, GHC will respect it. It's just rejecting the pragma >>>> combination in HsSyn.**** >>>> >>>> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby(a)gmail.com> >>>> wrote: >>>> > >>>> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding. >>>> > >>>> > (I'm sketching a defunctionalization pass. I'd like the 'apply` >>>> routine RHS to make it into the interface file, but I do not want it to be >>>> inlined, since that'd undo the defunctionalization.) >>>> > >>>> > In other words, I'd like a CoreUnfolding value with the uf_guidance = >>>> UnfNever. >>>> > >>>> > It seems TidyPgm.addExternal ignores such a core unfolding. >>>> > >>>> > Would GHC consider a patch to make this work? >>>> > >>>> > Thanks.**** >>>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>

1 0

defunctionalization
by Nicolas Frisby 18 Jul '13

18 Jul '13

I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks.

4 6

RE: [commit: ghc] master: include FastString.string_table in CoreMonad.reinitializeGlobals (163de25)
by Simon Peyton-Jones 16 Jul '13

16 Jul '13

Do you put the FS table back after running the plugin? If not, the same unique may be allocated more than once. S | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Nicolas Frisby | Sent: 04 July 2013 05:13 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: include FastString.string_table in | CoreMonad.reinitializeGlobals (163de25) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | https://github.com/ghc/ghc/commit/163de25813d12764aa5ded1666af7c06fee0d6 | 7e | | >--------------------------------------------------------------- | | commit 163de25813d12764aa5ded1666af7c06fee0d67e | Author: Nicolas Frisby <nicolas.frisby(a)gmail.com> | Date: Wed Jul 3 18:23:54 2013 -0500 | | include FastString.string_table in CoreMonad.reinitializeGlobals | | >--------------------------------------------------------------- | | compiler/simplCore/CoreMonad.lhs | 36 +++++++++++++++++++++++++++++++-- | --- | compiler/utils/FastString.lhs | 15 ++++++++++++++- | 2 files changed, 45 insertions(+), 6 deletions(-) | | diff --git a/compiler/simplCore/CoreMonad.lhs | b/compiler/simplCore/CoreMonad.lhs | index e11c139..7fe5554 100644 | --- a/compiler/simplCore/CoreMonad.lhs | +++ b/compiler/simplCore/CoreMonad.lhs | @@ -722,11 +722,12 @@ data CoreReader = CoreReader { | cr_hsc_env :: HscEnv, | cr_rule_base :: RuleBase, | cr_module :: Module, | - cr_globals :: ((Bool, [String]), | + cr_globals :: (,,) (Bool, [String]) -- from StaticFlags | + FastStringTable -- from FastString | #ifdef GHCI | - (MVar PersistentLinkerState, Bool)) | + (MVar PersistentLinkerState, Bool) -- | from Linker | #else | - ()) | + () | #endif | } | | @@ -789,7 +790,7 @@ runCoreM :: HscEnv | -> CoreM a | -> IO (a, SimplCount) | runCoreM hsc_env rule_base us mod m = do | - glbls <- liftM2 (,) saveStaticFlagGlobals saveLinkerGlobals | + glbls <- liftM3 (,,) saveStaticFlagGlobals saveFSTable | saveLinkerGlobals | liftM extract $ runIOEnv (reader glbls) $ unCoreM m state | where | reader glbls = CoreReader { | @@ -891,6 +892,8 @@ getOrigNameCache = do | %* * | | %*********************************************************************** | * | | +Note [Initializing globals] | + | This is a rather annoying function. When a plugin is loaded, it | currently | gets linked against a *newly loaded* copy of the GHC package. This | would | not be a problem, except that the new copy has its own mutable state | @@ -921,13 +924,36 @@ I've threaded the cr_globals through CoreM rather | than giving them as an | argument to the plugin function so that we can turn this function into | (return ()) without breaking any plugins when we eventually get 1. | working. | | +----- | + | +We include the FastString table in this mechanism, because we'd like | +FastStrings created by the plugin to have the same uniques as similar | strings | +created by the host compiler itself. For example, this allows plugins | to | +lookup known names (eg `mkTcOcc "MySpecialType"`) in the GlobalRdrEnv | or even | +re-invoke the parser. | + | +In particular, the following little sanity test was failing in a plugin | +prototyping safe newtype-coercions. | + | + let rdrName = mkModuleName "GHC.NT.Type" `mkRdrQual` mkTcOcc "NT" | + putMsgS $ showSDoc dflags $ ppr $ lookupGRE_RdrName rdrName $ | mg_rdr_env guts | + | +`mkTcOcc` involves the lookup (or creation) of a FastString. Since the | +plugin's FastString.string_table is empty, constructing the RdrName | also | +allocates new uniques for the FastStrings "GHC.NT.Type" and "NT". | These | +uniques are almost certainly unequal to the ones that the host compiler | +originally assigned to those FastStrings. Thus the lookup fails since | the | +domain of the GlobalRdrEnv is affected by the RdrName's OccName's | FastString's | +unique. | + | \begin{code} | reinitializeGlobals :: CoreM () | reinitializeGlobals = do | - (sf_globals, linker_globals) <- read cr_globals | + (sf_globals, fs_table, linker_globals) <- read cr_globals | hsc_env <- getHscEnv | let dflags = hsc_dflags hsc_env | liftIO $ restoreStaticFlagGlobals sf_globals | + liftIO $ restoreFSTable fs_table | liftIO $ restoreLinkerGlobals linker_globals | liftIO $ setUnsafeGlobalDynFlags dflags | \end{code} | diff --git a/compiler/utils/FastString.lhs | b/compiler/utils/FastString.lhs | index 36b1b1e..0bdf0a0 100644 | --- a/compiler/utils/FastString.lhs | +++ b/compiler/utils/FastString.lhs | @@ -91,7 +91,10 @@ module FastString | unpackLitString, | | -- ** Operations | - lengthLS | + lengthLS, | + | + -- * Saving/restoring globals | + saveFSTable, restoreFSTable, FastStringTable | ) where | | #include "HsVersions.h" | @@ -573,4 +576,14 @@ fsLit x = mkFastString x | forall x . sLit (unpackCString# x) = mkLitString# x #-} | {-# RULES "fslit" | forall x . fsLit (unpackCString# x) = mkFastString# x #-} | + | + | +-------------------- | +-- for plugins; see Note [Initializing globals] in CoreMonad | + | +saveFSTable :: IO FastStringTable | +saveFSTable = readIORef string_table | + | +restoreFSTable :: FastStringTable -> IO () | +restoreFSTable = writeIORef string_table | \end{code} | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

Re: Exposing newtype coercions to Haskell
by Nicolas Frisby 16 Jul '13

16 Jul '13

It's available here (for now). http://ittc.ku.edu/~nfrisby/tcrn-plugin.tar.gz Sorry for the whack build/test infrastructure: I wasn't planning sharing this write-once experimental code. The 'MyTcRnDriver.initTcFromModGuts` function and the 'TcRnPlugin.append_guts` are the key functions. The rest of 'MyTcRnDriver` is only necessary because 'tcRnModule` is a big function that bakes in its own invocation of 'initTc`. Most other functions in the tcrn don't do this. I hope to patch GHC to factor 'tcRnModule` a bit and export the pieces so that it can be re-used with 'initTcFromModGuts` instead Note the TODOs; mostly they focus on stuff like hpc and Safe Haskell. Basic functionality seems fine. HTH. On Tue, Jul 16, 2013 at 8:31 AM, Joachim Breitner <mail(a)joachim-breitner.de>wrote: > Hi, > > Am Dienstag, den 16.07.2013, 07:44 -0500 schrieb Nicolas Frisby: > > It allows you to execute TcRn computations (without manually > > reinitializing its monadic inputs), which is a prerequisite for > > invoking most functions from the type checker or renamer. I anticipate > > that such invocations will be helpful in your task. > > I see; in that case: Thanks! > > Greetings, > Joachim > > -- > Joachim Breitner > e-Mail: mail(a)joachim-breitner.de > Homepage: http://www.joachim-breitner.de > ICQ#: 74513189 > Jabber-ID: nomeata(a)joachim-breitner.de >

1 0

Trac
by Simon Peyton-Jones 15 Jul '13

15 Jul '13

Hi Ian Trac at http;//ghc.haskell.org seems to be down. Is it a config issue or is our new server really down? Thanks eg http://ghc.haskell.org/trac/ghc/ticket/7850 Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Heads up: darcs.haskell.org server changed
by Ian Lynagh 15 Jul '13

15 Jul '13

Hi all, darcs.haskell.org has now moved to the new server. SSH will complain that the key has changed, and you will probably have to delete the corresponding line from ~/.ssh/known_hosts. The new key fingerprint is: 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0 Please let me know if you see any problems. Thanks Ian

4 8

Nightly builder server, and snapshots
by Ian Lynagh 14 Jul '13

14 Jul '13

Hi all, The nightly builder server is finally back up and running; sorry for the delay. If you use the latest client code, then the resulting bindist will also get uploaded to darcs.haskell.org. Thanks Ian

2 1

T3294 variies in whether it fails or not
by Simon Peyton-Jones 13 Jul '13

13 Jul '13

Ian Perf/compiler/T3294 has very different max_bytes_used when BINDIST=YES than without. See below. I don't know why. I don't know whether it matters. Maybe it's just the moment that GC strikes. But it's uncomfortable to have such an erratic test failure. Simon simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make TEST=T3294 python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2"' -e 'config.ghc_pkg="/5playpen/simonpj/HEAD-1/inplace/bin/ghc-pkg"' -e 'config.hp2ps="/5playpen/simonpj/HEAD-1/inplace/bin/hp2ps"' -e 'config.hpc="/5playpen/simonpj/HEAD-1/inplace/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-1/testsuite"' \ --only=T3294 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at Tue May 28 09:21:29 BST 2013 ====> Scanning ./all.T =====> T3294(normal) 2 of 14 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable -RTS >T3294.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Tue May 28 09:21:29 BST 2013 14 total tests, which gave rise to 47 test cases, of which 46 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ cat T3294.comp.stats /5playpen/simonpj/HEAD-1/inplace/lib/bin/ghc-stage2 -B/5playpen/simonpj/HEAD-1/inplace/lib -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable [("bytes allocated", "2721056936") ,("num_GCs", "540") ,("average_bytes_used", "15190408") ,("max_bytes_used", "36726792") ,("num_byte_usage_samples", "15") ,("peak_megabytes_allocated", "105") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "2.64") ,("mutator_wall_seconds", "3.25") ,("GC_cpu_seconds", "2.03") ,("GC_wall_seconds", "2.03") ] simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make TEST=T3294 BINDIST=YES python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc"' -e 'config.ghc_pkg="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc-pkg"' -e 'config.hp2ps="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/hp2ps"' -e 'config.hpc="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-1/testsuite"' \ --only=T3294 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at Tue May 28 09:21:49 BST 2013 ====> Scanning ./all.T =====> T3294(normal) 2 of 14 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable -RTS >T3294.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 36904752 +/-15% Lower bound max_bytes_used: 31369039 Upper bound max_bytes_used: 42440465 Actual max_bytes_used: 43818472 *** unexpected failure for T3294(normal) Unexpected results from: TEST="T3294" OVERALL SUMMARY for test run started at Tue May 28 09:21:49 BST 2013 14 total tests, which gave rise to 47 test cases, of which 46 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures Unexpected failures: . T3294 [stat not good enough] (normal) simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ cat T3294.comp.stats /5playpen/simonpj/HEAD-1/bindisttest/install dir/lib/ghc-7.7/bin/ghc -B/5playpen/simonpj/HEAD-1/bindisttest/install dir/lib/ghc-7.7 -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable [("bytes allocated", "2724158504") ,("num_GCs", "525") ,("average_bytes_used", "16042228") ,("max_bytes_used", "43818472") ,("num_byte_usage_samples", "15") ,("peak_megabytes_allocated", "116") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "2.77") ,("mutator_wall_seconds", "3.38") ,("GC_cpu_seconds", "2.38") ,("GC_wall_seconds", "2.38") ] simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$

2 1

[PATCH] Haddockify some comments in compiler/hsSyn/HsBinds.lhs
by Mateusz Kowalczyk 13 Jul '13

13 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have turned some comments in compiler/hsSyn/HsBinds.lhs into Haddock format. They were just sitting there, hidden from the world (to spite anyone scratching their heads when looking through the generated docs, like myself). They were already written so why not use them? See attachment. I trust that they're right but I cannot guarantee it. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRsQ3TAAoJEM1mucMq2pqX9lQP/Al86/rfrr+Q6yLf8HtudIeT +vBDu/r4wClZmNzKKxrtgECELl5UoRX33EUdY2ydHAh0VyPFQZwK1G2Xzktg6zjS 8DSvPhHWDvlces3EWdQOyScwMG+jm+/ezdhU7LVQjCEPvfSQ21csIrDkdRgGH918 qD6wThZ7lZMfccJkkFxya8MIN9XJxQCW65XGUobVgpY5OyQTmy5Dj5teYz+GW/7O VWUUDyNQP6OtlmefhdvHEjrq88Gl+YylAa6x4B27mavRxmdV2gzMxcApfcwj5vkD 1T8+Azl8zpAOwOLa02is7yb0gsuIo/naropcicSeyz67S+Bivp/XO/Z66n6BEAhW iIr+fCTJeArU2NZ5erT/Awkcw9yam8hD3/3wJgaME07Q6Qmfd0l1NoXm4u/6M/Hr yLFhinnRBe/NiENf9wxWzSCky/lkvZjmWcchxPYFN1ZtmOKnP07S1YnjKZ+XEwwW X72XIMAbKzUkhm615UkV//Z09ueTEXpHvA7JRiCVpCivpHX8mXWwe5Su5tlrvL6t /DO2uUawD9OcPpSgarqI1/j+JmWmDq0/ayGI2Wj5PQmp5gFZS8EfYANYXDOCa4nx bZh32ZIgh+agoMvo/XqhRdO0oj/rTd9V3mrh3Na1Yu0KcC3uRwkiBfj0S0C/Wb92 bjxukm7b56XtazyUk2BX =0okt -----END PGP SIGNATURE-----

2 2

package installation woes with Template Haskell / dynamic libraries
by Richard Eisenberg 13 Jul '13

13 Jul '13

Hi all, --- tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's? --- I've built and installed HEAD (as of Apr 8), on Mac OS 10.8.2, without specifying a build.mk file (i.e., using the defaults). I then tried to install the singletons package. This package has multiple modules, one of which uses another in some Template Haskell code. The TH code also uses the syb and mtl packages. - A simple `cabal install singletons` fails when compiling the module that uses TH, because there are no .dylib files for the syb or mtl libraries. I add 'shared: True' to my ~/.cabal/config file, "dangerous"ly reinstall mtl and syb and try again. - Now, `cabal install singletons` still fails during compilation, because the TH code looks for Singletons.dyn_o, which doesn't exist. The problem is that the vanilla build happens before the shared build, and TH seems to require the shared build. - I try `cabal install singletons --disable-library-vanilla`, and everything compiles, but then I get this: Installing library in /Users/rae/Library/Haskell/ghc-7.7.20130407/lib/singletons-0.8.5/lib cabal: dist/build/HSsingletons-0.8.5.o: does not exist - In the hopes that cabal kept the .dyn_o files around, I try regular `cabal install singletons`, but cabal seems to have discarded the .dyn_o files and I get the same error as before. - So, I `cabal unpack singletons`, go into the singletons folder, and run `cabal install --disable-library-vanilla`, and get the installation error as before. But, the compile worked and the .dyn_o files are kept! So, a final `cabal install` now works. Phew. I have a relatively weak understanding of cabal. My question is: Is the problem I've run into here based on local settings that need to be fixed? Is there a moving part somewhere that needs to be upgraded? Or, is this a real bug somewhere? If the problem isn't local, I see three separate bugs here: 1) I had to "dangerous"ly reinstall mtl and syb to get the shared libraries after updating my ~/.cabal/config. I think it should be possible to augment an existing package installation with a new "way" without reinstalling. 2) If a package uses TH and depends on another package, and if TH requires dynamic linking, cabal should automatically install dynamic versions of the library, overriding settings in ~/.cabal/config. Or, if overriding settings is a no-no, it should give a stern warning. It would make sense if this dependency were required to be stated in the package's .cabal file. 3) If a package uses TH and depends on itself, similar logic should apply (requiring a dynamic build), and the order of compilation should be fixed. I can understand (but, without more knowledge, would disagree with) an argument discarding 1) and 2) as natural consequences of a silly user, but 3) -- especially the compilation order -- seems more fundamental. I don't know of a way of installing singletons now without unpacking it and dancing around this problem. What do you think? Are these bugs? Am I a silly user? Or both? Thanks! Richard

2 1