- ghc-devs - Haskell.org

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

DoAndIfThenElse
by Harendra Kumar 22 Feb '18

22 Feb '18

Hi, I recently found a mention of DoAndIfThenElse extension somewhere. I looked inside the ghc user guide and could not find any such extension. Then I looked in the ghc man page, no mention. I googled and found a very sparse references to it here and there. Then I tried using the extension with ghc and ghc seems to accept it. What's the story behind this, why is it not documented but accepted? thanks, harendra

5 6

A (late-)demand analysis and w/w question
by Ömer Sinan Ağacan 21 Feb '18

21 Feb '18

Hi, I was recently looking at #6087. One of the cases that increased allocations (see comment:27) is when we do worker/wrapper to pass an `Int#` instead of `Int` when we need the boxed form in the function body. This causes redundant allocations because we already have the boxed version of the value but we passed it unboxed as a result of worker/wrapper. This raises the obvious (but maybe naive?) question of whether we could improve the demand analysis and/or worker/wrapper to avoid unpacking arguments when the argument is boxed again somewhere in the function body. Does this make sense? Has anyone tried this before? Thanks, Ömer

2 3

Re: [GHC DevOps Group] Release policies
by Boespflug, Mathieu 19 Feb '18

19 Feb '18

Hi Herbert, On 18 December 2017 at 12:22, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hi Mathieu, > > On Mon, Dec 18, 2017 at 12:03 PM, Boespflug, Mathieu <m(a)tweag.io> wrote: >> it's worth thinking about asking that >> the versions of all upstream packages only make it into GHC, at the >> behest of their respective maintainers, after a new release of >> upstream is made. > > Let me try to formulate the invariant such a procedure would demand: > > That would require a guarantee that the APIs provided by GHC (mostly > ghc-prim/base, but possibly more, including other boot libs; as well > as GHC's own behaviour) my package(s) rely upon are frozen to the > point that any such release of my packages advertising compatiblity > with the imminent GHC release will remain compatible with said final > GHC release. > > Is this something you're ready to guarantee? That's exactly it: a tradeoff. As you note, any package release now can't possibly anticipate all changes in future GHC. Furthermore, if a new GHC feature crucially depends on upstream but no upstream release is available yet, under this proposal merging the new GHC feature would need to be delayed. But on the other hand, if indeed GHC is to have more frequent releases, we can't have a GHC release perennially held up by upstream maintainers cutting their own releases one after the other, or worse still, releases happening *after* it already shipped in GHC as we just saw, or with breaking changes not announced to downstream tooling authors ahead of time. This is a problem that was brought up by Ben at ICFP, and again here. It's a problem relevant to the discussion at hand, which started as the result of upstream releases showing up on Hackage long after the release, and downstream tooling authors not afforded any advance notice to adapt. When this was brought up at ICFP, several GHC DevOps Group members recommended to Ben that he avoid needing *any* cooperation from upstream maintainers on the critical path towards a release. Of the packages you mention, base can't introduce breaking changes without a grace period. Are any upstream packages that closely tied to ghc-prim etc that a breaking change in the latter is likely between feature freeze and the release date? On the off-chance that a BC change does happen, package releases are cheap, so would that really be a problem? If a package is that closely tied to ghc-prim, base or any other boot lib, and conversely GHC is closely tied to it, then shouldn't that package just be part of the GHC codebase proper, rather than managed separately outside of GHC devs' control?

6 9

testsuite failures in DEBUG
by Richard Eisenberg 14 Feb '18

14 Feb '18

Hi devs, It seems our CI infrastructure has become too good. My workflow normally involves working with a DEBUG compiler, and then occasionally running the whole testsuite. I don't validate from scratch mid-patch, but it's good to know if I'm failing tests. With HEAD, I'm getting quite a few testsuite failures, and they all seem to be coming from ASSERTs, and they're all problems that I'm pretty sure I didn't cause. My full list of failures (I'm on Mac) is below, but after looking into 5-6 of them and finding only stuff that isn't my fault, I've given up. So: would it be possible to have our CI infrastructure validate DEBUG mode as well? Then it would be easy to spot where these failures are from. backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) cabal/T12733/T12733.run T12733 [bad stderr] (normal) cabal/cabal01/cabal01.run cabal01 [bad stderr] (normal) cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) dependent/should_compile/T12442.run T12442 [exit code non-0] (normal) dependent/should_compile/T12176.run T12176 [exit code non-0] (normal) driver/T3007/T3007.run T3007 [bad stderr] (normal) gadt/T12087.run T12087 [stderr mismatch] (normal) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) indexed-types/should_fail/T13877.run T13877 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail0.run NumericUnderscoresFail0 [stderr mismatch] (normal) parser/should_fail/NumericUnderscoresFail1.run NumericUnderscoresFail1 [stderr mismatch] (normal) patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) polykinds/T14174a.run T14174a [exit code non-0] (normal) printer/T13050p.run T13050p [bad exit code] (normal) safeHaskell/check/pkg01/safePkg01.run safePkg01 [bad stderr] (normal) simplCore/should_compile/T13025.run T13025 [bad stderr] (normal) simplCore/should_compile/T13410.run T13410 [exit code non-0] (normal) typecheck/T13168/T13168.run T13168 [bad stderr] (normal) typecheck/bug1465/bug1465.run bug1465 [bad stderr] (normal) typecheck/should_compile/holes2.run holes2 [exit code non-0] (normal) typecheck/should_compile/valid_substitutions.run valid_substitutions [exit code non-0] (normal) typecheck/should_compile/holes3.run holes3 [stderr mismatch] (normal) typecheck/should_compile/holes.run holes [stderr mismatch] (normal) typecheck/should_compile/T13050.run T13050 [exit code non-0] (normal) typecheck/should_compile/T13822.run T13822 [exit code non-0] (normal) typecheck/should_compile/T14590.run T14590 [exit code non-0] (normal) typecheck/should_compile/T13032.run T13032 [stderr mismatch] (normal) typecheck/should_fail/T7175.run T7175 [stderr mismatch] (normal) Thanks! Richard

3 3

Looking for GSoC Mentor
by Andreas Klebinger 14 Feb '18

14 Feb '18

Hello Everyone, I'm looking for a mentor for a GSoC Project/Proposal. The whole idea revolves around: * Getting hot path information from static analysis and user annotations. * Making sure it's not destroyed by optimization passes. * Using it to generate better code where applicable. See also: #14672: Make likelihood of branches/conditions available throughout the compiler. Towards these goals I would like for GSoC: * Land https://phabricator.haskell.org/D4327(Branchweights in STG and Cmm) + It might be ready before then. But it's a prerequisite so worth listing here. * Design and implement a way for users to: + Mark hot paths in Haskell code. + Push the information through the passes (up to STG) on a best effort basis. STG and beyond is part of the diff above. + The current backend already uses this information in some places, so this alone should lead to small but consistent gains. + I don't plan to add additional optimizations unless there is time left at the end. Where I think I will need help/experience from a mentor is: * Frontend questions: I haven't looked at GHC's parser/renamer yet so while this is surmountable I expect some questions to arise there. * Design questions/feedback: Things like: + How should the user be able to give this information. + What should be flag controlled? What always on? + Things like compile time/executable speed tradeoffs. ... * Potentially the simplifier: I've looked into it briefly as originally D4327 was aimed at the core stage instead of stg. There doesn't seem to be a lot that could mess with hot path information/branchweights. But I haven't worked on the simplifier before and it seems like a good place for unexpected issues to arise. * If this involves the proposal process then also guidance there. For myself: * I'm studying at TU Vienna (Software & Information Engineering) and am close to finishing my undergrad. Located in Austria (UTC+1) * I have contributed a few small changes to GHC throughout last year. See AndreasK on Phab/Trac. * If you want to know more contact me! If you are interested in mentoring me or looking for more details feel free to contact me at klebinger.andreas(a)gmx.at <mailto:klebinger.andreas@gmx.at>or look for AndreasK in #ghc Best Regards Andreas

1 0

User constructed types with new Data.Typeable and Data.Reflection
by Development 13 Feb '18

13 Feb '18

Hey guys I have a (hopefully quick) question. With the new `Data.Typeable` and `Data.Reflection` in base 4.10 have we really lost the ability for users to compose `TypeRep`’s? I was using `Data.Typeable` before (mainly `mkTyConApp`). But in the new base 4.10 I cannot find any way to achieve the same goal. I have read the wiki page Typeable and Typeable/BenGamari and neither explicitly mentions the removal of `mkTyConApp` and similar facilities. In fact the latter mentions potential implementations for user constructed type applications twice with `mkTrApp` at the beginning of the page and `mkApp` at the end. Furthermore the documentation for `Typeable` (and `Reflection`) also never mentions the fact that this functionality was removed. My question is this: Is this intentional? Is there now a consensus that there should not be user constructed types? Or is there some subtile issue that I’m missing wich prevents user constructed types for now or always? Thanks in advance guys. Best regards. Justus

3 4

Re: [Haskell-cafe] GHC 8.2.2 for WSL Ubuntu 16.04
by Herbert Valerio Riedel 13 Feb '18

13 Feb '18

Hello *, Even though WSL may eventually address this issue for good, I've setup a new WSL-optimised flavour of my PPA for Ubuntu 16.04 LTS https://launchpad.net/~hvr/+archive/ubuntu/ghc over at https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl I don't have experience myself with Ubuntu on WSL, but it should be simply a matter of using sudo add-apt-repository ppa:hvr/ghc-wsl sudo apt-get update and then sudo apt-get install ghc-8.2.2-prof cabal-install-head Then simply add `/opt/ghc/bin` to your `$PATH` (see instructions at https://launchpad.net/~hvr/+archive/ubuntu/ghc ) There are also builds of GHC 8.0.2 and GHC 8.4.1-alpha (may still be building as of writing) in this new ghc-for-wsl PPA. I'd appreciate if somebody could test whether these GHC binaries work as intended on the non-insider Windows 10 builds and let me know. Cheers, Herbert On Tue, Feb 13, 2018 at 12:21 PM, Yitzchak Gale <gale(a)sefer.org> wrote: > I wrote: >>> I have made available a build of GHC 8.2.2 with the config option: >>> --disable-large-address-space >>> [2] https://github.com/Microsoft/WSL/issues/1671 > > Shao Cheng wrote: >> Thank you! A simpler fix for WSL ghc users is upgrading to fast ring of >> insider builds, the mmap overhead is much lower and ghc startup lag is >> barely noticable. > > Thanks, that's good news. I can't use an insider build - I need to be on > standard Windows in order to support our customers. The latest reports > in the GitHub issue seemed to indicate that the slowness is still quite > significant even on insider builds. I'm glad to hear you say that this is no > longer true. I am looking forward to regular GHC binary tarballs working > normally on regular WSL sometime in the near future. > > Yitz > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0