Evan Laforge | 31 Jul 20:10 2015

simultaneous ghc versions

The recent release of ghc 7.10.2 reminded me of something I meant to
ask about a long time ago.  Most of the binaries ghc installs are
versioned (x linked to x-7.10.2), with some exceptions (hpc and
hsc2hs).  Shouldn't they all be versioned?  Also, 'haddock' is
inconsistent with all the rest, in that it's haddock linked to

I've long used a few shell scripts (recently upgraded to python) to
manage ghc installs.  A 'set' which creates symlinks to make a
particular version current, and an 'rm' to remove all traces of a
version.  But due to the inconsistency, I have to remember to run
"fix" first, which moves the unversioned binaries to versioned names.

As an aside, I have three scripts I use all the time: set version,
remove version, and remove library.  Come to think of it, shouldn't
ghc include this, instead of everyone creating their own shell scripts
by hand?
Christian Maeder | 24 Jul 09:59 2015

broken source link


when trying to look up the original definition for
Data.List.transpose in
I found that the source link
does not work.

Could this be fixed? Or should I look elsewhere for the sources?

Cheers Christian

P.S. my looking up transpose was inspired by
Gershom B | 28 Jun 10:47 2015

Re: tweaking text on the ghc downloads page

Ok, this is now done. Rather than “Stop” it now says the hopefully slightly less confusing “Take
Notice,” and the text is otherwise as I proposed.

I agree that this is only a tiny step in a more general streamining of this whole process.


On June 26, 2015 at 11:29:25 AM, Mark Lentczner (mark.lentczner <at> gmail.com) wrote:
> Well - it isn't objectionable.... but it is, at best, a stop gap.
> Ultimately, what people want when they want to get Haskell installed is a
> big button marked "Download" - that when pressed starts the download
> immediately. This is true for beginners and seasoned users alike. It is
> true on all web sites for all things.
> Every link we put in their way looses some percentage, and increases the
> frustration of others. This change makes it:
> 1) Google search GHC
> 2) "Latest news...", search and find Download in left bar, click
> 3) "Stop! ...", click downloads
> 4) "You've got options ...", click "Platform
> 5) "Download button", click
> (That last one is actually another click and page load, but we'll be
(Continue reading)

Gershom B | 26 Jun 16:53 2015

tweaking text on the ghc downloads page

I know there is a plan for some broader ghc webpage redesign.

In the meantime, apparently people find the current "Stop" text terribly troublesome. This is because, of course, it points to the platform and now some people believe that a minimal distribution is more usable, etc.

Just to take this issue off the agenda, I would like, if there are no objections, to just change that text as follows.



For most users, we recommend installing the _Haskell Platform_ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together."



For most users, we recommend installing _a proper distribution_ instead of just GHC. A distribution includes a recent GHC release as well as other important tools (such as cabal, for installing libraries), and potentially a broader set of libraries known to work together."

And where before the "Haskell Platform" text would link to of course the platform page, the new "proper distribution" text would now link to https://www.haskell.org/downloads where we could then argue to our heart's content about the best way to present the various download and installation options as we go forward.

So, this doesn't resolve any controversy, but it at least centralizes it.

If there's no objection, I'll try to get to this tomorrow?

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
Jérome Mahuet | 22 Jun 12:56 2015

Re: Trouble building applications with Haskell GLUT and freeglut on OS X with GHC 7.10.1


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:
5): Symbol not found: _glutBitmap8By13
  Referenced from:
  Expected in: flat namespace
 in /Users/jd/sandbox/.cabal-sandbox/lib/x86_64-osx-ghc-7.10.1/GLUT_J2ZZFJOYOcH4hQYFlXhEPp/libHSGLUT-

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?
Simon Peyton Jones | 11 Jun 18:21 2015

7.10 branch


I’m getting these validation failures on the 7.10 branch. Are you?  This is on Linux.


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)

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
Ranjit Jhala | 10 Jun 06:18 2015

cannot build 'vector' with profiling

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’

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!

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
AntC | 6 Jun 08:04 2015

Closed Type Families: type checking dumbness? [was: separate instance groups]

> 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:

{-# LANGUAGE TypeFamilies,
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.

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
AntC | 4 Jun 01:09 2015

Closed Type Families: separate instance groups?

Currently (GHC 7.8.3) the only form for Closed Type Families is:

    type family F a where ...
      -- list your instances here

(This was considered a common use case
 -- for example in HList to put the type-matching instance
 with the non-matching, and that would be total coverage;
 rather than needing a type family decl and an instance decl
 with the instance head same as family.
 That was an optimisation over ...)

Way back the design was more like this:

    type family F a

    type instance F (Foo b c)  where
      F (Foo Int c) = ...
      F (Foo b Char) = ...

    type instance F (Bar e f g) where
      F (Bar Int f g) = ...

The idea was that the separate instance groups must have non-overlapping heads.

This is handy if Foo, Bar, etc are declared in separate places/modules.
You can put the instances with the data decl. 
And quite possibly the family decl is in an imported/library module 
you don't want to touch.

Is this separate instance group idea still a gleam in someone's eye? 
If not, is there some deep theoretical reason against?

Lars Kuhtz | 3 Jun 07:20 2015

-prof, -threaded, and -N


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?

Evan Laforge | 3 Jun 03:36 2015

ghc 7.10.1 hard lock on exit with shake, OS X 10.10

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.