can't build random fu

[cartazio]

it gets stuck building 10 of 27] Compiling Data.Random.Distribution.Categorical ( src/Data/Random/Distribution/Categorical.hs, dist/dist-sandbox-64cab31b/build/Data/Random/Distribution/Categorical.o )

which shouldn't take that long, but seems to never terminate....

steps to reproduce this problem with ghc 7.6.3 on OS X 10.8 (using cabal 1.17 for sandboxing)

mkdir Foo ; cd Foo ; cabal sandbox init ; cabal install random-fu

[cartazio]

this is with the most recent haskell platform.

[cartazio]

other folks who aren't using a haskell platform install don't have this problem, so I think that it might have to do with the global packages provided by haskell platform, heres the list of them from my ghc-pkg list

[cartazio]

its possible that you have some bad undecidable instances setting GHC for a loop?

[mokus0]

That's definitely possible, I'll take a look.

[mokus0]

Hmm, unfortunately I can't reproduce this. I'm also using Mac OS 10.8.4, and just installed the 64-bit Haskell Platform 2013.2.0.0 and Cabal/cabal-install 1.17 (commit 20b4ab0) and did a sandbox build after double-checking that the Haskell-Platform-provided GHC is the one on the path. I also tried moving my .ghc directory and doing a clean non-sandbox build, with the same results.

Is it possible it was a transient problem relating to the state of Hackage or the Cabal repo at the particular point in time that you built? Or maybe there's some other difference in our configurations that we don't realize is relevant, such as XCode/GCC (i've got XCode 4.6.3 with the latest "Command Line Tools" installed) or other package managers (I have homebrew installed but I don't think it has installed anything that's being used by this build)?

BTW, thanks for showing me the "cabal sandbox" feature, that's quite a bit more convenient to use than cabal-dev :)

[mokus0]

An additional data point; I also just successfully finished a build after removing both ~/.ghc and ~/.cabal (in case something in my .cabal/config was causing the difference).

[cartazio]

i just did a sandboxed build attempt again... and i'm still seeing

[10 of 27] Compiling Data.Random.Distribution.Categorical ( src/Data/Random/Distribution/Categorical.hs, dist/dist-sandbox-aead0b34/build/Data/Random/Distribution/Categorical.o )

as the stuck point in my sandboxed build. I believe that the issue is that theres some undecidable instances loop in ghc.

when i do cabal install install random-fu -v in a sandbox after the deps have been installed and i get

Ready to install random-fu-0.2.4.0
Waiting for install task to finish...
Extracting
/Users/carter/Library/Haskell/repo-cache/hackage.haskell.org/random-fu/0.2.4.0/random-fu-0.2.4.0.tar.gz
to /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/random-fu-0.2.4.0-74311...
Updating random-fu.cabal with the latest revision from the index.
Configuring random-fu-0.2.4.0...
Flags chosen: mtl2=True, base4_2=True
Dependency base ==4.6.0.1: using base-4.6.0.1
Dependency erf ==2.0.0.0: using erf-2.0.0.0
Dependency gamma ==0.9.0.2: using gamma-0.9.0.2
Dependency monad-loops ==0.4.2: using monad-loops-0.4.2
Dependency mtl ==2.1.2: using mtl-2.1.2
Dependency random-shuffle ==0.0.4: using random-shuffle-0.0.4
Dependency random-source ==0.3.0.4: using random-source-0.3.0.4
Dependency rvar ==0.2.0.1: using rvar-0.2.0.1
Dependency syb ==0.4.0: using syb-0.4.0
Dependency template-haskell ==2.8.0.0: using template-haskell-2.8.0.0
Dependency transformers ==0.3.0.0: using transformers-0.3.0.0
Dependency vector ==0.10.0.1: using vector-0.10.0.1
'/usr/bin/ghc' '--info'

as the libs being used.

when i do cabal install random-fu --v --ghc-options="-v"

it looks like i'm getting the ghc in a loop some time after type checking. I'm going to stare at that module more, this sounds vaguely like a bug i've seen in ghc's trac before. Somehow that module is doing something that depending on something not sure what it loops

[cartazio]

YUP.

when i do the verbose run of ghc

it ends with

*** Common sub-expression:
Result size of Common sub-expression
  = {terms: 5,151, types: 10,409, coercions: 1,679}
*** Float inwards:
Result size of Float inwards
  = {terms: 5,151, types: 10,409, coercions: 1,679}
*** Liberate case:
Result size of Liberate case
  = {terms: 5,201, types: 10,537, coercions: 1,699}
*** Simplifier:
Result size of Simplifier iteration=1
  = {terms: 5,175, types: 10,490, coercions: 1,679}
Result size of Simplifier
  = {terms: 5,63, types: 10,419, coercions: 1,679}
*** SpecConstr:
Result size of SpecConstr

looks like its related to http://hackage.haskell.org/trac/ghc/ticket/7944#comment:2 and http://hackage.haskell.org/trac/ghc/ticket/5550

will try and see if some of those tricks / work arounds fix it for me

[cartazio]

could you compare your results for ghc-pkg list --global to mine?

carter repoScratcher/lambdabot-4.3 » ghc-pkg list --global 
/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d
   Cabal-1.16.0
   Cabal-1.17.0
   GLURaw-1.3.0.0
   GLUT-2.4.0.0
   HTTP-4000.2.8
   HUnit-1.2.5.2
   OpenGL-2.8.0.0
   OpenGLRaw-1.3.0.0
   QuickCheck-2.6
   array-0.4.0.1
   async-2.0.1.4
   attoparsec-0.10.4.0
   base-4.6.0.1
   bin-package-db-0.0.0.0
   binary-0.5.1.1
   bytestring-0.10.0.2
   case-insensitive-1.0.0.1
   cgi-3001.1.7.5
   containers-0.5.0.0
   deepseq-1.3.0.1
   directory-1.2.0.1
   fgl-5.4.2.4
   filepath-1.3.0.1
   ghc-7.6.3
   ghc-prim-0.3.0.0
   hashable-1.1.2.5
   haskell-platform-2013.2.0.0
   haskell-src-1.0.1.5
   haskell2010-1.1.1.0
   haskell98-2.0.0.2
   hoopl-3.9.0.0
   hpc-0.6.0.0
   html-1.0.1.2
   integer-gmp-0.5.0.0
   mtl-2.1.2
   network-2.4.1.2
   old-locale-1.0.0.5
   old-time-1.1.0.1
   parallel-3.2.0.3
   parsec-3.1.3
   pretty-1.1.1.0
   primitive-0.5.0.1
   process-1.1.0.2
   random-1.0.1.1
   regex-base-0.93.2
   regex-compat-0.95.1
   regex-posix-0.95.2
   rts-1.0
   split-0.2.2
   stm-2.4.2
   syb-0.4.0
   template-haskell-2.8.0.0
   text-0.11.3.1
   time-1.4.0.1
   transformers-0.3.0.0
   unix-2.6.0.1
   unordered-containers-0.2.3.0
   vector-0.10.0.1
   xhtml-3000.2.1
   zlib-0.5.4.1

[cartazio]

theory: one of the modules that the categorical module uses is hitting an infinite loop in specialization..?

[cartazio]

as an exercise in i have no clue what i'm doing i'm trying cabal install random-fu --v --ghc-options="-fspec-constr-threshold=300" and seeing what happens

[mokus0]

From a quick diff, the only difference I see is that ghc, haskell98 and haskell2010 are not parenthesized (hidden, IIRC) on yours, but that's probably just because i used ghc-pkg ... | pbcopy rather than copying manually from the term (where it would've been colored instead of parenthesized). In case you'd like to look through it yourself:

/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d: Cabal-1.16.0 GLURaw-1.3.0.0 GLUT-2.4.0.0 HTTP-4000.2.8 HUnit-1.2.5.2 OpenGL-2.8.0.0 OpenGLRaw-1.3.0.0 QuickCheck-2.6 array-0.4.0.1 async-2.0.1.4 attoparsec-0.10.4.0 base-4.6.0.1 bin-package-db-0.0.0.0 binary-0.5.1.1 bytestring-0.10.0.2 case-insensitive-1.0.0.1 cgi-3001.1.7.5 containers-0.5.0.0 deepseq-1.3.0.1 directory-1.2.0.1 fgl-5.4.2.4 filepath-1.3.0.1 (ghc-7.6.3) ghc-prim-0.3.0.0 hashable-1.1.2.5 haskell-platform-2013.2.0.0 haskell-src-1.0.1.5 (haskell2010-1.1.1.0) (haskell98-2.0.0.2) hoopl-3.9.0.0 hpc-0.6.0.0 html-1.0.1.2 integer-gmp-0.5.0.0 mtl-2.1.2 network-2.4.1.2 old-locale-1.0.0.5 old-time-1.1.0.1 parallel-3.2.0.3 parsec-3.1.3 pretty-1.1.1.0 primitive-0.5.0.1 process-1.1.0.2 random-1.0.1.1 regex-base-0.93.2 regex-compat-0.95.1 regex-posix-0.95.2 rts-1.0 split-0.2.2 stm-2.4.2 syb-0.4.0 template-haskell-2.8.0.0 text-0.11.3.1 time-1.4.0.1 transformers-0.3.0.0 unix-2.6.0.1 unordered-containers-0.2.3.0 vector-0.10.0.1 xhtml-3000.2.1 zlib-0.5.4.1

[mokus0]

oh, and you had Cabal 1.17 in your global (mine's in the user db). That doesn't seem like it should make a difference though...

[cartazio]

thats a good catch, i'll try doing that next, in the next few days.

That shouldn't be triggering the specconstr loop bug though...

[cartazio]

A HAH.

in my cabal file i had

optimize: 2 rather than optimize: true

this means that the libs were being build with O2 rather than O1

looks like its an instance of that GHC bug i linked to before.

Could you test that you can repro the breakage on your side now ? If you can, i'll add a link to this thread onto the associated ghc trac ticket i referenced above.

[mokus0]

yep, that does the trick.

[cartazio]

It broke for your too? Ok, i'll add it to the ghc ticket

[mokus0]

Sorry, my reply was probably a little too terse. Yes, it broke when I added "optimization: 2" to my cabal.config.

[cartazio]

yay (or ugh). I'm glad thats easy to reproduce now. I guess since its pretty clearly a ghc bug, so leave it open or close it as you please, its not your problem. ish.

[mokus0]

I'll go ahead and close it, since I'm not likely to remember to close it whenever the next GHC ships.