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> 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 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>
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>
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>
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>
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:  (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 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.
Austin Seipp | 2 Jun 23:31 2015

HEADS UP: Final call for 7.10.2 is soon

Hi *,

I've just finished merging all the latest patches for GHC 7.10.2 into
the STABLE branch. All in all, we've fixed a lot of bugs (over 80
tickets closed)!

So, we'll probably be doing a 7.10.2 release here in a few weeks. The
tentative plan was around the 14th, although it's not set in stone.
(At worst, it would be pushed from the 14th to the 21st).

With that in mind, if I could quickly direct your attention to the GHC
bug tracker and the status page[1] - it would be really helpful if you
check if the things you want are fixed!

Specifically, if you want something fixed for the 7.10.2 release:

  - Make sure there is a ticket. It really needs to exist or we'll just forget!

  - If your bug is critical, please explain why! We really want to
kill showstoppers ASAP, because bugs are much cheaper to fix early. If
that's the case we can bump the priority if it's necessary to make
things clear.

  - Set the milestone to 7.10.2. It'll automatically appear on the status page.

That should be it - we'll be monitoring the status page regularly to
keep track of new things. The current bug list is pretty small - we
may move some of them out, or fix several more. So just try to let us

As a sidenote, I'm quite happy with this release - it's fixed dozens
of tricky bugs, improved some nasty corner cases in compiler
performance, and overall seems like it will be high quality. Thanks to
everyone who submitted patches!

I'll send out another email next week as another reminder.




Austin Seipp, Haskell Consultant
Well-Typed LLP,
Wolfgang Jeltsch | 2 Jun 18:28 2015

Ambiguity check and type families


the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1:

> {-# LANGUAGE TypeFamilies #-}
> type family F a :: *
> type family G b :: *
> x :: G (F a) ~ a => F a
> x = undefined

GHC 7.10.1 reports:

> Could not deduce (F a0 ~ F a)
> from the context (G (F a) ~ a)
>   bound by the type signature for x :: (G (F a) ~ a) => F a
>   at Test.hs:7:6-23
> NB: ‘F’ is a type function, and may not be injective
> The type variable ‘a0’ is ambiguous
> In the ambiguity check for the type signature for ‘x’:
>   x :: forall a. (G (F a) ~ a) => F a
> To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
> In the type signature for ‘x’: x :: G (F a) ~ a => F a

At a first look, this complaint seems reasonable, and I have already
wondered why GHC 7.8.3 actually accepts the above code.

From an intuitive standpoint, however, the code seems actually
acceptable to me. While it is true that type families are generally not
injective, it is possible to derive the type a from F a by applying G.

It would great if this code would be accepted by GHC again and if there
was a workaround to make it work with GHC 7.10.1. At the moment, this
change in the type checker from 7.8.3 to 7.10.1 breaks the
incremental-computing package in a rather fundamental way.

All the best,

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>