June 2019 - ghc-devs - Haskell.org

RE: Hadrian: Suddenly a full build fails with: Rules may not be recursive
by Andrey Mokhov 23 Jun '19

23 Jun '19

Hi all, > I think this is because `--configure` is currently broken > https://gitlab.haskell.org/ghc/ghc/issues/16809. You can work around by > running bootstrap and configure manually for now. Here is a merge request with a fix: https://gitlab.haskell.org/ghc/ghc/merge_requests/1255 Cheers, Andrey

1 0

Hadrian: Suddenly a full build fails with: Rules may not be recursive
by Roland Senn 21 Jun '19

21 Jun '19

Hi, Suddenly I'm unable to build! As usual, I did: git pull upstream master --recurse-submodules=yes git submodule update --init --recursive $ hadrian/build.sh clean Up to date | Removing Hadrian files... | Remove directory _build/stage0 | Remove directory _build/stage1 | Remove directory _build/stage2 | Remove directory _build/stage3 | Remove directory sdistprep | Remove directory _build (after build completes) | Done. ... + statistics $ hadrian/build.sh -c --flavour=devel2 -j2 Up to date | Running boot... Error when running Shake build system: at action, called at src/Rules.hs:68:19 in main:Rules at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2- fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo pment.Shake.Internal.Rules.Oracle * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host- os")) at need, called at src/Hadrian/Oracles/TextFile.hs:90:9 in main:Hadrian.Oracles.TextFile * Depends on: hadrian/cfg/system.config at &%>, called at src/Rules/Configure.hs:21:5 in main:Rules.Configure * Depends on: hadrian/cfg/system.config mk/config.h compiler/ghc.cabal rts/rts.cabal at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.2- fca156899176fbf7a9b05f30b3ec991784b3e60af38a503ea1cb277fd96f971e:Develo pment.Shake.Internal.Rules.Oracle * Depends on: OracleQ (KeyValue ("hadrian/cfg/system.config","host- os")) * Raised the exception: Build system error - recursion detected: Key type: OracleQ KeyValue Key value: OracleQ (KeyValue ("hadrian/cfg/system.config","host- os")) Rules may not be recursive OS is Linux Debian 9 (x86_64) Any ideas what's wrong?? Many thanks and kind regards Roland

4 4

libraries/array bad git hash?
by Erik de Castro Lopo 21 Jun '19

21 Jun '19

Hi all, I just tried to clone a new copy of the GHC sources and on pulling the submodules i get: Fetched in submodule path 'libraries/array', but it did not contain 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit failed. I suspect that someone updated to that hash without pushing their changes to the public repo. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 2

ZuriHac 2019 - GHC Track
by Andreas Herrmann 13 Jun '19

13 Jun '19

Dear GHC devs, This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Continuous Integration / DevOps, by Manual Chakravarty - PrimOps / PrimTypes, by Michal Terepeta - Performance Regression Tests, by Niklas Hambüchen - Newcomers Tutorial, by Andreas Herrmann Other possible subjects could be around: - Improving documentation - Extending GHC's test-suite - General GHC development workflows - The inner workings of some aspect of GHC Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers. Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message. Best, Niklas and Andreas ZuriHac 2019 GHC track coordinators [1]: https://zfoh.ch/zurihac2019/

13 14

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 12 Jun '19

12 Jun '19

Dear Haskell community, the GHC Steering committee is seeking nominations for two or three new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until June 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Typed hole improvements
by David Feuer 07 Jun '19

07 Jun '19

I've been playing around with 8.6.3, and I've really been appreciating the improvements in typed hole messages. Both the information about constraints and the suggestions for filling the holes have proven valuable in heavily typish programming. Thanks! One thing that's still not where I'd like it to be is the equality constraint display. I recognize this is a Hard Problem. But digging through something like x ~ C y z x ~ C y1 z2 D p b ~ q z y1 to get b ~ y gets tiresome. Is there room for improvement here? If not, are there any programs around using the GHC API to offer an interactive system for such calculations? It'd be quite helpful when seeing such constraints to be able to express special interest in a particular type variable, for example.

2 1

reviewing on GitLab
by Richard Eisenberg 07 Jun '19

07 Jun '19

Hi all, I've just reviewed !364, and it was a painful experience. Perhaps documenting why will help spur more UI innovations. - My review was in response to several of the author's in-line comments, which themselves were in response to previous in-line comments. This has to be a common scenario. - The *only* place I could get a simple listing of all the new comments was in my notification email. Neither the Discussion tab nor the Changes tab on GitLab allow me to collect recent comments, as they new comments are placed directly below the old comments, each of which started at different points in time. - The Discussions tab has all the comments somewhere. But for each comment, I had to search (with Ctrl+F) on the page to find the corresponding comment trail, so I could get context. The order on the Discussions tab was unrelated to the order in my email. - Actually, not all comments were on the Discussions page, because the commit author had *resolved* a discussion. In this case, though, I still wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I could find the comment trail and unresolve it. - The Changes page has much more code context than the Discussions page. So I had that open, too, so I could scroll through the code. Not all the comments appeared on the Changes page, because the most interesting, most important files are always hidden by default. Even after expanding the relevant files, the comment trails did not always appear. Perhaps 30 seconds wasn't enough waiting. - All this means that this was my workflow: 1. Scroll through my notification email to see the author's next comment. 2. Ctrl+F with the text of that comment to find it on the Discussion tab. (Ctrl+F for "resolved" if the first search fails.) 3. If necessary, then use the line numbers and source file names from the Discussions tab to find the the relevant code in the Changes tab... which were often offset by a few lines, as things churn. I needed three windows open to complete a fairly simple review! I believe this is easy to fix: make the Discussions tab *chronological*. And have a link from the comment on the Discussions page to the Changes page that warps you to just the right spot in the code, with the full commentary context. (Right now, the link from the Discussions page just brings you to the file in the Changes page, not the line.) I know this isn't the first time we've suggested this or complained, but I'm not aware of progress (or even "it's on our queue") from GitLab. Has that happened? Is there a way to prioritize this? This review process is really a drag! Many thanks, Richard

3 5

Strange behavior of "-with-rtsopts=-T
by Vlatko Basic 07 Jun '19

07 Jun '19

Hello ghc-devs, I wrote about this issue to haskell-cafe, but received no reply as of today, so I'm hoping I could get some answer(s) here. I wrote a small Servant server that communicates with the same other server(s). When compiled without "-with-rtsopts=-T", I see in 'gnome-system-monitor' that memory used by each server constantly growing. I was investigating the issue, and found that it is (probably) not in my code, but in one http call (Servant client call to the same server). When I compile it with "-with-rtsopts=-T", the memory is constant and steady. Tested on Arch Linux with Stack LTS 13.14. If any one wants to test this, here are the steps: (server is standalone and does not require any external services (like DB, Redis, etc) and uses just a few MBs of RAM.) $ hg clone https://bitbucket.org/vlatkoB/poomas && cd poomas && stack build ## open your system monitor ## open two terminals in 'poomas' dir and in one run $ srvb.sh 5 ## and in the other # $ srvb.sh 6 ## (5 and 6 represent port number added to 3000, i.e. 3005 and 3006) ## Notice that memory is steady, around 6 MB on my machine. ## In 'server/package.yaml' comment out the line 139 (#-with-rtsopts=-T) $ stack build --force-dirty ## start those two servers again and see memory usage growing. Can anyone shed some light what could be happening here? Best regards, vlatko

2 2

Zurihac 2019 - Heap Profiling Projects
by Matthew Pickering 06 Jun '19

06 Jun '19

Hi all, I plan to do some work on the heap profiler during Zurihac this year. I've written down quite a long list of possible projects if anyone else wants to work on this with me. They are split into two categories. 1. Improving my replacement for hp2ps/hp2pretty which parses and renders eventlogs into an interactive HTML page. 2. General improvements to the heap profiler. https://gitlab.haskell.org/ghc/ghc/wikis/Zurihac-2019-Profiler-Ideas Feel free to add your own suggestions, as long as they are backed up by a ticket. Cheers, Matt

1 0

should TcCanonical.rewriteEvidence preserve ctev_nosh?
by Nicolas Frisby 05 Jun '19

05 Jun '19

A bit of context and then my question. https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcCanonic… declares `rewriteEvidence` with the comment that "rewriteEvidence old_ev new_pred co ... Returns a new_ev : new_pred, with same wanted/given/derived flag as old_ev". However, the `CtWanted` case just immediately calls `newWanted`, which ignores the incoming `ctev_nosh` flag and always uses `WDeriv`. ``` rewriteEvidence ev@(CtWanted { ctev_dest = dest , ctev_loc = loc }) new_pred co = do { mb_new_ev <- newWanted loc new_pred ``` (This is true in 8.6.5 and also right now at 6febc444c0abea6c033174aa0e813c950b9b2877.) Thus I'm seeing a [W] is become a [WD], which seems to contradict the comment's "same flag" claim. MY QUESTION ======> Is this "WD unsplitting" the intended behavior? See canonicalization tc-trace below. If it is intended, I'll probably write a follow-up question asking for more advice. The constraint solver is looping unproductively because my plugin keeps discarding the (re-)emitted [D] shadow as a tautology, then the [W] "unsplits" during canonicalization (even though my plugin didn't touch the [W]), this re-emits the same [D] (via a fundep), and so on. My continual disclaimer recently is that I'm seeing this behavior with my in-development plugin activated, so it's entirely I'm pushing GHC into unfamiliar waters or even just plain violating some invariants without realizing it. But this trace looks rather isolated from plugins. Thanks! -Nick Here's a -ddump-tc-trace of a canonicalization that goes from [W] to [WD] happen (with GHC 8.6.5): runStage canonicalization { workitem = [W] $dMonadFree_a35V {0}:: MonadFree ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]) (Free fs_a2UF[sk:1]) (CDictCan) flatten_args { (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1] Free fs_a2UF[sk:1] matchFamTcM Matching: (fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1] Match failed matchFamTcM Matching: fs_a2UF[sk:1] :- Const e_a2UE[sk:1] Match failed Unfilled tyvar fs_a2UF[sk:1] Unfilled tyvar e_a2UE[sk:1] flatten/flat-cache hit :- [* -> *, fs_a2UF[sk:1], Const e_a2UE[sk:1]] s_a35Z[fmv:1] Unfilled tyvar s_a35Z[fmv:1] Unfilled tyvar e_a2UE[sk:1] matchFamTcM Matching: s_a35Z[fmv:1] :+ Const e_a2UE[sk:1] Match failed New coercion hole: co_a365 Emitting new coercion hole {co_a365} :: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]) GHC.Prim.~# s_a364[fmv:1] extendFlatCache :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]] [WD] s_a364[fmv:1] flatten/flat-cache miss :+ [* -> *, s_a35Z[fmv:1], Const e_a2UE[sk:1]] s_a364[fmv:1] [WD] hole{co_a365} {0}:: (s_a35Z[fmv:1] :+ Const e_a2UE[sk:1]) GHC.Prim.~# s_a364[fmv:1] Unfilled tyvar fs_a2UF[sk:1] flatten } s_a364[fmv:1] Free fs_a2UF[sk:1] Emitting new wanted $dMonadFree_a366 :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1]) arising from a use of ‘wrap’ at tests/ill-typed/T7.hs:77:14-17 addTcEvBind a2V1 [W] $dMonadFree_a35V = $dMonadFree_a366 `cast` ((MonadFree (Sym {co_a365} ; ((:+) <* -> *>_N (Sym {co_a360}) <Const e_a2UE[sk:1]>_N)_N) <Free fs_a2UF[sk:1]>_N)_R :: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1]) ~R# MonadFree ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]) (Free fs_a2UF[sk:1])) canClass [W] $dMonadFree_a35V {0}:: MonadFree ((fs_a2UF[sk:1] :- Const e_a2UE[sk:1]) :+ Const e_a2UE[sk:1]) (Free fs_a2UF[sk:1]) MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1]) ContinueWith [WD] $dMonadFree_a366 {0}:: MonadFree s_a364[fmv:1] (Free fs_a2UF[sk:1]) end stage canonicalization } and later try_fundeps [WD] $dMonadFree_a36h {0}:: MonadFree s_a36f[fmv:1] (Free fs_a2UF[sk:1]) (CDictCan) emitFunDepDeriveds 1 0 [fs_a2UF[sk:1] ~ s_a36f[fmv:1]] False Emitting new derived equality [D] _ {0}:: fs_a2UF[sk:1] GHC.Prim.~# s_a36f[fmv:1] and then my plugin discards that [D] as a tautological, and then the [W] gets unsplit and the [D] comes back around etc

2 3