February 2018 - 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

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 07 Mar '18

07 Mar '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

4 8

ghc, OpenBSD and stack pointer checking
by Matthias Kilian 06 Mar '18

06 Mar '18

Hi, while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK for the system stack and, if the check fails, just aborts the process.[1] (Please note that this differs from the meaning of MAP_STACK on some other operating systems) At first, everything looked fine, but later during the build, *sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got aborted after *many* succesfull runs of it (for example, while compiling the bundled haddock and after already a couple of haddock sources had been successfully compiled). So, if the stack pointer checking diff to OpenBSD is correct, and if I'm not running into a completely unrelated problem: does ghc and/or the runtime library sometimes move the system stack pointer to newly allocated/mapped memory? If so, where in the code? Please note: the check happens on traps and system calls, so the doesn't happen when the stack pointer is changed to newly allocated/mapped memory, but after the next trap or system call. Unfurtunately, I was stupid enough to drop my recent build logs and back traces, but they weren't very enlightening, anyway ;-) I may to get some more information tomorrow or on thursday. I'd appreciate any help on this. After all it's probably just a matter of changing one call to mmap(2), shielded by an #ifdef. Ciao and thanks in advance for any help, Kili [1]: https://marc.info/?l=openbsd-tech&m=151572838911297&w=2

2 3

Guarded Impredicativity implementation
by Artem Pelenitsyn 02 Mar '18

02 Mar '18

Dear ghc-devs, Is there any work has been done on the latest (ttbomk) proposal for impredicative types in Haskell: > Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage, Dimitrios Vytiniotis, Simon Peyton Jones https://www.microsoft.com/en-us/research/wp-content/uploads/2017/07/impredi… Or are there any plans to do so? I wasn't able to spot any mentions of this in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo). -- Best wishes, Artem Pelenitsyn

3 2

An idea for a different style of metaprogramming evaluation using the optimiser
by Matthew Pickering 28 Feb '18

28 Feb '18

I've had an idea for a while of a different way we could evaluate TH-like splices which would be more lightweight and easier to work with. The idea is to create a third quotation/splicing mechanism which has no introspection (like MetaML) but then to evaluate these quotes and splices in the optimiser rather than using the bytecode interpreter. I am motivated by the many examples of recursive functions in libraries, which when given a statically known argument should be able to be unrolled to produce much better code. It is understandable that the compiler doesn't try to do this itself but there should be an easy way for the user to direct the compiler to do so. (See also https://www.reddit.com/r/haskell/comments/7yvb43/ghc_compiletime_evaluation/) An example to be concrete: Take the power function such that power k n computes k^n. power :: Int -> Int -> Int power k n = if n == 0 then 1 else k * power k (n - 1) If we statically know n then we can create a staged version. We use R to indicate that an argument is dynamically known. power :: R Int -> Int -> R Int power k n = if n == 0 then .< 1 >. else .< ~k * ~(power k (n-1)) >. One way to implement this in Haskell is to use typed template haskell quoting and splicing. The key thing to notice about why this works is that in order to splice `power k (n-1)` we need to evaluate `power k (n-1)` so that we have something of type `R Int` which we can then splice back into the quote. The way this is currently implemented is that the bytecode interpreter runs these splices in order to find out what they evaluate to. The idea is that instead, we add another mode which runs splices in the core-to-core optimiser. The optimiser performs evaluation by beta reduction, inlining and constant folding. For simple definitions on algebraic data types it does a very good job of eliminating overhead. As long as the call is not recursive. If we can just get the optimiser to inline recursive calls in a controlled manner as well, it should do a good job on the unrolled definition. The benefits of this are that it works across all platforms and fits nicely already into the compilation pipeline. It also fits in nicely with the intuition that a "quote" means to stop evaluating and a "splice" means to evaluate. A disadvantage is that the optimiser is only a *partial* evaluator rather than an evaluator. It gets stuck evaluating things containing primitives and so on. I don't forsee this as a major issue but a limitation that library authors should be aware of when writing their staged programs. To go back to the power example, the recursive condition would have to be an inductively defined natural (data N = Z | S N) rather than an Int as the comparison operator for integers can't be evaluated by the optimiser. It is already rather easy to write staged programs which loop if you don't carefully consider the staging so this seems now worse than the status quo. Does this sound at all sensible to anyone else? Matt

3 4

Help with build ordering issue
by Sylvain Henry 26 Feb '18

26 Feb '18

Hi, @Bodigrim is working on a patch (https://phabricator.haskell.org/D4212) to fix #14170. The build fails because of interface file errors: "bad interface file" for GHC.Natural and "failed to load interface" for GHC.Types. I suspect it is a wired-in module build ordering issue but I haven't been able to help fixing it. If anyone with more insights could help it would be much appreciated! Thanks, Sylvain

2 6

RE: [commit: ghc] master: testsuite: Bump allocations for T9630 (f57c305)
by Simon Peyton Jones 26 Feb '18

26 Feb '18

This is a reduction => good! "Bump" is usually bad. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 25 February 2018 21:58 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: testsuite: Bump allocations for T9630 | (f57c305) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2Ff57c3059d7c8b8e00bd3a9f9153c3520f | 6db14d4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cbff75d8952bc489 | 7f12608d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519 | 27127060212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=Hk8Q%2FVgrwqEUkysgX3Stj5GO5t3YNeM04wALzV6ZZSE%3D&reserved=0 | | >--------------------------------------------------------------- | | commit f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Sun Feb 25 16:23:39 2018 -0500 | | testsuite: Bump allocations for T9630 | | | >--------------------------------------------------------------- | | f57c3059d7c8b8e00bd3a9f9153c3520f6db14d4 | testsuite/tests/perf/compiler/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1ae69e7..1a2413a 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -1228,9 +1228,10 @@ test ('T9630', | [ compiler_stats_num_field('max_bytes_used', # Note [residency] | [(platform('x86_64-unknown-mingw32'), 39867088, 15), | # 2017-12-24: 34171816 (x64/Windows) | - (wordsize(64), 41568168, 15) | + (wordsize(64), 35324712, 15) | # initial: 56955240 | # 2017-06-07: 41568168 Stop the specialiser generating | loopy code | + # 2018-02-25: 35324712 It's not entirely clear | ]), | extra_clean(['T9630a.hi', 'T9630a.o']) | ], | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=04%7C01%7Csimonpj%40microsoft.com%7Cbff75d8952bc4897f1260 | 8d57c9ae8c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365519271270 | 60212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | TiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=2bTG4reUJV7m3RsSUMse20LChfZPcJP3Ea%2FQkgqmLFw%3D&reserved=0

2 1

GNU make file in ghc/utils folder
by Chris R. Timmons 23 Feb '18

23 Feb '18

I'm trying to add a new utility to the $(TOP)/ghc/utils folder. The utility has a make file, but I can't seem to get it to play nice with GHC's build system. The error I receive is "No rule to make target...". Here's a simple test environment that demonstrates the problem: --------------- 1. Create a new folder called $(TOP)/ghc/utils/testmake. 2. In the 'testmake' folder, create a file named "Makefile" with this content: dir = utils/testmake TOP = ../.. include $(TOP)/mk/sub-makefile.mk 3. In the 'testmake' folder, create a file named "ghc.mk" with this content (NOTE: My email app may have replaced the tab character before "@echo" with spaces.): $(eval $(call all-target,utils/testmake,utils/testmake/dummy_target)) utils/testmake/dummy_target: @echo Hello world! ---------------- Running make results in a "No rule to make target" error: $ make make -C ../.. all_utils/testmake make[1]: Entering directory '/home/ctimmons/ghc' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[2]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[2]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all_utils/testmake make[2]: *** No rule to make target 'all_utils/testmake'. Stop. make[1]: *** [Makefile:127: all_utils/testmake] Error 2 make[1]: Leaving directory '/home/ctimmons/ghc' make: *** [../../mk/sub-makefile.mk:50: all] Error 2 However, running ghc.mk directly from the utils/testmake folder does not result in an error: $ make -C ../.. -f utils/testmake/ghc.mk make: Entering directory '/home/ctimmons/ghc' Hello world! make: Leaving directory '/home/ctimmons/ghc' What am I not understanding? Thanks. Chris

2 2