October 2017 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

perf.haskell.org functional again
by Joachim Breitner 30 Nov '18

30 Nov '18

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim

5 11

GHCi recompilation avoidance UI
by David Feuer 11 Dec '17

11 Dec '17

Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses to load optimized code unless -fobject-code (and optimization flags) are enabled. I propose the following slight modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48 1. Optimization flags (except -O0) imply -fobject-code. This ensures that GHC respects optimization flags regardless of --interactive. 2. Even when -fobject-code is on, :load *M will load M as bytecode. This provides the "escape hatch" from -fobject-code that you need to use debugging features, etc. 3. New -fignore-optim-changes and -fignore-hpc-changes (Phab:D4123) flags should enable users to put together object code and bytecode with diverse optimization levels/options and HPC options while still updating automatically based on source changes and whether profiling is enabled. Does this seem like a reasonable way forward? David Feuer

5 8

Building on limited memory environments (or does -M really work?)
by Saurabh Nanda 08 Nov '17

08 Nov '17

Hi, We're struggling to get our build pipeline working on CircleCI, which has a 4GB RAM limit. Here are some project stats to set the context: - 1,200+ modules - 36,315 LoC of Haskell - On the local machine with -O1 -j the build takes approx 5.2 GB of RAM [1] Trying to build on CircleCI with -O1 -j fails consistently, as expected. However, the behaviour of -M -j -O1 is erratic, at best. Sometimes it magically works, sometimes it fails. A number of times we've seen GHC take 3.5 GB (as reported by `top`), even though the limit was set to 2.5GB. Here are flags that we've tried in various combinations we've tried. None of them is consistent in building / failing: * -O1 * -j * +RTS -M2621440000 -RTS * +RTS -A32m -RTS * +RTS -n2m -RTS What is the **real** behaviour of the -M option? How does it interact with -j and -A? [1] If I'm reading this correctly - https://gist.github.com/saurabhnanda/c8f8654a7f29c1adb753b357b897b5f3#file-… -- Saurabh.

4 5

tcSubsumes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi Simon, Could you take a look at TcSimplify.tcSubsumes? This relatively new function pushes the TcLevel when calling tcSubType, but then doesn't set the TcLevel when calling the solver. Inexplicably, this sometimes works -- even passing the testsuite. Somehow, my work caused this to fail. I fixed it by setting the TcLevel before calling the solver. Two questions: 1. Is this a reasonable fix? 2. (optional) How is it possible that this didn't fail drastically often? Note (to author / reviewers of this function): my astonishment isn't that this error crept into the codebase -- I've done similar many many times. My astonishment is how the testsuite didn't find this error forthwith. Thanks, Richard

2 1

valid substitutions for holes
by Richard Eisenberg 07 Nov '17

07 Nov '17

Hi all, GHC HEAD currently suggests valid in-scope single-identifier substitutions for typed holes (underscores in terms). Some unrelated work somehow changed the output, and I'm wondering if this is a change for the better or for the worse. The test case is this: > f :: Int -> Int -> Int > f x y = _ x y With my patch, GHC now suggests `pure` and `return` as replacements for _ (along with the other top contenders of (-), asTypeOf, and const). (You can also increase the number of suggestions, which will then include (+) and (*) among others.) It's true that `pure` and `return` fit the bill, noting that ((->) Int) is an Applicative. But I doubt these suggestions will help the user. I'm not keen to make fixing this "valid suggestions" feature (which I do really like) a dependency of finishing my patch, but I also don't want the change to output to go unnoticed. So, I'm asking: when I merge my patch, should I post a bug asking for perhaps a priority ordering of suggestions? Thanks, Richard

2 1

[ANNOUNCE] GHC 8.2.2 release candidate 2
by Ben Gamari 05 Nov '17

05 Nov '17

Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id…

4 3

Bringing some observable sharing to GHCi
by David Feuer 02 Nov '17

02 Nov '17

The :sprint, :print, and :force commands in GHCi fall into infinite loops when confronted by cyclical data. This bit me hard in https://phabricator.haskell.org/D4085 because that produces cyclical TypeReps, which is trouble for (e.g.) the test break011 which tries to :force a SomeException (which wraps an Exception dictionary, which has a Typeable constraint). I could try coming up with a fix myself, but I'm rather curious whether some of the work you (or others) have already done on observing GHC data graphs could be yanked into GHCi itself for this purpose. We want 1. To be able to display cyclical data in some sensible way. > x = "hi" : x > x `seq` () > :print x should print some useful representation of x. 2. To be able to force cyclical data without looping. > x = "hi" : x > :force x should print a useful representation of x.

4 3

When does GHC produce unlifted `let` bindings?
by Sebastian Graf 02 Nov '17

02 Nov '17

Hi folks, I was debugging a Core-to-Core transform for TEST=spec-inline <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> and was wondering (yet again) why GHC produces unlifted `let` bindings in Core like it seems supposed to be doing <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/te…> . - Why doesn't this use `case` instead? - Is there a semantic difference? - Can `case` be used with unlifted types? - And if not, why can `let`? Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem to agree. <https://github.com/ghc/ghc/search?l=Haskell&q=%22strict+let%22&type=&utf8=%…> Cheers, Sebastian

3 4