June 2015 - Glasgow-haskell-users

Discovery of source dependencies without --make
by Lars Hupel 13 Dec '15

13 Dec '15

(cross-posted from [haskell-cafe]) Hi, I've got a problem in our – admittedly complex – build process. We're running an automated grading system for student-submitted homework exercises. The compilation proceeds in stages: 1) Compile a library file, marked as trustworthy 2) Compile student submissions using Safe Haskell, able to access a whitelisted set of packages and the previously compiled library files 3) Compile the test suite 4) Link everything together into an executable The invocation is similar to this: ghc -c -outputdir "$OUT" -XTrustworthy Library.hs ghc -c -outputdir "$OUT" -i"$OUT" -XSafe "$SUBMISSION" ghc -c -outputdir "$OUT" -i"$OUT" Test_Suite.hs ghc -outputdir "$OUT" -i"$OUT" -o "$OUT/runner" The second stage works well under the assumption that there's just one single submitted file. If there's more than one, I need to specify them in topological order wrt their module dependencies. Consider two simple modules: A.hs > module A where > > import B > import Library B.hs > module B where Invoking GHC with "A.hs" "B.hs" will fail: A.hs:3:1: Failed to load interface for ‘B’ My naive attempt at solving that problem was to just insert "--make" into the compiler flags. No luck, because according to [1, §4.7.3], "--make" will only look at source files and will ignore the "Library.hi" file from the previous compilation stage. If I give the path to "Library.hs" as well, GHC insists on recompiling it with changed flags ("-XSafe" instead of "-XTrustworthy"). Reading a bit further, I discovered the '-M' flag, however, not only does it output Makefile-formatted output, it also ignores .hi files. Is there any way to get the dependency discovery of '--make' without the rest? I know I could probably make it work if I made a package out of the first build stage, but I really want to avoid that in order to not increase the build complexity even further. Cheers Lars [1] <https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/separate-com…>

8 15

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

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