- ghc-devs - Haskell.org

Old build system broken
by Simon Peyton Jones 09 May '19

09 May '19

I know we are supposed to be using Hadrian now, but is the old build system supposed to be broken? A clean build fails with "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an error: Failed to read "target arch" value "" libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 simonpj@MSRC-3645512:~/code/HEAD$

6 7

Is cleaning up old issues worthwhile?
by Kevin Buhr 08 May '19

08 May '19

I presume I can't be the first to ask this question, but I tried searching the ghc-devs archives and didn't find anything. After accidentally clicking on the sort order button in the GitLab issue list, I found myself browsing 18-year-old open issues that are clearly obsolete (e.g., #515 related to bad source location info in LHS files long since fixed, #517 which looks like a transient issue with error messages affecting HEAD in March 2001, #519 which refers to "ghc -M" reading "import" statements from comments which I tried and failed to duplicate. etc.). I would be interested in going through some of these and triaging and closing them where appropriate. But I also don't want to be "that guy" -- you know, the person who systematically works his or her way through the wiki boldfacing all occurrences of the word "GHC" or submits 1200 merge requests to remove doubled-space-after-period occurrences in comments. So, the first question is, would working on cleaning up these issues be useful, or would it generate too much noise to be worthwhile? Second, if it *is* useful, what sort of policy/procedure would be most helpful? There are a bunch of these issues that: * have gone many years without any non-administrative activity * have clear test cases that can't be duplicated with modern GHC * don't involve any apparent unresolved technical issues I'd be pretty comfortable adding a comment documenting my failure to duplicate them and then closing them. So, that might be a good first pass. Is there any reason *not* to simply comment and close them immediately? For example, I already closed #497 and #515 on this basis. Would it be better to comment on them, maybe tag them with a new label like "issue cleanup", and have a grace period before closing them? -- Kevin Buhr <buhr(a)asaurus.net>

6 10

MR titles
by Simon Peyton Jones 08 May '19

08 May '19

Friends In this MR<https://gitlab.haskell.org/ghc/ghc/merge_requests/908>, Vlad includes the number of the ticket it fixes in the title of the MR. That is so helpful: * It links the MR back to the issue * And does so in large font (screen shot below) * And the link is clickable, even in the title. I suggest we document this in our GHC-best-practice guide, and get everyone to do it. Would you agree Simon [cid:image001.jpg@01D50583.988DEB70]

3 3

Keeping track of issues
by Simon Peyton Jones 08 May '19

08 May '19

Ben I'm struggling to establish a clear understanding of the life cycle of an issue. Consider https://gitlab.haskell.org/ghc/ghc/issues/15872. Here is my faithfully recorded chain of thought at 2330 on a Tuesday night. * I can see that it is closed * But I wonder if it was fixed? * Well, scrolling up from the bottom, apparently it was mentioned in no fewer than six patches. That's odd. Why is this issue mentioned in six patches? * Oh, one of those six patches is a dup, mentioned twice. No idea why. * Are any of the five The Patch that is designed to fix this issue. Indeed does The Patch exist at all? And what MR is it in? * Oh, what is that MR? * Hmm. Well Ryan says "I've opened MR 851". Maybe that's it? * Let's head over to MR 851: https://gitlab.haskell.org/ghc/ghc/merge_requests/851 * Oh! It just says "Closed". I was hoping it'd say "merged", but no. * Uh oh. Near the top it says "Closed by Omer"... "the changes were not merged into master". * Then scrolling further down there is a lot of noise from Marge, followed by a presumably hand-written message from Omer saying "Merged as cc495d57</ghc/ghc/commit/cc495d5777c01ef62129df15caacf87b0e430c6b>.". * Huh. So maybe it did get merged after all. You can see how confused I am. It all just feels like much more work to find relevant info than it should be. It's frustrating because all the info is in the system, -- it's just hard (for me) to find. An issue should say prominently: this is The MR (or MRs) that fixes the issue. It should be easy to tell if those MR(s) have been successfully merged - along with their commit messages (this will come Moe Bot). Trac used to let you close a ticket as "fixed" or "wont-fix" or "invalid" etc. This was Jolly Useful. Doesn't Gitlab? Similarly, MRs sould be closed as "merged" or "abandoned". Much of this is not under your control - it's what GitLab does. But maybe we should have stronger best-practice guidelines. Eg "Never just close an issue; always say "Closing as won't fix" or...". etc. Simon

2 1

[ANNOUNCE] GHC 8.8.1-alpha1 is now available
by Ben Gamari 08 May '19

08 May '19

Hello everyone, The GHC team is pleased to announce the first alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha1 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release starts the pre-release cycle for GHC 8.8. This cycle is starting quite a bit later than expected due recent work on GHC's CI and release infrastructure. See the GHC Blog [2] for more on this. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-… [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html

3 2

Linear Types: ready for review
by Spiwack, Arnaud 07 May '19

07 May '19

Dear GHC devs, The linear types patch is ready for review! https://gitlab.haskell.org/ghc/ghc/merge_requests/852 It is a fairly large patch (~3500loc of change to the compiler itself, with a ~2000loc diff on the testsuite). And it's gone through a lot of redesigns. The issue with a patch like this is that it is rather easy to get reviewer fatigue and just let things through. This is why I want to encourage as many people as possible to give a thorough review of part of the patch. Even 15 minutes of your time would be tremendously helpful! Here is what I suggest: pick a part of the compiler you know well, and look at how the patch affects it. If there is something that you don't understand let us know! Either in the MR discussion, or send an email to Krzysztof and me. We will answer and update the documentation. --- If you are still unsure where to start, here are what we consider to be the main entry points to the patch: - The file Multiplicity, which defines type Mult = Type, the Scaled type and functions unrestricted, linear, pattern synonyms One and Omega, quick submultiplicity test submult - The change to FunTy and new mkFunTy in TyCoRep, where the multiplicity argument is added - The change to funTyCon in TysPrim - The new unrestrictedFunTyCon and multiplicityTy in TysWiredIn - Var has now a new field varMult; functions such as updateVarTypeAndMult can be used to update multiplicity (e.g. when zonking). In Core, the multiplicity of a lambda is indicated by its varMult; multiplicity of a case expression is indicated by varMult of the case binder. - The functions mkDataConRepXin basicTypes/MkId and and dataConUserType function in basicTypes/DataCon, which are adding multiplicity variables to constructors. The change to wrapper_reqd means that all data constructors have a wrapper now. - The file UsageEnv defines a map from a variable to its multiplicity, used when typechecking - Calls to submult and tcSubMult, which guide multiplicity checking in the type checker - ensureSubMult and its calls, which guide multiplicity checking in Lint --- A more in-depth documentation and overview of the patch is on the wiki: https://gitlab.haskell.org/ghc/ghc/wikis/linear-types/implementation It has a table of contents which you can use as yet another way to find a starting point. --- If any of these resources are lacking, let us know too! We'll make sure to update them. --- Finally, I'll be holding a project session on Linear Types in ZüriHac next month. Where we can have further, more in-depth discussion about the patch, finalise its documentation, and address outstanding requests from reviews.

4 5

Re: How do I find out which info table a continuation belongs to?
by Ömer Sinan Ağacan 02 May '19

02 May '19

Bumping thread, this is still a problem for me. I wonder if this ever worked. I should try this with older GHCs. Ömer Sergei Azovskov <lastg(a)fb.com>, 26 Şub 2019 Sal, 19:21 tarihinde şunu yazdı: > > Hey! > > Unfortunately, I'm not a big expert in gdb and debugging ghc runtime. I stripped some auto generated symbols from the symtab but they can still be found in dwarf section. I don't know how to force gdb to show them but you can manually check via dwarfdump. > ________________________________ > From: Ömer Sinan Ağacan <omeragacan(a)gmail.com> > Sent: Sunday, February 10, 2019 6:45 PM > To: Simon Marlow > Cc: ghc-devs; Sergei Azovskov > Subject: Re: How do I find out which info table a continuation belongs to? > > I'm already using -g3. Here's my build.mk: > > BuildFlavour = quick > > ifneq "$(BuildFlavour)" "" > include mk/flavours/$(BuildFlavour).mk > endif > > GhcRtsHcOpts += -O0 -g3 > SRC_HC_OPTS += -g3 > GhcStage1HcOpts += -g3 > GhcStage2HcOpts += -g3 > GhcLibHcOpts += -g3 > > STRIP_CMD = : > > Ömer > > Simon Marlow <marlowsd(a)gmail.com>, 10 Şub 2019 Paz, 19:00 tarihinde şunu yazdı: > > > > I believe this is due to https://urldefense.proofpoint.com/v2/url?u=https-3A__phabricator.haskell.or… > > > > (cc Sergei Azovskov) > > > > I'm a bit surprised that gdb isn't showing anything though, it should know that the address corresponds to a temporary symbol like `.L1234`. Perhaps you need to compile with -g to make this work, I'm not sure. > > > > On Sun, 10 Feb 2019 at 07:50, Ömer Sinan Ağacan <omeragacan(a)gmail.com> wrote: > >> > >> I'm currently working on a bug and one of the things I often want to know is > >> what's on the stack. The problem is I can't see labels of continuations so the > >> information is really useless. Example: > >> > >> >>> call printStack(((StgTSO*)0x42000e0198)->stackobj) > >> 0x42000c8788: RET_SMALL (0x512d70) > >> 0x42000c8790: RET_SMALL (0x40edf0) > >> stk[5] (0x42000c8798) = 0x7b3938 > >> 0x42000c87a0: CATCH_FRAME(0x735a98,0x7d3ff2) > >> 0x42000c87b8: STOP_FRAME(0x7311b8) > >> > >> (I modified the printer to print stack locations when printing stacks) > >> > >> Here I need to know which info table the RET_SMALLs return to. Normally I do > >> this for other kinds of closures: > >> > >> >>> print ((StgClosure*)...)->header.info > >> $15 = (const StgInfoTable *) 0x404dc0 <Main_nats_info> > >> > >> But for continuations that doesn't work: > >> > >> >>> print ((StgClosure*)0x42000c8788)->header.info > >> $11 = (const StgInfoTable *) 0x512d80 > >> >>> info symbol 0x512d80 > >> No symbol matches 0x512d80. > >> > >> Anyone know how to make this work? Can I maybe mark the continuations label in > >> the generated assembly somehow to make those labels available in gdb? > >> > >> Thanks > >> > >> Ömer > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs(a)haskell.org > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2D…

1 1

RE: ZuriHac 2019 - GHC Track
by Andrey Mokhov 01 May '19

01 May '19

Hi all, I am happy to help with Hadrian, perhaps giving an overview of the codebase and a quick demo covering typical use-cases. I'll generally be around to help with any build related issues, Hadrian hacking, etc. Note: I'm attending full days on Friday and Saturday, but on Sunday I may be available only in the morning. Cheers, Andrey ======================================= 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/

1 0

GHC HEAD documentation once again available
by Ben Gamari 01 May '19

01 May '19

TL;DR. A snapshot of GHC's documentation from the master branch can always be found at [2]. Hi everyone, Quite a while ago I made it a habit of periodically pushing documentation snapshots from GHC's master branch to downloads.haskell.org [1]. Unfortunately, despite some attempts at automating this process, this frequently grew out-of-date. I am happy to report that documentation snapshots are now generated as a product of GHC's CI process and made available here [2]. The old downloads.haskell.org URL redirects to [2] and consequently should now always be up-to-date. Let me know if you notice anything amiss. Cheers, - Ben [1] https://downloads.haskell.org/ghc/master/ [2] https://ghc.gitlab.haskell.org/ghc/doc/

4 6

GHC user manual
by Simon Peyton Jones 30 Apr '19

30 Apr '19

Where is the latest GHC user manual. I tried https://ghc.gitlab.haskell.org/ghc/doc/ but got a 502 failure. It would be good if it was easy to find the link from the developers home page https://gitlab.haskell.org/ghc/ghc/wikis/home Simon

2 4