- ghc-devs - Haskell.org

RE: Coordinating the Hadrian merge
by Andrey Mokhov 16 Oct '18

16 Oct '18

Thanks Alp and Ben! I fully agree with you. Let's go ahead. Ben: I guess you'll do the actual merge -- feel free to do this whenever you like. > How should we handle ticket tracking post-merge? The easiest option > would probably be to keep the existing tickets on GitHub and ask that > new tickets be reported via Trac. Yes, this sounds good. Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 16 October 2018 02:33 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: RE: Coordinating the Hadrian merge Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Ben, > > Yes, I'm fine to merge, but we should make it clear that Hadrian > should not be used just yet: > > 1) It is currently broken due to some recent changes in GHC. > > 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left. > > 3) There are a few usability requests by Simon Marlow that we need to address. > >> In the past we discussed squashing the project's early history >> however I've had very little luck doing this cleanly > Sure, I'm happy to make it clear that things are still in flux and that there are known weaknesses. That being said, I'm not sure it helps to active discourage use. Afterall, there will be little incentive for others to help find and fix the remaining issues unless there are users. > Ouch, it would be a bit grim to merge all those early commits. On the > other hand, I looked at commits at the middle of Hadrian's history and > they look quite sensible, just overly fine-grained. So, even if we > could somehow squash the early history, that probably wouldn't give us > much saving in terms of the commit count -- it would still be more > than 1K. > Right; given that GHC itself has more than 50k commits I'm not terribly concerned about Hadrian's contribution. How should we handle ticket tracking post-merge? The easiest option would probably be to keep the existing tickets on GitHub and ask that new tickets be reported via Trac. Cheers, - Ben

1 0

RE: Coordinating the Hadrian merge
by Andrey Mokhov 16 Oct '18

16 Oct '18

Hi Ben, Yes, I'm fine to merge, but we should make it clear that Hadrian should not be used just yet: 1) It is currently broken due to some recent changes in GHC. 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left. 3) There are a few usability requests by Simon Marlow that we need to address. > In the past we discussed squashing the project's early history > however I've had very little luck doing this cleanly Ouch, it would be a bit grim to merge all those early commits. On the other hand, I looked at commits at the middle of Hadrian's history and they look quite sensible, just overly fine-grained. So, even if we could somehow squash the early history, that probably wouldn't give us much saving in terms of the commit count -- it would still be more than 1K. P.S.: Don't forget to switch off commit notifications when you do the merge ;-) Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 15 October 2018 23:14 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Coordinating the Hadrian merge Hi Andrey and Alp, Before ICFP we concluded that we will merge Hadrian into the GHC tree. This unfortunately took a back-seat priority-wise while I sorted out various release things but I think we are now in a position to make this happen. Andrey, would you be okay with my merging Hadrian as-is into the GHC tree? In the past we discussed squashing the project's early history however I've had very little luck doing this cleanly (primarily due to the difficulty of rebasing in the presence of merge commits) After merging there will be a period where we flush the pull request queue but I don't anticipate this causing much trouble. Cheers, - Ben

3 2

Coordinating the Hadrian merge
by Ben Gamari 15 Oct '18

15 Oct '18

Hi Andrey and Alp, Before ICFP we concluded that we will merge Hadrian into the GHC tree. This unfortunately took a back-seat priority-wise while I sorted out various release things but I think we are now in a position to make this happen. Andrey, would you be okay with my merging Hadrian as-is into the GHC tree? In the past we discussed squashing the project's early history however I've had very little luck doing this cleanly (primarily due to the difficulty of rebasing in the presence of merge commits) After merging there will be a period where we flush the pull request queue but I don't anticipate this causing much trouble. Cheers, - Ben

1 0

Feedback request: GHC performance test-suite
by David Eichmann 10 Oct '18

10 Oct '18

Hello all, I've recently resumed some work started by Jared Weakly on the GHC test suite. This specifically regards performance tests. The work aims to, among some other things, reduce manual work and to log performance test results from our CI server. The proposed change is described in more detail on this wiki page: https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests. I'd appreciate any feedback or questions on this. Thank you and have a great day, 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

3 4

Phabricator workflow vs. GitHub
by Simon Marlow 07 Oct '18

07 Oct '18

Here's an interesting blog post relevant to previous discussions about Phabricator / GitHub: https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3Jy… Yes it's a decidedly pro-Phabricator rant, but it does go into a lot of details about why the Phabricator workflow is productive, and might be useful to those who struggle to get to grips with it coming from GitHub. Cheers Simon

4 6

Please update ghc user's guide for GHC 8.6
by Takenobu Tani 06 Oct '18

06 Oct '18

Dear devs, Would you please update latest document [1] to GHC 8.6 ? [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide Regards, Takenobu

2 2

Does it sound a good idea to implement "backend plugins"?
by Shao, Cheng 05 Oct '18

05 Oct '18

Hi all, I'm thinking of adding "backend plugins" in the current Plugins mechanism which allows one to inspect/modify the IRs post simplifier pass (STG/Cmm), similar to the recently added source plugins for HsSyn IRs. This can be useful for anyone creating a custom GHC backend to target an experimental platform (e.g. the Asterius compiler which targets WebAssembly), and previously in order to retrieve those IRs from the regular pipeline, we need to use Hooks which is somewhat hacky. Does this sound a good idea to you? If so, I can open a trac ticket and a Phab diff for this feature. Best, Shao Cheng

5 6

nofib oldest GHC to support?
by Ömer Sinan Ağacan 04 Oct '18

04 Oct '18

Do we have a policy on the oldest GHC to support in nofib? I'm currently doing some hacking on nofib to parse some new info printed by a modified GHC, and I think we can do a lot of cleaning (at the very least remove some regexes and parsers) if we decide on which GHCs to support. I checked the README and RunningNoFib wiki page but couldn't see anything relevant. Thanks Ömer

3 3

typed holes inferring very polymorphic types
by Sreenidhi Nair 01 Oct '18

01 Oct '18

Hello, We tried the following code with ghc-8.6.1 testFailure :: Char testFailure = let x = Prelude.id _ in x which gave the following suggestion /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:22: error: • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the inferred type of x :: a at /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:7-22 And then this testSuccess :: Char testSuccess = _ which gave a much better suggestion /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:87:15: error: • Found hole: _ :: Char • In the expression: _ In an equation for ‘testSuccess’: testSuccess = _ Is there any way to get better suggestions with 'let' version?

2 1

Re: Stable name allocation
by David Feuer 27 Sep '18

27 Sep '18

Simon seems a bit busy right now. Can anyone else advise me on the basics of heap allocation in primops? On Tue, Sep 25, 2018 at 1:42 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Let's forget about allocate(). I can definitely handle this part in > C--. But I'm still lost in the macros and such. For example, I'm very > unclear on the differences among the ALLOC, HP_CHK, and MAYBE_GC > classes of macro. I can't find anything in the commentary, and the > source code documentation is very sparse. I'm okay with either of the > following approaches, but either way I need a bit more info. > > 1. First see if we need to allocate a StableName#. If so, check > whether GC would be required to allocate the StableName# (how?). If > so, drop the lock, run GC (how?) and start over. This looks cleanest > to me if it can be done easily. > > 2. First run the GC if we're low on memory (how?). Then if we need to > allocate a StableName#, we'll be sure to have room. > > > On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> You can do it unconditionally before taking the lock, or you can do it >> conditionally as long as you release the lock if the heap check fails. I >> think in the latter case there might not be a macro that allows this, but >> you could use the `allocate()` method for allocating memory (like >> newByteArray#) and then you could write a heap check like the MAYBE_GC() >> macro. Doing it unconditionally is easier and probably not a big performance >> hit, but note that you'll have to retreat Hp if you don't use the memory. >> >> Cheers >> Simon >> >> On Sat, 22 Sep 2018 at 13:08, David Feuer <david.feuer(a)gmail.com> wrote: >>> >>> How do I check if GC will be required, and how do I trigger it? Should I >>> perform the check unconditionally at the beginning of the operation so I >>> don't have to drop the lock, GC, then retake? I don't know the right ways to >>> deal with this stuff, and the macros are mostly undocumented. >>> >>> On Sep 22, 2018 3:53 AM, "Simon Marlow" <marlowsd(a)gmail.com> wrote: >>> >>> Yes, the current implementation looks like it creates the object after >>> adding the entry to the StableName table and releasing the lock, which is >>> unsafe because another thread could read that same entry before the object >>> has been created. The easiest solution to that is to take and release the >>> lock in C-- in the right places instead of in the C lookupStableName() >>> function (you might need to make a separate version of lookupStableName() >>> that doesn't take the lock). >>> >>> Cheers >>> Simon >>> >>> >>> On Fri, 21 Sep 2018 at 12:53, David Feuer <david.feuer(a)gmail.com> wrote: >>>> >>>> It seems awkward to do it in C--, but maybe you can help me work out how. >>>> The allocation facilities definitely seem much nicer there, and allocating a >>>> small heap object in C feels like an abuse of the facilities we have there. >>>> The essential challenge, as I see it, is that we need the key to point to a >>>> valid stable name object by the time we drop the hash table lock. The >>>> process, as I imagine it: >>>> >>>> 1. Follow indirections, untag, choose the right generation. (All this is >>>> in C) >>>> 2. Take the appropriate hash table lock. (C) >>>> 3. Look up the key in the hash table (C). >>>> >>>> Now there's a branch. If we found the key, then we don't need to allocate >>>> an SNO. We just drop the lock and return. Otherwise >>>> >>>> 4. Allocate an SNO and set its info pointer (most easily done in C--). If >>>> this necessitates GC, we need to drop the lock first and might as well just >>>> go back to the very beginning afterwards. >>>> 5. Populate the SNO with its "hash value" (we can do this anywhere we >>>> like, I imagine). >>>> 6. Insert the key and SNO into the hash table and drop the hash table >>>> lock (C) >>>> 7. If necessary, insert the SNO into the remembered set (C) >>>> >>>> How would you recommend structuring this back-and-forth? >>>> >>>> On Fri, Sep 21, 2018, 3:19 AM Simon Marlow <marlowsd(a)gmail.com> wrote: >>>>> >>>>> I'm a bit sceptical that you need to allocate a heap object in C instead >>>>> of C--, but still, here's an example: >>>>> https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c… >>>>> >>>>> It's slightly less efficient to do this in C than C--, because >>>>> `allocate()` is slower than allocating by bumping `Hp`. >>>>> >>>>> On Mon, 17 Sep 2018 at 21:25, David Feuer <david.feuer(a)gmail.com> wrote: >>>>>> >>>>>> How can I allocate a heap object in C code in the rts? I've only seen >>>>>> heap objects allocated in C--, and doing that here would be lousy for >>>>>> performance and worse for clarity. >>>>>> >>>>>> David >>> >>> >>

2 1