- Glasgow-haskell-users

GHC crashing in checkProddableBlock during linking
by Luke Iannini 24 Jul '15

24 Jul '15

Hi all, I'm encountering a crash in GHC 7.10.1 and 7.8.4 on Windows when I attempt to use Template Haskell in anything that relies on a package that contains C++; in my case, bindings to the Bullet physics engine. This is a pretty big blocker for me as I haven't found any good workarounds, so it would be awesome to get a fix in (I guess I just missed 7.10.2) I've made some progress here and a minimal reproduction if anyone can help: https://ghc.haskell.org/trac/ghc/ticket/10672 Cheers Luke

1 0

ANNOUNCE: GHC 7.10.2 Release Candidate 2
by Austin Seipp 14 Jul '15

14 Jul '15

We are pleased to announce the first release candidate for GHC 7.10.2: https://downloads.haskell.org/~ghc/7.10.2-rc2 https://downloads.haskell.org/~ghc/7.10.2-rc2/docs/html/ This includes the source tarball and bindists for Windows, and Debian Linux. FreeBSD, OS X 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 in a week or two - 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/

4 3

Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2
by Sven Panne 07 Jul '15

07 Jul '15

2015-07-07 7:26 GMT+02:00 Mark Lentczner <mark.lentczner(a)gmail.com>: > And now Windows RC2 for Haksell Platform is also here: > > http://www.ozonehouse.com/mark/platform/ > > [...] > I noticed 2 problems so far: * The package cache is still always out of date (I thought there was a fix for that): ---------------------------------------------------------------------- Sven@SCOTTY /d/Repositories/ObjectName (master) $ ghc-pkg list WARNING: cache is out of date: c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d: Cabal-1.22.4.0 GLURaw-1.5.0.1 GLUT-2.7.0.1 [...] ---------------------------------------------------------------------- * Something is missing/misconfigured for Haddock (note the funny non-local path in the error message): ---------------------------------------------------------------------- Sven@SCOTTY /d/Repositories/ObjectName (master) $ cabal sandbox init Writing a default package environment file to d:\Repositories\ObjectName\cabal.sandbox.config Creating a new sandbox at D:\Repositories\ObjectName\.cabal-sandbox Sven@SCOTTY /d/Repositories/ObjectName (master) $ cabal configure Resolving dependencies... Configuring ObjectName-1.1.0.0... Sven@SCOTTY /d/Repositories/ObjectName (master) $ cabal haddock Running Haddock for ObjectName-1.1.0.0... Preprocessing library ObjectName-1.1.0.0... Haddock coverage: 100% ( 3 / 3) in 'Data.ObjectName' Haddock's resource directory (G:\GitHub\haddock\.cabal-sandbox\x86_64-windows-ghc-7.10.1.20150630\haddock-api-2.16.1) does not exist! ----------------------------------------------------------------------

2 2

ANNOUNCE: GHC 7.10.2 Release Candidate 1
by Austin Seipp 04 Jul '15

04 Jul '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/

7 8

Re: tweaking text on the ghc downloads page
by Gershom B 28 Jun '15

28 Jun '15

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. Cheers, Gershom On June 26, 2015 at 11:29:25 AM, Mark Lentczner (mark.lentczner(a)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 > putting the download buttons on the first Platform page in this round.) > > The Platform team built and proposed a page for #3 (the > haskell.org/downloads) page, that included the Download button for Platform > on the detected users's OS, and had top bar links to other options. The > sequence should be this: > > 1) Google search GHC > > 2) "GHC is cool... Get it with a full Haskell distribution", click > > 3) (on haskell.org/downloads) "Download Haskell Platform... Download > button", click > > A page for #3 was built by the Haskell Platform team that included links to > other options. You can preview it here: > > http://45.55.156.136:8000/demo-3200/download-plan-a2.html > > > — Mark >

1 0

tweaking text on the ghc downloads page
by Gershom B 26 Jun '15

26 Jun '15

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. Current: "Stop! 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." Proposed: "Stop! 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? --Gershom

3 3

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