- ghc-devs - Haskell.org

GitLab transition status
by Ben Gamari 22 Dec '18

22 Dec '18

Hello everyone, Over the past week we have been busily pushing ahead with the GitLab transition. While the original plan was to switch the upstream repository to the GitLab on last Tuesday, I have been too preoccupied pushing through the last mile of continuous integration stabilization to write the documentation that would make such a switch possible. Consequently, GitLab's ghc/ghc repository is still mirroring git.haskell.org. Continuous integration via GitLab pipelines is now very nearly green [1]. Once this happens I will send an email with final migration instructions and disable mirroring, signalling that the GitLab repository is the official upstream. After we migrate the upstream all code entering `master` will be merged via merge request, ensuring that no further breakage in CI. It would be greatly appreciated if those with commit rights could refrain from pushing unnecessary changes until the migration is finalized. I have had to fix a few breakages this week, each of which costs a few hours in effort and build time. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/pipelines/444

1 0

Notifications from GitLab
by Matthew Pickering 22 Dec '18

22 Dec '18

I am not receiving any emails from gitlab despite modifying the notification settings to indicate I want to be notified of all new diffs posted. Is anyone else getting notification emails? How can I debug this? Cheers, Matt

3 2

GitLab Migration
by Ara Adkins 21 Dec '18

21 Dec '18

Hey All, Sorry for my confusion, but I'm a bit unclear as to when we're meant to start working against the GHC repo on the gitlab.haskell.org instance. I had in mind that the cutover was intended to be the 18th, but going on there it still appears as if it's mirrored from git.haskell.org. Can somebody clarify this for me? Best, _ara

3 4

References for GHC usage of multiple capabilities
by Artem Pelenitsyn 20 Dec '18

20 Dec '18

Hello devs, I've been working on a short survey devoted to a topic of multithreading inside the GHC compiler and runtime. So far I was mostly looking at the following three papers [1] P. W. Trinder, K. Hammond, J. S. Mattson, Jr., A. S. Partridge, and S. L. Peyton Jones. Gum: A portable parallel implementation of Haskell. PLDI ’96 [2] Tim Harris, Simon Marlow, and Simon Peyton Jones. Haskell on a shared-memory multiprocessor. Haskell ’05 [3] Simon Marlow, Simon Peyton Jones, and Satnam Singh. Runtime support for multicore Haskell. ICFP ’09 Can you suggest any other papers adding insights on how GHC uses multiple capabilities for anything from GC to the implementation of Parallel/Concurrent Haskell? Perhaps, something more recent than the above, but preferably published in academic venues. The survey is meant to be of interest for systems folks. Therefore, I'm not paying so much attention to the programming model and how it is used in programs. -- Best wishes, Artem

4 5

GHC (API?) question: GHC Core for Base libraries
by Bill Hallahan 19 Dec '18

19 Dec '18

Hi, I'm writing a program analyzer that operates on GHC Core. Currently, I'm using the GHC API to get Core from .hs files. I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core. Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script. I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file. I was able to write the plugin successfully, and test it on several files that were not from the base library. Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin. I ended up with the following: GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself. With this I get an error message, which I have not been able to find a way to resolve: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o <command line>: not built for interactive use - can't load plugins (HPlugin.Plugin) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 So I'm now wondering (an answer to either of these two questions would be helpful): (1) Is this a viable path? That is, is it possible to use a plugin when building Base? If so, does anyone know what I might be doing wrong/what could be causing this error message? (2) Is there some other better/easier way I could get Core representations of the standard libraries? I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how? Thanks, Bill

4 8

GitLab migration status
by Ben Gamari 18 Dec '18

18 Dec '18

TL;DR. Given somewhat slower-than-expected progress on the Trac import I suggest that we implement a pared-down migration on Tuesday. See "The Plan" below. Hello everyone, Over the last few weeks we have been hard at work preparing the migration to GitLab. Currently the following things are ready: * Hosting of GHC's repositories and those of its mirrors have been prepared. * Continuous integration has been configured for GHC. All-in-all the GitLab migration has been quite timely since we were recently notified by CircleCI of billing changes which will soon make it quite difficult for us to continue using their services (see the thread on ghc-devops for details). Thankfully, moving CI to GitLab has been mostly painless and has even enabled us to introduce testing of platforms which were previously inaccessible to us under CircleCI. * The various linters which previously ran via `arc lint` and gitolite post-receive hooks have been ported to CI jobs. * The Trac ticket migration is looking good although there are still a significant number of details which need to be sorted out. * The Wiki migration is in a similar state. Over the past weeks we have been in constant contact with GitLab's FOSS outreach group, who have been quite helpful in getting the eyes of GitLab employees on the issues affecting our transition. Thanks to especially to David Planella for his help so far. Unfortunately, there is one issue in particular [1] which is currently blocking the Trac migration. From my discussions with GitLab's upstream it sounds like it may be possible for them to prioritize a fix in the short-term. However, our aggressive migration timeline is a fair bit faster than GitLab's development cycle and consequently this certainly won't happen before our planned migration on Tuesday. # The Plan Given what remains to be done in the Trac migration I believe it would be a mistake to move ahead with the full migration as planned. However, in the interest of re-gaining functional continuous integration of patches as soon as possible I propose that we move ahead with moving code review on Tuesday. The plan would be as follows: 1. We setup the final gitlab.haskell.org instance tomorrow; since the Trac migration will not be run will need to create new accounts on instance. 2. We begin officially accepting merge requests on this fresh GitLab instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will become GHC's official upstream repository. 3. We allow a week of transition time where new Differentials will continue to be accepted via Phabricator. 4. After this transition period we place Phabricator in read-only mode. 5. When we are confident in the Trac migration (likely after the new year) we move ahead with importing tickets and the wiki Previously I was skeptical of any plan that involved running the Trac migration against a live GitLab instance. However, further reflection I believe such a migration is safe and feasible. Moreover, given the constraints set upon us by the impending CircleCI changes, I think this is our best option to ensure continuity of CI. Thoughts? Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980

6 7

Windows failures
by Simon Peyton Jones 16 Dec '18

16 Dec '18

Tamar Things are getting better. Here's my list of testsuite failure on Windows, based on last night's HEAD. Still 16 failures. Simon Unexpected failures: plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) th/T10596.run T10596 [exit code non-0] (normal) th/TH_spliceE1.run TH_spliceE1 [exit code non-0] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal)

2 1

Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70)
by Sylvain Henry 15 Dec '18

15 Dec '18

Hi Ben, I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2ed…) Reviewers and subscribers to the phab diff are indicated in the commit message but not the author (here Ingo Blechschmidt "iblech"). I'm worried that if the Phabricator instance goes down we won't be able to retrieve commit authors. And also that they are not credited appropriately (cf git shortlog -sne). (By the way, I've also noticed that .mailmap contents isn't up to date: `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. Maybe you could add a check in a script somewhere to ensure that it stays empty when you push a commit?). Regards, Sylvain -------- Forwarded Message -------- Subject: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) Date: Sat, 15 Dec 2018 00:49:47 +0000 (UTC) From: git(a)git.haskell.org Reply-To: ghc-devs(a)haskell.org To: ghc-commits(a)haskell.org Repository : ssh://git@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/a1c0b70638949a73bbd404c11797f2edf… > --------------------------------------------------------------- commit a1c0b70638949a73bbd404c11797f2edf28f5965 Author: Ben Gamari <ben(a)smart-cactus.org> Date: Fri Dec 14 11:10:56 2018 -0500 Use https links in user-facing startup and error messages I consider myself lucky that in my circle of friends, `http` urls (as opposed to `https` urls) are frowned upon in that we generally apologize in the rase cases that we share an `http` url. This pull request changes `http` links into their `https` analogues in the following places: * In the GHCI startup message (and parts of the User's Guide, where there are verbatim transcripts of GHCi sessions). * In a couple of error messages, asking the user to report a bug. (I also took the liberty to change a single space before the reportabug url into two spaces, harmonizing this occurence with the others.) I'm not trying to start a war. I just had a moment to spare and felt like preparing this diff. Merge or don't merge as you wish! Reviewers: bgamari, erikd, simonmar Subscribers: goldfire, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5450 > --------------------------------------------------------------- a1c0b70638949a73bbd404c11797f2edf28f5965 compiler/typecheck/TcTyClsDecls.hs | 2 +- compiler/utils/Panic.hs | 2 +- docs/users_guide/ghci.rst | 4 ++-- ghc/GHCi/UI.hs | 2 +- rts/RtsMessages.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index cc9779a..71899a1 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -3609,7 +3609,7 @@ checkValidRoles tc report_error doc = addErrTc $ vcat [text "Internal error in role inference:", doc, - text "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"] + text "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug"] {- ************************************************************************ diff --git a/compiler/utils/Panic.hs b/compiler/utils/Panic.hs index 03f095b..4f0f3b1 100644 --- a/compiler/utils/Panic.hs +++ b/compiler/utils/Panic.hs @@ -168,7 +168,7 @@ showGhcException exception showString "panic! (the 'impossible' happened)\n" . showString (" (GHC version " ++ cProjectVersion ++ " for " ++ TargetPlatform_NAME ++ "):\n\t") . s . showString "\n\n" - . showString "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n" + . showString "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n" throwGhcException :: GhcException -> a diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst index 49a96ca..f468e80 100644 --- a/docs/users_guide/ghci.rst +++ b/docs/users_guide/ghci.rst @@ -37,7 +37,7 @@ command ``ghci``: .. code-block:: none $ ghci - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Prelude> There may be a short pause while GHCi loads the prelude and standard @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: .. code-block:: none $ ghci -package readline - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package readline-1.0 ... linking ... done. Prelude> diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs index ae8ba02..13275f8 100644 --- a/ghc/GHCi/UI.hs +++ b/ghc/GHCi/UI.hs @@ -162,7 +162,7 @@ defaultGhciSettings = ghciWelcomeMsg :: String ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ - ": http://www.haskell.org/ghc/ :? for help" + ": https://www.haskell.org/ghc/ :? for help" ghciCommands :: [Command] ghciCommands = map mkCmd [ diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c index 053805e..a90962e 100644 --- a/rts/RtsMessages.c +++ b/rts/RtsMessages.c @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) #endif fprintf(stderr, "\n"); fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, xstr(HostPlatform_TYPE)); - fprintf(stderr, " Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n"); + fprintf(stderr, " Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n"); fflush(stderr); } #if defined(mingw32_HOST_OS) _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

4 5

Re: Better perf
by Sebastian Graf 14 Dec '18

14 Dec '18

Hey, when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html. Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`. It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC. Just wanted to record this here for posterity. Cheers Sebastian Hi, > > Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via > ghc-devs: > >* > But: binary-trees runtime increases by 5%. > *> >* David: might you look to see if there is any obvious reason for this > *>* regression? We could just accept it, but it's always good to know > *>* why, and to document it. > * > Turns out that my commit > Add rule mapFB c (λx.x) = c > fixed that regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb… > > Maybe there is just a performance cliff there, and these jumps don’t > really mean anything. > > Greetings, > Joachim > >

1 0

Post-spec optimisation, wen and where
by Gabor Greif 13 Dec '18

13 Dec '18

Hi devs, I am wondering where the optimisation (e.g. simplified) of specialised dictionaries is taking place. In my case -ddump-spec shows unoptimised, but -ddump-simpl-iterations shows already optimised dictionaries (float-out already happened). I searched yesterday, but to no avail. Thanks, Gabor

2 2