- Glasgow-haskell-users

ghc 7.10.1 hard lock on exit with shake, OS X 10.10
by Evan Laforge 23 Jun '15

23 Jun '15

After I upgraded to 7.10.1 I started noticing that my shakefile would lock up on exit. It's after the 'main' function exits, and none of the shake tests have a problem, so presumably it's a GHC thing, that shake somehow causes to happen. Only kill -9 gets it to quit. Here's a stack trace from the OS X sampler: Call graph: 2801 Thread_909901 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2801 _dispatch_mgr_thread (in libdispatch.dylib) + 52 [0x7fff8828ca6a] 2801 kevent64 (in libsystem_kernel.dylib) + 10 [0x7fff90ec0232] Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): kevent64 (in libsystem_kernel.dylib) 2801 I know there aren't a lot of details here, but does this sound familiar to anyone? I can't see anything on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 that looks like this. Is there any way I can get more information I can get to report this? It used to be frequent (once in 10 runs maybe), but later became quite infrequent (once in a couple hundred runs, maybe). I downgraded to 7.8.4 and it hasn't happened again.

3 5

Re: Trouble building applications with Haskell GLUT and freeglut on OS X with GHC 7.10.1
by Jérome Mahuet 22 Jun '15

22 Jun '15

Hello, When I depend on the GLUT Haskell package (2.6 or newer) on GHC 7.10.1 on OS X 10.10.3, the GLUT package builds and installs successfully, but applications that depend on GLUT fail during cabal install with this kind of linking error: can't load .so/.DLL for: /Users/jd/sandbox/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT_J2ZZFJOYOcH4hQYFlXhEPp/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib (dlopen(/Users/jd/sandbox/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT_J2ZZFJOYOcH4hQYFlXhEPp/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Users/jdsandbox/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT_J2ZZFJOYOcH4hQYFlXhEPp/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib Expected in: flat namespace in /Users/jd/sandbox/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT_J2ZZFJOYOcH4hQYFlXhEPp/libHSGLUT-2.7.0.1-0waW9bZutCf5s5H5zSV4Oh-ghc7.10.1.dylib) Occurs when trying to load GLUT to GHCi. $ ghci -package GLUT I tried loading the OSX's GLUT.framework manually: $ ghci -framework GLUT -package GLUT but it produces the same error message. To be sure I checked the OSX's GLUT.framework, it does contain the _glutBitmap8By13 symbol. It's also worth noticing that this only occurs on OS X with GHC 7.10.1 and cabal 1.22.*. linux + ghc 7.10.1 = Ok mac + ghc 7.10.1 = Fail mac + ghc 7.8.4 = Ok I'm not sure if this is a GHC or Cabal bug, but something is working differently on Mac with GHC 7.10.1/cabal 1.22.* Did you guys encounter something similar, is there a work-around we can do inside the GLUT Haskell package?

2 1

-prof, -threaded, and -N
by Lars Kuhtz 19 Jun '15

19 Jun '15

Hi, The behavior of the -N flag (without argument) with the profiling runtime seems inconsistent compared to the behavior without profiling. The following program ``` module Main where import GHC.Conc main :: IO () main = print numCapabilities ``` when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof +RTS -N` prints `2` on my machine. When the same program is compiled with `ghc -threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N` it prints `1`. When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling and non-profiling versions behave the same. I tested this with GHC-7.10.1 but I think that I already observed the same behavior with GHC-7.8. Is this inconsistency intended? Lars

2 2

RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 19 Jun '15

19 Jun '15

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

11 14

overlapping instances in 7.10.1
by Sergei Meshveliani 16 Jun '15

16 Jun '15

Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2… presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei

2 6

ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 14 Jun '15

14 Jun '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc1 https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/ This includes the source tarball and bindists for Windows, Mac OS X, and Debian Linux. FreeBSD and Solaris binaries will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.2 final release at the end of this coming week - so please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

cannot build 'vector' with profiling
by Ranjit Jhala 11 Jun '15

11 Jun '15

Hi all, I cannot build 'vector' (or 'cmdargs') with profiling on. specifically when I run: $ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all -caf-all" vector I get the message: Perhaps you haven't installed the "p_dyn" libraries for package ‛integer-gmp’ https://ghc.haskell.org/trac/ghc/ticket/8677 Per some advice I tried to add the '--disable-shared' $ cabal install --disable-shared --enable-executable-profiling --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all -caf-all" vector but then I get this: Loading package primitive-0.6 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.6.dylib (dlopen(libHSprimitive-0.6.dylib, 9): image not found) Any idea whats going on or for any work arounds? Pretty stumped! Thanks in advance! Ranjit.

3 10

7.10 branch
by Simon Peyton Jones 11 Jun '15

11 Jun '15

Austin I'm getting these validation failures on the 7.10 branch. Are you? This is on Linux. Simon Unexpected failures: driver T8959a [bad stderr] (normal) ghci/scripts T9878b [bad stderr] (ghci) th T10279 [stderr mismatch] (normal) Unexpected stat failures: perf/should_run T4830 [stat not good enough] (normal) perf/should_run T7436 [stat not good enough] (normal)

1 0

Re: [Haskell-cafe] The evil GADTs extension in ghci 7.8.4 (maybe in other versions too?)
by Edward Z. Yang 10 Jun '15

10 Jun '15

This is because -XGADTs implies -XMonoLocalBinds. Edward Excerpts from Ki Yung Ahn's message of 2015-06-04 20:29:50 -0700: > \y -> let x = (\z -> y) in x x > > is a perfectly fine there whose type is a -> a. > (1) With no options, ghci infers its type correctly. > (2) However, with -XGADTs, type check fails and raises occurs check. > (3) We can remedy this by supplying some additional options > (4) Howver, if you put -XGADTs option at the end, it fails again :( > > > kyagrd@kyahp:~$ ghci > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > \y -> let x = (\z -> y) in x x :: t -> t > Prelude> :q > Leaving GHCi. > > > kyagrd@kyahp:~$ ghci -XGADTs > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > > <interactive>:1:30: > Occurs check: cannot construct the infinite type: t0 ~ t0 -> t > Relevant bindings include > x :: t0 -> t (bound at <interactive>:1:11) > y :: t (bound at <interactive>:1:2) > In the first argument of ‘x’, namely ‘x’ > In the expression: x x > Prelude> :q > Leaving GHCi. > > > ~$ ghci -XGADTs -XNoMonoLocalBinds -XNoMonomorphismRestriction > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > \y -> let x = (\z -> y) in x x :: t -> t > Prelude> :q > Leaving GHCi. > > > ~$ ghci -XNoMonoLocalBinds -XNoMonomorphismRestriction -XGADTs > GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :t \y -> let x = (\z -> y) in x x > > <interactive>:1:30: > Occurs check: cannot construct the infinite type: t0 ~ t0 -> t > Relevant bindings include > x :: t0 -> t (bound at <interactive>:1:11) > y :: t (bound at <interactive>:1:2) > In the first argument of ‘x’, namely ‘x’ >

3 3

Closed Type Families: type checking dumbness? [was: separate instance groups]
by AntC 08 Jun '15

08 Jun '15

> From: AntC > Date: 2015-06-04 22:39:25 GMT > > Take the standard example for partial overlaps. > Suppose I have a class: ... > I'm also getting (in more complex examples) > GHC complaining it can't infer the types > for the result of f. > So now I'm having to put type equality > constraints on the class instances, > to assure it that F comes up with > the right type. In a reduced example, I'm still getting poor type checking. This is GHC 7.8.3. This seems so dumb, I'm suspecting a defect, It's similar to but much more glaring than: https://ghc.haskell.org/trac/ghc/ticket/10227 https://ghc.haskell.org/trac/ghc/ticket/9918 {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module ClosedTypeFamily where data Foo b c = Foo b c deriving (Eq, Read, Show) type family F a where F (Foo Int c) = Int -- Foo Int is first instance F (Foo b Char) = Char class C a where f :: a -> F a instance C (Foo Int c) where -- compiles OK f (Foo x _) = x instance (F (Foo b Char) ~ Char) => C (Foo b Char) where f (Foo _ y) = y needs the eq constraint. Without it, GHC complains: Couldn't match expected type ‘F (Foo b Char)’ with actual type ‘Char’ Relevant bindings include f :: Foo b Char -> F (Foo b Char) In the expression: y In an equation for ‘f’: f (Foo _ y) = y Note that if I change the sequence of the family instances for F, then GHC instead complains about the class instance for (Foo Int c). OK these are overlapping class instances. But GHC's usual behaviour (without closed type families) is to postpone complaining until and unless a usage (Foo Int Char) actually turns up. BTW if I put a first family instance F (Foo Int Char) = Int to explicitly catch the overlap, then GHC complains about **both** class instances. Reminder [to Richard] I need not only types but also terms. AntC

4 6