- ghc-devs - Haskell.org

Two weeks left for Haskell Exchange talk proposals
by Spiwack, Arnaud 29 May '19

29 May '19

Dear all, Only two weeks remain before the end of the Haskell eXchange call-for-paper (11th of june). Send your proposals! This year's keynote speaker will be Elise Huard, Gabriele Keller, Simon Peyton Jones, and Philip Wadler. Find the full CFP and submit your proposal here: https://docs.google.com/forms/d/e/1FAIpQLSeJgeTqAdYLBlRcO9PDzI3yrR22CqzhInH…

1 0

RE: Clean build fails with make
by Simon Peyton Jones 29 May '19

29 May '19

| Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. Excellent, that works. | I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. It may not matter. We don't want to spend lots of time on the old build system. Is this a once-only thing? I.e. once done will never happen again? Or might it happen repeatedly? Simon | -----Original Message----- | From: John Ericson <git(a)johnericson.me> | Sent: 28 May 2019 23:33 | To: Ben Gamari <ben(a)well-typed.com> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; GHC developers <ghc- | devs(a)haskell.org> | Subject: Re: Clean build fails with make | | This is the same issue as before; and I don't know how the cleaning works. | The good thing is that I think I am done adding things to that. (Perhaps | some should be removed, but that won't cause these issues.) | | Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. | | Sorry for more disruption, | | John | | On Tue, May 28, 2019, at 5:56 PM, Ben Gamari wrote: | > Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | > > A 'sh validate` in a clean tree fails as below. | > > Is that expected? That is, is validate dead? | > > If so let's change the shell script to say "game over, just use | > > Hadrian". | > > Simon | > | > John, it looks like this is more fallout from the recent platform | > changes. Any thoughts? | > | > Cheers, | > | > - Ben | > | > > "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: | > > | > > No entry for "target platform string" in | > > | > > "/home/simonpj/code/HEAD/inplace/lib/settings" | > > | > > 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 | > | > | > *Attachments:* | > * signature.asc

1 0

Clean build fails with make
by Simon Peyton Jones 28 May '19

28 May '19

A 'sh validate` in a clean tree fails as below. Is that expected? That is, is validate dead? If so let's change the shell script to say "game over, just use Hadrian". Simon "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: No entry for "target platform string" in "/home/simonpj/code/HEAD/inplace/lib/settings" 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

2 1

RE: newtype workers
by Simon Peyton Jones 28 May '19

28 May '19

| I'm working on unlifted newtypes. | | In MkId.mkDataConWorkId, I see | | > mkDataConWorkId wkr_name data_con | > | isNewTyCon tycon | > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info | > | otherwise | > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty alg_wkr_info | | Why is a newtype worker called a wrapper (DataConWrapId)? Note that some | newtype constructors have separate wrappers (which is relatively new). | This doesn't appear to be hurting anything right now, but it's odd, and | there's no commentary on this. That is indeed odd, I agree. Some points * Newtypes can have wrappers: see Note [Data con wrappers and GADT syntax] in MkId.hs * The "worker" for a newtype data constructor is just a function with a compulsory unfolding, of form (\x. x |> co), where co is the newtype coercion. * I agree that it's not right to describe the "worker" for a newtype data constructor as a "DataConWrapId"; after all, it may have a wrapper too (see previous bullet). * Bu not is it rigt to call it a regular DataConWorkId. Those are *data* constructors, head normal forms, very very special. The kosher thing would be to create a NewtypeWorkId. But that's seems a terrible fiddle, because these things are inlined compulsorily so they never exist for long. Maybe it should just be a vanilla Id. While there are a few places where we do test for data-con-wrap-ids -- eg in isImplicitId -- but remember that these things are inlined so aggressively that we will only see them very briefly. Or leave it as-is, with the above commentary as a Note -- that might be the easiest thing! Might you make a little patch? Simon | -----Original Message----- | From: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Sent: 25 May 2019 11:50 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: newtype workers | | Hi Simon, | | I'm working on unlifted newtypes. | | In MkId.mkDataConWorkId, I see | | > mkDataConWorkId wkr_name data_con | > | isNewTyCon tycon | > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info | > | otherwise | > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty alg_wkr_info | | Why is a newtype worker called a wrapper (DataConWrapId)? Note that some | newtype constructors have separate wrappers (which is relatively new). | This doesn't appear to be hurting anything right now, but it's odd, and | there's no commentary on this. | | Thanks, | Richard

1 0

Re: Processing MRs very slow?
by David Eichmann 28 May '19

28 May '19

Simon, your suggestion makes sense to me. We can have 3 pages that cover: 1. Fixing Bugs (/working-conventions/fixing-bugs) 2. Adding Features (/working-conventions/adding-features) 3. Merge request work-flow (New page e.g. (/working-conventions/merge-requests) Then (1) and (2) would reference (3) and most of the content in /home would be moved to (3). This leave one loose end: /home is left almost empty. I suggest we move contents of /contributing <https://gitlab.haskell.org/ghc/ghc/wikis/contributing> to /home, though I'm interested in hearing any alternative idea - David E On 5/23/19 12:24 PM, Simon Peyton Jones wrote: > > Thanks > > * I've noted this infixing-bugs <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> and linked tohome <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-… <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> andhttps://gitlab.haskell.org/ghc/ghc/wikis/home <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>) > > I agree with avoiding duplication, but let’s fix that by fixing the > home page. Why is there all this detail about merge requests there? > Let’s push all that off into a single integrated page “How to > contribute a patch”. > > The current “how to contribute a patch” page is really “how to fix a > bug (including how to contribute a patch)”. So maybe we should have: > > * How to fix a bug > * How to add a feature > > both as pages of their own, but both pointing to a single pate > > * The mechanics of contributing a patch (bug or feature) > > That would also de-clutter the home page. > > Simon > > *From:*David Eichmann <davide(a)well-typed.com> > *Sent:* 23 May 2019 12:10 > *To:* Simon Peyton Jones <simonpj(a)microsoft.com>; Ben Gamari > <ben(a)well-typed.com> > *Cc:* iavor.diatchki(a)gmail.com > *Subject:* Re: Processing MRs very slow? > > I found the email you're referring to > https://mail.haskell.org/pipermail/ghc-devs/2019-May/017656.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask…>. > You mentioned 3 points of missing information: > > * Picking approvers > * Lets see how the "gitlab upgrade - change in approval system" email thread develops. > * Assigning to Marge > * I've noted this infixing-bugs <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> and linked tohome <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-… <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> andhttps://gitlab.haskell.org/ghc/ghc/wikis/home <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>) > * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. > * I've added some info inhttps://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> > Hope this is better now. Ben maybe you'd like to double check the bullet list inhttps://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> for the conditions under which marge will batch your MR. > - David E > > On 5/23/19 9:02 AM, Simon Peyton Jones wrote: > > | | Perhaps it is worth updating Step 7 or 8 of > > Yes, I suggested that to Ben a week or two ago, but he's flat out on incremental GC. > > Maybe David could do it? I can dig out the email. > > Thanks! > > Simon > > | -----Original Message----- > > | From: ghc-devs<ghc-devs-bounces(a)haskell.org> <mailto:ghc-devs-bounces@haskell.org> On Behalf Of Iavor Diatchki > > | Sent: 22 May 2019 23:49 > > | To: David Eichmann<davide(a)well-typed.com> <mailto:davide@well-typed.com> > > | Cc: ghc-devs<ghc-devs(a)haskell.org> <mailto:ghc-devs@haskell.org> > > | Subject: Re: Processing MRs very slow? > > | > > | Great thanks! How can I have a look at Marge-bot's queue? > > | > > | Perhaps it is worth updating Step 7 or 8 of > > |https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > > | bugs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6 > > | df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&a > > | mp;sdata=gWoMbrHZwyfDQWeCst0VmAl4x%2Fv%2BjFY3dUXI7X%2FCHEQ%3D&reserved > > | =0 > > | to indicate that the reviewers should assign the MR to Marge-bot when it > > | is approved, and how one can check if that has happened. > > | > > | > > | On Wed, May 22, 2019 at 9:53 AM David Eichmann<davide(a)well-typed.com> <mailto:davide@well-typed.com> > > | wrote: > > | > > > | > Recently there have been some issues with CI that has slowed down > > | > merging. In particular a performance test (T9630) was failing on CI. > > | > That is fixed now and as of today Marge-Bot seems to be merging MRs > > | > again. I'll continue to monitor this in the coming days. > > | > > > | > Iavor, your MR was approved but not assigned to Marge-bot, and so was > > | > not in the merge queue. I'm not sure who has permission to do this, > > | > but you can always ping the approvers. In this case I've assigned to > > | > Marge-bot for you, and it will hopefully be merge soon. > > | > > > | > David Eichmann > > | > > > | > On 5/22/19 5:09 PM, Iavor Diatchki wrote: > > | > > Hello, > > | > > > > | > > I made a gitlab MR that adds two NOINLINE pragmas and some comments. > > | > > It's been about a week since my last push to the MR, and nothing has > > | > > happened since. > > | > > > > | > > Is there a way to check on what is its status: > > | > > - Is it stuck because I need to do something? > > | > > - Is it stuck because someone else needs to do something? > > | > > - Or is it just in the queue to be merged, in which case it would > > | > > be nice to know where in line it is, so I can see that there is > > | > > progress, and it is not just stuck. > > | > > > > | > > Given that this is such a simple MR, I am not too worried about > > | > > conflicts but a week long lag seems less than ideal for anything > > | > > even mildly complex. > > | > > > > | > > -Iavor > > | > > > > | > > PS: I just clicked on all the little check boxes from the > > | > > template---perhaps that's why things weren't progressing? > > | > > _______________________________________________ > > | > > ghc-devs mailing list > > | > >ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > | > >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai > > | > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02% > > | > > 7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6df07cbb3%7C > > | > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&sd > > | > > ata=W3wnIH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reser > > | > > ved=0 > > | > > > | > -- > > | > David Eichmann, Haskell Consultant > > | > Well-Typed LLP, > > | >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w > > | > ell-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773d > > | > d4c553d8c08d6df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 > > | > 941621907873036&sdata=RIcEblo4xNED7UY6Vv%2FNIG4aAzcjLgzN8uegqX9K%2 > > | > F3I%3D&reserved=0 > > | > > > | > Registered in England & Wales, OC335890 > > | > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > > | > > > | > _______________________________________________ > > | > ghc-devs mailing list > > | >ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > | >https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. > > | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01 > > | > %7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6df07cbb3%7C72f988 > > | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&sdata=W3wn > > | > IH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reserved=0 > > | _______________________________________________ > > | ghc-devs mailing list > > |ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > > |https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc0e7235773dd4c553d8c08d6 > > | df07cbb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941621907873036&a > > | mp;sdata=W3wnIH%2F2oEmuqona%2Fk6NtoYUZsnFA1kun%2Blm%2BSGMIjo%3D&reserv > > | ed=0 > > -- > David Eichmann, Haskell Consultant > Well-Typed LLP,http://www.well-typed.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

2 2

Re: Building GHC 8.4.3 Cross-Compiler Linux x86 -> Linux ARM
by Ben Gamari 28 May '19

28 May '19

Michael Dunn <michaelsdunn1(a)gmail.com> writes: > Ben, > > I saw that you responded to my question in #ghc on freenode last > weekend (mdunnio), and I missed your message. > Michael, I would be happy to help. I'm CCing ghc-devs so others may benefit from this discussion. > I'm trying to build a cross compiler using ghc 8.0.1 to build ghc > 8.4.3. You mentioned that you have experience. > > Have you tried on newer versions of GHC? I've looked at a few guides > (mostly https://gitlab.haskell.org/ghc/ghc/wikis/building/cross-compiling) > and they all are using pre-8.0. The problem I'm running into now just > seems to be that I can't build the base packages (ghc-pkg > specifically). > > My configure command is: > > ./configure --target=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc > --enable-unregisterised > This is helpful to know but you didn't specify what your `make` invocation looks like or your mk/build.mk. It would be very helpful to know both of these things. Presumably you at least had to set `HADDOCK_DOCS=NO` since otherwise the build system fails very early on. Cheers, - Ben

2 1

Is your MR failing CI test T9630 or haddock.base?
by David Eichmann 27 May '19

27 May '19

Try rebasing! Due to some unfortunate circumstances the performance tests (T9630 and haddock.base) became fragile. This should be fixed, but you need to rebase off of the latest master (at at least c931f2561207aa06f1750827afbb68fbee241c6f) for the tests to pass. Happy Hacking, David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

1 0

wiki page of notes for type checker plugin authors
by Nicolas Frisby 26 May '19

26 May '19

To: ghc-devs Cc: some plugin authors I'm aware of Today, I finally added a test that caused the type checker plugin I'm developing to fail because I'm ignoring the incoming Derived constraints. While investigating what exactly I should do with incoming Deriveds, I wrote up my notes in hopes they are helpful to other type checker plugin authors. https://gitlab.haskell.org/ghc/ghc/wikis/plugins/type-checker/notes It's a high-level summary of what the GHC constraint solver is doing, that dips down into the details a bit regarding Deriveds. I would really appreciate it if you'd check that page for errors andr glaring omissions. Also, is there a better location for it? It seemed too sprawling for a source `Note`. Thank you for your time. -Nick

1 0

Overloaded names for Map/Set?
by Andreas Klebinger 24 May '19

24 May '19

Hello devs, I would appreciate feedback on the idea in https://gitlab.haskell.org/ghc/ghc/merge_requests/934 Maps/Sets in GHC for the most part offer the same basic functionality but their interfaces differ. In order to make this easier to work with I propose using overloading via IsSet/IsMap classes. The goal is to make working with these data structures simpler by having a uniform interface when it comes to names and argument orders. There are downsides, but to me they seem minor. Error messages can be more confusing when one get's the types wrong. We have to import the class to use it and the like. However overall I think making code easier by not having to remember the naming scheme + argument order for the different possible instances would make this worthwhile. But GHC isn't my project but one of the community so please voice your opinion on the matter on the merge request! Cheers Andreas

4 3

Fwd: GHC | Hadrian: ld crashes linking HStime on macos (#16685)
by Shayne Fletcher 23 May '19

23 May '19

Hi Andrey, On Thu, May 23, 2019 at 10:04 AM Andrey Mokhov <gitlab(a)gitlab.haskell.org> wrote: > I've travelling all week, so can't look into this issue properly, but > can't we simply revert the commit that introduced the breakage? Looks like > it was committed just a week ago. > I'll have to defer to the approvers on this one - I'm just a reporter :) -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

1 0