From omeragacan at gmail.com Wed May 1 06:05:46 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 1 May 2019 09:05:46 +0300 Subject: ZuriHac 2019 - GHC Track In-Reply-To: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> References: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> Message-ID: I'll also be there and I'd be happy to help with general GHC development or more specifically RTS or STG parts of the compiler. Ömer Richard Eisenberg , 30 Nis 2019 Sal, 19:43 tarihinde şunu yazdı: > > I'm also happy to lead a session on GHC. I could perhaps give a high-level overview (no slides, just whiteboard & projected code) on the GHC compilation pipeline. I don't expect it would be terribly hands-on, though I would hope to get lots of questions from the audience. This might most easily come before Simon's presentation, which would doubtless be more detailed. > > I'm happy to assist others in their hacking efforts, too. > > I'll be around Fri - Sun. > > Richard > > On Apr 23, 2019, at 12:51 PM, Andreas Herrmann wrote: > > 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/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Wed May 1 07:50:39 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 May 2019 07:50:39 +0000 Subject: ZuriHac 2019 - GHC Track In-Reply-To: References: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> Message-ID: I’d be happy to help with anything GHC-related. I’ll take the advice of the ZuriHac organisers (Jesper, Andreas) about what would be best; but probably mail on this list would be a good way to gather ideas Simon From: ghc-devs On Behalf Of Siddharth Bhat Sent: 30 April 2019 18:17 To: Richard Eisenberg Cc: GHC developers ; Niklas Hambüchen Subject: Re: ZuriHac 2019 - GHC Track I'm not sure if this is the right place, but I'm putting this out there at any rate: I'd be interested in a deep dive into STG and related shenanigans "within the compiler", since my understanding is that a decent amount has changed since the last paper on STG (eval/apply). This is out of an interest in understanding STG as-it-lives within GHC so I can get back to simplexhc(https://github.com/bollu/simplexhc), a pet project of mine. I meant to take some time and read through the GHC internals in this area, but college coursework does not really facilitate deep meditation about the GHC codebase ;) Would someone be willing to help with this? Thanks, ~Siddharth On Tue, Apr 30, 2019 at 10:13 PM Richard Eisenberg > wrote: I'm also happy to lead a session on GHC. I could perhaps give a high-level overview (no slides, just whiteboard & projected code) on the GHC compilation pipeline. I don't expect it would be terribly hands-on, though I would hope to get lots of questions from the audience. This might most easily come before Simon's presentation, which would doubtless be more detailed. I'm happy to assist others in their hacking efforts, too. I'll be around Fri - Sun. Richard On Apr 23, 2019, at 12:51 PM, Andreas Herrmann > wrote: 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/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Wed May 1 08:14:27 2019 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Wed, 1 May 2019 10:14:27 +0200 Subject: ZuriHac 2019 - GHC Track In-Reply-To: References: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> Message-ID: I'd be interested in the STG, RTS, PrimOp semantics. It would be helpful for my ghc-grin project, which is a (work in progress) whole program optimizer backend for GHC. On Wed, May 1, 2019 at 9:51 AM Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > I’d be happy to help with anything GHC-related. I’ll take the advice of > the ZuriHac organisers (Jesper, Andreas) about what would be best; but > probably mail on this list would be a good way to gather ideas > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Siddharth > Bhat > *Sent:* 30 April 2019 18:17 > *To:* Richard Eisenberg > *Cc:* GHC developers ; Niklas Hambüchen < > niklas at nh2.me> > *Subject:* Re: ZuriHac 2019 - GHC Track > > > > I'm not sure if this is the right place, but I'm putting this out there at > any rate: > > > > I'd be interested in a deep dive into STG and related shenanigans "within > the compiler", since my understanding is that a decent amount > > has changed since the last paper on STG (eval/apply). This is out of an > interest in understanding STG as-it-lives within GHC so I can get back to > > simplexhc(https://github.com/bollu/simplexhc > ), > a pet project of mine. > > > > I meant to take some time and read through the GHC internals in this area, > but college coursework does not really facilitate deep meditation > > about the GHC codebase ;) > > > > Would someone be willing to help with this? > > > > Thanks, > > ~Siddharth > > > > On Tue, Apr 30, 2019 at 10:13 PM Richard Eisenberg > wrote: > > I'm also happy to lead a session on GHC. I could perhaps give a high-level > overview (no slides, just whiteboard & projected code) on the GHC > compilation pipeline. I don't expect it would be terribly hands-on, though > I would hope to get lots of questions from the audience. This might most > easily come before Simon's presentation, which would doubtless be more > detailed. > > > > I'm happy to assist others in their hacking efforts, too. > > > > I'll be around Fri - Sun. > > > > Richard > > > > On Apr 23, 2019, at 12:51 PM, Andreas Herrmann wrote: > > > > 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/ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Wed May 1 12:51:15 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 1 May 2019 21:51:15 +0900 Subject: GHC HEAD documentation once again available In-Reply-To: <87zhpbhnfh.fsf@smart-cactus.org> References: <87zhpbhnfh.fsf@smart-cactus.org> Message-ID: Hi, > The old downloads.haskell.org URL redirects to [2] and consequently should now always be up-to-date. > [2] https://ghc.gitlab.haskell.org/ghc/doc/ For the following URL, CDN or something seems to be a problem: https://ghc.gitlab.haskell.org/ghc/doc/ It is displayed for the following: "502 Bad Gateway". The build of the document on gitlab seems to be successful. For instance: https://gitlab.haskell.org/ghc/ghc/-/jobs/72818 (I am not in a hurry.) Regards, Takenobu On Sun, Mar 31, 2019 at 9:56 AM Ben Gamari wrote: > > 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/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andrey.mokhov at newcastle.ac.uk Wed May 1 13:24:08 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Wed, 1 May 2019 13:24:08 +0000 Subject: ZuriHac 2019 - GHC Track References: Message-ID: 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu May 2 13:18:22 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 2 May 2019 16:18:22 +0300 Subject: How do I find out which info table a continuation belongs to? In-Reply-To: References: Message-ID: Anyone know where should I be looking at to improve this? I found one workaround which is painful and does not work if you don't have the asm dumps already, but basically if you can find the current location in the program in the assembly dump you can find the map the symbols manually. E.g. I see this in gdb: 0x0000000000405115 Main_main1_info+101 movq $0x405058,-0x10(%r12) 0x000000000040511e Main_main1_info+110 mov %rbx,(%r12) 0x0000000000405122 Main_main1_info+114 mov $0x8c7a9a,%edi in the asm dump this code is shown as movq $sat_s6gH_info,-16(%r12) movq %rbx,(%r12) movl $True_closure+2,%edi Once I found the code in the asm dump I can map addresses to symbols 0x405058 -> sat_s6gH_info 0x8c7a98 -> True_closure Ömer Ömer Sinan Ağacan , 24 Nis 2019 Çar, 12:58 tarihinde şunu yazdı: > > 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 , 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 > > 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 , 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.org_D4722&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kdITsLFp8oDGMKQlc9eIzA&m=TC61xap_n2utc37GJd4nKe0d_swgwMyqoHVKekcPDZk&s=I_8-wOL9DBs5msIWONBC1IwDvNFG-rXrOgrXVhBqt6Q&e= > > > > > > (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 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 > > >> > > >> 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 at haskell.org > > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2Dbin_mailman_listinfo_ghc-2Ddevs&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kdITsLFp8oDGMKQlc9eIzA&m=TC61xap_n2utc37GJd4nKe0d_swgwMyqoHVKekcPDZk&s=OIXAtMjQkAnHAverwOpWQrKM1GIy-Eo85s3wxcnOqfU&e= From arnaud.spiwack at tweag.io Fri May 3 09:52:09 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 3 May 2019 11:52:09 +0200 Subject: Linear Types: ready for review Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buhr at asaurus.net Sat May 4 17:35:23 2019 From: buhr at asaurus.net (Kevin Buhr) Date: Sat, 4 May 2019 12:35:23 -0500 Subject: Is cleaning up old issues worthwhile? Message-ID: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandreR_B at outlook.com Sat May 4 18:35:19 2019 From: alexandreR_B at outlook.com (Alexandre Rodrigues) Date: Sat, 4 May 2019 18:35:19 +0000 Subject: Is cleaning up old issues worthwhile? In-Reply-To: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: That sounds like a great idea. The more people we have doing that, the better! In my opinion, doing this > adding a comment documenting my failure to duplicate them and then closing them. would work, although perhaps creating a new issue label for very old issues and first tagging them with it to notify all involved of their possibly imminent closure would be a nice first step. As you said, these issues may no longer be relevant for different reasons each, so it’d be good to document which it is. ________________________________ From: ghc-devs on behalf of Kevin Buhr Sent: Saturday, May 4, 2019 6:35:23 PM To: ghc-devs at haskell.org Subject: Is cleaning up old issues worthwhile? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sat May 4 19:14:20 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 4 May 2019 20:14:20 +0100 Subject: Is cleaning up old issues worthwhile? In-Reply-To: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: A bug sweep like this is very valuable so thank you for starting to do it. Labelling older issues is also very useful. If you are going to doing this a lot then you might be interested in the TUI I wrote to browse gitlab issues which makes traversing the issue list more ergonomic. https://github.com/mpickering/gitlab-triage Cheers, Matt On Sat, May 4, 2019 at 6:35 PM Kevin Buhr wrote: > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From buhr at asaurus.net Sat May 4 21:31:38 2019 From: buhr at asaurus.net (Kevin Buhr) Date: Sat, 4 May 2019 16:31:38 -0500 Subject: Is cleaning up old issues worthwhile? In-Reply-To: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: Okay, I've added a new "obsolete" label:  "Old issues that no longer apply and are in a short waiting period before closing."  I'll start going through the low-hanging fruit adding comments and sticking this label on them, with the idea of going back and closing them after, say, 4 weeks with no complaints.  After I've gone through a few of these and gained some experience with it, I'll try to draft some guidelines for handling old tickets. Anyway, please let me know if this process starts to get irritating. -- Kevin Buhr From matthewtpickering at gmail.com Sat May 4 21:56:49 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 4 May 2019 22:56:49 +0100 Subject: Is cleaning up old issues worthwhile? In-Reply-To: References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: I'm not sure the benefit of marking these tickets obsolete is. You may as well just close them. Someone can reopen them if they disagree. There could be some arguent for adding tests from these old tickets but tbh they are so old that if the bug still exists there is probably a newer ticket. On Sat, May 4, 2019 at 10:31 PM Kevin Buhr wrote: > > Okay, I've added a new "obsolete" label: "Old issues that no longer > apply and are in a short waiting period before closing." I'll start > going through the low-hanging fruit adding comments and sticking this > label on them, with the idea of going back and closing them after, say, > 4 weeks with no complaints. After I've gone through a few of these and > gained some experience with it, I'll try to draft some guidelines for > handling old tickets. > > Anyway, please let me know if this process starts to get irritating. > > -- > Kevin Buhr > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From buhr at asaurus.net Sat May 4 22:01:21 2019 From: buhr at asaurus.net (Kevin Buhr) Date: Sat, 4 May 2019 17:01:21 -0500 Subject: Is cleaning up old issues worthwhile? In-Reply-To: References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: Okay, sounds fine.  Maybe I'll use "obsolete" when I'm <95% sure it should just be closed.  When you suggested there was benefit in labelling older issues, what sort of labelling were you thinking of?  Adding existing triage-style labelling, like "bug" and/or the appropriate subsystem for the bugs that are still relevant? On 5/4/19 4:56 PM, Matthew Pickering wrote: > I'm not sure the benefit of marking these tickets obsolete is. You may > as well just close them. Someone can reopen them if they disagree. > > There could be some arguent for adding tests from these old tickets > but tbh they are so old that if the bug still exists there is probably > a newer ticket. > -- Kevin Buhr From alexandreR_B at outlook.com Sat May 4 22:04:38 2019 From: alexandreR_B at outlook.com (Alexandre Rodrigues) Date: Sat, 4 May 2019 22:04:38 +0000 Subject: Is cleaning up old issues worthwhile? In-Reply-To: References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> , Message-ID: They can be closed outright, but marking them with obsolescence is still useful for future reference, and is negligible. ________________________________ From: ghc-devs on behalf of Matthew Pickering Sent: Saturday, May 4, 2019 10:56:49 PM To: Kevin Buhr Cc: GHC developers Subject: Re: Is cleaning up old issues worthwhile? I'm not sure the benefit of marking these tickets obsolete is. You may as well just close them. Someone can reopen them if they disagree. There could be some arguent for adding tests from these old tickets but tbh they are so old that if the bug still exists there is probably a newer ticket. On Sat, May 4, 2019 at 10:31 PM Kevin Buhr wrote: > > Okay, I've added a new "obsolete" label: "Old issues that no longer > apply and are in a short waiting period before closing." I'll start > going through the low-hanging fruit adding comments and sticking this > label on them, with the idea of going back and closing them after, say, > 4 weeks with no complaints. After I've gone through a few of these and > gained some experience with it, I'll try to draft some guidelines for > handling old tickets. > > Anyway, please let me know if this process starts to get irritating. > > -- > Kevin Buhr > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From buhr at asaurus.net Sat May 4 22:49:28 2019 From: buhr at asaurus.net (Kevin Buhr) Date: Sat, 4 May 2019 17:49:28 -0500 Subject: Is cleaning up old issues worthwhile? In-Reply-To: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: <322759a5-bfd7-04a2-9d1b-7e144fea04e8@asaurus.net> Well, after going through a few of these, I realize that there's some relevant Trac metadata (specifically, "Resolution" fields of "ResolvedWorksForMe", "ResolvedFixed", etc.) for all of the ones I've found.  It looks like certain old bugs that were somehow "resolved" but not "closed" in the old system came over as open tickets in GitLab. This is maybe related to gitlab-migration issue #43.  So, I'll stop now. -- Kevin Buhr From wolfgang-it at jeltsch.info Sun May 5 11:02:21 2019 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Sun, 05 May 2019 14:02:21 +0300 Subject: Linear Types: ready for review In-Reply-To: References: Message-ID: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> Am Freitag, den 03.05.2019, 11:52 +0200 schrieb Spiwack, Arnaud: > * The file `Multiplicity`, which defines `type Mult = Type`, the > `Scaled` type and functions unrestricted, linear, pattern > synonyms `One` and `Omega`, quick submultiplicity test submult Could `Omega` **please** be changed to `Many`? I argued long time ago [1] already why `Omega` seems to be a bad choice and `Many` to be a much better alternative. Unfortunately, my arguments, while having been positively received, didn’t really have a considerable impact on the proposal and implementation; still today the proposal reflects only part of them, as it did 1½ months ago [2]. Notation is important, since good notation aids and bad notation confuses. Notation is something that is very likely to stay once it has been in use. Given that changing this one identifier shouldn’t be a big deal, I’m asking you keenly to make this change. Following are my arguments again: 1. It’s already questionable that the paper uses the symbol ω. The choice of this symbol stems from its use for the smallest transfinite ordinal number, the number that denotes the length of an infinite list, if you so wish. This doesn’t match the use of ω in this proposal, where it stands for the possibility to use a value *any number* of times and thus rather corresponds to something like ℕ ∪ {ω}. 2. Even if ω is considered okay for being used in the theory, we shouldn’t use the identifier `Omega` in Haskell. `Omega` doesn’t name the multiplicity; instead it names the symbol that is used to denote the multiplicity. 3. To people not into something like ordinal numbers or ω-words, `Omega` doesn’t mean anything. Therefore its use would rather confuse than enlighten those people. I propose to pick multiplicity identifiers that capture the actual meanings of the multiplicities and are consistent with existing identifiers at the same time. `Control.Applicative` already uses the identifiers `some`, `many`, and `optional`. Thus we should use `Many` for what is now called `Omega` and `Optional` for the affinity multiplicity in case it’s added at some time. I think `One` is a good name and thus should be kept. The 0-multiplicity would probably be best named `None`. All the best, Wolfgang From wolfgang-it at jeltsch.info Sun May 5 11:20:40 2019 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Sun, 05 May 2019 14:20:40 +0300 Subject: Linear Types: ready for review In-Reply-To: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> References: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> Message-ID: <99221c7fd0f69d6559361bda06c37b53c872ad49.camel@jeltsch.info> Hi, again! Here are the missing links to my previous e-mail: [1] https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437271986 [2] https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476125233 All the best, Wolfgang Am Sonntag, den 05.05.2019, 14:02 +0300 schrieb Wolfgang Jeltsch: > Am Freitag, den 03.05.2019, 11:52 +0200 schrieb Spiwack, Arnaud: > > * The file `Multiplicity`, which defines `type Mult = Type`, the > > `Scaled` type and functions unrestricted, linear, pattern > > synonyms `One` and `Omega`, quick submultiplicity test submult > > Could `Omega` **please** be changed to `Many`? I argued long time > ago [1] already why `Omega` seems to be a bad choice and `Many` to be > a much better alternative. Unfortunately, my arguments, while having > been positively received, didn’t really have a considerable impact on > the proposal and implementation; still today the proposal reflects > only part of them, as it did 1½ months ago [2]. > > Notation is important, since good notation aids and bad notation > confuses. Notation is something that is very likely to stay once it > has been in use. Given that changing this one identifier shouldn’t be > a big deal, I’m asking you keenly to make this change. > > Following are my arguments again: > > 1. It’s already questionable that the paper uses the symbol ω. The > choice of this symbol stems from its use for the smallest > transfinite ordinal number, the number that denotes the length of > an infinite list, if you so wish. This doesn’t match the use of ω > in this proposal, where it stands for the possibility to use a > value *any number* of times and thus rather corresponds to > something like ℕ ∪ {ω}. > > 2. Even if ω is considered okay for being used in the theory, we > shouldn’t use the identifier `Omega` in Haskell. `Omega` doesn’t > name the multiplicity; instead it names the symbol that is used > to denote the multiplicity. > > 3. To people not into something like ordinal numbers or ω-words, > `Omega` doesn’t mean anything. Therefore its use would rather > confuse than enlighten those people. > > I propose to pick multiplicity identifiers that capture the actual > meanings of the multiplicities and are consistent with existing > identifiers at the same time. `Control.Applicative` already uses the > identifiers `some`, `many`, and `optional`. Thus we should use `Many` > for what is now called `Omega` and `Optional` for the affinity > multiplicity in case it’s added at some time. I think `One` is a good > name and thus should be kept. The 0-multiplicity would probably be > best named `None`. > > All the best, > Wolfgang From eric at seidel.io Sun May 5 14:26:57 2019 From: eric at seidel.io (Eric Seidel) Date: Sun, 05 May 2019 10:26:57 -0400 Subject: Linear Types: ready for review In-Reply-To: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> References: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> Message-ID: <76661e6b-dc99-4eef-a6c8-1bc3aa8324b3@www.fastmail.com> Hi Wolfgang, Just FYI, the GHC Steering Committee is currently reviewing a few more design decisions for the Linear Types proposal, one of which is the name of the unrestricted multiplicity. The current recommendation is to use Many rather than Omega (https://mail.haskell.org/pipermail/ghc-steering-committee/2019-May/001082.html). Thanks! Eric On Sun, May 5, 2019, at 07:02, Wolfgang Jeltsch wrote: > Am Freitag, den 03.05.2019, 11:52 +0200 schrieb Spiwack, Arnaud: > > * The file `Multiplicity`, which defines `type Mult = Type`, the > > `Scaled` type and functions unrestricted, linear, pattern > > synonyms `One` and `Omega`, quick submultiplicity test submult > > Could `Omega` **please** be changed to `Many`? I argued long time > ago [1] already why `Omega` seems to be a bad choice and `Many` to be a > much better alternative. Unfortunately, my arguments, while having been > positively received, didn’t really have a considerable impact on the > proposal and implementation; still today the proposal reflects only part > of them, as it did 1½ months ago [2]. > > Notation is important, since good notation aids and bad notation > confuses. Notation is something that is very likely to stay once it has > been in use. Given that changing this one identifier shouldn’t be a big > deal, I’m asking you keenly to make this change. > > Following are my arguments again: > > 1. It’s already questionable that the paper uses the symbol ω. The > choice of this symbol stems from its use for the smallest > transfinite ordinal number, the number that denotes the length of > an infinite list, if you so wish. This doesn’t match the use of ω > in this proposal, where it stands for the possibility to use a > value *any number* of times and thus rather corresponds to > something like ℕ ∪ {ω}. > > 2. Even if ω is considered okay for being used in the theory, we > shouldn’t use the identifier `Omega` in Haskell. `Omega` doesn’t > name the multiplicity; instead it names the symbol that is used to > denote the multiplicity. > > 3. To people not into something like ordinal numbers or ω-words, > `Omega` doesn’t mean anything. Therefore its use would rather > confuse than enlighten those people. > > I propose to pick multiplicity identifiers that capture the actual > meanings of the multiplicities and are consistent with existing > identifiers at the same time. `Control.Applicative` already uses the > identifiers `some`, `many`, and `optional`. Thus we should use `Many` > for what is now called `Omega` and `Optional` for the affinity > multiplicity in case it’s added at some time. I think `One` is a good > name and thus should be kept. The 0-multiplicity would probably be best > named `None`. > > All the best, > Wolfgang > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From rae at richarde.dev Mon May 6 03:04:43 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Sun, 5 May 2019 23:04:43 -0400 Subject: Is cleaning up old issues worthwhile? In-Reply-To: <322759a5-bfd7-04a2-9d1b-7e144fea04e8@asaurus.net> References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> <322759a5-bfd7-04a2-9d1b-7e144fea04e8@asaurus.net> Message-ID: I just want to second comments others have said about the value of this kind of activity. It is most certainly *not* annoying! If you're right and there is a migration issue, then it is indeed reasonable to stop and get feedback, but I'm (for one) comfortable having you close tickets that you cannot reproduce in a modern GHC -- as long as you're careful about checking this. (For example, perhaps an old ticket has some code that doesn't make sense with Applicative being a superclass of Monad. Before labeling the issue as unreproducible, it would be wise to update the example first.) The worst case scenario is that someone reopens. Many thanks for this work! Richard > On May 4, 2019, at 6:49 PM, Kevin Buhr wrote: > > Well, after going through a few of these, I realize that there's some relevant Trac metadata (specifically, "Resolution" fields of "ResolvedWorksForMe", "ResolvedFixed", etc.) for all of the ones I've found. It looks like certain old bugs that were somehow "resolved" but not "closed" in the old system came over as open tickets in GitLab. This is maybe related to gitlab-migration issue #43. So, I'll stop now. > > -- > Kevin Buhr > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon May 6 21:51:36 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 May 2019 21:51:36 +0000 Subject: Is cleaning up old issues worthwhile? In-Reply-To: References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> <322759a5-bfd7-04a2-9d1b-7e144fea04e8@asaurus.net> Message-ID: | I just want to second comments others have said about the value of this | kind of activity. It is most certainly *not* annoying! Indeed. Thank you for doing this. Wherever possible, please consider adding a regression test. That makes sure the bug *stays* fixed. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Richard | Eisenberg | Sent: 06 May 2019 04:05 | To: Kevin Buhr | Cc: ghc-devs at haskell.org | Subject: Re: Is cleaning up old issues worthwhile? | | I just want to second comments others have said about the value of this | kind of activity. It is most certainly *not* annoying! If you're right and | there is a migration issue, then it is indeed reasonable to stop and get | feedback, but I'm (for one) comfortable having you close tickets that you | cannot reproduce in a modern GHC -- as long as you're careful about | checking this. (For example, perhaps an old ticket has some code that | doesn't make sense with Applicative being a superclass of Monad. Before | labeling the issue as unreproducible, it would be wise to update the | example first.) The worst case scenario is that someone reopens. | | Many thanks for this work! | Richard | | > On May 4, 2019, at 6:49 PM, Kevin Buhr wrote: | > | > Well, after going through a few of these, I realize that there's some | relevant Trac metadata (specifically, "Resolution" fields of | "ResolvedWorksForMe", "ResolvedFixed", etc.) for all of the ones I've | found. It looks like certain old bugs that were somehow "resolved" but | not "closed" in the old system came over as open tickets in GitLab. This | is maybe related to gitlab-migration issue #43. So, I'll stop now. | > | > -- | > Kevin Buhr | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From arnaud.spiwack at tweag.io Tue May 7 07:08:25 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 7 May 2019 09:08:25 +0200 Subject: Linear Types: ready for review In-Reply-To: <76661e6b-dc99-4eef-a6c8-1bc3aa8324b3@www.fastmail.com> References: <743708b358d66ef8ee0c8ca024dace315eebc169.camel@jeltsch.info> <76661e6b-dc99-4eef-a6c8-1bc3aa8324b3@www.fastmail.com> Message-ID: Indeed, I'd like to insist, to dispell any ambiguity, that none of the syntax in the above-mentioned patch is definitive. We had to make up some syntax because we needed it for testing, but the decision on what the actual syntax will be has not been made yet. It's too early to worry :) I'll, of course, update the proposal with the committee's decision when it is made. Best, Arnaud On Sun, May 5, 2019 at 4:27 PM Eric Seidel wrote: > Hi Wolfgang, > > Just FYI, the GHC Steering Committee is currently reviewing a few more > design decisions for the Linear Types proposal, one of which is the name of > the unrestricted multiplicity. The current recommendation is to use Many > rather than Omega ( > https://mail.haskell.org/pipermail/ghc-steering-committee/2019-May/001082.html > ). > > Thanks! > Eric > > On Sun, May 5, 2019, at 07:02, Wolfgang Jeltsch wrote: > > Am Freitag, den 03.05.2019, 11:52 +0200 schrieb Spiwack, Arnaud: > > > * The file `Multiplicity`, which defines `type Mult = Type`, the > > > `Scaled` type and functions unrestricted, linear, pattern > > > synonyms `One` and `Omega`, quick submultiplicity test submult > > > > Could `Omega` **please** be changed to `Many`? I argued long time > > ago [1] already why `Omega` seems to be a bad choice and `Many` to be a > > much better alternative. Unfortunately, my arguments, while having been > > positively received, didn’t really have a considerable impact on the > > proposal and implementation; still today the proposal reflects only part > > of them, as it did 1½ months ago [2]. > > > > Notation is important, since good notation aids and bad notation > > confuses. Notation is something that is very likely to stay once it has > > been in use. Given that changing this one identifier shouldn’t be a big > > deal, I’m asking you keenly to make this change. > > > > Following are my arguments again: > > > > 1. It’s already questionable that the paper uses the symbol ω. The > > choice of this symbol stems from its use for the smallest > > transfinite ordinal number, the number that denotes the length of > > an infinite list, if you so wish. This doesn’t match the use of ω > > in this proposal, where it stands for the possibility to use a > > value *any number* of times and thus rather corresponds to > > something like ℕ ∪ {ω}. > > > > 2. Even if ω is considered okay for being used in the theory, we > > shouldn’t use the identifier `Omega` in Haskell. `Omega` doesn’t > > name the multiplicity; instead it names the symbol that is used to > > denote the multiplicity. > > > > 3. To people not into something like ordinal numbers or ω-words, > > `Omega` doesn’t mean anything. Therefore its use would rather > > confuse than enlighten those people. > > > > I propose to pick multiplicity identifiers that capture the actual > > meanings of the multiplicities and are consistent with existing > > identifiers at the same time. `Control.Applicative` already uses the > > identifiers `some`, `many`, and `optional`. Thus we should use `Many` > > for what is now called `Omega` and `Optional` for the affinity > > multiplicity in case it’s added at some time. I think `One` is a good > > name and thus should be kept. The 0-multiplicity would probably be best > > named `None`. > > > > All the best, > > Wolfgang > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 7 21:50:00 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 May 2019 21:50:00 +0000 Subject: Linear Types: ready for review In-Reply-To: References: Message-ID: Dear GHC developers and friends I would like to urge you to review, and help to improve, this patch. Adding linear types to Haskell is a big change that touches a lot of code. That makes the patch a bit daunting. But GHC is supposed to be a laboratory for advanced stuff, and this is a great example. The authors (esp Arnaud, Krzysztof, and Jean-Philippe) have invested a lot of effort in the paper, the proposal, and now the patch. And lots of people are interested in the result. In short, we owe it to them to give their work serious attention. But please don’t think “oh, I’m not qualified and anyway Simon will look at it”. I will, of course, but like you I’m too busy. And a far-reaching change like this needs many eyes. Moreover, assuming it’s committed, this code will be us for a long time; most future developers will be no better qualified than you, but they’ll still have to deal with it! So if you get bamboozled, make constructive suggestions about what sorts of Notes or explanation would un-bamboozle you. Don’t just assume you are too stupid; that way likes an un-maintainable code base. So please jump in there. This is your compiler. Thanks Simon From: ghc-devs On Behalf Of Spiwack, Arnaud Sent: 03 May 2019 10:52 To: GHC developers Cc: Krzysztof Gogolewski Subject: Linear Types: ready for review 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 7 22:36:11 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 May 2019 22:36:11 +0000 Subject: Keeping track of issues Message-ID: 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.". * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Wed May 8 02:15:21 2019 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 8 May 2019 10:15:21 +0800 Subject: [ANNOUNCE] GHC 8.8.1-alpha1 is now available In-Reply-To: <87a7gdtziv.fsf@smart-cactus.org> References: <87a7gdtziv.fsf@smart-cactus.org> Message-ID: On Fri, 26 Apr 2019 at 07:51, Ben Gamari wrote: > The GHC team is pleased to announce the first alpha release of GHC 8.8.1. I built it for Fedora 30 and Rawhide in a new ghc:8.8 Fedora module stream (builds for 28 and 29 will be forthcoming later). You should be able to install with ``` $ sudo dnf --enablerepo=updates-testing-modular module enable ghc:8.8 $ sudo dnf --enablerepo=updates-testing-modular install ghc ``` (If you have already enabled or installed a Fedora ghc module stream, then you will need to `dnf remove ghc-base` and reset the ghc module.) Thanks, Jens From omeragacan at gmail.com Wed May 8 05:57:33 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 8 May 2019 08:57:33 +0300 Subject: Keeping track of issues In-Reply-To: References: Message-ID: Hi Simon, > 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? That's because Marge got stuck for some reason (I think related to but in Gitlab API, but I'm not sure) and couldn't merge the first batch MR that it created. So it created another one, failed again, created another one and so on. The MR you're looking at was in those batch MRs, so every time Marge created another MR the issue you're looking at got a new reference. After 6 attempts by Marge I realized that it got stuck for good so I stopped it, merged the last batch MR crated by Marge manually, closed all other MRs in that batch MR with a "merged as ..." comment, and started Marge again. > Oh, one of those six patches is a dup, mentioned twice. No idea why. I think you mean cc495d57 ? I'm not sure why it's mentioned twice, perhaps it's a Gitlab bug. I'd only expect to see "closed via cc495d57", "mentioned in cc495d57" looks redundant to me after that. > 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? There's just one patch. The commit hash is different for each one becuase they're applied to a different tree in each MR. > Hmm. Well Ryan says “I’ve opened MR 851”. Maybe that’s it? That's the original MR that fixed the issue. All other MRs are batch merge request created by Marge. > Oh! It just says “Closed”. I was hoping it’d say “merged”, but no. > 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.”. I also don't understand this part. Normally when Marge merges a MR similar to how I merge, the MR gets a "merged" comment, but when I merged the batch MR manually this did not happen, so I added a "merged as ..." comment to each MR that I merged and closed the MRs. > Huh. So maybe it did get merged after all. Right. Reading rest of your email, I think the main issues are: - Marge gets stuck for various reasons and generates a lot of noise until someone intercepts. (this is why you saw all those commit references in the issue and Marge comments in the fixing MR) - (This may be a mistake on my part) When I merged a batch of merge requests manually those merge requests are not automatically closed. - There's no way to close a MR as "merged" unless Gitlab decides that it's merged. So in my case I couldn't close those MRs as "merged" and had to close as "closed". > Trac used to let you close a ticket as “fixed” or “wont-fix” or “invalid” etc. > This was Jolly Useful. Doesn’t Gitlab? I think the Gitlab way of closing something as "wont-fix" is by labelling it as "wont-fix" and then closing the ticket/MR. Ömer Simon Peyton Jones via ghc-devs , 8 May 2019 Çar, 01:36 tarihinde şunu yazdı: > > 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.”. > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From vladislav at serokell.io Wed May 8 08:51:17 2019 From: vladislav at serokell.io (Vladislav Zavialov) Date: Wed, 8 May 2019 11:51:17 +0300 Subject: Parser performance: 10% regression in 8.8 Message-ID: Hello ghc-devs, This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4 ). Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134 ), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration. Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done: 1. Merge https://github.com/simonmar/happy/pull/134 2. Release a new ‘happy’ 3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration 5. Backport it to the ghc-8.8 branch I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5. All the best, - Vladislav -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 8 08:51:24 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 May 2019 08:51:24 +0000 Subject: MR titles Message-ID: Friends In this MR, 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 at 01D50583.988DEB70] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14040 bytes Desc: image001.jpg URL: From chessai1996 at gmail.com Wed May 8 11:28:38 2019 From: chessai1996 at gmail.com (chessai .) Date: Wed, 8 May 2019 07:28:38 -0400 Subject: MR titles In-Reply-To: References: Message-ID: I agree that this is the way to go. This is part of our contributing guide at work, for the reasons you mentioned. Additionally it helps avoid the need to read the MR's contents (comments/code) before going into it, since reading relevant tickets is almost always something you want to do. Thanks On Wed, May 8, 2019, 4:51 AM Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Friends > > In this MR , 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 > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14040 bytes Desc: not available URL: From simonpj at microsoft.com Wed May 8 11:31:16 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 May 2019 11:31:16 +0000 Subject: MR titles In-Reply-To: References: Message-ID: This is part of our contributing guide at work Do you have other advice from your contributing guide that we could learn from? Simon From: chessai . Sent: 08 May 2019 12:29 To: Simon Peyton Jones Cc: GHC developers Subject: Re: MR titles I agree that this is the way to go. This is part of our contributing guide at work, for the reasons you mentioned. Additionally it helps avoid the need to read the MR's contents (comments/code) before going into it, since reading relevant tickets is almost always something you want to do. Thanks On Wed, May 8, 2019, 4:51 AM Simon Peyton Jones via ghc-devs > wrote: Friends In this MR, 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 at 01D50583.988DEB70] _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed May 8 13:21:24 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 8 May 2019 09:21:24 -0400 Subject: MR titles In-Reply-To: References: Message-ID: <8E43FEB2-E581-4C99-A510-B7F1EA0692CA@richarde.dev> Might I also suggest that we put a very brief summary of the area of GHC that the MR fixes in the title? With the way that GitLab puts numbers at the end of subject lines, it's harder to recognize tickets by number now. By including a few keywords in the MR title, I can find ones of interest more easily. Regardless, putting the ticket number in the title should be a higher priority. Richard > On May 8, 2019, at 4:51 AM, Simon Peyton Jones via ghc-devs wrote: > > Friends > > In this MR , 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 > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 8 15:24:26 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 May 2019 15:24:26 +0000 Subject: Old build system broken Message-ID: 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 at MSRC-3645512:~/code/HEAD$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From carette at mcmaster.ca Wed May 8 16:16:41 2019 From: carette at mcmaster.ca (Jacques Carette) Date: Wed, 8 May 2019 12:16:41 -0400 Subject: Is cleaning up old issues worthwhile? In-Reply-To: References: <516aa1da-ff3d-7838-7d01-88ec1fdcce42@asaurus.net> Message-ID: <12394078-e8b6-e6b4-9a0e-edc1a74b8c84@mcmaster.ca> In my time working on an old system, I found the statement "they are so old that if the bug still exists there is probably a newer ticket" to be false multiple times.  Large systems hide many obscure bugs, some of which are rarely encountered. And sometimes the oldest symptom is the clearest one. I have always found that more tests is best; so even when I closed old bugs as 'magically fixed' in Maple, I still created a regression test for it. Jacques On 2019-05-04 5:56 p.m., Matthew Pickering wrote: > I'm not sure the benefit of marking these tickets obsolete is. You may > as well just close them. Someone can reopen them if they disagree. > > There could be some arguent for adding tests from these old tickets > but tbh they are so old that if the bug still exists there is probably > a newer ticket. > > On Sat, May 4, 2019 at 10:31 PM Kevin Buhr wrote: >> Okay, I've added a new "obsolete" label: "Old issues that no longer >> apply and are in a short waiting period before closing." I'll start >> going through the low-hanging fruit adding comments and sticking this >> label on them, with the idea of going back and closing them after, say, >> 4 weeks with no complaints. After I've gone through a few of these and >> gained some experience with it, I'll try to draft some guidelines for >> handling old tickets. >> >> Anyway, please let me know if this process starts to get irritating. >> >> -- >> Kevin Buhr >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From buhr at asaurus.net Wed May 8 18:40:08 2019 From: buhr at asaurus.net (Kevin Buhr) Date: Wed, 8 May 2019 13:40:08 -0500 Subject: CI on forked projects: Darwin woes Message-ID: Over the past few days, I've submitted several merge requests from branches on my forked project (mostly because I didn't even realize pushing to a branch on the main project was an alternative). When those MRs run under CI, I've had a bunch of failures due to timeouts waiting on a darwin-x86_64 runner.  I was a little mystified that no other pipelines besides mine seemed to be having this problem, but I've come to understand that MRs submitted from branches on the main project use a different, larger set of runners than the shared runners used by MRs from branches on forked projects. Under my project, I can view the available shared runners under the "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that there's only one darwin runner ("b4bc6410" / mac-mini-x86_64-darwin-davxkc).  This machine is a trooper, but it unfortunately shares a circuit breaker with a toaster oven, so it goes offline every time someone wants a bagel, and the rest of the time it must be running CI for a few hundred GHC forks. I ended up deleting an (unreviewed) MR sourced from my branch, and pushing it to the main project and resubmitting just to get the CI to run.  (Admittedly, it failed, but at least not on darwin!)  I obviously don't want to do this with the merge requests that have already been reviewed. Is this a temporary problem?  Is there anything I can do other than keep retrying the darwin jobs every couple days? Also, is there a better place than "ghc-dev" to send these sorts of GitLab/CI issues?  I thought there might be a project dedicated to it, but if so I couldn't find it. -- Kevin Buhr From iavor.diatchki at gmail.com Wed May 8 18:58:42 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 8 May 2019 11:58:42 -0700 Subject: CI on forked projects: Darwin woes In-Reply-To: References: Message-ID: I think there was the ghc-devops-group list, but I don't know if it is still active, and I kind of like to not have to follow too many lists. For example, I had also not realized that it is an option to push to branches on the main project, and have been using my own fork, so thanks for posting this here! -Iavor On Wed, May 8, 2019 at 11:40 AM Kevin Buhr wrote: > > Over the past few days, I've submitted several merge requests from > branches on my forked project (mostly because I didn't even realize > pushing to a branch on the main project was an alternative). > > When those MRs run under CI, I've had a bunch of failures due to > timeouts waiting on a darwin-x86_64 runner. I was a little mystified > that no other pipelines besides mine seemed to be having this problem, > but I've come to understand that MRs submitted from branches on the main > project use a different, larger set of runners than the shared runners > used by MRs from branches on forked projects. > > Under my project, I can view the available shared runners under the > "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that > there's only one darwin runner ("b4bc6410" / > mac-mini-x86_64-darwin-davxkc). This machine is a trooper, but it > unfortunately shares a circuit breaker with a toaster oven, so it goes > offline every time someone wants a bagel, and the rest of the time it > must be running CI for a few hundred GHC forks. > > I ended up deleting an (unreviewed) MR sourced from my branch, and > pushing it to the main project and resubmitting just to get the CI to > run. (Admittedly, it failed, but at least not on darwin!) I obviously > don't want to do this with the merge requests that have already been > reviewed. > > Is this a temporary problem? Is there anything I can do other than keep > retrying the darwin jobs every couple days? > > Also, is there a better place than "ghc-dev" to send these sorts of > GitLab/CI issues? I thought there might be a project dedicated to it, > but if so I couldn't find it. > > > -- > Kevin Buhr > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From lonetiger at gmail.com Wed May 8 19:28:39 2019 From: lonetiger at gmail.com (Phyx) Date: Wed, 8 May 2019 20:28:39 +0100 Subject: Old build system broken In-Reply-To: References: Message-ID: That looks like stage1 has been improperly configured. Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info *Return anything sensible for target arch? * *I still use the make system exclusively and haven't noticed a failure. * *But my nightlies haven't kicked off yet today. * *Thanks, * *Tamar * Sent from my Mobile On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > 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 at MSRC-3645512:~/code/HEAD$ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Wed May 8 19:48:55 2019 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 08 May 2019 21:48:55 +0200 Subject: Old build system broken In-Reply-To: References: Message-ID: <5CD332A7.8030607@centrum.cz> Sorry to hijack the thread, I get something very similar on ppc64le linux: Configuring ghc-prim-0.6.1... ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error: No entry for "Tables next to code" in "/tmpram/ghc/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 this is from today's HEAD. Thanks, Karel On 05/ 8/19 09:28 PM, Phyx wrote: > That looks like stage1 has been improperly configured. > > Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info > * > * > *Return anything sensible for target arch? * > * > * > *I still use the make system exclusively and haven't noticed a failure. * > * > * > *But my nightlies haven't kicked off yet today. * > * > * > *Thanks, * > *Tamar > * > Sent from my Mobile > > On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs > > wrote: > > 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 at MSRC-3645512:~/code/HEAD$____ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From rae at richarde.dev Wed May 8 19:51:58 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 8 May 2019 15:51:58 -0400 Subject: Old build system broken In-Reply-To: <5CD332A7.8030607@centrum.cz> References: <5CD332A7.8030607@centrum.cz> Message-ID: <69595604-3526-440F-956F-CFC41CA562D6@richarde.dev> Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I don't have the error message any more. It mentioned "Tables next to code" and the settings file, so I'm confident that it's related. Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for me. Richard > On May 8, 2019, at 3:48 PM, Karel Gardas wrote: > > > Sorry to hijack the thread, I get something very similar on ppc64le linux: > > Configuring ghc-prim-0.6.1... > ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error: > No entry for "Tables next to code" in "/tmpram/ghc/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 > > this is from today's HEAD. > > Thanks, > Karel > > On 05/ 8/19 09:28 PM, Phyx wrote: >> That looks like stage1 has been improperly configured. >> >> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info >> * >> * >> *Return anything sensible for target arch? * >> * >> * >> *I still use the make system exclusively and haven't noticed a failure. * >> * >> * >> *But my nightlies haven't kicked off yet today. * >> * >> * >> *Thanks, * >> *Tamar >> * >> Sent from my Mobile >> >> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs >> > wrote: >> >> 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 at MSRC-3645512:~/code/HEAD$____ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at richarde.dev Wed May 8 20:33:14 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 8 May 2019 16:33:14 -0400 Subject: Old build system broken In-Reply-To: <69595604-3526-440F-956F-CFC41CA562D6@richarde.dev> References: <5CD332A7.8030607@centrum.cz> <69595604-3526-440F-956F-CFC41CA562D6@richarde.dev> Message-ID: <39DE7F99-0F5B-48C2-87BF-02E80109311D@richarde.dev> Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is not deleting settings files, which cause this bug. If you do a fresh checkout and build, the problem should go away. It's also possible that deleting inplace/lib/settings manually (and then running ./configure) may also fix it. Richard > On May 8, 2019, at 3:51 PM, Richard Eisenberg wrote: > > Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I don't have the error message any more. It mentioned "Tables next to code" and the settings file, so I'm confident that it's related. > > Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for me. > > Richard > >> On May 8, 2019, at 3:48 PM, Karel Gardas wrote: >> >> >> Sorry to hijack the thread, I get something very similar on ppc64le linux: >> >> Configuring ghc-prim-0.6.1... >> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error: >> No entry for "Tables next to code" in "/tmpram/ghc/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 >> >> this is from today's HEAD. >> >> Thanks, >> Karel >> >> On 05/ 8/19 09:28 PM, Phyx wrote: >>> That looks like stage1 has been improperly configured. >>> >>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info >>> * >>> * >>> *Return anything sensible for target arch? * >>> * >>> * >>> *I still use the make system exclusively and haven't noticed a failure. * >>> * >>> * >>> *But my nightlies haven't kicked off yet today. * >>> * >>> * >>> *Thanks, * >>> *Tamar >>> * >>> Sent from my Mobile >>> >>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs >>> > wrote: >>> >>> 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 at MSRC-3645512:~/code/HEAD$____ >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From John.Ericson at Obsidian.Systems Wed May 8 21:47:36 2019 From: John.Ericson at Obsidian.Systems (John Cotton Ericson) Date: Wed, 8 May 2019 17:47:36 -0400 Subject: Old build system broken In-Reply-To: <39DE7F99-0F5B-48C2-87BF-02E80109311D@richarde.dev> References: <5CD332A7.8030607@centrum.cz> <69595604-3526-440F-956F-CFC41CA562D6@richarde.dev> <39DE7F99-0F5B-48C2-87BF-02E80109311D@richarde.dev> Message-ID: <6f874bba-5380-28c9-7cfe-5a034df769a7@Obsidian.Systems> Yeah so what I did is making settings no longer be created directly by configure, but by make and hadrian. I did this because I'm moving configurations options from Config.hs to there, Config.hs was generated by make and hadrian, and the whole thing will become stage-specific. I tried do mimic what hadrian/make for `Config.hs` and the various header files like `ghcplatform.h`, but evidently I missed how those are invalidated / cleaned up (unless they change so infrequently that cleaning up never worked). I'm happy to make the fix (especially as I hope to change `settings` some more), but I would appreciate some advise from people in the know about how the cleaning ought to work. I suspect the cleaning with both build systems is broken. Sorry for the disruption, John On 5/8/19 4:33 PM, Richard Eisenberg wrote: > Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is not deleting settings files, which cause this bug. If you do a fresh checkout and build, the problem should go away. It's also possible that deleting inplace/lib/settings manually (and then running ./configure) may also fix it. > > Richard > >> On May 8, 2019, at 3:51 PM, Richard Eisenberg wrote: >> >> Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I don't have the error message any more. It mentioned "Tables next to code" and the settings file, so I'm confident that it's related. >> >> Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for me. >> >> Richard >> >>> On May 8, 2019, at 3:48 PM, Karel Gardas wrote: >>> >>> >>> Sorry to hijack the thread, I get something very similar on ppc64le linux: >>> >>> Configuring ghc-prim-0.6.1... >>> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error: >>> No entry for "Tables next to code" in "/tmpram/ghc/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 >>> >>> this is from today's HEAD. >>> >>> Thanks, >>> Karel >>> >>> On 05/ 8/19 09:28 PM, Phyx wrote: >>>> That looks like stage1 has been improperly configured. >>>> >>>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info >>>> * >>>> * >>>> *Return anything sensible for target arch? * >>>> * >>>> * >>>> *I still use the make system exclusively and haven't noticed a failure. * >>>> * >>>> * >>>> *But my nightlies haven't kicked off yet today. * >>>> * >>>> * >>>> *Thanks, * >>>> *Tamar >>>> * >>>> Sent from my Mobile >>>> >>>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs >>>> > wrote: >>>> >>>> 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 at MSRC-3645512:~/code/HEAD$____ >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From iavor.diatchki at gmail.com Wed May 8 23:19:03 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 8 May 2019 16:19:03 -0700 Subject: Question about Gitlab MR workflow. Message-ID: Hello, I've just had a go at making a small MR on our new Gitlab system, and I am a bit confused about the intended workflow. I was following these instructions : https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs My question is about the steps after 2 (i.e., 3 and 4). Step 5 about the beer I already did :-) Here was my experience so far: 1. I made the changes I wanted yesterday over lunch: the change was quite trivial, I added a NOINLINE pragma and some comments and I mage the MR. 2. Sometime in the evening (half a day later!) I got an e-mail from the CI system that something had failed. It was quite hard to tell what had failed, and after poking around at the logs, it seemed like it was some sort of spurious failures because things had timed out, I think? 3. Today I got some feedback from a reviewer about some changes I should make to the MR. As I was working on those, I noticed that every time I push to the MR, the CI is forking a new job. I cancelled some of those manually, to save on resources, as they already seem to be taking half a day. 4. After making the changes, I noticed that Gitlab is asking me to rebase my changes because, presumably, some other things have already been merged. It is easy enough to rebase my MR, but every time I do so, this fires up a new CI job. And, of course, this is going to keep happening, until I am lucky enough to rebase just at the right time? This doesn't seem right. So my questions are specifically about step 3 and 4: About 3: wouldn't it make more sense to start firing up CI jobs only after an MR has been approved for merging? About 4: I really don't understand how this rebasing business is intended to work: every time I rebase, I new CI job is fired up. But, presumably, while this is going, other things are going to be merged with `master`, so I'd need to rebase again. So, when would I ever stop rebasing? Furthermore, in my case the rebase is trivial, but with a larger patch, doing multiple rebases seems like a lot of wasted work. Any help would be appreciated! -Iavor From omeragacan at gmail.com Thu May 9 06:40:01 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 9 May 2019 09:40:01 +0300 Subject: Old build system broken In-Reply-To: <39DE7F99-0F5B-48C2-87BF-02E80109311D@richarde.dev> References: <5CD332A7.8030607@centrum.cz> <69595604-3526-440F-956F-CFC41CA562D6@richarde.dev> <39DE7F99-0F5B-48C2-87BF-02E80109311D@richarde.dev> Message-ID: > If you do a fresh checkout and build, the problem should go away. You can also do `git clean -xfd`. Ömer Richard Eisenberg , 8 May 2019 Çar, 23:33 tarihinde şunu yazdı: > > Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is not deleting settings files, which cause this bug. If you do a fresh checkout and build, the problem should go away. It's also possible that deleting inplace/lib/settings manually (and then running ./configure) may also fix it. > > Richard > > > On May 8, 2019, at 3:51 PM, Richard Eisenberg wrote: > > > > Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I don't have the error message any more. It mentioned "Tables next to code" and the settings file, so I'm confident that it's related. > > > > Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for me. > > > > Richard > > > >> On May 8, 2019, at 3:48 PM, Karel Gardas wrote: > >> > >> > >> Sorry to hijack the thread, I get something very similar on ppc64le linux: > >> > >> Configuring ghc-prim-0.6.1... > >> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error: > >> No entry for "Tables next to code" in "/tmpram/ghc/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 > >> > >> this is from today's HEAD. > >> > >> Thanks, > >> Karel > >> > >> On 05/ 8/19 09:28 PM, Phyx wrote: > >>> That looks like stage1 has been improperly configured. > >>> > >>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info > >>> * > >>> * > >>> *Return anything sensible for target arch? * > >>> * > >>> * > >>> *I still use the make system exclusively and haven't noticed a failure. * > >>> * > >>> * > >>> *But my nightlies haven't kicked off yet today. * > >>> * > >>> * > >>> *Thanks, * > >>> *Tamar > >>> * > >>> Sent from my Mobile > >>> > >>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs > >>> > wrote: > >>> > >>> 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 at MSRC-3645512:~/code/HEAD$____ > >>> > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>> > >>> > >>> > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >>> > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From omeragacan at gmail.com Thu May 9 06:46:14 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 9 May 2019 09:46:14 +0300 Subject: Question about Gitlab MR workflow. In-Reply-To: References: Message-ID: Hi, > About 4: I really don't understand how this rebasing business is intended to > work: every time I rebase, I new CI job is fired up. But, presumably, while > this is going, other things are going to be merged with `master`, so I'd need > to rebase again. So, when would I ever stop rebasing? Rebasing is actually not necessary. Marge adds your MR to the batch MR when it's approved and passed the tests. It doesn't have to be based on HEAD. So just don't bother with it. Only time I needed a rebase was when there was a failing test in HEAD and a commit that disabled it had just landed. My MR was not passing the tests because of the test so I had to rebase. Ömer Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde şunu yazdı: > > Hello, > > I've just had a go at making a small MR on our new Gitlab system, and > I am a bit confused about the intended workflow. I was following > these instructions : > > https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs > > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about > the beer I already did :-) Here was my experience so far: > > 1. I made the changes I wanted yesterday over lunch: the change was > quite trivial, I added a NOINLINE pragma and some comments and I mage > the MR. > > 2. Sometime in the evening (half a day later!) I got an e-mail from > the CI system that something had failed. It was quite hard to tell > what had failed, and after poking around at the logs, it seemed like > it was some sort of spurious failures because things had timed out, I > think? > > 3. Today I got some feedback from a reviewer about some changes I > should make to the MR. As I was working on those, I noticed that > every time I push to the MR, the CI is forking a new job. I cancelled > some of those manually, to save on resources, as they already seem to > be taking half a day. > > 4. After making the changes, I noticed that Gitlab is asking me to > rebase my changes because, presumably, some other things have already > been merged. It is easy enough to rebase my MR, but every time I do > so, this fires up a new CI job. And, of course, this is going to > keep happening, until I am lucky enough to rebase just at the right > time? This doesn't seem right. > > So my questions are specifically about step 3 and 4: > > About 3: wouldn't it make more sense to start firing up CI jobs > only after an MR has been approved for merging? > > About 4: I really don't understand how this rebasing business is > intended to work: every time I rebase, I new CI job is fired up. But, > presumably, while this is going, other things are going to be merged > with `master`, so I'd need to rebase again. So, when would I ever > stop rebasing? > Furthermore, in my case the rebase is trivial, but with a larger > patch, doing multiple rebases seems like a lot of wasted work. > > Any help would be appreciated! > > -Iavor > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From marlowsd at gmail.com Thu May 9 07:35:42 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 9 May 2019 08:35:42 +0100 Subject: Parser performance: 10% regression in 8.8 In-Reply-To: References: Message-ID: Thanks for bringing this up. I've merged the PR and uploaded Happy 1.19.10 to Hackage. Can someone else look at steps 3-5? Cheers Simon On Wed, 8 May 2019 at 09:51, Vladislav Zavialov wrote: > Hello ghc-devs, > > This February I did some changes to the parser that require higher rank > types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce > option is severely broken in the presence of higher rank types, so I had to > disable it. My benchmarks have shown a 10% slowdown from disabling --coerce > (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4). > > Alongside my changes I submitted a pull request to happy which fixes the > issue (https://github.com/simonmar/happy/pull/134), in the hope that it > would get merged, released, and I could re-enable --coerce in GHC ‘happy' > configuration. > > Unfortunately, my patch has been ignored to this day (for 3 months now), > and the performance regression reached 8.8-alpha. We need to act swiftly if > we want to avoid a performance regression in the actual release. Here’s > what needs to be done: > > 1. Merge https://github.com/simonmar/happy/pull/134 > 2. Release a new ‘happy’ > 3. (Optional) Specify in GHC’s build system that it builds only with the > latest 'happy' release > 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration > 5. Backport it to the ghc-8.8 branch > > I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate > if someone took care of 3, currently the build system does not install > ‘happy’ and assumes a system-wide installation without checking its > version. This means that users of all but the newly released version will > encounter obscure error messages. We need a version check. Then I will do > 4, as planned, and create a merge request for 5. > > All the best, > - Vladislav > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 9 08:02:43 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 May 2019 08:02:43 +0000 Subject: Question about Gitlab MR workflow. In-Reply-To: References: Message-ID: It would be good to add this advice to our "how-to-contribute" pages. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 09 May 2019 07:46 | To: Iavor Diatchki | Cc: ghc-devs | Subject: Re: Question about Gitlab MR workflow. | | Hi, | | > About 4: I really don't understand how this rebasing business is | > intended to | > work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | with `master`, so I'd need | > to rebase again. So, when would I ever stop rebasing? | | Rebasing is actually not necessary. Marge adds your MR to the batch MR | when it's approved and passed the tests. It doesn't have to be based on | HEAD. So just don't bother with it. | | Only time I needed a rebase was when there was a failing test in HEAD and | a commit that disabled it had just landed. My MR was not passing the tests | because of the test so I had to rebase. | | Ömer | | Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde | şunu yazdı: | > | > Hello, | > | > I've just had a go at making a small MR on our new Gitlab system, and | > I am a bit confused about the intended workflow. I was following | > these instructions : | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs | > &data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UBBq5BHxuAdK | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&reserved=0 | > | > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about | > the beer I already did :-) Here was my experience so far: | > | > 1. I made the changes I wanted yesterday over lunch: the change was | > quite trivial, I added a NOINLINE pragma and some comments and I mage | > the MR. | > | > 2. Sometime in the evening (half a day later!) I got an e-mail from | > the CI system that something had failed. It was quite hard to tell | > what had failed, and after poking around at the logs, it seemed like | > it was some sort of spurious failures because things had timed out, I | > think? | > | > 3. Today I got some feedback from a reviewer about some changes I | > should make to the MR. As I was working on those, I noticed that | > every time I push to the MR, the CI is forking a new job. I cancelled | > some of those manually, to save on resources, as they already seem to | > be taking half a day. | > | > 4. After making the changes, I noticed that Gitlab is asking me to | > rebase my changes because, presumably, some other things have already | > been merged. It is easy enough to rebase my MR, but every time I do | > so, this fires up a new CI job. And, of course, this is going to | > keep happening, until I am lucky enough to rebase just at the right | > time? This doesn't seem right. | > | > So my questions are specifically about step 3 and 4: | > | > About 3: wouldn't it make more sense to start firing up CI jobs | > only after an MR has been approved for merging? | > | > About 4: I really don't understand how this rebasing business is | > intended to work: every time I rebase, I new CI job is fired up. But, | > presumably, while this is going, other things are going to be merged | > with `master`, so I'd need to rebase again. So, when would I ever | > stop rebasing? | > Furthermore, in my case the rebase is trivial, but with a larger | > patch, doing multiple rebases seems like a lot of wasted work. | > | > Any help would be appreciated! | > | > -Iavor | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01 | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ | > i%2F6%2F5uwfAdypps%3D&reserved=0 | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 | d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXK | tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&reserved=0 From matthewtpickering at gmail.com Thu May 9 08:39:35 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 9 May 2019 09:39:35 +0100 Subject: Website for viewing proposals Message-ID: Hi, It would be useful if there was a canonical way to link and view GHC proposals rather than relying on github's RST viewer. Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to automatically when a new accepted proposal is merged? FWIW, if the proposals process was also on gitlab then doing this deployment would be easy using our CI infrastructure but I don't know how to set up something similar on github. Cheers, Matt From simonpj at microsoft.com Thu May 9 09:11:04 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 May 2019 09:11:04 +0000 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: Interesting. How would it differ from what we have (i.e. github's RST viewer)? | -----Original Message----- | From: ghc-devs On Behalf Of Matthew | Pickering | Sent: 09 May 2019 09:40 | To: GHC developers | Subject: Website for viewing proposals | | Hi, | | It would be useful if there was a canonical way to link and view GHC | proposals rather than relying on github's RST viewer. | | Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to | automatically when a new accepted proposal is merged? | | FWIW, if the proposals process was also on gitlab then doing this | deployment would be easy using our CI infrastructure but I don't know how | to set up something similar on github. | | Cheers, | | Matt | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 | d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l | RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 From matthewtpickering at gmail.com Thu May 9 09:45:26 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 9 May 2019 10:45:26 +0100 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: I want to cite a GHC proposal but linking to github for it doesn't seem very official or permanent. Last year you also cited a proposal for your Haskell symposium paper (https://arxiv.org/abs/1806.03476) but instead linked to the pull request which also doesn't seem ideal to me. Matt On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones wrote: > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > | -----Original Message----- > | From: ghc-devs On Behalf Of Matthew > | Pickering > | Sent: 09 May 2019 09:40 > | To: GHC developers > | Subject: Website for viewing proposals > | > | Hi, > | > | It would be useful if there was a canonical way to link and view GHC > | proposals rather than relying on github's RST viewer. > | > | Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > | automatically when a new accepted proposal is merged? > | > | FWIW, if the proposals process was also on gitlab then doing this > | deployment would be easy using our CI infrastructure but I don't know how > | to set up something similar on github. > | > | Cheers, > | > | Matt > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > | d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > | RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 From mail at joachim-breitner.de Thu May 9 12:40:46 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 09 May 2019 14:40:46 +0200 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: Hi, I looked into getting doi’s for our accepted proposals, but it looked harder than it should be. Building a nice web page from our repository and publishing it on GitHub pages, which can serve a custom domain like ghc-proposals.haskell.org would not be hard. Matthew even started a Makefile at some point that produces a reasonably nice output using sphinx. Maybe only reason why I am hesitant to do so is that there is a feature creep risk: We start with a webpage that shows accepted proposals, soon we’ll add functionality to list pending proposals and their status (why not? They are just a GitHub API call away), then we start using this page to actually drive the proposals (surely we can use this to tally the votes), and then we end up with a system that no longer has the “you just need to know GitHub to use it” property that made us build a Github-centric process in the first place. But maybe I am paranoid, and I should just set up the CI infrastructure for Matthew’s sphinx build. BTW, in hindsight, I regret that we renumber proposals after acceptance. It would be easier if they just retained the number of the PR (other proposal processes out there do that). But that ship has sailed. Cheers, Joachim Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > I want to cite a GHC proposal but linking to github for it doesn't > seem very official or permanent. > > Last year you also cited a proposal for your Haskell symposium paper > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > request which also doesn't seem ideal to me. > > Matt > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > wrote: > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > -----Original Message----- > > > From: ghc-devs On Behalf Of Matthew > > > Pickering > > > Sent: 09 May 2019 09:40 > > > To: GHC developers > > > Subject: Website for viewing proposals > > > > > > Hi, > > > > > > It would be useful if there was a canonical way to link and view GHC > > > proposals rather than relying on github's RST viewer. > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > automatically when a new accepted proposal is merged? > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > deployment would be easy using our CI infrastructure but I don't know how > > > to set up something similar on github. > > > > > > Cheers, > > > > > > Matt > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From davide at well-typed.com Thu May 9 14:37:42 2019 From: davide at well-typed.com (David Eichmann) Date: Thu, 9 May 2019 15:37:42 +0100 Subject: Question about Gitlab MR workflow. In-Reply-To: References: Message-ID: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> I've added a blurb in the wiki page about rebasing MRs: GitLab usually complains that "Fast-forward merge is not possible" on your MR. If you see a green check and green "Rebase" button, NO action is necessary: your MR will be rebased automatically on merge. If instead you see an exclamation mark and disabled "Merge" button, you must rebase manually and fix any merge conflicts. - David Eichmann On 5/9/19 9:02 AM, Simon Peyton Jones via ghc-devs wrote: > It would be good to add this advice to our "how-to-contribute" pages. > > Simon > > | -----Original Message----- > | From: ghc-devs On Behalf Of Ömer Sinan > | Agacan > | Sent: 09 May 2019 07:46 > | To: Iavor Diatchki > | Cc: ghc-devs > | Subject: Re: Question about Gitlab MR workflow. > | > | Hi, > | > | > About 4: I really don't understand how this rebasing business is > | > intended to > | > work: every time I rebase, I new CI job is fired up. But, > | > presumably, while this is going, other things are going to be merged > | with `master`, so I'd need > | > to rebase again. So, when would I ever stop rebasing? > | > | Rebasing is actually not necessary. Marge adds your MR to the batch MR > | when it's approved and passed the tests. It doesn't have to be based on > | HEAD. So just don't bother with it. > | > | Only time I needed a rebase was when there was a failing test in HEAD and > | a commit that disabled it had just landed. My MR was not passing the tests > | because of the test so I had to rebase. > | > | Ömer > | > | Iavor Diatchki , 9 May 2019 Per, 02:19 tarihinde > | şunu yazdı: > | > > | > Hello, > | > > | > I've just had a go at making a small MR on our new Gitlab system, and > | > I am a bit confused about the intended workflow. I was following > | > these instructions : > | > > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl > | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing-bugs > | > &data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 > | > d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UBBq5BHxuAdK > | > ZRSkl3wVCCNoVC23%2FF7cUETgUQcdx30%3D&reserved=0 > | > > | > My question is about the steps after 2 (i.e., 3 and 4). Step 5 about > | > the beer I already did :-) Here was my experience so far: > | > > | > 1. I made the changes I wanted yesterday over lunch: the change was > | > quite trivial, I added a NOINLINE pragma and some comments and I mage > | > the MR. > | > > | > 2. Sometime in the evening (half a day later!) I got an e-mail from > | > the CI system that something had failed. It was quite hard to tell > | > what had failed, and after poking around at the logs, it seemed like > | > it was some sort of spurious failures because things had timed out, I > | > think? > | > > | > 3. Today I got some feedback from a reviewer about some changes I > | > should make to the MR. As I was working on those, I noticed that > | > every time I push to the MR, the CI is forking a new job. I cancelled > | > some of those manually, to save on resources, as they already seem to > | > be taking half a day. > | > > | > 4. After making the changes, I noticed that Gitlab is asking me to > | > rebase my changes because, presumably, some other things have already > | > been merged. It is easy enough to rebase my MR, but every time I do > | > so, this fires up a new CI job. And, of course, this is going to > | > keep happening, until I am lucky enough to rebase just at the right > | > time? This doesn't seem right. > | > > | > So my questions are specifically about step 3 and 4: > | > > | > About 3: wouldn't it make more sense to start firing up CI jobs > | > only after an MR has been approved for merging? > | > > | > About 4: I really don't understand how this rebasing business is > | > intended to work: every time I rebase, I new CI job is fired up. But, > | > presumably, while this is going, other things are going to be merged > | > with `master`, so I'd need to rebase again. So, when would I ever > | > stop rebasing? > | > Furthermore, in my case the rebase is trivial, but with a larger > | > patch, doing multiple rebases seems like a lot of wasted work. > | > > | > Any help would be appreciated! > | > > | > -Iavor > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. > | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01 > | > %7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6d44a2702%7C72f988 > | > bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXKtJMrTzTB4V2TJ > | > i%2F6%2F5uwfAdypps%3D&reserved=0 > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7261de3ecc064db43f9e08d6 > | d44a2702%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=wf4URw4jefgMCuXK > | tJMrTzTB4V2TJi%2F6%2F5uwfAdypps%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- 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 From ben at smart-cactus.org Thu May 9 14:47:16 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 09 May 2019 10:47:16 -0400 Subject: Question about Gitlab MR workflow. In-Reply-To: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> References: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> Message-ID: <87zhnvr8gj.fsf@smart-cactus.org> David Eichmann writes: > I've added a blurb in the wiki page about rebasing MRs: > Which Wiki page specifically? - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Thu May 9 15:45:21 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 May 2019 15:45:21 +0000 Subject: Old build system broken In-Reply-To: References: Message-ID: Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info No, it fails too: ./inplace/bin/ghc-stage1 --info Failed to read "target arch" value "" I’ll try git clean -xfd next. Simon From: Phyx Sent: 08 May 2019 20:29 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Devs Subject: Re: Old build system broken That looks like stage1 has been improperly configured. Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info Return anything sensible for target arch? I still use the make system exclusively and haven't noticed a failure. But my nightlies haven't kicked off yet today. Thanks, Tamar Sent from my Mobile On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs > wrote: 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 at MSRC-3645512:~/code/HEAD$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Thu May 9 15:47:14 2019 From: davide at well-typed.com (David Eichmann) Date: Thu, 9 May 2019 16:47:14 +0100 Subject: Question about Gitlab MR workflow. In-Reply-To: <87zhnvr8gj.fsf@smart-cactus.org> References: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> <87zhnvr8gj.fsf@smart-cactus.org> Message-ID: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs On 5/9/19 3:47 PM, Ben Gamari wrote: > David Eichmann writes: > >> I've added a blurb in the wiki page about rebasing MRs: >> > Which Wiki page specifically? > > - Ben -- 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 From simonpj at microsoft.com Thu May 9 15:49:56 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 May 2019 15:49:56 +0000 Subject: Question about Gitlab MR workflow. In-Reply-To: References: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> <87zhnvr8gj.fsf@smart-cactus.org> Message-ID: Thanks. That page is one click from the "Working conventions" page which is listed in the sidebar. (I wonder if "Working conventions" is the right title?) The numbering of the "Contributing a patch" page is deeply strange. 1,2,1,1,1,2,3,4. | -----Original Message----- | From: ghc-devs On Behalf Of David Eichmann | Sent: 09 May 2019 16:47 | To: Ben Gamari ; ghc-devs at haskell.org | Subject: Re: Question about Gitlab MR workflow. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- | bugs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=0 | | On 5/9/19 3:47 PM, Ben Gamari wrote: | > David Eichmann writes: | > | >> I've added a blurb in the wiki page about rebasing MRs: | >> | > Which Wiki page specifically? | > | > - Ben | | -- | David Eichmann, Haskell Consultant | Well-Typed LLP, | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- | typed.com&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=0 | | Registered in England & Wales, OC335890 | 118 Wymering Mansions, Wymering Road, London W9 2NF, England | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 From a.pelenitsyn at gmail.com Thu May 9 20:32:55 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 9 May 2019 23:32:55 +0300 Subject: Question about Gitlab MR workflow. In-Reply-To: References: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> <87zhnvr8gj.fsf@smart-cactus.org> Message-ID: I fixed the numbering and added some spaces here and there. -- Best, Artem On Thu, 9 May 2019 at 18:50, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Thanks. That page is one click from the "Working conventions" page which > is listed in the sidebar. (I wonder if "Working conventions" is the right > title?) > > The numbering of the "Contributing a patch" page is deeply strange. > 1,2,1,1,1,2,3,4. > > > > | -----Original Message----- > | From: ghc-devs On Behalf Of David > Eichmann > | Sent: 09 May 2019 16:47 > | To: Ben Gamari ; ghc-devs at haskell.org > | Subject: Re: Question about Gitlab MR workflow. > | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > | bugs&data=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3008d6 > | > d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY > | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=0 > | > | On 5/9/19 3:47 PM, Ben Gamari wrote: > | > David Eichmann writes: > | > > | >> I've added a blurb in the wiki page about rebasing MRs: > | >> > | > Which Wiki page specifically? > | > > | > - Ben > | > | -- > | David Eichmann, Haskell Consultant > | Well-Typed LLP, > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- > | typed.com&data=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3 > | > 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF > | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=0 > | > | Registered in England & Wales, OC335890 > | 118 Wymering Mansions, Wymering Road, London W9 2NF, England > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com > %7C7615e39c98f84ae42e3008d6 > | > d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp > | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri May 10 13:27:53 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 10 May 2019 22:27:53 +0900 Subject: Question about Gitlab MR workflow. In-Reply-To: References: <90b8103a-aadd-54eb-c8b2-c43200f5034c@well-typed.com> <87zhnvr8gj.fsf@smart-cactus.org> Message-ID: Hi everyone, Shall I change the link title of "Working conventions" on sidebar [1] to "How to contribute" or "Contributing to GHC" (or else) ? [1]: https://gitlab.haskell.org/ghc/ghc/wikis/home Regards, Takenobu On Fri, May 10, 2019 at 12:50 AM Simon Peyton Jones via ghc-devs wrote: > > Thanks. That page is one click from the "Working conventions" page which is listed in the sidebar. (I wonder if "Working conventions" is the right title?) > > The numbering of the "Contributing a patch" page is deeply strange. 1,2,1,1,1,2,3,4. > > > > | -----Original Message----- > | From: ghc-devs On Behalf Of David Eichmann > | Sent: 09 May 2019 16:47 > | To: Ben Gamari ; ghc-devs at haskell.org > | Subject: Re: Question about Gitlab MR workflow. > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > | bugs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY > | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=0 > | > | On 5/9/19 3:47 PM, Ben Gamari wrote: > | > David Eichmann writes: > | > > | >> I've added a blurb in the wiki page about rebasing MRs: > | >> > | > Which Wiki page specifically? > | > > | > - Ben > | > | -- > | David Eichmann, Haskell Consultant > | Well-Typed LLP, > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- > | typed.com&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 > | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF > | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=0 > | > | Registered in England & Wales, OC335890 > | 118 Wymering Mansions, Wymering Road, London W9 2NF, England > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp > | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From iavor.diatchki at gmail.com Fri May 10 20:33:52 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 10 May 2019 13:33:52 -0700 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: Having a read-only rendered version of all accepted proposals should probably be pretty simple---we can even host it in the same repo using "Github Pages". I don't know that we need anything more complex than that. On Thu, May 9, 2019 at 5:41 AM Joachim Breitner wrote: > > Hi, > > I looked into getting doi’s for our accepted proposals, but it looked > harder than it should be. > > Building a nice web page from our repository and publishing it on > GitHub pages, which can serve a custom domain like > ghc-proposals.haskell.org would not be hard. Matthew even started a > Makefile at some point that produces a reasonably nice output using > sphinx. > > Maybe only reason why I am hesitant to do so is that there is a feature > creep risk: > We start with a webpage that shows accepted proposals, > soon we’ll add functionality to list pending proposals and their status > (why not? They are just a GitHub API call away), > then we start using this page to actually drive the proposals (surely > we can use this to tally the votes), > and then we end up with a system that no longer has the “you just need > to know GitHub to use it” property that made us build a Github-centric > process in the first place. > > But maybe I am paranoid, and I should just set up the CI infrastructure > for Matthew’s sphinx build. > > BTW, in hindsight, I regret that we renumber proposals after > acceptance. It would be easier if they just retained the number of the > PR (other proposal processes out there do that). But that ship has > sailed. > > Cheers, > Joachim > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > I want to cite a GHC proposal but linking to github for it doesn't > > seem very official or permanent. > > > > Last year you also cited a proposal for your Haskell symposium paper > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > request which also doesn't seem ideal to me. > > > > Matt > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > wrote: > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > -----Original Message----- > > > > From: ghc-devs On Behalf Of Matthew > > > > Pickering > > > > Sent: 09 May 2019 09:40 > > > > To: GHC developers > > > > Subject: Website for viewing proposals > > > > > > > > Hi, > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > proposals rather than relying on github's RST viewer. > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > automatically when a new accepted proposal is merged? > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > to set up something similar on github. > > > > > > > > Cheers, > > > > > > > > Matt > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Fri May 10 22:06:16 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 10 May 2019 23:06:16 +0100 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: I agree a simple static site is all it needs, as Joachim points out I already implemented the basic site generation. The main question is about where the site lives and what the deployment mechanism is. If it's tied to the ghc-proposal repo then I can't do anything but if it's a subdomain of `haskell.org` then I could be more potent. Cheers, Matt On Fri, May 10, 2019 at 9:34 PM Iavor Diatchki wrote: > > Having a read-only rendered version of all accepted proposals should > probably be pretty simple---we can even host it in the same repo using > "Github Pages". I don't know that we need anything more complex > than that. > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > wrote: > > > > Hi, > > > > I looked into getting doi’s for our accepted proposals, but it looked > > harder than it should be. > > > > Building a nice web page from our repository and publishing it on > > GitHub pages, which can serve a custom domain like > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > Makefile at some point that produces a reasonably nice output using > > sphinx. > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > creep risk: > > We start with a webpage that shows accepted proposals, > > soon we’ll add functionality to list pending proposals and their status > > (why not? They are just a GitHub API call away), > > then we start using this page to actually drive the proposals (surely > > we can use this to tally the votes), > > and then we end up with a system that no longer has the “you just need > > to know GitHub to use it” property that made us build a Github-centric > > process in the first place. > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > for Matthew’s sphinx build. > > > > BTW, in hindsight, I regret that we renumber proposals after > > acceptance. It would be easier if they just retained the number of the > > PR (other proposal processes out there do that). But that ship has > > sailed. > > > > Cheers, > > Joachim > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > I want to cite a GHC proposal but linking to github for it doesn't > > > seem very official or permanent. > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > request which also doesn't seem ideal to me. > > > > > > Matt > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > wrote: > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > -----Original Message----- > > > > > From: ghc-devs On Behalf Of Matthew > > > > > Pickering > > > > > Sent: 09 May 2019 09:40 > > > > > To: GHC developers > > > > > Subject: Website for viewing proposals > > > > > > > > > > Hi, > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > to set up something similar on github. > > > > > > > > > > Cheers, > > > > > > > > > > Matt > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Fri May 10 22:13:23 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 May 2019 00:13:23 +0200 Subject: Website for viewing proposals In-Reply-To: References: Message-ID: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Hi, given that Matthew already created a sphinx setup, GitHub pages isn’t optimal. You need to use some other CI system like Travis to actually build the page and push it, which I have set up a few times and is possible, not completely straight-forward. What is straight-forward is readthedocs.io, where I essentially just pressed one button and got this: https://ghc-proposals.readthedocs.io/en/latest/ Neat, isn’t it? I will clean up the section numbering. The only thing I’d like to do before making this official is to use a more permanent URL, in case we move this somewhere else. For that I’d need a haskell.org admin to add a CNAME from ghc-proposals.haskell.org to readthedocs.io CC’ing gershom, hope he is the right contact for this task. Cheers, Joachim Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > Having a read-only rendered version of all accepted proposals should > probably be pretty simple---we can even host it in the same repo using > "Github Pages". I don't know that we need anything more complex > than that. > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > wrote: > > Hi, > > > > I looked into getting doi’s for our accepted proposals, but it looked > > harder than it should be. > > > > Building a nice web page from our repository and publishing it on > > GitHub pages, which can serve a custom domain like > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > Makefile at some point that produces a reasonably nice output using > > sphinx. > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > creep risk: > > We start with a webpage that shows accepted proposals, > > soon we’ll add functionality to list pending proposals and their status > > (why not? They are just a GitHub API call away), > > then we start using this page to actually drive the proposals (surely > > we can use this to tally the votes), > > and then we end up with a system that no longer has the “you just need > > to know GitHub to use it” property that made us build a Github-centric > > process in the first place. > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > for Matthew’s sphinx build. > > > > BTW, in hindsight, I regret that we renumber proposals after > > acceptance. It would be easier if they just retained the number of the > > PR (other proposal processes out there do that). But that ship has > > sailed. > > > > Cheers, > > Joachim > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > I want to cite a GHC proposal but linking to github for it doesn't > > > seem very official or permanent. > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > request which also doesn't seem ideal to me. > > > > > > Matt > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > wrote: > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > -----Original Message----- > > > > > From: ghc-devs On Behalf Of Matthew > > > > > Pickering > > > > > Sent: 09 May 2019 09:40 > > > > > To: GHC developers > > > > > Subject: Website for viewing proposals > > > > > > > > > > Hi, > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > to set up something similar on github. > > > > > > > > > > Cheers, > > > > > > > > > > Matt > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From matthewtpickering at gmail.com Fri May 10 22:22:41 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 10 May 2019 23:22:41 +0100 Subject: Website for viewing proposals In-Reply-To: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: Thanks Joachim, that looks good. I might have a go styling the site this weekend to make it fit in more with the Haskell.org theme. Matt On Fri, May 10, 2019 at 11:13 PM Joachim Breitner wrote: > > Hi, > > given that Matthew already created a sphinx setup, GitHub pages isn’t > optimal. You need to use some other CI system like Travis to actually > build the page and push it, which I have set up a few times and is > possible, not completely straight-forward. What is straight-forward is > readthedocs.io, where I essentially just pressed one button and got > this: > > https://ghc-proposals.readthedocs.io/en/latest/ > > Neat, isn’t it? I will clean up the section numbering. > > > The only thing I’d like to do before making this official is to use a > more permanent URL, in case we move this somewhere else. For that I’d > need a haskell.org admin to add a CNAME from > > ghc-proposals.haskell.org > > to > > readthedocs.io > > CC’ing gershom, hope he is the right contact for this task. > > Cheers, > Joachim > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > Having a read-only rendered version of all accepted proposals should > > probably be pretty simple---we can even host it in the same repo using > > "Github Pages". I don't know that we need anything more complex > > than that. > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > wrote: > > > Hi, > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > harder than it should be. > > > > > > Building a nice web page from our repository and publishing it on > > > GitHub pages, which can serve a custom domain like > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > Makefile at some point that produces a reasonably nice output using > > > sphinx. > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > creep risk: > > > We start with a webpage that shows accepted proposals, > > > soon we’ll add functionality to list pending proposals and their status > > > (why not? They are just a GitHub API call away), > > > then we start using this page to actually drive the proposals (surely > > > we can use this to tally the votes), > > > and then we end up with a system that no longer has the “you just need > > > to know GitHub to use it” property that made us build a Github-centric > > > process in the first place. > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > for Matthew’s sphinx build. > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > acceptance. It would be easier if they just retained the number of the > > > PR (other proposal processes out there do that). But that ship has > > > sailed. > > > > > > Cheers, > > > Joachim > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > seem very official or permanent. > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > request which also doesn't seem ideal to me. > > > > > > > > Matt > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > wrote: > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > -----Original Message----- > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > Pickering > > > > > > Sent: 09 May 2019 09:40 > > > > > > To: GHC developers > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > Hi, > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > to set up something similar on github. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Matt > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list > > > > > > ghc-devs at haskell.org > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Fri May 10 22:25:52 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 May 2019 00:25:52 +0200 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: <0a8d02264df9abe90b25d08428728220c02e9d83.camel@joachim-breitner.de> Hi, Am Freitag, den 10.05.2019, 23:22 +0100 schrieb Matthew Pickering: > I might have a go styling the site this weekend to make it fit in more > with the Haskell.org theme. that’d be awesome. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From gershomb at gmail.com Fri May 10 22:26:13 2019 From: gershomb at gmail.com (Gershom B) Date: Fri, 10 May 2019 18:26:13 -0400 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: Joachim -- will the readthedocs settings automatically know how to direct things once the cname is set? Also, I'd note that the documentation needs a little cleanup to make clear that this is the page for _accepted_ proposals, not all proposals -- perhaps it should also link back to the PR tracker as well? (And also the nice generation makes obvious that there are a few too many proposals numbered "1" :-)). Along those lines too, perhaps the name should be bikeshedded a bit for that reason -- ghc-proposals.haskell.org makes it look like that's where I'd go to get all proposals, not just the accepted ones. Cheers, Gershom On Fri, May 10, 2019 at 6:22 PM Matthew Pickering wrote: > > Thanks Joachim, that looks good. > > I might have a go styling the site this weekend to make it fit in more > with the Haskell.org theme. > > Matt > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > wrote: > > > > Hi, > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > optimal. You need to use some other CI system like Travis to actually > > build the page and push it, which I have set up a few times and is > > possible, not completely straight-forward. What is straight-forward is > > readthedocs.io, where I essentially just pressed one button and got > > this: > > > > https://ghc-proposals.readthedocs.io/en/latest/ > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > The only thing I’d like to do before making this official is to use a > > more permanent URL, in case we move this somewhere else. For that I’d > > need a haskell.org admin to add a CNAME from > > > > ghc-proposals.haskell.org > > > > to > > > > readthedocs.io > > > > CC’ing gershom, hope he is the right contact for this task. > > > > Cheers, > > Joachim > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > Having a read-only rendered version of all accepted proposals should > > > probably be pretty simple---we can even host it in the same repo using > > > "Github Pages". I don't know that we need anything more complex > > > than that. > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > wrote: > > > > Hi, > > > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > > harder than it should be. > > > > > > > > Building a nice web page from our repository and publishing it on > > > > GitHub pages, which can serve a custom domain like > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > Makefile at some point that produces a reasonably nice output using > > > > sphinx. > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > > creep risk: > > > > We start with a webpage that shows accepted proposals, > > > > soon we’ll add functionality to list pending proposals and their status > > > > (why not? They are just a GitHub API call away), > > > > then we start using this page to actually drive the proposals (surely > > > > we can use this to tally the votes), > > > > and then we end up with a system that no longer has the “you just need > > > > to know GitHub to use it” property that made us build a Github-centric > > > > process in the first place. > > > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > > for Matthew’s sphinx build. > > > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > > acceptance. It would be easier if they just retained the number of the > > > > PR (other proposal processes out there do that). But that ship has > > > > sailed. > > > > > > > > Cheers, > > > > Joachim > > > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > > seem very official or permanent. > > > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > > request which also doesn't seem ideal to me. > > > > > > > > > > Matt > > > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > > wrote: > > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > > Pickering > > > > > > > Sent: 09 May 2019 09:40 > > > > > > > To: GHC developers > > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > > to set up something similar on github. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Matt > > > > > > > _______________________________________________ > > > > > > > ghc-devs mailing list > > > > > > > ghc-devs at haskell.org > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Fri May 10 22:29:40 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 May 2019 00:29:40 +0200 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: <5a1c8cbcf65d79499eff96f38e5bb93aa7a65e1c.camel@joachim-breitner.de> Hi, Am Freitag, den 10.05.2019, 18:26 -0400 schrieb Gershom B: > Joachim -- will the readthedocs settings automatically know how to > direct things once the cname is set? yes I have configured things on that side already. Should work right away. > Also, I'd note that the documentation needs a little cleanup to make > clear that this is the page for _accepted_ proposals, not all > proposals -- perhaps it should also link back to the PR tracker as > well? (And also the nice generation makes obvious that there are a few > too many proposals numbered "1" :-)). Reload, both fixed a few minutes ago. > Along those lines too, perhaps > the name should be bikeshedded a bit for that reason -- > ghc-proposals.haskell.org makes it look like that's where I'd go to > get all proposals, not just the accepted ones. accepted-ghc-proposals.haskell.org doesn’t make a pretty domain name. We will add a intro to that page explaining what this page is, and point to the GitHub repo for more details. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From matthewtpickering at gmail.com Fri May 10 22:30:50 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 10 May 2019 23:30:50 +0100 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: Perhaps the correct URL should be ghc.haskell.org/proposals but that redirects to https://www.haskell.org/ghc/ So is the correct URL https://www.haskell.org/ghc/proposals ? Anyway, there should probably be some mention of the proposals process on the GHC website which is sorely unloved. Matt On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > Joachim -- will the readthedocs settings automatically know how to > direct things once the cname is set? > > Also, I'd note that the documentation needs a little cleanup to make > clear that this is the page for _accepted_ proposals, not all > proposals -- perhaps it should also link back to the PR tracker as > well? (And also the nice generation makes obvious that there are a few > too many proposals numbered "1" :-)). Along those lines too, perhaps > the name should be bikeshedded a bit for that reason -- > ghc-proposals.haskell.org makes it look like that's where I'd go to > get all proposals, not just the accepted ones. > > Cheers, > Gershom > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > wrote: > > > > Thanks Joachim, that looks good. > > > > I might have a go styling the site this weekend to make it fit in more > > with the Haskell.org theme. > > > > Matt > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > wrote: > > > > > > Hi, > > > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > > optimal. You need to use some other CI system like Travis to actually > > > build the page and push it, which I have set up a few times and is > > > possible, not completely straight-forward. What is straight-forward is > > > readthedocs.io, where I essentially just pressed one button and got > > > this: > > > > > > https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > The only thing I’d like to do before making this official is to use a > > > more permanent URL, in case we move this somewhere else. For that I’d > > > need a haskell.org admin to add a CNAME from > > > > > > ghc-proposals.haskell.org > > > > > > to > > > > > > readthedocs.io > > > > > > CC’ing gershom, hope he is the right contact for this task. > > > > > > Cheers, > > > Joachim > > > > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > > Having a read-only rendered version of all accepted proposals should > > > > probably be pretty simple---we can even host it in the same repo using > > > > "Github Pages". I don't know that we need anything more complex > > > > than that. > > > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > > wrote: > > > > > Hi, > > > > > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > > > harder than it should be. > > > > > > > > > > Building a nice web page from our repository and publishing it on > > > > > GitHub pages, which can serve a custom domain like > > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > > Makefile at some point that produces a reasonably nice output using > > > > > sphinx. > > > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > > > creep risk: > > > > > We start with a webpage that shows accepted proposals, > > > > > soon we’ll add functionality to list pending proposals and their status > > > > > (why not? They are just a GitHub API call away), > > > > > then we start using this page to actually drive the proposals (surely > > > > > we can use this to tally the votes), > > > > > and then we end up with a system that no longer has the “you just need > > > > > to know GitHub to use it” property that made us build a Github-centric > > > > > process in the first place. > > > > > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > > > for Matthew’s sphinx build. > > > > > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > > > acceptance. It would be easier if they just retained the number of the > > > > > PR (other proposal processes out there do that). But that ship has > > > > > sailed. > > > > > > > > > > Cheers, > > > > > Joachim > > > > > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > > > seem very official or permanent. > > > > > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > > > request which also doesn't seem ideal to me. > > > > > > > > > > > > Matt > > > > > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > > > wrote: > > > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > > > Pickering > > > > > > > > Sent: 09 May 2019 09:40 > > > > > > > > To: GHC developers > > > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > > > to set up something similar on github. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Matt > > > > > > > > _______________________________________________ > > > > > > > > ghc-devs mailing list > > > > > > > > ghc-devs at haskell.org > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list > > > > > > ghc-devs at haskell.org > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > > > > > Joachim Breitner > > > > > mail at joachim-breitner.de > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Fri May 10 22:33:02 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 May 2019 00:33:02 +0200 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> Message-ID: <0e72c87358b02773ba16c599fb002a94d3d895cf.camel@joachim-breitner.de> Hi, unfortunately it has to be a dedicated domain, not an URL on some other domain, to get the easy, no-additional-work hosting from readthedocs. Cheers, Joachim Am Freitag, den 10.05.2019, 23:30 +0100 schrieb Matthew Pickering: > Perhaps the correct URL should be > > ghc.haskell.org/proposals > > but that redirects to https://www.haskell.org/ghc/ > > So is the correct URL https://www.haskell.org/ghc/proposals ? > > Anyway, there should probably be some mention of the proposals process > on the GHC website which is sorely unloved. > > Matt > > On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > Joachim -- will the readthedocs settings automatically know how to > > direct things once the cname is set? > > > > Also, I'd note that the documentation needs a little cleanup to make > > clear that this is the page for _accepted_ proposals, not all > > proposals -- perhaps it should also link back to the PR tracker as > > well? (And also the nice generation makes obvious that there are a few > > too many proposals numbered "1" :-)). Along those lines too, perhaps > > the name should be bikeshedded a bit for that reason -- > > ghc-proposals.haskell.org makes it look like that's where I'd go to > > get all proposals, not just the accepted ones. > > > > Cheers, > > Gershom > > > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > > wrote: > > > Thanks Joachim, that looks good. > > > > > > I might have a go styling the site this weekend to make it fit in more > > > with the Haskell.org theme. > > > > > > Matt > > > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > > wrote: > > > > Hi, > > > > > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > > > optimal. You need to use some other CI system like Travis to actually > > > > build the page and push it, which I have set up a few times and is > > > > possible, not completely straight-forward. What is straight-forward is > > > > readthedocs.io, where I essentially just pressed one button and got > > > > this: > > > > > > > > https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > > > > The only thing I’d like to do before making this official is to use a > > > > more permanent URL, in case we move this somewhere else. For that I’d > > > > need a haskell.org admin to add a CNAME from > > > > > > > > ghc-proposals.haskell.org > > > > > > > > to > > > > > > > > readthedocs.io > > > > > > > > CC’ing gershom, hope he is the right contact for this task. > > > > > > > > Cheers, > > > > Joachim > > > > > > > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > > > Having a read-only rendered version of all accepted proposals should > > > > > probably be pretty simple---we can even host it in the same repo using > > > > > "Github Pages". I don't know that we need anything more complex > > > > > than that. > > > > > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > > > > harder than it should be. > > > > > > > > > > > > Building a nice web page from our repository and publishing it on > > > > > > GitHub pages, which can serve a custom domain like > > > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > > > Makefile at some point that produces a reasonably nice output using > > > > > > sphinx. > > > > > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > > > > creep risk: > > > > > > We start with a webpage that shows accepted proposals, > > > > > > soon we’ll add functionality to list pending proposals and their status > > > > > > (why not? They are just a GitHub API call away), > > > > > > then we start using this page to actually drive the proposals (surely > > > > > > we can use this to tally the votes), > > > > > > and then we end up with a system that no longer has the “you just need > > > > > > to know GitHub to use it” property that made us build a Github-centric > > > > > > process in the first place. > > > > > > > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > > > > for Matthew’s sphinx build. > > > > > > > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > > > > acceptance. It would be easier if they just retained the number of the > > > > > > PR (other proposal processes out there do that). But that ship has > > > > > > sailed. > > > > > > > > > > > > Cheers, > > > > > > Joachim > > > > > > > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > > > > seem very official or permanent. > > > > > > > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > > > > request which also doesn't seem ideal to me. > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > > > > wrote: > > > > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > > > > Pickering > > > > > > > > > Sent: 09 May 2019 09:40 > > > > > > > > > To: GHC developers > > > > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > > > > to set up something similar on github. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > _______________________________________________ > > > > > > > > > ghc-devs mailing list > > > > > > > > > ghc-devs at haskell.org > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > > > > _______________________________________________ > > > > > > > ghc-devs mailing list > > > > > > > ghc-devs at haskell.org > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > > > > > Joachim Breitner > > > > > > mail at joachim-breitner.de > > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list > > > > > > ghc-devs at haskell.org > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From matthewtpickering at gmail.com Fri May 10 22:34:34 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 10 May 2019 23:34:34 +0100 Subject: Website for viewing proposals In-Reply-To: <0e72c87358b02773ba16c599fb002a94d3d895cf.camel@joachim-breitner.de> References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> <0e72c87358b02773ba16c599fb002a94d3d895cf.camel@joachim-breitner.de> Message-ID: The GHC website is already deployed by gitlab. It could be possible to set up a nightly job which clones the ghc-proposals repo and deploys it in a similar manner. I do feel that it would be very unfortunate if the proposals were distant from the supposed official GHC homepage. Matt On Fri, May 10, 2019 at 11:33 PM Joachim Breitner wrote: > > Hi, > > unfortunately it has to be a dedicated domain, not an URL on some other > domain, to get the easy, no-additional-work hosting from readthedocs. > > Cheers, > Joachim > > Am Freitag, den 10.05.2019, 23:30 +0100 schrieb Matthew Pickering: > > Perhaps the correct URL should be > > > > ghc.haskell.org/proposals > > > > but that redirects to https://www.haskell.org/ghc/ > > > > So is the correct URL https://www.haskell.org/ghc/proposals ? > > > > Anyway, there should probably be some mention of the proposals process > > on the GHC website which is sorely unloved. > > > > Matt > > > > On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > > Joachim -- will the readthedocs settings automatically know how to > > > direct things once the cname is set? > > > > > > Also, I'd note that the documentation needs a little cleanup to make > > > clear that this is the page for _accepted_ proposals, not all > > > proposals -- perhaps it should also link back to the PR tracker as > > > well? (And also the nice generation makes obvious that there are a few > > > too many proposals numbered "1" :-)). Along those lines too, perhaps > > > the name should be bikeshedded a bit for that reason -- > > > ghc-proposals.haskell.org makes it look like that's where I'd go to > > > get all proposals, not just the accepted ones. > > > > > > Cheers, > > > Gershom > > > > > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > > > wrote: > > > > Thanks Joachim, that looks good. > > > > > > > > I might have a go styling the site this weekend to make it fit in more > > > > with the Haskell.org theme. > > > > > > > > Matt > > > > > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > > > wrote: > > > > > Hi, > > > > > > > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > > > > optimal. You need to use some other CI system like Travis to actually > > > > > build the page and push it, which I have set up a few times and is > > > > > possible, not completely straight-forward. What is straight-forward is > > > > > readthedocs.io, where I essentially just pressed one button and got > > > > > this: > > > > > > > > > > https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > > > > > > > The only thing I’d like to do before making this official is to use a > > > > > more permanent URL, in case we move this somewhere else. For that I’d > > > > > need a haskell.org admin to add a CNAME from > > > > > > > > > > ghc-proposals.haskell.org > > > > > > > > > > to > > > > > > > > > > readthedocs.io > > > > > > > > > > CC’ing gershom, hope he is the right contact for this task. > > > > > > > > > > Cheers, > > > > > Joachim > > > > > > > > > > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > > > > Having a read-only rendered version of all accepted proposals should > > > > > > probably be pretty simple---we can even host it in the same repo using > > > > > > "Github Pages". I don't know that we need anything more complex > > > > > > than that. > > > > > > > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > > > > > harder than it should be. > > > > > > > > > > > > > > Building a nice web page from our repository and publishing it on > > > > > > > GitHub pages, which can serve a custom domain like > > > > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > > > > Makefile at some point that produces a reasonably nice output using > > > > > > > sphinx. > > > > > > > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > > > > > creep risk: > > > > > > > We start with a webpage that shows accepted proposals, > > > > > > > soon we’ll add functionality to list pending proposals and their status > > > > > > > (why not? They are just a GitHub API call away), > > > > > > > then we start using this page to actually drive the proposals (surely > > > > > > > we can use this to tally the votes), > > > > > > > and then we end up with a system that no longer has the “you just need > > > > > > > to know GitHub to use it” property that made us build a Github-centric > > > > > > > process in the first place. > > > > > > > > > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > > > > > for Matthew’s sphinx build. > > > > > > > > > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > > > > > acceptance. It would be easier if they just retained the number of the > > > > > > > PR (other proposal processes out there do that). But that ship has > > > > > > > sailed. > > > > > > > > > > > > > > Cheers, > > > > > > > Joachim > > > > > > > > > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > > > > > seem very official or permanent. > > > > > > > > > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > > > > > request which also doesn't seem ideal to me. > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > > > > > wrote: > > > > > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > > > > > Pickering > > > > > > > > > > Sent: 09 May 2019 09:40 > > > > > > > > > > To: GHC developers > > > > > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > > > > > to set up something similar on github. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > _______________________________________________ > > > > > > > > > > ghc-devs mailing list > > > > > > > > > > ghc-devs at haskell.org > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > > > > > _______________________________________________ > > > > > > > > ghc-devs mailing list > > > > > > > > ghc-devs at haskell.org > > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > -- > > > > > > > Joachim Breitner > > > > > > > mail at joachim-breitner.de > > > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > ghc-devs mailing list > > > > > > > ghc-devs at haskell.org > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > > > > > Joachim Breitner > > > > > mail at joachim-breitner.de > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > From mail at joachim-breitner.de Fri May 10 22:40:00 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 11 May 2019 00:40:00 +0200 Subject: Website for viewing proposals In-Reply-To: References: <566fc366ae697f28d71ac54ce83a6bf6c9ceb6c3.camel@joachim-breitner.de> <0e72c87358b02773ba16c599fb002a94d3d895cf.camel@joachim-breitner.de> Message-ID: <9f26f5e141276971f27f23fa48b374b75d23f11e.camel@joachim-breitner.de> Hi, we have a solution that needed 10 mins of setup and is completely self- hosting otherwise, with a proven, open-source friendly provider, at the expense of a possibly odd (but custom) domain name. I think this is very good effort to result ratio. If someone wants do to recreate that manually, that’s ok with it, but maybe I’m too old and lazy to be excited by the process. Anyways, bedtime here. I’ll read tomorrow if we shall use this, of if someone else steps up to be the master of the accepted ghc proposals webpage deployment, and has created something more bespoke (in which I case I can remove the readthedocs setup again). Cheer, Joachim Am Freitag, den 10.05.2019, 23:34 +0100 schrieb Matthew Pickering: > The GHC website is already deployed by gitlab. It could be possible to > set up a nightly job which clones the ghc-proposals repo and deploys > it in a similar manner. > > I do feel that it would be very unfortunate if the proposals were > distant from the supposed official GHC homepage. > > Matt > > On Fri, May 10, 2019 at 11:33 PM Joachim Breitner > wrote: > > Hi, > > > > unfortunately it has to be a dedicated domain, not an URL on some other > > domain, to get the easy, no-additional-work hosting from readthedocs. > > > > Cheers, > > Joachim > > > > Am Freitag, den 10.05.2019, 23:30 +0100 schrieb Matthew Pickering: > > > Perhaps the correct URL should be > > > > > > ghc.haskell.org/proposals > > > > > > but that redirects to https://www.haskell.org/ghc/ > > > > > > So is the correct URL https://www.haskell.org/ghc/proposals ? > > > > > > Anyway, there should probably be some mention of the proposals process > > > on the GHC website which is sorely unloved. > > > > > > Matt > > > > > > On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > > > Joachim -- will the readthedocs settings automatically know how to > > > > direct things once the cname is set? > > > > > > > > Also, I'd note that the documentation needs a little cleanup to make > > > > clear that this is the page for _accepted_ proposals, not all > > > > proposals -- perhaps it should also link back to the PR tracker as > > > > well? (And also the nice generation makes obvious that there are a few > > > > too many proposals numbered "1" :-)). Along those lines too, perhaps > > > > the name should be bikeshedded a bit for that reason -- > > > > ghc-proposals.haskell.org makes it look like that's where I'd go to > > > > get all proposals, not just the accepted ones. > > > > > > > > Cheers, > > > > Gershom > > > > > > > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > > > > wrote: > > > > > Thanks Joachim, that looks good. > > > > > > > > > > I might have a go styling the site this weekend to make it fit in more > > > > > with the Haskell.org theme. > > > > > > > > > > Matt > > > > > > > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > > > > > optimal. You need to use some other CI system like Travis to actually > > > > > > build the page and push it, which I have set up a few times and is > > > > > > possible, not completely straight-forward. What is straight-forward is > > > > > > readthedocs.io, where I essentially just pressed one button and got > > > > > > this: > > > > > > > > > > > > https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > > > > > > > > > > The only thing I’d like to do before making this official is to use a > > > > > > more permanent URL, in case we move this somewhere else. For that I’d > > > > > > need a haskell.org admin to add a CNAME from > > > > > > > > > > > > ghc-proposals.haskell.org > > > > > > > > > > > > to > > > > > > > > > > > > readthedocs.io > > > > > > > > > > > > CC’ing gershom, hope he is the right contact for this task. > > > > > > > > > > > > Cheers, > > > > > > Joachim > > > > > > > > > > > > > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > > > > > Having a read-only rendered version of all accepted proposals should > > > > > > > probably be pretty simple---we can even host it in the same repo using > > > > > > > "Github Pages". I don't know that we need anything more complex > > > > > > > than that. > > > > > > > > > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I looked into getting doi’s for our accepted proposals, but it looked > > > > > > > > harder than it should be. > > > > > > > > > > > > > > > > Building a nice web page from our repository and publishing it on > > > > > > > > GitHub pages, which can serve a custom domain like > > > > > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > > > > > Makefile at some point that produces a reasonably nice output using > > > > > > > > sphinx. > > > > > > > > > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > > > > > > > creep risk: > > > > > > > > We start with a webpage that shows accepted proposals, > > > > > > > > soon we’ll add functionality to list pending proposals and their status > > > > > > > > (why not? They are just a GitHub API call away), > > > > > > > > then we start using this page to actually drive the proposals (surely > > > > > > > > we can use this to tally the votes), > > > > > > > > and then we end up with a system that no longer has the “you just need > > > > > > > > to know GitHub to use it” property that made us build a Github-centric > > > > > > > > process in the first place. > > > > > > > > > > > > > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > > > > > > > for Matthew’s sphinx build. > > > > > > > > > > > > > > > > BTW, in hindsight, I regret that we renumber proposals after > > > > > > > > acceptance. It would be easier if they just retained the number of the > > > > > > > > PR (other proposal processes out there do that). But that ship has > > > > > > > > sailed. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Joachim > > > > > > > > > > > > > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > > > > > > > I want to cite a GHC proposal but linking to github for it doesn't > > > > > > > > > seem very official or permanent. > > > > > > > > > > > > > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > > > > > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > > > > > > > request which also doesn't seem ideal to me. > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > > > > > > > wrote: > > > > > > > > > > Interesting. How would it differ from what we have (i.e. github's RST viewer)? > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ghc-devs On Behalf Of Matthew > > > > > > > > > > > Pickering > > > > > > > > > > > Sent: 09 May 2019 09:40 > > > > > > > > > > > To: GHC developers > > > > > > > > > > > Subject: Website for viewing proposals > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > > > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > > > > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to > > > > > > > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > > > > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > > > > > > > deployment would be easy using our CI infrastructure but I don't know how > > > > > > > > > > > to set up something similar on github. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > ghc-devs mailing list > > > > > > > > > > > ghc-devs at haskell.org > > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > > > > > > > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > > > > > > > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > > > > > > > > > _______________________________________________ > > > > > > > > > ghc-devs mailing list > > > > > > > > > ghc-devs at haskell.org > > > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > -- > > > > > > > > Joachim Breitner > > > > > > > > mail at joachim-breitner.de > > > > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > ghc-devs mailing list > > > > > > > > ghc-devs at haskell.org > > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > > > > > Joachim Breitner > > > > > > mail at joachim-breitner.de > > > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list > > > > > > ghc-devs at haskell.org > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chessai1996 at gmail.com Sat May 11 20:01:23 2019 From: chessai1996 at gmail.com (chessai .) Date: Sat, 11 May 2019 16:01:23 -0400 Subject: Commit searching Message-ID: Devs, Is there a way to take the sha1 of a git commit and find which released version of GHC contains that commit, without resorting to a manual cross-reference? Is it possible there could be some sort of webpage where this information could be made accessible, just by pasting in a commit? From a.pelenitsyn at gmail.com Sat May 11 20:26:48 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sat, 11 May 2019 23:26:48 +0300 Subject: Commit searching In-Reply-To: References: Message-ID: Hi chessai, What I usually do for this is open up the corresponding GitHub page, e.g.: https://github.com/ghc/ghc/commit/bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee where I see the list of branches the commit was added to, below the commit message (note that you have to click "..." to see the full list of branches). The branches ending with `-release` (e.g. ghc-8.6.5-release) answer your question, I believe. -- Best, Artem On Sat, 11 May 2019 at 23:01, chessai . wrote: > Devs, > > Is there a way to take the sha1 of a git commit and find which > released version of GHC contains that commit, without resorting to a > manual cross-reference? > > Is it possible there could be some sort of webpage where this > information could be made accessible, just by pasting in a commit? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krz.gogolewski at gmail.com Sat May 11 22:36:48 2019 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Sun, 12 May 2019 00:36:48 +0200 Subject: Commit searching In-Reply-To: References: Message-ID: Hi, You can use git tag --contains to see the list of tags containing a commit; this goes back to ghc-7.2. A different option is to checkout the configure.ac file for a given commit; there'll be a line such as AC_INIT([The Glorious Glasgow Haskell Compilation System], [6.9], [ glasgow-haskell-bugs at haskell.org], [ghc]) which means that GHC was 6.9 (so the given commit was released in 6.10). Of course both methods don't account for cherry-picks, the same change with a different sha could have landed in a bugfix release. -Krzysztof On Sat, May 11, 2019 at 10:27 PM Artem Pelenitsyn wrote: > Hi chessai, > > What I usually do for this is open up the corresponding GitHub page, e.g.: > > https://github.com/ghc/ghc/commit/bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee > > where I see the list of branches the commit was added to, below the commit > message (note that you have to click "..." to see the full list of > branches). The branches ending with `-release` (e.g. ghc-8.6.5-release) > answer your question, I believe. > > -- > Best, Artem > > > On Sat, 11 May 2019 at 23:01, chessai . wrote: > >> Devs, >> >> Is there a way to take the sha1 of a git commit and find which >> released version of GHC contains that commit, without resorting to a >> manual cross-reference? >> >> Is it possible there could be some sort of webpage where this >> information could be made accessible, just by pasting in a commit? >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun May 12 12:23:35 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 12 May 2019 08:23:35 -0400 Subject: CI on forked projects: Darwin woes In-Reply-To: References: Message-ID: I’m the root care taker on the Mac ci box. One issue here is that while forks and branches both get ci, only branches are visible to non admin roles. So there could be a kajillion other folks forks going on or something. timeouts sound like gitlab side thing. I definitely have had to restart jobs before. For what it’s worth: it’s hosted at Mac stadium so it’s actually in a data center. Plus after Ben added some disk space cleanup scripts to the ci its had zero administrative interventions for months. Plus it’s configured to actually have a working gitlab runner even if a reboot happens (took a while to figure out that bit of Mac admin ) Failures on the Mac mini side tend to have more informative failure modes. Timeouts are a gitlab runner thing. And I’ve definitely had to tickle restarting in my own patches. Next time you hit a failure could you share with the devs list and or #ghc irc ? On Wed, May 8, 2019 at 2:59 PM Iavor Diatchki wrote: > I think there was the ghc-devops-group list, but I don't know if it is > still active, and I kind of like to not have to follow too many lists. > > For example, I had also not realized that it is an option to push to > branches on the main project, and have been using my own fork, > so thanks for posting this here! > > -Iavor > > > On Wed, May 8, 2019 at 11:40 AM Kevin Buhr wrote: > > > > Over the past few days, I've submitted several merge requests from > > branches on my forked project (mostly because I didn't even realize > > pushing to a branch on the main project was an alternative). > > > > When those MRs run under CI, I've had a bunch of failures due to > > timeouts waiting on a darwin-x86_64 runner. I was a little mystified > > that no other pipelines besides mine seemed to be having this problem, > > but I've come to understand that MRs submitted from branches on the main > > project use a different, larger set of runners than the shared runners > > used by MRs from branches on forked projects. > > > > Under my project, I can view the available shared runners under the > > "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that > > there's only one darwin runner ("b4bc6410" / > > mac-mini-x86_64-darwin-davxkc). This machine is a trooper, but it > > unfortunately shares a circuit breaker with a toaster oven, so it goes > > offline every time someone wants a bagel, and the rest of the time it > > must be running CI for a few hundred GHC forks. > > > > I ended up deleting an (unreviewed) MR sourced from my branch, and > > pushing it to the main project and resubmitting just to get the CI to > > run. (Admittedly, it failed, but at least not on darwin!) I obviously > > don't want to do this with the merge requests that have already been > > reviewed. > > > > Is this a temporary problem? Is there anything I can do other than keep > > retrying the darwin jobs every couple days? > > > > Also, is there a better place than "ghc-dev" to send these sorts of > > GitLab/CI issues? I thought there might be a project dedicated to it, > > but if so I couldn't find it. > > > > > > -- > > Kevin Buhr > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Sun May 12 14:37:51 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 12 May 2019 10:37:51 -0400 Subject: Commit searching In-Reply-To: References: Message-ID: Both very useful replies, thank you very much. On Sat, May 11, 2019, 6:37 PM Krzysztof Gogolewski wrote: > Hi, > > You can use git tag --contains to see the list of tags containing a > commit; this goes back to ghc-7.2. > > A different option is to checkout the configure.ac file for a given > commit; there'll be a line such as > AC_INIT([The Glorious Glasgow Haskell Compilation System], [6.9], [ > glasgow-haskell-bugs at haskell.org], [ghc]) > which means that GHC was 6.9 (so the given commit was released in 6.10). > > Of course both methods don't account for cherry-picks, the same change > with a different sha could have landed in a bugfix release. > > -Krzysztof > > On Sat, May 11, 2019 at 10:27 PM Artem Pelenitsyn > wrote: > >> Hi chessai, >> >> What I usually do for this is open up the corresponding GitHub page, e.g.: >> >> https://github.com/ghc/ghc/commit/bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee >> >> where I see the list of branches the commit was added to, below the >> commit message (note that you have to click "..." to see the full list of >> branches). The branches ending with `-release` (e.g. ghc-8.6.5-release) >> answer your question, I believe. >> >> -- >> Best, Artem >> >> >> On Sat, 11 May 2019 at 23:01, chessai . wrote: >> >>> Devs, >>> >>> Is there a way to take the sha1 of a git commit and find which >>> released version of GHC contains that commit, without resorting to a >>> manual cross-reference? >>> >>> Is it possible there could be some sort of webpage where this >>> information could be made accessible, just by pasting in a commit? >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun May 12 15:03:47 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 12 May 2019 15:03:47 +0000 Subject: CI on forked projects: Darwin woes In-Reply-To: <7434b9c6-a614-d15a-52de-f340304e6db5@asaurus.net> References: , <7434b9c6-a614-d15a-52de-f340304e6db5@asaurus.net> Message-ID: Cool. I recommend irc and devs list plus urls / copies of error messages. Hard to debug timeout if we don’t have the literal url or error messages shared ! -Carter ________________________________ From: Kevin Buhr Sent: Sunday, May 12, 2019 11:01 AM To: Carter Schonwald Cc: Iavor Diatchki Subject: Re: CI on forked projects: Darwin woes Thanks! I'll send a note if it starts happening again. On 5/12/19 7:23 AM, Carter Schonwald wrote: > [ . . . ] > Next time you hit a failure could you share with the devs list and or > #ghc irc ? -- Kevin Buhr -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 13 12:43:36 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 13 May 2019 08:43:36 -0400 Subject: CI on forked projects: Darwin woes In-Reply-To: References: <7434b9c6-a614-d15a-52de-f340304e6db5@asaurus.net> Message-ID: <87tvdyr0cs.fsf@smart-cactus.org> Carter Schonwald writes: > Cool. I recommend irc and devs list plus urls / copies of error messages. > > Hard to debug timeout if we don’t have the literal url or error messages shared ! > For what it's worth I suspect these timeouts are simply due to the fact that we are somewhat lacking in Darwin builder capacity. There are rarely fewer than five builds queued to run on our two Darwin machines and this number can sometimes spike to much higher than the machines can run in the 10-hour build timeout. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From shayne.fletcher at daml.com Wed May 15 01:36:26 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Tue, 14 May 2019 21:36:26 -0400 Subject: [hadrian] happy 1.19.10 Message-ID: Hi Vlad, Are there imminent plans to update hadrian/stack.yaml with something like, ``` # Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2) resolver: lts-13.21 ``` I think this is necessary to get the recent happy upgrade? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladislav at serokell.io Wed May 15 06:22:30 2019 From: vladislav at serokell.io (Vladislav Zavialov) Date: Wed, 15 May 2019 09:22:30 +0300 Subject: [hadrian] happy 1.19.10 In-Reply-To: References: Message-ID: Hi Shayne, I don’t use ’stack’ to build GHC and CI doesn’t check it, so I think I missed this one. Thanks for bringing this up, have you already checked locally that ‘lts-13.21’ fixes the issue (if so, perhaps submit an MR with your fix)? Would it be a good idea to add a CI job for stack to avoid breakage in the future? - Vlad > On 15 May 2019, at 04:36, Shayne Fletcher via ghc-devs wrote: > > Hi Vlad, > > Are there imminent plans to update hadrian/stack.yaml with something like, > ``` > # Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2) > resolver: lts-13.21 > ``` > I think this is necessary to get the recent happy upgrade? > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > New York, NY 10007, USA > 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. If you are not the intended recipient, please delete this message._______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From vladislav at serokell.io Wed May 15 06:39:24 2019 From: vladislav at serokell.io (Vladislav Zavialov) Date: Wed, 15 May 2019 09:39:24 +0300 Subject: Parser performance: 10% regression in 8.8 In-Reply-To: References: Message-ID: <50824083-B4BC-4854-AB19-AAA78DA6D189@serokell.io> Steps 3–4 are done: https://gitlab.haskell.org/ghc/ghc/commit/684dc290563769d456b6f1c772673d64307ab072 Step 5, as it turns out, is not needed: I was mistaken and GHC 8.8 was not affected. I got confused about the releases, it’s only 8.10 that would be affected, sorry about this. However, it’s good that we merged the fix before the ghc-8.10 branch is cut, which should happen mid-June according to https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html Thanks everyone for responding to this, I’ve got help with CI images and updating build configuration. All the best, - Vladislav > On 9 May 2019, at 10:35, Simon Marlow wrote: > > Thanks for bringing this up. I've merged the PR and uploaded Happy 1.19.10 to Hackage. Can someone else look at steps 3-5? > > Cheers > Simon > > On Wed, 8 May 2019 at 09:51, Vladislav Zavialov wrote: > Hello ghc-devs, > > This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4). > > Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration. > > Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done: > > 1. Merge https://github.com/simonmar/happy/pull/134 > 2. Release a new ‘happy’ > 3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release > 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration > 5. Backport it to the ghc-8.8 branch > > I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5. > > All the best, > - Vladislav > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From shayne.fletcher at daml.com Wed May 15 10:42:28 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 15 May 2019 06:42:28 -0400 Subject: [hadrian] happy 1.19.10 In-Reply-To: References: Message-ID: Hi Vlad, On Wed, May 15, 2019 at 2:20 AM Vladislav Zavialov wrote: > I don’t use ’stack’ to build GHC and CI doesn’t check it, so I think I > missed this one. Thanks for bringing this up, have you already checked > locally that ‘lts-13.21’ fixes the issue (if so, perhaps submit an MR with > your fix)? Confirmed that the build is broken and that this fixes it. MR here https://gitlab.haskell.org/ghc/ghc/merge_requests/953. -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed May 15 11:45:59 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 15 May 2019 07:45:59 -0400 Subject: CI on forked projects: Darwin woes In-Reply-To: <87tvdyr0cs.fsf@smart-cactus.org> References: <7434b9c6-a614-d15a-52de-f340304e6db5@asaurus.net> <87tvdyr0cs.fsf@smart-cactus.org> Message-ID: Yeah. That’s my current theory. It doesn’t help that the queue length isn’t visible On Mon, May 13, 2019 at 8:43 AM Ben Gamari wrote: > Carter Schonwald writes: > > > Cool. I recommend irc and devs list plus urls / copies of error > messages. > > > > Hard to debug timeout if we don’t have the literal url or error messages > shared ! > > > For what it's worth I suspect these timeouts are simply due to the fact > that we are somewhat lacking in Darwin builder capacity. There are > rarely fewer than five builds queued to run on our two Darwin machines > and this number can sometimes spike to much higher than the machines can > run in the 10-hour build timeout. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Thu May 16 05:03:15 2019 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Wed, 15 May 2019 22:03:15 -0700 Subject: clarification re Note [Deeper level on the left] Message-ID: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcUnify.hs#L1754 contains ``` Note [Deeper level on the left]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~The most important thing is that we want to put tyvars withthe deepest level on the left. The reason to do so differs forWanteds and Givens, but either way, deepest wins! Simple.* Wanteds. Putting the deepest variable on the left maximise the chances that it's a touchable meta-tyvar which can be solved.* Givens. Suppose we have something like forall a[2]. b[1] ~ a[2] => beta[1] ~ a[2] If we orient the Given a[2] on the left, we'll rewrite the Wanted to (beta[1] ~ b[1]), and that can float out of the implication. Otherwise it can't. By putting the deepest variable on the left we maximise our changes of eliminating skolem capture. See also TcSMonad Note [Let-bound skolems] for another reason to orient with the deepest skolem on the left. IMPORTANT NOTE: this test does a level-number comparison on skolems, so it's important that skolems have (accurate) level numbers.See #15009 for an further analysis of why "deepest on the left"is a good plan.``` I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Am I missing something? Roughly: I'm asking because I need to decide if there's a reason for my typechecker plugin to bother with "eliminating skolem capture" when #15009 does *not* apply. Thanks. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 16 08:05:54 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 16 May 2019 08:05:54 +0000 Subject: clarification re Note [Deeper level on the left] In-Reply-To: References: Message-ID: I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Consider our example forall a[2]. b[1] ~ a[2] => beta[1] ~ a[2] If we leave the Given oriented as it is, the (beta~a) constraint cannot float, because it mentions a, which is bound by the forall If we swizzle the Given we get this: forall a[2]. a[2] ~ b[1] => beta[1] ~ a[2] Now we’ll use that Given to rewrite the Wanted, to get this: forall a[2]. a[2] ~ b[1] => beta[1] ~ b[1] Now the Wanted can float – it no longer mentions a. But wait! There’s a second thing that prevents floating: we never float out of an implication that binds Given equalities. But not quite: the Note [Let-bound skolems] explains that we don’t treat as “binding a Given equality” an equality whose LHS is one of the skolems bound by this very implication. And lo! in the implication forall a[2]. a[2] ~ b[1] => beta[1] ~ b[1] the a[2] on the LHS is indeed bound by this implication. So we do not disable floating (despite the apparent Given equality), and can float to give beta[1] ~ b[1], (forall a[2]. a[2] ~ b[1] => ) Does that help explain? If so, might you update the Note(s) so they are clearer? Thanks Simon rom: Nicolas Frisby Sent: 16 May 2019 06:03 To: ghc-devs at haskell.org Cc: Richard Eisenberg ; Simon Peyton Jones Subject: clarification re Note [Deeper level on the left] https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcUnify.hs#L1754 contains ``` Note [Deeper level on the left] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The most important thing is that we want to put tyvars with the deepest level on the left. The reason to do so differs for Wanteds and Givens, but either way, deepest wins! Simple. * Wanteds. Putting the deepest variable on the left maximise the chances that it's a touchable meta-tyvar which can be solved. * Givens. Suppose we have something like forall a[2]. b[1] ~ a[2] => beta[1] ~ a[2] If we orient the Given a[2] on the left, we'll rewrite the Wanted to (beta[1] ~ b[1]), and that can float out of the implication. Otherwise it can't. By putting the deepest variable on the left we maximise our changes of eliminating skolem capture. See also TcSMonad Note [Let-bound skolems] for another reason to orient with the deepest skolem on the left. IMPORTANT NOTE: this test does a level-number comparison on skolems, so it's important that skolems have (accurate) level numbers. See #15009 for an further analysis of why "deepest on the left" is a good plan. ``` I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Am I missing something? Roughly: I'm asking because I need to decide if there's a reason for my typechecker plugin to bother with "eliminating skolem capture" when #15009 does *not* apply. Thanks. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu May 16 09:54:01 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 16 May 2019 10:54:01 +0100 Subject: GHC API, GHCi, profiling, shared objects In-Reply-To: References: Message-ID: OK, so by accident I have stumbled across some documentation for the remote interpreter which I think claims to solve some of these issues. https://gitlab.haskell.org/ghc/ghc/wikis/remote-ghci https://simonmar.github.io/posts/2016-02-12-Stack-traces-in-GHCi.html Simon in his blog post explains that there are some advantages to the external interpreter. 1. The interpreter and compiler can be run using separate runtimes. In the context of the GHCi API I believe this means that the GHC API program can be compiled the profiling way BUT the interpreted code can be compiled the normal way, which is the opposite to the use case suggested in the blog post. 2. The decision about whether to use the dynamic linker is separated from whether the executable is dynamically linked. We have discovered that compiling the executable with -dynamic causes the interpreted code to use the system dynamic linker as well which is significantly more performant. Therefore it seems like a sensible plan to enable `-fexternal-interpreter` in the GHC API application. On Sat, Apr 27, 2019 at 12:37 PM Matthew Pickering wrote: > > Hi, > > If I write a program using the GHC API then the resulting executable > is sensitive to the version of GHC which I used to build the program. > > For example, if I build a version of GHC which has profiling enabled > (prof flavour) then building my application (static linking) with this > version means that I can only load packages which were also built with > profiling enabled. This happens in particular when you load a module > which uses TemplateHaskell which causes all the dependencies to be > loaded. > > If the so isn't built with profiling then you get errors such as > > ``` > : can't load .so/.DLL for: > libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib > (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): > image not found) > ``` > > This seemed to somewhat make sense to me because compiling > with/without profiling changes > the heap representation but then I considered whether this also > happens in GHCi and I concluded that it didn't. > > In particular, it seems to me that > > 1. GHCi is not built by a profiled version of GHC and is still a "GHC > API application" > 2. There is no problem loading profiled packages into GHCi despite this fact? > > 1. Does GHCi do something special to mitigate against these kinds of failures? > 2. Is this a difference between staticly and dynamically linking the > application executable (`ghc` in the case for ghci). ? > > Hopefully someone familiar with the implementation of the linker will > be able to clear this up. > > Cheers, > > Matt From simonpj at microsoft.com Thu May 16 12:04:05 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 16 May 2019 12:04:05 +0000 Subject: How to contribute a patch Message-ID: Ben The "how to contribute a patch" page https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs doesn't say anything about the process of actually getting it committed, notably: * Picking approvers * Assigning to Marge * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. There's a bit of info, rather oddly, on the GHC wiki root page https://gitlab.haskell.org/ghc/ghc/wikis/home The initial stuff about opening a MR is details, but there is not enough on these latter steps I think. I'm cc'ing Sandy He's asking "what next" and I wanted to say "look at the instructions here" but failed to find a suitable "here." Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu May 16 12:21:59 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 16 May 2019 13:21:59 +0100 Subject: How to contribute a patch In-Reply-To: References: Message-ID: I made the start of a wiki page about Marge https://gitlab.haskell.org/ghc/ghc/wikis/Marge-Bot Matt On Thu, May 16, 2019 at 1:04 PM Simon Peyton Jones via ghc-devs wrote: > > Ben > > The “how to contribute a patch” page https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs doesn’t say anything about the process of actually getting it committed, notably: > > Picking approvers > Assigning to Marge > Monitoring progress if it doesn’t land within 24 hrs; even knowing when to time out would help. > > There’s a bit of info, rather oddly, on the GHC wiki root page https://gitlab.haskell.org/ghc/ghc/wikis/home > > The initial stuff about opening a MR is details, but there is not enough on these latter steps I think. > > I’m cc’ing Sandy He’s asking “what next” and I wanted to say “look at the instructions here” but failed to find a suitable “here.” > > Thanks > > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Thu May 16 12:43:08 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 16 May 2019 08:43:08 -0400 Subject: How to contribute a patch In-Reply-To: References: Message-ID: <87bm02r2nd.fsf@smart-cactus.org> Matthew Pickering writes: > I made the start of a wiki page about Marge > > https://gitlab.haskell.org/ghc/ghc/wikis/Marge-Bot > Thank you Matthew! I also think there is more to be said here; I'll add this to my todo this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matthewtpickering at gmail.com Fri May 17 08:18:31 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 17 May 2019 09:18:31 +0100 Subject: gitlab upgrade - change in approval system Message-ID: Hi, I just noticed that the gitlab upgrade has caused the approval system to change. Before all that was required was 1 approval from anyone. Now, at least one approval from the default group is required (me, Ben, Omer, Tobias, David) I couldn't see a way to turn back to the old behaviour from a brief look at the UI. Do you know if there is a way Ben? Cheers, Matt From ryan.gl.scott at gmail.com Fri May 17 12:53:47 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 17 May 2019 08:53:47 -0400 Subject: gitlab upgrade - change in approval system Message-ID: I would definitely appreciate changing Marge's behavior back to the old one. As things stand currently, I am unable to approve anything that I'm not explicitly listed as a reviewer for. See here [1] for an example of where this has happened. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/559#note_198714 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri May 17 23:57:37 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 17 May 2019 16:57:37 -0700 Subject: Bug or feature? Message-ID: Hello, I've encountered some odd behavior related to quantification and type families, but I am not sure if it is a bug or by design. Here is an example which works fine: > {-# Language ExistentialQuantification, RankNTypes, TypeFamilies #-} > > data T a b = T a > > t :: T Bool a > t = T True > > data Q1 = forall a. Q1 (forall b. T a b) > > q1 :: Q1 > q1 = Q1 t Now, suppose we wanted to constraint the universally quantified type of the field. This also works fine: > data Q2 = forall a. Q2 (forall b. (b ~ Int) => T a b) > > q2 :: Q2 > q2 = Q2 t However, things break down if the restriction involves a type family: > type family F a > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > q3 :: Q3 > q3 = Q3 t This causes some complaints about *a*, resulting from checking ambiguity. If we `AllowAmbiguousTypes`, then the definition of `Q3` is accepted, but `q3` fails with a similar error, complaining that GHC cannot match `a` with `Bool` because it is "untouchable". This seems confusing---I would have thought that when we use the `Q3` constructor we are providing the value for `a` (e.g., it is `Bool`), so I am not sure why GHC is trying to match anything. Any ideas? -Iavor From lonetiger at gmail.com Sat May 18 01:19:50 2019 From: lonetiger at gmail.com (Phyx) Date: Sat, 18 May 2019 02:19:50 +0100 Subject: gitlab upgrade - change in approval system In-Reply-To: References: Message-ID: I have noticed that you can work around this by editing the Mr and adding yourself explicitly to the approvals list for it. It then allows you to approve it. Sent from my Mobile On Fri, May 17, 2019, 13:54 Ryan Scott wrote: > I would definitely appreciate changing Marge's behavior back to the old > one. As things stand currently, I am unable to approve anything that I'm > not explicitly listed as a reviewer for. See here [1] for an example of > where this has happened. > > Ryan S. > ----- > [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/559#note_198714 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Sat May 18 12:57:42 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 18 May 2019 08:57:42 -0400 Subject: gitlab upgrade - change in approval system Message-ID: To be clear, your workaround is precisely what I used to do, but that is no longer working after the GitLab upgrade. I can add myself as a reviewer, but only to a group besides the default approvers list. Because Marge only counts approvals from those who belong to the default approvers list, my approvals don't count anymore. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Sat May 18 14:03:23 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 18 May 2019 10:03:23 -0400 Subject: Bug or feature? Message-ID: Hi Iavor, This is a feature in the sense that it is an expected outcome of the OutsideIn(X) type inference algorithm (in particular, Section 5 of the corresponding paper [1]). I'll try to explain the issue to the best of my understanding. The tricky thing about the Q3 data type: data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) Is that there is a rank-n type with a /local/ equality constraint. In order to ensure that the type of the Q3 data constructor is never ambiguous, GHC tries to infer that Q3's type is always a subtype of itself. As a part of this, GHC attempts to solve the following implication constraint: forall a. forall b. (F b ~ Int) => (a ~ alpha) Where `alpha` is a unification variable. GHC tries to find a unique, most-general substitution that solves this constraint but ultimately gives up and reports the "untouchable" error message you observed. This is a bit strange, however. Upon first glance, this constraint would appear to have a unique solution: namely, [alpha |-> a]. Why doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is conservative: there may exist constraints that admit a unique solution which it may fail to solve. This is explained in greater depth in Section 5.2 of the paper, but the essence of this restriction is because of the open-world assumption for type families. Namely, it's possible that your Q3 data type might later be linked against code which defines the following type family: type family G i a type instance G Int a = a If that were the case, then the implication constraint above would no longer have a unique solution, since there would exist another substitution [alpha |-> G (F b) a] that is incomparable with [alpha |-> a]. OutsideIn(X) was designed to only pick unique solutions that remain unique solutions even if more axioms (i.e., type family equations) are added, so for these reasons it fails to solve the implication constraint above. See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all involve similar issues. ----- I'm far from an expert on type inference, so I can't really offer a better inference algorithm that would avoid this problem. The best you can do, as far as I can tell, is to enable AllowAmbiguousTypes and hope for the best. Even then, you'll still run into situations where untouchability rears its ugly head, as in your `q3` definition. When that happens, your only available option (again, as far as I can tell) is to make use of TypeApplications. For example, the following /does/ typecheck: q3 :: Q3 q3 = Q3 @Bool t Hope that helps, Ryan S. ----- [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 [4] https://gitlab.haskell.org/ghc/ghc/issues/15649 From iavor.diatchki at gmail.com Mon May 20 18:00:34 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 20 May 2019 11:00:34 -0700 Subject: Bug or feature? In-Reply-To: References: Message-ID: Hi, thanks for the detailed response---I thought something like that might be happening, which is why I thought I'd better ask before reporting a bug. I wonder how we might make the error message a little more user friendly. One idea would be to compute a couple of examples to show, after an ambiguity check fails. -Iavor On Sat, May 18, 2019 at 7:03 AM Ryan Scott wrote: > > Hi Iavor, > > This is a feature in the sense that it is an expected outcome of the > OutsideIn(X) type inference algorithm (in particular, Section 5 of the > corresponding paper [1]). I'll try to explain the issue to the best of > my understanding. > > The tricky thing about the Q3 data type: > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > Is that there is a rank-n type with a /local/ equality constraint. In > order to ensure that the type of the Q3 data constructor is never > ambiguous, GHC tries to infer that Q3's type is always a subtype of > itself. As a part of this, GHC attempts to solve the following > implication constraint: > > forall a. forall b. (F b ~ Int) => (a ~ alpha) > > Where `alpha` is a unification variable. GHC tries to find a unique, > most-general substitution that solves this constraint but ultimately > gives up and reports the "untouchable" error message you observed. > > This is a bit strange, however. Upon first glance, this constraint > would appear to have a unique solution: namely, [alpha |-> a]. Why > doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is > conservative: there may exist constraints that admit a unique solution > which it may fail to solve. This is explained in greater depth in > Section 5.2 of the paper, but the essence of this restriction is > because of the open-world assumption for type families. Namely, it's > possible that your Q3 data type might later be linked against code > which defines the following type family: > > type family G i a > type instance G Int a = a > > If that were the case, then the implication constraint above would no > longer have a unique solution, since there would exist another > substitution [alpha |-> G (F b) a] that is incomparable with [alpha > |-> a]. OutsideIn(X) was designed to only pick unique solutions that > remain unique solutions even if more axioms (i.e., type family > equations) are added, so for these reasons it fails to solve the > implication constraint above. > > See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all > involve similar issues. > > ----- > > I'm far from an expert on type inference, so I can't really offer a > better inference algorithm that would avoid this problem. The best you > can do, as far as I can tell, is to enable AllowAmbiguousTypes and > hope for the best. Even then, you'll still run into situations where > untouchability rears its ugly head, as in your `q3` definition. When > that happens, your only available option (again, as far as I can tell) > is to make use of TypeApplications. For example, the following /does/ > typecheck: > > q3 :: Q3 > q3 = Q3 @Bool t > > Hope that helps, > > Ryan S. > ----- > [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf > [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 > [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 > [4] https://gitlab.haskell.org/ghc/ghc/issues/15649 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nicolas.frisby at gmail.com Mon May 20 23:26:03 2019 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon, 20 May 2019 16:26:03 -0700 Subject: Bug or feature? In-Reply-To: References: Message-ID: FYI, your Q2 (with no tyfam) is well-typed because of #15009 On Mon, May 20, 2019, 11:01 Iavor Diatchki wrote: > Hi, > > thanks for the detailed response---I thought something like that might > be happening, which is why I thought I'd better ask before reporting a > bug. > > I wonder how we might make the error message a little more user > friendly. One idea would be to compute a couple of examples to show, > after an ambiguity check fails. > > -Iavor > > On Sat, May 18, 2019 at 7:03 AM Ryan Scott > wrote: > > > > Hi Iavor, > > > > This is a feature in the sense that it is an expected outcome of the > > OutsideIn(X) type inference algorithm (in particular, Section 5 of the > > corresponding paper [1]). I'll try to explain the issue to the best of > > my understanding. > > > > The tricky thing about the Q3 data type: > > > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > > > Is that there is a rank-n type with a /local/ equality constraint. In > > order to ensure that the type of the Q3 data constructor is never > > ambiguous, GHC tries to infer that Q3's type is always a subtype of > > itself. As a part of this, GHC attempts to solve the following > > implication constraint: > > > > forall a. forall b. (F b ~ Int) => (a ~ alpha) > > > > Where `alpha` is a unification variable. GHC tries to find a unique, > > most-general substitution that solves this constraint but ultimately > > gives up and reports the "untouchable" error message you observed. > > > > This is a bit strange, however. Upon first glance, this constraint > > would appear to have a unique solution: namely, [alpha |-> a]. Why > > doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is > > conservative: there may exist constraints that admit a unique solution > > which it may fail to solve. This is explained in greater depth in > > Section 5.2 of the paper, but the essence of this restriction is > > because of the open-world assumption for type families. Namely, it's > > possible that your Q3 data type might later be linked against code > > which defines the following type family: > > > > type family G i a > > type instance G Int a = a > > > > If that were the case, then the implication constraint above would no > > longer have a unique solution, since there would exist another > > substitution [alpha |-> G (F b) a] that is incomparable with [alpha > > |-> a]. OutsideIn(X) was designed to only pick unique solutions that > > remain unique solutions even if more axioms (i.e., type family > > equations) are added, so for these reasons it fails to solve the > > implication constraint above. > > > > See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all > > involve similar issues. > > > > ----- > > > > I'm far from an expert on type inference, so I can't really offer a > > better inference algorithm that would avoid this problem. The best you > > can do, as far as I can tell, is to enable AllowAmbiguousTypes and > > hope for the best. Even then, you'll still run into situations where > > untouchability rears its ugly head, as in your `q3` definition. When > > that happens, your only available option (again, as far as I can tell) > > is to make use of TypeApplications. For example, the following /does/ > > typecheck: > > > > q3 :: Q3 > > q3 = Q3 @Bool t > > > > Hope that helps, > > > > Ryan S. > > ----- > > [1] > https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf > > [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 > > [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 > > [4] https://gitlab.haskell.org/ghc/ghc/issues/15649 > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Mon May 20 23:57:42 2019 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon, 20 May 2019 16:57:42 -0700 Subject: Bug or feature? In-Reply-To: References: Message-ID: Also, thanks for the concrete counter example! I tried to organize my thoughts on this kind of thing a while ago (see rambly notes at https://gitlab.haskell.org/ghc/ghc/wikis/float-more-eqs2018 and my comments on #15009), but didn't succeed before setting it aside. Your counter example is very helpful as a conversation substrate. Disclaimer: I've only ever tested my understanding of this stuff with GHC itself (as a typechecker plugin author, with a malnourished test suite to boot), so I'm not totally confident in what follows. Excited for others to review. Iavor's user decl: data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) Your summary of the relevant Wanted implication of the ambiguity check: forall a. forall b. (F b ~ Int) => (a ~ alpha) Your explanation of the "counter-example" due to the open world assumption: type family G i a type instance G Int a = a If that were the case, then the implication constraint above would no longer have a unique solution, since there would exist another substitution [alpha |-> G (F b) a] that is incomparable with [alpha |-> a]. OutsideIn(X) was designed to only pick unique solutions … If we write the Wanted again with explicit tyvar levels: forall a[1]. forall b[2]. (F b ~ Int) => (a ~ alpha[2]) And flatten: forall a[1]. forall b[2]. (F b ~ fsk[2], fsk ~ Int) => (a ~ alpha[1]) Then I think your counter example becomes: the substitution mapping alpha[1] to G fsk[2] a[1] (I'm eliding the corresponding fmv flatten skolem; irrelevant, I think.) But that mapping is "ill-leveled", isn't it? The level 2 skolem b[2] would be escaping if a type including it were assigned to the level 1 univar alpha[1]. (I'm unsure if b's position as an argument to a tyfam in the RHS of alpha matters -- my intuition says it does not.) Could be an exciting improvement to unification under local equalities, if I'm right here and also the argument generalizes beyond this kind of example. Please let me know what you think! Thanks. -Nick On Mon, May 20, 2019, 16:26 Nicolas Frisby wrote: > FYI, your Q2 (with no tyfam) is well-typed because of #15009 > > On Mon, May 20, 2019, 11:01 Iavor Diatchki > wrote: > >> Hi, >> >> thanks for the detailed response---I thought something like that might >> be happening, which is why I thought I'd better ask before reporting a >> bug. >> >> I wonder how we might make the error message a little more user >> friendly. One idea would be to compute a couple of examples to show, >> after an ambiguity check fails. >> >> -Iavor >> >> On Sat, May 18, 2019 at 7:03 AM Ryan Scott >> wrote: >> > >> > Hi Iavor, >> > >> > This is a feature in the sense that it is an expected outcome of the >> > OutsideIn(X) type inference algorithm (in particular, Section 5 of the >> > corresponding paper [1]). I'll try to explain the issue to the best of >> > my understanding. >> > >> > The tricky thing about the Q3 data type: >> > >> > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) >> > >> > Is that there is a rank-n type with a /local/ equality constraint. In >> > order to ensure that the type of the Q3 data constructor is never >> > ambiguous, GHC tries to infer that Q3's type is always a subtype of >> > itself. As a part of this, GHC attempts to solve the following >> > implication constraint: >> > >> > forall a. forall b. (F b ~ Int) => (a ~ alpha) >> > >> > Where `alpha` is a unification variable. GHC tries to find a unique, >> > most-general substitution that solves this constraint but ultimately >> > gives up and reports the "untouchable" error message you observed. >> > >> > This is a bit strange, however. Upon first glance, this constraint >> > would appear to have a unique solution: namely, [alpha |-> a]. Why >> > doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is >> > conservative: there may exist constraints that admit a unique solution >> > which it may fail to solve. This is explained in greater depth in >> > Section 5.2 of the paper, but the essence of this restriction is >> > because of the open-world assumption for type families. Namely, it's >> > possible that your Q3 data type might later be linked against code >> > which defines the following type family: >> > >> > type family G i a >> > type instance G Int a = a >> > >> > If that were the case, then the implication constraint above would no >> > longer have a unique solution, since there would exist another >> > substitution [alpha |-> G (F b) a] that is incomparable with [alpha >> > |-> a]. OutsideIn(X) was designed to only pick unique solutions that >> > remain unique solutions even if more axioms (i.e., type family >> > equations) are added, so for these reasons it fails to solve the >> > implication constraint above. >> > >> > See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all >> > involve similar issues. >> > >> > ----- >> > >> > I'm far from an expert on type inference, so I can't really offer a >> > better inference algorithm that would avoid this problem. The best you >> > can do, as far as I can tell, is to enable AllowAmbiguousTypes and >> > hope for the best. Even then, you'll still run into situations where >> > untouchability rears its ugly head, as in your `q3` definition. When >> > that happens, your only available option (again, as far as I can tell) >> > is to make use of TypeApplications. For example, the following /does/ >> > typecheck: >> > >> > q3 :: Q3 >> > q3 = Q3 @Bool t >> > >> > Hope that helps, >> > >> > Ryan S. >> > ----- >> > [1] >> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf >> > [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 >> > [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 >> > [4] https://gitlab.haskell.org/ghc/ghc/issues/15649 >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsx at bluewin.ch Tue May 21 08:02:47 2019 From: rsx at bluewin.ch (Roland Senn) Date: Tue, 21 May 2019 10:02:47 +0200 Subject: make fails with "No entry for "integer library" in .../inplace/lib/settings" Message-ID: <1558425767.14469.3.camel@bluewin.ch> Hi, Suddenly I'm unable to build ghc with make. I get the error: "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install -- with-ghc="/home/roland/Projekte/ghc/inplace/bin/ghc-stage1" --with-ghc- pkg="/home/roland/Projekte/ghc/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="/home/roland/Software/ghc/bin/alex" --with- happy="/home/roland/Software/ghc/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/roland/Projekte/ghc/inplace/bin/ghc-stage1' exited with an error: No entry for "integer library" in "/home/roland/Projekte/ghc/inplace/lib/settings" libraries/ghc-prim/ghc.mk:4: die Regel für Ziel „libraries/ghc- prim/dist-install/package-data.mk“ scheiterte make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Fehler 1 Makefile:123: die Regel für Ziel „all“ scheiterte make: *** [all] Fehler 2 Any ideas what's wrong? Any ideas how to fix? Many thanks and best wishes Roland PS: I still need the old make based build system to run validations... From simonpj at microsoft.com Tue May 21 08:23:00 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 21 May 2019 08:23:00 +0000 Subject: Bug or feature? In-Reply-To: References: Message-ID: Let me have a quick stab at Nick’s idea. Consider forall b[2]. (a ~ Int) => alpha[1] ~ Maybe a Then we don’t want to unify alpha := Maybe a, because an equally good way to solve the constraint would be alpha := Maybe Int. And constraints elsewhere might force one or the other to be the “right” one. But suppose none of the given constraints involve ‘a’ in any way, shape, or form. For example: forall b[2]. (b ~ Int) => alpha[1] ~ Maybe a Well then, we have no local constraints on a, so we can’t get any ambiguity. Aha – this is covered by the current “local equalities” story. Note [Let-bound skolems] in TcSMonad. But what about this: forall b[2]. (F b ~ G b) => alpha[1] ~ Maybe a That is *not* covered by the current local-equalities story, but I think is equally immune to producing a local constraint on ‘a’. And Iavor’s example is just such a case. So here is a possible refinement: 1. An implication is considered to “bind local equalities” iff it has at least one given equality whose free variables are not all bound by the same implication. That loosens up Note [Let-bound skolems] in TcSMonad, perhaps significantly. Could we go further? 1. An equality (t1~t2) can float out of an implication (forall as. C => blah) iff, assuming fvs(t1,t2) = FV * The ‘as’ are disjoint from FV obviously. * None of the equality constraints in C mentions any of the variables in FV This is a bit looser because in forall c[2]. (b ~ Int) => alpha[1] ~ a it would allow the equality alpha~a to float even though there is a real local equality (b~Int). I’m a bit worried about (B) however. Suppose we had a Given equality (a ~ b). Then suddenly that local Given (b ~ Int) does actually constrain a after all. Can we have Givens we didn’t “see” before? Yes, via superclasses or outer unifications. So I would be rather cautious about (B). But (A) looks sound to me. I think it would address Iavor’s example, but perhaps not Nick’s. Simon From: ghc-devs On Behalf Of Nicolas Frisby Sent: 21 May 2019 00:58 To: Iavor S. S. Diatchki Cc: ghc-devs at haskell.org; Ryan Scott Subject: Re: Bug or feature? Also, thanks for the concrete counter example! I tried to organize my thoughts on this kind of thing a while ago (see rambly notes at https://gitlab.haskell.org/ghc/ghc/wikis/float-more-eqs2018 and my comments on #15009), but didn't succeed before setting it aside. Your counter example is very helpful as a conversation substrate. Disclaimer: I've only ever tested my understanding of this stuff with GHC itself (as a typechecker plugin author, with a malnourished test suite to boot), so I'm not totally confident in what follows. Excited for others to review. Iavor's user decl: data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) Your summary of the relevant Wanted implication of the ambiguity check: forall a. forall b. (F b ~ Int) => (a ~ alpha) Your explanation of the "counter-example" due to the open world assumption: type family G i a type instance G Int a = a If that were the case, then the implication constraint above would no longer have a unique solution, since there would exist another substitution [alpha |-> G (F b) a] that is incomparable with [alpha |-> a]. OutsideIn(X) was designed to only pick unique solutions … If we write the Wanted again with explicit tyvar levels: forall a[1]. forall b[2]. (F b ~ Int) => (a ~ alpha[2]) And flatten: forall a[1]. forall b[2]. (F b ~ fsk[2], fsk ~ Int) => (a ~ alpha[1]) Then I think your counter example becomes: the substitution mapping alpha[1] to G fsk[2] a[1] (I'm eliding the corresponding fmv flatten skolem; irrelevant, I think.) But that mapping is "ill-leveled", isn't it? The level 2 skolem b[2] would be escaping if a type including it were assigned to the level 1 univar alpha[1]. (I'm unsure if b's position as an argument to a tyfam in the RHS of alpha matters -- my intuition says it does not.) Could be an exciting improvement to unification under local equalities, if I'm right here and also the argument generalizes beyond this kind of example. Please let me know what you think! Thanks. -Nick On Mon, May 20, 2019, 16:26 Nicolas Frisby > wrote: FYI, your Q2 (with no tyfam) is well-typed because of #15009 On Mon, May 20, 2019, 11:01 Iavor Diatchki > wrote: Hi, thanks for the detailed response---I thought something like that might be happening, which is why I thought I'd better ask before reporting a bug. I wonder how we might make the error message a little more user friendly. One idea would be to compute a couple of examples to show, after an ambiguity check fails. -Iavor On Sat, May 18, 2019 at 7:03 AM Ryan Scott > wrote: > > Hi Iavor, > > This is a feature in the sense that it is an expected outcome of the > OutsideIn(X) type inference algorithm (in particular, Section 5 of the > corresponding paper [1]). I'll try to explain the issue to the best of > my understanding. > > The tricky thing about the Q3 data type: > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > Is that there is a rank-n type with a /local/ equality constraint. In > order to ensure that the type of the Q3 data constructor is never > ambiguous, GHC tries to infer that Q3's type is always a subtype of > itself. As a part of this, GHC attempts to solve the following > implication constraint: > > forall a. forall b. (F b ~ Int) => (a ~ alpha) > > Where `alpha` is a unification variable. GHC tries to find a unique, > most-general substitution that solves this constraint but ultimately > gives up and reports the "untouchable" error message you observed. > > This is a bit strange, however. Upon first glance, this constraint > would appear to have a unique solution: namely, [alpha |-> a]. Why > doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is > conservative: there may exist constraints that admit a unique solution > which it may fail to solve. This is explained in greater depth in > Section 5.2 of the paper, but the essence of this restriction is > because of the open-world assumption for type families. Namely, it's > possible that your Q3 data type might later be linked against code > which defines the following type family: > > type family G i a > type instance G Int a = a > > If that were the case, then the implication constraint above would no > longer have a unique solution, since there would exist another > substitution [alpha |-> G (F b) a] that is incomparable with [alpha > |-> a]. OutsideIn(X) was designed to only pick unique solutions that > remain unique solutions even if more axioms (i.e., type family > equations) are added, so for these reasons it fails to solve the > implication constraint above. > > See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all > involve similar issues. > > ----- > > I'm far from an expert on type inference, so I can't really offer a > better inference algorithm that would avoid this problem. The best you > can do, as far as I can tell, is to enable AllowAmbiguousTypes and > hope for the best. Even then, you'll still run into situations where > untouchability rears its ugly head, as in your `q3` definition. When > that happens, your only available option (again, as far as I can tell) > is to make use of TypeApplications. For example, the following /does/ > typecheck: > > q3 :: Q3 > q3 = Q3 @Bool t > > Hope that helps, > > Ryan S. > ----- > [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-outsidein.pdf > [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 > [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 > [4] https://gitlab.haskell.org/ghc/ghc/issues/15649 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue May 21 08:33:53 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 21 May 2019 09:33:53 +0100 Subject: make fails with "No entry for "integer library" in .../inplace/lib/settings" In-Reply-To: <1558425767.14469.3.camel@bluewin.ch> References: <1558425767.14469.3.camel@bluewin.ch> Message-ID: I think this thread is related. https://mail.haskell.org/pipermail/ghc-devs/2019-May/017605.html In short, try deleting `inplace/lib/settings` manually. On Tue, May 21, 2019 at 9:03 AM Roland Senn wrote: > > Hi, > > Suddenly I'm unable to build ghc with make. I get the error: > > "inplace/bin/ghc-cabal" check libraries/ghc-prim > "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install -- > with-ghc="/home/roland/Projekte/ghc/inplace/bin/ghc-stage1" --with-ghc- > pkg="/home/roland/Projekte/ghc/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="/home/roland/Software/ghc/bin/alex" --with- > happy="/home/roland/Software/ghc/bin/happy" > Configuring ghc-prim-0.6.1... > ghc-cabal: '/home/roland/Projekte/ghc/inplace/bin/ghc-stage1' exited > with an > error: > No entry for "integer library" in > "/home/roland/Projekte/ghc/inplace/lib/settings" > > libraries/ghc-prim/ghc.mk:4: die Regel für Ziel „libraries/ghc- > prim/dist-install/package-data.mk“ scheiterte > make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Fehler 1 > Makefile:123: die Regel für Ziel „all“ scheiterte > make: *** [all] Fehler 2 > > Any ideas what's wrong? Any ideas how to fix? > > Many thanks and best wishes > Roland > > PS: I still need the old make based build system to run validations... > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue May 21 08:55:26 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 21 May 2019 08:55:26 +0000 Subject: Bug or feature? In-Reply-To: <7141FD55-D107-4C4E-86EC-5A615B7A1E06@cs.brynmawr.edu> References: <7141FD55-D107-4C4E-86EC-5A615B7A1E06@cs.brynmawr.edu> Message-ID: We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. Indeed. That’s what happens now. I do think this would work. Cool. Nick or Iavor: would you like to turn this conversation into a ticket? (Although it is technically user-facing, it is a very small corner and I’m not sure it would need a GHC proposal – others may want to comment.) Simon From: Richard Eisenberg Sent: 21 May 2019 09:43 To: Simon Peyton Jones Cc: Nicolas Frisby ; Iavor Diatchki ; ghc-devs at haskell.org; Ryan Scott Subject: Re: Bug or feature? On May 21, 2019, at 10:23 AM, Simon Peyton Jones via ghc-devs > wrote: But (A) looks sound to me. I like (A). (B) makes me nervous, too. > A. An implication is considered to “bind local equalities” iff it has at least one given equality whose free variables are not all bound by the same implication. We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. I do think this would work. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Wed May 22 05:18:46 2019 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Tue, 21 May 2019 22:18:46 -0700 Subject: Bug or feature? In-Reply-To: References: <7141FD55-D107-4C4E-86EC-5A615B7A1E06@cs.brynmawr.edu> Message-ID: I'd be happy to raise a ticket, but it might take a few days -- work trip. On Tue, May 21, 2019, 01:55 Simon Peyton Jones wrote: > We have to be careful in how we define "equality" in the above sentence, > including class constraints that (may) have superclass equality constraints. > > > > Indeed. That’s what happens now. > > > > I do think this would work. > > > > Cool. Nick or Iavor: would you like to turn this conversation into a > ticket? > > > > (Although it is technically user-facing, it is a very small corner and I’m > not sure it would need a GHC proposal – others may want to comment.) > > > > Simon > > > > *From:* Richard Eisenberg > *Sent:* 21 May 2019 09:43 > *To:* Simon Peyton Jones > *Cc:* Nicolas Frisby ; Iavor Diatchki < > iavor.diatchki at gmail.com>; ghc-devs at haskell.org; Ryan Scott < > ryan.gl.scott at gmail.com> > *Subject:* Re: Bug or feature? > > > > > > > > On May 21, 2019, at 10:23 AM, Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > > > But (A) looks sound to me. > > > > I like (A). (B) makes me nervous, too. > > > > > A. An implication is considered to “bind local equalities” iff it has at > least one given equality whose free variables are not all bound by the same > implication. > > > > We have to be careful in how we define "equality" in the above sentence, > including class constraints that (may) have superclass equality > constraints. I do think this would work. > > > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed May 22 16:09:13 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 22 May 2019 09:09:13 -0700 Subject: Processing MRs very slow? Message-ID: 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? From alexandreR_B at outlook.com Wed May 22 16:18:22 2019 From: alexandreR_B at outlook.com (Alexandre Rodrigues) Date: Wed, 22 May 2019 16:18:22 +0000 Subject: Processing MRs very slow? In-Reply-To: References: Message-ID: The same has happened to an MR I submitted, 713. I believe it is because this kind of contributions have low priority, and maintainers already have their hands full. ________________________________ From: ghc-devs on behalf of Iavor Diatchki Sent: Wednesday, May 22, 2019 5:09:13 PM To: ghc-devs Subject: Processing MRs very slow? 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 at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Wed May 22 16:27:57 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 22 May 2019 12:27:57 -0400 Subject: [hadrian/windows] build broken Message-ID: Windows builds with hadrian are currently failing with "file does not exist and no build rule available" `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas on how to overcome that? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Wed May 22 16:53:08 2019 From: davide at well-typed.com (David Eichmann) Date: Wed, 22 May 2019 17:53:08 +0100 Subject: Processing MRs very slow? In-Reply-To: References: Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- 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 From iavor.diatchki at gmail.com Wed May 22 17:00:01 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 22 May 2019 10:00:01 -0700 Subject: Bug or feature? In-Reply-To: References: <7141FD55-D107-4C4E-86EC-5A615B7A1E06@cs.brynmawr.edu> Message-ID: OK, I made #16684 to track the issue: https://gitlab.haskell.org/ghc/ghc/issues/16684 Perhaps we should continue the discussion over there. -Iavor On Tue, May 21, 2019 at 10:18 PM Nicolas Frisby wrote: > > I'd be happy to raise a ticket, but it might take a few days -- work trip. > > On Tue, May 21, 2019, 01:55 Simon Peyton Jones wrote: >> >> We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. >> >> >> >> Indeed. That’s what happens now. >> >> >> >> I do think this would work. >> >> >> >> Cool. Nick or Iavor: would you like to turn this conversation into a ticket? >> >> >> >> (Although it is technically user-facing, it is a very small corner and I’m not sure it would need a GHC proposal – others may want to comment.) >> >> >> >> Simon >> >> >> >> From: Richard Eisenberg >> Sent: 21 May 2019 09:43 >> To: Simon Peyton Jones >> Cc: Nicolas Frisby ; Iavor Diatchki ; ghc-devs at haskell.org; Ryan Scott >> Subject: Re: Bug or feature? >> >> >> >> >> >> >> >> On May 21, 2019, at 10:23 AM, Simon Peyton Jones via ghc-devs wrote: >> >> >> >> But (A) looks sound to me. >> >> >> >> I like (A). (B) makes me nervous, too. >> >> >> >> > A. An implication is considered to “bind local equalities” iff it has at least one given equality whose free variables are not all bound by the same implication. >> >> >> >> We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. I do think this would work. >> >> >> >> Richard From shayne.fletcher at daml.com Wed May 22 17:03:17 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 22 May 2019 13:03:17 -0400 Subject: [hadrian/windows] build broken In-Reply-To: References: Message-ID: I guess, On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher wrote: > Windows builds with hadrian are currently failing with "file does not > exist and no build rule available" > `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas > on how to overcome that? > > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi and RTS rules" (@DavidEichmann). I get the feeling that the current state of affairs is known and there are MRs working their way through the system to restore things already? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Wed May 22 17:37:19 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 22 May 2019 13:37:19 -0400 Subject: [hadrian/macos] build broken Message-ID: I'm trying to isolate the commit that's causing this, but the deal is on MacOS I'm seeing stage1 `ld` crashes linking `HStime`: ``` 0 0x1052e2748 __assert_rtn + 129 1 0x1052be30f ld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 95 2 0x1052e8736 mach_o::relocatable::Parser::addFixup(mach_o::relocatable::Parser::SourceLocation const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 34 3 0x1052eaa9c mach_o::relocatable::Section::addRelocFixup(mach_o::relocatable::Parser&, macho_relocation_info > const*) + 1722 4 0x1052ff61b mach_o::relocatable::Section::makeFixups(mach_o::relocatable::Parser&, mach_o::relocatable::Parser::CFI_CU_InfoArrays const&) + 105 5 0x1052faa66 mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 2120 6 0x1052f1250 mach_o::relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 282 7 0x10534352a ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 808 8 0x105345f22 ld::tool::InputFiles::parseWorkerThread() + 530 9 0x7fff70a6b2eb _pthread_body + 126 10 0x7fff70a6e249 _pthread_start + 66 A linker snapshot was created at: /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot ld: Assertion failed: (name != NULL), function Fixup, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, line 724. ``` I can replicate this on multiple machines and different versions of xcode command line tools. Any ideas? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Wed May 22 17:41:18 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Wed, 22 May 2019 19:41:18 +0200 Subject: [hadrian/macos] build broken In-Reply-To: References: Message-ID: <0c1a2096-a967-cd53-abfd-81b8aa48779d@well-typed.com> Hello! Could you create a ticket about this with all the relevant details (OS X version, boot ghc version, commit, hadrian command, etc), and the 'hadrian' label? You should even feel free to mention @snowleopard and @alp there. Cheers On 22/05/2019 19:37, Shayne Fletcher via ghc-devs wrote: > I'm trying to isolate the commit that's causing this, but the deal is > on MacOS I'm seeing stage1 `ld` crashes linking `HStime`: > ``` > > 00x1052e2748__assert_rtn + 129 > > 10x1052be30fld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster, > ld::Fixup::Kind, bool, char const*) + 95 > > 20x1052e8736mach_o::relocatable::Parser::addFixup(mach_o::relocatable::Parser::SourceLocation > const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 34 > > 30x1052eaa9cmach_o::relocatable::Section::addRelocFixup(mach_o::relocatable::Parser&, > macho_relocation_info > const*) + 1722 > > 40x1052ff61bmach_o::relocatable::Section::makeFixups(mach_o::relocatable::Parser&, > mach_o::relocatable::Parser::CFI_CU_InfoArrays const&) + 105 > > 50x1052faa66mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions > const&) + 2120 > > 60x1052f1250mach_o::relocatable::Parser::parse(unsigned char > const*, unsigned long long, char const*, long, ld::File::Ordinal, > mach_o::relocatable::ParserOptions const&) + 282 > > 70x10534352ald::tool::InputFiles::makeFile(Options::FileInfo const&, > bool) + 808 > > 80x105345f22ld::tool::InputFiles::parseWorkerThread() + 530 > > 90x7fff70a6b2eb_pthread_body + 126 > > 100x7fff70a6e249_pthread_start + 66 > > A linker snapshot was created at: > > /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot > > ld: Assertion failed: (name != NULL), function Fixup, file > /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, > line 724. > ``` > I can replicate this on multiple machines and different versions of > xcode command line tools. > > Any ideas? > > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Wed May 22 17:42:26 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Wed, 22 May 2019 19:42:26 +0200 Subject: [hadrian/windows] build broken In-Reply-To: References: Message-ID: Yes, I suspect so, even though I'll let David (cc'd) talk about this, as he's the one who's been working on this. On 22/05/2019 19:03, Shayne Fletcher via ghc-devs wrote: > I guess, > > On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher > > wrote: > > Windows builds with hadrian are currently failing with "file does > not exist and no build rule available" > `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have > an ideas on how to overcome that? > > > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi > and RTS rules" (@DavidEichmann). > > I get the feeling that the current state of affairs is known and there > are MRs working their way through the system to restore things already? > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Wed May 22 17:56:13 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 22 May 2019 13:56:13 -0400 Subject: [hadrian/macos] build broken In-Reply-To: <0c1a2096-a967-cd53-abfd-81b8aa48779d@well-typed.com> References: <0c1a2096-a967-cd53-abfd-81b8aa48779d@well-typed.com> Message-ID: Here you go Alp https://gitlab.haskell.org/ghc/ghc/issues/16685. Hope this helps! On Wed, May 22, 2019 at 1:41 PM Alp Mestanogullari wrote: > Hello! > > Could you create a ticket about this with all the relevant details (OS X > version, boot ghc version, commit, hadrian command, etc), and the 'hadrian' > label? You should even feel free to mention @snowleopard and @alp there. > > Cheers > On 22/05/2019 19:37, Shayne Fletcher via ghc-devs wrote: > > I'm trying to isolate the commit that's causing this, but the deal is on > MacOS I'm seeing stage1 `ld` crashes linking `HStime`: > ``` > > 0 0x1052e2748 __assert_rtn + 129 > > 1 0x1052be30f ld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster, > ld::Fixup::Kind, bool, char const*) + 95 > > 2 0x1052e8736 mach_o::relocatable::Parser::addFixup(mach_o::relocatable::Parser::SourceLocation > const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 34 > > 3 0x1052eaa9c mach_o::relocatable::Section::addRelocFixup(mach_o::relocatable::Parser&, > macho_relocation_info > const*) + 1722 > > 4 0x1052ff61b mach_o::relocatable::Section::makeFixups(mach_o::relocatable::Parser&, > mach_o::relocatable::Parser::CFI_CU_InfoArrays const&) + 105 > > 5 0x1052faa66 mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions > const&) + 2120 > > 6 0x1052f1250 mach_o::relocatable::Parser::parse(unsigned char > const*, unsigned long long, char const*, long, ld::File::Ordinal, > mach_o::relocatable::ParserOptions const&) + 282 > > 7 0x10534352a ld::tool::InputFiles::makeFile(Options::FileInfo const&, > bool) + 808 > > 8 0x105345f22 ld::tool::InputFiles::parseWorkerThread() + 530 > > 9 0x7fff70a6b2eb _pthread_body + 126 > > 10 0x7fff70a6e249 _pthread_start + 66 > > A linker snapshot was created at: > > /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot > > ld: Assertion failed: (name != NULL), function Fixup, file > /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, line > 724. > ``` > I can replicate this on multiple machines and different versions of xcode > command line tools. > > Any ideas? > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich > Street, 47th Floor > > New York, NY 10007, USA > > 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. If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Alp Mestanogullari, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England and Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London, W9 2NF, England > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Wed May 22 19:15:12 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 22 May 2019 15:15:12 -0400 Subject: [hadrian/macos] build broken In-Reply-To: References: <0c1a2096-a967-cd53-abfd-81b8aa48779d@well-typed.com> Message-ID: Hi Alp, Just confirming now but it seems its https://gitlab.haskell.org/ghc/ghc/commit/e529c65eacf595006dd5358491d28c202d673732 where the breakage came in ("Remove all target specific portions of Config.hs" @John Ericson). On Wed, May 22, 2019 at 1:56 PM Shayne Fletcher wrote: > Here you go Alp https://gitlab.haskell.org/ghc/ghc/issues/16685. Hope > this helps! > > On Wed, May 22, 2019 at 1:41 PM Alp Mestanogullari > wrote: > >> Hello! >> >> Could you create a ticket about this with all the relevant details (OS X >> version, boot ghc version, commit, hadrian command, etc), and the 'hadrian' >> label? You should even feel free to mention @snowleopard and @alp there. >> >> Cheers >> On 22/05/2019 19:37, Shayne Fletcher via ghc-devs wrote: >> >> I'm trying to isolate the commit that's causing this, but the deal is on >> MacOS I'm seeing stage1 `ld` crashes linking `HStime`: >> ``` >> >> 0 0x1052e2748 __assert_rtn + 129 >> >> 1 0x1052be30f ld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster, >> ld::Fixup::Kind, bool, char const*) + 95 >> >> 2 0x1052e8736 mach_o::relocatable::Parser::addFixup(mach_o::relocatable::Parser::SourceLocation >> const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 34 >> >> 3 0x1052eaa9c mach_o::relocatable::Section::addRelocFixup(mach_o::relocatable::Parser&, >> macho_relocation_info > const*) + 1722 >> >> 4 0x1052ff61b mach_o::relocatable::Section::makeFixups(mach_o::relocatable::Parser&, >> mach_o::relocatable::Parser::CFI_CU_InfoArrays const&) + 105 >> >> 5 0x1052faa66 mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions >> const&) + 2120 >> >> 6 0x1052f1250 mach_o::relocatable::Parser::parse(unsigned char >> const*, unsigned long long, char const*, long, ld::File::Ordinal, >> mach_o::relocatable::ParserOptions const&) + 282 >> >> 7 0x10534352a ld::tool::InputFiles::makeFile(Options::FileInfo const&, >> bool) + 808 >> >> 8 0x105345f22 ld::tool::InputFiles::parseWorkerThread() + 530 >> >> 9 0x7fff70a6b2eb _pthread_body + 126 >> >> 10 0x7fff70a6e249 _pthread_start + 66 >> >> A linker snapshot was created at: >> >> /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot >> >> ld: Assertion failed: (name != NULL), function Fixup, file >> /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, line >> 724. >> ``` >> I can replicate this on multiple machines and different versions of xcode >> command line tools. >> >> Any ideas? >> >> -- >> Shayne Fletcher >> Language Engineer >> c: +1 917 699 7763 >> e: shayne.fletcher at daml.com >> Digital Asset Holdings, LLC >> 4 World Trade Center 150 >> Greenwich Street, 47th Floor >> >> New York, NY 10007, USA >> >> 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. If you are not the >> intended recipient, please delete this message. >> >> _______________________________________________ >> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -- >> Alp Mestanogullari, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England and Wales, OC335890 >> 118 Wymering Mansions, Wymering Road, London, W9 2NF, England >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich > Street, 47th Floor > > New York, NY 10007, USA > > digitalasset.com > > -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Wed May 22 19:17:28 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Wed, 22 May 2019 21:17:28 +0200 Subject: [hadrian/macos] build broken In-Reply-To: References: <0c1a2096-a967-cd53-abfd-81b8aa48779d@well-typed.com> Message-ID: I @'d the author of that patch on your ticket. On 22/05/2019 21:15, Shayne Fletcher wrote: > Hi Alp, > > Just confirming now but it seems its > https://gitlab.haskell.org/ghc/ghc/commit/e529c65eacf595006dd5358491d28c202d673732 where > the breakage came in ("Remove all target specific portions of > Config.hs" @John Ericson). > > On Wed, May 22, 2019 at 1:56 PM Shayne Fletcher > > wrote: > > Here you go Alp https://gitlab.haskell.org/ghc/ghc/issues/16685. > Hope this helps! > > On Wed, May 22, 2019 at 1:41 PM Alp Mestanogullari > > wrote: > > Hello! > > Could you create a ticket about this with all the relevant > details (OS X version, boot ghc version, commit, hadrian > command, etc), and the 'hadrian' label? You should even feel > free to mention @snowleopard and @alp there. > > Cheers > > On 22/05/2019 19:37, Shayne Fletcher via ghc-devs wrote: >> I'm trying to isolate the commit that's causing this, but the >> deal is on MacOS I'm seeing stage1 `ld` crashes linking `HStime`: >> ``` >> >> 00x1052e2748__assert_rtn + 129 >> >> 10x1052be30fld::Fixup::Fixup(unsigned int, >> ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 95 >> >> 20x1052e8736mach_o::relocatable::Parser::addFixup(mach_o::relocatable::Parser::SourceLocation >> const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char >> const*) + 34 >> >> 30x1052eaa9cmach_o::relocatable::Section::addRelocFixup(mach_o::relocatable::Parser&, >> macho_relocation_info > const*) + 1722 >> >> 40x1052ff61bmach_o::relocatable::Section::makeFixups(mach_o::relocatable::Parser&, >> mach_o::relocatable::Parser::CFI_CU_InfoArrays >> const&) + 105 >> >> 50x1052faa66mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions >> const&) + 2120 >> >> 60x1052f1250mach_o::relocatable::Parser::parse(unsigned >> char const*, unsigned long long, char const*, long, >> ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) >> + 282 >> >> 70x10534352ald::tool::InputFiles::makeFile(Options::FileInfo >> const&, bool) + 808 >> >> 80x105345f22ld::tool::InputFiles::parseWorkerThread() + 530 >> >> 90x7fff70a6b2eb_pthread_body + 126 >> >> 100x7fff70a6e249_pthread_start + 66 >> >> A linker snapshot was created at: >> >> /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot >> >> ld: Assertion failed: (name != NULL), function Fixup, file >> /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, >> line 724. >> ``` >> I can replicate this on multiple machines and different >> versions of xcode command line tools. >> >> Any ideas? >> >> >> -- >> Shayne Fletcher >> Language Engineer >> c: +1 917 699 7763 >> e: shayne.fletcher at daml.com >> Digital Asset Holdings, LLC >> 4 World Trade Center 150 Greenwich Street, 47th Floor >> >> New York, NY 10007, USA >> >> 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. If you are >> not the intended recipient, please delete this message. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Alp Mestanogullari, Haskell Consultant > Well-Typed LLP,https://www.well-typed.com/ > > Registered in England and Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London, W9 2NF, England > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > digitalasset.com > > > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed May 22 22:49:22 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 22 May 2019 15:49:22 -0700 Subject: Processing MRs very slow? In-Reply-To: References: Message-ID: Great thanks! How can I have a look at Marge-bot's queue? Perhaps it is worth updating Step 7 or 8 of https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs 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 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 at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From shayne.fletcher at daml.com Thu May 23 11:12:05 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 23 May 2019 07:12:05 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: Message-ID: No comments on this. Maybe I should raise a ticket? Anybody got an email address to ping David on? ---------- Forwarded message --------- From: Shayne Fletcher Date: Wed, May 22, 2019, 13:03 Subject: Re: [hadrian/windows] build broken To: GHC developers I guess, On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher wrote: > Windows builds with hadrian are currently failing with "file does not > exist and no build rule available" > `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas > on how to overcome that? > > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi and RTS rules" (@DavidEichmann). I get the feeling that the current state of affairs is known and there are MRs working their way through the system to restore things already? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Thu May 23 12:09:29 2019 From: davide at well-typed.com (David Eichmann) Date: Thu, 23 May 2019 13:09:29 +0100 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: Message-ID: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Ooops I've let this thread pass by me, but this is most likely due to my latest refactoring of libffi rules in Hadrian. No need to create a new issue, I'll just reopen #16304, and have a look at this now. On that note, Alp, are we planning on adding a hadrian/windows CI job soon? - David E On 5/23/19 12:12 PM, Shayne Fletcher via ghc-devs wrote: > No comments on this. Maybe I should raise a ticket? Anybody got an > email address to ping David on? > > ---------- Forwarded message --------- > From: *Shayne Fletcher* > > Date: Wed, May 22, 2019, 13:03 > Subject: Re: [hadrian/windows] build broken > To: GHC developers > > > > I guess, > > On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher > > wrote: > > Windows builds with hadrian are currently failing with "file does > not exist and no build rule available" > `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have > an ideas on how to overcome that? > > > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi > and RTS rules" (@DavidEichmann). > > I get the feeling that the current state of affairs is known and there > are MRs working their way through the system to restore things already? > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Thu May 23 12:13:15 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Thu, 23 May 2019 14:13:15 +0200 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: Yes. We actually had one until a few weeks ago but it became really unstable because of some cache messing about with cabal-install's ability to build Hadrian, see https://gitlab.haskell.org/ghc/ghc/issues/16574. I need to figure this out soon indeed, I'll do my best to get us a working Windows/Hadrian job ASAP. On 23/05/2019 14:09, David Eichmann wrote: > > Ooops I've let this thread pass by me, but this is most likely due to > my latest refactoring of libffi rules in Hadrian. No need to create a > new issue, I'll just reopen #16304, and have a look at this now. > > On that note, Alp, are we planning on adding a hadrian/windows CI job > soon? > > - David E > > On 5/23/19 12:12 PM, Shayne Fletcher via ghc-devs wrote: >> No comments on this. Maybe I should raise a ticket? Anybody got an >> email address to ping David on? >> >> ---------- Forwarded message --------- >> From: *Shayne Fletcher* > > >> Date: Wed, May 22, 2019, 13:03 >> Subject: Re: [hadrian/windows] build broken >> To: GHC developers > >> >> >> I guess, >> >> On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher >> > wrote: >> >> Windows builds with hadrian are currently failing with "file does >> not exist and no build rule available" >> `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have >> an ideas on how to overcome that? >> >> >> relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi >> and RTS rules" (@DavidEichmann). >> >> I get the feeling that the current state of affairs is known and >> there are MRs working their way through the system to restore things >> already? >> -- >> Shayne Fletcher >> Language Engineer >> c: +1 917 699 7763 >> e: shayne.fletcher at daml.com >> Digital Asset Holdings, LLC >> 4 World Trade Center 150 Greenwich Street, 47th Floor >> >> New York, NY 10007, USA >> >> 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 >> . If you are not >> the intended recipient, please delete this message. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 23 12:58:52 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 23 May 2019 08:58:52 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: On Thu, May 23, 2019 at 8:13 AM Alp Mestanogullari wrote: > Yes. We actually had one until a few weeks ago but it became really > unstable because of some cache messing about with cabal-install's ability > to build Hadrian, see https://gitlab.haskell.org/ghc/ghc/issues/16574. > > I need to figure this out soon indeed, I'll do my best to get us a working > Windows/Hadrian job ASAP. > Nice. We really, really need this and for MacOS too! On 23/05/2019 14:09, David Eichmann wrote: > > Ooops I've let this thread pass by me, but this is most likely due to my > latest refactoring of libffi rules in Hadrian. No need to create a new > issue, I'll just reopen #16304, and have a look at this now. > > On that note, Alp, are we planning on adding a hadrian/windows CI job soon? > > - David E > On 5/23/19 12:12 PM, Shayne Fletcher via ghc-devs wrote: > > No comments on this. Maybe I should raise a ticket? Anybody got an email > address to ping David on? > > ---------- Forwarded message --------- > From: Shayne Fletcher > Date: Wed, May 22, 2019, 13:03 > Subject: Re: [hadrian/windows] build broken > To: GHC developers > > > I guess, > > On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher > wrote: > >> Windows builds with hadrian are currently failing with "file does not >> exist and no build rule available" >> `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas >> on how to overcome that? >> >> > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi and > RTS rules" (@DavidEichmann). > > I get the feeling that the current state of affairs is known and there are > MRs working their way through the system to restore things already? > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich > Street, 47th Floor > > New York, NY 10007, USA > > 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. If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > 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 > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Alp Mestanogullari, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England and Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London, W9 2NF, England > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 23 12:59:33 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 23 May 2019 08:59:33 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: On Thu, May 23, 2019 at 8:09 AM David Eichmann wrote: > Ooops I've let this thread pass by me, but this is most likely due to my > latest refactoring of libffi rules in Hadrian. No need to create a new > issue, I'll just reopen #16304, and have a look at this now. > Sounds good. Thanks David. > On that note, Alp, are we planning on adding a hadrian/windows CI job soon? > > - David E > On 5/23/19 12:12 PM, Shayne Fletcher via ghc-devs wrote: > > No comments on this. Maybe I should raise a ticket? Anybody got an email > address to ping David on? > > ---------- Forwarded message --------- > From: Shayne Fletcher > Date: Wed, May 22, 2019, 13:03 > Subject: Re: [hadrian/windows] build broken > To: GHC developers > > > I guess, > > On Wed, May 22, 2019 at 12:27 PM Shayne Fletcher > wrote: > >> Windows builds with hadrian are currently failing with "file does not >> exist and no build rule available" >> `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas >> on how to overcome that? >> >> > relates to 0af519ac583c3544b1c4b1315b38ba0174d3ccb1, "Refactor libffi and > RTS rules" (@DavidEichmann). > > I get the feeling that the current state of affairs is known and there are > MRs working their way through the system to restore things already? > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich > Street, 47th Floor > > New York, NY 10007, USA > > 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. If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 23 14:11:56 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 23 May 2019 10:11:56 -0400 Subject: Fwd: GHC | Hadrian: ld crashes linking HStime on macos (#16685) In-Reply-To: References: Message-ID: Hi Andrey, On Thu, May 23, 2019 at 10:04 AM Andrey Mokhov 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 at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA digitalasset.com -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Fri May 24 11:10:07 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 24 May 2019 07:10:07 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: Hi David, On Thu, May 23, 2019 at 8:09 AM David Eichmann wrote: > Ooops I've let this thread pass by me, but this is most likely due to my > latest refactoring of libffi rules in Hadrian. No need to create a new > issue, I'll just reopen #16304, and have a look at this now. > Hate to nag - any updates? Also, did you mean #16653? What ticket should I subscribe to -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Fri May 24 11:33:18 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Fri, 24 May 2019 13:33:18 +0200 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: Hello Shayne, David and I figured out the cause of that problem, I am working on a patch, will put it up as a (WIP) MR as soon as it's ready. On 24/05/2019 13:10, Shayne Fletcher via ghc-devs wrote: > Hi David, > > On Thu, May 23, 2019 at 8:09 AM David Eichmann > wrote: > > Ooops I've let this thread pass by me, but this is most likely due > to my latest refactoring of libffi rules in Hadrian. No need to > create a new issue, I'll just reopen #16304, and have a look at > this now. > > Hate to nag - any updates? Also, did you mean #16653? What ticket > should I subscribe to > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Fri May 24 14:11:55 2019 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Fri, 24 May 2019 16:11:55 +0200 Subject: Overloaded names for Map/Set? Message-ID: <5CE7FBAB.10909@gmx.at> 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 From allbery.b at gmail.com Fri May 24 14:29:32 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 24 May 2019 10:29:32 -0400 Subject: Overloaded names for Map/Set? In-Reply-To: <5CE7FBAB.10909@gmx.at> References: <5CE7FBAB.10909@gmx.at> Message-ID: For what it's worth, the Edison packages provide such interfaces for many structures. You might want to ask about experiences. http://hackage.haskell.org/package/EdisonCore On Fri, May 24, 2019, 10:12 Andreas Klebinger wrote: > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri May 24 15:16:53 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 24 May 2019 08:16:53 -0700 Subject: Overloaded names for Map/Set? In-Reply-To: <5CE7FBAB.10909@gmx.at> References: <5CE7FBAB.10909@gmx.at> Message-ID: Hello, I think refactoring to use consistent naming is a good idea, but I am not sure about the class idea. To see if it is viable, we should list the types in question and the operations we'd like to overload. I find that with containers there tend to be two cases: either the operations are similar but not exactly the same and you have to do type hackery to make things fit, or you realize that you can just use the same type in multiple places. Iavor On Fri, May 24, 2019, 07:12 Andreas Klebinger wrote: > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Fri May 24 15:34:01 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 24 May 2019 11:34:01 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari wrote: > Hello Shayne, > > David and I figured out the cause of that problem, I am working on a > patch, will put it up as a (WIP) MR as soon as it's ready. > > Awesome! -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri May 24 16:09:35 2019 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 24 May 2019 13:09:35 -0300 Subject: Overloaded names for Map/Set? In-Reply-To: <5CE7FBAB.10909@gmx.at> References: <5CE7FBAB.10909@gmx.at> Message-ID: fwiw, I think this is a good idea On Fri, May 24, 2019 at 11:12 AM Andreas Klebinger wrote: > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sat May 25 11:08:10 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 25 May 2019 12:08:10 +0100 Subject: ZuriHac 2019 - GHC Track In-Reply-To: References: Message-ID: Andreas/Niklas, I can do a talk/demo of using tools such as `ghc-artefact-nix`, `haskell-ide-engine`, `ghcid`, GHC's debugger whilst working on GHC. Could you schedule in a 30 minute slot for that please if you think it would be of interest. Cheers, Matt On Tue, Apr 23, 2019 at 5:52 PM Andreas Herrmann wrote: > > 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/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nicolas.frisby at gmail.com Sun May 26 04:10:27 2019 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Sat, 25 May 2019 21:10:27 -0700 Subject: wiki page of notes for type checker plugin authors Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Mon May 27 10:59:13 2019 From: davide at well-typed.com (David Eichmann) Date: Mon, 27 May 2019 11:59:13 +0100 Subject: Is your MR failing CI test T9630 or haddock.base? Message-ID: <1cb1399f-ed50-bca7-8593-e81aef70b021@well-typed.com> 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 From davide at well-typed.com Mon May 27 15:56:58 2019 From: davide at well-typed.com (David Eichmann) Date: Mon, 27 May 2019 16:56:58 +0100 Subject: Processing MRs very slow? In-Reply-To: References: <092eb20a-a797-915f-8aa2-517774d2384e@well-typed.com> Message-ID: <720793c2-aea4-9652-3f90-7947128e4b78@well-typed.com> 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 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 and linked tohome (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs andhttps://gitlab.haskell.org/ghc/ghc/wikis/home ) > > 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 > *Sent:* 23 May 2019 12:10 > *To:* Simon Peyton Jones ; Ben Gamari > > *Cc:* iavor.diatchki at 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 > . > 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 and linked tohome (I'm trying to avoid too much duplication betweenhttps://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs andhttps://gitlab.haskell.org/ghc/ghc/wikis/home ) > *   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 > 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 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 On Behalf Of Iavor Diatchki > > |  Sent: 22 May 2019 23:49 > > |  To: David Eichmann > > |  Cc: ghc-devs > > |  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 > > |  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 at 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 at 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 at 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 27 21:25:00 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 27 May 2019 17:25:00 -0400 Subject: Building GHC 8.4.3 Cross-Compiler Linux x86 -> Linux ARM In-Reply-To: References: Message-ID: <878suroaja.fsf@smart-cactus.org> Michael Dunn 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue May 28 09:14:56 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 May 2019 09:14:56 +0000 Subject: Processing MRs very slow? In-Reply-To: <720793c2-aea4-9652-3f90-7947128e4b78@well-typed.com> References: <092eb20a-a797-915f-8aa2-517774d2384e@well-typed.com> <720793c2-aea4-9652-3f90-7947128e4b78@well-typed.com> Message-ID: This leave one loose end: /home is left almost empty I think /home can give a little overview of what’s on the wiki, including: * A copy of what’s in the side-bar, annotated with what’s in each bit. * A pointer to the title list for the wiki (which we auto-generate I think). I’m sure other stuff will occur to us! Thanks for doing this. Simon From: David Eichmann Sent: 27 May 2019 16:57 To: GHC developers Cc: Ben Gamari ; Simon Peyton Jones Subject: Re: Processing MRs very slow? 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 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 in fixing-bugs and linked to home (I'm trying to avoid too much duplication between https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs and https://gitlab.haskell.org/ghc/ghc/wikis/home) 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 Sent: 23 May 2019 12:10 To: Simon Peyton Jones ; Ben Gamari Cc: iavor.diatchki at 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. 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 in fixing-bugs and linked to home (I'm trying to avoid too much duplication between https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs and https://gitlab.haskell.org/ghc/ghc/wikis/home) * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. * I've added some info in https://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request Hope this is better now. Ben maybe you'd like to double check the bullet list in https://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request 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 On Behalf Of Iavor Diatchki | Sent: 22 May 2019 23:49 | To: David Eichmann | Cc: ghc-devs | 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 | 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 at 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 at 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 at 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Tue May 28 10:01:01 2019 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Tue, 28 May 2019 18:01:01 +0800 Subject: Building GHC 8.4.3 Cross-Compiler Linux x86 -> Linux ARM In-Reply-To: <878suroaja.fsf@smart-cactus.org> References: <878suroaja.fsf@smart-cactus.org> Message-ID: <081F5D6D-EC06-40B6-AAD2-272A34EF47DB@gmail.com> Hi Michael, any reason you want to build specifically 8.4.3? And any specific reason you want to use 8.0.2 to build it? Anyway, you likely don't want to build unregistered, but use the llvm backend. You want to set the BuildFlavour to quick-cross, e.g. with sed -E "s/^#BuildFlavour[ ]+= quick-cross$/BuildFlavour = quick-cross/" < mk/build.mk.sample > mk/build.mk Once you have your compiler built, you'll likely want to use toolchain wrapper[1] to make things a bit easier. If you just want to try to build some simple code for a raspberry pi, you could also try the experimental pre-built cross compilers from[2] Cheers, Moritz -- [1]: https://github.com/zw3rk/toolchain-wrapper [2]: http://hackage.mobilehaskell.org/ > On May 28, 2019, at 5:25 AM, Ben Gamari wrote: > > Michael Dunn 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue May 28 12:54:55 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 May 2019 12:54:55 +0000 Subject: Processing MRs very slow? In-Reply-To: <720793c2-aea4-9652-3f90-7947128e4b78@well-typed.com> References: <092eb20a-a797-915f-8aa2-517774d2384e@well-typed.com> <720793c2-aea4-9652-3f90-7947128e4b78@well-typed.com> Message-ID: David Ben writes (on #16586) @simonpj, in general GHC HQ sets the milestone during triage (which I did in this case; I only realized that Iavor had submitted an MR after I left the comment requesting that he set the milestone). Could you include this point in your workflow revisions? Simon From: David Eichmann Sent: 27 May 2019 16:57 To: GHC developers Cc: Ben Gamari ; Simon Peyton Jones Subject: Re: Processing MRs very slow? 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 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 in fixing-bugs and linked to home (I'm trying to avoid too much duplication between https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs and https://gitlab.haskell.org/ghc/ghc/wikis/home) 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 Sent: 23 May 2019 12:10 To: Simon Peyton Jones ; Ben Gamari Cc: iavor.diatchki at 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. 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 in fixing-bugs and linked to home (I'm trying to avoid too much duplication between https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs and https://gitlab.haskell.org/ghc/ghc/wikis/home) * Monitoring progress if it doesn't land within 24 hrs; even knowing when to time out would help. * I've added some info in https://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request Hope this is better now. Ben maybe you'd like to double check the bullet list in https://gitlab.haskell.org/ghc/ghc/wikis/home#merging-your-merge-request 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 On Behalf Of Iavor Diatchki | Sent: 22 May 2019 23:49 | To: David Eichmann | Cc: ghc-devs | 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 | 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 at 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 at 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 at 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 28 14:09:22 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 May 2019 14:09:22 +0000 Subject: Clean build fails with make Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 28 14:55:01 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 May 2019 14:55:01 +0000 Subject: newtype workers In-Reply-To: <03856FD4-F379-4269-9F4A-5222B126CBEB@cs.brynmawr.edu> References: <03856FD4-F379-4269-9F4A-5222B126CBEB@cs.brynmawr.edu> Message-ID: | 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 | Sent: 25 May 2019 11:50 | To: Simon Peyton Jones | 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 From ben at smart-cactus.org Tue May 28 21:37:07 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 28 May 2019 17:37:07 -0400 Subject: ZuriHac 2019 - GHC Track In-Reply-To: References: Message-ID: <87tvdemfb5.fsf@smart-cactus.org> Andreas Herrmann writes: > Dear GHC devs, > I've been rather quiet on this since it's been unclear whether I will be able to make it to ZuriHac this year. While I would love to be there (and perhaps do some hiking after), at this point chances are unfortunately looking rather slim; it looks like I may have contracted Lyme disease so international traveling likely isn't a good idea in the next couple of months. I can, however, try to be around on IRC as festivities are underway. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue May 28 21:55:53 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 28 May 2019 17:55:53 -0400 Subject: Clean build fails with make In-Reply-To: References: Message-ID: <87r28imefv.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From klebinger.andreas at gmx.at Wed May 29 10:48:17 2019 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Wed, 29 May 2019 12:48:17 +0200 Subject: Container type classes In-Reply-To: References: Message-ID: <5CEE6371.2010406@gmx.at> ghc-devs-request at haskell.org schrieb: > Hello, > > I think refactoring to use consistent naming is a good idea, but I am > not sure about the class idea. > > To see if it is viable, we should list the types in question and the > operations we'd like to overload. > > I find that with containers there tend to be two cases: either the > operations are similar but not exactly the same and you have to do > type hackery to make things fit, or you realize that you can just use > the same type in multiple places. > > Iavor The function prototype are already part of the merge request. See here: https://gitlab.haskell.org/ghc/ghc/blob/a0781d746c223636a90a0837fe678aab5b70e4b6/compiler/structures/Collections.hs As for the data structures in question these are: * EnumSet * Data.IntSet * Data.Set * UniqSet * UniqDSet * Data.IntMap * Data.Map * LabelMap * UniqFM * UniqDFM * UniqMap * Maybe the TrieMap Variants Maybe I missed some but these are all I can think of currently. But they are already plenty. Imo using type classes IS a kind of type hackery required "to make things fit". From simonpj at microsoft.com Wed May 29 11:35:20 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 29 May 2019 11:35:20 +0000 Subject: Clean build fails with make In-Reply-To: <725bac62-9609-4ab6-b5cc-fe41983b1fc9@www.fastmail.com> References: <87r28imefv.fsf@smart-cactus.org> <725bac62-9609-4ab6-b5cc-fe41983b1fc9@www.fastmail.com> Message-ID: | 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 | Sent: 28 May 2019 23:33 | To: Ben Gamari | Cc: Simon Peyton Jones ; GHC developers | 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 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 From arnaud.spiwack at tweag.io Wed May 29 12:30:15 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 29 May 2019 14:30:15 +0200 Subject: Two weeks left for Haskell Exchange talk proposals Message-ID: 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/1FAIpQLSeJgeTqAdYLBlRcO9PDzI3yrR22CqzhInHpelnqWzOrs5Wg9A/viewform -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed May 29 17:52:47 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 29 May 2019 10:52:47 -0700 Subject: Container type classes In-Reply-To: <5CEE6371.2010406@gmx.at> References: <5CEE6371.2010406@gmx.at> Message-ID: Hi, having a common pattern for naming the operations certainly seems nice. I am ambivalent if we do this with a class, or just name the operations the same way, and use the module system. The type hackery I was referring to was the type family for the set elements and map keys you were referring to. It looks like the maps we have are uniform enough that one type family per class does the job, so I think the class you came with looks nice. -Iavor PS: the type hacker I was referring to was having to add more type families, for example if we had a map that can only store one type of elements, but it looks like this is not the case here. On Wed, May 29, 2019 at 3:48 AM Andreas Klebinger wrote: > > ghc-devs-request at haskell.org schrieb: > > Hello, > > > > I think refactoring to use consistent naming is a good idea, but I am > > not sure about the class idea. > > > > To see if it is viable, we should list the types in question and the > > operations we'd like to overload. > > > > I find that with containers there tend to be two cases: either the > > operations are similar but not exactly the same and you have to do > > type hackery to make things fit, or you realize that you can just use > > the same type in multiple places. > > > > Iavor > The function prototype are already part of the merge request. See here: > https://gitlab.haskell.org/ghc/ghc/blob/a0781d746c223636a90a0837fe678aab5b70e4b6/compiler/structures/Collections.hs > > As for the data structures in question these are: > * EnumSet > * Data.IntSet > * Data.Set > * UniqSet > * UniqDSet > > * Data.IntMap > * Data.Map > * LabelMap > * UniqFM > * UniqDFM > * UniqMap > > * Maybe the TrieMap Variants > > Maybe I missed some but these are all I can think of currently. But they > are already plenty. > > Imo using type classes IS a kind of type hackery required "to make > things fit". > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Wed May 29 20:07:41 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 29 May 2019 20:07:41 +0000 Subject: Container type classes In-Reply-To: References: <5CEE6371.2010406@gmx.at> Message-ID: | having a common pattern for naming the operations certainly seems | nice. I am ambivalent if we do this with a class, or just name the | operations the same way, and use the module system. This was my reaction too. Consistent naming, yes. Using a type class, when every invocation is at a statically known type (i.e. not leveraging the type class) seems less good. For example, eqType :: Type -> Type -> Bool, and I can search for every invocation of eqType. That can be very useful. Searching for every use of (==) and figuring out which of those zillions of calls are for equality of Type, is much less attractive. But I'm not going to die in the trenches for this. You are doing us a service by making everything systematic. The code that is finally executed will, I hope and believe, be the same either way. Simon The type hackery I | was referring to was the type family for the set elements and map | keys you were referring to. It looks like the maps we have are | uniform enough that one type family per class does the job, so I think the | class you came with looks nice. | | -Iavor | PS: the type hacker I was referring to was having to add more type | families, for example if we had a map that can only store one type of | elements, but it looks like this is not the case here. | | | On Wed, May 29, 2019 at 3:48 AM Andreas Klebinger | wrote: | > | > ghc-devs-request at haskell.org schrieb: | > > Hello, | > > | > > I think refactoring to use consistent naming is a good idea, but I | > > am not sure about the class idea. | > > | > > To see if it is viable, we should list the types in question and the | > > operations we'd like to overload. | > > | > > I find that with containers there tend to be two cases: either the | > > operations are similar but not exactly the same and you have to do | > > type hackery to make things fit, or you realize that you can just | > > use the same type in multiple places. | > > | > > Iavor | > The function prototype are already part of the merge request. See here: | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fblob%2Fa0781d746c223636a90a0837fe678aab5b | > 70e4b6%2Fcompiler%2Fstructures%2FCollections.hs&data=02%7C01%7Csim | > onpj%40microsoft.com%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988bf86f1 | > 41af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=lgu4jc9g3x | > H%2B9nDorkvPZjts9L1RpVLpexed1uJnyXA%3D&reserved=0 | > | > As for the data structures in question these are: | > * EnumSet | > * Data.IntSet | > * Data.Set | > * UniqSet | > * UniqDSet | > | > * Data.IntMap | > * Data.Map | > * LabelMap | > * UniqFM | > * UniqDFM | > * UniqMap | > | > * Maybe the TrieMap Variants | > | > Maybe I missed some but these are all I can think of currently. But | > they are already plenty. | > | > Imo using type classes IS a kind of type hackery required "to make | > things fit". | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at 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%7C4fe7780126ff475c3c7308d6e45e8586%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&sdata=fjw2 | > XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0 | _______________________________________________ | ghc-devs mailing list | ghc-devs at 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%7C4fe7780126ff475c3c7308d6 | e45e8586%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947491952787823&a | mp;sdata=fjw2XfNXANsWXsCb4mfQV0UFvyNNW%2BjqUhhCbOcr%2FhQ%3D&reserved=0 From shayne.fletcher at daml.com Thu May 30 10:55:59 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 30 May 2019 06:55:59 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: Hi Alp, On Fri, May 24, 2019 at 11:34 AM Shayne Fletcher wrote: > > On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari > wrote: > >> Hello Shayne, >> >> David and I figured out the cause of that problem, I am working on a >> patch, will put it up as a (WIP) MR as soon as it's ready. >> >> > Awesome! > Confused. I see 382dc918 ("Hadrian: always generate the libffi dynlibs manifest with globbing") has landed but I'm still getting, ``` 2019-05-30T10:47:57.5002328Z Error, file does not exist and no rule available: 2019-05-30T10:47:57.5002606Z _build/stage1/libffi/build/inst/bin/libffi-6.dll ``` What am I missing? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 30 11:01:12 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 30 May 2019 07:01:12 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: On Thu, May 30, 2019 at 6:55 AM Shayne Fletcher wrote: > Hi Alp, > > On Fri, May 24, 2019 at 11:34 AM Shayne Fletcher > wrote: > >> >> On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari >> wrote: >> >>> Hello Shayne, >>> >>> David and I figured out the cause of that problem, I am working on a >>> patch, will put it up as a (WIP) MR as soon as it's ready. >>> >>> >> Awesome! >> > Confused. I see 382dc918 ("Hadrian: always generate the libffi dynlibs > manifest with globbing") has landed but I'm still getting, > ``` > 2019-05-30T10:47:57.5002328Z Error, file does not exist and no rule > available: > 2019-05-30T10:47:57.5002606Z > _build/stage1/libffi/build/inst/bin/libffi-6.dll > ``` > What am I missing? > Golden rule of programming : when your program doesn't work and you've checked everything and are sure everything is right and your program still doesn't work then, one of the things you are sure of is wrong :) My front-running guess is that the patch hasn't landed. So many confusing notifications!! Sorry for the noise and fingers crossed for its progress in the merge queue! -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Thu May 30 12:32:21 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Thu, 30 May 2019 14:32:21 +0200 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> Message-ID: <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> Heh, it landed less than an hour ago. If the error persists, you'll probably want to do a clean build, by removing at the very least _build/stage1, even though I'd say it can't hurt to remove _build altogether. Along with that patch, I also brought back the Windows CI job and the error did not show up there, so I'm pretty confident you will not run into it again with a fresh, clean build. Do feel free to contact me or open a ticket if somehow the error still shows up, even against a clean tree. On 30/05/2019 13:01, Shayne Fletcher wrote: > > > On Thu, May 30, 2019 at 6:55 AM Shayne Fletcher > > wrote: > > Hi Alp, > > On Fri, May 24, 2019 at 11:34 AM Shayne Fletcher > > wrote: > > > On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari > > wrote: > > Hello Shayne, > > David and I figured out the cause of that problem, I am > working on a patch, will put it up as a (WIP) MR as soon > as it's ready. > > > > Awesome! > > Confused. I see 382dc918 ("Hadrian: always generate the libffi > dynlibs manifest with globbing") has landed but I'm still getting, > ``` > 2019-05-30T10:47:57.5002328Z Error, file does not exist and no > rule available: > 2019-05-30T10:47:57.5002606Z > _build/stage1/libffi/build/inst/bin/libffi-6.dll > ``` > What am I missing? > > > Golden rule of programming : when your program doesn't work and you've > checked everything and are sure everything is right and your program > still doesn't work then, one of the things you are sure of is wrong :) > > My front-running guess is that the patch hasn't landed. So many > confusing notifications!! Sorry for the noise and fingers crossed for > its progress in the merge queue! > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 30 13:04:12 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 30 May 2019 09:04:12 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> Message-ID: On Thu, May 30, 2019 at 8:32 AM Alp Mestanogullari wrote: > Heh, it landed less than an hour ago. > > If the error persists, you'll probably want to do a clean build, by > removing at the very least _build/stage1, even though I'd say it can't hurt > to remove _build altogether. Along with that patch, I also brought back the > Windows CI job and the error did not show up there, so I'm pretty confident > you will not run into it again with a fresh, clean build. > > It's cooking now. Looking promising :) I build fresh every time. Good news on the Windows CI!! On that note, how are we doing on the MacOS front ? (Let me know if we need resources to make that happen - might be able to help if so!). > Do feel free to contact me or open a ticket if somehow the error still > shows up, even against a clean tree. > You bet. Thanks for your hard work! -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Thu May 30 13:17:54 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Thu, 30 May 2019 15:17:54 +0200 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> Message-ID: <67b24966-6107-0d5e-c0d7-9d2182f1b098@well-typed.com> I haven't (yet) worked on making an OS X job for Hadrian. I brought back the Windows/Hadrian CI job with that fix, but then tried running the testsuite, which didn't go well, see: https://gitlab.haskell.org/ghc/ghc/merge_requests/1035 https://gitlab.haskell.org/alp/ghc/-/jobs/87467 This seems to have brought back a problem that Ben and I started looking into and which led us to disabling that job in the first place... However, running the testsuite is one thing, but just making sure we can build GHC is another. I guess I can put together a patch to get us an OS X job that just builds GHC pretty quickly, and then later get both the Windows and OS X jobs to go as far as running the testsuite. That'd at least give us confidence that people can build GHC with Hadrian just fine on OS X. Regarding the resources, that certainly sounds like something that would help if we are to double the number of OS X builds, indeed. I'm sure Ben (cc'd), who handles those matters, would be happy to talk about this with you! In the meantime, I will prepare a patch to add an OSX/Hadrian job. On 30/05/2019 15:04, Shayne Fletcher wrote: > > > On Thu, May 30, 2019 at 8:32 AM Alp Mestanogullari > wrote: > > Heh, it landed less than an hour ago. > > If the error persists, you'll probably want to do a clean build, > by removing at the very least _build/stage1, even though I'd say > it can't hurt to remove _build altogether. Along with that patch, > I also brought back the Windows CI job and the error did not show > up there, so I'm pretty confident you will not run into it again > with a fresh, clean build. > > It's cooking now. Looking promising :) I build fresh every time. Good > news on the Windows CI!! On that note, how are we doing on the MacOS > front ? (Let me know if we need resources to make that happen - might > be able to help if so!). > > Do feel free to contact me or open a ticket if somehow the error > still shows up, even against a clean tree. > > You bet. Thanks for your hard work! > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: shayne.fletcher at daml.com > Digital Asset Holdings, LLC > 4 World Trade Center 150 Greenwich Street, 47th Floor > > New York, NY 10007, USA > > 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 > . If you are not the > intended recipient, please delete this message. -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu May 30 13:21:22 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 30 May 2019 09:21:22 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: <67b24966-6107-0d5e-c0d7-9d2182f1b098@well-typed.com> References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> <67b24966-6107-0d5e-c0d7-9d2182f1b098@well-typed.com> Message-ID: On Thu, May 30, 2019 at 9:18 AM Alp Mestanogullari wrote: > I haven't (yet) worked on making an OS X job for Hadrian. I brought back > the Windows/Hadrian CI job with that fix, but then tried running the > testsuite, which didn't go well, see: > > https://gitlab.haskell.org/ghc/ghc/merge_requests/1035 > > https://gitlab.haskell.org/alp/ghc/-/jobs/87467 > > This seems to have brought back a problem that Ben and I started looking > into and which led us to disabling that job in the first place... However, > running the testsuite is one thing, but just making sure we can build GHC > is another. > Exactly. One problem at a time. Preventing changes that break the hadrian build from landing is what I advocate we concern ourselves with today. > I guess I can put together a patch to get us an OS X job that just builds > GHC pretty quickly, and then later get both the Windows and OS X jobs to go > as far as running the testsuite. That'd at least give us confidence that > people can build GHC with Hadrian just fine on OS X. > Perfect. > Regarding the resources, that certainly sounds like something that would > help if we are to double the number of OS X builds, indeed. I'm sure Ben > (cc'd), who handles those matters, would be happy to talk about this with > you! > Excellent. @Ben, let's talk! > In the meantime, I will prepare a patch to add an OSX/Hadrian job. > Thanks Alp! -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher at daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor New York, NY 10007, USA 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 . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu May 30 14:19:39 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 May 2019 10:19:39 -0400 Subject: Fwd: [hadrian/windows] build broken In-Reply-To: References: <28ef364b-ab73-908c-4565-add897bd4207@well-typed.com> <2cee919e-95a6-5abe-d54c-2296ad45195e@well-typed.com> Message-ID: <87muj4m3d5.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > On Thu, May 30, 2019 at 8:32 AM Alp Mestanogullari > wrote: > >> Heh, it landed less than an hour ago. >> >> If the error persists, you'll probably want to do a clean build, by >> removing at the very least _build/stage1, even though I'd say it can't hurt >> to remove _build altogether. Along with that patch, I also brought back the >> Windows CI job and the error did not show up there, so I'm pretty confident >> you will not run into it again with a fresh, clean build. >> >> It's cooking now. Looking promising :) I build fresh every time. Good news > on the Windows CI!! On that note, how are we doing on the MacOS front ? > (Let me know if we need resources to make that happen - might be able to > help if so!). > Hi Shayne, If you think you may be able to help with MacOS resources let's chat. This is certainly an area where we could use help. Currently we have two boxes which are generously provided to us by Davean Scies. These tend to struggle with the load and consequently jobs sometimes timeout before they are able to get a builder. It would be great to be able to do better here. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andrey.mokhov at newcastle.ac.uk Thu May 30 17:11:05 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 17:11:05 +0000 Subject: Container type classes References: Message-ID: Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey From matthewtpickering at gmail.com Thu May 30 17:25:37 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 30 May 2019 18:25:37 +0100 Subject: Container type classes In-Reply-To: References: Message-ID: If you care about performance then explicit dictionary passing is going to be worse than using type classes. At that point though, what do you gain from using the module system as you are just going to pass the same dictionaries into every function and never change them. So, for me, keep using modules but make the APIs of each module more consistent if you think it's worthwhile. On Thu, May 30, 2019 at 6:11 PM Andrey Mokhov wrote: > > Hi all, > > I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > > However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andrey.mokhov at newcastle.ac.uk Thu May 30 18:35:54 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 18:35:54 +0000 Subject: Container type classes In-Reply-To: References: Message-ID: > If you care about performance then explicit dictionary passing is > going to be worse than using type classes. Of course! But explicit dictionary passing works great for tests: the code size is reduced from O(#modules * #tests) when using the module system to O(#modules + #tests) when using dictionaries. For example, in the algebraic-graphs library, I have 500+ generic tests and around 10 modules. I don't want to write 5000 tests! Here is an example generic test which uses explicit dictionary passing: https://github.com/snowleopard/alga/blob/master/test/Algebra/Graph/Test/Generic.hs#L303-L319. I don't think it would be possible to reuse this test for different graph data types by using the module system instead of dictionaries. (Perhaps, Backpack could help? I don't know it very well.) Cheers, Andrey -----Original Message----- From: Matthew Pickering [mailto:matthewtpickering at gmail.com] Sent: 30 May 2019 18:26 To: Andrey Mokhov Cc: ghc-devs at haskell.org; Andreas Klebinger Subject: Re: Container type classes If you care about performance then explicit dictionary passing is going to be worse than using type classes. At that point though, what do you gain from using the module system as you are just going to pass the same dictionaries into every function and never change them. So, for me, keep using modules but make the APIs of each module more consistent if you think it's worthwhile. On Thu, May 30, 2019 at 6:11 PM Andrey Mokhov wrote: > > Hi all, > > I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > > However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From a.pelenitsyn at gmail.com Thu May 30 19:56:02 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 30 May 2019 22:56:02 +0300 Subject: Container type classes In-Reply-To: References: Message-ID: Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov wrote: > Hi all, > > I tried to use type classes for unifying APIs of several similar data > structures and it didn't work well. (In my case I was working with graphs, > instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, > because you care about performance. You really want to use that > Very.Special.Set.insert because it has the right performance > characteristics for your task at hand. I found only *one* use-case for > writing polymorphic functions operating on something like IsSet: the > testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement > `member` and `insert`. Here you don't care about performance, only about > correctness! > > However, this approach leads to problems with type inference, confusing > error messages, and complexity. I found that it is much nicer to use > explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via > RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and > IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this > using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how > do I tell the compiler that in the IntSet case s ~ t in the map signature? > Shall I add more associated types, or "associated constraints" using > ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> > Set b -> Set (a, b), but no equivalent in IntSet and things get even more > grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu May 30 21:26:14 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 21:26:14 +0000 Subject: Container type classes In-Reply-To: References: Message-ID: Hi Artem, Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] Sent: 30 May 2019 20:56 To: Andrey Mokhov Cc: ghc-devs at haskell.org; Andreas Klebinger Subject: Re: Container type classes Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov > wrote: Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu May 30 21:31:30 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 30 May 2019 17:31:30 -0400 Subject: Container type classes In-Reply-To: References: Message-ID: They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: > Hi Artem, > > > > Thanks for the pointer, but this doesn’t seem to be a solution to my > challenge: they simply give up on overloading `map` for both Set and > IntSet. As a result, we can’t write polymorphic functions over Set and > IntSet if they involve any mapping. > > > > I looked at the prototype by Andreas Klebinger, and it doesn’t include the > method `setMap` either. > > > > Perhaps, Haskell’s type classes just can’t cope with this problem. > > > > *ducks for cover* > > > > Cheers, > > Andrey > > > > *From:* Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] > *Sent:* 30 May 2019 20:56 > *To:* Andrey Mokhov > *Cc:* ghc-devs at haskell.org; Andreas Klebinger > *Subject:* Re: Container type classes > > > > Hi Andrey, > > > > FWIW, mono-traversable ( > http://hackage.haskell.org/package/mono-traversable) suggests decoupling > IsSet and Funtor-like. > > > > In a nutshell, they define the IsSet class (in Data.Containers) with > typical set operations like member and singleton, union and intersection. > And then they tackle a (seemingly) independent problem of mapping > monomorphic containers (like IntSet, ByteString, etc.) with a separate > class MonoFunctor (in Data.MonoTraversable): > > > > class MonoFunctor mono where > omap :: (Element mono -> Element mono) -> mono -> mono > > > > And gazillion of instances for both polymorphic containers with a fixed > type parameter and monomorphic ones. > > > > -- > > Best wishes, > > Artem > > > > On Thu, 30 May 2019 at 20:11, Andrey Mokhov > wrote: > > Hi all, > > I tried to use type classes for unifying APIs of several similar data > structures and it didn't work well. (In my case I was working with graphs, > instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, > because you care about performance. You really want to use that > Very.Special.Set.insert because it has the right performance > characteristics for your task at hand. I found only *one* use-case for > writing polymorphic functions operating on something like IsSet: the > testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement > `member` and `insert`. Here you don't care about performance, only about > correctness! > > However, this approach leads to problems with type inference, confusing > error messages, and complexity. I found that it is much nicer to use > explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via > RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and > IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this > using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how > do I tell the compiler that in the IntSet case s ~ t in the map signature? > Shall I add more associated types, or "associated constraints" using > ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> > Set b -> Set (a, b), but no equivalent in IntSet and things get even more > grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu May 30 21:36:50 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 21:36:50 +0000 Subject: Container type classes In-Reply-To: References: Message-ID: Hi Brandon, Could you show the code? I have no idea how indexed monads could possibly be related here. All I want is to have a type class that unifies these two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Cheers, Andrey From: Brandon Allbery [mailto:allbery.b at gmail.com] Sent: 30 May 2019 22:32 To: Andrey Mokhov Cc: Artem Pelenitsyn ; Andreas Klebinger ; ghc-devs at haskell.org Subject: Re: Container type classes They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov > wrote: Hi Artem, Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] Sent: 30 May 2019 20:56 To: Andrey Mokhov > Cc: ghc-devs at haskell.org; Andreas Klebinger > Subject: Re: Container type classes Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov > wrote: Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Thu May 30 21:38:09 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 30 May 2019 14:38:09 -0700 Subject: Container type classes In-Reply-To: References: Message-ID: This is how you could define `map`. This is just for fun, and to discuss Haskell idioms---I am not suggesting we should do it. Of course, it might be a bit more general than what you'd like---for example it allows defining instances like `Fun IntSet (Set Int)` that, perhaps?, you'd like to disallow: {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} import Data.Set (Set) import qualified Data.Set as Set import Data.IntSet (IntSet) import qualified Data.IntSet as ISet class Col t where type Elem t -- ... As in Andreas's example class (Col a, Col b) => Fun a b where colMap :: (Elem a -> Elem b) -> a -> b instance Col (Set a) where type Elem (Set a) = a instance Col IntSet where type Elem IntSet = Int instance Fun IntSet IntSet where colMap = ISet.map instance Ord b => Fun (Set a) (Set b) where colMap = Set.map On Thu, May 30, 2019 at 2:32 PM Brandon Allbery wrote: > > They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: >> >> Hi Artem, >> >> >> >> Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. >> >> >> >> I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. >> >> >> >> Perhaps, Haskell’s type classes just can’t cope with this problem. >> >> >> >> *ducks for cover* >> >> >> >> Cheers, >> >> Andrey >> >> >> >> From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] >> Sent: 30 May 2019 20:56 >> To: Andrey Mokhov >> Cc: ghc-devs at haskell.org; Andreas Klebinger >> Subject: Re: Container type classes >> >> >> >> Hi Andrey, >> >> >> >> FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. >> >> >> >> In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): >> >> >> >> class MonoFunctor mono where >> omap :: (Element mono -> Element mono) -> mono -> mono >> >> >> >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. >> >> >> >> -- >> >> Best wishes, >> >> Artem >> >> >> >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov wrote: >> >> Hi all, >> >> I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) >> >> First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like >> >> memberInsertProperty x set = (member x (insert x set) == True) >> >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! >> >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: >> >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) >> >> where `member` and `insert` come from the SetAPI record via RecordWildCards. >> >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: >> >> singleton :: a -> Set a >> map :: Ord b => (a -> b) -> Set a -> Set b >> >> singleton :: Int -> IntSet >> map :: (Int -> Int) -> IntSet -> IntSet >> >> Could anyone please enlighten me about the right way to abstract over this using type classes? >> >> I tried a few approaches, for example: >> >> class IsSet s where >> type Elem s >> singleton :: Elem s -> s >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t >> >> Looks nice, but I can't define the IntSet instance: >> >> instance IsSet IntSet where >> type Elem IntSet = Int >> singleton = IntSet.singleton >> map = IntSet.map >> >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. >> >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. >> >> Cheers, >> Andrey >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From allbery.b at gmail.com Thu May 30 21:39:16 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 30 May 2019 17:39:16 -0400 Subject: Container type classes In-Reply-To: References: Message-ID: I was talking in general about why you don't find instances of Monad, etc. for Set or Map which require an additional constraint on the key. On Thu, May 30, 2019 at 5:36 PM Andrey Mokhov wrote: > Hi Brandon, > > > > Could you show the code? > > > > I have no idea how indexed monads could possibly be related here. All I > want is to have a type class that unifies these two methods: > > > > singleton :: a -> Set a > > map :: Ord b => (a -> b) -> Set a -> Set b > > > > singleton :: Int -> IntSet > > map :: (Int -> Int) -> IntSet -> IntSet > > > > Cheers, > > Andrey > > > > *From:* Brandon Allbery [mailto:allbery.b at gmail.com] > *Sent:* 30 May 2019 22:32 > *To:* Andrey Mokhov > *Cc:* Artem Pelenitsyn ; Andreas Klebinger < > klebinger.andreas at gmx.at>; ghc-devs at haskell.org > *Subject:* Re: Container type classes > > > > They can, with more work. You want indexed monads, so you can describe > types that have e.g. an ordering constraint as well as the Monad constraint. > > > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov < > andrey.mokhov at newcastle.ac.uk> wrote: > > Hi Artem, > > > > Thanks for the pointer, but this doesn’t seem to be a solution to my > challenge: they simply give up on overloading `map` for both Set and > IntSet. As a result, we can’t write polymorphic functions over Set and > IntSet if they involve any mapping. > > > > I looked at the prototype by Andreas Klebinger, and it doesn’t include the > method `setMap` either. > > > > Perhaps, Haskell’s type classes just can’t cope with this problem. > > > > *ducks for cover* > > > > Cheers, > > Andrey > > > > *From:* Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] > *Sent:* 30 May 2019 20:56 > *To:* Andrey Mokhov > *Cc:* ghc-devs at haskell.org; Andreas Klebinger > *Subject:* Re: Container type classes > > > > Hi Andrey, > > > > FWIW, mono-traversable ( > http://hackage.haskell.org/package/mono-traversable) suggests decoupling > IsSet and Funtor-like. > > > > In a nutshell, they define the IsSet class (in Data.Containers) with > typical set operations like member and singleton, union and intersection. > And then they tackle a (seemingly) independent problem of mapping > monomorphic containers (like IntSet, ByteString, etc.) with a separate > class MonoFunctor (in Data.MonoTraversable): > > > > class MonoFunctor mono where > omap :: (Element mono -> Element mono) -> mono -> mono > > > > And gazillion of instances for both polymorphic containers with a fixed > type parameter and monomorphic ones. > > > > -- > > Best wishes, > > Artem > > > > On Thu, 30 May 2019 at 20:11, Andrey Mokhov > wrote: > > Hi all, > > I tried to use type classes for unifying APIs of several similar data > structures and it didn't work well. (In my case I was working with graphs, > instead of sets or maps.) > > First, you rarely want to be polymorphic over the set representation, > because you care about performance. You really want to use that > Very.Special.Set.insert because it has the right performance > characteristics for your task at hand. I found only *one* use-case for > writing polymorphic functions operating on something like IsSet: the > testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement > `member` and `insert`. Here you don't care about performance, only about > correctness! > > However, this approach leads to problems with type inference, confusing > error messages, and complexity. I found that it is much nicer to use > explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via > RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and > IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this > using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how > do I tell the compiler that in the IntSet case s ~ t in the map signature? > Shall I add more associated types, or "associated constraints" using > ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> > Set b -> Set (a, b), but no equivalent in IntSet and things get even more > grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu May 30 21:58:48 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 21:58:48 +0000 Subject: Container type classes In-Reply-To: References: Message-ID: Many thanks Iavor, This looks very promising! I played with your encoding a little, but quickly came across type inference issues. The following doesn't compile: add3 :: (Fun s s, Elem s ~ Int) => s -> s add3 = colMap (+1) . colMap (+2) I'm getting: * Could not deduce: Elem a0 ~ Int from the context: (Fun s s, Elem s ~ Int) bound by the type signature for: add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s Expected type: Elem a0 -> Elem s Actual type: Int -> Int The type variable `a0' is ambiguous Fun s s is supposed to say that the intermediate type is `s` too, but I guess this is not how type class resolution works. Cheers, Andrey -----Original Message----- From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 30 May 2019 22:38 To: Brandon Allbery Cc: Andrey Mokhov ; Andreas Klebinger ; ghc-devs at haskell.org Subject: Re: Container type classes This is how you could define `map`. This is just for fun, and to discuss Haskell idioms---I am not suggesting we should do it. Of course, it might be a bit more general than what you'd like---for example it allows defining instances like `Fun IntSet (Set Int)` that, perhaps?, you'd like to disallow: {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} import Data.Set (Set) import qualified Data.Set as Set import Data.IntSet (IntSet) import qualified Data.IntSet as ISet class Col t where type Elem t -- ... As in Andreas's example class (Col a, Col b) => Fun a b where colMap :: (Elem a -> Elem b) -> a -> b instance Col (Set a) where type Elem (Set a) = a instance Col IntSet where type Elem IntSet = Int instance Fun IntSet IntSet where colMap = ISet.map instance Ord b => Fun (Set a) (Set b) where colMap = Set.map On Thu, May 30, 2019 at 2:32 PM Brandon Allbery wrote: > > They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: >> >> Hi Artem, >> >> >> >> Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. >> >> >> >> I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. >> >> >> >> Perhaps, Haskell’s type classes just can’t cope with this problem. >> >> >> >> *ducks for cover* >> >> >> >> Cheers, >> >> Andrey >> >> >> >> From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] >> Sent: 30 May 2019 20:56 >> To: Andrey Mokhov >> Cc: ghc-devs at haskell.org; Andreas Klebinger >> Subject: Re: Container type classes >> >> >> >> Hi Andrey, >> >> >> >> FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. >> >> >> >> In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): >> >> >> >> class MonoFunctor mono where >> omap :: (Element mono -> Element mono) -> mono -> mono >> >> >> >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. >> >> >> >> -- >> >> Best wishes, >> >> Artem >> >> >> >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov wrote: >> >> Hi all, >> >> I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) >> >> First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like >> >> memberInsertProperty x set = (member x (insert x set) == True) >> >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! >> >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: >> >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) >> >> where `member` and `insert` come from the SetAPI record via RecordWildCards. >> >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: >> >> singleton :: a -> Set a >> map :: Ord b => (a -> b) -> Set a -> Set b >> >> singleton :: Int -> IntSet >> map :: (Int -> Int) -> IntSet -> IntSet >> >> Could anyone please enlighten me about the right way to abstract over this using type classes? >> >> I tried a few approaches, for example: >> >> class IsSet s where >> type Elem s >> singleton :: Elem s -> s >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t >> >> Looks nice, but I can't define the IntSet instance: >> >> instance IsSet IntSet where >> type Elem IntSet = Int >> singleton = IntSet.singleton >> map = IntSet.map >> >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. >> >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. >> >> Cheers, >> Andrey >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From iavor.diatchki at gmail.com Thu May 30 22:15:59 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 30 May 2019 15:15:59 -0700 Subject: Container type classes In-Reply-To: References: Message-ID: Yeah, there is really no relation between the two parameters of `Fun`, so you'd have to specify the intermediate type manually. For example: add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s add3 = colMap @s (+1) . colMap (+2) I wouldn't say that it's a particularly convenient interface to work with, unless you are working in a setting where most of the containers have known types. On Thu, May 30, 2019 at 2:58 PM Andrey Mokhov wrote: > > Many thanks Iavor, > > This looks very promising! I played with your encoding a little, but quickly came across type inference issues. The following doesn't compile: > > add3 :: (Fun s s, Elem s ~ Int) => s -> s > add3 = colMap (+1) . colMap (+2) > > I'm getting: > > * Could not deduce: Elem a0 ~ Int > from the context: (Fun s s, Elem s ~ Int) > bound by the type signature for: > add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s > Expected type: Elem a0 -> Elem s > Actual type: Int -> Int > The type variable `a0' is ambiguous > > Fun s s is supposed to say that the intermediate type is `s` too, but I guess this is not how type class resolution works. > > Cheers, > Andrey > > -----Original Message----- > From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > Sent: 30 May 2019 22:38 > To: Brandon Allbery > Cc: Andrey Mokhov ; Andreas Klebinger ; ghc-devs at haskell.org > Subject: Re: Container type classes > > This is how you could define `map`. This is just for fun, and to > discuss Haskell idioms---I am not suggesting we should do it. Of > course, it might be a bit more general than what you'd like---for > example it allows defining instances like `Fun IntSet (Set Int)` that, > perhaps?, you'd like to disallow: > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > import Data.Set (Set) > import qualified Data.Set as Set > import Data.IntSet (IntSet) > import qualified Data.IntSet as ISet > > class Col t where > type Elem t > -- ... As in Andreas's example > > class (Col a, Col b) => Fun a b where > colMap :: (Elem a -> Elem b) -> a -> b > > instance Col (Set a) where > type Elem (Set a) = a > > instance Col IntSet where > type Elem IntSet = Int > > instance Fun IntSet IntSet where > colMap = ISet.map > > instance Ord b => Fun (Set a) (Set b) where > colMap = Set.map > > On Thu, May 30, 2019 at 2:32 PM Brandon Allbery wrote: > > > > They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. > > > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: > >> > >> Hi Artem, > >> > >> > >> > >> Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. > >> > >> > >> > >> I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. > >> > >> > >> > >> Perhaps, Haskell’s type classes just can’t cope with this problem. > >> > >> > >> > >> *ducks for cover* > >> > >> > >> > >> Cheers, > >> > >> Andrey > >> > >> > >> > >> From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] > >> Sent: 30 May 2019 20:56 > >> To: Andrey Mokhov > >> Cc: ghc-devs at haskell.org; Andreas Klebinger > >> Subject: Re: Container type classes > >> > >> > >> > >> Hi Andrey, > >> > >> > >> > >> FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. > >> > >> > >> > >> In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): > >> > >> > >> > >> class MonoFunctor mono where > >> omap :: (Element mono -> Element mono) -> mono -> mono > >> > >> > >> > >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. > >> > >> > >> > >> -- > >> > >> Best wishes, > >> > >> Artem > >> > >> > >> > >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov wrote: > >> > >> Hi all, > >> > >> I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) > >> > >> First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > >> > >> memberInsertProperty x set = (member x (insert x set) == True) > >> > >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > >> > >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > >> > >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > >> > >> where `member` and `insert` come from the SetAPI record via RecordWildCards. > >> > >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > >> > >> singleton :: a -> Set a > >> map :: Ord b => (a -> b) -> Set a -> Set b > >> > >> singleton :: Int -> IntSet > >> map :: (Int -> Int) -> IntSet -> IntSet > >> > >> Could anyone please enlighten me about the right way to abstract over this using type classes? > >> > >> I tried a few approaches, for example: > >> > >> class IsSet s where > >> type Elem s > >> singleton :: Elem s -> s > >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > >> > >> Looks nice, but I can't define the IntSet instance: > >> > >> instance IsSet IntSet where > >> type Elem IntSet = Int > >> singleton = IntSet.singleton > >> map = IntSet.map > >> > >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > >> > >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > >> > >> Cheers, > >> Andrey > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andrey.mokhov at newcastle.ac.uk Thu May 30 23:22:50 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 30 May 2019 23:22:50 +0000 Subject: Container type classes In-Reply-To: References: Message-ID: Thanks again Iavor, Despite the type inference issue, and the fact that this requires a separate type class, this is the best solution I've seen so far. Cheers, Andrey -----Original Message----- From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 30 May 2019 23:16 To: Andrey Mokhov Cc: Brandon Allbery ; Andreas Klebinger ; ghc-devs at haskell.org Subject: Re: Container type classes Yeah, there is really no relation between the two parameters of `Fun`, so you'd have to specify the intermediate type manually. For example: add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s add3 = colMap @s (+1) . colMap (+2) I wouldn't say that it's a particularly convenient interface to work with, unless you are working in a setting where most of the containers have known types. On Thu, May 30, 2019 at 2:58 PM Andrey Mokhov wrote: > > Many thanks Iavor, > > This looks very promising! I played with your encoding a little, but quickly came across type inference issues. The following doesn't compile: > > add3 :: (Fun s s, Elem s ~ Int) => s -> s > add3 = colMap (+1) . colMap (+2) > > I'm getting: > > * Could not deduce: Elem a0 ~ Int > from the context: (Fun s s, Elem s ~ Int) > bound by the type signature for: > add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s > Expected type: Elem a0 -> Elem s > Actual type: Int -> Int > The type variable `a0' is ambiguous > > Fun s s is supposed to say that the intermediate type is `s` too, but I guess this is not how type class resolution works. > > Cheers, > Andrey > > -----Original Message----- > From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > Sent: 30 May 2019 22:38 > To: Brandon Allbery > Cc: Andrey Mokhov ; Andreas Klebinger ; ghc-devs at haskell.org > Subject: Re: Container type classes > > This is how you could define `map`. This is just for fun, and to > discuss Haskell idioms---I am not suggesting we should do it. Of > course, it might be a bit more general than what you'd like---for > example it allows defining instances like `Fun IntSet (Set Int)` that, > perhaps?, you'd like to disallow: > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > import Data.Set (Set) > import qualified Data.Set as Set > import Data.IntSet (IntSet) > import qualified Data.IntSet as ISet > > class Col t where > type Elem t > -- ... As in Andreas's example > > class (Col a, Col b) => Fun a b where > colMap :: (Elem a -> Elem b) -> a -> b > > instance Col (Set a) where > type Elem (Set a) = a > > instance Col IntSet where > type Elem IntSet = Int > > instance Fun IntSet IntSet where > colMap = ISet.map > > instance Ord b => Fun (Set a) (Set b) where > colMap = Set.map > > On Thu, May 30, 2019 at 2:32 PM Brandon Allbery wrote: > > > > They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. > > > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: > >> > >> Hi Artem, > >> > >> > >> > >> Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. > >> > >> > >> > >> I looked at the prototype by Andreas Klebinger, and it doesn’t include the method `setMap` either. > >> > >> > >> > >> Perhaps, Haskell’s type classes just can’t cope with this problem. > >> > >> > >> > >> *ducks for cover* > >> > >> > >> > >> Cheers, > >> > >> Andrey > >> > >> > >> > >> From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] > >> Sent: 30 May 2019 20:56 > >> To: Andrey Mokhov > >> Cc: ghc-devs at haskell.org; Andreas Klebinger > >> Subject: Re: Container type classes > >> > >> > >> > >> Hi Andrey, > >> > >> > >> > >> FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. > >> > >> > >> > >> In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): > >> > >> > >> > >> class MonoFunctor mono where > >> omap :: (Element mono -> Element mono) -> mono -> mono > >> > >> > >> > >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. > >> > >> > >> > >> -- > >> > >> Best wishes, > >> > >> Artem > >> > >> > >> > >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov wrote: > >> > >> Hi all, > >> > >> I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) > >> > >> First, you rarely want to be polymorphic over the set representation, because you care about performance. You really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > >> > >> memberInsertProperty x set = (member x (insert x set) == True) > >> > >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > >> > >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > >> > >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > >> > >> where `member` and `insert` come from the SetAPI record via RecordWildCards. > >> > >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > >> > >> singleton :: a -> Set a > >> map :: Ord b => (a -> b) -> Set a -> Set b > >> > >> singleton :: Int -> IntSet > >> map :: (Int -> Int) -> IntSet -> IntSet > >> > >> Could anyone please enlighten me about the right way to abstract over this using type classes? > >> > >> I tried a few approaches, for example: > >> > >> class IsSet s where > >> type Elem s > >> singleton :: Elem s -> s > >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > >> > >> Looks nice, but I can't define the IntSet instance: > >> > >> instance IsSet IntSet where > >> type Elem IntSet = Int > >> singleton = IntSet.singleton > >> map = IntSet.map > >> > >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > >> > >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > >> > >> Cheers, > >> Andrey > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From clintonmead at gmail.com Fri May 31 01:11:12 2019 From: clintonmead at gmail.com (Clinton Mead) Date: Fri, 31 May 2019 11:11:12 +1000 Subject: Container type classes In-Reply-To: References: Message-ID: I'm not sure if this is related but the package Map-Classes provides about 50 functions on around a dozen key/value like datatypes e.g. Arrays, Maps, Sets (value is ()) etc. Even ByteStrings are included (Int -> Word8 mapping). You should be able to fairly easily add new types and even new functions to the instances if you give them default implementations. On Fri, May 31, 2019 at 9:23 AM Andrey Mokhov wrote: > Thanks again Iavor, > > Despite the type inference issue, and the fact that this requires a > separate type class, this is the best solution I've seen so far. > > Cheers, > Andrey > > -----Original Message----- > From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > Sent: 30 May 2019 23:16 > To: Andrey Mokhov > Cc: Brandon Allbery ; Andreas Klebinger < > klebinger.andreas at gmx.at>; ghc-devs at haskell.org > Subject: Re: Container type classes > > Yeah, there is really no relation between the two parameters of `Fun`, > so you'd have to specify the intermediate type manually. For example: > > add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s > add3 = colMap @s (+1) . colMap (+2) > > I wouldn't say that it's a particularly convenient interface to work > with, unless you are working in a setting where most of the containers > have known types. > > > On Thu, May 30, 2019 at 2:58 PM Andrey Mokhov > wrote: > > > > Many thanks Iavor, > > > > This looks very promising! I played with your encoding a little, but > quickly came across type inference issues. The following doesn't compile: > > > > add3 :: (Fun s s, Elem s ~ Int) => s -> s > > add3 = colMap (+1) . colMap (+2) > > > > I'm getting: > > > > * Could not deduce: Elem a0 ~ Int > > from the context: (Fun s s, Elem s ~ Int) > > bound by the type signature for: > > add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s > > Expected type: Elem a0 -> Elem s > > Actual type: Int -> Int > > The type variable `a0' is ambiguous > > > > Fun s s is supposed to say that the intermediate type is `s` too, but I > guess this is not how type class resolution works. > > > > Cheers, > > Andrey > > > > -----Original Message----- > > From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > > Sent: 30 May 2019 22:38 > > To: Brandon Allbery > > Cc: Andrey Mokhov ; Andreas Klebinger < > klebinger.andreas at gmx.at>; ghc-devs at haskell.org > > Subject: Re: Container type classes > > > > This is how you could define `map`. This is just for fun, and to > > discuss Haskell idioms---I am not suggesting we should do it. Of > > course, it might be a bit more general than what you'd like---for > > example it allows defining instances like `Fun IntSet (Set Int)` that, > > perhaps?, you'd like to disallow: > > > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > > > import Data.Set (Set) > > import qualified Data.Set as Set > > import Data.IntSet (IntSet) > > import qualified Data.IntSet as ISet > > > > class Col t where > > type Elem t > > -- ... As in Andreas's example > > > > class (Col a, Col b) => Fun a b where > > colMap :: (Elem a -> Elem b) -> a -> b > > > > instance Col (Set a) where > > type Elem (Set a) = a > > > > instance Col IntSet where > > type Elem IntSet = Int > > > > instance Fun IntSet IntSet where > > colMap = ISet.map > > > > instance Ord b => Fun (Set a) (Set b) where > > colMap = Set.map > > > > On Thu, May 30, 2019 at 2:32 PM Brandon Allbery > wrote: > > > > > > They can, with more work. You want indexed monads, so you can describe > types that have e.g. an ordering constraint as well as the Monad constraint. > > > > > > On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov < > andrey.mokhov at newcastle.ac.uk> wrote: > > >> > > >> Hi Artem, > > >> > > >> > > >> > > >> Thanks for the pointer, but this doesn’t seem to be a solution to my > challenge: they simply give up on overloading `map` for both Set and > IntSet. As a result, we can’t write polymorphic functions over Set and > IntSet if they involve any mapping. > > >> > > >> > > >> > > >> I looked at the prototype by Andreas Klebinger, and it doesn’t > include the method `setMap` either. > > >> > > >> > > >> > > >> Perhaps, Haskell’s type classes just can’t cope with this problem. > > >> > > >> > > >> > > >> *ducks for cover* > > >> > > >> > > >> > > >> Cheers, > > >> > > >> Andrey > > >> > > >> > > >> > > >> From: Artem Pelenitsyn [mailto:a.pelenitsyn at gmail.com] > > >> Sent: 30 May 2019 20:56 > > >> To: Andrey Mokhov > > >> Cc: ghc-devs at haskell.org; Andreas Klebinger > > > >> Subject: Re: Container type classes > > >> > > >> > > >> > > >> Hi Andrey, > > >> > > >> > > >> > > >> FWIW, mono-traversable ( > http://hackage.haskell.org/package/mono-traversable) suggests decoupling > IsSet and Funtor-like. > > >> > > >> > > >> > > >> In a nutshell, they define the IsSet class (in Data.Containers) with > typical set operations like member and singleton, union and intersection. > And then they tackle a (seemingly) independent problem of mapping > monomorphic containers (like IntSet, ByteString, etc.) with a separate > class MonoFunctor (in Data.MonoTraversable): > > >> > > >> > > >> > > >> class MonoFunctor mono where > > >> omap :: (Element mono -> Element mono) -> mono -> mono > > >> > > >> > > >> > > >> And gazillion of instances for both polymorphic containers with a > fixed type parameter and monomorphic ones. > > >> > > >> > > >> > > >> -- > > >> > > >> Best wishes, > > >> > > >> Artem > > >> > > >> > > >> > > >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov < > andrey.mokhov at newcastle.ac.uk> wrote: > > >> > > >> Hi all, > > >> > > >> I tried to use type classes for unifying APIs of several similar data > structures and it didn't work well. (In my case I was working with graphs, > instead of sets or maps.) > > >> > > >> First, you rarely want to be polymorphic over the set representation, > because you care about performance. You really want to use that > Very.Special.Set.insert because it has the right performance > characteristics for your task at hand. I found only *one* use-case for > writing polymorphic functions operating on something like IsSet: the > testsuite. Of course, it is very nice to write a single property test like > > >> > > >> memberInsertProperty x set = (member x (insert x set) == True) > > >> > > >> and then use it for testing all set data structures that implement > `member` and `insert`. Here you don't care about performance, only about > correctness! > > >> > > >> However, this approach leads to problems with type inference, > confusing error messages, and complexity. I found that it is much nicer to > use explicit dictionary passing and write something like this instead: > > >> > > >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == > True) > > >> > > >> where `member` and `insert` come from the SetAPI record via > RecordWildCards. > > >> > > >> Finally, I'm not even sure how to create a type class covering Set > and IntSet with the following two methods: > > >> > > >> singleton :: a -> Set a > > >> map :: Ord b => (a -> b) -> Set a -> Set b > > >> > > >> singleton :: Int -> IntSet > > >> map :: (Int -> Int) -> IntSet -> IntSet > > >> > > >> Could anyone please enlighten me about the right way to abstract over > this using type classes? > > >> > > >> I tried a few approaches, for example: > > >> > > >> class IsSet s where > > >> type Elem s > > >> singleton :: Elem s -> s > > >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > >> > > >> Looks nice, but I can't define the IntSet instance: > > >> > > >> instance IsSet IntSet where > > >> type Elem IntSet = Int > > >> singleton = IntSet.singleton > > >> map = IntSet.map > > >> > > >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, > how do I tell the compiler that in the IntSet case s ~ t in the map > signature? Shall I add more associated types, or "associated constraints" > using ConstraintKinds? I tried and failed, at various stages, repeatedly. > > >> > > >> ...And then you discover that there is Set.cartesianProduct :: Set a > -> Set b -> Set (a, b), but no equivalent in IntSet and things get even > more grim. > > >> > > >> Cheers, > > >> Andrey > > >> > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs at haskell.org > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >> > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs at haskell.org > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > > > > > -- > > > brandon s allbery kf8nh > > > allbery.b at gmail.com > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri May 31 12:03:44 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 31 May 2019 21:03:44 +0900 Subject: Cmm syntax page on wiki Message-ID: Hi devs, I wrote a wiki page for Cmm syntax [1] to improve readability for ghc developers. Could you tell me if there are any problems or errors? I'll update them or remove the page. [1]: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cmm-syntax Regards, Takenobu From simonpj at microsoft.com Fri May 31 14:18:40 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 31 May 2019 14:18:40 +0000 Subject: search on GItlab Message-ID: If I search in GitLab for "checkExpectedKind" I don't fine #16635, which clearly mentions that. Why not? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From giorgio at marinel.li Fri May 31 15:39:16 2019 From: giorgio at marinel.li (Giorgio Marinelli) Date: Fri, 31 May 2019 17:39:16 +0200 Subject: search on GItlab In-Reply-To: References: Message-ID: You have to look at the "Comments" results. But also there, it's not easy to find where all the occurrences of that string appear. Anyway, a link to your comment with that string it's there. Giorgio Giorgio On Fri, 31 May 2019 at 16:19, Simon Peyton Jones via ghc-devs wrote: > > If I search in GitLab for “checkExpectedKind” I don’t fine #16635, which clearly mentions that. > > Why not? > > Thanks > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Fri May 31 20:20:54 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 31 May 2019 20:20:54 +0000 Subject: Cmm syntax page on wiki In-Reply-To: References: Message-ID: Really good, thank you. Let's make sure it's discoverable. Perhaps from the commentary, in at least two places: The description of code generation: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen The runtime system https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts And your new page could itself link back to those locations. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Takenobu Tani | Sent: 31 May 2019 13:04 | To: ghc-devs | Subject: Cmm syntax page on wiki | | Hi devs, | | I wrote a wiki page for Cmm syntax [1] to improve readability for ghc | developers. | | Could you tell me if there are any problems or errors? | I'll update them or remove the page. | | [1]: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fcommentary%2Fcompiler%2Fcmm- | syntax&data=02%7C01%7Csimonpj%40microsoft.com%7Ce396859157a54a0567d908 | d6e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542023339 | &sdata=4DbAUYWd1bVM%2FDGuNctjBZgmYhCxazKnhGNN1CcLiJM%3D&reserved=0 | | Regards, | Takenobu | _______________________________________________ | ghc-devs mailing list | ghc-devs at 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%7Ce396859157a54a0567d908d6 | e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542033347&a | mp;sdata=F6SDwM2XoZ3s58gWmzJu0OiMJshsxNxjGAT8AYzjgRI%3D&reserved=0 From simonpj at microsoft.com Fri May 31 20:40:01 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 31 May 2019 20:40:01 +0000 Subject: search on GItlab In-Reply-To: References: Message-ID: Aiee. I went round this loop once before, and even recorded the answer: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj (See "search".) Sorry for the noise -- thank for help Simon | -----Original Message----- | From: Giorgio Marinelli | Sent: 31 May 2019 16:39 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: search on GItlab | | You have to look at the "Comments" results. | But also there, it's not easy to find where all the occurrences of that | string appear. | Anyway, a link to your comment with that string it's there. | | Giorgio | | | Giorgio | | | | On Fri, 31 May 2019 at 16:19, Simon Peyton Jones via ghc-devs wrote: | > | > If I search in GitLab for “checkExpectedKind” I don’t fine #16635, which | clearly mentions that. | > | > Why not? | > | > Thanks | > | > Simon | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at 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%7Cc3de7c738df94a85bc9d08d6e5de2b60%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C1%7C636949139715138971&sdata=iyQ% | > 2FJZxuRRscu%2F2mQTIEPtYAw8DnJKFrp3saH9mCaf0%3D&reserved=0