- Glasgow-haskell-users

8.4.1 ghci findings
by Evan Laforge 23 Mar '18

23 Mar '18

I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference.

1 0

ghc 8.0.2 vs 8.4.1 compilation time and performance
by Evan Laforge 21 Mar '18

21 Mar '18

I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 Linux, PC: RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. >From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 Linux, PC: score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1

1 0

"strange" error
by asyropoulos＠aol.com 15 Mar '18

15 Mar '18

Hello, I have compiled the latest veersion of ghc under OpenIndiana (Solaris) and now I am trying to compile cabal. I downloaded the source code from https://www.haskell.org/cabal/download.html and I tried to compile. I used the bootstrap.sh script bit it failed: Configuring cabal-install-2.0.0.1... Setup: Encountered missing dependencies: HTTP >=4000.1.5 && <4000.4, async >=2.0 && <3, cryptohash-sha256 ==0.11.*, hackage-security >=0.5.2.2 && <0.6, hashable >=1.0 && <2, tar >=0.5.0.3 && <0.6 Error during cabal-install bootstrap: Configuring the cabal-install package failed. The script downloaded all these packages so I tried to see why they fail: $ cd HTTP-4000.3.7 $ ls CHANGES HTTP.cabal Network test dist LICENSE Setup.lhs $ runhaskell Setup configure Configuring HTTP-4000.3.7... Setup: Encountered missing dependencies: base >=4.3.0.0 && <4.11 Of course this package is already installed and this means that for some reason it cannot find it. It is quite possible that I am doing something stupid but I would like to know how can I proceed? Thanks in advance for your help/assistance. A.S. -- Apostolos Syropoulos Xanthi, Greece

1 0

[ANNOUNCE] GHC 8.4.1 released
by Ben Gamari 14 Mar '18

14 Mar '18

The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.… There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

5 8

Re: [ANNOUNCE] GHC 8.4.1 released
by asyropoulos＠aol.com 08 Mar '18

08 Mar '18

Hello, I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and compilation never starts because: checking target system type... i386-pc-solaris2.11 Build platform inferred as: i386-unknown-solaris2 Host platform inferred as: i386-unknown-solaris2 Target platform inferred as: i386-unknown-solaris2 Unknown OS solaris2.11 The configure script mentions Solaris... On my system I get $ uname -m i86pc $ uname -r 5.11 $ uname -s SunOS $ uname -v illumos-87446a5213 Any idea that migh help me go beyond this point? Thanks in advance! A.S. -- Apostolos Syropoulos Xanthi, Greece

2 1

How to highlighting subexpressions in dumped core?
by Joachim Breitner 07 Mar '18

07 Mar '18

Hi, one of my plugins dumps core output to the user, and this core output contains “interesting subexpressions”. I would like to highlight them (for example, with `bold :: SDoc -> SDoc`). As far as I can see, I have these options: * I copy all, or most of PprCore, and extend ppr_expr to look for the subexpressions that I care about. Obviously not nice, because of a code copy. * I extend GHC to support that. One way would be to add a new constructor to `data Tickish id = … | Highlight` so that I can wrap the interesting subexpressions in `Tick Highlight e`. That’s a bit better, and could even be useful in GHC (e.g. a linter error could highlight the lint error location), but it’d mean waiting for new compiler versions until I can make use of that, and it is still limited to subexpressions – highlighting a binder would require yet another support. * Could we extend SDoc with an operation highlightIn :: SDoc -> SDoc -> SDoc or highlightIn :: Doc -> Doc -> Doc where `highlightIn doc1 doc2` is like doc2, but any subdocument that is “ismorphic to doc1” (for whatever that means) gets highlighted? Are there other options that I might not see right now? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

GHC 8.4.1-rc1 is slower on a ray-tracer project
by Vassil Ognyanov Keremidchiev 28 Feb '18

28 Feb '18

Hello! I have a small ray-tracer project: https://bitbucket.org/varosi/cgraytrace >From time to time I'm testing it with different GHC versions including ARM. Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my Intel Core i7 machine on Windows 10 x64. I got this results: GHC 8.4.1-rc1 Average time: 61.87s GHC 8.2.2 Average time: 60.09s GHC 8.0.2 Average time: 67.07s Application is doing multi-threaded brute-force ray-tracing with GI, so a lot of rays are shot around. It seems that previous GHC 8.2.2 is doing better on a high-performance application. I know that this test is too simple, but it is on a real world problem and application and not one for whole purpose of benchmarking. Any thoughts are welcome!

3 5

Re: [ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 26 Feb '18

26 Feb '18

Vincent Hanquez <tab(a)snarc.org> writes: > On 25/02/18 17:42, Ben Gamari wrote: >> The GHC development team is pleased to announce the first (and likely >> final) release candidate of GHC 8.4.1. The usual release artifacts are >> available from >> >> https://downloads.haskell.org/~ghc/8.4.1-rc1 >> > Hi Ben, > > Looks like both SHA1SUM and SHA256SUM are missing the fedora27 variant > Good catch; it looks like I neglected to regenerate them after fixing the name of the the Fedora vairant. Fixed. Cheers, - Ben

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 25 Feb '18

25 Feb '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

1 1

GHC for Plugins
by Matt Walker 13 Feb '18

13 Feb '18

Hello, I am developing a game and would like to write the core in haskell with haskell also for scripting. I like haskell. I have the following file to help me do this. >>> BEGIN FILE {-# LANGUAGE ScopedTypeVariables #-} module Plugin.Load where import Data.Functor import System.Directory import GHC import GHC.Paths import DynFlags import Unsafe.Coerce type ModName = String type ValName = String loadPlugin :: FilePath -> ModName -> ValName -> IO a loadPlugin dir modName value = do withCurrentDirectory dir $ defaultErrorHandler defaultFatalMessager defaultFlushOut $ runGhc (Just libdir) $ do dynFlags <- getSessionDynFlags setSessionDynFlags $ dynamicTooMkDynamicDynFlags $ dynFlags { importPaths = [modName] ++ importPaths dynFlags , hscTarget = HscAsm , ghcLink = LinkInMemory , ghcMode = CompManager } sequence [guessTarget modName Nothing] >>= setTargets load LoadAllTargets setContext [IIDecl $ simpleImportDecl $ mkModuleName modName] fetched <- compileExpr (modName ++ "." ++ value) return (unsafeCoerce fetched :: a) <<< END FILE The problem is that if I run the function loadPlugin on the same input more than once, GHC barfs. The error I get is: /usr/bin/ld.gold: error: cannot find -lghc_5 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** Exception: ExitFailure 1 sometimes it's -lghc_2 or -lghc_13 above. Anyways, it seems like I and/or ghc isn't cleaning up properly after themself and then wants to try to append numbers. Any idea what is causing this and how to fix it? Thanks, Matt PS. is there a better way of doing this using Typeable? I'd rather not unsafeCoerce.

1 0