From rae at cs.brynmawr.edu Fri Mar 1 15:41:20 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 1 Mar 2019 10:41:20 -0500 Subject: gitlab migration Message-ID: <2022382E-D021-40C3-B7D4-EDE066662769@cs.brynmawr.edu> Hi all, As I'm wrapping up some ICFP papers, I realize that I sometimes link to Trac tickets in published papers. It would be a shame for all these links to suddenly go dead, and I'm sure that my papers aren't the only places external sites link to Trac. Is it expected that, after the full migration, the Trac URLs will redirect? Thanks, Richard From julian at leviston.net Sat Mar 2 00:36:06 2019 From: julian at leviston.net (Julian Leviston) Date: Sat, 2 Mar 2019 11:36:06 +1100 Subject: Newcomers' Guide to GHC Development In-Reply-To: <20190227100657.b3qodmep4ymvrade@nibbler> References: <20190227100657.b3qodmep4ymvrade@nibbler> Message-ID: Hi, Pretty glad someone’s updating the guide! The updated version could be improved by shaping it into clearer sections because we’d like newcomers to feel like it’s light and easy. Layers is a great way to achieve this. The first time I ran through the task list (not very long ago), it felt light and easy. This was because it was chunked well. So, my suggestion would be to have a third sentence/paragraph in the introduction section that explains what the overall steps are that we’re going to explain next. Provide links down into those sections, and make it really clear that those sections are sections, if possible. “Contributing to GHC is a simple process conceptually: it consists of [setting up your build tooling], [finding an issue/feature] for you to work on, [working on the code], then getting it [approved and merged].” At each section, you could reiterate how to do that driving from the overarching aim of the explanation for the section. (Having an introduction to each section would help here, too). For example, having a canonical way to determine what a good issue or feature to start on would be awesome, as would having somewhat of a mentor/buddy to help new users when working on their bugs (ie one or two people assigned to a newcomers’ first two or so tickets to help them through any issues until they feel confident). Not sure if our contributors allow for such things yet, tho. Nice effort so far! Julian > On 27 Feb 2019, at 9:06 pm, Tobias Dammers wrote: > > Dear all, > > With the migration of our affairs from Trac to GitLab nearing > completion, I would like to ask for a final round of feedback on the new > Newcomers' Guide to GHC development. > > The draft can be found here: > > https://github.com/tdammers/ghc-wiki/blob/wip/newcomers/newcomers-tutorial.md > > TL;DR: If you have any kind of input / critique / praise regarding this > document, feel free to reply, or, even better, issue a PR on github. > > > Some background: > > The purpose of this document is to provide potential contributors with a > practical, no-nonsense tutorial, guiding them from "I know nothing about > GHC development" to their first successful merge request. > > The document has been compiled using existing wiki content, revised and > edited to match the current state of affairs (particularly using Hadrian > as the recommended build system), and to tune it to the target audience > of first-time contributors. As such, we avoid going off on tangents > (e.g., we do not explain how to use the make-based alternative build > system), and we only explain what you need to understand in order to get > going (e.g., we do not provide a complete run-down of all hadrian > options). > > A few nonlinearities were deemed necessary in order to make the tutorial > suitable across target platforms; Windows in particular requires some > special attention. Other than that, however, we try to provide as linear > an experience as we reasonably can. > > > So with that said; all feedback and suggestions on this are welcome. We > have gotten some great responses already, but I'd like to gather one > more round of feedback before merging it into the freshly-migrated > Haskell Wiki on GitLab. > > Thank you for your attention! > > -- > Tobias Dammers - tdammers at gmail.com > _______________________________________________ > 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 ben at smart-cactus.org Sat Mar 2 02:19:34 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 01 Mar 2019 21:19:34 -0500 Subject: gitlab migration In-Reply-To: <2022382E-D021-40C3-B7D4-EDE066662769@cs.brynmawr.edu> References: <2022382E-D021-40C3-B7D4-EDE066662769@cs.brynmawr.edu> Message-ID: <8736o6t3v4.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi all, > > As I'm wrapping up some ICFP papers, I realize that I sometimes link > to Trac tickets in published papers. It would be a shame for all these > links to suddenly go dead, and I'm sure that my papers aren't the only > places external sites link to Trac. Is it expected that, after the > full migration, the Trac URLs will redirect? > Yes, canonical Trac ticket and Wiki URLs will redirect. In fact, this is what I am working on as we speak. 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 tdammers at gmail.com Mon Mar 4 15:31:45 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Mon, 4 Mar 2019 16:31:45 +0100 Subject: Newcomers' Guide to GHC Development In-Reply-To: References: <20190227100657.b3qodmep4ymvrade@nibbler> Message-ID: <20190304153145.mz6hr34juqwtuoh7@nibbler> On Thu, Feb 28, 2019 at 12:43:12PM +0100, Spiwack, Arnaud wrote: > - The dependencies instruction are too complex and long-winded. I'd start > by: if you are a nix user, use , otherwise you need > installed [in particular, no sectioning of the dependencies!], > see to find instruction for your particular system. One consideration with this guide is that we want to reduce the amount of indirection - the current "getting started" guide is very close to being just a chaotic collection of links, and if you follow them all to exhaustion, you will get lost and confused long before you manage to make your first successful build (I know I did). So we decided to keep the main narrative entirely in this document, providing links to other pages and resources only for optional steps or unusual situations. The nix-based setup is certainly a good idea though, and I do agree that shortening this section further would be a good thing, so I will definitely look into it again. Please keep in mind however that we cannot possibly cater to all potential needs; we need to strike a balance. > - The considerations about gitlab are mostly trivial and distract from the > point (at this point we're trying to build GHC): simply give a git clone > instruction from the main repository. This was originally in the document; however, the goal here is not just to build GHC (there are separate instructions for that), but to actually issue a MR, and for that, you are supposed to create a fork. So we instruct people to do that right away, and then clone the fork, rather than clone the main repo and then modify their working copy to point to the fork later. > (also highlight the fact that there > is a `--recursive`, it's easily missed, and give the `git submodule update > --init` back up in case it was forgotten, maybe?) Makes sense, I will add that. > - Scrap the section called A note on Hadrian. It will just come up as > scary. The further reading section is sufficient to point to Hadrian issues The purpose of this is not to scare people off, but to avoid confusion when running into unexpected issues. Hadrian *is* a complex beast, and quite new, and experience shows that people still encounter issues. The intended message here is "if it doesn't work, it may not be your fault". I will reword. > - devel2 is a good default flavour, but, when it comes up, you should also > include a link to a documentation that says: want to do X -> use flavour Y In the interest of keeping things short, I'm inclined to say let's not do that, and rely on the links we're already providing. (Those do not work properly from within the github rendering of this page, but will be fine if viewed from within gitlab; you should also be able to figure out what the corresponding wiki pages on the old Trac wiki are). > - The idiom/stages seems to be a dead link, but maybe it'll work when this > document is transferred to the wiki? Yes, it should. I have pushed this page to a development gitlab instance, and the link seems to work fine there. See above. > - `git clean` is not sufficient to get to a pristine state, you need `git > clean -xdf && git submodule foreach 'git clean -xdf'`. It's probably even > better to just give the following one-liner: `git clean -xdf && git > submodule foreach 'git clean -xdf' && git submodule update --init`. Maybe > even even better, build.hs could have an option to call this one-liner? Not a fan of tying SCM concerns into the build system. Rest seems reasonable, although choice of git clean details may be up to the individual (e.g. -f vs. -i). Anyhow, thanks a lot for your feedback. From simonpj at microsoft.com Mon Mar 4 21:00:30 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 4 Mar 2019 21:00:30 +0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> Message-ID: Matthew, Ben I've just received 40-odd messages like this one. It looks as if Marge is now sending commit messages at Trac ticket messages, which is great. Will that happen after the move to GitLab. Also, is this sudden wave because a whole lot of commits have now landed in master? Or is it somehow an old backlog stuck in a mail queue? There may be some housekeeping to do, to close tickets, check regression tests and add pointers to the appropriate tests. Is anyone up for doing that? Thanks Simon | -----Original Message----- | From: ghc-tickets On Behalf Of GHC | Sent: 04 March 2019 18:51 | Subject: Re: [GHC] #16348: GHC HEAD regression: tyConAppArgs | | #16348: GHC HEAD regression: tyConAppArgs | -------------------------------------+------------------------------------- | Reporter: RyanGlScott | Owner: (none) | Type: bug | Status: closed | Priority: highest | Milestone: 8.10.1 | Component: Compiler | Version: 8.7 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Compile-time | Test Case: | crash or panic | simplCore/should_compile/T16348 | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha | skell.org%2Fghc%2Fghc%2Fmerge_requests%2F416&data=02%7C01%7Csimonpj%40m | icrosoft.com%7C50e6bec9985e4121351808d6a0d2a90f%7C72f988bf86f141af91ab2d7cd | 011db47%7C1%7C0%7C636873224010230414&sdata=SvX8wLsObYmasJTvB6yT9CQbxoFK | ZkdGpv7ZHfDRqYs%3D&reserved=0 | -------------------------------------+------------------------------------- | | Comment (by Matthew Pickering ): | | In [changeset:"c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1/ghc" | c25b135f/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1" | Fix exprIsConApp_maybe | | In this commit | commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 | Date: Thu Jan 24 17:58:50 2019 +0100 | Look through newtype wrappers (Trac #16254) | | we made exprIsConApp_maybe quite a bit cleverer. But I had not paid | enough attention to keeping exactly the correct substitution and | in-scope set, which led to Trac #16348. | | There were several buglets (like applying the substitution twice in | exprIsConApp_maybe, but the proximate source of the bug was that we were | calling addNewInScopeIds, which deleted things from the substitution as | well as adding them to the in-scope set. That's usually right, but not | here! | | This was quite tricky to track down. But it is nicer now. | }}} | | -- | Ticket URL: | | GHC | | The Glasgow Haskell Compiler From tdammers at gmail.com Tue Mar 5 11:54:34 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Tue, 5 Mar 2019 12:54:34 +0100 Subject: Newcomers' Guide to GHC Development In-Reply-To: References: <20190227100657.b3qodmep4ymvrade@nibbler> Message-ID: <20190305115433.ftpp42evwatmgien@nibbler> Hi, thanks for your feedback. I'll get into some detail below. On Sat, Mar 02, 2019 at 11:36:06AM +1100, Julian Leviston wrote: > The updated version could be improved by shaping it into clearer > sections because we’d like newcomers to feel like it’s light and easy. > Layers is a great way to achieve this. > > The first time I ran through the task list (not very long ago), it > felt light and easy. This was because it was chunked well. > > So, my suggestion would be to have a third sentence/paragraph in the > introduction section that explains what the overall steps are that > we’re going to explain next. Provide links down into those sections, > and make it really clear that those sections are sections, if > possible. I like the idea of a short outline of the overall progression in the introduction, so just added that. I won't add those links yet, because due to the way this works in Gitlab, it's best to do it after the document has solidified, because adding or removing headers (of any level) will change the headers' generated ID properties, potentially breaking any links. As far as the chunking goes, I believe we already have a fairly decent structure in place. The GitHub layout may not make it very obvious though, and I think it'll be clearer on Gitlab. I did rearrange things a tiny bit in order to fit in better with the overall arch though. If you have concrete suggestions on how to improve the structure further, please feel free to tell, or better yet, issue a PR on GitHub. > At each section, you could reiterate how to do that driving from the > overarching aim of the explanation for the section. (Having an > introduction to each section would help here, too). This seems like overkill to me. We need to strike a balance between completeness and brevity, and we're bordering on "too long" already. I did try to come up with suitable introductions, but they all ended being paraphrasings of the title or the entire section, so I decided against them. Note that my goal here is to remove obstacles and friction, not to persuade people into contributing - by the time you read this guide, you should have been persuaded already. Quoting the very first sentence in the guide: | This page is intended to serve as the first stop for those people who | say, "I want to contribute to GHC, but I don't know quite where to | begin." > For example, having a canonical way to determine what a good issue or > feature to start on would be awesome, as would having somewhat of a > mentor/buddy to help new users when working on their bugs (ie one or > two people assigned to a newcomers’ first two or so tickets to help > them through any issues until they feel confident). Not sure if our > contributors allow for such things yet, tho. I agree that that would be awesome; however, we have limited resources at our disposal that we need to juggle between several concerns, and mentoring newcomers is only one of them. What we can offer right now is: - Issues labeled "newcomers" (the guide already mentions these) - Ad-hoc, no-strings-attached support from core GHC contributors and various volunteers via this mailing list and IRC (the guide mentions these, too) - Some time from core contributors, as available, allocated to handling incoming issues and merge requests. We strive to provide feedback on every one of them, but we cannot make any hard promises as to the timeframe, and we have to prioritize. On top of that, many individuals and third-party organisations run various forms of mentoring, tutoring, guidance, hackathon events, counseling, etc. Listing those would go way beyond the scope of this document, but you should have little trouble getting suggestions via our various communication channels. Hope that clarifies things, and again, thanks a lot for your input. From ben at well-typed.com Tue Mar 5 17:01:34 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 12:01:34 -0500 Subject: __mingw_vsnw_printf definition Message-ID: <87pnr5s1at.fsf@smart-cactus.org> Hi Tamar, Recently I've been working on (finally) stabilizing our remaining CI configurations (namely i386/Linux and Windows). I've opened a number of tickets (see the list in !487 [1]) but one of these in particular I'd like your input on. Specifically #16387: The problem is the apparent multiple-definition of __mingw_vsnwprintf: once in mingwex.a and again in RtsSymbols. Unfortunately I have been unable to reproduce this error locally, so debugging has been a bit tricky. The RtsSymbols entry was introduced in 4de585a5c1ac3edc2914cebcac1753b514051a89 (which lifted the MAX_PATH restriction in the RTS) but there was no explanation for why. Do you happen to recall why you added it? Note [Symbols for MinGW's printf] seems relevant, but seems to only discuss the entries for _lock_file and _unlock_file. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/487 -------------- 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 Mar 5 18:10:06 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 13:10:06 -0500 Subject: Testing GHC against Hackage via CI Message-ID: <87o96pry4m.fsf@smart-cactus.org> Hello everyone, As many of you know, recently I have been working on bringing up infrastructure for using CI-produced binary distributions to build a subset of Hackage using the head.hackage patchset. Happily, this effort has now converged on a usable result, embodied in two merge requests: * https://gitlab.haskell.org/ghc/head.hackage/merge_requests/2 * https://gitlab.haskell.org/ghc/ghc/merge_requests/465 ghc/head.hackage!2 adds CI support to head.hackage. In addition to the usual pass/fail status, this job produces (e.g. [1]) a few additional products: * a JSON summary of the run, describing the dependency graph and pass/fail state of each package. we can feed to an external service to track newly-failing packages. * a (rendered) graphviz graph showing the dependency structure of the built packages, each node colored by its pass/fail state * a tarball of build logs, each including statistics from -ddump-timings. The hope here is that we can use this to track compiler performance on real-world code ghc/ghc!465 adds a job to GHC's own CI pipeline to trigger a head.hackage job using the binary distribution produced earlier in the pipeline. This job will run automatically under a variety of circumstances: * via the scheduled nightly pipeline * on merge requests labelled with the `user-facing` label * when manually started using a button on the MR's Pipelines tab Currently the head.hackage MR tests only a small number of Hackage packages (and their dependencies). Specifically, we currently build `aeson`, `criterion`, `singletons`, `servant`, and `scotty`. This pulls in 127 packages in total. There are a few things that remain to be done: * Better document the existence of the job and how it is triggered * Document how to update the list of tested packages * Work out how to handle tracking of persistent breakage (e.g. we want a notification when a package initially breaks but not in later builds) * Automatically push patched packages to a Hackage repository (e.g. head.hackage.org) as a result of CI. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/head.hackage/-/jobs/38022 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Tue Mar 5 18:30:34 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 5 Mar 2019 13:30:34 -0500 Subject: Testing GHC against Hackage via CI Message-ID: This is fantastic work! I'm looking forward to using this. Are there plans to merge GitLab's fork of head.hackage back into the upstream repo [1]? I ask since I regularly submit patches to upstream, but if the GitLab CI is using the fork, then it may take some time for upstream changes to make their way back to the fork. Ryan S. ----- [1] https://github.com/hvr/head.hackage -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Mar 5 19:22:01 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 14:22:01 -0500 Subject: Testing GHC against Hackage via CI In-Reply-To: References: Message-ID: <87lg1truss.fsf@smart-cactus.org> Ryan Scott writes: > This is fantastic work! I'm looking forward to using this. > > Are there plans to merge GitLab's fork of head.hackage back into the > upstream repo [1]? I ask since I regularly submit patches to upstream, but > if the GitLab CI is using the fork, then it may take some time for upstream > changes to make their way back to the fork. > Yes, if it's okay with Herbert I think this branch should be merged upstream. We might also consider going even further: making gitlab.haskell.org/ghc/head.hackage the upstream repository. If we don't do this I would likely need to maintain a "stable" branch alongside `master` to ensure that the head.hackage build doesn't break due to bad patches landing in `master`. Moving the upstream to GitLab would avoid this since all patches landed would go through CI. 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 Mar 5 20:53:19 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 15:53:19 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available Message-ID: <87h8chrqkl.fsf@smart-cactus.org> Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.4, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.4 The 8.6.4 release fixes several regressions present in 8.6.3 including: - A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible to #16071. #16071 will be fixed in GHC 8.8.1. - A bug resulting in incorrect locking on Darwin, potentially resulting in hangs at shutdown (#16150) - A few bugs in the profiled runtime resulting in the potential for memory unsafety has been fixed (#15508). - The `process` and `transformers` libraries shipped now properly reflect released Hackage releases (#16199) - A bug where TH name resolution would break in a plugin context has been fixed (#16104) - Compilers that do not support TemplateHaskell no longer advertise such support in `--supported-languages` (#16331) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Note also that this is the first release cut from our (yet again) revamped continuous integration infrastructure. While we have done a great deal of checking to ensure that the build configuration reflects that of previous releases, do let us know if something looks off. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rae at cs.brynmawr.edu Tue Mar 5 21:08:55 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 5 Mar 2019 16:08:55 -0500 Subject: Testing GHC against Hackage via CI In-Reply-To: <87o96pry4m.fsf@smart-cactus.org> References: <87o96pry4m.fsf@smart-cactus.org> Message-ID: <91820B71-7C4E-4857-A255-28CF1A22C0AC@cs.brynmawr.edu> How will this affect workflow of developers submitting patches? For example, suppose I write a user-facing change that breaks some of these packages. Am I expected to patch up the breakage? How? Will the CI infrastructure detect this before merging or after? To be clear, I don't have specific answers I'm looking for here. In particular, I think it's reasonable to ask that the developer of a user-facing feature make sure that head.hackage works with the feature. This has the distinct advantage of making sure the developer knows that their patch breaks code and how it must be fixed. Indeed, this can all be fodder to force the developer to update the GHC migration guide alongside their work in fixing head.hackage. I just want to know what the steps are. :) Thanks, Richard PS: And thanks, generally, to all of you doing the heavy lifting to get this infrastructure in place. This is all quite wonderful, even if there have been some bumps in the road en route! > On Mar 5, 2019, at 1:10 PM, Ben Gamari wrote: > > Hello everyone, > > As many of you know, recently I have been working on bringing up > infrastructure for using CI-produced binary distributions to build a > subset of Hackage using the head.hackage patchset. > > Happily, this effort has now converged on a usable result, embodied in > two merge requests: > > * https://gitlab.haskell.org/ghc/head.hackage/merge_requests/2 > * https://gitlab.haskell.org/ghc/ghc/merge_requests/465 > > ghc/head.hackage!2 adds CI support to head.hackage. In addition to the > usual pass/fail status, this job produces (e.g. [1]) a few additional > products: > > * a JSON summary of the run, describing the dependency graph and > pass/fail state of each package. we can feed to an external service to > track newly-failing packages. > > * a (rendered) graphviz graph showing the dependency structure of the > built packages, each node colored by its pass/fail state > > * a tarball of build logs, each including statistics from > -ddump-timings. The hope here is that we can use this to track > compiler performance on real-world code > > ghc/ghc!465 adds a job to GHC's own CI pipeline to trigger a > head.hackage job using the binary distribution produced earlier in the > pipeline. This job will run automatically under a variety of > circumstances: > > * via the scheduled nightly pipeline > > * on merge requests labelled with the `user-facing` label > > * when manually started using a button on the MR's Pipelines tab > > Currently the head.hackage MR tests only a small number of Hackage > packages (and their dependencies). Specifically, we currently build > `aeson`, `criterion`, `singletons`, `servant`, and `scotty`. This pulls > in 127 packages in total. > > There are a few things that remain to be done: > > * Better document the existence of the job and how it is triggered > > * Document how to update the list of tested packages > > * Work out how to handle tracking of persistent breakage (e.g. we want > a notification when a package initially breaks but not in later > builds) > > * Automatically push patched packages to a Hackage repository (e.g. > head.hackage.org) as a result of CI. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/head.hackage/-/jobs/38022 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From lonetiger at gmail.com Tue Mar 5 21:10:44 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 5 Mar 2019 21:10:44 +0000 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <87h8chrqkl.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: Hi Ben, Thanks for the release! I was wondering, any reason for the no i386 Windows? Should I just create the package without it or is it coming? Thanks, Tamar On Tue, Mar 5, 2019 at 8:53 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.4, a > bugfix release in the GHC 8.6 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.4 > > The 8.6.4 release fixes several regressions present in 8.6.3 including: > > - A regression resulting in segmentation faults on Windows introduced > by the fix for #16071 backported in 8.6.3. This fix has been reverted, > meaning that 8.6.4 is once again susceptible to #16071. #16071 will > be fixed in GHC 8.8.1. > > - A bug resulting in incorrect locking on Darwin, potentially resulting > in hangs at shutdown (#16150) > > - A few bugs in the profiled runtime resulting in the potential for > memory unsafety has been fixed (#15508). > > - The `process` and `transformers` libraries shipped now properly > reflect released Hackage releases (#16199) > > - A bug where TH name resolution would break in a plugin context has > been fixed (#16104) > > - Compilers that do not support TemplateHaskell no longer advertise > such support in `--supported-languages` (#16331) > > As a few of these issues are rather serious users are strongly > encouraged to upgrade. See Trac [1] for a full list of issues resolved > in this release. > > Note that this release ships with one significant but long-standing bug > (#14251): Calls to functions taking both Float# and Double# may result > in incorrect code generation when compiled using the LLVM code generator. > This is not a new issue, it has existed as long as the LLVM code > generator has existed; however, changes in code generation in 8.6 made > it more likely that user code using only lifted types will trigger it. > > Note also that this is the first release cut from our (yet again) > revamped continuous integration infrastructure. While we have done a > great deal of checking to ensure that the build configuration reflects > that of previous releases, do let us know if something looks off. > > Happy compiling! > > Cheers, > > - Ben > > [1] > https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority > _______________________________________________ > 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 ben at well-typed.com Tue Mar 5 21:47:01 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 16:47:01 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: <877eddro34.fsf@smart-cactus.org> Phyx writes: > Hi Ben, > > Thanks for the release! I was wondering, any reason for the no i386 Windows? > Should I just create the package without it or is it coming? > This is one configuration I haven't yet had a chance to CI-ify. I was hoping it would be missed but since you mention it I've gone ahead and put up an attempt at fixing this (!495 [1]). It will likely take a few iterations to get right but I'll try to get it sorted by the end of the week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/495 -------------- 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 Mar 5 21:58:03 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 16:58:03 -0500 Subject: Testing GHC against Hackage via CI In-Reply-To: <91820B71-7C4E-4857-A255-28CF1A22C0AC@cs.brynmawr.edu> References: <87o96pry4m.fsf@smart-cactus.org> <91820B71-7C4E-4857-A255-28CF1A22C0AC@cs.brynmawr.edu> Message-ID: <874l8hrnkp.fsf@smart-cactus.org> Richard Eisenberg writes: > How will this affect workflow of developers submitting patches? For > example, suppose I write a user-facing change that breaks some of > these packages. Am I expected to patch up the breakage? How? Will the > CI infrastructure detect this before merging or after? > > To be clear, I don't have specific answers I'm looking for here. In > particular, I think it's reasonable to ask that the developer of a > user-facing feature make sure that head.hackage works with the > feature. This has the distinct advantage of making sure the developer > knows that their patch breaks code and how it must be fixed. Indeed, > this can all be fodder to force the developer to update the GHC > migration guide alongside their work in fixing head.hackage. I just > want to know what the steps are. :) > All very good questions. Frankly, many of them are still open. I should have made this clearer: The short answer is that in the short term very little is changing. head.hackage is, at the moment, merely another tool that we can use to evaluate contributions and identify regressions in the compiler; it's not (yet) a requirement that MRs pass the job. The reason is that I don't think we are yet in a position to start requiring contributors to update head.hackage. For one, the workflow for doing so is arguably not well enough documented (something that I will be working to fix). Moreover, it's quite unclear to me exactly how much work maintaining this infrastructure is going to require. I'd like to better understand this before requiring that contributors put in the work. 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 lonetiger at gmail.com Tue Mar 5 21:57:59 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 5 Mar 2019 21:57:59 +0000 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <877eddro34.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> <877eddro34.fsf@smart-cactus.org> Message-ID: Thanks! To be fair I'm not really sure how popular it is. I was wondering since once I upload the chocolatey packages it's immutable. If there's anything I can help with let me know. Cheers, Tamar On Tue, Mar 5, 2019, 21:47 Ben Gamari wrote: > Phyx writes: > > > Hi Ben, > > > > Thanks for the release! I was wondering, any reason for the no i386 > Windows? > > Should I just create the package without it or is it coming? > > > This is one configuration I haven't yet had a chance to CI-ify. I was > hoping it would be missed but since you mention it I've gone ahead and > put up an attempt at fixing this (!495 [1]). It will likely take a few > iterations to get right but I'll try to get it sorted by the end of the > week. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/495 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Mar 6 01:21:09 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 20:21:09 -0500 Subject: Final steps in GHC's Trac-to-GitLab migration Message-ID: <8736o0ssqo.fsf@smart-cactus.org> Hi everyone, Over the past few weeks we have been hard at work sorting out the last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I believe we have sorted out the issues which are necessary to perform the final migration: * We are missing only two tickets (#1436 and #2074 which will require a bit of manual intervention to import due to extremely large description lengths) * A variety of markup issues have been resolved * More metadata is now preserved via labels. We may choose to reorganize or eliminate some of these labels in time but it's easier to remove metadata after import than it is to reintroduce it. The logic which maps Trac metadata to GitLab labels can be found here [2] * We now generate a Wiki table of contents [3] which is significantly more readable than GitLab's default page list. This will be updated by a cron job until underlying GitLab pages list becomes more readable. * We now generate redirects for Trac ticket and Wiki links (although this isn't visible in the staging instance) * Milestones are now properly closed when closed in Trac * Mapping between Trac and GitLab usernames is now a bit more robust As in previous test imports, we would appreciate it if you could have a look over the import and let us know of any problems your encounter. If no serious issues are identified with the staging site we plan to proceed with the migration this coming weekend. The current migration plan is to perform the final import on gitlab.haskell.org on Saturday, 9 March 2019. This will involve both gitlab.haskell.org and ghc.haskell.org being down for likely the entirety of the day Saturday and likely some of Sunday (EST time zone). Read-only access will be available to gitlab.staging.haskell.org for ticket lookup while the import is underway. After the import we will wait at least a week or so before we begin the process of decommissioning Trac, which will be kept in read-only mode for the duration. Do let me know if the 9 March timing is problematic. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ghc/ghc [2] https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index -------------- 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 Wed Mar 6 03:57:39 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Mar 2019 22:57:39 -0500 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> Message-ID: <87va0wr6xd.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Matthew, Ben > > I've just received 40-odd messages like this one. It looks as if Marge > is now sending commit messages at Trac ticket messages, which is > great. Will that happen after the move to GitLab. > > Also, is this sudden wave because a whole lot of commits have now > landed in master? Or is it somehow an old backlog stuck in a mail > queue? > This happened because the GitLab -> git.haskell.org mirroring process was stuck. Yesterday I un-stuck it which then triggered the push of approximately 40 commits, triggering the old Trac commit notifier which produced the messages you received. Regarding commit notifications after we migrate: * Tickets will have notes added when they are mentioned by a commit message. As we discussed earlier, messages won't include the commit message text but rather only a reference to the referring commit SHA. For instance, this looks like [1]. If we find the indirection between the ticket and the mentioning commit message to be problematic we can certainly revisit this. * Commit notifications will be sent to ghc-commits at haskell.org; the format will change a bit but the overall content won't change. * Unfortunately a mention of a ticket from a commit does not produce a notification email. This is in my opinion a rather serious issue that we will need to work around since it makes closing tickets after merge far more painful than necessary. > There may be some housekeeping to do, to close tickets, check > regression tests and add pointers to the appropriate tests. Is anyone > up for doing that? > Yes, I have been accumulating a sizeable queue of tickets to sort through. I've started working through this but certainly won't finish tonight. I have a few other obligations tomorrow but I'll try to pick it up again later in the day. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ghc/ghc/issues/16260#note_173847 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From omeragacan at gmail.com Wed Mar 6 06:32:44 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 6 Mar 2019 09:32:44 +0300 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <8736o0ssqo.fsf@smart-cactus.org> References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: This look great, thanks to everyone involved! Some feedback: - When I click to the "Wiki" link on the left it opens "Home" page and I don't know how to go to the index from there. I think we may want index to be the home page for the wiki? - Redirects don't seem to work: https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects - Comparing these two pages: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects?redirectedfrom=Commentary/Rts/HeapObjects https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/storage/heap-objects The Gitlab page doesn't have images that Trac page has. Secondly, the "_|_" string used in the Trac page is migrated as italic "|" in Gitlab. Ömer Ben Gamari , 6 Mar 2019 Çar, 04:21 tarihinde şunu yazdı: > > Hi everyone, > > Over the past few weeks we have been hard at work sorting out the > last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I > believe we have sorted out the issues which are necessary to perform the > final migration: > > * We are missing only two tickets (#1436 and #2074 which will require a > bit of manual intervention to import due to extremely large > description lengths) > > * A variety of markup issues have been resolved > > * More metadata is now preserved via labels. We may choose to > reorganize or eliminate some of these labels in time but it's easier > to remove metadata after import than it is to reintroduce it. The > logic which maps Trac metadata to GitLab labels can be found here [2] > > * We now generate a Wiki table of contents [3] which is significantly > more readable than GitLab's default page list. This will be updated > by a cron job until underlying GitLab pages list becomes more > readable. > > * We now generate redirects for Trac ticket and Wiki links (although > this isn't visible in the staging instance) > > * Milestones are now properly closed when closed in Trac > > * Mapping between Trac and GitLab usernames is now a bit more robust > > As in previous test imports, we would appreciate it if you could have a > look over the import and let us know of any problems your encounter. > > If no serious issues are identified with the staging site we plan to > proceed with the migration this coming weekend. The current migration > plan is to perform the final import on gitlab.haskell.org on Saturday, 9 > March 2019. > > This will involve both gitlab.haskell.org and ghc.haskell.org being down > for likely the entirety of the day Saturday and likely some of Sunday > (EST time zone). Read-only access will be available to > gitlab.staging.haskell.org for ticket lookup while the import is > underway. > > After the import we will wait at least a week or so before we begin the > process of decommissioning Trac, which will be kept in read-only mode > for the duration. > > Do let me know if the 9 March timing is problematic. > > Cheers, > > - Ben > > > [1] https://gitlab.staging.haskell.org/ghc/ghc > [2] https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 > [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From b at chreekat.net Wed Mar 6 07:06:25 2019 From: b at chreekat.net (Bryan Richter) Date: Wed, 6 Mar 2019 09:06:25 +0200 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <87va0wr6xd.fsf@smart-cactus.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> <87va0wr6xd.fsf@smart-cactus.org> Message-ID: Ben wrote: > Unfortunately a mention of a ticket from a commit does not produce a notification email. This is in my opinion a rather serious issue that we will need to work around since it makes closing tickets after merge far more painful than necessary. Is there something in the GHC workflow that precludes the normal Gitlab behavior of automatically closing issues after a merge? There just needs to be a commit message or MR description with the words "Closes #xxx" [1]. Or perhaps you were talking specifically about Trac? I'm just spectating this from a distance so might have misunderstood the problem. [1]: Full details at https://docs.gitlab.com/ee/user/project/issues/closing_issues.html#via-merge-request On Wed, 6 Mar 2019, 5.57 Ben Gamari, wrote: > Simon Peyton Jones via ghc-devs writes: > > > Matthew, Ben > > > > I've just received 40-odd messages like this one. It looks as if Marge > > is now sending commit messages at Trac ticket messages, which is > > great. Will that happen after the move to GitLab. > > > > Also, is this sudden wave because a whole lot of commits have now > > landed in master? Or is it somehow an old backlog stuck in a mail > > queue? > > > This happened because the GitLab -> git.haskell.org mirroring > process was stuck. Yesterday I un-stuck it which then triggered the push > of approximately 40 commits, triggering the old Trac commit notifier > which produced the messages you received. > > Regarding commit notifications after we migrate: > > * Tickets will have notes added when they are mentioned by a commit > message. As we discussed earlier, messages won't include the commit > message text but rather only a reference to the referring commit SHA. > For instance, this looks like [1]. > > If we find the indirection between the ticket and the mentioning > commit message to be problematic we can certainly revisit this. > > * Commit notifications will be sent to ghc-commits at haskell.org; the > format will change a bit but the overall content won't change. > > * Unfortunately a mention of a ticket from a commit does not produce a > notification email. This is in my opinion a rather serious issue that > we will need to work around since it makes closing tickets after > merge far more painful than necessary. > > > > There may be some housekeeping to do, to close tickets, check > > regression tests and add pointers to the appropriate tests. Is anyone > > up for doing that? > > > Yes, I have been accumulating a sizeable queue of tickets to > sort through. I've started working through this but certainly won't > finish tonight. I have a few other obligations tomorrow but I'll try to > pick it up again later in the day. > > Cheers, > > - Ben > > > > [1] https://gitlab.staging.haskell.org/ghc/ghc/issues/16260#note_173847 > _______________________________________________ > 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 alan.zimm at gmail.com Wed Mar 6 07:12:45 2019 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 6 Mar 2019 09:12:45 +0200 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> <877eddro34.fsf@smart-cactus.org> Message-ID: I'm impressed, 'stack setup 8.6.4` brings it down already. Alan On Tue, 5 Mar 2019 at 23:58, Phyx wrote: > Thanks! To be fair I'm not really sure how popular it is. I was wondering > since once I upload the chocolatey packages it's immutable. > > If there's anything I can help with let me know. > > Cheers, > Tamar > > On Tue, Mar 5, 2019, 21:47 Ben Gamari wrote: > >> Phyx writes: >> >> > Hi Ben, >> > >> > Thanks for the release! I was wondering, any reason for the no i386 >> Windows? >> > Should I just create the package without it or is it coming? >> > >> This is one configuration I haven't yet had a chance to CI-ify. I was >> hoping it would be missed but since you mention it I've gone ahead and >> put up an attempt at fixing this (!495 [1]). It will likely take a few >> iterations to get right but I'll try to get it sorted by the end of the >> week. >> >> Cheers, >> >> - Ben >> >> >> [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/495 >> > _______________________________________________ > 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 Mar 6 09:23:37 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Mar 2019 09:23:37 +0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <87va0wr6xd.fsf@smart-cactus.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> <87va0wr6xd.fsf@smart-cactus.org> Message-ID: | * Tickets will have notes added when they are mentioned by a commit | message. As we discussed earlier, messages won't include the commit | message text but rather only a reference to the referring commit SHA. | For instance, this looks like [1]. I thought we'd decided, for now anyway, to /include/ the commit message text. (Matthew dissented.) Is that hard to do? Simon | -----Original Message----- | From: Ben Gamari | Sent: 06 March 2019 03:58 | To: Simon Peyton Jones ; Matthew Pickering | | Cc: ghc-devs at haskell.org | Subject: RE: [GHC] #16348: GHC HEAD regression: tyConAppArgs | | Simon Peyton Jones via ghc-devs writes: | | > Matthew, Ben | > | > I've just received 40-odd messages like this one. It looks as if Marge | > is now sending commit messages at Trac ticket messages, which is | > great. Will that happen after the move to GitLab. | > | > Also, is this sudden wave because a whole lot of commits have now | > landed in master? Or is it somehow an old backlog stuck in a mail | > queue? | > | This happened because the GitLab -> git.haskell.org mirroring process | was stuck. Yesterday I un-stuck it which then triggered the push of | approximately 40 commits, triggering the old Trac commit notifier which | produced the messages you received. | | Regarding commit notifications after we migrate: | | * Tickets will have notes added when they are mentioned by a commit | message. As we discussed earlier, messages won't include the commit | message text but rather only a reference to the referring commit SHA. | For instance, this looks like [1]. | | If we find the indirection between the ticket and the mentioning | commit message to be problematic we can certainly revisit this. | | * Commit notifications will be sent to ghc-commits at haskell.org; the | format will change a bit but the overall content won't change. | | * Unfortunately a mention of a ticket from a commit does not produce a | notification email. This is in my opinion a rather serious issue that | we will need to work around since it makes closing tickets after | merge far more painful than necessary. | | | > There may be some housekeeping to do, to close tickets, check | > regression tests and add pointers to the appropriate tests. Is anyone | > up for doing that? | > | Yes, I have been accumulating a sizeable queue of tickets to sort | through. I've started working through this but certainly won't finish | tonight. I have a few other obligations tomorrow but I'll try to pick it | up again later in the day. | | Cheers, | | - Ben | | | | [1] https://gitlab.staging.haskell.org/ghc/ghc/issues/16260#note_173847 From simonpj at microsoft.com Wed Mar 6 09:57:35 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Mar 2019 09:57:35 +0000 Subject: Haddock tree spongled Message-ID: Devs In a clean, up-to-date master I try to say Bash$ git submodule update fatal: reference is not a tree: 07f2ca98fd4249dc6ebad053bd6aef90c814efe0 Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in submodule path 'utils/haddock' What should I do? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Mar 6 10:05:06 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 6 Mar 2019 13:05:06 +0300 Subject: Haddock tree spongled In-Reply-To: References: Message-ID: I just pulled master and `git submodule update` worked. Have you done `git submodule sync` after updating your remotes to point to Gitlab? I'd try doing that and then `git submodule update --init` again afterwards. Ömer Simon Peyton Jones via ghc-devs , 6 Mar 2019 Çar, 12:57 tarihinde şunu yazdı: > > Devs > > > > In a clean, up-to-date master I try to say > > Bash$ git submodule update > > fatal: reference is not a tree: 07f2ca98fd4249dc6ebad053bd6aef90c814efe0 > > Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in submodule path 'utils/haddock' > > > > What should I do? > > > > 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 Wed Mar 6 10:13:49 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Mar 2019 10:13:49 +0000 Subject: Haddock tree spongled In-Reply-To: References: Message-ID: Yes I'm pointing to gitlab. [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = https://gitlab.haskell.org/ghc/ghc.git pushurl = git at gitlab.haskell.org:ghc/ghc I have done git submodule sync git submodule init git submodule update The latter elicits this odd message. Simon | -----Original Message----- | From: Ömer Sinan Ağacan | Sent: 06 March 2019 10:05 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Haddock tree spongled | | I just pulled master and `git submodule update` worked. Have you done `git | submodule sync` after updating your remotes to point to Gitlab? I'd try | doing that and then `git submodule update --init` again afterwards. | | Ömer | | Simon Peyton Jones via ghc-devs , 6 Mar 2019 Çar, | 12:57 tarihinde şunu yazdı: | > | > Devs | > | > | > | > In a clean, up-to-date master I try to say | > | > Bash$ git submodule update | > | > fatal: reference is not a tree: | > 07f2ca98fd4249dc6ebad053bd6aef90c814efe0 | > | > Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in | submodule path 'utils/haddock' | > | > | > | > What should I do? | > | > | > | > 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%7Cc8487e1fe20546d89ada08d6a21b4bd8%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636874635457691388&sdata=q%2F | > Fex6QsoPl9IkBydNUGcWLbf2dlrgbzltMAkTHtA5g%3D&reserved=0 From ben at well-typed.com Wed Mar 6 10:54:14 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 05:54:14 -0500 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> <87va0wr6xd.fsf@smart-cactus.org> Message-ID: <2FD63404-E902-48C3-AF3D-0BC692EE151B@well-typed.com> On March 6, 2019 2:06:25 AM EST, Bryan Richter wrote: >Ben wrote: >> Unfortunately a mention of a ticket from a commit does not produce >a notification email. This is in my opinion a rather serious issue that >we will need to work around since it makes closing tickets after merge >far >more painful than necessary. > >Is there something in the GHC workflow that precludes the normal Gitlab >behavior of automatically closing issues after a merge? There just >needs to >be a commit message or MR description with the words "Closes #xxx" [1]. > >Or perhaps you were talking specifically about Trac? > >I'm just spectating this from a distance so might have misunderstood >the >problem. > >[1]: Full details at >https://docs.gitlab.com/ee/user/project/issues/closing_issues.html#via-merge-request > The problem is that you very often want to review the ticket before closing it. There might be several reasons for this: - You might believe that your commit closes the ticket but perhaps there is a facet of the problem that you are forgetting - You might want to write a final summary of the solution - Perhaps there is an additional refactoring that you thought of while writing your patch that you would like to open a new ticket to track. - Maybe you just want to mark the patch to be back ported to the stable branch. The general theme here is that looking over the ticket one last time before closing is a helpful practice that allows us to catch problems early and keep our issue tracker tidy. It would be quite unfortunate to lose this ability. Cheers, - Ben >On Wed, 6 Mar 2019, 5.57 Ben Gamari, wrote: > >> Simon Peyton Jones via ghc-devs writes: >> >> > Matthew, Ben >> > >> > I've just received 40-odd messages like this one. It looks as if >Marge >> > is now sending commit messages at Trac ticket messages, which is >> > great. Will that happen after the move to GitLab. >> > >> > Also, is this sudden wave because a whole lot of commits have now >> > landed in master? Or is it somehow an old backlog stuck in a mail >> > queue? >> > >> This happened because the GitLab -> git.haskell.org mirroring >> process was stuck. Yesterday I un-stuck it which then triggered the >push >> of approximately 40 commits, triggering the old Trac commit notifier >> which produced the messages you received. >> >> Regarding commit notifications after we migrate: >> >> * Tickets will have notes added when they are mentioned by a commit >> message. As we discussed earlier, messages won't include the >commit >> message text but rather only a reference to the referring commit >SHA. >> For instance, this looks like [1]. >> >> If we find the indirection between the ticket and the mentioning >> commit message to be problematic we can certainly revisit this. >> >> * Commit notifications will be sent to ghc-commits at haskell.org; the >> format will change a bit but the overall content won't change. >> >> * Unfortunately a mention of a ticket from a commit does not produce >a >> notification email. This is in my opinion a rather serious issue >that >> we will need to work around since it makes closing tickets after >> merge far more painful than necessary. >> >> >> > There may be some housekeeping to do, to close tickets, check >> > regression tests and add pointers to the appropriate tests. Is >anyone >> > up for doing that? >> > >> Yes, I have been accumulating a sizeable queue of tickets to >> sort through. I've started working through this but certainly won't >> finish tonight. I have a few other obligations tomorrow but I'll try >to >> pick it up again later in the day. >> >> Cheers, >> >> - Ben >> >> >> >> [1] >https://gitlab.staging.haskell.org/ghc/ghc/issues/16260#note_173847 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From tdammers at gmail.com Wed Mar 6 10:55:15 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Wed, 6 Mar 2019 11:55:15 +0100 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: <20190306105513.wmozsv7qnlmv2jzd@nibbler> On Wed, Mar 06, 2019 at 09:32:44AM +0300, Ömer Sinan Ağacan wrote: > - Redirects don't seem to work: > https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects I believe this is an unfortunate result of the way we migrate wiki pages. The way that works is that we don't actually parse the original Trac markup; instead, we scrape the rendered HTML directly from the live Trac instance, and massage that into GitLab markup. This has a few interesting consequences: 1. "Wiki processors", such as for example dynamically-generated TOCs and issue lists, get to run on the Trac instance as we request the page, and thus capture a snapshot of the dynamic data at the time of migration. 2. Redirects, being implemented as such wiki processors, cause client-side redirects, which our scraper will not follow. Hence, the converted page is based on an HTML page body that you don't normally get to see, and no actual redirect is generated on the GitLab side of things. 3. The scraper only looks at what is normally the actual page content; any additional UI generated outside of the main content element is ignored. Hence, when Trac generates links to the redirect target for clients that do not support client-side redirects, those links don't make it into the converted page. 4. Because redirects are usually the last thing to be added to a page, that page's history ends there, and becomes the "current" version on the GitLab side. So we end up with what you're seeing: a nonsensical page that contains the fallback content, a somewhat cryptic question asking whether it should redirect, and no way to answer that question. Since GitLab doesn't have an equivalent to those "wiki processors", and AFAIK does not cater for such redirects, the question is how we should handle these. I can think of several options: 1. Do nothing; when anyone complains, fix the offending pages manually (either by converting the useless redirect message into a proper hyperlink, or by manually adding a rewrite entry to the nginx configuration). 2. Generate a list of redirecting pages from the Trac dataset, either as part of the import (2a), or with some grep/sed/awk magic based on the converted git repo after the fact (2b); then use that list to generate suitable nginx redirects. 3. Extend the import script to detect redirects, and special-case those so that they render as proper links to the redirect target. 4. Do more research and see if there is a way to make GitLab redirect based on wiki content, then extend the import script like in step 3, but render redirecting pages to use the (currently hypothetical) redirect feature. Personally, I'm inclined to say let's go with option 2b: run the import, then grep for 'redirect(wiki:', and massage that into nginx redirects. TL;DR: the import currently ignores Trac wiki redirects, and I'm not sure what the best way is to deal with this. From ben at well-typed.com Wed Mar 6 10:57:07 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 05:57:07 -0500 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org> <87va0wr6xd.fsf@smart-cactus.org> Message-ID: On March 6, 2019 4:23:37 AM EST, Simon Peyton Jones wrote: >| * Tickets will have notes added when they are mentioned by a commit >| message. As we discussed earlier, messages won't include the >commit >| message text but rather only a reference to the referring commit >SHA. >| For instance, this looks like [1]. > >I thought we'd decided, for now anyway, to /include/ the commit message >text. (Matthew dissented.) Is that hard to do? > >Simon > > Oh dear, I will need to look back over my notes. I suspect my memory has failed me here. Regardless, it is not particularly hard to include commit messages. Cheers, - Ben -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ben at well-typed.com Wed Mar 6 11:02:45 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 06:02:45 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: On March 6, 2019 1:32:44 AM EST, "Ömer Sinan Ağacan" wrote: >This look great, thanks to everyone involved! > >Some feedback: > >- When I click to the "Wiki" link on the left it opens "Home" page and >I don't >know how to go to the index from there. I think we may want index to be >the > home page for the wiki? > Yes, I do think we at least want to link to the index from the wiki home page. >- Redirects don't seem to work: >https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects > Yes this needs to be fixed. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From ben at well-typed.com Wed Mar 6 11:09:35 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 06:09:35 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <20190306105513.wmozsv7qnlmv2jzd@nibbler> References: <8736o0ssqo.fsf@smart-cactus.org> <20190306105513.wmozsv7qnlmv2jzd@nibbler> Message-ID: <58274B81-E1C1-4607-ABFD-9427967B5B40@well-typed.com> The lacking redirect support is unfortunate. In my opinion this is something we will need to handle going forward as well; a one time solution like adding nginx redirects doesn't seem like the right approach to me. I would rather advocate either option 3 or one of the following options: 5. Detect redirects and convert them to symbolic links in the repo 6. Request redirect support in the gitlab wiki. On March 6, 2019 5:55:15 AM EST, Tobias Dammers wrote: >On Wed, Mar 06, 2019 at 09:32:44AM +0300, Ömer Sinan Ağacan wrote: >> - Redirects don't seem to work: >> >https://gitlab.staging.haskell.org/ghc/ghc/wikis/commentary/rts/heap-objects > >I believe this is an unfortunate result of the way we migrate wiki >pages. The way that works is that we don't actually parse the original >Trac markup; instead, we scrape the rendered HTML directly from the >live >Trac instance, and massage that into GitLab markup. > >This has a few interesting consequences: > >1. "Wiki processors", such as for example dynamically-generated TOCs >and >issue lists, get to run on the Trac instance as we request the page, >and >thus capture a snapshot of the dynamic data at the time of migration. >2. Redirects, being implemented as such wiki processors, cause >client-side redirects, which our scraper will not follow. Hence, the >converted page is based on an HTML page body that you don't normally >get >to see, and no actual redirect is generated on the GitLab side of >things. >3. The scraper only looks at what is normally the actual page content; >any additional UI generated outside of the main content element is >ignored. Hence, when Trac generates links to the redirect target for >clients that do not support client-side redirects, those links don't >make it into the converted page. >4. Because redirects are usually the last thing to be added to a page, >that page's history ends there, and becomes the "current" version on >the >GitLab side. So we end up with what you're seeing: a nonsensical page >that contains the fallback content, a somewhat cryptic question asking >whether it should redirect, and no way to answer that question. > >Since GitLab doesn't have an equivalent to those "wiki processors", and >AFAIK does not cater for such redirects, the question is how we should >handle these. I can think of several options: > >1. Do nothing; when anyone complains, fix the offending pages manually >(either by converting the useless redirect message into a proper >hyperlink, or by manually adding a rewrite entry to the nginx >configuration). >2. Generate a list of redirecting pages from the Trac dataset, either >as >part of the import (2a), or with some grep/sed/awk magic based on the >converted git repo after the fact (2b); then use that list to generate >suitable nginx redirects. >3. Extend the import script to detect redirects, and special-case those >so that they render as proper links to the redirect target. >4. Do more research and see if there is a way to make GitLab redirect >based on wiki content, then extend the import script like in step 3, >but >render redirecting pages to use the (currently hypothetical) redirect >feature. > >Personally, I'm inclined to say let's go with option 2b: run the >import, >then grep for 'redirect(wiki:', and massage that into nginx redirects. > >TL;DR: the import currently ignores Trac wiki redirects, and I'm not >sure what the best way is to deal with this. >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Wed Mar 6 11:11:49 2019 From: me at ara.io (Ara Adkins) Date: Wed, 6 Mar 2019 11:11:49 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <8736o0ssqo.fsf@smart-cactus.org> References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: Super excited for this! Thank you to everyone whose put in so much hard work to get it done! One question: what is happening with the trac tickets mailing list? I imagine it’ll be going away, but for those of us that use it to keep track of things is there a recommended alternative? Best, _ara > On 6 Mar 2019, at 01:21, Ben Gamari wrote: > > Hi everyone, > > Over the past few weeks we have been hard at work sorting out the > last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I > believe we have sorted out the issues which are necessary to perform the > final migration: > > * We are missing only two tickets (#1436 and #2074 which will require a > bit of manual intervention to import due to extremely large > description lengths) > > * A variety of markup issues have been resolved > > * More metadata is now preserved via labels. We may choose to > reorganize or eliminate some of these labels in time but it's easier > to remove metadata after import than it is to reintroduce it. The > logic which maps Trac metadata to GitLab labels can be found here [2] > > * We now generate a Wiki table of contents [3] which is significantly > more readable than GitLab's default page list. This will be updated > by a cron job until underlying GitLab pages list becomes more > readable. > > * We now generate redirects for Trac ticket and Wiki links (although > this isn't visible in the staging instance) > > * Milestones are now properly closed when closed in Trac > > * Mapping between Trac and GitLab usernames is now a bit more robust > > As in previous test imports, we would appreciate it if you could have a > look over the import and let us know of any problems your encounter. > > If no serious issues are identified with the staging site we plan to > proceed with the migration this coming weekend. The current migration > plan is to perform the final import on gitlab.haskell.org on Saturday, 9 > March 2019. > > This will involve both gitlab.haskell.org and ghc.haskell.org being down > for likely the entirety of the day Saturday and likely some of Sunday > (EST time zone). Read-only access will be available to > gitlab.staging.haskell.org for ticket lookup while the import is > underway. > > After the import we will wait at least a week or so before we begin the > process of decommissioning Trac, which will be kept in read-only mode > for the duration. > > Do let me know if the 9 March timing is problematic. > > Cheers, > > - Ben > > > [1] https://gitlab.staging.haskell.org/ghc/ghc > [2] https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 > [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ryan.gl.scott at gmail.com Wed Mar 6 11:17:24 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 6 Mar 2019 06:17:24 -0500 Subject: Haddock tree spongled Message-ID: I do think something is afoot here. The current Haddock submodule commit is at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6 [2]. It would be good if someone could update the ghc-head branch accordingly. Ryan S. ----- [1] https://github.com/haskell/haddock/commit/07f2ca98fd4249dc6ebad053bd6aef90c814efe0 [2] https://github.com/haskell/haddock/commit/8459c600e0f6da3f85abefdefe651bbe3ed3da4a -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Mar 6 11:21:34 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 06:21:34 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> Message-ID: <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >Super excited for this! Thank you to everyone whose put in so much hard >work to get it done! > >One question: what is happening with the trac tickets mailing list? I >imagine it’ll be going away, but for those of us that use it to keep >track of things is there a recommended alternative? > The ghc-commits list will continue to work. The ghc-tickets list is a good question. I suspect that under gitlab there will be less need for this list but we may still want to continue maintaining it regardless for continuity's sake. Thoughts? Cheers, - Ben >Best, >_ara > >> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >> >> Hi everyone, >> >> Over the past few weeks we have been hard at work sorting out the >> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >point I >> believe we have sorted out the issues which are necessary to perform >the >> final migration: >> >> * We are missing only two tickets (#1436 and #2074 which will require >a >> bit of manual intervention to import due to extremely large >> description lengths) >> >> * A variety of markup issues have been resolved >> >> * More metadata is now preserved via labels. We may choose to >> reorganize or eliminate some of these labels in time but it's >easier >> to remove metadata after import than it is to reintroduce it. The >> logic which maps Trac metadata to GitLab labels can be found here >[2] >> >> * We now generate a Wiki table of contents [3] which is significantly >> more readable than GitLab's default page list. This will be updated >> by a cron job until underlying GitLab pages list becomes more >> readable. >> >> * We now generate redirects for Trac ticket and Wiki links (although >> this isn't visible in the staging instance) >> >> * Milestones are now properly closed when closed in Trac >> >> * Mapping between Trac and GitLab usernames is now a bit more robust >> >> As in previous test imports, we would appreciate it if you could have >a >> look over the import and let us know of any problems your encounter. >> >> If no serious issues are identified with the staging site we plan to >> proceed with the migration this coming weekend. The current migration >> plan is to perform the final import on gitlab.haskell.org on >Saturday, 9 >> March 2019. >> >> This will involve both gitlab.haskell.org and ghc.haskell.org being >down >> for likely the entirety of the day Saturday and likely some of Sunday >> (EST time zone). Read-only access will be available to >> gitlab.staging.haskell.org for ticket lookup while the import is >> underway. >> >> After the import we will wait at least a week or so before we begin >the >> process of decommissioning Trac, which will be kept in read-only mode >> for the duration. >> >> Do let me know if the 9 March timing is problematic. >> >> Cheers, >> >> - Ben >> >> >> [1] https://gitlab.staging.haskell.org/ghc/ghc >> [2] >https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From me at ara.io Wed Mar 6 11:33:39 2019 From: me at ara.io (Ara Adkins) Date: Wed, 6 Mar 2019 11:33:39 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> Message-ID: Personally I would like to see it continued, but it may not be worth the work if I’m in a minority here. A potential stopgap would be to ‘watch’ the GHC project on our gitlab instance, but I can’t see any way to decide to get emails for notifications rather than having to check in at GitLab all the time. _ara > On 6 Mar 2019, at 11:21, Ben Gamari wrote: > > > >> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >> Super excited for this! Thank you to everyone whose put in so much hard >> work to get it done! >> >> One question: what is happening with the trac tickets mailing list? I >> imagine it’ll be going away, but for those of us that use it to keep >> track of things is there a recommended alternative? >> > The ghc-commits list will continue to work. > > The ghc-tickets list is a good question. I suspect that under gitlab there will be less need for this list but we may still want to continue maintaining it regardless for continuity's sake. Thoughts? > > Cheers, > > - Ben > > > >> Best, >> _ara >> >>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >>> >>> Hi everyone, >>> >>> Over the past few weeks we have been hard at work sorting out the >>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >> point I >>> believe we have sorted out the issues which are necessary to perform >> the >>> final migration: >>> >>> * We are missing only two tickets (#1436 and #2074 which will require >> a >>> bit of manual intervention to import due to extremely large >>> description lengths) >>> >>> * A variety of markup issues have been resolved >>> >>> * More metadata is now preserved via labels. We may choose to >>> reorganize or eliminate some of these labels in time but it's >> easier >>> to remove metadata after import than it is to reintroduce it. The >>> logic which maps Trac metadata to GitLab labels can be found here >> [2] >>> >>> * We now generate a Wiki table of contents [3] which is significantly >>> more readable than GitLab's default page list. This will be updated >>> by a cron job until underlying GitLab pages list becomes more >>> readable. >>> >>> * We now generate redirects for Trac ticket and Wiki links (although >>> this isn't visible in the staging instance) >>> >>> * Milestones are now properly closed when closed in Trac >>> >>> * Mapping between Trac and GitLab usernames is now a bit more robust >>> >>> As in previous test imports, we would appreciate it if you could have >> a >>> look over the import and let us know of any problems your encounter. >>> >>> If no serious issues are identified with the staging site we plan to >>> proceed with the migration this coming weekend. The current migration >>> plan is to perform the final import on gitlab.haskell.org on >> Saturday, 9 >>> March 2019. >>> >>> This will involve both gitlab.haskell.org and ghc.haskell.org being >> down >>> for likely the entirety of the day Saturday and likely some of Sunday >>> (EST time zone). Read-only access will be available to >>> gitlab.staging.haskell.org for ticket lookup while the import is >>> underway. >>> >>> After the import we will wait at least a week or so before we begin >> the >>> process of decommissioning Trac, which will be kept in read-only mode >>> for the duration. >>> >>> Do let me know if the 9 March timing is problematic. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] https://gitlab.staging.haskell.org/ghc/ghc >>> [2] >> https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From sylvain at haskus.fr Wed Mar 6 12:00:28 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 6 Mar 2019 13:00:28 +0100 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> Message-ID: <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> I use it to track tickets and I would also like to see it continued. Sylvain On 06/03/2019 12:33, Ara Adkins wrote: > Personally I would like to see it continued, but it may not be worth the work if I’m in a minority here. > > A potential stopgap would be to ‘watch’ the GHC project on our gitlab instance, but I can’t see any way to decide to get emails for notifications rather than having to check in at GitLab all the time. > > _ara > >> On 6 Mar 2019, at 11:21, Ben Gamari wrote: >> >> >> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >>> Super excited for this! Thank you to everyone whose put in so much hard >>> work to get it done! >>> >>> One question: what is happening with the trac tickets mailing list? I >>> imagine it’ll be going away, but for those of us that use it to keep >>> track of things is there a recommended alternative? >>> >> The ghc-commits list will continue to work. >> >> The ghc-tickets list is a good question. I suspect that under gitlab there will be less need for this list but we may still want to continue maintaining it regardless for continuity's sake. Thoughts? >> >> Cheers, >> >> - Ben >> >> >> >>> Best, >>> _ara >>> >>>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >>>> >>>> Hi everyone, >>>> >>>> Over the past few weeks we have been hard at work sorting out the >>>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >>> point I >>>> believe we have sorted out the issues which are necessary to perform >>> the >>>> final migration: >>>> >>>> * We are missing only two tickets (#1436 and #2074 which will require >>> a >>>> bit of manual intervention to import due to extremely large >>>> description lengths) >>>> >>>> * A variety of markup issues have been resolved >>>> >>>> * More metadata is now preserved via labels. We may choose to >>>> reorganize or eliminate some of these labels in time but it's >>> easier >>>> to remove metadata after import than it is to reintroduce it. The >>>> logic which maps Trac metadata to GitLab labels can be found here >>> [2] >>>> * We now generate a Wiki table of contents [3] which is significantly >>>> more readable than GitLab's default page list. This will be updated >>>> by a cron job until underlying GitLab pages list becomes more >>>> readable. >>>> >>>> * We now generate redirects for Trac ticket and Wiki links (although >>>> this isn't visible in the staging instance) >>>> >>>> * Milestones are now properly closed when closed in Trac >>>> >>>> * Mapping between Trac and GitLab usernames is now a bit more robust >>>> >>>> As in previous test imports, we would appreciate it if you could have >>> a >>>> look over the import and let us know of any problems your encounter. >>>> >>>> If no serious issues are identified with the staging site we plan to >>>> proceed with the migration this coming weekend. The current migration >>>> plan is to perform the final import on gitlab.haskell.org on >>> Saturday, 9 >>>> March 2019. >>>> >>>> This will involve both gitlab.haskell.org and ghc.haskell.org being >>> down >>>> for likely the entirety of the day Saturday and likely some of Sunday >>>> (EST time zone). Read-only access will be available to >>>> gitlab.staging.haskell.org for ticket lookup while the import is >>>> underway. >>>> >>>> After the import we will wait at least a week or so before we begin >>> the >>>> process of decommissioning Trac, which will be kept in read-only mode >>>> for the duration. >>>> >>>> Do let me know if the 9 March timing is problematic. >>>> >>>> Cheers, >>>> >>>> - Ben >>>> >>>> >>>> [1] https://gitlab.staging.haskell.org/ghc/ghc >>>> [2] >>> https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >>>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From tdammers at gmail.com Wed Mar 6 12:05:28 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Wed, 6 Mar 2019 13:05:28 +0100 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <58274B81-E1C1-4607-ABFD-9427967B5B40@well-typed.com> References: <8736o0ssqo.fsf@smart-cactus.org> <20190306105513.wmozsv7qnlmv2jzd@nibbler> <58274B81-E1C1-4607-ABFD-9427967B5B40@well-typed.com> Message-ID: <20190306120527.mrinpp7j5j3koxk6@nibbler> On Wed, Mar 06, 2019 at 06:09:35AM -0500, Ben Gamari wrote: > The lacking redirect support is unfortunate. In my opinion this is something we will need to handle going forward as well; a one time solution like adding nginx redirects doesn't seem like the right approach to me. > > I would rather advocate either option 3 or one of the following options: > > 5. Detect redirects and convert them to symbolic links in the repo > 6. Request redirect support in the gitlab wiki. OK, I'll see what I can do about option 3. Option 5 is something that I believe we can still do after the fact if need be. Option 6, I think, we should do anyway, because we will want that feature for future pages, and the solutions outlined so far only take care of existing pages. From ben at smart-cactus.org Wed Mar 6 12:08:26 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 06 Mar 2019 07:08:26 -0500 Subject: Haddock tree spongled In-Reply-To: References: Message-ID: <87sgw0qk8b.fsf@smart-cactus.org> Ryan Scott writes: > I do think something is afoot here. The current Haddock submodule commit is > at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6 > [2]. It would be good if someone could update the ghc-head branch > accordingly. > Indeed. Done. It would be nice if we had a better way to handle this. Ideally Marge or someone similar would land any relevant haddock patches to ghc-head when landing a GHC MR. 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 takenobu.hs at gmail.com Wed Mar 6 12:12:05 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 6 Mar 2019 21:12:05 +0900 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <87h8chrqkl.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: Hi, I always appreciate your hard work. Perhaps you may know, but the following html documents are not included in the windows tarball [1]: * doc/html/index.html * doc/html/users_guide/index.html * doc/html/libraries/index.html These files were included in ghc-8.6.3 tarball [2]. These are very useful in offline or slow network environment :) [1]: https://downloads.haskell.org/ghc/8.6.4/ghc-8.6.4-x86_64-unknown-mingw32.tar.xz [2]: https://downloads.haskell.org/ghc/8.6.3/ghc-8.6.3-x86_64-unknown-mingw32.tar.xz Regards, Takenobu On Wed, Mar 6, 2019 at 5:53 AM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.4, a > bugfix release in the GHC 8.6 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.4 > > The 8.6.4 release fixes several regressions present in 8.6.3 including: > > - A regression resulting in segmentation faults on Windows introduced > by the fix for #16071 backported in 8.6.3. This fix has been reverted, > meaning that 8.6.4 is once again susceptible to #16071. #16071 will > be fixed in GHC 8.8.1. > > - A bug resulting in incorrect locking on Darwin, potentially resulting > in hangs at shutdown (#16150) > > - A few bugs in the profiled runtime resulting in the potential for > memory unsafety has been fixed (#15508). > > - The `process` and `transformers` libraries shipped now properly > reflect released Hackage releases (#16199) > > - A bug where TH name resolution would break in a plugin context has > been fixed (#16104) > > - Compilers that do not support TemplateHaskell no longer advertise > such support in `--supported-languages` (#16331) > > As a few of these issues are rather serious users are strongly > encouraged to upgrade. See Trac [1] for a full list of issues resolved > in this release. > > Note that this release ships with one significant but long-standing bug > (#14251): Calls to functions taking both Float# and Double# may result > in incorrect code generation when compiled using the LLVM code generator. > This is not a new issue, it has existed as long as the LLVM code > generator has existed; however, changes in code generation in 8.6 made > it more likely that user code using only lifted types will trigger it. > > Note also that this is the first release cut from our (yet again) > revamped continuous integration infrastructure. While we have done a > great deal of checking to ensure that the build configuration reflects > that of previous releases, do let us know if something looks off. > > Happy compiling! > > Cheers, > > - Ben > > [1] > https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority > _______________________________________________ > 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 ben at well-typed.com Wed Mar 6 12:22:42 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 07:22:42 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: <87pnr4qjjl.fsf@smart-cactus.org> Takenobu Tani writes: > Hi, > > I always appreciate your hard work. > > Perhaps you may know, but the following html documents are not included in > the windows tarball [1]: > > * doc/html/index.html > * doc/html/users_guide/index.html > * doc/html/libraries/index.html > Thanks Takenobu! I hadn't noticed this. I've opened #16398 to track this. We'll try to fix this before 8.8.1. 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 Wed Mar 6 12:32:54 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 6 Mar 2019 12:32:54 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> Message-ID: I think gitlab can be configured so notifications are sent for new issues and comments on issues which should achieve the same thing as the mailing list did? On Wed, Mar 6, 2019 at 12:00 PM Sylvain Henry wrote: > I use it to track tickets and I would also like to see it continued. > > Sylvain > > On 06/03/2019 12:33, Ara Adkins wrote: > > Personally I would like to see it continued, but it may not be worth the > work if I’m in a minority here. > > > > A potential stopgap would be to ‘watch’ the GHC project on our gitlab > instance, but I can’t see any way to decide to get emails for notifications > rather than having to check in at GitLab all the time. > > > > _ara > > > >> On 6 Mar 2019, at 11:21, Ben Gamari wrote: > >> > >> > >> > >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: > >>> Super excited for this! Thank you to everyone whose put in so much hard > >>> work to get it done! > >>> > >>> One question: what is happening with the trac tickets mailing list? I > >>> imagine it’ll be going away, but for those of us that use it to keep > >>> track of things is there a recommended alternative? > >>> > >> The ghc-commits list will continue to work. > >> > >> The ghc-tickets list is a good question. I suspect that under gitlab > there will be less need for this list but we may still want to continue > maintaining it regardless for continuity's sake. Thoughts? > >> > >> Cheers, > >> > >> - Ben > >> > >> > >> > >>> Best, > >>> _ara > >>> > >>>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> Over the past few weeks we have been hard at work sorting out the > >>>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this > >>> point I > >>>> believe we have sorted out the issues which are necessary to perform > >>> the > >>>> final migration: > >>>> > >>>> * We are missing only two tickets (#1436 and #2074 which will require > >>> a > >>>> bit of manual intervention to import due to extremely large > >>>> description lengths) > >>>> > >>>> * A variety of markup issues have been resolved > >>>> > >>>> * More metadata is now preserved via labels. We may choose to > >>>> reorganize or eliminate some of these labels in time but it's > >>> easier > >>>> to remove metadata after import than it is to reintroduce it. The > >>>> logic which maps Trac metadata to GitLab labels can be found here > >>> [2] > >>>> * We now generate a Wiki table of contents [3] which is significantly > >>>> more readable than GitLab's default page list. This will be updated > >>>> by a cron job until underlying GitLab pages list becomes more > >>>> readable. > >>>> > >>>> * We now generate redirects for Trac ticket and Wiki links (although > >>>> this isn't visible in the staging instance) > >>>> > >>>> * Milestones are now properly closed when closed in Trac > >>>> > >>>> * Mapping between Trac and GitLab usernames is now a bit more robust > >>>> > >>>> As in previous test imports, we would appreciate it if you could have > >>> a > >>>> look over the import and let us know of any problems your encounter. > >>>> > >>>> If no serious issues are identified with the staging site we plan to > >>>> proceed with the migration this coming weekend. The current migration > >>>> plan is to perform the final import on gitlab.haskell.org on > >>> Saturday, 9 > >>>> March 2019. > >>>> > >>>> This will involve both gitlab.haskell.org and ghc.haskell.org being > >>> down > >>>> for likely the entirety of the day Saturday and likely some of Sunday > >>>> (EST time zone). Read-only access will be available to > >>>> gitlab.staging.haskell.org for ticket lookup while the import is > >>>> underway. > >>>> > >>>> After the import we will wait at least a week or so before we begin > >>> the > >>>> process of decommissioning Trac, which will be kept in read-only mode > >>>> for the duration. > >>>> > >>>> Do let me know if the 9 March timing is problematic. > >>>> > >>>> Cheers, > >>>> > >>>> - Ben > >>>> > >>>> > >>>> [1] https://gitlab.staging.haskell.org/ghc/ghc > >>>> [2] > >>> > https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 > >>>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> To (un)subscribe, modify options or view archives go to: > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >>>> Only members subscribed via the mailman list are allowed to post. > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > > 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 me at ara.io Wed Mar 6 12:57:23 2019 From: me at ara.io (Ara Adkins) Date: Wed, 6 Mar 2019 12:57:23 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> Message-ID: That would be perfect if so. I couldn't find a way to do it when I looked earlier, but I may well have missed something! On Wed, 6 Mar 2019 at 12:33, Matthew Pickering wrote: > I think gitlab can be configured so notifications are sent for new issues > and comments on issues which should achieve the same thing as the mailing > list did? > > > > On Wed, Mar 6, 2019 at 12:00 PM Sylvain Henry wrote: > >> I use it to track tickets and I would also like to see it continued. >> >> Sylvain >> >> On 06/03/2019 12:33, Ara Adkins wrote: >> > Personally I would like to see it continued, but it may not be worth >> the work if I’m in a minority here. >> > >> > A potential stopgap would be to ‘watch’ the GHC project on our gitlab >> instance, but I can’t see any way to decide to get emails for notifications >> rather than having to check in at GitLab all the time. >> > >> > _ara >> > >> >> On 6 Mar 2019, at 11:21, Ben Gamari wrote: >> >> >> >> >> >> >> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >> >>> Super excited for this! Thank you to everyone whose put in so much >> hard >> >>> work to get it done! >> >>> >> >>> One question: what is happening with the trac tickets mailing list? I >> >>> imagine it’ll be going away, but for those of us that use it to keep >> >>> track of things is there a recommended alternative? >> >>> >> >> The ghc-commits list will continue to work. >> >> >> >> The ghc-tickets list is a good question. I suspect that under gitlab >> there will be less need for this list but we may still want to continue >> maintaining it regardless for continuity's sake. Thoughts? >> >> >> >> Cheers, >> >> >> >> - Ben >> >> >> >> >> >> >> >>> Best, >> >>> _ara >> >>> >> >>>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >> >>>> >> >>>> Hi everyone, >> >>>> >> >>>> Over the past few weeks we have been hard at work sorting out the >> >>>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >> >>> point I >> >>>> believe we have sorted out the issues which are necessary to perform >> >>> the >> >>>> final migration: >> >>>> >> >>>> * We are missing only two tickets (#1436 and #2074 which will require >> >>> a >> >>>> bit of manual intervention to import due to extremely large >> >>>> description lengths) >> >>>> >> >>>> * A variety of markup issues have been resolved >> >>>> >> >>>> * More metadata is now preserved via labels. We may choose to >> >>>> reorganize or eliminate some of these labels in time but it's >> >>> easier >> >>>> to remove metadata after import than it is to reintroduce it. The >> >>>> logic which maps Trac metadata to GitLab labels can be found here >> >>> [2] >> >>>> * We now generate a Wiki table of contents [3] which is significantly >> >>>> more readable than GitLab's default page list. This will be updated >> >>>> by a cron job until underlying GitLab pages list becomes more >> >>>> readable. >> >>>> >> >>>> * We now generate redirects for Trac ticket and Wiki links (although >> >>>> this isn't visible in the staging instance) >> >>>> >> >>>> * Milestones are now properly closed when closed in Trac >> >>>> >> >>>> * Mapping between Trac and GitLab usernames is now a bit more robust >> >>>> >> >>>> As in previous test imports, we would appreciate it if you could have >> >>> a >> >>>> look over the import and let us know of any problems your encounter. >> >>>> >> >>>> If no serious issues are identified with the staging site we plan to >> >>>> proceed with the migration this coming weekend. The current migration >> >>>> plan is to perform the final import on gitlab.haskell.org on >> >>> Saturday, 9 >> >>>> March 2019. >> >>>> >> >>>> This will involve both gitlab.haskell.org and ghc.haskell.org being >> >>> down >> >>>> for likely the entirety of the day Saturday and likely some of Sunday >> >>>> (EST time zone). Read-only access will be available to >> >>>> gitlab.staging.haskell.org for ticket lookup while the import is >> >>>> underway. >> >>>> >> >>>> After the import we will wait at least a week or so before we begin >> >>> the >> >>>> process of decommissioning Trac, which will be kept in read-only mode >> >>>> for the duration. >> >>>> >> >>>> Do let me know if the 9 March timing is problematic. >> >>>> >> >>>> Cheers, >> >>>> >> >>>> - Ben >> >>>> >> >>>> >> >>>> [1] https://gitlab.staging.haskell.org/ghc/ghc >> >>>> [2] >> >>> >> https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >> >>>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >> >>>> _______________________________________________ >> >>>> Haskell-Cafe mailing list >> >>>> To (un)subscribe, modify options or view archives go to: >> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >>>> Only members subscribed via the mailman list are allowed to post. >> >> -- >> >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > _______________________________________________ >> > 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 tdammers at gmail.com Wed Mar 6 13:29:23 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Wed, 6 Mar 2019 14:29:23 +0100 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <20190306120527.mrinpp7j5j3koxk6@nibbler> References: <8736o0ssqo.fsf@smart-cactus.org> <20190306105513.wmozsv7qnlmv2jzd@nibbler> <58274B81-E1C1-4607-ABFD-9427967B5B40@well-typed.com> <20190306120527.mrinpp7j5j3koxk6@nibbler> Message-ID: <20190306132922.43jpj6vtqwnzbkr3@nibbler> For context: there is a total of 22 pages that use the redirect feature. So it may actually be feasible to just do this manually. On Wed, Mar 06, 2019 at 01:05:28PM +0100, Tobias Dammers wrote: > On Wed, Mar 06, 2019 at 06:09:35AM -0500, Ben Gamari wrote: > > The lacking redirect support is unfortunate. In my opinion this is something we will need to handle going forward as well; a one time solution like adding nginx redirects doesn't seem like the right approach to me. > > > > I would rather advocate either option 3 or one of the following options: > > > > 5. Detect redirects and convert them to symbolic links in the repo > > 6. Request redirect support in the gitlab wiki. > > OK, I'll see what I can do about option 3. Option 5 is something that I > believe we can still do after the fact if need be. Option 6, I think, we > should do anyway, because we will want that feature for future pages, > and the solutions outlined so far only take care of existing pages. > -- Tobias Dammers - tdammers at gmail.com From takenobu.hs at gmail.com Wed Mar 6 13:45:16 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Wed, 6 Mar 2019 22:45:16 +0900 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <87pnr4qjjl.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> <87pnr4qjjl.fsf@smart-cactus.org> Message-ID: > I've opened #16398 to track this. We'll try to fix this before 8.8.1. Thanks for doing that! Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Wed Mar 6 14:51:30 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 6 Mar 2019 15:51:30 +0100 Subject: Haddock tree spongled In-Reply-To: <87sgw0qk8b.fsf@smart-cactus.org> References: <87sgw0qk8b.fsf@smart-cactus.org> Message-ID: Why don't we just put Haddock into GHC's repository? It was proposed in a previous discussion in February [1] and it would avoid the bad experience of having it as a submodule while keeping it in sync. With the following commands we can keep the whole commit history: In Haddock repo: > mkdir -p utils/haddock > git rm .arcconfig .arclint .ghci .gitignore .travis.yml > git mv -k * utils/haddock > git commit -a -m "Prepare Haddock merge" In GHC repo: > git rm -rf utils/haddock > git commit -a -m "Prepare Haddock merge" > git remote add haddock https://gitlab.haskell.org/ghc/haddock > git fetch haddock > git merge --allow-unrelated-histories haddock/ghc-8.6 -m "Merge haddock" > git remote remove haddock [1] https://mail.haskell.org/pipermail/ghc-devs/2019-February/017120.html Cheers, Sylvain On 06/03/2019 13:08, Ben Gamari wrote: > Ryan Scott writes: > >> I do think something is afoot here. The current Haddock submodule commit is >> at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6 >> [2]. It would be good if someone could update the ghc-head branch >> accordingly. >> > Indeed. Done. > > It would be nice if we had a better way to handle this. Ideally Marge or > someone similar would land any relevant haddock patches to ghc-head when > landing a GHC MR. > > Cheers, > > - Ben > > > _______________________________________________ > 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 ben at smart-cactus.org Wed Mar 6 14:59:31 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 06 Mar 2019 09:59:31 -0500 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> Message-ID: <87lg1sqcaa.fsf@smart-cactus.org> Sylvain Henry writes: > Why don't we just put Haddock into GHC's repository? It was proposed in > a previous discussion in February [1] and it would avoid the bad > experience of having it as a submodule while keeping it in sync. > I'm reluctant to keep it in the GHC tree; it really is a separate project with separate maintainership, dependencies, and contributors. That being said, I do agree that the status quo is pretty poor. I was going to suggest managing it with git-subtree instead, but I'm not sure this would be much of an improvement. 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 Mar 6 15:50:44 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Wed, 6 Mar 2019 10:50:44 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <87h8chrqkl.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: Hi Ben, On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.4, a > bugfix release in the GHC 8.6 series. > There doesn't seem to be a ghc-8.6.4-release tag of http://git.haskell.org/ghc.git? Can you advise me on a magic invocation that would let me get a checkout of the repository at the release SHA? -- 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 digitalasset.com Wed Mar 6 15:59:54 2019 From: shayne.fletcher at digitalasset.com (Shayne Fletcher) Date: Wed, 6 Mar 2019 10:59:54 -0500 Subject: Fwd: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: Sorry if you get two of these messages (having some email client problems :) )! Hi Ben, On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.4, a > bugfix release in the GHC 8.6 series. > There doesn't seem to be a ghc-8.6.4-release tag of http://git.haskell.org/ghc.git? Can you advise me on a magic invocation that would let me get a checkout of the repository at the release SHA? -- 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 digitalasset.com Wed Mar 6 16:09:05 2019 From: shayne.fletcher at digitalasset.com (Shayne Fletcher) Date: Wed, 6 Mar 2019 11:09:05 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: On Wed, Mar 6, 2019 at 10:59 AM Shayne Fletcher < shayne.fletcher at digitalasset.com> wrote: > Sorry if you get two of these messages (having some email client problems > :) )! > > Hi Ben, > > On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: > >> >> Hello everyone, >> >> The GHC team is very happy to announce the availability of GHC 8.6.4, a >> bugfix release in the GHC 8.6 series. >> > > There doesn't seem to be a ghc-8.6.4-release tag of > http://git.haskell.org/ghc.git? Can you advise me on a magic invocation > that would let me get a checkout of the repository at the release SHA? > Oh wait! Is it the SHA in the file `GIT_COMMIT_ID`? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: email at digitalasset.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 digitalasset.com Wed Mar 6 16:16:10 2019 From: shayne.fletcher at digitalasset.com (Shayne Fletcher) Date: Wed, 6 Mar 2019 11:16:10 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: On Wed, Mar 6, 2019 at 11:09 AM Shayne Fletcher < shayne.fletcher at digitalasset.com> wrote: > > >> On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: >> >>> >>> Hello everyone, >>> >>> The GHC team is very happy to announce the availability of GHC 8.6.4, a >>> bugfix release in the GHC 8.6 series. >>> >> >> There doesn't seem to be a ghc-8.6.4-release tag of >> http://git.haskell.org/ghc.git? Can you advise me on a magic invocation >> that would let me get a checkout of the repository at the release SHA? >> > > Oh wait! Is it the SHA in the file `GIT_COMMIT_ID`? > > No, apparently not: ``` fatal: reference is not a tree: aac18e9a08e6de9648e1a62d849dcd409f407df8 ``` Related : the `ANNOUNCE` file at least seems very out-of-date. -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: email at digitalasset.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 matthewtpickering at gmail.com Wed Mar 6 16:34:49 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 6 Mar 2019 16:34:49 +0000 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: You probably want to use the gitlab remote rather than the git.haskell.org one. Matt On Wed, Mar 6, 2019 at 4:16 PM Shayne Fletcher via ghc-devs < ghc-devs at haskell.org> wrote: > > On Wed, Mar 6, 2019 at 11:09 AM Shayne Fletcher < > shayne.fletcher at digitalasset.com> wrote: > >> >> >>> On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: >>> >>>> >>>> Hello everyone, >>>> >>>> The GHC team is very happy to announce the availability of GHC 8.6.4, a >>>> bugfix release in the GHC 8.6 series. >>>> >>> >>> There doesn't seem to be a ghc-8.6.4-release tag of >>> http://git.haskell.org/ghc.git? Can you advise me on a magic invocation >>> that would let me get a checkout of the repository at the release SHA? >>> >> >> Oh wait! Is it the SHA in the file `GIT_COMMIT_ID`? >> >> > No, apparently not: > ``` > fatal: reference is not a tree: aac18e9a08e6de9648e1a62d849dcd409f407df8 > ``` > Related : the `ANNOUNCE` file at least seems very out-of-date. > > -- > Shayne Fletcher > Language Engineer > c: +1 917 699 7763 > e: email at digitalasset.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Mar 6 16:39:31 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 11:39:31 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: References: <87h8chrqkl.fsf@smart-cactus.org> Message-ID: <87imwwq7nx.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > On Wed, Mar 6, 2019 at 11:09 AM Shayne Fletcher < > shayne.fletcher at digitalasset.com> wrote: > >> >> >>> On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: >>> >>>> >>>> Hello everyone, >>>> >>>> The GHC team is very happy to announce the availability of GHC 8.6.4, a >>>> bugfix release in the GHC 8.6 series. >>>> >>> >>> There doesn't seem to be a ghc-8.6.4-release tag of >>> http://git.haskell.org/ghc.git? Can you advise me on a magic invocation >>> that would let me get a checkout of the repository at the release SHA? >>> >> >> Oh wait! Is it the SHA in the file `GIT_COMMIT_ID`? >> >> > No, apparently not: > ``` > fatal: reference is not a tree: aac18e9a08e6de9648e1a62d849dcd409f407df8 > ``` > Related : the `ANNOUNCE` file at least seems very out-of-date. > Hi Shayne, You should find the tag on https://gitlab.haskell.org/ghc/ghc, which is now the official upstream. That being said, I am a bit surprised that it wasn't mirrored to git.haskell.org. 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 Wed Mar 6 16:44:02 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 11:44:02 -0500 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> Message-ID: <87fts0q7fz.fsf@smart-cactus.org> Ara Adkins writes: > That would be perfect if so. I couldn't find a way to do it when I looked > earlier, but I may well have missed something! > If you navigate to the GHC project page [1] while logged in you should find a little bell [2] button to the right of the "GHC" heading. If you click on this and select "Custom" from the drop-down you can choose precisely which notifications you want sent. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc [2] https://docs.gitlab.com/ee/workflow/notifications.html#project-settings -------------- 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 digitalasset.com Wed Mar 6 16:43:55 2019 From: shayne.fletcher at digitalasset.com (Shayne Fletcher) Date: Wed, 6 Mar 2019 11:43:55 -0500 Subject: [ANNOUNCE] GHC 8.6.4 is now available In-Reply-To: <87imwwq7nx.fsf@smart-cactus.org> References: <87h8chrqkl.fsf@smart-cactus.org> <87imwwq7nx.fsf@smart-cactus.org> Message-ID: On Wed, Mar 6, 2019 at 11:39 AM Ben Gamari wrote: > Shayne Fletcher via ghc-devs writes: > > > On Wed, Mar 6, 2019 at 11:09 AM Shayne Fletcher < > > shayne.fletcher at digitalasset.com> wrote: > > > >> > >> > >>> On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari wrote: > >>> > >>>> > >>>> Hello everyone, > >>>> > >>>> The GHC team is very happy to announce the availability of GHC 8.6.4, > a > >>>> bugfix release in the GHC 8.6 series. > >>>> > >>> > >>> There doesn't seem to be a ghc-8.6.4-release tag of > >>> http://git.haskell.org/ghc.git? Can you advise me on a magic > invocation > >>> that would let me get a checkout of the repository at the release SHA? > >>> > [...] > > Related : the `ANNOUNCE` file at least seems very out-of-date. > > > Hi Shayne, > > You should find the tag on https://gitlab.haskell.org/ghc/ghc, which is > now the official upstream. That being said, I am a bit > surprised that it wasn't mirrored to git.haskell.org. > > Yep, thanks Ben and Matt. Got it. > That being said, I am a bit surprised that it wasn't mirrored to git.haskell.org. Yes! Kind of worrying ... Will you be following through on that? > Cheers, > > - Ben > -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: email at digitalasset.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 me at ara.io Wed Mar 6 16:48:47 2019 From: me at ara.io (Ara Adkins) Date: Wed, 6 Mar 2019 16:48:47 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: <87fts0q7fz.fsf@smart-cactus.org> References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> <87fts0q7fz.fsf@smart-cactus.org> Message-ID: I think that's a reliable replacement for the ghc-tickets mailing list if it works well. I'll have to see once the cut-over happens! On Wed, 6 Mar 2019 at 16:44, Ben Gamari wrote: > Ara Adkins writes: > > > That would be perfect if so. I couldn't find a way to do it when I looked > > earlier, but I may well have missed something! > > > If you navigate to the GHC project page [1] while logged in you should > find a little bell [2] button to the right of the "GHC" heading. If you > click on this and select "Custom" from the drop-down you can choose > precisely which notifications you want sent. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc > [2] > https://docs.gitlab.com/ee/workflow/notifications.html#project-settings > _______________________________________________ > 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 lonetiger at gmail.com Wed Mar 6 19:42:59 2019 From: lonetiger at gmail.com (Phyx) Date: Wed, 6 Mar 2019 19:42:59 +0000 Subject: [Haskell-cafe] Final steps in GHC's Trac-to-GitLab migration In-Reply-To: References: <8736o0ssqo.fsf@smart-cactus.org> <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com> <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr> Message-ID: Can they be sent from a different email address than the main. Gitlab+margebot are quite. Ahum, noisy.. and filtering based on message content has a potential for false positives. Kind regards, Tamar On Wed, Mar 6, 2019, 12:33 Matthew Pickering wrote: > I think gitlab can be configured so notifications are sent for new issues > and comments on issues which should achieve the same thing as the mailing > list did? > > > > On Wed, Mar 6, 2019 at 12:00 PM Sylvain Henry wrote: > >> I use it to track tickets and I would also like to see it continued. >> >> Sylvain >> >> On 06/03/2019 12:33, Ara Adkins wrote: >> > Personally I would like to see it continued, but it may not be worth >> the work if I’m in a minority here. >> > >> > A potential stopgap would be to ‘watch’ the GHC project on our gitlab >> instance, but I can’t see any way to decide to get emails for notifications >> rather than having to check in at GitLab all the time. >> > >> > _ara >> > >> >> On 6 Mar 2019, at 11:21, Ben Gamari wrote: >> >> >> >> >> >> >> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins wrote: >> >>> Super excited for this! Thank you to everyone whose put in so much >> hard >> >>> work to get it done! >> >>> >> >>> One question: what is happening with the trac tickets mailing list? I >> >>> imagine it’ll be going away, but for those of us that use it to keep >> >>> track of things is there a recommended alternative? >> >>> >> >> The ghc-commits list will continue to work. >> >> >> >> The ghc-tickets list is a good question. I suspect that under gitlab >> there will be less need for this list but we may still want to continue >> maintaining it regardless for continuity's sake. Thoughts? >> >> >> >> Cheers, >> >> >> >> - Ben >> >> >> >> >> >> >> >>> Best, >> >>> _ara >> >>> >> >>>> On 6 Mar 2019, at 01:21, Ben Gamari wrote: >> >>>> >> >>>> Hi everyone, >> >>>> >> >>>> Over the past few weeks we have been hard at work sorting out the >> >>>> last batch of issues in GHC's Trac-to-GitLab import [1]. At this >> >>> point I >> >>>> believe we have sorted out the issues which are necessary to perform >> >>> the >> >>>> final migration: >> >>>> >> >>>> * We are missing only two tickets (#1436 and #2074 which will require >> >>> a >> >>>> bit of manual intervention to import due to extremely large >> >>>> description lengths) >> >>>> >> >>>> * A variety of markup issues have been resolved >> >>>> >> >>>> * More metadata is now preserved via labels. We may choose to >> >>>> reorganize or eliminate some of these labels in time but it's >> >>> easier >> >>>> to remove metadata after import than it is to reintroduce it. The >> >>>> logic which maps Trac metadata to GitLab labels can be found here >> >>> [2] >> >>>> * We now generate a Wiki table of contents [3] which is significantly >> >>>> more readable than GitLab's default page list. This will be updated >> >>>> by a cron job until underlying GitLab pages list becomes more >> >>>> readable. >> >>>> >> >>>> * We now generate redirects for Trac ticket and Wiki links (although >> >>>> this isn't visible in the staging instance) >> >>>> >> >>>> * Milestones are now properly closed when closed in Trac >> >>>> >> >>>> * Mapping between Trac and GitLab usernames is now a bit more robust >> >>>> >> >>>> As in previous test imports, we would appreciate it if you could have >> >>> a >> >>>> look over the import and let us know of any problems your encounter. >> >>>> >> >>>> If no serious issues are identified with the staging site we plan to >> >>>> proceed with the migration this coming weekend. The current migration >> >>>> plan is to perform the final import on gitlab.haskell.org on >> >>> Saturday, 9 >> >>>> March 2019. >> >>>> >> >>>> This will involve both gitlab.haskell.org and ghc.haskell.org being >> >>> down >> >>>> for likely the entirety of the day Saturday and likely some of Sunday >> >>>> (EST time zone). Read-only access will be available to >> >>>> gitlab.staging.haskell.org for ticket lookup while the import is >> >>>> underway. >> >>>> >> >>>> After the import we will wait at least a week or so before we begin >> >>> the >> >>>> process of decommissioning Trac, which will be kept in read-only mode >> >>>> for the duration. >> >>>> >> >>>> Do let me know if the 9 March timing is problematic. >> >>>> >> >>>> Cheers, >> >>>> >> >>>> - Ben >> >>>> >> >>>> >> >>>> [1] https://gitlab.staging.haskell.org/ghc/ghc >> >>>> [2] >> >>> >> https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 >> >>>> [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index >> >>>> _______________________________________________ >> >>>> Haskell-Cafe mailing list >> >>>> To (un)subscribe, modify options or view archives go to: >> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >>>> Only members subscribed via the mailman list are allowed to post. >> >> -- >> >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > _______________________________________________ >> > 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 m at tweag.io Wed Mar 6 21:26:36 2019 From: m at tweag.io (Boespflug, Mathieu) Date: Wed, 6 Mar 2019 22:26:36 +0100 Subject: Haddock tree spongled In-Reply-To: <87lg1sqcaa.fsf@smart-cactus.org> References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> Message-ID: If the status quo is poor, then why not merge the two? git-subtree won't fix the problem and will arguably be even harder to manage than submodules. Best, On Wed, 6 Mar 2019 at 15:59, Ben Gamari wrote: > Sylvain Henry writes: > > > Why don't we just put Haddock into GHC's repository? It was proposed in > > a previous discussion in February [1] and it would avoid the bad > > experience of having it as a submodule while keeping it in sync. > > > I'm reluctant to keep it in the GHC tree; it really is a separate > project with separate maintainership, dependencies, and contributors. > > That being said, I do agree that the status quo is pretty poor. I was > going to suggest managing it with git-subtree instead, but I'm not sure > this would be much of an improvement. > > Cheers, > > - Ben > _______________________________________________ > 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 ben at well-typed.com Wed Mar 6 21:59:54 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 06 Mar 2019 16:59:54 -0500 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> Message-ID: <87a7i7r7ea.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > If the status quo is poor, then why not merge the two? git-subtree won't > fix the problem and will arguably be even harder to manage than submodules. > The status quo is indeed awkward at times. However, merging Haddock into GHC would only serve to shuffle this awkwardness to be felt by a different group of people. Currently the awkward workflow is contributing a GHC patch that affects the subset of GHC's AST that Haddock cares about. This is unfortunate but not unexpected; working with coupled systems always brings challenges. However, this is not the common case. If we were to merge Haddock into GHC then we make harder the lives of those who work on Haddock independently from GHC. All Haddock changes would need to go through the GHC tree, we would need to setup special CI rules to run only the haddock testsuite, and the histories of the two orthogonal projects would be awkwardly coupled. Given that most of the commits in the haddock repository are independent from GHC this seems like a poor trade-off. As a general rule I think we would be better off trying to loosen GHC's coupling to other projects than further entrench them. 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 alec.theriault at gmail.com Wed Mar 6 22:04:06 2019 From: alec.theriault at gmail.com (Alec Theriault) Date: Wed, 6 Mar 2019 14:04:06 -0800 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> Message-ID: <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> Merging Haddock into GHC’s subtree would undoubtedly simplify the GHC workflow for patches affecting Haddock. There are a couple other considerations though: Haddock currently sees the bulk of its contributions and bug fixes on its stable branches, not the ghc-head branch (which is the one GHC tracks). Not only is this exactly the opposite of GHC, but it also makes outside contributions and CI much simpler. The Haddock project is actually 3 packages, two of which are libraries, one of which is expected to build on GHC going all the way back to the 7.4.* series. AFAICT, the packages kept in GHC’s source tree usually advance in lockstep with GHC. Running the full GHC CI for most of Haddock’s changes seems a waste of resources and an unnecessary delay. Besides, Haddock actually has a larger test suite, which is only expected to compile on the stable branch (although I try to keep it running on ghc-head with the help of head.hackage). I recently incorporated the other part of Haddock’s testsuite into GHC’s testsuite, so I’m hoping there will be less breakage coming from ghc-head. Interleaving git histories would (mostly) just make bisecting both GHC and Haddock more of a pain. The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front… Thanks, Alec > On Mar 6, 2019, at 1:26 PM, Boespflug, Mathieu wrote: > > If the status quo is poor, then why not merge the two? git-subtree won't fix the problem and will arguably be even harder to manage than submodules. > > Best, > > On Wed, 6 Mar 2019 at 15:59, Ben Gamari > wrote: > Sylvain Henry > writes: > > > Why don't we just put Haddock into GHC's repository? It was proposed in > > a previous discussion in February [1] and it would avoid the bad > > experience of having it as a submodule while keeping it in sync. > > > I'm reluctant to keep it in the GHC tree; it really is a separate > project with separate maintainership, dependencies, and contributors. > > That being said, I do agree that the status quo is pretty poor. I was > going to suggest managing it with git-subtree instead, but I'm not sure > this would be much of an improvement. > > Cheers, > > - Ben > _______________________________________________ > 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 moritz.angermann at gmail.com Thu Mar 7 07:45:47 2019 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 7 Mar 2019 15:45:47 +0800 Subject: Why can't we re-install the template-haskell package? Message-ID: Dear friends, as I'm working on making lib:ghc re-installable [1][2]. Ideally I'd prefer we only had to freeze rts + ghc-prim and maybe base (which would implicate the integer library). However, we apparently can't re-install Template Haskell I'm told. Not just not upgrade it, but not even re-install it (same version). I've attached some rough dependency graph (which I hope is correct for ghc 8.8). Fixing template-haskell implies ghc-boot-th, pretty, deepseq and array. Can someone shed some light onto the details here? What are the fundamental issues we can't reinstall template-haskell? Cheers, Moritz -- [1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/490 [2]: https://gitlab.haskell.org/ghc/ghc/merge_requests/506 -------------- next part -------------- A non-text attachment was scrubbed... Name: ghc-8.8-deps.pdf Type: application/pdf Size: 28739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From ryan.gl.scott at gmail.com Thu Mar 7 13:28:11 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 7 Mar 2019 08:28:11 -0500 Subject: Why can't we re-install the template-haskell package? Message-ID: My (limited) understanding is that template-haskell is not reinstallable for the same reasons that base and ghc-prim aren't reinstallable: the GHC codebase directly wires in several definitions several functions, types, and data constructors from template-haskell. See THNames [1]. If one were to, say, use GHC 8.6 but install a different version of template-haskell than the one that came bundled with 8.6, then it's almost certain that lots of code in THNames would no longer work, since they could be referencing identifiers that no longer exist (if the new version of template-haskell doesn't have them). Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/blob/25c3dd39f7d446f66b5c967be81f80cd7facb509/compiler/prelude/THNames.hs -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu Mar 7 18:08:08 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 7 Mar 2019 13:08:08 -0500 Subject: git.haskell.org is broken Message-ID: As of today, git clone git://git.haskell.org/ghc.git --recursive is failing with, error: Server does not allow request for unadvertised object 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 Fetched in submodule path 'libraries/binary', but it did not contain 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit failed. -- 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 rae at cs.brynmawr.edu Thu Mar 7 18:53:12 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 7 Mar 2019 13:53:12 -0500 Subject: Why can't we re-install the template-haskell package? In-Reply-To: References: Message-ID: <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu> I have to admit I don't have a strong grasp on what "reinstallable" implies. Does a package get the same hash after reinstalling? What could make a package not reinstallable? Why aren't packages reinstallable today? Why isn't ghc-prim reinstallable? My concern stems from the fact that ghc is interlinked with TH in at least two ways: - GHC imports definitions from template-haskell. But this is the same as the way GHC is involved with, say, `base`. - GHC also wires in some template-haskell definitions. This is the aspect I am worried about. Is `base` reinstallable? If so, then perhaps template-haskell could be, too. Thanks, Richard From ben at well-typed.com Fri Mar 8 00:43:56 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 07 Mar 2019 19:43:56 -0500 Subject: git.haskell.org is broken In-Reply-To: References: Message-ID: <871s3iqjp4.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > As of today, > git clone git://git.haskell.org/ghc.git --recursive > is failing with, > error: Server does not allow request for unadvertised object > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 > Fetched in submodule path 'libraries/binary', but it did not contain > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit > failed. > Yes, we are currently in the process of decommissioning git.haskell.org. The official upstream repository is now https://gitlab.haskell.org/ghc/ghc. This will all become clearer after Saturday when we finish the migration and can start updating the documentation to reflect the new state of the world. 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 moritz.angermann at gmail.com Fri Mar 8 03:12:32 2019 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 8 Mar 2019 11:12:32 +0800 Subject: Why can't we re-install the template-haskell package? In-Reply-To: <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu> References: <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu> Message-ID: <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com> Hi Ryan, hi Richard, > My (limited) understanding is that template-haskell is not reinstallable for the same reasons that base and ghc-prim aren't reinstallable: the GHC codebase directly wires in several definitions several functions, types, and data constructors from template-haskell. See THNames [1]. If one were to, say, use GHC 8.6 but install a different version of template-haskell than the one that came bundled with 8.6, then it's almost certain that lots of code in THNames would no longer work, since they could be referencing identifiers that no longer exist (if the new version of template-haskell doesn't have them). Right, I'm mostly concerned about re-installing the *same* version again. For the motivation: template-haskell depends on pretty, deepseq and array. Let's assume there is some off-by-one issue in array that only affects my application right now. Now I'm going to patch my array package, but if my application depends on template-haskell, I end up with two different array packages in my dependency tree that are not identical. What I'd ideally like to do here is to re-install deepseq, pretty and template-haskell based on my fixed array package. Now I don't have two different array packeds in my dependencies anymore; it would however require me to be able to rebuild (the same version) of template-haskell. > I have to admit I don't have a strong grasp on what "reinstallable" implies. Does a package get the same hash after reinstalling? What could make a package not reinstallable? Why aren't packages reinstallable today? Why isn't ghc-prim reinstallable? We can't re-install packages that depend on build-time values. The RTS and ghc-prim right now include files that are generated during the build process and they have no capability on their own to create those files, as such re-installing them is not possible right now. > My concern stems from the fact that ghc is interlinked with TH in at least two ways: > - GHC imports definitions from template-haskell. But this is the same as the way GHC is involved with, say, `base`. > - GHC also wires in some template-haskell definitions. This is the aspect I am worried about. Is `base` reinstallable? If so, then perhaps template-haskell could be, too. Now especially with TH I might see an issue when *running/using* TH, as at that point the compiler and the produces code have to interact. That is we are compiling splices against a different template-haskell package than the compiler is built against. This is where I see *upgrading* (that is building a newer version of Template Haskell) could be an issue, but I feel I don't fully grasp why rebuilding the same version should pose an issue. If we go one step further and use iserv (-fexternal-interpreter) outright, then I think we could just rebuild iserv against the re-installed template-haskell, and would not even run into the above mentioned issue. Might this potentially even be allow us to upgrade template-haskell? Cheers, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From shayne.fletcher at digitalasset.com Fri Mar 8 04:39:43 2019 From: shayne.fletcher at digitalasset.com (Shayne Fletcher) Date: Thu, 7 Mar 2019 23:39:43 -0500 Subject: git.haskell.org is broken In-Reply-To: <871s3iqjp4.fsf@smart-cactus.org> References: <871s3iqjp4.fsf@smart-cactus.org> Message-ID: Hi Ben, On Thu, Mar 7, 2019 at 7:44 PM Ben Gamari wrote: > Shayne Fletcher via ghc-devs writes: > > > As of today, > > git clone git://git.haskell.org/ghc.git --recursive > > is failing with, > > error: Server does not allow request for unadvertised object > > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 > > Fetched in submodule path 'libraries/binary', but it did not contain > > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit > > failed. > > > Yes, we are currently in the process of decommissioning git.haskell.org. > The official upstream repository is now > https://gitlab.haskell.org/ghc/ghc. > > Got it! Thanks for the update. One little problem that's causing is `git checkout https://gitlab.haskell.org/ghc/ghc` on Travis, linux config, seems to fail (appears to be a known issue). Travis macos and Appveyor work fine. > This will all become clearer after Saturday when we finish the migration > and can start updating the documentation to reflect the new state of the > world. > > Awesome. Thanks again. > Cheers, > > - Ben > -- 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 Mar 8 05:09:50 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 8 Mar 2019 00:09:50 -0500 Subject: git.haskell.org is broken In-Reply-To: References: <871s3iqjp4.fsf@smart-cactus.org> Message-ID: On Thu, Mar 7, 2019 at 11:39 PM Shayne Fletcher < shayne.fletcher at digitalasset.com> wrote: > Hi Ben, > > On Thu, Mar 7, 2019 at 7:44 PM Ben Gamari wrote: > >> [...] Yes, we are currently in the process of decommissioning git.haskell.org. >> The official upstream repository is now >> https://gitlab.haskell.org/ghc/ghc. >> >> > Got it! Thanks for the update. > > One little problem that's causing is `git checkout > https://gitlab.haskell.org/ghc/ghc` > I meant `clone` of course (long day) :) > on Travis, linux config, seems to fail (appears to be a known issue). > Travis macos and Appveyor work fine. > > -- 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 ryan.gl.scott at gmail.com Fri Mar 8 14:05:53 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 8 Mar 2019 09:05:53 -0500 Subject: Why can't we re-install the template-haskell package? In-Reply-To: <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com> References: <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu> <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com> Message-ID: If you're reinstalling the same template-haskell version, then I can't immediately think of anything that would go wrong. Then again, I'm not intimately familiar with all of the little details that might be relevant here. Out of curiosity, are you asking this question because you've tried implementing this and failed somewhere? Or are you trying to figure out is there's some obvious problem with the idea that's been overlooked? In the absence of anyone chiming in with such an obvious problem, I'd be inclined to just try implementing it and seeing what happens. If it does break, that could provide some valuable insight. Ryan S. On Thu, Mar 7, 2019 at 10:12 PM Moritz Angermann wrote: > Hi Ryan, hi Richard, > > > My (limited) understanding is that template-haskell is not reinstallable > for the same reasons that base and ghc-prim aren't reinstallable: the GHC > codebase directly wires in several definitions several functions, types, > and data constructors from template-haskell. See THNames [1]. If one were > to, say, use GHC 8.6 but install a different version of template-haskell > than the one that came bundled with 8.6, then it's almost certain that lots > of code in THNames would no longer work, since they could be referencing > identifiers that no longer exist (if the new version of template-haskell > doesn't have them). > > Right, I'm mostly concerned about re-installing the *same* version again. > For the motivation: > template-haskell depends on pretty, deepseq and array. Let's assume there > is some off-by-one issue > in array that only affects my application right now. Now I'm going to > patch my array package, but > if my application depends on template-haskell, I end up with two different > array packages in my dependency > tree that are not identical. What I'd ideally like to do here is to > re-install deepseq, pretty and > template-haskell based on my fixed array package. Now I don't have two > different array packeds in my > dependencies anymore; it would however require me to be able to rebuild > (the same version) of template-haskell. > > > > I have to admit I don't have a strong grasp on what "reinstallable" > implies. Does a package get the same hash after reinstalling? What could > make a package not reinstallable? Why aren't packages reinstallable today? > Why isn't ghc-prim reinstallable? > > We can't re-install packages that depend on build-time values. The RTS and > ghc-prim right now > include files that are generated during the build process and they have no > capability on their > own to create those files, as such re-installing them is not possible > right now. > > > My concern stems from the fact that ghc is interlinked with TH in at > least two ways: > > - GHC imports definitions from template-haskell. But this is the same as > the way GHC is involved with, say, `base`. > > - GHC also wires in some template-haskell definitions. This is the > aspect I am worried about. Is `base` reinstallable? If so, then perhaps > template-haskell could be, too. > > > Now especially with TH I might see an issue when *running/using* TH, as at > that point the compiler > and the produces code have to interact. That is we are compiling splices > against a different > template-haskell package than the compiler is built against. This is > where I see *upgrading* (that > is building a newer version of Template Haskell) could be an issue, but I > feel I don't fully grasp > why rebuilding the same version should pose an issue. > > If we go one step further and use iserv (-fexternal-interpreter) outright, > then I think we could just > rebuild iserv against the re-installed template-haskell, and would not > even run into the above > mentioned issue. Might this potentially even be allow us to upgrade > template-haskell? > > Cheers, > Moritz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Fri Mar 8 14:16:49 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 8 Mar 2019 09:16:49 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work Message-ID: I appreciate this isn't really "our" problem :) Nonetheless, if there's any config we can do on the repo on gitlab, that would be cool. Other URLs (like github) for example are fine - something specific to gitlab. -- 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 oleg.grenrus at iki.fi Fri Mar 8 15:32:21 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 8 Mar 2019 17:32:21 +0200 Subject: Why can't we re-install the template-haskell package? In-Reply-To: References: <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu> <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com> Message-ID: <6a1712e4-1928-ea4d-f2d8-313bc72d8e6d@iki.fi> The Note [Wirde-in packages] is relevant, and highlights how you need to compile and use new template-haskell, for an exercise having a chance to work. Importantly you have to compile new `template-haskell` with `-this-unit-id template-haskell`, and not `template-haskell-2.14.0.0-somehash`. For the reference: Certain packages are known to the compiler, in that we know about certain entities that reside in these packages, and the compiler needs to declare static Modules and Names that refer to these packages.  Hence the wired-in packages can't include version numbers in their package UnitId, since we don't want to bake the version numbers of these packages into GHC. So here's the plan.  Wired-in packages are still versioned as normal in the packages database, and you can still have multiple versions of them installed. To the user, everything looks normal. However, for each invocation of GHC, only a single instance of each wired-in package will be recognised (the desired one is selected via @-package@\/@-hide-package@), and GHC will internall pretend that it has the *unversioned* 'UnitId', including in .hi files and object file symbols. Unselected versions of wired-in packages will be ignored, as will any other package that depends directly or indirectly on it (much as if you had used @-ignore-package@). The affected packages are compiled with, e.g., @-this-unit-id base@, so that the symbols in the object files have the unversioned unit id in their name. Make sure you change 'Packages.findWiredInPackages' if you add an entry here. For `integer-gmp`/`integer-simple` we also change the base name to `integer-wired-in`, but this is fundamentally no different. See Note [The integer library] in PrelNames. - Oleg On 8.3.2019 16.05, Ryan Scott wrote: > If you're reinstalling the same template-haskell version, then I can't > immediately think of anything that would go wrong. Then again, I'm not > intimately familiar with all of the little details that might be > relevant here. > > Out of curiosity, are you asking this question because you've tried > implementing this and failed somewhere? Or are you trying to figure > out is there's some obvious problem with the idea that's been > overlooked? In the absence of anyone chiming in with such an obvious > problem, I'd be inclined to just try implementing it and seeing what > happens. If it does break, that could provide some valuable insight. > > Ryan S. > > On Thu, Mar 7, 2019 at 10:12 PM Moritz Angermann > > wrote: > > Hi Ryan, hi Richard, > > > My (limited) understanding is that template-haskell is not > reinstallable for the same reasons that base and ghc-prim aren't > reinstallable: the GHC codebase directly wires in several > definitions several functions, types, and data constructors from > template-haskell. See THNames [1]. If one were to, say, use GHC > 8.6 but install a different version of template-haskell than the > one that came bundled with 8.6, then it's almost certain that lots > of code in THNames would no longer work, since they could be > referencing identifiers that no longer exist (if the new version > of template-haskell doesn't have them). > > Right, I'm mostly concerned about re-installing the *same* version > again.  For the motivation: > template-haskell depends on pretty, deepseq and array.  Let's > assume there is some off-by-one issue > in array that only affects my application right now.  Now I'm > going to patch my array package, but > if my application depends on template-haskell, I end up with two > different array packages in my dependency > tree that are not identical.  What I'd ideally like to do here is > to re-install deepseq, pretty and > template-haskell based on my fixed array package.  Now I don't > have two different array packeds in my > dependencies anymore; it would however require me to be able to > rebuild (the same version) of template-haskell. > > > > I have to admit I don't have a strong grasp on what > "reinstallable" implies. Does a package get the same hash after > reinstalling? What could make a package not reinstallable? Why > aren't packages reinstallable today? Why isn't ghc-prim reinstallable? > > We can't re-install packages that depend on build-time values. The > RTS and ghc-prim right now > include files that are generated during the build process and they > have no capability on their > own to create those files, as such re-installing them is not > possible right now. > > > My concern stems from the fact that ghc is interlinked with TH > in at least two ways: > > - GHC imports definitions from template-haskell. But this is the > same as the way GHC is involved with, say, `base`. > > - GHC also wires in some template-haskell definitions. This is > the aspect I am worried about. Is `base` reinstallable? If so, > then perhaps template-haskell could be, too. > > > Now especially with TH I might see an issue when *running/using* > TH, as at that point the compiler > and the produces code have to interact.  That is we are compiling > splices against a different > template-haskell package than the compiler is built against.  This > is where I see *upgrading* (that > is building a newer version of Template Haskell) could be an > issue, but I feel I don't fully grasp > why rebuilding the same version should pose an issue. > > If we go one step further and use iserv (-fexternal-interpreter) > outright, then I think we could just > rebuild iserv against the re-installed template-haskell, and would > not even run into the above > mentioned issue. Might this potentially even be allow us to > upgrade template-haskell? > > Cheers, >  Moritz > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shayne.fletcher at daml.com Fri Mar 8 18:54:45 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 8 Mar 2019 13:54:45 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: Message-ID: Hi y'all On Fri, Mar 8, 2019 at 9:16 AM Shayne Fletcher wrote: > I appreciate this isn't really "our" problem :) Nonetheless, if there's > any config we can do on the repo on gitlab, that would be cool. Other URLs > (like github) for example are fine - something specific to gitlab. > If anybody else gets bitten by this, mail me privately - I can offer a cheeky workaround! -- 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 Sat Mar 9 06:22:51 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 09 Mar 2019 01:22:51 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: Message-ID: <87wol8pnwp.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > I appreciate this isn't really "our" problem :) Nonetheless, if there's any > config we can do on the repo on gitlab, that would be cool. Other URLs > (like github) for example are fine - something specific to gitlab. > I feel like I'm missing something here. I recall you mentioned this in your previous message but there I'm still lacking crucial context. Can you offer any additional details? How exactly does it fail? In principle there is no reason why cloning from gitlab.haskell.org from Travis shouldn't work. I'd be happy to fix the issue if there is one but without knowing more I'm pretty powerless to change the situation. 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 oleg.grenrus at iki.fi Sat Mar 9 09:56:16 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 9 Mar 2019 11:56:16 +0200 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: <87wol8pnwp.fsf@smart-cactus.org> References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: <6767B6A5-7C02-4EF1-A80B-B1A39CC45D2D@iki.fi> At least at some point travis refused to clone git:// (over ssh) urls; but https:// works fine. As ghcs’ submodules are relative it /should just work/ - Oleg Sent from my iPhone > On 9 Mar 2019, at 8.22, Ben Gamari wrote: > > Shayne Fletcher via ghc-devs writes: > >> I appreciate this isn't really "our" problem :) Nonetheless, if there's any >> config we can do on the repo on gitlab, that would be cool. Other URLs >> (like github) for example are fine - something specific to gitlab. >> > I feel like I'm missing something here. I recall you mentioned this in > your previous message but there I'm still lacking crucial context. Can > you offer any additional details? How exactly does it fail? > > In principle there is no reason why cloning from gitlab.haskell.org from > Travis shouldn't work. I'd be happy to fix the issue if there is one but > without knowing more I'm pretty powerless to change the situation. > > Cheers, > > - Ben > > _______________________________________________ > 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 Sat Mar 9 12:15:15 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sat, 9 Mar 2019 07:15:15 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: <87wol8pnwp.fsf@smart-cactus.org> References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: On Sat, Mar 9, 2019 at 1:23 AM Ben Gamari wrote: > Shayne Fletcher via ghc-devs writes: > > [...] > I feel like I'm missing something here. I recall you mentioned this in > your previous message but there I'm still lacking crucial context. Can > you offer any additional details? How exactly does it fail? > > git clone https://gitlab.haskell.org/ghc/ghc.git fails on Travis Linux Ubuntu VMs with "fatal: unable to access ' https://gitlab.haskell.org/ghc/ghc.git/': gnutls_handshake() failed: Handshake failed. In principle there is no reason why cloning from gitlab.haskell.org from > Travis shouldn't work. I'd be happy to fix the issue if there is one but > without knowing more I'm pretty powerless to change the situation. > > The issue as I understand relates to gitlab's use of the "Let's Encrypt" certificate authority. Apparently this is a relatively new authority and is unrecognized by the SSL software on the Ubuntu VM that Travis provides. I don't know of any workarounds at this time that can be applied in the VM that to overcome this problem. I also don't know if anything can be done on the gitlab side to mitigate it but suspect not. I do have a procedure that allows me to side-step the problem for my own case and can share that with anyone that needs it. Cheers, > > - Ben > > -- 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 Sat Mar 9 16:23:10 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 09 Mar 2019 11:23:10 -0500 Subject: Trac to GitLab migration underway Message-ID: <87tvgcow4d.fsf@smart-cactus.org> Hello everyone, I have started the process of migrating GHC's Trac content to GitLab. GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down until this process has finished. I will post updates as necessary. However, if you do need to refer to a ticket, you are welcome to use the staging server [1], which has a reasonably up-to-date (read-only) snapshot of our Trac tickets. However, do note that unfortunately authentication via GitHub will not work on this site. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From oleg.grenrus at iki.fi Sat Mar 9 16:41:03 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 9 Mar 2019 18:41:03 +0200 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: I can reproduce that problem on Ubuntu 14.04 which Travis uses now by default. It's "fixed" in Ubuntu 16.04. Use     dist: xenial and your travis build should proceed. --- Ubuntu 14.04 root at 6f98cdde6521:/# git clone https://gitlab.haskell.org/ghc/ci-images.git Cloning into 'ci-images'... fatal: unable to access 'https://gitlab.haskell.org/ghc/ci-images.git/': gnutls_handshake() failed: Handshake failed Ubuntu 16.04 root at a66b1076e2f8:/#  git clone https://gitlab.haskell.org/ghc/ci-images.git Cloning into 'ci-images'... remote: Enumerating objects: 110, done. remote: Counting objects: 100% (110/110), done. remote: Compressing objects: 100% (53/53), done. remote: Total 110 (delta 49), reused 81 (delta 36) Receiving objects: 100% (110/110), 17.14 KiB | 0 bytes/s, done. Resolving deltas: 100% (49/49), done. Checking connectivity... done. --- - Oleg On 9.3.2019 14.15, Shayne Fletcher wrote: > > On Sat, Mar 9, 2019 at 1:23 AM Ben Gamari > wrote: > > Shayne Fletcher via ghc-devs > writes: > > [...]  > > I feel like I'm missing something here. I recall you mentioned this in > your previous message but there I'm still lacking crucial context. Can > you offer any additional details? How exactly does it fail? > > > git clone https://gitlab.haskell.org/ghc/ghc.git fails on Travis Linux > Ubuntu VMs with "fatal: unable to access > 'https://gitlab.haskell.org/ghc/ghc.git/': gnutls_handshake() failed: > Handshake failed. > > In principle there is no reason why cloning from > gitlab.haskell.org from > Travis shouldn't work. I'd be happy to fix the issue if there is > one but > without knowing more I'm pretty powerless to change the situation. > > > The issue as I understand relates to gitlab's use of the "Let's > Encrypt" certificate authority. Apparently this is a relatively new > authority and is unrecognized by the SSL software on the Ubuntu VM > that Travis provides. I don't know of any workarounds at this time > that can be applied in the VM that to overcome this problem. I also > don't know if anything can be done on the gitlab side to mitigate it > but suspect not. I do have a procedure that allows me to side-step the > problem for my own case and can share that with anyone that needs it. > > Cheers, > > - Ben > > > > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From shayne.fletcher at daml.com Sat Mar 9 17:44:47 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sat, 9 Mar 2019 12:44:47 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: On Sat, Mar 9, 2019 at 11:41 AM Oleg Grenrus wrote: > I can reproduce that problem on Ubuntu 14.04 which Travis uses now by > default. > It's "fixed" in Ubuntu 16.04. Use > > dist: xenial > > and your travis build should proceed. > > Nice! Thanks!! -- 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 mgsloan at gmail.com Sun Mar 10 01:53:33 2019 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 9 Mar 2019 17:53:33 -0800 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: <87wol8pnwp.fsf@smart-cactus.org> References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine: > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Chrome also believes that the certificate of https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows that the certificate is for "gitlab.staging.haskell.org" whereas the domain is "gitlab.haskell.org", so I'm guessing that's the problem. I'm not very experienced with such cert stuff, but perhaps a wildcard cert like "*.haskell.org" could allow using the same cert regardless of whether it's on staging vs prod. For now I've just done "git config --global http.sslverify false" temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky workaround? :) -Michael On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: > > Shayne Fletcher via ghc-devs writes: > > > I appreciate this isn't really "our" problem :) Nonetheless, if there's any > > config we can do on the repo on gitlab, that would be cool. Other URLs > > (like github) for example are fine - something specific to gitlab. > > > I feel like I'm missing something here. I recall you mentioned this in > your previous message but there I'm still lacking crucial context. Can > you offer any additional details? How exactly does it fail? > > In principle there is no reason why cloning from gitlab.haskell.org from > Travis shouldn't work. I'd be happy to fix the issue if there is one but > without knowing more I'm pretty powerless to change the situation. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mgsloan at gmail.com Sun Mar 10 01:58:41 2019 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 9 Mar 2019 17:58:41 -0800 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also trying to use the gitlab.staging.haskell.org cert. I can't get chrome to ignore the cert error because it's using HSTS - HTTP Strict Transport Security. On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan wrote: > > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine: > > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none > > Chrome also believes that the certificate of > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the > "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows > that the certificate is for "gitlab.staging.haskell.org" whereas the > domain is "gitlab.haskell.org", so I'm guessing that's the problem. > I'm not very experienced with such cert stuff, but perhaps a wildcard > cert like "*.haskell.org" could allow using the same cert regardless > of whether it's on staging vs prod. > > For now I've just done "git config --global http.sslverify false" > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky > workaround? :) > > -Michael > > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: > > > > Shayne Fletcher via ghc-devs writes: > > > > > I appreciate this isn't really "our" problem :) Nonetheless, if there's any > > > config we can do on the repo on gitlab, that would be cool. Other URLs > > > (like github) for example are fine - something specific to gitlab. > > > > > I feel like I'm missing something here. I recall you mentioned this in > > your previous message but there I'm still lacking crucial context. Can > > you offer any additional details? How exactly does it fail? > > > > In principle there is no reason why cloning from gitlab.haskell.org from > > Travis shouldn't work. I'd be happy to fix the issue if there is one but > > without knowing more I'm pretty powerless to change the situation. > > > > Cheers, > > > > - Ben > > > > _______________________________________________ > > 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 Sun Mar 10 02:05:14 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 9 Mar 2019 21:05:14 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: I think the public name is pointed to the staging site because the main one is down for the trac to github migration. On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan wrote: > Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also > trying to use the gitlab.staging.haskell.org cert. I can't get chrome > to ignore the cert error because it's using HSTS - HTTP Strict > Transport Security. > > On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan wrote: > > > > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 > machine: > > > > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server > certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt > CRLfile: none > > > > Chrome also believes that the certificate of > > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the > > "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows > > that the certificate is for "gitlab.staging.haskell.org" whereas the > > domain is "gitlab.haskell.org", so I'm guessing that's the problem. > > I'm not very experienced with such cert stuff, but perhaps a wildcard > > cert like "*.haskell.org" could allow using the same cert regardless > > of whether it's on staging vs prod. > > > > For now I've just done "git config --global http.sslverify false" > > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky > > workaround? :) > > > > -Michael > > > > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: > > > > > > Shayne Fletcher via ghc-devs writes: > > > > > > > I appreciate this isn't really "our" problem :) Nonetheless, if > there's any > > > > config we can do on the repo on gitlab, that would be cool. Other > URLs > > > > (like github) for example are fine - something specific to gitlab. > > > > > > > I feel like I'm missing something here. I recall you mentioned this in > > > your previous message but there I'm still lacking crucial context. Can > > > you offer any additional details? How exactly does it fail? > > > > > > In principle there is no reason why cloning from gitlab.haskell.org > from > > > Travis shouldn't work. I'd be happy to fix the issue if there is one > but > > > without knowing more I'm pretty powerless to change the situation. > > > > > > Cheers, > > > > > > - Ben > > > > > > _______________________________________________ > > > 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 mgsloan at gmail.com Sun Mar 10 02:09:20 2019 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 9 Mar 2019 18:09:20 -0800 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: Ah, probably so, thanks! On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery wrote: > > I think the public name is pointed to the staging site because the main one is down for the trac to github migration. > > On Sat, Mar 9, 2019 at 8:59 PM Michael Sloan wrote: >> >> Whoah, I can't get https://ghc.haskell.org/ to load at all - it's also >> trying to use the gitlab.staging.haskell.org cert. I can't get chrome >> to ignore the cert error because it's using HSTS - HTTP Strict >> Transport Security. >> >> On Sat, Mar 9, 2019 at 5:53 PM Michael Sloan wrote: >> > >> > I just encountered this when doing a "git pull" on my Ubuntu 18.04.1 machine: >> > >> > > fatal: unable to access 'https://gitlab.haskell.org/ghc/ghc/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none >> > >> > Chrome also believes that the certificate of >> > https://gitlab.haskell.org/ghc/ghc is invalid and I have to click the >> > "Proceed to ... (unsafe)" link. Chrome's certificate viewer shows >> > that the certificate is for "gitlab.staging.haskell.org" whereas the >> > domain is "gitlab.haskell.org", so I'm guessing that's the problem. >> > I'm not very experienced with such cert stuff, but perhaps a wildcard >> > cert like "*.haskell.org" could allow using the same cert regardless >> > of whether it's on staging vs prod. >> > >> > For now I've just done "git config --global http.sslverify false" >> > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky >> > workaround? :) >> > >> > -Michael >> > >> > On Fri, Mar 8, 2019 at 10:23 PM Ben Gamari wrote: >> > > >> > > Shayne Fletcher via ghc-devs writes: >> > > >> > > > I appreciate this isn't really "our" problem :) Nonetheless, if there's any >> > > > config we can do on the repo on gitlab, that would be cool. Other URLs >> > > > (like github) for example are fine - something specific to gitlab. >> > > > >> > > I feel like I'm missing something here. I recall you mentioned this in >> > > your previous message but there I'm still lacking crucial context. Can >> > > you offer any additional details? How exactly does it fail? >> > > >> > > In principle there is no reason why cloning from gitlab.haskell.org from >> > > Travis shouldn't work. I'd be happy to fix the issue if there is one but >> > > without knowing more I'm pretty powerless to change the situation. >> > > >> > > Cheers, >> > > >> > > - Ben >> > > >> > > _______________________________________________ >> > > 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 From shayne.fletcher at daml.com Sun Mar 10 02:32:06 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sat, 9 Mar 2019 21:32:06 -0500 Subject: git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work In-Reply-To: References: <87wol8pnwp.fsf@smart-cactus.org> Message-ID: On Sat, Mar 9, 2019 at 9:09 PM Michael Sloan wrote: > Ah, probably so, thanks! > > On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery > wrote: > > > > I think the public name is pointed to the staging site because the main > one is down for the trac to github migration. > That's exactly it - been down Sat. I guess it will take as long as it takes! > >>> > For now I've just done "git config --global http.sslverify false" > >> > temporarily to do the pull. Perhaps this is Shayne Fletcher's cheeky > >> > workaround? :) > No, that ain't it :) -- 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 Sun Mar 10 21:38:42 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 10 Mar 2019 17:38:42 -0400 Subject: Trac to GitLab migration underway In-Reply-To: <87tvgcow4d.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org> Message-ID: <87h8caqujm.fsf@smart-cactus.org> Ben Gamari writes: > Hello everyone, > > I have started the process of migrating GHC's Trac content to GitLab. > GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down > until this process has finished. I will post updates as necessary. > Hi everyone, I'm happy to announce that the ticket and issue import processes are now complete and gitlab.haskell.org is back online. There are still a few final steps remaining which I will be carrying out over the next few days: * Put in place redirect logic for Trac ticket and Wiki URLs * Add issue comments showing commit messages, replicating the previous Trac behavior * Migrate the GHC Blog entries * Make the old Trac instance again accessible in read-only mode However, while I do this you should feel free to use gitlab.haskell.org freely. If you notice any issues with the import feel free to open a ticket here [1]. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alexandreR_B at outlook.com Sun Mar 10 21:56:27 2019 From: alexandreR_B at outlook.com (Alexandre Rodrigues) Date: Sun, 10 Mar 2019 21:56:27 +0000 Subject: Trac to GitLab migration underway In-Reply-To: <87h8caqujm.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org>, <87h8caqujm.fsf@smart-cactus.org> Message-ID: Those are great news, I did not expect such a large task with so many avenues for failure to go so well. Thank you for your hard work, Ben and everyone else involved. ________________________________ From: ghc-devs on behalf of Ben Gamari Sent: Sunday, March 10, 2019 9:38:42 PM To: GHC users; GHC developers; Haskell Cafe Subject: Re: Trac to GitLab migration underway Ben Gamari writes: > Hello everyone, > > I have started the process of migrating GHC's Trac content to GitLab. > GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down > until this process has finished. I will post updates as necessary. > Hi everyone, I'm happy to announce that the ticket and issue import processes are now complete and gitlab.haskell.org is back online. There are still a few final steps remaining which I will be carrying out over the next few days: * Put in place redirect logic for Trac ticket and Wiki URLs * Add issue comments showing commit messages, replicating the previous Trac behavior * Migrate the GHC Blog entries * Make the old Trac instance again accessible in read-only mode However, while I do this you should feel free to use gitlab.haskell.org freely. If you notice any issues with the import feel free to open a ticket here [1]. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Sun Mar 10 22:15:55 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sun, 10 Mar 2019 18:15:55 -0400 Subject: Trac to GitLab migration underway In-Reply-To: <87h8caqujm.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: On Sun, Mar 10, 2019 at 5:38 PM Ben Gamari wrote: > Ben Gamari writes: > > > Hello everyone, > > > > I have started the process of migrating GHC's Trac content to GitLab. > > GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down > > until this process has finished. I will post updates as necessary. > > > Hi everyone, > > I'm happy to announce that the ticket and issue import processes are now > complete and gitlab.haskell.org is back online. > [...] Thanks for your hard work! > Cheers, > > - Ben > > > > [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- 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 me at ara.io Sun Mar 10 22:27:24 2019 From: me at ara.io (Ara Adkins) Date: Sun, 10 Mar 2019 22:27:24 +0000 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: <50FD6871-64DD-4926-ACAB-1C417F9FA135@ara.io> Thanks for all the hard work to all involved! I’m very excited for everything to be in one place! _ara > On 10 Mar 2019, at 22:15, Shayne Fletcher via ghc-devs wrote: > > > >> On Sun, Mar 10, 2019 at 5:38 PM Ben Gamari wrote: >> Ben Gamari writes: >> >> > Hello everyone, >> > >> > I have started the process of migrating GHC's Trac content to GitLab. >> > GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down >> > until this process has finished. I will post updates as necessary. >> > >> Hi everyone, >> >> I'm happy to announce that the ticket and issue import processes are now >> complete and gitlab.haskell.org is back online. > [...] > > Thanks for your hard work! > >> Cheers, >> >> - Ben >> >> >> >> [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 11 08:58:53 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Mar 2019 08:58:53 +0000 Subject: Trac to GitLab migration underway In-Reply-To: <87h8caqujm.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: | I'm happy to announce that the ticket and issue import processes are now | complete and gitlab.haskell.org is back online. There are still a few | final steps remaining which I will be carrying out over the next few | days: Great! I'm sure it'll help to have everything in one place. Can I ask * That the old ticket repo be put in read-only mode. I've just modified the old #16344, but I should have modified the new one. * Back on the tickets front, how do I record the test cases(s) for a ticket? * How do I record the MR for a ticket? (When it has one.) * That the banner (on the wiki at least) saying "This site has been deprecated and is in read-only mode" should describe how to get to the corresponding URL on the new wiki. Eg. say "If you are trying to access https://ghc.haskell.org/trac/ghc/wiki/, the new URL is "https://gitlab.haskell.org/ghc/ghc/wikis/". * Where has https://ghc.haskell.org/trac/ghc/wiki/RichardAndSimon gone? The corresponding URL on the new wiki doesn't exist. * How can I list the title index on the new wiki? * I have lots of pages like this one https://gitlab.haskell.org/ghc/ghc/wikis/proposal/custom-type-errors that list the tickets relevant to a particular keyword. (Now "label" I think?) But tat page is now lying: it claims to list current open tickets, but actually it's a frozen snapshot. What should I do? Thanks Simon | I'm happy to announce that the ticket and issue import processes are now | complete and gitlab.haskell.org is back online. There are still a few | final steps remaining which I will be carrying out over the next few | days: | | * Put in place redirect logic for Trac ticket and Wiki URLs | | * Add issue comments showing commit messages, replicating the previous | Trac behavior | | * Migrate the GHC Blog entries | | * Make the old Trac instance again accessible in read-only mode | | However, while I do this you should feel free to use gitlab.haskell.org | freely. | If you notice any issues with the import feel free to open a ticket here | [1]. | | Cheers, | | - Ben | | | | [1] | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fbgamari%2Fgitlab- | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce7f7334 | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878 | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo0sk4%3 | D&reserved=0 From matthewtpickering at gmail.com Mon Mar 11 09:37:24 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 11 Mar 2019 09:37:24 +0000 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: > * That the old ticket repo be put in read-only mode. I've just modified the old #16344, but I should have modified the new one. That is tracked https://gitlab.haskell.org/bgamari/gitlab-migration/issues/14 It seems that there are still some problems to iron out though. > * Back on the tickets front, how do I record the test cases(s) for a ticket? I don't believe there is a way other than via the commit referencing the ticket. > > * How do I record the MR for a ticket? (When it has one.) When you mention a ticket in a MR then a reference should be created from it to the ticket. For example, when I mentioned !509 on this ticket it now displays in the UI. https://gitlab.haskell.org/ghc/ghc/issues/16417 > > * That the banner (on the wiki at least) saying "This site has been deprecated and is in read-only mode" should describe how to get to the corresponding URL on the new wiki. Eg. say "If you are trying to access https://ghc.haskell.org/trac/ghc/wiki/, the new URL is "https://gitlab.haskell.org/ghc/ghc/wikis/". > > * Where has https://ghc.haskell.org/trac/ghc/wiki/RichardAndSimon gone? The corresponding URL on the new wiki doesn't exist. The page is now located at: https://gitlab.haskell.org/ghc/ghc/wikis/richard-and-simon > > * How can I list the title index on the new wiki? An automatically generated index is available here https://gitlab.haskell.org/ghc/ghc/wikis/index I believe the intention is to automatically update this with a cronjob. > > * I have lots of pages like this one https://gitlab.haskell.org/ghc/ghc/wikis/proposal/custom-type-errors that list the tickets relevant to a particular keyword. (Now "label" I think?) But tat page is now lying: it claims to list current open tickets, but actually it's a frozen snapshot. What should I do? Gitlab Wiki does not support this feature so you have to refer to a custom search. For example: https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=ApplicativeDo However, it seems that the `CustomTypeErrors` label was lost during the migration. Do you know why this is Tobias/Ben? It looks like it will have to be added back manually. > > Thanks > > Simon > > | I'm happy to announce that the ticket and issue import processes are now > | complete and gitlab.haskell.org is back online. There are still a few > | final steps remaining which I will be carrying out over the next few > | days: > | > | * Put in place redirect logic for Trac ticket and Wiki URLs > | > | * Add issue comments showing commit messages, replicating the previous > | Trac behavior > | > | * Migrate the GHC Blog entries > | > | * Make the old Trac instance again accessible in read-only mode > | > | However, while I do this you should feel free to use gitlab.haskell.org > | freely. > | If you notice any issues with the import feel free to open a ticket here > | [1]. > | > | Cheers, > | > | - Ben > | > | > | > | [1] > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fbgamari%2Fgitlab- > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce7f7334 > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878 > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo0sk4%3 > | D&reserved=0 > _______________________________________________ > 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 Mar 11 10:14:04 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Mar 2019 10:14:04 +0000 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: | > * Back on the tickets front, how do I record the test cases(s) for a | ticket? | | I don't believe there is a way other than via the commit referencing the | ticket. That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? | > * How do I record the MR for a ticket? (When it has one.) | | When you mention a ticket in a MR then a reference should be created from | it to the ticket. | | For example, when I mentioned !509 on this ticket it now displays in the | UI. I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? Or is it another discipline we could impose on ourselves? Simon | -----Original Message----- | From: Matthew Pickering | Sent: 11 March 2019 09:37 | To: Simon Peyton Jones | Cc: Ben Gamari ; GHC developers | Subject: Re: Trac to GitLab migration underway | | > * That the old ticket repo be put in read-only mode. I've just modified | the old #16344, but I should have modified the new one. | | That is tracked | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fbgamari%2Fgitlab- | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356 | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By | CdI%3D&reserved=0 | | It seems that there are still some problems to iron out though. | | > * Back on the tickets front, how do I record the test cases(s) for a | ticket? | | I don't believe there is a way other than via the commit referencing the | ticket. | | > | > * How do I record the MR for a ticket? (When it has one.) | | When you mention a ticket in a MR then a reference should be created from | it to the ticket. | | For example, when I mentioned !509 on this ticket it now displays in the | UI. | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro | soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P | FJpNt6nkr%2BObzRAmk%3D&reserved=0 | | > | > * That the banner (on the wiki at least) saying "This site has been | deprecated and is in read-only mode" should describe how to get to the | corresponding URL on the new wiki. Eg. say "If you are trying to access | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com% | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM | 1UyIq4%3D&reserved=0, the new URL is | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. | haskell.org%2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb | BUo5ABhqVo%3D&reserved=0". | > | > * Where has | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 | 0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the | new wiki doesn't exist. | | The page is now located at: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- | simon&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= | 0 | | > | > * How can I list the title index on the new wiki? | | An automatically generated index is available here | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros | oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T | D4DGorbNyz28%3D&reserved=0 | | I believe the intention is to automatically update this with a cronjob. | | > | > * I have lots of pages like this one | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- | errors&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008 | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 | that list the tickets relevant to a particular keyword. (Now "label" I | think?) But tat page is now lying: it claims to list current open | tickets, but actually it's a frozen snapshot. What should I do? | | Gitlab Wiki does not support this feature so you have to refer to a custom | search. | | For example: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& | ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319 | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 | | However, it seems that the `CustomTypeErrors` label was lost during the | migration. Do you know why this is Tobias/Ben? It looks like it will have | to be added back manually. | | > | > Thanks | > | > Simon | > | > | I'm happy to announce that the ticket and issue import processes | > | are now complete and gitlab.haskell.org is back online. There are | > | still a few final steps remaining which I will be carrying out over | > | the next few | > | days: | > | | > | * Put in place redirect logic for Trac ticket and Wiki URLs | > | | > | * Add issue comments showing commit messages, replicating the | previous | > | Trac behavior | > | | > | * Migrate the GHC Blog entries | > | | > | * Make the old Trac instance again accessible in read-only mode | > | | > | However, while I do this you should feel free to use | > | gitlab.haskell.org freely. | > | If you notice any issues with the import feel free to open a ticket | > | here [1]. | > | | > | Cheers, | > | | > | - Ben | > | | > | | > | | > | [1] | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | tlab.h | > | askell.org%2Fbgamari%2Fgitlab- | > | | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce | > | 7f7334 | > | | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | > | 636878 | > | | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo | > | 0sk4%3 | > | D&reserved=0 | > _______________________________________________ | > 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%7Cac356d50797a44abf82008d6a6053319%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 From simonpj at microsoft.com Mon Mar 11 10:17:28 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Mar 2019 10:17:28 +0000 Subject: Search on gitlab Message-ID: I searched for captureTopConstraints on GitLab, using the search box at the top. But it found nothing. And yet here it is https://gitlab.haskell.org/ghc/ghc/merge_requests/508 What am I doing wrong? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Mar 11 10:17:25 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 11 Mar 2019 10:17:25 +0000 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: I wrote !509 in the ticket which then made gitlab display the "Related Merge Request" bit underneath. I don't know what happens if you mention a MR in a comment. On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones wrote: > > | > * Back on the tickets front, how do I record the test cases(s) for a > | ticket? > | > | I don't believe there is a way other than via the commit referencing the > | ticket. > > That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. > > Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? > > | > * How do I record the MR for a ticket? (When it has one.) > | > | When you mention a ticket in a MR then a reference should be created from > | it to the ticket. > | > | For example, when I mentioned !509 on this ticket it now displays in the > | UI. > > I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? > > Or is it another discipline we could impose on ourselves? > > Simon > > | -----Original Message----- > | From: Matthew Pickering > | Sent: 11 March 2019 09:37 > | To: Simon Peyton Jones > | Cc: Ben Gamari ; GHC developers > | Subject: Re: Trac to GitLab migration underway > | > | > * That the old ticket repo be put in read-only mode. I've just modified > | the old #16344, but I should have modified the new one. > | > | That is tracked > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fbgamari%2Fgitlab- > | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356 > | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 > | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By > | CdI%3D&reserved=0 > | > | It seems that there are still some problems to iron out though. > | > | > * Back on the tickets front, how do I record the test cases(s) for a > | ticket? > | > | I don't believe there is a way other than via the commit referencing the > | ticket. > | > | > > | > * How do I record the MR for a ticket? (When it has one.) > | > | When you mention a ticket in a MR then a reference should be created from > | it to the ticket. > | > | For example, when I mentioned !509 on this ticket it now displays in the > | UI. > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro > | soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 > | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P > | FJpNt6nkr%2BObzRAmk%3D&reserved=0 > | > | > > | > * That the banner (on the wiki at least) saying "This site has been > | deprecated and is in read-only mode" should describe how to get to the > | corresponding URL on the new wiki. Eg. say "If you are trying to access > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com% > | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% > | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM > | 1UyIq4%3D&reserved=0, the new URL is > | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. > | haskell.org%2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. > | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% > | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb > | BUo5ABhqVo%3D&reserved=0". > | > > | > * Where has > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > | ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 > | 0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d > | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu > | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the > | new wiki doesn't exist. > | > | The page is now located at: > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- > | simon&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d > | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& > | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= > | 0 > | > | > > | > * How can I list the title index on the new wiki? > | > | An automatically generated index is available here > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros > | oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d > | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T > | D4DGorbNyz28%3D&reserved=0 > | > | I believe the intention is to automatically update this with a cronjob. > | > | > > | > * I have lots of pages like this one > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- > | errors&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008 > | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 > | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 > | that list the tickets relevant to a particular keyword. (Now "label" I > | think?) But tat page is now lying: it claims to list current open > | tickets, but actually it's a frozen snapshot. What should I do? > | > | Gitlab Wiki does not support this feature so you have to refer to a custom > | search. > | > | For example: > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& > | ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319 > | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata > | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 > | > | However, it seems that the `CustomTypeErrors` label was lost during the > | migration. Do you know why this is Tobias/Ben? It looks like it will have > | to be added back manually. > | > | > > | > Thanks > | > > | > Simon > | > > | > | I'm happy to announce that the ticket and issue import processes > | > | are now complete and gitlab.haskell.org is back online. There are > | > | still a few final steps remaining which I will be carrying out over > | > | the next few > | > | days: > | > | > | > | * Put in place redirect logic for Trac ticket and Wiki URLs > | > | > | > | * Add issue comments showing commit messages, replicating the > | previous > | > | Trac behavior > | > | > | > | * Migrate the GHC Blog entries > | > | > | > | * Make the old Trac instance again accessible in read-only mode > | > | > | > | However, while I do this you should feel free to use > | > | gitlab.haskell.org freely. > | > | If you notice any issues with the import feel free to open a ticket > | > | here [1]. > | > | > | > | Cheers, > | > | > | > | - Ben > | > | > | > | > | > | > | > | [1] > | > | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > | > | tlab.h > | > | askell.org%2Fbgamari%2Fgitlab- > | > | > | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce > | > | 7f7334 > | > | > | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C > | > | 636878 > | > | > | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo > | > | 0sk4%3 > | > | D&reserved=0 > | > _______________________________________________ > | > 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%7Cac356d50797a44abf82008d6a6053319%7C72f988 > | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq > | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 From matthewtpickering at gmail.com Mon Mar 11 10:18:35 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 11 Mar 2019 10:18:35 +0000 Subject: Search on gitlab In-Reply-To: References: Message-ID: Which search box did you use? It appears for me. https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=captureTopConstraints&group_id=&project_id=1&scope=merge_requests&repository_ref= On Mon, Mar 11, 2019 at 10:17 AM Simon Peyton Jones via ghc-devs wrote: > > I searched for captureTopConstraints on GitLab, using the search box at the top. But it found nothing. > > > > And yet here it is https://gitlab.haskell.org/ghc/ghc/merge_requests/508 > > > > What am I doing wrong? > > > 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 Mon Mar 11 11:23:01 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Mar 2019 11:23:01 +0000 Subject: Search on gitlab In-Reply-To: References: Message-ID: I typed the query into the search box on the top black menu bar. The box has the encouraging text "search or jump to". https://gitlab.haskell.org/search?group_id=&project_id=&repository_ref=&scope=projects&search=capturetopconstraints Ah.... now I see that it's displaying a "projects" tab. In BOLD LETTERS the page says "We couldn't find any results matching capturetopconstraints". But there is a quiet grey "merge requests" tab that indeed shows the MR. Ha! That's subtle! Even more oddly, when I did the same thing again (from somewhere else) I got this https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=captureTopConstraints&group_id=&project_id=1&scope=wiki_blobs&repository_ref= Note it displays "Code", "Commits" and "Comments" tabs which it did not before. In that second page it looks as if the "project" filter is set to GHC. But if actually pick GHC from the project-filter menu I get no results. Well, I picked "Project: Glasgow Haskell Compiler/ci-images" whatever that is? But there /is/ no plain GHC project in the list! When I get more results like this: https://gitlab.haskell.org/search?project_id=1&scope=notes&search=stub+binding how are the results sorted? Can I sort them most-recent first? Thanks Simon | -----Original Message----- | From: Matthew Pickering | Sent: 11 March 2019 10:19 | To: Simon Peyton Jones | Cc: GHC developers | Subject: Re: Search on gitlab | | Which search box did you use? It appears for me. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fsearch%3Futf8%3D%25E2%259C%2593%26search%3DcaptureTopConstrai | nts%26group_id%3D%26project_id%3D1%26scope%3Dmerge_requests%26repository_r | ef&data=02%7C01%7Csimonpj%40microsoft.com%7Cd6f130325d1b4641570208d6a6 | 0af46b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708& | ;sdata=pW9%2Fu6XwR9MUxHDVaHzVmHz4sdICeOUVx5a92ItG4f4%3D&reserved=0= | | On Mon, Mar 11, 2019 at 10:17 AM Simon Peyton Jones via ghc-devs wrote: | > | > I searched for captureTopConstraints on GitLab, using the search box at | the top. But it found nothing. | > | > | > | > And yet here it is | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F508&data=02%7C01%7Cs | > imonpj%40microsoft.com%7Cd6f130325d1b4641570208d6a60af46b%7C72f988bf86 | > f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708&sdata=7OWEef4q | > 1ccSiKV1DFWkndz2XT6gpy%2BD5sbuphUxCQA%3D&reserved=0 | > | > | > | > What am I doing wrong? | > | > | > 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%7Cd6f130325d1b4641570208d6a60af46b%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708&sdata=OdHS | > SX6KLIX4oqGoKnCYOZ3hXrFHLYNUpCMwKfl2Jz0%3D&reserved=0 From rae at cs.brynmawr.edu Mon Mar 11 13:12:04 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 11 Mar 2019 09:12:04 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Thanks to all who have made this happen. Looking forward to having everything in one place! Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow. I'd also like to second Simon's request, in particular, of having a clear path from an issue to an MR. Getting from an MR to an issue is normally easier -- when the MR is created, most devs would automatically mention the issue number somewhere in the description -- but going from an issue to an MR is harder. It would be a shame to have to search through the commentary looking for the link. I used the old "Phab:D1234" links in the top of a Trac ticket quite often. I also second the request for a test-case field. This field, to me, is most useful as a reminder to the author that they need to add a test case. But I think the issue-to-MR link is more important than the test-case field. Thanks! Richard > On Mar 11, 2019, at 6:17 AM, Matthew Pickering wrote: > > I wrote !509 in the ticket which then made gitlab display the "Related > Merge Request" bit underneath. I don't know what happens if you > mention a MR in a comment. > > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones > wrote: >> >> | > * Back on the tickets front, how do I record the test cases(s) for a >> | ticket? >> | >> | I don't believe there is a way other than via the commit referencing the >> | ticket. >> >> That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. >> >> Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? >> >> | > * How do I record the MR for a ticket? (When it has one.) >> | >> | When you mention a ticket in a MR then a reference should be created from >> | it to the ticket. >> | >> | For example, when I mentioned !509 on this ticket it now displays in the >> | UI. >> >> I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? >> >> Or is it another discipline we could impose on ourselves? >> >> Simon >> >> | -----Original Message----- >> | From: Matthew Pickering >> | Sent: 11 March 2019 09:37 >> | To: Simon Peyton Jones >> | Cc: Ben Gamari ; GHC developers >> | Subject: Re: Trac to GitLab migration underway >> | >> | > * That the old ticket repo be put in read-only mode. I've just modified >> | the old #16344, but I should have modified the new one. >> | >> | That is tracked >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fbgamari%2Fgitlab- >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356 >> | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >> | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By >> | CdI%3D&reserved=0 >> | >> | It seems that there are still some problems to iron out though. >> | >> | > * Back on the tickets front, how do I record the test cases(s) for a >> | ticket? >> | >> | I don't believe there is a way other than via the commit referencing the >> | ticket. >> | >> | > >> | > * How do I record the MR for a ticket? (When it has one.) >> | >> | When you mention a ticket in a MR then a reference should be created from >> | it to the ticket. >> | >> | For example, when I mentioned !509 on this ticket it now displays in the >> | UI. >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro >> | soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 >> | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 >> | >> | > >> | > * That the banner (on the wiki at least) saying "This site has been >> | deprecated and is in read-only mode" should describe how to get to the >> | corresponding URL on the new wiki. Eg. say "If you are trying to access >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com% >> | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM >> | 1UyIq4%3D&reserved=0, the new URL is >> | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. >> | haskell.org%2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. >> | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% >> | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb >> | BUo5ABhqVo%3D&reserved=0". >> | > >> | > * Where has >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> | ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 >> | 0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d >> | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the >> | new wiki doesn't exist. >> | >> | The page is now located at: >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- >> | simon&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d >> | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& >> | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= >> | 0 >> | >> | > >> | > * How can I list the title index on the new wiki? >> | >> | An automatically generated index is available here >> | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros >> | oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d >> | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T >> | D4DGorbNyz28%3D&reserved=0 >> | >> | I believe the intention is to automatically update this with a cronjob. >> | >> | > >> | > * I have lots of pages like this one >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- >> | errors&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008 >> | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 >> | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 >> | that list the tickets relevant to a particular keyword. (Now "label" I >> | think?) But tat page is now lying: it claims to list current open >> | tickets, but actually it's a frozen snapshot. What should I do? >> | >> | Gitlab Wiki does not support this feature so you have to refer to a custom >> | search. >> | >> | For example: >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& >> | ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319 >> | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 >> | >> | However, it seems that the `CustomTypeErrors` label was lost during the >> | migration. Do you know why this is Tobias/Ben? It looks like it will have >> | to be added back manually. >> | >> | > >> | > Thanks >> | > >> | > Simon >> | > >> | > | I'm happy to announce that the ticket and issue import processes >> | > | are now complete and gitlab.haskell.org is back online. There are >> | > | still a few final steps remaining which I will be carrying out over >> | > | the next few >> | > | days: >> | > | >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs >> | > | >> | > | * Add issue comments showing commit messages, replicating the >> | previous >> | > | Trac behavior >> | > | >> | > | * Migrate the GHC Blog entries >> | > | >> | > | * Make the old Trac instance again accessible in read-only mode >> | > | >> | > | However, while I do this you should feel free to use >> | > | gitlab.haskell.org freely. >> | > | If you notice any issues with the import feel free to open a ticket >> | > | here [1]. >> | > | >> | > | Cheers, >> | > | >> | > | - Ben >> | > | >> | > | >> | > | >> | > | [1] >> | > | >> | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >> | > | tlab.h >> | > | askell.org%2Fbgamari%2Fgitlab- >> | > | >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce >> | > | 7f7334 >> | > | >> | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >> | > | 636878 >> | > | >> | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo >> | > | 0sk4%3 >> | > | D&reserved=0 >> | > _______________________________________________ >> | > 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%7Cac356d50797a44abf82008d6a6053319%7C72f988 >> | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 > _______________________________________________ > 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 Mon Mar 11 14:25:23 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 11 Mar 2019 10:25:23 -0400 Subject: Trac to GitLab migration underway In-Reply-To: <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: Hello, I just wanted to thank Ben and everyone involved for this transition. And also reiterate Richard's point about having !123 / #12345 in the front of mail subjects — I think, this is small but quite important detail to ease navigating the flow of notifications. -- Best regards, Artem On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg wrote: > Thanks to all who have made this happen. Looking forward to having > everything in one place! > > Do we have any ability to edit the formatting of subject lines of ticket > emails? It would be great if we could get the (!234) or (#12345) up front, > as this is the effective summary of what's to follow. > > I'd also like to second Simon's request, in particular, of having a clear > path from an issue to an MR. Getting from an MR to an issue is normally > easier -- when the MR is created, most devs would automatically mention the > issue number somewhere in the description -- but going from an issue to an > MR is harder. It would be a shame to have to search through the commentary > looking for the link. I used the old "Phab:D1234" links in the top of a > Trac ticket quite often. > > I also second the request for a test-case field. This field, to me, is > most useful as a reminder to the author that they need to add a test case. > But I think the issue-to-MR link is more important than the test-case field. > > Thanks! > Richard > > > On Mar 11, 2019, at 6:17 AM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > > > I wrote !509 in the ticket which then made gitlab display the "Related > > Merge Request" bit underneath. I don't know what happens if you > > mention a MR in a comment. > > > > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones > > wrote: > >> > >> | > * Back on the tickets front, how do I record the test cases(s) for > a > >> | ticket? > >> | > >> | I don't believe there is a way other than via the commit referencing > the > >> | ticket. > >> > >> That's sad. It's a useful discipline to fill in that field before > closing the ticket. And it's useful later when looking for the test cases > for the ticket. > >> > >> Is this just a straight loss, or is there a longer term plan to recover > it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment > that lists the test cases (and does nothing else) before closing an issue? > >> > >> | > * How do I record the MR for a ticket? (When it has one.) > >> | > >> | When you mention a ticket in a MR then a reference should be created > from > >> | it to the ticket. > >> | > >> | For example, when I mentioned !509 on this ticket it now displays in > the > >> | UI. > >> > >> I don't get it. You manually added "Corresponding MR !509" to the > issue Description. Or are you saying that that apparently-user-written > line was added by GitLab? If you have many MRs taht mention (perhaps en > passant) the same issue, will there be many such lines? > >> > >> Or is it another discipline we could impose on ourselves? > >> > >> Simon > >> > >> | -----Original Message----- > >> | From: Matthew Pickering > >> | Sent: 11 March 2019 09:37 > >> | To: Simon Peyton Jones > >> | Cc: Ben Gamari ; GHC developers < > ghc-devs at haskell.org> > >> | Subject: Re: Trac to GitLab migration underway > >> | > >> | > * That the old ticket repo be put in read-only mode. I've just > modified > >> | the old #16344, but I should have modified the new one. > >> | > >> | That is tracked > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org%2Fbgamari%2Fgitlab- > >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com > %7Cac356 > >> | > d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 > >> | > 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By > >> | CdI%3D&reserved=0 > >> | > >> | It seems that there are still some problems to iron out though. > >> | > >> | > * Back on the tickets front, how do I record the test cases(s) for > a > >> | ticket? > >> | > >> | I don't believe there is a way other than via the commit referencing > the > >> | ticket. > >> | > >> | > > >> | > * How do I record the MR for a ticket? (When it has one.) > >> | > >> | When you mention a ticket in a MR then a reference should be created > from > >> | it to the ticket. > >> | > >> | For example, when I mentioned !509 on this ticket it now displays in > the > >> | UI. > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org > %2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro > >> | soft.com > %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 > >> | > db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P > >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 > >> | > >> | > > >> | > * That the banner (on the wiki at least) saying "This site has been > >> | deprecated and is in read-only mode" should describe how to get to > the > >> | corresponding URL on the new wiki. Eg. say "If you are trying to > access > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > >> | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj% > 40microsoft.com% > >> | > 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% > >> | > 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM > >> | 1UyIq4%3D&reserved=0, the new URL is > >> | " > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. > >> | haskell.org > %2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. > >> | > com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% > >> | > 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb > >> | BUo5ABhqVo%3D&reserved=0". > >> | > > >> | > * Where has > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > >> | ell.org > %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 > >> | 0microsoft.com > %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d > >> | > 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu > >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL > on the > >> | new wiki doesn't exist. > >> | > >> | The page is now located at: > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- > >> | simon&data=02%7C01%7Csimonpj%40microsoft.com > %7Cac356d50797a44abf82008d > >> | > 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& > >> | > amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= > >> | 0 > >> | > >> | > > >> | > * How can I list the title index on the new wiki? > >> | > >> | An automatically generated index is available here > >> | > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org > %2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros > >> | oft.com > %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d > >> | > b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T > >> | D4DGorbNyz28%3D&reserved=0 > >> | > >> | I believe the intention is to automatically update this with a > cronjob. > >> | > >> | > > >> | > * I have lots of pages like this one > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- > >> | errors&data=02%7C01%7Csimonpj%40microsoft.com > %7Cac356d50797a44abf82008 > >> | > d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 > >> | > &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 > >> | that list the tickets relevant to a particular keyword. (Now > "label" I > >> | think?) But tat page is now lying: it claims to list current open > >> | tickets, but actually it's a frozen snapshot. What should I do? > >> | > >> | Gitlab Wiki does not support this feature so you have to refer to a > custom > >> | search. > >> | > >> | For example: > >> | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org > %2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& > >> | ;data=02%7C01%7Csimonpj%40microsoft.com > %7Cac356d50797a44abf82008d6a6053319 > >> | > %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata > >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 > >> | > >> | However, it seems that the `CustomTypeErrors` label was lost during > the > >> | migration. Do you know why this is Tobias/Ben? It looks like it will > have > >> | to be added back manually. > >> | > >> | > > >> | > Thanks > >> | > > >> | > Simon > >> | > > >> | > | I'm happy to announce that the ticket and issue import processes > >> | > | are now complete and gitlab.haskell.org is back online. There > are > >> | > | still a few final steps remaining which I will be carrying out > over > >> | > | the next few > >> | > | days: > >> | > | > >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs > >> | > | > >> | > | * Add issue comments showing commit messages, replicating the > >> | previous > >> | > | Trac behavior > >> | > | > >> | > | * Migrate the GHC Blog entries > >> | > | > >> | > | * Make the old Trac instance again accessible in read-only mode > >> | > | > >> | > | However, while I do this you should feel free to use > >> | > | gitlab.haskell.org freely. > >> | > | If you notice any issues with the import feel free to open a > ticket > >> | > | here [1]. > >> | > | > >> | > | Cheers, > >> | > | > >> | > | - Ben > >> | > | > >> | > | > >> | > | > >> | > | [1] > >> | > | > >> | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >> | > | tlab.h > >> | > | askell.org%2Fbgamari%2Fgitlab- > >> | > | > >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com > %7C48ce > >> | > | 7f7334 > >> | > | > >> | > | > c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C > >> | > | 636878 > >> | > | > >> | > | > 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo > >> | > | 0sk4%3 > >> | > | D&reserved=0 > >> | > _______________________________________________ > >> | > 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 > %7Cac356d50797a44abf82008d6a6053319%7C72f988 > >> | > > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq > >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 > > _______________________________________________ > > 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 rae at cs.brynmawr.edu Mon Mar 11 15:55:56 2019 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 11 Mar 2019 11:55:56 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: This old ticket might be related: https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 It advocates for moving numbers to the front of tab names, too. Looks like it was shut down by judgment call. Perhaps if we raise our voices in chorus against this decision, we can get some action (or a new configuration switch). > On Mar 11, 2019, at 10:25 AM, Artem Pelenitsyn wrote: > > Hello, > > I just wanted to thank Ben and everyone involved for this transition. And also reiterate Richard's point about having !123 / #12345 in the front of mail subjects — I think, this is small but quite important detail to ease navigating the flow of notifications. > > -- > Best regards, > Artem > > On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg > wrote: > Thanks to all who have made this happen. Looking forward to having everything in one place! > > Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow. > > I'd also like to second Simon's request, in particular, of having a clear path from an issue to an MR. Getting from an MR to an issue is normally easier -- when the MR is created, most devs would automatically mention the issue number somewhere in the description -- but going from an issue to an MR is harder. It would be a shame to have to search through the commentary looking for the link. I used the old "Phab:D1234" links in the top of a Trac ticket quite often. > > I also second the request for a test-case field. This field, to me, is most useful as a reminder to the author that they need to add a test case. But I think the issue-to-MR link is more important than the test-case field. > > Thanks! > Richard > > > On Mar 11, 2019, at 6:17 AM, Matthew Pickering > wrote: > > > > I wrote !509 in the ticket which then made gitlab display the "Related > > Merge Request" bit underneath. I don't know what happens if you > > mention a MR in a comment. > > > > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones > > > wrote: > >> > >> | > * Back on the tickets front, how do I record the test cases(s) for a > >> | ticket? > >> | > >> | I don't believe there is a way other than via the commit referencing the > >> | ticket. > >> > >> That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. > >> > >> Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? > >> > >> | > * How do I record the MR for a ticket? (When it has one.) > >> | > >> | When you mention a ticket in a MR then a reference should be created from > >> | it to the ticket. > >> | > >> | For example, when I mentioned !509 on this ticket it now displays in the > >> | UI. > >> > >> I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? > >> > >> Or is it another discipline we could impose on ourselves? > >> > >> Simon > >> > >> | -----Original Message----- > >> | From: Matthew Pickering > > >> | Sent: 11 March 2019 09:37 > >> | To: Simon Peyton Jones > > >> | Cc: Ben Gamari >; GHC developers > > >> | Subject: Re: Trac to GitLab migration underway > >> | > >> | > * That the old ticket repo be put in read-only mode. I've just modified > >> | the old #16344, but I should have modified the new one. > >> | > >> | That is tracked > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fbgamari%2Fgitlab- > >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356 > >> | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 > >> | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By > >> | CdI%3D&reserved=0 > >> | > >> | It seems that there are still some problems to iron out though. > >> | > >> | > * Back on the tickets front, how do I record the test cases(s) for a > >> | ticket? > >> | > >> | I don't believe there is a way other than via the commit referencing the > >> | ticket. > >> | > >> | > > >> | > * How do I record the MR for a ticket? (When it has one.) > >> | > >> | When you mention a ticket in a MR then a reference should be created from > >> | it to the ticket. > >> | > >> | For example, when I mentioned !509 on this ticket it now displays in the > >> | UI. > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro > >> | soft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 > >> | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P > >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 > >> | > >> | > > >> | > * That the banner (on the wiki at least) saying "This site has been > >> | deprecated and is in read-only mode" should describe how to get to the > >> | corresponding URL on the new wiki. Eg. say "If you are trying to access > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > >> | ell.org %2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com % > >> | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% > >> | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM > >> | 1UyIq4%3D&reserved=0, the new URL is > >> | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab . > >> | haskell.org %2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. > >> | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% > >> | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb > >> | BUo5ABhqVo%3D&reserved=0". > >> | > > >> | > * Where has > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask > >> | ell.org %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 > >> | 0microsoft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d > >> | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu > >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the > >> | new wiki doesn't exist. > >> | > >> | The page is now located at: > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fghc%2Fghc%2Fwikis%2Frichard-and- > >> | simon&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008d > >> | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& > >> | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= > >> | 0 > >> | > >> | > > >> | > * How can I list the title index on the new wiki? > >> | > >> | An automatically generated index is available here > >> | > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros > >> | oft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d > >> | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T > >> | D4DGorbNyz28%3D&reserved=0 > >> | > >> | I believe the intention is to automatically update this with a cronjob. > >> | > >> | > > >> | > * I have lots of pages like this one > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- > >> | errors&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008 > >> | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 > >> | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 > >> | that list the tickets relevant to a particular keyword. (Now "label" I > >> | think?) But tat page is now lying: it claims to list current open > >> | tickets, but actually it's a frozen snapshot. What should I do? > >> | > >> | Gitlab Wiki does not support this feature so you have to refer to a custom > >> | search. > >> | > >> | For example: > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > >> | askell.org %2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& > >> | ;data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008d6a6053319 > >> | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata > >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 > >> | > >> | However, it seems that the `CustomTypeErrors` label was lost during the > >> | migration. Do you know why this is Tobias/Ben? It looks like it will have > >> | to be added back manually. > >> | > >> | > > >> | > Thanks > >> | > > >> | > Simon > >> | > > >> | > | I'm happy to announce that the ticket and issue import processes > >> | > | are now complete and gitlab.haskell.org is back online. There are > >> | > | still a few final steps remaining which I will be carrying out over > >> | > | the next few > >> | > | days: > >> | > | > >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs > >> | > | > >> | > | * Add issue comments showing commit messages, replicating the > >> | previous > >> | > | Trac behavior > >> | > | > >> | > | * Migrate the GHC Blog entries > >> | > | > >> | > | * Make the old Trac instance again accessible in read-only mode > >> | > | > >> | > | However, while I do this you should feel free to use > >> | > | gitlab.haskell.org freely. > >> | > | If you notice any issues with the import feel free to open a ticket > >> | > | here [1]. > >> | > | > >> | > | Cheers, > >> | > | > >> | > | - Ben > >> | > | > >> | > | > >> | > | > >> | > | [1] > >> | > | > >> | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >> | > | tlab.h > >> | > | askell.org %2Fbgamari%2Fgitlab- > >> | > | > >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com %7C48ce > >> | > | 7f7334 > >> | > | > >> | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C > >> | > | 636878 > >> | > | > >> | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo > >> | > | 0sk4%3 > >> | > | D&reserved=0 > >> | > _______________________________________________ > >> | > 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 %7Cac356d50797a44abf82008d6a6053319%7C72f988 > >> | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq > >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 > > _______________________________________________ > > 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 a.pelenitsyn at gmail.com Mon Mar 11 17:54:51 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 11 Mar 2019 13:54:51 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: Hi Richard, Good catch! What troubles me in that issue, is (subjectively) the passive-aggressive form of the initial post. Given that it is email that we are worrying about, not the browser tabs, maybe it is better to start over with a new issue referencing that one in passing. -- Best, Artem On Mon, 11 Mar 2019 at 11:56 Richard Eisenberg wrote: > This old ticket might be related: > https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 It advocates for > moving numbers to the front of tab names, too. Looks like it was shut down > by judgment call. Perhaps if we raise our voices in chorus against this > decision, we can get some action (or a new configuration switch). > > On Mar 11, 2019, at 10:25 AM, Artem Pelenitsyn > wrote: > > Hello, > > I just wanted to thank Ben and everyone involved for this transition. And > also reiterate Richard's point about having !123 / #12345 in the front of > mail subjects — I think, this is small but quite important detail to ease > navigating the flow of notifications. > > -- > Best regards, > Artem > > On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg > wrote: > >> Thanks to all who have made this happen. Looking forward to having >> everything in one place! >> >> Do we have any ability to edit the formatting of subject lines of ticket >> emails? It would be great if we could get the (!234) or (#12345) up front, >> as this is the effective summary of what's to follow. >> >> I'd also like to second Simon's request, in particular, of having a clear >> path from an issue to an MR. Getting from an MR to an issue is normally >> easier -- when the MR is created, most devs would automatically mention the >> issue number somewhere in the description -- but going from an issue to an >> MR is harder. It would be a shame to have to search through the commentary >> looking for the link. I used the old "Phab:D1234" links in the top of a >> Trac ticket quite often. >> >> I also second the request for a test-case field. This field, to me, is >> most useful as a reminder to the author that they need to add a test case. >> But I think the issue-to-MR link is more important than the test-case field. >> >> Thanks! >> Richard >> >> > On Mar 11, 2019, at 6:17 AM, Matthew Pickering < >> matthewtpickering at gmail.com> wrote: >> > >> > I wrote !509 in the ticket which then made gitlab display the "Related >> > Merge Request" bit underneath. I don't know what happens if you >> > mention a MR in a comment. >> > >> > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones >> > wrote: >> >> >> >> | > * Back on the tickets front, how do I record the test cases(s) >> for a >> >> | ticket? >> >> | >> >> | I don't believe there is a way other than via the commit >> referencing the >> >> | ticket. >> >> >> >> That's sad. It's a useful discipline to fill in that field before >> closing the ticket. And it's useful later when looking for the test cases >> for the ticket. >> >> >> >> Is this just a straight loss, or is there a longer term plan to >> recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a >> comment that lists the test cases (and does nothing else) before closing an >> issue? >> >> >> >> | > * How do I record the MR for a ticket? (When it has one.) >> >> | >> >> | When you mention a ticket in a MR then a reference should be >> created from >> >> | it to the ticket. >> >> | >> >> | For example, when I mentioned !509 on this ticket it now displays >> in the >> >> | UI. >> >> >> >> I don't get it. You manually added "Corresponding MR !509" to the >> issue Description. Or are you saying that that apparently-user-written >> line was added by GitLab? If you have many MRs taht mention (perhaps en >> passant) the same issue, will there be many such lines? >> >> >> >> Or is it another discipline we could impose on ourselves? >> >> >> >> Simon >> >> >> >> | -----Original Message----- >> >> | From: Matthew Pickering >> >> | Sent: 11 March 2019 09:37 >> >> | To: Simon Peyton Jones >> >> | Cc: Ben Gamari ; GHC developers < >> ghc-devs at haskell.org> >> >> | Subject: Re: Trac to GitLab migration underway >> >> | >> >> | > * That the old ticket repo be put in read-only mode. I've just >> modified >> >> | the old #16344, but I should have modified the new one. >> >> | >> >> | That is tracked >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org%2Fbgamari%2Fgitlab- >> >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com >> %7Cac356 >> >> | >> d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >> >> | >> 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By >> >> | CdI%3D&reserved=0 >> >> | >> >> | It seems that there are still some problems to iron out though. >> >> | >> >> | > * Back on the tickets front, how do I record the test cases(s) >> for a >> >> | ticket? >> >> | >> >> | I don't believe there is a way other than via the commit >> referencing the >> >> | ticket. >> >> | >> >> | > >> >> | > * How do I record the MR for a ticket? (When it has one.) >> >> | >> >> | When you mention a ticket in a MR then a reference should be >> created from >> >> | it to the ticket. >> >> | >> >> | For example, when I mentioned !509 on this ticket it now displays >> in the >> >> | UI. >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org >> %2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro >> >> | soft.com >> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 >> >> | >> db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P >> >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 >> >> | >> >> | > >> >> | > * That the banner (on the wiki at least) saying "This site has >> been >> >> | deprecated and is in read-only mode" should describe how to get to >> the >> >> | corresponding URL on the new wiki. Eg. say "If you are trying to >> access >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> >> | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj% >> 40microsoft.com% >> >> | >> 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> >> | >> 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM >> >> | 1UyIq4%3D&reserved=0, the new URL is >> >> | " >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. >> >> | haskell.org >> %2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. >> >> | >> com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% >> >> | >> 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb >> >> | BUo5ABhqVo%3D&reserved=0". >> >> | > >> >> | > * Where has >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> >> | ell.org >> %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 >> >> | 0microsoft.com >> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d >> >> | >> 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu >> >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL >> on the >> >> | new wiki doesn't exist. >> >> | >> >> | The page is now located at: >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- >> >> | simon&data=02%7C01%7Csimonpj%40microsoft.com >> %7Cac356d50797a44abf82008d >> >> | >> 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& >> >> | >> amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= >> >> | 0 >> >> | >> >> | > >> >> | > * How can I list the title index on the new wiki? >> >> | >> >> | An automatically generated index is available here >> >> | >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org >> %2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros >> >> | oft.com >> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d >> >> | >> b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T >> >> | D4DGorbNyz28%3D&reserved=0 >> >> | >> >> | I believe the intention is to automatically update this with a >> cronjob. >> >> | >> >> | > >> >> | > * I have lots of pages like this one >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- >> >> | errors&data=02%7C01%7Csimonpj%40microsoft.com >> %7Cac356d50797a44abf82008 >> >> | >> d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 >> >> | >> &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 >> >> | that list the tickets relevant to a particular keyword. (Now >> "label" I >> >> | think?) But tat page is now lying: it claims to list current open >> >> | tickets, but actually it's a frozen snapshot. What should I do? >> >> | >> >> | Gitlab Wiki does not support this feature so you have to refer to a >> custom >> >> | search. >> >> | >> >> | For example: >> >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org >> %2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& >> >> | ;data=02%7C01%7Csimonpj%40microsoft.com >> %7Cac356d50797a44abf82008d6a6053319 >> >> | >> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata >> >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 >> >> | >> >> | However, it seems that the `CustomTypeErrors` label was lost during >> the >> >> | migration. Do you know why this is Tobias/Ben? It looks like it >> will have >> >> | to be added back manually. >> >> | >> >> | > >> >> | > Thanks >> >> | > >> >> | > Simon >> >> | > >> >> | > | I'm happy to announce that the ticket and issue import >> processes >> >> | > | are now complete and gitlab.haskell.org is back online. There >> are >> >> | > | still a few final steps remaining which I will be carrying out >> over >> >> | > | the next few >> >> | > | days: >> >> | > | >> >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs >> >> | > | >> >> | > | * Add issue comments showing commit messages, replicating the >> >> | previous >> >> | > | Trac behavior >> >> | > | >> >> | > | * Migrate the GHC Blog entries >> >> | > | >> >> | > | * Make the old Trac instance again accessible in read-only >> mode >> >> | > | >> >> | > | However, while I do this you should feel free to use >> >> | > | gitlab.haskell.org freely. >> >> | > | If you notice any issues with the import feel free to open a >> ticket >> >> | > | here [1]. >> >> | > | >> >> | > | Cheers, >> >> | > | >> >> | > | - Ben >> >> | > | >> >> | > | >> >> | > | >> >> | > | [1] >> >> | > | >> >> | > | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >> >> | > | tlab.h >> >> | > | askell.org%2Fbgamari%2Fgitlab- >> >> | > | >> >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com >> %7C48ce >> >> | > | 7f7334 >> >> | > | >> >> | > | >> c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >> >> | > | 636878 >> >> | > | >> >> | > | >> 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo >> >> | > | 0sk4%3 >> >> | > | D&reserved=0 >> >> | > _______________________________________________ >> >> | > 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 >> %7Cac356d50797a44abf82008d6a6053319%7C72f988 >> >> | > >> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq >> >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 >> > _______________________________________________ >> > 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 rae at richarde.dev Mon Mar 11 20:42:52 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 11 Mar 2019 16:42:52 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: Good point -- I hadn't noticed the unfortunate phrasing of the original post. You're right that the current focus is on email, but the tabs issue affects me, too. In any case, let's not link to that ticket. But before I take further action, I know that we have some side channels with GitLab, and I don't want to muddy the waters by working outside of those channels. If I should take further action, please let me know. Richard > On Mar 11, 2019, at 1:54 PM, Artem Pelenitsyn wrote: > > Hi Richard, > > Good catch! What troubles me in that issue, is (subjectively) the passive-aggressive form of the initial post. Given that it is email that we are worrying about, not the browser tabs, maybe it is better to start over with a new issue referencing that one in passing. > > -- > Best, Artem > > On Mon, 11 Mar 2019 at 11:56 Richard Eisenberg > wrote: > This old ticket might be related: https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 It advocates for moving numbers to the front of tab names, too. Looks like it was shut down by judgment call. Perhaps if we raise our voices in chorus against this decision, we can get some action (or a new configuration switch). > >> On Mar 11, 2019, at 10:25 AM, Artem Pelenitsyn > wrote: >> >> Hello, >> >> I just wanted to thank Ben and everyone involved for this transition. And also reiterate Richard's point about having !123 / #12345 in the front of mail subjects — I think, this is small but quite important detail to ease navigating the flow of notifications. >> >> -- >> Best regards, >> Artem >> >> On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg > wrote: >> Thanks to all who have made this happen. Looking forward to having everything in one place! >> >> Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow. >> >> I'd also like to second Simon's request, in particular, of having a clear path from an issue to an MR. Getting from an MR to an issue is normally easier -- when the MR is created, most devs would automatically mention the issue number somewhere in the description -- but going from an issue to an MR is harder. It would be a shame to have to search through the commentary looking for the link. I used the old "Phab:D1234" links in the top of a Trac ticket quite often. >> >> I also second the request for a test-case field. This field, to me, is most useful as a reminder to the author that they need to add a test case. But I think the issue-to-MR link is more important than the test-case field. >> >> Thanks! >> Richard >> >> > On Mar 11, 2019, at 6:17 AM, Matthew Pickering > wrote: >> > >> > I wrote !509 in the ticket which then made gitlab display the "Related >> > Merge Request" bit underneath. I don't know what happens if you >> > mention a MR in a comment. >> > >> > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones >> > > wrote: >> >> >> >> | > * Back on the tickets front, how do I record the test cases(s) for a >> >> | ticket? >> >> | >> >> | I don't believe there is a way other than via the commit referencing the >> >> | ticket. >> >> >> >> That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. >> >> >> >> Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? >> >> >> >> | > * How do I record the MR for a ticket? (When it has one.) >> >> | >> >> | When you mention a ticket in a MR then a reference should be created from >> >> | it to the ticket. >> >> | >> >> | For example, when I mentioned !509 on this ticket it now displays in the >> >> | UI. >> >> >> >> I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? >> >> >> >> Or is it another discipline we could impose on ourselves? >> >> >> >> Simon >> >> >> >> | -----Original Message----- >> >> | From: Matthew Pickering > >> >> | Sent: 11 March 2019 09:37 >> >> | To: Simon Peyton Jones > >> >> | Cc: Ben Gamari >; GHC developers > >> >> | Subject: Re: Trac to GitLab migration underway >> >> | >> >> | > * That the old ticket repo be put in read-only mode. I've just modified >> >> | the old #16344, but I should have modified the new one. >> >> | >> >> | That is tracked >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fbgamari%2Fgitlab- >> >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356 >> >> | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >> >> | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By >> >> | CdI%3D&reserved=0 >> >> | >> >> | It seems that there are still some problems to iron out though. >> >> | >> >> | > * Back on the tickets front, how do I record the test cases(s) for a >> >> | ticket? >> >> | >> >> | I don't believe there is a way other than via the commit referencing the >> >> | ticket. >> >> | >> >> | > >> >> | > * How do I record the MR for a ticket? (When it has one.) >> >> | >> >> | When you mention a ticket in a MR then a reference should be created from >> >> | it to the ticket. >> >> | >> >> | For example, when I mentioned !509 on this ticket it now displays in the >> >> | UI. >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro >> >> | soft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 >> >> | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P >> >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 >> >> | >> >> | > >> >> | > * That the banner (on the wiki at least) saying "This site has been >> >> | deprecated and is in read-only mode" should describe how to get to the >> >> | corresponding URL on the new wiki. Eg. say "If you are trying to access >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> >> | ell.org %2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com % >> >> | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> >> | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM >> >> | 1UyIq4%3D&reserved=0, the new URL is >> >> | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab . >> >> | haskell.org %2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. >> >> | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% >> >> | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb >> >> | BUo5ABhqVo%3D&reserved=0". >> >> | > >> >> | > * Where has >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> >> | ell.org %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 >> >> | 0microsoft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d >> >> | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu >> >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the >> >> | new wiki doesn't exist. >> >> | >> >> | The page is now located at: >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fghc%2Fghc%2Fwikis%2Frichard-and- >> >> | simon&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008d >> >> | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& >> >> | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= >> >> | 0 >> >> | >> >> | > >> >> | > * How can I list the title index on the new wiki? >> >> | >> >> | An automatically generated index is available here >> >> | >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros >> >> | oft.com %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d >> >> | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T >> >> | D4DGorbNyz28%3D&reserved=0 >> >> | >> >> | I believe the intention is to automatically update this with a cronjob. >> >> | >> >> | > >> >> | > * I have lots of pages like this one >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- >> >> | errors&data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008 >> >> | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 >> >> | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 >> >> | that list the tickets relevant to a particular keyword. (Now "label" I >> >> | think?) But tat page is now lying: it claims to list current open >> >> | tickets, but actually it's a frozen snapshot. What should I do? >> >> | >> >> | Gitlab Wiki does not support this feature so you have to refer to a custom >> >> | search. >> >> | >> >> | For example: >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> >> | askell.org %2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& >> >> | ;data=02%7C01%7Csimonpj%40microsoft.com %7Cac356d50797a44abf82008d6a6053319 >> >> | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata >> >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 >> >> | >> >> | However, it seems that the `CustomTypeErrors` label was lost during the >> >> | migration. Do you know why this is Tobias/Ben? It looks like it will have >> >> | to be added back manually. >> >> | >> >> | > >> >> | > Thanks >> >> | > >> >> | > Simon >> >> | > >> >> | > | I'm happy to announce that the ticket and issue import processes >> >> | > | are now complete and gitlab.haskell.org is back online. There are >> >> | > | still a few final steps remaining which I will be carrying out over >> >> | > | the next few >> >> | > | days: >> >> | > | >> >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs >> >> | > | >> >> | > | * Add issue comments showing commit messages, replicating the >> >> | previous >> >> | > | Trac behavior >> >> | > | >> >> | > | * Migrate the GHC Blog entries >> >> | > | >> >> | > | * Make the old Trac instance again accessible in read-only mode >> >> | > | >> >> | > | However, while I do this you should feel free to use >> >> | > | gitlab.haskell.org freely. >> >> | > | If you notice any issues with the import feel free to open a ticket >> >> | > | here [1]. >> >> | > | >> >> | > | Cheers, >> >> | > | >> >> | > | - Ben >> >> | > | >> >> | > | >> >> | > | >> >> | > | [1] >> >> | > | >> >> | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >> >> | > | tlab.h >> >> | > | askell.org %2Fbgamari%2Fgitlab- >> >> | > | >> >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com %7C48ce >> >> | > | 7f7334 >> >> | > | >> >> | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >> >> | > | 636878 >> >> | > | >> >> | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo >> >> | > | 0sk4%3 >> >> | > | D&reserved=0 >> >> | > _______________________________________________ >> >> | > 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 %7Cac356d50797a44abf82008d6a6053319%7C72f988 >> >> | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq >> >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 >> > _______________________________________________ >> > 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 ben at well-typed.com Mon Mar 11 22:37:05 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 11 Mar 2019 18:37:05 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> Message-ID: <87bm2hqbqy.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > | I'm happy to announce that the ticket and issue import processes are now > | complete and gitlab.haskell.org is back online. There are still a few > | final steps remaining which I will be carrying out over the next few > | days: > > Great! I'm sure it'll help to have everything in one place. > > Can I ask > > * That the old ticket repo be put in read-only mode. I've just > modified the old #16344, but I should have modified the new one. > Indeed this was supposed to be already done but it looks like I failed to remove a few permissions for developers which allowed further changes. This has been fixed. > * Back on the tickets front, how do I record the test cases(s) for a ticket? > This is unfortunately one of the casualties of the migration. GitLab doesn't have support for custom ticket fields (although they have indicated that they may introduce such support in the future). In the meantime we have a few options: * we introduce a convention to document this in comments * we give up tracking this in the issue tracker > * How do I record the MR for a ticket? (When it has one.) > Referring to the ticket from the MR description will result in a reference being added to the ticket. > * That the banner (on the wiki at least) saying "This site has been > deprecated and is in read-only mode" should describe how to get to the > corresponding URL on the new wiki. Eg. say "If you are trying to > access https://ghc.haskell.org/trac/ghc/wiki/, the new URL is > "https://gitlab.haskell.org/ghc/ghc/wikis/". > Ultimately the plan is to make Trac URLs directly forward to GitLab's Wiki. The current state of affairs is temporary. > * Where has https://ghc.haskell.org/trac/ghc/wiki/RichardAndSimon > gone? The corresponding URL on the new wiki doesn't exist. > This is an unfortunate effect of the move to GitLab's wiki, which insists on a different naming convention than Trac (kebab-case instead of CamelCase). > * How can I list the title index on the new wiki? > As Matthew mentioned, there is a table of contents page here [1]. Note that this is quite a hack; ideally we would be able to use GitLab's provided pages list feature [2] but unfortunately it's essentially unusable with a Wiki of non-trivial size. I have reported this upstream [3,4]. > * I have lots of pages like this one > https://gitlab.haskell.org/ghc/ghc/wikis/proposal/custom-type-errors > that list the tickets relevant to a particular keyword. (Now "label" I > think?) But tat page is now lying: it claims to list current open > tickets, but actually it's a frozen snapshot. What should I do? I can take care of replacing these with links to the appropriate query. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/index [2] https://gitlab.haskell.org/ghc/ghc/wikis/pages [3] https://gitlab.com/gitlab-org/gitlab-ce/issues/57751 [4] https://gitlab.com/gitlab-org/gitlab-ce/issues/57179 -------------- 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 Mon Mar 11 22:39:34 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Mar 2019 22:39:34 +0000 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: I suggest adding it to https://docs.google.com/document/d/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1QJQ/edit?usp=sharing which is our “GHC project wishlist for GitLab”. But Ben may have a way to bring it up directly as well. Simon From: ghc-devs On Behalf Of Richard Eisenberg Sent: 11 March 2019 20:43 To: Artem Pelenitsyn Cc: GHC developers Subject: Re: Trac to GitLab migration underway Good point -- I hadn't noticed the unfortunate phrasing of the original post. You're right that the current focus is on email, but the tabs issue affects me, too. In any case, let's not link to that ticket. But before I take further action, I know that we have some side channels with GitLab, and I don't want to muddy the waters by working outside of those channels. If I should take further action, please let me know. Richard On Mar 11, 2019, at 1:54 PM, Artem Pelenitsyn > wrote: Hi Richard, Good catch! What troubles me in that issue, is (subjectively) the passive-aggressive form of the initial post. Given that it is email that we are worrying about, not the browser tabs, maybe it is better to start over with a new issue referencing that one in passing. -- Best, Artem On Mon, 11 Mar 2019 at 11:56 Richard Eisenberg > wrote: This old ticket might be related: https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 It advocates for moving numbers to the front of tab names, too. Looks like it was shut down by judgment call. Perhaps if we raise our voices in chorus against this decision, we can get some action (or a new configuration switch). On Mar 11, 2019, at 10:25 AM, Artem Pelenitsyn > wrote: Hello, I just wanted to thank Ben and everyone involved for this transition. And also reiterate Richard's point about having !123 / #12345 in the front of mail subjects — I think, this is small but quite important detail to ease navigating the flow of notifications. -- Best regards, Artem On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg > wrote: Thanks to all who have made this happen. Looking forward to having everything in one place! Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow. I'd also like to second Simon's request, in particular, of having a clear path from an issue to an MR. Getting from an MR to an issue is normally easier -- when the MR is created, most devs would automatically mention the issue number somewhere in the description -- but going from an issue to an MR is harder. It would be a shame to have to search through the commentary looking for the link. I used the old "Phab:D1234" links in the top of a Trac ticket quite often. I also second the request for a test-case field. This field, to me, is most useful as a reminder to the author that they need to add a test case. But I think the issue-to-MR link is more important than the test-case field. Thanks! Richard > On Mar 11, 2019, at 6:17 AM, Matthew Pickering > wrote: > > I wrote !509 in the ticket which then made gitlab display the "Related > Merge Request" bit underneath. I don't know what happens if you > mention a MR in a comment. > > On Mon, Mar 11, 2019 at 10:14 AM Simon Peyton Jones > > wrote: >> >> | > * Back on the tickets front, how do I record the test cases(s) for a >> | ticket? >> | >> | I don't believe there is a way other than via the commit referencing the >> | ticket. >> >> That's sad. It's a useful discipline to fill in that field before closing the ticket. And it's useful later when looking for the test cases for the ticket. >> >> Is this just a straight loss, or is there a longer term plan to recover it? Do we need a self-imposed discipline, e.g. to ALWAYS add a comment that lists the test cases (and does nothing else) before closing an issue? >> >> | > * How do I record the MR for a ticket? (When it has one.) >> | >> | When you mention a ticket in a MR then a reference should be created from >> | it to the ticket. >> | >> | For example, when I mentioned !509 on this ticket it now displays in the >> | UI. >> >> I don't get it. You manually added "Corresponding MR !509" to the issue Description. Or are you saying that that apparently-user-written line was added by GitLab? If you have many MRs taht mention (perhaps en passant) the same issue, will there be many such lines? >> >> Or is it another discipline we could impose on ourselves? >> >> Simon >> >> | -----Original Message----- >> | From: Matthew Pickering > >> | Sent: 11 March 2019 09:37 >> | To: Simon Peyton Jones > >> | Cc: Ben Gamari >; GHC developers > >> | Subject: Re: Trac to GitLab migration underway >> | >> | > * That the old ticket repo be put in read-only mode. I've just modified >> | the old #16344, but I should have modified the new one. >> | >> | That is tracked >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fbgamari%2Fgitlab- >> | migration%2Fissues%2F14&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356 >> | d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 >> | 36878938597242017&sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By >> | CdI%3D&reserved=0 >> | >> | It seems that there are still some problems to iron out though. >> | >> | > * Back on the tickets front, how do I record the test cases(s) for a >> | ticket? >> | >> | I don't believe there is a way other than via the commit referencing the >> | ticket. >> | >> | > >> | > * How do I record the MR for a ticket? (When it has one.) >> | >> | When you mention a ticket in a MR then a reference should be created from >> | it to the ticket. >> | >> | For example, when I mentioned !509 on this ticket it now displays in the >> | UI. >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fissues%2F16417&data=02%7C01%7Csimonpj%40micro >> | soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011 >> | db47%7C1%7C0%7C636878938597242017&sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P >> | FJpNt6nkr%2BObzRAmk%3D&reserved=0 >> | >> | > >> | > * That the banner (on the wiki at least) saying "This site has been >> | deprecated and is in read-only mode" should describe how to get to the >> | corresponding URL on the new wiki. Eg. say "If you are trying to access >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> | ell.org%2Ftrac%2Fghc%2Fwiki%2F&data=02%7C01%7Csimonpj%40microsoft.com% >> | 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> | 7C0%7C636878938597242017&sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM >> | 1UyIq4%3D&reserved=0, the new URL is >> | "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab. >> | haskell.org%2Fghc%2Fghc%2Fwikis%2F&data=02%7C01%7Csimonpj%40microsoft. >> | com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47% >> | 7C1%7C0%7C636878938597242017&sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb >> | BUo5ABhqVo%3D&reserved=0". >> | > >> | > * Where has >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask >> | ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&data=02%7C01%7Csimonpj%4 >> | 0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d >> | 7cd011db47%7C1%7C0%7C636878938597242017&sdata=xkERHLEyWh8yWLxRS2GUZ4iu >> | Yk0DjFBxuKFkQbnyUeI%3D&reserved=0 gone? The corresponding URL on the >> | new wiki doesn't exist. >> | >> | The page is now located at: >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Frichard-and- >> | simon&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d >> | 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017& >> | amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&reserved= >> | 0 >> | >> | > >> | > * How can I list the title index on the new wiki? >> | >> | An automatically generated index is available here >> | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Findex&data=02%7C01%7Csimonpj%40micros >> | oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d >> | b47%7C1%7C0%7C636878938597242017&sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T >> | D4DGorbNyz28%3D&reserved=0 >> | >> | I believe the intention is to automatically update this with a cronjob. >> | >> | > >> | > * I have lots of pages like this one >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type- >> | errors&data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008 >> | d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017 >> | &sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&reserved=0 >> | that list the tickets relevant to a particular keyword. (Now "label" I >> | think?) But tat page is now lying: it claims to list current open >> | tickets, but actually it's a frozen snapshot. What should I do? >> | >> | Gitlab Wiki does not support this feature so you have to refer to a custom >> | search. >> | >> | For example: >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h >> | askell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo& >> | ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319 >> | %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata >> | =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&reserved=0 >> | >> | However, it seems that the `CustomTypeErrors` label was lost during the >> | migration. Do you know why this is Tobias/Ben? It looks like it will have >> | to be added back manually. >> | >> | > >> | > Thanks >> | > >> | > Simon >> | > >> | > | I'm happy to announce that the ticket and issue import processes >> | > | are now complete and gitlab.haskell.org is back online. There are >> | > | still a few final steps remaining which I will be carrying out over >> | > | the next few >> | > | days: >> | > | >> | > | * Put in place redirect logic for Trac ticket and Wiki URLs >> | > | >> | > | * Add issue comments showing commit messages, replicating the >> | previous >> | > | Trac behavior >> | > | >> | > | * Migrate the GHC Blog entries >> | > | >> | > | * Make the old Trac instance again accessible in read-only mode >> | > | >> | > | However, while I do this you should feel free to use >> | > | gitlab.haskell.org freely. >> | > | If you notice any issues with the import feel free to open a ticket >> | > | here [1]. >> | > | >> | > | Cheers, >> | > | >> | > | - Ben >> | > | >> | > | >> | > | >> | > | [1] >> | > | >> | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >> | > | tlab.h >> | > | askell.org%2Fbgamari%2Fgitlab- >> | > | >> | > | migration%2Fissues&data=02%7C01%7Csimonpj%40microsoft.com%7C48ce >> | > | 7f7334 >> | > | >> | > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >> | > | 636878 >> | > | >> | > | 507364801779&sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo >> | > | 0sk4%3 >> | > | D&reserved=0 >> | > _______________________________________________ >> | > 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%7Cac356d50797a44abf82008d6a6053319%7C72f988 >> | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&sdata=V5Xq >> | > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&reserved=0 > _______________________________________________ > 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 ben at smart-cactus.org Tue Mar 12 00:13:31 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 11 Mar 2019 20:13:31 -0400 Subject: Trac to GitLab migration underway In-Reply-To: <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: <874l89q7ad.fsf@smart-cactus.org> Richard Eisenberg writes: > Thanks to all who have made this happen. Looking forward to having > everything in one place! > > Do we have any ability to edit the formatting of subject lines of > ticket emails? It would be great if we could get the (!234) or > (#12345) up front, as this is the effective summary of what's to > follow. > I think we can manage that. Ideally I'd like to stay as close to an unmodified GitLab installation as possible but this particular issue doesn't sound like it should be a hard thing to fix. > I'd also like to second Simon's request, in particular, of having a > clear path from an issue to an MR. Getting from an MR to an issue is > normally easier -- when the MR is created, most devs would > automatically mention the issue number somewhere in the description -- > but going from an issue to an MR is harder. It would be a shame to > have to search through the commentary looking for the link. I used the > old "Phab:D1234" links in the top of a Trac ticket quite often. > In principle it shouldn't be any harder to go from an issue to an MR than it is to go the other direction. For instance, consider the case of #16347 [1]. You will note that below the "Related issues" section there is a list of related merge requests (strangely formatted completely differently). To be honest, how this list is formed is a bit of a mystery to me. The fact that !525 is included is not surprises: !525 mentions #16347 in its description. However, !436 is a bit less obvious since it does not mention #16347 at all. My hypothesis is that it is transitively included via #16344, which does mention #16437 and is related to it. [1] https://gitlab.haskell.org/ghc/ghc/issues/16347 > I also second the request for a test-case field. This field, to me, is > most useful as a reminder to the author that they need to add a test > case. But I think the issue-to-MR link is more important than the > test-case field. > Indeed, as I mentioned earlier this may be a bit of a hard thing to accomplish in the near-term. One measure we could take to ensure that tests aren't forgotten is to include a "field" in the default merge request description which contributors would be asked to fill in with the names of the tests that cover their change. That being said, this is no substitute for a proper field. 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 smart-cactus.org Tue Mar 12 00:17:37 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 11 Mar 2019 20:17:37 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> Message-ID: <871s3dq735.fsf@smart-cactus.org> Richard Eisenberg writes: > Good point -- I hadn't noticed the unfortunate phrasing of the > original post. > > You're right that the current focus is on email, but the tabs issue > affects me, too. In any case, let's not link to that ticket. > > But before I take further action, I know that we have some side > channels with GitLab, and I don't want to muddy the waters by working > outside of those channels. If I should take further action, please let > me know. > Opening a ticket is always a good first step. Generally my interactions with our contact take the form of opening new tickets or bringing existing tickets to his attention. 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 Tue Mar 12 13:30:35 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 12 Mar 2019 13:30:35 +0000 Subject: New and improved ghc-in-ghci target Message-ID: Hi all, My patch to improve the ghc-in-ghci target just got merged a few minutes ago. Now from a clean tree it only takes a few minutes to launch the target. You can now load ghc into ghci by running the following script: ./hadrian/ghci.sh https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian#fast-feedback-using-ghci Please try it out and open tickets if there are any issues on your system. Matt From simonpj at microsoft.com Tue Mar 12 16:39:44 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 Mar 2019 16:39:44 +0000 Subject: Trac to GitLab migration underway In-Reply-To: <87bm2hqbqy.fsf@smart-cactus.org> References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <87bm2hqbqy.fsf@smart-cactus.org> Message-ID: | > * I have lots of pages like this one | > https://gitlab.haskell.org/ghc/ghc/wikis/proposal/custom-type-errors | > that list the tickets relevant to a particular keyword. (Now "label" I | > think?) But tat page is now lying: it claims to list current open | > tickets, but actually it's a frozen snapshot. What should I do? | | I can take care of replacing these with links to the appropriate query. Actually, clicking on a label icon takes you to a page that lists the open and closed issues associated with that label. That's enough I think. No need to make a custom query. I have done an example here: https://gitlab.haskell.org/ghc/ghc/wikis/partial-type-signatures Simon | -----Original Message----- | From: Ben Gamari | Sent: 11 March 2019 22:37 | To: Simon Peyton Jones ; GHC developers | Subject: RE: Trac to GitLab migration underway | | Simon Peyton Jones via ghc-devs writes: | | > | I'm happy to announce that the ticket and issue import processes | > | are now complete and gitlab.haskell.org is back online. There are | > | still a few final steps remaining which I will be carrying out over | > | the next few | > | days: | > | > Great! I'm sure it'll help to have everything in one place. | > | > Can I ask | > | > * That the old ticket repo be put in read-only mode. I've just | > modified the old #16344, but I should have modified the new one. | > | Indeed this was supposed to be already done but it looks like I failed to | remove a few permissions for developers which allowed further changes. | This has been fixed. | | > * Back on the tickets front, how do I record the test cases(s) for a | ticket? | > | This is unfortunately one of the casualties of the migration. GitLab | doesn't have support for custom ticket fields (although they have | indicated that they may introduce such support in the future). | | In the meantime we have a few options: | | * we introduce a convention to document this in comments | | * we give up tracking this in the issue tracker | | > * How do I record the MR for a ticket? (When it has one.) | > | Referring to the ticket from the MR description will result in a reference | being added to the ticket. | | > * That the banner (on the wiki at least) saying "This site has been | > deprecated and is in read-only mode" should describe how to get to the | > corresponding URL on the new wiki. Eg. say "If you are trying to | > access https://ghc.haskell.org/trac/ghc/wiki/, the new URL is | > "https://gitlab.haskell.org/ghc/ghc/wikis/". | > | Ultimately the plan is to make Trac URLs directly forward to GitLab's | Wiki. The current state of affairs is temporary. | | > * Where has https://ghc.haskell.org/trac/ghc/wiki/RichardAndSimon | > gone? The corresponding URL on the new wiki doesn't exist. | > | This is an unfortunate effect of the move to GitLab's wiki, which insists | on a different naming convention than Trac (kebab-case instead of | CamelCase). | | | > * How can I list the title index on the new wiki? | > | As Matthew mentioned, there is a table of contents page here [1]. Note | that this is quite a hack; ideally we would be able to use GitLab's | provided pages list feature [2] but unfortunately it's essentially | unusable with a Wiki of non-trivial size. I have reported this upstream | [3,4]. | | > * I have lots of pages like this one | > https://gitlab.haskell.org/ghc/ghc/wikis/proposal/custom-type-errors | > that list the tickets relevant to a particular keyword. (Now "label" I | > think?) But tat page is now lying: it claims to list current open | > tickets, but actually it's a frozen snapshot. What should I do? | | I can take care of replacing these with links to the appropriate query. | | Cheers, | | - Ben | | | [1] https://gitlab.haskell.org/ghc/ghc/wikis/index | [2] https://gitlab.haskell.org/ghc/ghc/wikis/pages | [3] https://gitlab.com/gitlab-org/gitlab-ce/issues/57751 | [4] https://gitlab.com/gitlab-org/gitlab-ce/issues/57179 From simonpj at microsoft.com Tue Mar 12 17:32:46 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 Mar 2019 17:32:46 +0000 Subject: From tickets to merge requests and vice versa Message-ID: Ben, Matthew I wrote up notes on how to get from MR to issue, and from issue to MR, in my help page: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj (See "Issues" and "Merge requests" headings) Alas, it seems that I was lying * Issue #16411 does not have a "relevant merge request" link to MR!520, even though the latter plainly mentions the former. That seems deeply strange, and makes it hard to see if the issue has a MR, let alone which one it is. * Somehow MR!520 says "closes #16411" rather than just "mentions #16411". Perhaps this is good, but how did it know to do that? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Mar 12 17:42:31 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 12 Mar 2019 13:42:31 -0400 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> <874l89q7ad.fsf@smart-cactus.org> Message-ID: > On Mar 11, 2019, at 8:13 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > For instance, consider the case of > #16347 [1]. You will note that below the "Related issues" section there > is a list of related merge requests (strangely formatted completely > differently). Aha. That's exactly what I wanted. If that note is added to an issue when an MR mentions the issue number, I'm quite satisfied. > > To be honest, how this list is formed is a bit of a mystery to me. The > fact that !525 is included is not surprises: !525 mentions #16347 in > its description. However, !436 is a bit less obvious since it does not > mention #16347 at all. My hypothesis is that it is transitively included > via #16344, which does mention #16437 and is related to it. Transitive closures have a habit of sometimes getting large. But we'll tackle that problem when/if it comes up. > Indeed, as I mentioned earlier this may be a bit of a hard thing to > accomplish in the near-term. One measure we could take to ensure that > tests aren't forgotten is to include a "field" in the default merge > request description which contributors would be asked to fill in with > the names of the tests that cover their change. That's not a bad starting point. But it will hit only new contributors, right? Or will I be filling out such a form too (it's been a few weeks since my last patch submission, I'm afraid.) Thanks! Richard From mgsloan at gmail.com Tue Mar 12 17:48:48 2019 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 12 Mar 2019 10:48:48 -0700 Subject: New and improved ghc-in-ghci target In-Reply-To: References: Message-ID: Cool! That's very nice that it only takes a few minutes from a clean tree. I sometimes find it useful to also be able to run code from the repl. Might be good to support both usage modes via hadrian. Though, perhaps it's sufficient to have both this and `utils/ghc-in-ghci/run.sh` -Michael On Tue, Mar 12, 2019 at 6:31 AM Matthew Pickering wrote: > > Hi all, > > My patch to improve the ghc-in-ghci target just got merged a few > minutes ago. Now from a clean tree it only takes a few minutes to > launch the target. You can now load ghc into ghci by running the > following script: > > ./hadrian/ghci.sh > > https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian#fast-feedback-using-ghci > > Please try it out and open tickets if there are any issues on your system. > > Matt > _______________________________________________ > 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 Tue Mar 12 18:09:42 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 12 Mar 2019 14:09:42 -0400 Subject: Search on gitlab In-Reply-To: References: Message-ID: <87k1h4otge.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > I typed the query into the search box on the top black menu bar. The box has the encouraging text "search or jump to". > https://gitlab.haskell.org/search?group_id=&project_id=&repository_ref=&scope=projects&search=capturetopconstraints > > Ah.... now I see that it's displaying a "projects" tab. > > In BOLD LETTERS the page says "We couldn't find any results matching capturetopconstraints". > > But there is a quiet grey "merge requests" tab that indeed shows the MR. Ha! That's subtle! > Indeed. GitLab really should be more clever about which tab it shows by default. I opened this related ticket [1] a few weeks ago. > Even more oddly, when I did the same thing again (from somewhere else) I got this > https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=captureTopConstraints&group_id=&project_id=1&scope=wiki_blobs&repository_ref= > Note it displays "Code", "Commits" and "Comments" tabs which it did not before. > The search box is somewhat context-sensitive. When you are looking at a particular project the search results will contain things code, commits, and comments from the current project, in addition to the usual projects, issues, merge requests, and milestones that global queries return. > In that second page it looks as if the "project" filter is set to GHC. > But if actually pick GHC from the project-filter menu I get no > results. Well, I picked "Project: Glasgow Haskell Compiler/ci-images" > whatever that is? But there /is/ no plain GHC project in the list! I can reproduce this. This is truly strange; seems like a bug. I'll investigate. I've opened [2] to track this. > When I get more results like this: > https://gitlab.haskell.org/search?project_id=1&scope=notes&search=stub+binding > how are the results sorted? Can I sort them most-recent first? That is a good question. I was hoping that the answer was that they are sorted by relevance, since search is not terribly useful otherwise. However, to my surprise it actually seems [3] that they are ordered by creation date with no option to change this. On the staging instance I had enabled Elasticsearch support, which promised "better" search results (although it's slightly unclear what that means; there is still no option to choose an ordering). Doing the same on gitlab.haskell.org is on my list. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/56967#note_137118450 [2] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/30 [3] https://gitlab.com/gitlab-org/gitlab-ce/issues/51991 -------------- 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 Tue Mar 12 18:20:35 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 12 Mar 2019 18:20:35 +0000 Subject: From tickets to merge requests and vice versa In-Reply-To: References: Message-ID: I have no idea about #16411 and 520 sorry. It is quite baffling. I think it might say "closes #16411" because it says "Fix #16411" in the title. On Tue, Mar 12, 2019 at 5:32 PM Simon Peyton Jones wrote: > > Ben, Matthew > > > > I wrote up notes on how to get from MR to issue, and from issue to MR, in my help page: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj > > (See “Issues” and “Merge requests” headings) > > > > Alas, it seems that I was lying > > > > Issue #16411 does not have a “relevant merge request” link to MR!520, even though the latter plainly mentions the former. That seems deeply strange, and makes it hard to see if the issue has a MR, let alone which one it is. > > > > Somehow MR!520 says “closes #16411” rather than just “mentions #16411”. Perhaps this is good, but how did it know to do that? > > > > Simon From me at ara.io Tue Mar 12 18:42:21 2019 From: me at ara.io (Ara Adkins) Date: Tue, 12 Mar 2019 18:42:21 +0000 Subject: Marge Bot Permissions on Trac Message-ID: <68EF1167-4F14-4300-A2A4-F9898008CB72@ara.io> Hey all, though mostly hey Ben, Just figured I should let you know that marge still seems to be making changes to trac tickets as of about four hours ago when sending this email. Best, _ara From ben at well-typed.com Tue Mar 12 20:55:11 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 12 Mar 2019 16:55:11 -0400 Subject: From tickets to merge requests and vice versa In-Reply-To: References: Message-ID: <87d0mvq0d1.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Ben, Matthew > > I wrote up notes on how to get from MR to issue, and from issue to MR, > in my help page: > https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj > (See "Issues" and "Merge requests" headings) One note unrelated to the MR-to-issue matter: * Regarding high zoom levels causing the interface to be truncated: you may want to switch to the "fluid" layout width option (see [1]). I quickly tried it and it seems to be a bit more tolerant of zooming than the default fixed-width layout. [1] https://gitlab.haskell.org/profile/preferences > Alas, it seems that I was lying > > > * Issue #16411 does not have a "relevant merge request" link to > MR!520, even though the latter plainly mentions the former. That > seems deeply strange, and makes it hard to see if the issue has a > MR, let alone which one it is. > I believe the reason for this is that !520 was opened before #16411 was imported. This is an unfortunate consequence of the fact that GitLab only scans for references when a comment/MR/issue is created or edited, not when it is rendered. I triggered a rescan of the description of !520 (by making a simple whitespace edit) and the expected reference was created. > > * Somehow MR!520 says "closes #16411" rather than just "mentions > #16411". Perhaps this is good, but how did it know to do that? > It matches the commit messages and merge request description against a regular expression. The default regular expression essentially matches phrases like * Fixes #1234 * Fixed #1234 * Closes #1234 * Closed #1234 occurring anywhere in the message. Given that we generally want contributors to review tickets before closing them, I think this is far too liberal. However, earlier today I made this significantly more selective. The new regular expression only matches lines starting with "Closes #1234". This still allows the auto-closure feature to be used but should greatly reduce the chance that it is inadvertently triggered. 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 alexandreR_B at outlook.com Tue Mar 12 23:35:14 2019 From: alexandreR_B at outlook.com (Alexandre Rodrigues) Date: Tue, 12 Mar 2019 23:35:14 +0000 Subject: Newcomers' Guide to GHC Development In-Reply-To: <20190305115433.ftpp42evwatmgien@nibbler> References: <20190227100657.b3qodmep4ymvrade@nibbler> , <20190305115433.ftpp42evwatmgien@nibbler> Message-ID: Hello; I’d like to ask something regarding this effort. Right now, GHC’s repository is mirrored in these locations: * Phabricator * git.haskell.org * GitHub * GitLab Most of these have associated READMEs that encourage users to contribute patches to that particular instance, which does not really reflect the current state of affairs: right now, it is my understanding that GitLab is where all (new) patches are to be submitted. With the recent migration to GitLab and archival of Trac, will the first two be moved to read-only status like the Trac service? Regarding GitHub/GitLab – do we still want to accept contributions to GitHub? If so, what kind? All kinds? Maybe just small documentation patches? I believe all of this should be documented to avoid fragmentation of contribution efforts. I still remember my first contribution was a little confusing because of this. ________________________________ From: ghc-devs on behalf of Tobias Dammers Sent: Tuesday, March 5, 2019 11:54:34 AM To: GHC Devs Subject: Re: Newcomers' Guide to GHC Development Hi, thanks for your feedback. I'll get into some detail below. On Sat, Mar 02, 2019 at 11:36:06AM +1100, Julian Leviston wrote: > The updated version could be improved by shaping it into clearer > sections because we’d like newcomers to feel like it’s light and easy. > Layers is a great way to achieve this. > > The first time I ran through the task list (not very long ago), it > felt light and easy. This was because it was chunked well. > > So, my suggestion would be to have a third sentence/paragraph in the > introduction section that explains what the overall steps are that > we’re going to explain next. Provide links down into those sections, > and make it really clear that those sections are sections, if > possible. I like the idea of a short outline of the overall progression in the introduction, so just added that. I won't add those links yet, because due to the way this works in Gitlab, it's best to do it after the document has solidified, because adding or removing headers (of any level) will change the headers' generated ID properties, potentially breaking any links. As far as the chunking goes, I believe we already have a fairly decent structure in place. The GitHub layout may not make it very obvious though, and I think it'll be clearer on Gitlab. I did rearrange things a tiny bit in order to fit in better with the overall arch though. If you have concrete suggestions on how to improve the structure further, please feel free to tell, or better yet, issue a PR on GitHub. > At each section, you could reiterate how to do that driving from the > overarching aim of the explanation for the section. (Having an > introduction to each section would help here, too). This seems like overkill to me. We need to strike a balance between completeness and brevity, and we're bordering on "too long" already. I did try to come up with suitable introductions, but they all ended being paraphrasings of the title or the entire section, so I decided against them. Note that my goal here is to remove obstacles and friction, not to persuade people into contributing - by the time you read this guide, you should have been persuaded already. Quoting the very first sentence in the guide: | This page is intended to serve as the first stop for those people who | say, "I want to contribute to GHC, but I don't know quite where to | begin." > For example, having a canonical way to determine what a good issue or > feature to start on would be awesome, as would having somewhat of a > mentor/buddy to help new users when working on their bugs (ie one or > two people assigned to a newcomers’ first two or so tickets to help > them through any issues until they feel confident). Not sure if our > contributors allow for such things yet, tho. I agree that that would be awesome; however, we have limited resources at our disposal that we need to juggle between several concerns, and mentoring newcomers is only one of them. What we can offer right now is: - Issues labeled "newcomers" (the guide already mentions these) - Ad-hoc, no-strings-attached support from core GHC contributors and various volunteers via this mailing list and IRC (the guide mentions these, too) - Some time from core contributors, as available, allocated to handling incoming issues and merge requests. We strive to provide feedback on every one of them, but we cannot make any hard promises as to the timeframe, and we have to prioritize. On top of that, many individuals and third-party organisations run various forms of mentoring, tutoring, guidance, hackathon events, counseling, etc. Listing those would go way beyond the scope of this document, but you should have little trouble getting suggestions via our various communication channels. Hope that clarifies things, and again, thanks a lot for your input. _______________________________________________ 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 ben at smart-cactus.org Wed Mar 13 03:52:00 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 12 Mar 2019 23:52:00 -0400 Subject: Newcomers' Guide to GHC Development In-Reply-To: References: <20190227100657.b3qodmep4ymvrade@nibbler> <20190305115433.ftpp42evwatmgien@nibbler> Message-ID: <878sxjph2c.fsf@smart-cactus.org> Alexandre Rodrigues writes: > Hello; > > I’d like to ask something regarding this effort. Right now, GHC’s > repository is mirrored in these locations: > > * Phabricator > * git.haskell.org > * GitHub > * GitLab > > Most of these have associated READMEs that encourage users to > contribute patches to that particular instance, which does not really > reflect the current state of affairs: right now, it is my > understanding that GitLab is where all (new) patches are to be > submitted. > > With the recent migration to GitLab and archival of Trac, will the > first two be moved to read-only status like the Trac service? > Precisely; git.haskell.org and Phabricator will both be decommissioned. However, we want to ensure that we keep archival copies of these services around so this will take some time. > Regarding GitHub/GitLab – do we still want to accept contributions to > GitHub? If so, what kind? All kinds? Maybe just small documentation > patches? > At the moment the plan is to continue accepting small documentation patches and divert everything larger to GitLab. > I believe all of this should be documented to avoid fragmentation of > contribution efforts. I still remember my first contribution was a > little confusing because of this. > Indeed this is on the queue. So far we've been trying out best to keep the migration on track and keep moving the release schedule chugging along, even if slowly. After this newcomer's guide is finished we will turn our attention to cleaning up the remaining documentation. 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 Wed Mar 13 07:39:22 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 13 Mar 2019 07:39:22 +0000 Subject: Gitlab Email Broken (again) Message-ID: HI Ben, I am not receiving emails from gitlab again. Is there a way we can make email more robust? Matt From lonetiger at gmail.com Wed Mar 13 08:18:01 2019 From: lonetiger at gmail.com (Phyx) Date: Wed, 13 Mar 2019 09:18:01 +0100 Subject: Trac to GitLab migration underway In-Reply-To: References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org> <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu> <874l89q7ad.fsf@smart-cactus.org> Message-ID: Hi all, Question, how do I view only Windows issues? I see there is a windows tag but nothing is linked to it. And tickets contain sporadically the "Trac Metadata" field. So I'm not sure how to get the same overview I used on trac. Kind regards, Tamar On Tue, Mar 12, 2019, 18:42 Richard Eisenberg wrote: > > > On Mar 11, 2019, at 8:13 PM, Ben Gamari wrote: > > > > Richard Eisenberg writes: > > For instance, consider the case of > > #16347 [1]. You will note that below the "Related issues" section there > > is a list of related merge requests (strangely formatted completely > > differently). > > Aha. That's exactly what I wanted. If that note is added to an issue when > an MR mentions the issue number, I'm quite satisfied. > > > > > To be honest, how this list is formed is a bit of a mystery to me. The > > fact that !525 is included is not surprises: !525 mentions #16347 in > > its description. However, !436 is a bit less obvious since it does not > > mention #16347 at all. My hypothesis is that it is transitively included > > via #16344, which does mention #16437 and is related to it. > > Transitive closures have a habit of sometimes getting large. But we'll > tackle that problem when/if it comes up. > > Indeed, as I mentioned earlier this may be a bit of a hard thing to > > accomplish in the near-term. One measure we could take to ensure that > > tests aren't forgotten is to include a "field" in the default merge > > request description which contributors would be asked to fill in with > > the names of the tests that cover their change. > > That's not a bad starting point. But it will hit only new contributors, > right? Or will I be filling out such a form too (it's been a few weeks > since my last patch submission, I'm afraid.) > > Thanks! > Richard > > > _______________________________________________ > 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 arnaud.spiwack at tweag.io Wed Mar 13 09:16:14 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 13 Mar 2019 10:16:14 +0100 Subject: Haddock tree spongled In-Reply-To: <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> Message-ID: On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault wrote: > The right way to solve this problem is probably to find a better way of > factoring GHC-specific functionality out and putting only that in the GHC > tree. This is a good long term goal, but I don’t think we are quite there > yet. Some other ongoing changes in both GHC and Haddock are blocking the > way forward on this front… > In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late. Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Wed Mar 13 11:13:35 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 13 Mar 2019 11:13:35 +0000 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> Message-ID: I tried adding back the linters which check to make sure a commit is in the upstream branch before a MR is merged but got blocked by a gitlab issue. https://gitlab.haskell.org/ghc/ghc/merge_requests/395 The currently recommended workflow is that your commit should be in the ghc-head branch before the merge to GHC takes place. This enforces some linearisation but it stops the tree breaking. Matt On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud wrote: > > > On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault wrote: >> >> The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front… > > > In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late. > > Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From me at ara.io Wed Mar 13 11:24:49 2019 From: me at ara.io (Ara Adkins) Date: Wed, 13 Mar 2019 11:24:49 +0000 Subject: Gitlab Email Broken (again) In-Reply-To: References: Message-ID: <89EEDF33-4D6A-4B81-B937-C43A1F8DD251@ara.io> The same thing seems to have happened to me too. _ara > On 13 Mar 2019, at 07:39, Matthew Pickering wrote: > > HI Ben, > > I am not receiving emails from gitlab again. Is there a way we can > make email more robust? > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Wed Mar 13 11:36:44 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Mar 2019 07:36:44 -0400 Subject: Gitlab Email Broken (again) In-Reply-To: References: Message-ID: <871s3bovjy.fsf@smart-cactus.org> Matthew Pickering writes: > HI Ben, > > I am not receiving emails from gitlab again. Is there a way we can > make email more robust? > Sigh. Yes, it has been on my list. Unfortunately it requires changes to the nixos module so I have been dragging my feet on it. I'll try ticking this off now. 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 Wed Mar 13 11:50:24 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Mar 2019 07:50:24 -0400 Subject: Gitlab Email Broken (again) In-Reply-To: <871s3bovjy.fsf@smart-cactus.org> References: <871s3bovjy.fsf@smart-cactus.org> Message-ID: <87y35jngcq.fsf@smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> HI Ben, >> >> I am not receiving emails from gitlab again. Is there a way we can >> make email more robust? >> > Sigh. Yes, it has been on my list. Unfortunately it requires changes to > the nixos module so I have been dragging my feet on it. > > I'll try ticking this off now. > Alright, this I believe the issue is probably fixed once and for all. 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 Wed Mar 13 11:52:56 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Mar 2019 07:52:56 -0400 Subject: CI artifacts moved Message-ID: <87va0nng89.fsf@smart-cactus.org> Hello everyone, Note that yesterday I moved CI artifact storage from AWS to Dreamobjects. However, I was not able to move the old artifacts themselves (transferring >500 GB of data that will largely be expired in two weeks between cloud providers is simply not economically feasible). Consequently artifacts produced earlier than today will be unavailable. 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 alec.theriault at gmail.com Wed Mar 13 13:42:21 2019 From: alec.theriault at gmail.com (Alec Theriault) Date: Wed, 13 Mar 2019 06:42:21 -0700 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> Message-ID: <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com> Hi, > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces This seems problematic: everyone is going to race to get their changes into Haddock's ghc-head first, then block everyone else’s Haddock-touching patches from building with CI until the GHC side of the first person's changes goes through too. And that might take some time if Marge finds problems with the patch. I propose the workflow be: Once you’ve finished your patch, rebase the GHC side on top of upstream GHC master Rebase the Haddock side on top of upstream Haddock ghc-head Once Marge merges your MR, fast-forward the upstream ghc-head to your new commit That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever loses just has to rebase. Ideally, we would have Marge doing both the rebasing and step #3 for us. In the place of Marge, anyone who has write access to Haddock should feel free to do step #3 too (like when Marge merges an MR while the author of the MR is busy doing other things… like sleeping). As a side note, I do wish there was an easy way in GitLab to quickly jump to the diffs of submodules (or at least an easy way to copy the new commit hash). Thanks, Alec > On Mar 13, 2019, at 4:13 AM, Matthew Pickering wrote: > > I tried adding back the linters which check to make sure a commit is > in the upstream branch before a MR is merged but got blocked by a > gitlab issue. > > https://gitlab.haskell.org/ghc/ghc/merge_requests/395 > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > some linearisation but it stops the tree breaking. > > Matt > > On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud wrote: >> >> >> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault wrote: >>> >>> The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front… >> >> >> In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late. >> >> Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree? >> _______________________________________________ >> 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 Wed Mar 13 13:59:52 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 13 Mar 2019 13:59:52 +0000 Subject: Haddock tree spongled In-Reply-To: <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com> References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com> Message-ID: Under your workflow it doesn't seem like the commit which ends up in master will point to a commit on ghc-head? This is problematic when doing bisection if the branch where the commit lives is deleted or force pushed to. I would prefer a workflow which is more annoying for contributors but doesn't leave the tree in a bad state than one which is convenient but dangerous. Cheers, Matt On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault wrote: > > Hi, > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > > > This seems problematic: everyone is going to race to get their changes into Haddock's ghc-head first, then block everyone else’s Haddock-touching patches from building with CI until the GHC side of the first person's changes goes through too. And that might take some time if Marge finds problems with the patch. I propose the workflow be: > > Once you’ve finished your patch, rebase the GHC side on top of upstream GHC master > Rebase the Haddock side on top of upstream Haddock ghc-head > Once Marge merges your MR, fast-forward the upstream ghc-head to your new commit > > > That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever loses just has to rebase. Ideally, we would have Marge doing both the rebasing and step #3 for us. In the place of Marge, anyone who has write access to Haddock should feel free to do step #3 too (like when Marge merges an MR while the author of the MR is busy doing other things… like sleeping). > > As a side note, I do wish there was an easy way in GitLab to quickly jump to the diffs of submodules (or at least an easy way to copy the new commit hash). > > Thanks, > Alec > > On Mar 13, 2019, at 4:13 AM, Matthew Pickering wrote: > > I tried adding back the linters which check to make sure a commit is > in the upstream branch before a MR is merged but got blocked by a > gitlab issue. > > https://gitlab.haskell.org/ghc/ghc/merge_requests/395 > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > some linearisation but it stops the tree breaking. > > Matt > > On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud wrote: > > > > On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault wrote: > > > The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front… > > > > In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late. > > Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From alec.theriault at gmail.com Wed Mar 13 14:19:08 2019 From: alec.theriault at gmail.com (Alec Theriault) Date: Wed, 13 Mar 2019 07:19:08 -0700 Subject: Haddock tree spongled In-Reply-To: References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com> Message-ID: <12E2F656-672B-4079-A924-1EBC04F509D0@gmail.com> > Under your workflow it doesn't seem like the commit which ends up in > master will point to a commit on ghc-head? Correct, but at most the head commit will be out of sync (and a fast forward merge should be always possible). Step 3 is about rectifying that situation. > This is problematic when doing bisection if the branch where the > commit lives is deleted or force pushed to. We still end up with an easy-to-bisect linear history (in both Haddock and GHC) at the end of the day. I fear I may be misunderstanding your point here. > I would prefer a workflow which is more annoying for contributors but > doesn't leave the tree in a bad state than one which is convenient but > dangerous. What is this bad state? Perhaps I’m again misunderstanding, but how does your proposal help leave the tree in a better state? As soon as someone preparing a GHC patch pushes changes directly to ghc-head and before those changes get merged, the situation is going to be just as confusing for everyone else trying to do something with Haddock (and not easily fixable either). Thanks, Alec > On Mar 13, 2019, at 6:59 AM, Matthew Pickering wrote: > > Under your workflow it doesn't seem like the commit which ends up in > master will point to a commit on ghc-head? > > This is problematic when doing bisection if the branch where the > commit lives is deleted or force pushed to. > > I would prefer a workflow which is more annoying for contributors but > doesn't leave the tree in a bad state than one which is convenient but > dangerous. > > Cheers, > > Matt > > On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault wrote: >> >> Hi, >> >> The currently recommended workflow is that your commit should be in >> the ghc-head branch before the merge to GHC takes place. This enforces >> >> >> This seems problematic: everyone is going to race to get their changes into Haddock's ghc-head first, then block everyone else’s Haddock-touching patches from building with CI until the GHC side of the first person's changes goes through too. And that might take some time if Marge finds problems with the patch. I propose the workflow be: >> >> Once you’ve finished your patch, rebase the GHC side on top of upstream GHC master >> Rebase the Haddock side on top of upstream Haddock ghc-head >> Once Marge merges your MR, fast-forward the upstream ghc-head to your new commit >> >> >> That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever loses just has to rebase. Ideally, we would have Marge doing both the rebasing and step #3 for us. In the place of Marge, anyone who has write access to Haddock should feel free to do step #3 too (like when Marge merges an MR while the author of the MR is busy doing other things… like sleeping). >> >> As a side note, I do wish there was an easy way in GitLab to quickly jump to the diffs of submodules (or at least an easy way to copy the new commit hash). >> >> Thanks, >> Alec >> >> On Mar 13, 2019, at 4:13 AM, Matthew Pickering wrote: >> >> I tried adding back the linters which check to make sure a commit is >> in the upstream branch before a MR is merged but got blocked by a >> gitlab issue. >> >> https://gitlab.haskell.org/ghc/ghc/merge_requests/395 >> >> The currently recommended workflow is that your commit should be in >> the ghc-head branch before the merge to GHC takes place. This enforces >> some linearisation but it stops the tree breaking. >> >> Matt >> >> On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud wrote: >> >> >> >> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault wrote: >> >> >> The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front… >> >> >> >> In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late. >> >> Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree? >> _______________________________________________ >> 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 arnaud.spiwack at tweag.io Thu Mar 14 11:07:42 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 14 Mar 2019 12:07:42 +0100 Subject: Haddock tree spongled In-Reply-To: <12E2F656-672B-4079-A924-1EBC04F509D0@gmail.com> References: <87sgw0qk8b.fsf@smart-cactus.org> <87lg1sqcaa.fsf@smart-cactus.org> <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com> <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com> <12E2F656-672B-4079-A924-1EBC04F509D0@gmail.com> Message-ID: What is this bad state? I think the problem is that if you don’t push to haddock/ghc-head first, then the commit in ghc/master would point to a commit which has no guarantee to be durable: it may be rebased or squashed, by the time it gets to ghc-head. This means that after the commit has been mutated, the commit in ghc is no longer a valid checkout (because it can’t checkout its Haddock submodule). In the current situation, it is imperative that haddock/ghc-head is updated first. If we want to preserve the most minimal of invariant. It is still a pretty awful situation to be in, to be honest. - It’s rather hard to enforce, so if one forgets to update haddock/ghc-head first, then we are back to square one. (I suppose that, in constrast, in Matthew’s linter change, we would have red CI during the entire review phase of an MR. Which would be rather inconvenient, to say the least) - You need two independent sets of approval to get either part of a patch merged. - Two MR which want to modify Haddock will needlessly conflict with one another. When one has its Haddock modification merged. The other requires updates (it’s super tedious to rebase a history and be clean if there are several commit which touch Haddock, by the way). And trigger unnecessary consumption of our already precious CI resources. - In fact, any merging of a change to haddock/ghc-head will require rewriting the history of the MR that needs it. Also unnecessary consumption of CI resources. Quite frankly, this is not a fun place to be. It may be worth taking a step back and contemplating the situation we’ve built for ourselves. /Arnaud On Wed, Mar 13, 2019 at 3:19 PM Alec Theriault wrote: > Under your workflow it doesn't seem like the commit which ends up in > master will point to a commit on ghc-head? > > > Correct, but at most the head commit will be out of sync (and a fast > forward merge should be always possible). Step 3 is about rectifying that > situation. > > This is problematic when doing bisection if the branch where the > commit lives is deleted or force pushed to. > > > We still end up with an easy-to-bisect linear history (in both Haddock and > GHC) at the end of the day. I fear I may be misunderstanding your point > here. > > I would prefer a workflow which is more annoying for contributors but > doesn't leave the tree in a bad state than one which is convenient but > dangerous. > > > What is this bad state? Perhaps I’m again misunderstanding, but how does > your proposal help leave the tree in a better state? As soon as someone > preparing a GHC patch pushes changes directly to ghc-head and before > those changes get merged, the situation is going to be just as confusing > for everyone else trying to do something with Haddock (and not easily > fixable either). > > Thanks, > Alec > > On Mar 13, 2019, at 6:59 AM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > Under your workflow it doesn't seem like the commit which ends up in > master will point to a commit on ghc-head? > > This is problematic when doing bisection if the branch where the > commit lives is deleted or force pushed to. > > I would prefer a workflow which is more annoying for contributors but > doesn't leave the tree in a bad state than one which is convenient but > dangerous. > > Cheers, > > Matt > > On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault > wrote: > > > Hi, > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > > > This seems problematic: everyone is going to race to get their changes > into Haddock's ghc-head first, then block everyone else’s Haddock-touching > patches from building with CI until the GHC side of the first person's > changes goes through too. And that might take some time if Marge finds > problems with the patch. I propose the workflow be: > > Once you’ve finished your patch, rebase the GHC side on top of upstream > GHC master > Rebase the Haddock side on top of upstream Haddock ghc-head > Once Marge merges your MR, fast-forward the upstream ghc-head to your new > commit > > > That way, multiple MR’s with Haddock parts can “race” to get merged. > Whoever loses just has to rebase. Ideally, we would have Marge doing both > the rebasing and step #3 for us. In the place of Marge, anyone who has > write access to Haddock should feel free to do step #3 too (like when Marge > merges an MR while the author of the MR is busy doing other things… like > sleeping). > > As a side note, I do wish there was an easy way in GitLab to quickly jump > to the diffs of submodules (or at least an easy way to copy the new commit > hash). > > Thanks, > Alec > > On Mar 13, 2019, at 4:13 AM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > I tried adding back the linters which check to make sure a commit is > in the upstream branch before a MR is merged but got blocked by a > gitlab issue. > > https://gitlab.haskell.org/ghc/ghc/merge_requests/395 > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > some linearisation but it stops the tree breaking. > > Matt > > On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud > wrote: > > > > On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault > wrote: > > > The right way to solve this problem is probably to find a better way of > factoring GHC-specific functionality out and putting only that in the GHC > tree. This is a good long term goal, but I don’t think we are quite there > yet. Some other ongoing changes in both GHC and Haddock are blocking the > way forward on this front… > > > > In the meantime, there is no way to make atomic updates to GHC and Haddock > (which need to happen regularly). And GHC's master and the ghc-head branch > keep getting out of sync. It's really hard to diagnose, until it blocks > someone's valuable time. At which point it's too late. > > Is there a short term solution which would alleviate that cost, besides > merging Haddock in the main Ghc tree? > _______________________________________________ > 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 arnaud.spiwack at tweag.io Thu Mar 14 15:19:32 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 14 Mar 2019 16:19:32 +0100 Subject: Discussion: Hadrian's defaults Message-ID: I’ve been using Hadrian for a while. And I really like it. But I think, based on my experience and also the reading of the soon to be freshly reforged newcomers’ guide, that it could be greatly improved by changing the default of some of the more common options: - The -c option should be the default. One of the cool thing about Hadrian is that it needs fewer steps to completion, as it knows how to run the boot and configuration script. It’s not always what you want, but if it isn’t, it should befall to you to specify it. The most common use is the default (-c is, for instance, used in the newcomers’ guide). The reverse flag could be --no-configure. - --freeze1 should be the default. Ok, this one is harder. It’s almost always the right thing to call --freeze1 and forgetting it can have big consequences. So let’s make --freeze1 the default, add a flag --rebuild1 to force the rebuilding of stage 1. However, this requires an exception: if stage 1 was never built, we should build it, even without the flag --rebuild1. - Eventually, the new --share option should be the default as well. But maybe the paint is a bit too fresh on this. If I missed something (other defaults which should be changed, or reason to keep the defaults as they currently are) reply to this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Mar 14 15:30:31 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 14 Mar 2019 15:30:31 +0000 Subject: Discussion: Hadrian's defaults In-Reply-To: References: Message-ID: My personal experience is that 1. -c doesn't work very well compared to ./configure for me and picks up the wrong versions of alex/happy as installed by hadrian rather than the ones provisioned by ghc.nix/. I have tried to avoid it anyway after encountering some problems. 2. I have the impression that freeze1 being the default could be quite safe. 3. In my experience --share is too unreliable at the moment. I tried using it for 2-3 days but it didn't seem ready. The most friendly option to developers would be not building the perf build by default but this has been repeatedly shot down in the past. Cheers, Matt On Thu, Mar 14, 2019 at 3:20 PM Spiwack, Arnaud wrote: > > I’ve been using Hadrian for a while. And I really like it. But I > think, based on my experience and also the reading of the soon to be > freshly reforged newcomers’ guide, that it could be greatly improved > by changing the default of some of the more common options: > > The -c option should be the default. One of the cool thing about > Hadrian is that it needs fewer steps to completion, as it knows how > to run the boot and configuration script. It’s not always what you > want, but if it isn’t, it should befall to you to specify it. The > most common use is the default (-c is, for instance, used in the > newcomers’ guide). The reverse flag could be --no-configure. > --freeze1 should be the default. Ok, this one is harder. It’s > almost always the right thing to call --freeze1 and forgetting it > can have big consequences. So let’s make --freeze1 the default, > add a flag --rebuild1 to force the rebuilding of stage 1. However, > this requires an exception: if stage 1 was never built, we should > build it, even without the flag --rebuild1. > Eventually, the new --share option should be the default as > well. But maybe the paint is a bit too fresh on this. > > If I missed something (other defaults which should be changed, or > reason to keep the defaults as they currently are) reply to this > thread. > > _______________________________________________ > 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 Thu Mar 14 15:57:27 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 14 Mar 2019 16:57:27 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: References: Message-ID: The most friendly option to developers would be not building the perf > build by default but this has been repeatedly shot down in the past. > I agree. But I also find it reasonable to make it so one won't accidentally build a dev build when trying to make a release. (that being said, in the Ocaml world, things have been going the other way, where, if I understand correctly, `dune build` builds development version, while `dune build @install` builds release artifact). I can't say I have a strong opinion on this. 1. -c doesn't work very well compared to ./configure for me and picks > up the wrong versions of alex/happy as installed by hadrian rather > than the ones provisioned by ghc.nix/. I have tried to avoid it anyway > after encountering some problems. > If anybody else have such issues with `-c`, please share your experience in the thread. I haven't had any problem so far, myself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Mar 14 18:19:50 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 14 Mar 2019 19:19:50 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: References: Message-ID: On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud wrote: > > - The -c option should be the default. > > Very strong -1 from me on this one; I've been quite vocal on the Hadrian issue tracker early on and multiple times against having Hadrian invoke ./configure at all, even more so against having it do so by default. I don't have the ticket number at my fingertips but it should be fairly easy to find. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu Mar 14 18:43:24 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 14 Mar 2019 14:43:24 -0400 Subject: github ghc.git broken on libraries/binary Message-ID: `git clone git at github.com:ghc/ghc.git` followed by `git submodule update --init --recursive` results in ``` error: Server does not allow request for unadvertised object 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 Fetched in submodule path 'libraries/binary', but it did not contain 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit failed. ``` -- 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 allbery.b at gmail.com Thu Mar 14 18:53:14 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 14 Mar 2019 14:53:14 -0400 Subject: github ghc.git broken on libraries/binary In-Reply-To: References: Message-ID: As yet mirroring github from gitlab is broken, I think (various parts of the migration are not yet complete); you should use the gitlab upstream. On Thu, Mar 14, 2019 at 2:44 PM Shayne Fletcher via ghc-devs < ghc-devs at haskell.org> wrote: > `git clone git at github.com:ghc/ghc.git` followed by `git submodule update > --init --recursive` results in > ``` > > error: Server does not allow request for unadvertised object > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 > > Fetched in submodule path 'libraries/binary', but it did not contain > 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit > failed. > ``` > -- > 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 > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Thu Mar 14 19:02:49 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 14 Mar 2019 15:02:49 -0400 Subject: github ghc.git broken on libraries/binary In-Reply-To: References: Message-ID: I'm between a rock and a hard place here. I appreciate gitlab hosts the official upstream (and at work use it extensively). We do however also maintain a fork of the github mirror on github (rightly or wrongly) and its existence and correctness is critical to some of our workflows. So, beyond this issue today which I assume to be temporary, going forward can I assume no guarantees about its reliability and do I have to advocate rejigging those aforementioned workflows so that github is out of the picture? On Thu, Mar 14, 2019 at 2:53 PM Brandon Allbery wrote: > As yet mirroring github from gitlab is broken, I think (various parts of > the migration are not yet complete); you should use the gitlab upstream. > > On Thu, Mar 14, 2019 at 2:44 PM Shayne Fletcher via ghc-devs < > ghc-devs at haskell.org> wrote: > >> `git clone git at github.com:ghc/ghc.git` followed by `git submodule update >> --init --recursive` results in >> ``` >> >> error: Server does not allow request for unadvertised object >> 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 >> >> Fetched in submodule path 'libraries/binary', but it did not contain >> 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit >> failed. >> ``` >> -- >> 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 >> > > > -- > brandon s allbery kf8nh > allbery.b at gmail.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 ben at well-typed.com Thu Mar 14 21:05:02 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 14 Mar 2019 17:05:02 -0400 Subject: github ghc.git broken on libraries/binary In-Reply-To: References: Message-ID: <87ef79np54.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > I'm between a rock and a hard place here. I appreciate gitlab hosts the > official upstream (and at work use it extensively). We do however also > maintain a fork of the github mirror on github (rightly or wrongly) and its > existence and correctness is critical to some of our workflows. Hi Shayne, I have been working to resolve the issue. Unfortunately, the process has been complicated by the fact that GitHub has flagged our mirror account as a bot and the credentials of an older mirror account have been lost to history. I am engaging with GitHub to resolve this but this has taken longer than expected. I will leave updates on the tracking ticket [1] as the situation develops. In the meantime I have manually updated these GitHub mirror repositories. I will try to do this on a daily basis until the situation is resolved. > So, beyond this issue today which I assume to be temporary, going > forward can I assume no guarantees about its reliability and do I have > to advocate rejigging those aforementioned workflows so that github is > out of the picture? > In general the mirror is maintained and we have no intention of dropping it. However, in the last week other responsibilities, coupled with the latency of working with GitHub support, has meant that bringing it back online has taken longer than I would have preferred. Sorry for the inconvenience. However, do keep in mind that even when working normally the GitHub mirror has a synchronization period of 20 minutes; if your systems depend upon having a consistent picture of the GHC repositories then you might consider using the official upstream. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/11 -------------- 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 Thu Mar 14 21:50:40 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 14 Mar 2019 17:50:40 -0400 Subject: github ghc.git broken on libraries/binary In-Reply-To: <87ef79np54.fsf@smart-cactus.org> References: <87ef79np54.fsf@smart-cactus.org> Message-ID: Hi Ben, On Thu, Mar 14, 2019 at 5:05 PM Ben Gamari wrote: > Shayne Fletcher via ghc-devs writes: > > > I'm between a rock and a hard place here. I appreciate gitlab hosts the > > official upstream (and at work use it extensively). We do however also > > maintain a fork of the github mirror on github (rightly or wrongly) and > its > > existence and correctness is critical to some of our workflows. > > Hi Shayne, > > I have been working to resolve the issue. Unfortunately, the process has > been complicated by the fact that GitHub has flagged our mirror account > as a bot and the credentials of an older mirror account have been lost > to history. I am engaging with GitHub to resolve this but this has taken > longer than expected. I will leave updates on the tracking ticket [1] as > the situation develops. > > In the meantime I have manually updated these GitHub mirror > repositories. I will try to do this on a daily basis until the situation > is resolved. > > > So, beyond this issue today which I assume to be temporary, going > > forward can I assume no guarantees about its reliability and do I have > > to advocate rejigging those aforementioned workflows so that github is > > out of the picture? > > > In general the mirror is maintained and we have no intention of dropping > it. However, in the last week other responsibilities, coupled with the > latency of working with GitHub support, has meant that bringing it back > online has taken longer than I would have preferred. Sorry for the > inconvenience. > Not at all Ben. All totally understandable and I hope you know how much I (we) appreciate how much you are doing for us! If I gave a different impression in my original post, please be assured, that wasn't intentional :) > > However, do keep in mind that even when working normally the GitHub > mirror has a synchronization period of 20 minutes; if your systems > depend upon having a consistent picture of the GHC repositories then > you might consider using the official upstream. > We can totally live with the synchronization lag in this instance. In summary, I'm happy to leave things be with the understanding that stability to will naturally improve and we just need to demonstrate some patience while things get ironed out! Thanks for taking time out to catch me up! > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/11 > > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCAAdFiEEmwpsh4C13+CdDZRjcVB86Evun78FAlyKwfcACgkQcVB86Evu > n78CJQf/V19WmieWw6fs+rCSFEtfZvsQW+wFtDewqrpBgvW5hIC3Br3s032DCEUA > nc8N3EteX9GExwNO7KkzCb/6vosmm9O7r+s3MQdY3CB69K0Yg3uXwfUXjttoneXB > l65fIonx5pcgvVFsa2QLIyOmYUq3lpZg0MEQjtLBZBnWa2H4WylRyU3hIdmMQZui > Ttt0TcJ4pWNGf3DgXU1EPD7FLdTkjlX2lptxh+r3uRzrqgGTSGCplOFJVk6ER8xA > WqQho8lGz1DAuU2noezQZLDGR7dbhk7ZFUT2ycubNBi5UdSicoSW5H1zXZ+9vaJK > 7vx1i3crhurIrjEcteKTLsmZBr4oWg== > =gqDF > -----END PGP SIGNATURE----- -- 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 moritz.angermann at gmail.com Fri Mar 15 02:09:53 2019 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 15 Mar 2019 10:09:53 +0800 Subject: Discussion: Hadrian's defaults In-Reply-To: References: Message-ID: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> > On Mar 15, 2019, at 2:19 AM, Herbert Valerio Riedel wrote: > On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud wrote: > • The -c option should be the default. > Very strong -1 from me on this one; I've been quite vocal on the Hadrian issue tracker early on and multiple times against having Hadrian invoke ./configure at all, even more so against having it do so by default. I don't have the ticket number at my fingertips but it should be fairly easy to find. I'm with Herbert here. I think that the `-c` flag should be mandatory if you want hadrian to invoke autoconf magic. I believe the confusion might stem from the newcomers guide[1]? I'd rather see the newcomers guide *not* use `-c`, and instead make it obvious to call `boot` and `configure`. These are essential steps and hiding them makes them less obvious. `boot` does - (1) checks that url rewrites are in place. - (2) checks that all bootpackages are available - (3) run autoreconf as needed - (4) and generates a bunch of make files for the make based build system. (4) can be disabled by passing `--hadrian` to `boot`. (1) is needed due to the relative submodules I beleive. `configure` generates the necessary configuration files based on the configure flags passed. And hadrian does the actual build step that `make` used to do. It's magically conflating two different phases with `-c`. The configure phase and the build phase. Making this the default means it's always magic. I don't like magic! Cheers, Moritz -- [1]: https://github.com/tdammers/ghc-wiki/blob/wip/newcomers/newcomers-tutorial.md -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From arnaud.spiwack at tweag.io Fri Mar 15 12:32:35 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 15 Mar 2019 13:32:35 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> Message-ID: On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel wrote: > I don't have the ticket number at my fingertips but it should be fairly > easy to find. > I'm afraid it doesn't appear to be. Could you share your arguments in this thread? On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann wrote: > It's magically conflating two different phases with `-c`. The configure > phase and > the build phase. Making this the default means it's always magic. I don't > like magic! > Unfortunately, I really don't understand what you are saying. What's magic about combining the phases? -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Fri Mar 15 13:35:28 2019 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 15 Mar 2019 21:35:28 +0800 Subject: Discussion: Hadrian's defaults In-Reply-To: References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> Message-ID: <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Hi Arnaud, > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud wrote: > > On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel wrote: > I don't have the ticket number at my fingertips but it should be fairly easy to find. > > I'm afraid it doesn't appear to be. Could you share your arguments in this thread? This was the last one that lead to the current `-c` state: - https://github.com/snowleopard/hadrian/issues/457 There is also - https://github.com/snowleopard/hadrian/issues/655 if you look through the issues on snowleopard/hadrian and sort by comment frequency you'll likely find quite a lot of further discussion about not making configure and boot the default. > > On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann wrote: > It's magically conflating two different phases with `-c`. The configure phase and > the build phase. Making this the default means it's always magic. I don't like magic! > > Unfortunately, I really don't understand what you are saying. What's magic about combining the phases? We have two phases: Phase 1: autoconf This phase is essentially a code-generation phase, where specific templates are instantiated to configure time value. Which again can be split into two specific subproblems: - Generation of the configure script from the configure.ac and aclocal.m4 files using autoconf. - Generating code using the configure script by computing configure time calues and filling those into the `.in` files producing the files that lack the `.in` extension. Phase 2: building This has been traditionally the job of make, and this is what hadrian should replace. By subsuming the configure phase (by invoking ./configure) from hadrian we loose the phase distinction and if the `-c` flag is optional, users will *not even see* a flag that indicates that the system will run `./configure` for them. This is the magic I'm referring to and to which I strongly object. If we can retire autoconf and do the whole configuration in hadrian, that story may change. But as long as we are using an autoconf based configuration we should *not* run that magically. The `-c` flag is at least there to show that hadrian is explicilty instructed to run configure. ./configure supports its own set of flags, if hadrian subsumes those, we'd need some generic way of passing flags to ./configure, at which point I have to ask why do we do this in the first place and try to call ./configure from within hadrian? Unless you want to reconfigure ghc, or hack on it's autoconf part, you are likely going to run the following only: ./boot --hadrian ./configure ./hadrian/build.sh -j ... ./hadrian/build.sh -j ... ./hadrian/build.sh -j ... ./hadrian/build.sh -j ... ... the configure step is required, and should be explicit. That is where you configure your ghc build. Set host/build/target values, and other configure flags that influence how you want your ghc to be configure. Hadrian is there to build that configuration. Mixing both may be convenient but hides the fact that there is a ./configure step. I consider this hiding to be magic which is meant to benefit the user but hides what's really going on. And again I don't like magic. Cheers, Moritz PS: we also don't hide the `./configure` step in the usual `./configure && make -j` instructions when building other software, even though you could surely hack that into your Makefile if you so wanted to. Why start with ghc now? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From andrey.mokhov at newcastle.ac.uk Fri Mar 15 14:55:16 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Fri, 15 Mar 2019 14:55:16 +0000 Subject: Discussion: Hadrian's defaults References: Message-ID: Hi Arnaud, Great to hear you've been using Hadrian for a while and like it! As others have already pointed, -c used to be default. I personally was always inclined to run boot and configure by default, because to me they seem like an unnecessary complication on the way to the first GHC build (they confused me a lot when I did my first GHC build). On the other hand, people who strongly oppose -c being default are all expert users of configure, and should be capable of passing --skip-configure when need be (or always). It's good to discuss this and see what proportion of GHC developers would prefer to include -c by default. So far the opponents were much more vocal. Making --freeze1 default is probably fine. If we go this way, there should be a big warning in the documentation saying that this default setting is convenient but unsafe, i.e. can produce wrong binaries. I think --share is not ready to become default. Hopefully, it will be in 1-2 months! Cheers, Andrey From alp at well-typed.com Fri Mar 15 15:51:35 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Fri, 15 Mar 2019 16:51:35 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: <915c0bf9-c2e4-0141-2a54-7e6bee35856d@well-typed.com> I have to admit I sympathize with Moritz's view. Since `-c` only "subsumes" the case where we call 'configure' with no extra env var or argument, and in the absence of a generic way to pass options to 'configure' when using -c, I'd quite like to keep -c as a "cherry on top", for users who just need to boot and configure with the default arguments and for whom hadrian provides a way to save a few keystrokes. Just like Moritz, I'm not even sure it would make all that much sense to provide a way to pass configure arguments through hadrian, I have a hard time seeing a better UX than just running configure with the extra arguments directly and _then_ calling hadrian to start the build. On 15/03/2019 14:35, Moritz Angermann wrote: > Hi Arnaud, > >> On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud wrote: >> >> On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel wrote: >> I don't have the ticket number at my fingertips but it should be fairly easy to find. >> >> I'm afraid it doesn't appear to be. Could you share your arguments in this thread? > This was the last one that lead to the current `-c` state: > - https://github.com/snowleopard/hadrian/issues/457 > There is also > - https://github.com/snowleopard/hadrian/issues/655 > > if you look through the issues on snowleopard/hadrian and sort by comment frequency > you'll likely find quite a lot of further discussion about not making configure and > boot the default. > >> On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann wrote: >> It's magically conflating two different phases with `-c`. The configure phase and >> the build phase. Making this the default means it's always magic. I don't like magic! >> >> Unfortunately, I really don't understand what you are saying. What's magic about combining the phases? > We have two phases: > > Phase 1: autoconf > > This phase is essentially a code-generation phase, where specific templates are > instantiated to configure time value. Which again can be split into two specific > subproblems: > > - Generation of the configure script from the configure.ac and aclocal.m4 files > using autoconf. > - Generating code using the configure script by computing configure time calues > and filling those into the `.in` files producing the files that lack the `.in` > extension. > > Phase 2: building > > This has been traditionally the job of make, and this is what hadrian should > replace. > > > By subsuming the configure phase (by invoking ./configure) from hadrian we loose > the phase distinction and if the `-c` flag is optional, users will *not even see* > a flag that indicates that the system will run `./configure` for them. This is the > magic I'm referring to and to which I strongly object. If we can retire autoconf > and do the whole configuration in hadrian, that story may change. But as long as > we are using an autoconf based configuration we should *not* run that magically. > The `-c` flag is at least there to show that hadrian is explicilty instructed to > run configure. > > ./configure supports its own set of flags, if hadrian subsumes those, we'd need > some generic way of passing flags to ./configure, at which point I have to ask > why do we do this in the first place and try to call ./configure from within hadrian? > > Unless you want to reconfigure ghc, or hack on it's autoconf part, you are likely > going to run the following only: > > ./boot --hadrian > ./configure > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ... > > the configure step is required, and should be explicit. That is where you configure > your ghc build. Set host/build/target values, and other configure flags that > influence how you want your ghc to be configure. Hadrian is there to build that > configuration. Mixing both may be convenient but hides the fact that there is a > ./configure step. I consider this hiding to be magic which is meant to benefit the > user but hides what's really going on. And again I don't like magic. > > Cheers, > Moritz > > PS: we also don't hide the `./configure` step in the usual `./configure && make -j` > instructions when building other software, even though you could surely hack that into > your Makefile if you so wanted to. Why start with ghc now? > > _______________________________________________ > 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 allbery.b at gmail.com Fri Mar 15 15:52:40 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 15 Mar 2019 11:52:40 -0400 Subject: Discussion: Hadrian's defaults In-Reply-To: <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: Expanding on Moritz a bit: configure creates a build plan, hadrian runs it. Newcomers to autoconf-based ecosystems often add a rule to run configure to their Makefiles, as a "shortcut". At some time thereafter, they discover that there's a problem when configure alters the build plan make is executing. There's no sane way to integrate this properly if the build plan changes enough, even if configure is always the very first thing executed as part of the original build plan. This generally results in forcing make to abort after running autoconf, since trying to be more clever results in looping over configure. The only other way that works is arranging for 2-stage Makefiles where the outer one amounts to "configure && make -f Makefile.real". Which makes it noticeably more error-prone to tweak something and do a fast rebuild, since configure will often cause it to be a full rebuild instead. If you try to give configure dependencies so that it doesn't get re-run, you discover that it's dependent in some sense on its own outputs and again can cause loops. Trying to integrate configure with hadrian runs the same risk, heightened by hadrian not using anything like Makefiles, so it would be even easier for it to either miss changes made by configure or end up looping on it. Or worse, the same with autoconf — or for ghc, the boot script which runs autoconf, among other things, and thus has even nastier risks in terms of missing important changes made thereby or causing loops. Really, don't try to conflate these; someone is going to end up very unhappy. On Fri, Mar 15, 2019 at 9:35 AM Moritz Angermann wrote: > Hi Arnaud, > > > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud > wrote: > > > > On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel < > hvriedel at gmail.com> wrote: > > I don't have the ticket number at my fingertips but it should be fairly > easy to find. > > > > I'm afraid it doesn't appear to be. Could you share your arguments in > this thread? > This was the last one that lead to the current `-c` state: > - https://github.com/snowleopard/hadrian/issues/457 > There is also > - https://github.com/snowleopard/hadrian/issues/655 > > if you look through the issues on snowleopard/hadrian and sort by comment > frequency > you'll likely find quite a lot of further discussion about not making > configure and > boot the default. > > > > > On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann < > moritz.angermann at gmail.com> wrote: > > It's magically conflating two different phases with `-c`. The configure > phase and > > the build phase. Making this the default means it's always magic. I > don't like magic! > > > > Unfortunately, I really don't understand what you are saying. What's > magic about combining the phases? > > We have two phases: > > Phase 1: autoconf > > This phase is essentially a code-generation phase, where specific > templates are > instantiated to configure time value. Which again can be split into two > specific > subproblems: > > - Generation of the configure script from the configure.ac and > aclocal.m4 files > using autoconf. > - Generating code using the configure script by computing configure time > calues > and filling those into the `.in` files producing the files that lack > the `.in` > extension. > > Phase 2: building > > This has been traditionally the job of make, and this is what hadrian > should > replace. > > > By subsuming the configure phase (by invoking ./configure) from hadrian we > loose > the phase distinction and if the `-c` flag is optional, users will *not > even see* > a flag that indicates that the system will run `./configure` for them. > This is the > magic I'm referring to and to which I strongly object. If we can retire > autoconf > and do the whole configuration in hadrian, that story may change. But as > long as > we are using an autoconf based configuration we should *not* run that > magically. > The `-c` flag is at least there to show that hadrian is explicilty > instructed to > run configure. > > ./configure supports its own set of flags, if hadrian subsumes those, we'd > need > some generic way of passing flags to ./configure, at which point I have to > ask > why do we do this in the first place and try to call ./configure from > within hadrian? > > Unless you want to reconfigure ghc, or hack on it's autoconf part, you are > likely > going to run the following only: > > ./boot --hadrian > ./configure > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ... > > the configure step is required, and should be explicit. That is where you > configure > your ghc build. Set host/build/target values, and other configure flags > that > influence how you want your ghc to be configure. Hadrian is there to build > that > configuration. Mixing both may be convenient but hides the fact that > there is a > ./configure step. I consider this hiding to be magic which is meant to > benefit the > user but hides what's really going on. And again I don't like magic. > > Cheers, > Moritz > > PS: we also don't hide the `./configure` step in the usual `./configure > && make -j` > instructions when building other software, even though you could > surely hack that into > your Makefile if you so wanted to. Why start with ghc now? > _______________________________________________ > 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 ben at well-typed.com Fri Mar 15 17:28:21 2019 From: ben at well-typed.com (Ben Gamari) Date: Fri, 15 Mar 2019 13:28:21 -0400 Subject: Discussion: Hadrian's defaults In-Reply-To: <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: <875zsknj2x.fsf@smart-cactus.org> Moritz Angermann writes: > Hi Arnaud, > ... I second everything that Moritz said. Having spent countless hours fighting other projects' "non-traditional" build systems in the past, my heart fills with dread whenever I see a project trying to be "clever" with autoconf. Inevitably such cleverness ends up being a source poorly-documented, unpredictable, and at times broken behavior which inevitably complicates the task of building the project in any non-trivial configuration (for instance, cross-compilation). We should keep in mind that users and packagers, not GHC developers, are the primary audience of GHC's build system. For their sake we should strive to keep GHC's build system as close to the usual configure/make/make install workflow as possible. In fact, I have at times wondered whether when we switch to Hadrian as our primary build system we should ship our source distributions with a stub makefile to build and run hadrian, allowing downstreams to treat the distribution as a normal autotools-based package. 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 Sun Mar 17 01:29:12 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 16 Mar 2019 21:29:12 -0400 Subject: GitLab updates Message-ID: <87sgvmmgpo.fsf@smart-cactus.org> Hi everyone, I want to share a few developments on the GitLab migration front: * URLs pointing to tickets or the Wiki which were previously served by Trac (https://ghc.haskell.org/) now redirect to their corresponding GitLab URL. Wiki page names are redirected via this mapping [1]. If you find any cases were this doesn't work as you would expect then please do let me know or open a ticket [4]. If you do want to view Trac you may do so (for the time being) at https://trac.haskell.org/. In the coming days I will be taking a final static archival snapshot of our Trac instance and in the next few weeks we will likely shut it down. * This afternoon I imported [2] a few dozen keywords from Trac that were omitted from the initial import. At this point the ghc/ghc project has nearly 100 labels. It's unclear how usable this will be without either paring down the label space or imposing some sort of order (e.g. adding categorical prefixes to label names) but time will tell. * Our GitLab installation has been upgraded to GitLab 11.8. The changes are relatively minor but I am sure you will spot them. * The source for GHC's homepage (https://www.haskell.org/ghc) is now hosted in the ghc/homepage project [3]. If you find anything wrong with the website feel free to submit a merge request. As always, if you find anything amiss don't hesitate to ping me or open a ticket [4]. Note that the Wiki is still in need of quite a bit of cleanup [5]. If you have some time and want to help out either pick up a ticket or just start browsing and clean-up the first page you find. Many hands makes for light work. However, if you end up renaming any Wiki pages please do open a merge request updating `wiki-mapping.json` [1]. Thank you for your patience while we push through the remaining parts of the migration. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json [2] https://gitlab.haskell.org/bgamari/trac-to-remarkup/commit/4104086bca53528b092ad907b6d1f57c5b140587#b39596681b9e4fc60d716cdc07030e8064b03d73_70_72 [3] https://gitlab.haskell.org/ghc/homepage [4] https://gitlab.haskell.org/bgamari/gitlab-migration/issues [5] https://gitlab.haskell.org/bgamari/gitlab-migration/issues?label_name%5B%5D=Wiki -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From julian at leviston.net Sun Mar 17 07:39:38 2019 From: julian at leviston.net (Julian Leviston) Date: Sun, 17 Mar 2019 18:39:38 +1100 Subject: Wiki search & pages Message-ID: Hi, When I started this message, I couldn't find the commentary in the wiki any more. Also, when I try to search with the “search or jump to” box, it sits on “Loading” for quite a while, then I get impatient (after 20 seconds or so), and click off it, but the drop down box doesn’t go away, so I remove the word “Commentary” from the search box, and the drop down box is replaced by a bunch of preset searches. I can’t seem to get it to go away then. Also, down the right hand side of the wiki are a bunch of links which seem to be the first 20 or so, sorted alphabetically, rather than the relevant navigation links in the old trac wiki side nav. I can’t seem to work out how to navigate my way around to find the commentary anymore :( If I type commentary and hit enter, on other hand, it comes up with search results, but it’s quite slow (takes 5 seconds or so to get that page up generally, and feels kind of buggy). That brings up the main commentary page, except I really miss the side-nav that indicated where I was located in the wiki (I realise there’s a breadcrumbs at the top… it says “GHC > Wiki > commentary”, but the commentary page is definitely *not* on the GHC > Wiki page… this makes me feel kind of “lost”. How is a new person supposed to discover these pages exist? Sorry I don’t want to be whining, but this seems quite important. Navigating between pages seems quite slow (3 or 4 seconds between page loads). Maybe it’s fine and I’ll get used to it with time. Hope so. Julian From julian at leviston.net Sun Mar 17 07:56:46 2019 From: julian at leviston.net (Julian Leviston) Date: Sun, 17 Mar 2019 18:56:46 +1100 Subject: Wiki Diagrams In-Reply-To: References: Message-ID: <2395CAF0-BA24-479E-8162-EBEED1F03ACC@leviston.net> Hello again, I just also noticed that the diagrams for the compiler pipeline seem to have disappeared. I refer to those diagrams all the time when I’m working on GHC, so I’d really like it if they could come back somehow. Julian From ben at smart-cactus.org Sun Mar 17 08:47:16 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 17 Mar 2019 04:47:16 -0400 Subject: Wiki search & pages In-Reply-To: References: Message-ID: <87o969nb02.fsf@smart-cactus.org> Julian Leviston writes: > Hi, > > When I started this message, I couldn't find the commentary in the > wiki any more. > > Also, when I try to search with the “search or jump to” box, it sits > on “Loading” for quite a while, then I get impatient (after 20 seconds > or so), and click off it, but the drop down box doesn’t go away, so I > remove the word “Commentary” from the search box, and the drop down > box is replaced by a bunch of preset searches. I can’t seem to get it > to go away then. > I have also noticed this. The relevant upstream ticket is [1]. The problem appears to be that an empty search result set is returned (strangely) but the user interface is not updated. > Also, down the right hand side of the wiki are a bunch of links which > seem to be the first 20 or so, sorted alphabetically, rather than the > relevant navigation links in the old trac wiki side nav. I can’t seem > to work out how to navigate my way around to find the commentary > anymore :( > Yes, GitLab's wiki page list is unfortunately very hard to use in the case of large Wiki [2] like GHC's. > If I type commentary and hit enter, on other hand, it comes up with > search results, but it’s quite slow (takes 5 seconds or so to get that > page up generally, and feels kind of buggy). That brings up the main > commentary page, except I really miss the side-nav that indicated > where I was located in the wiki (I realise there’s a breadcrumbs at > the top… it says “GHC > Wiki > commentary”, but the commentary page is > definitely *not* on the GHC > Wiki page… this makes me feel kind of > “lost”. > The Wiki does indeed have a number of problems: 1. The permissions model is too restrictive (https://gitlab.haskell.org/bgamari/gitlab-migration/issues/16) 2. The pages list is slow (https://gitlab.com/gitlab-org/gitlab-ce/issues/57751) 3. The pages list doesn't reflect hierarchy (https://gitlab.com/gitlab-org/gitlab-ce/issues/57751) 4. Breadcrumbs don't reflect hierarchy (https://gitlab.com/gitlab-org/gitlab-ce/issues/30441) I'm aware and am pushing for fixing for all of these: 1. I have a small patch which looses wiki permissions which I will try deploying on Monday. Upstream has also said they are interested in fixing the issue. 2. Upstream is working on improving the situation (https://gitlab.com/gitlab-org/gitlab-ce/issues/53523) 3. I have pinged upstream about this and they are planning work in this area (https://gitlab.com/groups/gitlab-org/-/epics/700) 4. This also falls under https://gitlab.com/groups/gitlab-org/-/epics/700. > How is a new person supposed to discover these pages exist? Sorry I > don’t want to be whining, but this seems quite important. > Indeed it is important and the status quo is not good. In the short term we have implemented a workaround in the form of a manually generated table of contents page [3]. This is linked to from the Wiki homepage [4] but admittedly this is pretty easy to miss. I suspect I will need to patch the wiki page rendering to make it more visible. I have opened [5] to track this. Currently the index is not automatically regenerated when the Wiki changes but this is on my list of things to fix [6]. > Navigating between pages seems quite slow (3 or 4 seconds between page > loads). > That is true. > Maybe it’s fine and I’ll get used to it with time. Hope so. > I also hope this improves. The currently situation is quite far from okay, but upstream has been quite responsive to our issues and is working actively to improve it. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/51863 [2] https://gitlab.com/gitlab-org/gitlab-ce/issues/57751 [3] https://gitlab.haskell.org/ghc/ghc/wikis/index [4] https://gitlab.haskell.org/ghc/ghc/wikis [5] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/48 [6] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/12 -------------- 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 smart-cactus.org Sun Mar 17 08:48:44 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 17 Mar 2019 04:48:44 -0400 Subject: Wiki Diagrams In-Reply-To: <2395CAF0-BA24-479E-8162-EBEED1F03ACC@leviston.net> References: <2395CAF0-BA24-479E-8162-EBEED1F03ACC@leviston.net> Message-ID: <87lg1dnaxk.fsf@smart-cactus.org> Julian Leviston writes: > Hello again, > > I just also noticed that the diagrams for the compiler pipeline seem > to have disappeared. I refer to those diagrams all the time when I’m > working on GHC, so I’d really like it if they could come back somehow. > Yes, this is a known issue [1] and we are working on restoring them. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/41 -------------- 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 Sun Mar 17 17:50:03 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sun, 17 Mar 2019 13:50:03 -0400 Subject: [ambiguous occurrence bug?] Message-ID: Sorry in advance if I should be posting questions of this kind elsewhere (please tell me if so!). Consider this two file program: ``` module T where main = undefined module Main where import T main = putStrLn "Hello world!" ``` Both 8.4.3 and 8.6.3 agree: ``` Main.hs:1:1: error: Ambiguous occurrence ‘main’ It could refer to either ‘T.main’, imported from ‘T’ at Main.hs:2:1-8 (and originally defined at Main.hs:2:1-4) or ‘Main.main’, defined at Main.hs:5:1 ``` Is this expected behavior? Does it not contradict "If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported" ( https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the latter, is this a bug? 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 allbery.b at gmail.com Sun Mar 17 18:09:01 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 17 Mar 2019 14:09:01 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: No contradiction: "not those that are imported" means a module which imports names does not automatically re-export those names to other modules that import it. So T does indeed export "main", which is imported unqualified by Main and thereby causes an ambiguous occurrence. But if T had imported "main" from a third module, it would not be exported for Main to import unless the export from T was explicit. On Sun, Mar 17, 2019 at 1:50 PM Shayne Fletcher via ghc-devs < ghc-devs at haskell.org> wrote: > Sorry in advance if I should be posting questions of this kind elsewhere > (please tell me if so!). > > Consider this two file program: > ``` > module T where > main = undefined > > module Main where > import T > main = putStrLn "Hello world!" > ``` > > Both 8.4.3 and 8.6.3 agree: > ``` > Main.hs:1:1: error: > Ambiguous occurrence ‘main’ > It could refer to either ‘T.main’, > imported from ‘T’ at Main.hs:2:1-8 > (and originally defined at Main.hs:2:1-4) > or ‘Main.main’, defined at Main.hs:5:1 > ``` > > Is this expected behavior? Does it not contradict "If the export list is > omitted, all values, types and classes defined in the module are exported, > but not those that are imported" ( > https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the > latter, is this a bug? 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. > _______________________________________________ > 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 shayne.fletcher at daml.com Sun Mar 17 18:16:43 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sun, 17 Mar 2019 14:16:43 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: Hi Brandon, On Sun, Mar 17, 2019 at 2:09 PM Brandon Allbery wrote: > No contradiction: "not those that are imported" means a module which > imports names does not automatically re-export those names to other modules > that import it. So T does indeed export "main", which is imported > unqualified by Main > No argument with anything said there. > and thereby causes an ambiguous occurrence. > This I don't get. I presume the ambiguous occurrence is due to the question what `main` is `Main.hs` exporting (or in this case is the "entry-point" for the program)? My reading of the above is that only the local `main` can be exported (or again, in this case, "considered" for the "entry-point") so where is the ambiguity? -- 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 allbery.b at gmail.com Sun Mar 17 18:23:35 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 17 Mar 2019 14:23:35 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: Hm. You're probably right that it should only consider the locally defined one, but I can see why it would do this and wonder if there's even a good way to constrain that check currently. On Sun, Mar 17, 2019 at 2:16 PM Shayne Fletcher wrote: > Hi Brandon, > > On Sun, Mar 17, 2019 at 2:09 PM Brandon Allbery > wrote: > >> No contradiction: "not those that are imported" means a module which >> imports names does not automatically re-export those names to other modules >> that import it. So T does indeed export "main", which is imported >> unqualified by Main >> > > No argument with anything said there. > > >> and thereby causes an ambiguous occurrence. >> > > This I don't get. I presume the ambiguous occurrence is due to the > question what `main` is `Main.hs` exporting (or in this case is the > "entry-point" for the program)? My reading of the above is that only the > local `main` can be exported (or again, in this case, "considered" for the > "entry-point") so where is the ambiguity? > > -- > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Sun Mar 17 18:29:47 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Sun, 17 Mar 2019 14:29:47 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery wrote: > Hm. You're probably right that it should only consider the locally defined > one, > Cool. > but I can see why it would do this > Can you elaborate? Perhaps, > and wonder if there's even a good way to constrain that check currently. > > indicates that you can see why it might be so based on knowledge of the implementation? -- 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 allbery.b at gmail.com Sun Mar 17 18:35:04 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 17 Mar 2019 14:35:04 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: I'm guessing, but I suspect currently the only way to look up a symbol either requires explicit qualification of the symbol name or that the symbol be part of a class or instance declaration that implicitly qualifies method and associated type names. So for the implicit export list to retrieve the local symbol definition, it would have to explicitly request the local one instead of simply passing the name. (But getting the local names, without their definitions, wouldn't hit this. Maybe that should return explicitly qualified names, but I could see that causing problems with ghci; consider ":browse". And that it already handles qualification somewhat oddly because multiple modules can be in scope; "import" doesn't mean quite the same thing in ghci as in ghc, and can't without making its interactive use rather more painful when multiple modules are in scope.) On Sun, Mar 17, 2019 at 2:30 PM Shayne Fletcher wrote: > > On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery > wrote: > >> Hm. You're probably right that it should only consider the locally >> defined one, >> > > Cool. > > >> but I can see why it would do this >> > Can you elaborate? Perhaps, > > >> and wonder if there's even a good way to constrain that check currently. >> >> > indicates that you can see why it might be so based on knowledge of the > implementation? > > -- > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian at leviston.net Sun Mar 17 20:35:41 2019 From: julian at leviston.net (Julian Leviston) Date: Mon, 18 Mar 2019 07:35:41 +1100 Subject: Wiki search & pages In-Reply-To: <87o969nb02.fsf@smart-cactus.org> References: <87o969nb02.fsf@smart-cactus.org> Message-ID: <55C33B21-198C-4AE4-A0F5-92CB7B5C9145@leviston.net> Wow! thank you so much for such a detailed reply, Ben. Makes me wish there was some way you could link to a blog entry of the current ongoing stuff and just write it down once in there as it happens rather than have to repeat it whenever someone asks to save you effort of repetition, but maybe the email history of this list suffices. Thanks for putting in so much comprehensive effort. Julian > On 17 Mar 2019, at 7:47 pm, Ben Gamari wrote: > > (replies removed) > > I also hope this improves. The currently situation is quite far from > okay, but upstream has been quite responsive to our issues and is > working actively to improve it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Mar 18 02:08:14 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Sun, 17 Mar 2019 22:08:14 -0400 Subject: searching for tickets Message-ID: Hi devs, Previously, I could effectively use Google as a way to search for contents in tickets, with a query like > site:ghc.haskell.org/blah/blah/tickets type families (I can't remember the exact URL, and Trac has been taken down so I can't figure it out.) Now, though, when I search for > site:gitlab.haskell.org/ghc/ghc/issues/ type families I get nothing. Is there something in our setup that stops Google from indexing our issues? Or has Google just missed the memo about the issues page being opened up? Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Mar 18 02:12:46 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Sun, 17 Mar 2019 22:12:46 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: <31342CE9-A0F9-4C70-B33A-4BADE6F7594C@richarde.dev> This looks like a bug to me. Post at https://gitlab.haskell.org/ghc/ghc/issues/ Thanks! Richard > On Mar 17, 2019, at 1:50 PM, Shayne Fletcher via ghc-devs wrote: > > Sorry in advance if I should be posting questions of this kind elsewhere (please tell me if so!). > > Consider this two file program: > ``` > module T where > main = undefined > > module Main where > import T > main = putStrLn "Hello world!" > ``` > > Both 8.4.3 and 8.6.3 agree: > ``` > Main.hs:1:1: error: > Ambiguous occurrence ‘main’ > It could refer to either ‘T.main’, > imported from ‘T’ at Main.hs:2:1-8 > (and originally defined at Main.hs:2:1-4) > or ‘Main.main’, defined at Main.hs:5:1 > ``` > > Is this expected behavior? Does it not contradict "If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported" (https://www.haskell.org/onlinereport/haskell2010/haskellch5.html )? If the latter, is this a bug? 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._______________________________________________ > 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 Mon Mar 18 10:12:29 2019 From: rsx at bluewin.ch (Roland Senn) Date: Mon, 18 Mar 2019 11:12:29 +0100 Subject: Trac -> Gitlab migration: A little issue with assignees Message-ID: <1552903949.2142.3.camel@bluewin.ch> After some days off, I returned to my work on GHC. I looked up my tickets in Gitlab with a search on assignee=RolandSenn [1].  The system returned a list of 8 open tickets.  Two of them are interesting: #14025 and #15336. Once upon a time I assigned them to me, worked on them, but unfortunately then I found them too difficult. So a couple of weeks ago I unassigned them in the good old Trac system. It seems, that these unassign operations weren't copied to Gitlab! For my 2 tickets, this is no problem, I can re-unassign them manually. However, I think, there are other tickets that were unassinged by their previous owners some time ago. Most probably some or all of them now got re-assinged during the migration to Gitlab.  [1] https://gitlab.haskell.org/ghc/ghc/issues?scope=all&utf8=%E2%9C%93& state=opened&assignee_username[]=RolandSenn From ben at smart-cactus.org Mon Mar 18 16:19:42 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 18 Mar 2019 12:19:42 -0400 Subject: searching for tickets In-Reply-To: References: Message-ID: <875zsgm9yb.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi devs, > > Previously, I could effectively use Google as a way to search for > contents in tickets, with a query like > >> site:ghc.haskell.org/blah/blah/tickets >> type families > > (I can't remember the exact URL, and Trac has been taken down so I > can't figure it out.) > > Now, though, when I search for > >> site:gitlab.haskell.org/ghc/ghc/issues/ >> type families > > I get nothing. Is there something in our setup that stops Google from > indexing our issues? Or has Google just missed the memo about the > issues page being opened up? > I checked via Google's search console and it seems that the issue is merely that Google hasn't yet indexed our tickets on GitLab. I have requested that it index one particular issue to make sure that there is nothing preventing issues from being indexed. I'm still waiting for the result but if there are any issues I'll see to it that they are resolved. 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 Mon Mar 18 22:42:43 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 18 Mar 2019 22:42:43 +0000 Subject: GHC | Work out how to manage labels (#16458) In-Reply-To: References: Message-ID: Useful categorisation * I’d favour using colour to separate the different groups. * I think we could collapse 4 and 5 into one group (one colour) Simon From: Ben Gamari Sent: 18 March 2019 21:39 To: Simon Peyton Jones Subject: GHC | Work out how to manage labels (#16458) Currently ghc/ghc> has nearly 100 labels. These fall into a variety of categories: 1. Labels that classify the ticket (bug, feature request, task) 2. Labels that classify bugs by their manifestation: compiler perf, compiler crash, ghc build failure 3. Labels that specify the environmental conditions under which an issue will manifest: * architectures: ARM, SPARC, PowerPC * operating system: ~OpenBSD, Windows, macOS 1. Labels that specify which compiler or program features are implicated in a bug * language extensions: ImpredicativeTypes, ~FlexibleContexts, UnboxedTuples * program constructs: join points, levity polymorphism, STM * compiler feature: recompilation checking, cpp, debug information, ~"cross compilation" 1. Labels that specify which bit of implementation a bug is likely caused by: * compiler subsystem: driver, simplifier, demand analysis, RTS, LLVM backend * related GHC project: ghc-pkg, integer-simple, nofib, core libraries, infrastructure * external project: haddock, hadrian 1. Labels that specify other attributes of a ticket: newcomer, backport request, ~"info needed", ~"user facing" It's not clear which of these are useful, which are just noise, and how we should best group them. We have two tools for logically grouping labels: * prefixing the label name with some sort of category string * color — View it on GitLab. You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Mar 19 01:24:10 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 18 Mar 2019 21:24:10 -0400 Subject: Trac -> Gitlab migration: A little issue with assignees In-Reply-To: <1552903949.2142.3.camel@bluewin.ch> References: <1552903949.2142.3.camel@bluewin.ch> Message-ID: <87va0flkqz.fsf@smart-cactus.org> Roland Senn writes: > After some days off, I returned to my work on GHC. I looked up my > tickets in Gitlab with a search on assignee=RolandSenn [1].  > The system returned a list of 8 open tickets.  > Two of them are interesting: #14025 and #15336. Once upon a time I > assigned them to me, worked on them, but unfortunately then > I found them too difficult. So a couple of weeks ago I unassigned them > in the good old Trac system. > It seems, that these unassign operations weren't copied to Gitlab! > Thanks Roland. I've opened this ticket [1] to track 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 ben at smart-cactus.org Tue Mar 19 01:30:13 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 18 Mar 2019 21:30:13 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: References: Message-ID: <87sgvjlkgu.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > Sorry in advance if I should be posting questions of this kind elsewhere > (please tell me if so!). > > Consider this two file program: > ``` > module T where > main = undefined > > module Main where > import T > main = putStrLn "Hello world!" > ``` > > Both 8.4.3 and 8.6.3 agree: > ``` > Main.hs:1:1: error: > Ambiguous occurrence ‘main’ > It could refer to either ‘T.main’, > imported from ‘T’ at Main.hs:2:1-8 > (and originally defined at Main.hs:2:1-4) > or ‘Main.main’, defined at Main.hs:5:1 > ``` > > Is this expected behavior? Does it not contradict "If the export list is > omitted, all values, types and classes defined in the module are exported, > but not those that are imported" ( > https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the > latter, is this a bug? What am I missing? > The language you cite from the report makes it sound as though this is a bug. Can you open a ticket? 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 lonetiger at gmail.com Tue Mar 19 06:47:36 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 19 Mar 2019 07:47:36 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: <915c0bf9-c2e4-0141-2a54-7e6bee35856d@well-typed.com> References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> <915c0bf9-c2e4-0141-2a54-7e6bee35856d@well-typed.com> Message-ID: Agreed, I was also an opponent of -c as the default, and as you pointed out it only works for the case where the default is used. But even if the defaults are used it is still harmful to do it automatically as the user's environment could have changed resulting in different configure output if you automatically rerun it. Not only isn't there a sane UX for this, there isn't even a safe way to do this. Sent from my Mobile On Fri, Mar 15, 2019, 16:51 Alp Mestanogullari wrote: > I have to admit I sympathize with Moritz's view. Since `-c` only > "subsumes" the case where we call 'configure' with no extra env var or > argument, and in the absence of a generic way to pass options to > 'configure' when using -c, I'd quite like to keep -c as a "cherry on top", > for users who just need to boot and configure with the default arguments > and for whom hadrian provides a way to save a few keystrokes. Just like > Moritz, I'm not even sure it would make all that much sense to provide a > way to pass configure arguments through hadrian, I have a hard time seeing > a better UX than just running configure with the extra arguments directly > and _then_ calling hadrian to start the build. > On 15/03/2019 14:35, Moritz Angermann wrote: > > Hi Arnaud, > > > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud wrote: > > On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel wrote: > I don't have the ticket number at my fingertips but it should be fairly easy to find. > > I'm afraid it doesn't appear to be. Could you share your arguments in this thread? > > This was the last one that lead to the current `-c` state: > - https://github.com/snowleopard/hadrian/issues/457 > There is also > - https://github.com/snowleopard/hadrian/issues/655 > > if you look through the issues on snowleopard/hadrian and sort by comment frequency > you'll likely find quite a lot of further discussion about not making configure and > boot the default. > > > > On Fri, Mar 15, 2019 at 3:10 AM Moritz Angermann wrote: > It's magically conflating two different phases with `-c`. The configure phase and > the build phase. Making this the default means it's always magic. I don't like magic! > > Unfortunately, I really don't understand what you are saying. What's magic about combining the phases? > > > We have two phases: > > Phase 1: autoconf > > This phase is essentially a code-generation phase, where specific templates are > instantiated to configure time value. Which again can be split into two specific > subproblems: > > - Generation of the configure script from the configure.ac and aclocal.m4 files > using autoconf. > - Generating code using the configure script by computing configure time calues > and filling those into the `.in` files producing the files that lack the `.in` > extension. > > Phase 2: building > > This has been traditionally the job of make, and this is what hadrian should > replace. > > > By subsuming the configure phase (by invoking ./configure) from hadrian we loose > the phase distinction and if the `-c` flag is optional, users will *not even see* > a flag that indicates that the system will run `./configure` for them. This is the > magic I'm referring to and to which I strongly object. If we can retire autoconf > and do the whole configuration in hadrian, that story may change. But as long as > we are using an autoconf based configuration we should *not* run that magically. > The `-c` flag is at least there to show that hadrian is explicilty instructed to > run configure. > > ./configure supports its own set of flags, if hadrian subsumes those, we'd need > some generic way of passing flags to ./configure, at which point I have to ask > why do we do this in the first place and try to call ./configure from within hadrian? > > Unless you want to reconfigure ghc, or hack on it's autoconf part, you are likely > going to run the following only: > > ./boot --hadrian > ./configure > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ./hadrian/build.sh -j ... > ... > > the configure step is required, and should be explicit. That is where you configure > your ghc build. Set host/build/target values, and other configure flags that > influence how you want your ghc to be configure. Hadrian is there to build that > configuration. Mixing both may be convenient but hides the fact that there is a > ./configure step. I consider this hiding to be magic which is meant to benefit the > user but hides what's really going on. And again I don't like magic. > > Cheers, > Moritz > > PS: we also don't hide the `./configure` step in the usual `./configure && make -j` > instructions when building other software, even though you could surely hack that into > your Makefile if you so wanted to. Why start with ghc now? > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Mar 19 08:42:03 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 19 Mar 2019 09:42:03 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery wrote: > Newcomers to autoconf-based ecosystems often add a rule to run configure > to their Makefiles, as a "shortcut". At some time thereafter, they discover > that there's a problem when configure alters the build plan make is > executing. There's no sane way to integrate this properly if the build plan > changes enough, even if configure is always the very first thing executed > as part of the original build plan. This generally results in forcing make > to abort after running autoconf, since trying to be more clever results in > looping over configure. The only other way that works is arranging for > 2-stage Makefiles where the outer one amounts to "configure && make -f > Makefile.real". Which makes it noticeably more error-prone to tweak > something and do a fast rebuild, since configure will often cause it to be > a full rebuild instead. If you try to give configure dependencies so that > it doesn't get re-run, you discover that it's dependent in some sense on > its own outputs and again can cause loops. > > Trying to integrate configure with hadrian runs the same risk, heightened > by hadrian not using anything like Makefiles, so it would be even easier > for it to either miss changes made by configure or end up looping on it. Or > worse, the same with autoconf — or for ghc, the boot script which runs > autoconf, among other things, and thus has even nastier risks in terms of > missing important changes made thereby or causing loops. > Aha! But is Hadrian doesn't use Make. And the shortcoming of Make which make autoconf necessary as a separate tools are ones that Shake fix. Making it a breeze to integrate a configure script without hassle. I'll be honest, so far, so far, the thread doesn't have much convincing arguments in favour of keeping `-c`. The argument which I understand is Ben's in [ https://github.com/snowleopard/hadrian/issues/457 ], who saw the arguments he passed to ./configure overwritten by Hadrian. This is surprising and unnecessary. But you have to realise what you are advocating for: the most typical workflow (not passing special arguments to ./configure) is the one which is special cased. We should rather take this as a challenge: how do we fix the limitations of `-c` so that it can be made the default; rather than giving up. A possibility would be to record the arguments passed to the configure script in a file, and make Hadrian pass these arguments to `./configure`. For instance. I'd also like to impart a bit of urgency to this: we are breaking everybody's habit now, so now is the time to discuss changes. When we're used to the new build system and it isn't new anymore, it will become much harder to justify change. By the way, on the default flavour: in addition to Ocaml's Dune, it appears that Bazel (Google's newish multi-language build system) also has the developers' build be the default. It's not enough data to establish that this default is the consensus. But I'm quite warming up to the position myself. Best, Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Tue Mar 19 10:04:01 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 19 Mar 2019 11:04:01 +0100 Subject: Discussion: Hadrian's defaults In-Reply-To: <875zsknj2x.fsf@smart-cactus.org> (Ben Gamari's message of "Fri, 15 Mar 2019 13:28:21 -0400") References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> <875zsknj2x.fsf@smart-cactus.org> Message-ID: <87o9672nam.fsf@gmail.com> On 2019-03-15 at 13:28:21 -0400, Ben Gamari wrote: [...] > We should keep in mind that users and packagers, not GHC developers, are > the primary audience of GHC's build system. For their sake we should > strive to keep GHC's build system as close to the usual > configure/make/make install workflow as possible. Actually, even as a GHC developer, I strongly prefer the IMO quite intuitive configure/make phase-separated workflow I've been used to for over 2 decades. It's deeply ingrained into my muscle memory and my tooling automatically knows what to do when it discovers a `configure` script and/or a `GNUmakefile`/`Makefile` file in the filesystem and I'm not excited to have to adapt all my dev scripts/integrations to make them Hadrian-aware which is effectively a bespoken build-system used by exactly one project and starting with a specific version of the project while the previous ones still require Makefiles. > In fact, I have at times wondered whether when we switch to Hadrian as > our primary build system we should ship our source distributions with a > stub makefile to build and run hadrian, allowing downstreams to treat > the distribution as a normal autotools-based package. Definitely, I've been wanting this as well! It's perfectly fine IMO to have it be a best-effort leaky abstraction. It'd be great if the following standard invocations kept working, which represents the usage pattern I use both in packaging scripts as well as in my dev-workflow scripts. The less I have to be aware of Hadrian pulling the strings behind the curtains for my 80% use-cases the better. And if I need to do something from the remaining 20% of use-cases that's when I'd be willing to invoke Hadrian directly, as that's also when I'd be doing something non-standard/non-routine anyway and I'd be consciously paying attention anyway... ,---- | # an example build.mk with some of the keys I typically set one way or | # another; just support a flat simple key/value grammar as text-file | # config input to Hadrian | | cat > mk/build.mk < References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: > I'll be honest, so far, so far, the thread doesn't have much convincing arguments in favour of keeping `-c`. The argument which I understand is Ben's in [ https://github.com/snowleopard/hadrian/issues/457 ], who saw the arguments he passed to ./configure overwritten by Hadrian. This is surprising and unnecessary. How about my reply in that it does not work. Configure isn't make.it never was. The whole point of configure is to perform configuration checks based on your environment. There are two real technical reasons that Hadrian cannot and should not run configure again on its own. 1) you cannot tell what arguments the configure was originally called with. Your assumption here is that everyone calls make with no arguments. This is simply not true. Yes the arguments are stored somewhat mangled in config.status but extracting them will prove very fragile. 2) Hadrian cannot restore the environment to what it was when configure was first called. Simple example CC=/foo/custom/compiler ./configure. Hadrain's -c by default would blow away this CC value and produce a config that would use something else. Giving me an abi issue that's harder to track down than the amount of effort it takes for someone to put -c. Configure by default has a much larger chance of producing invalid code than not having it by default. There is a very good reason why autoconf and automake are different. They have different goals. Hadrian is a replacement for make and shouldn't try to dictate what autoconf does. Tamar. On Tue, Mar 19, 2019, 08:42 Spiwack, Arnaud wrote: > On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery > wrote: > >> Newcomers to autoconf-based ecosystems often add a rule to run configure >> to their Makefiles, as a "shortcut". At some time thereafter, they discover >> that there's a problem when configure alters the build plan make is >> executing. There's no sane way to integrate this properly if the build plan >> changes enough, even if configure is always the very first thing executed >> as part of the original build plan. This generally results in forcing make >> to abort after running autoconf, since trying to be more clever results in >> looping over configure. The only other way that works is arranging for >> 2-stage Makefiles where the outer one amounts to "configure && make -f >> Makefile.real". Which makes it noticeably more error-prone to tweak >> something and do a fast rebuild, since configure will often cause it to be >> a full rebuild instead. If you try to give configure dependencies so that >> it doesn't get re-run, you discover that it's dependent in some sense on >> its own outputs and again can cause loops. >> >> Trying to integrate configure with hadrian runs the same risk, heightened >> by hadrian not using anything like Makefiles, so it would be even easier >> for it to either miss changes made by configure or end up looping on it. Or >> worse, the same with autoconf — or for ghc, the boot script which runs >> autoconf, among other things, and thus has even nastier risks in terms of >> missing important changes made thereby or causing loops. >> > > Aha! But is Hadrian doesn't use Make. And the shortcoming of Make which > make autoconf necessary as a separate tools are ones that Shake fix. Making > it a breeze to integrate a configure script without hassle. > > I'll be honest, so far, so far, the thread doesn't have much convincing > arguments in favour of keeping `-c`. The argument which I understand is > Ben's in [ https://github.com/snowleopard/hadrian/issues/457 ], who saw > the arguments he passed to ./configure overwritten by Hadrian. This is > surprising and unnecessary. > > But you have to realise what you are advocating for: the most typical > workflow (not passing special arguments to ./configure) is the one which is > special cased. We should rather take this as a challenge: how do we fix the > limitations of `-c` so that it can be made the default; rather than giving > up. A possibility would be to record the arguments passed to the configure > script in a file, and make Hadrian pass these arguments to `./configure`. > For instance. > > I'd also like to impart a bit of urgency to this: we are breaking > everybody's habit now, so now is the time to discuss changes. When we're > used to the new build system and it isn't new anymore, it will become much > harder to justify change. > > By the way, on the default flavour: in addition to Ocaml's Dune, it > appears that Bazel (Google's newish multi-language build system) also has > the developers' build be the default. It's not enough data to establish > that this default is the consensus. But I'm quite warming up to the > position myself. > > Best, > Arnaud > _______________________________________________ > 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 Tue Mar 19 10:45:30 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Tue, 19 Mar 2019 06:45:30 -0400 Subject: [ambiguous occurrence bug?] In-Reply-To: <87sgvjlkgu.fsf@smart-cactus.org> References: <87sgvjlkgu.fsf@smart-cactus.org> Message-ID: On Mon, Mar 18, 2019 at 9:30 PM Ben Gamari wrote: > Shayne Fletcher via ghc-devs writes: > > > Consider this two file program: > > ``` > > module T where > > main = undefined > > > > module Main where > > import T > > main = putStrLn "Hello world!" > > ``` > > > > Both 8.4.3 and 8.6.3 agree: > > ``` > > Main.hs:1:1: error: > > Ambiguous occurrence ‘main’ > > It could refer to either ‘T.main’, > > imported from ‘T’ at Main.hs:2:1-8 > > (and originally defined at Main.hs:2:1-4) > > or ‘Main.main’, defined at Main.hs:5:1 > > ``` > > > > Is this expected behavior? Does it not contradict "If the export list is > > omitted, all values, types and classes defined in the module are > exported, > > but not those that are imported" ( > > https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If > the > > latter, is this a bug? What am I missing? > > > The language you cite from the report makes it sound as though this is a > bug. Can you open a ticket? > Yes! Tracked in https://gitlab.haskell.org/ghc/ghc/issues/16453. -- 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 allbery.b at gmail.com Tue Mar 19 16:22:29 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 19 Mar 2019 12:22:29 -0400 Subject: Discussion: Hadrian's defaults In-Reply-To: References: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com> <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com> Message-ID: I feel like you didn't read this completely. I used make as the example, but hadrian is also a build system and will have some version of the same problem: configure's dependencies are also its outputs. Hadrian might be able to handle this, if it recomputes the entire dependency tree after every operation — but any mistakes in the dependencies will lead to loops. And none of this addresses the point that if configure is in any way automatic, including as a separate initialization operation before dependencies are computed, it's going to make life difficult for developers who want to restart a build. Granting the viewpoint that says that end-builder ease is more important than developer ease, but even there if you make things too difficult for developers, a project that is already short on developers may become even more short on developers and/or developer time. (I also think decisions like whether and how to run configure and/or the build tooling should be part of my local configuration, because my own needs will differ from others'. We already see this with devs who prefer e.g. quick vs. perf builds.) By far the safest approach is to keep configure separate. On Tue, Mar 19, 2019 at 4:42 AM Spiwack, Arnaud wrote: > On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery > wrote: > >> Newcomers to autoconf-based ecosystems often add a rule to run configure >> to their Makefiles, as a "shortcut". At some time thereafter, they discover >> that there's a problem when configure alters the build plan make is >> executing. There's no sane way to integrate this properly if the build plan >> changes enough, even if configure is always the very first thing executed >> as part of the original build plan. This generally results in forcing make >> to abort after running autoconf, since trying to be more clever results in >> looping over configure. The only other way that works is arranging for >> 2-stage Makefiles where the outer one amounts to "configure && make -f >> Makefile.real". Which makes it noticeably more error-prone to tweak >> something and do a fast rebuild, since configure will often cause it to be >> a full rebuild instead. If you try to give configure dependencies so that >> it doesn't get re-run, you discover that it's dependent in some sense on >> its own outputs and again can cause loops. >> >> Trying to integrate configure with hadrian runs the same risk, heightened >> by hadrian not using anything like Makefiles, so it would be even easier >> for it to either miss changes made by configure or end up looping on it. Or >> worse, the same with autoconf — or for ghc, the boot script which runs >> autoconf, among other things, and thus has even nastier risks in terms of >> missing important changes made thereby or causing loops. >> > > Aha! But is Hadrian doesn't use Make. And the shortcoming of Make which > make autoconf necessary as a separate tools are ones that Shake fix. Making > it a breeze to integrate a configure script without hassle. > > I'll be honest, so far, so far, the thread doesn't have much convincing > arguments in favour of keeping `-c`. The argument which I understand is > Ben's in [ https://github.com/snowleopard/hadrian/issues/457 ], who saw > the arguments he passed to ./configure overwritten by Hadrian. This is > surprising and unnecessary. > > But you have to realise what you are advocating for: the most typical > workflow (not passing special arguments to ./configure) is the one which is > special cased. We should rather take this as a challenge: how do we fix the > limitations of `-c` so that it can be made the default; rather than giving > up. A possibility would be to record the arguments passed to the configure > script in a file, and make Hadrian pass these arguments to `./configure`. > For instance. > > I'd also like to impart a bit of urgency to this: we are breaking > everybody's habit now, so now is the time to discuss changes. When we're > used to the new build system and it isn't new anymore, it will become much > harder to justify change. > > By the way, on the default flavour: in addition to Ocaml's Dune, it > appears that Bazel (Google's newish multi-language build system) also has > the developers' build be the default. It's not enough data to establish > that this default is the consensus. But I'm quite warming up to the > position myself. > > Best, > Arnaud > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Tue Mar 19 17:57:19 2019 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Tue, 19 Mar 2019 18:57:19 +0100 Subject: Windows release quality Message-ID: <5C912D7F.5040400@gmx.at> Hello Devs, After running into #16408 today I realized there is as of yet no released bindist of the 8.6 series which I would consider stable for windows. GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 GHC 8.6.3 loops forever if compiling certain code using TH on windows. This affects some very popular hackage packages: (#16057) GHC 8.6.4 (marked stable) currently ships without profiling libraries, making profiling impossible. Being stuck with 8.4 is one thing, and if properly communicated not too bad. But it requires work to even find out about these (major) issues and to discover that 8.6 is NOT production ready for windows. We offered the broken 8.6.3 as stable for weeks without any indication that it was broken. We still serve GHC 8.6.4 as stable without any hint about the missing profiling libraries. I can't offer solutions in this case but I feel like something about the release management has to change if . Having to check the GHC bugtracker to find out if the current stable release is actually stable is just not sustainable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Mar 19 18:52:40 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 19 Mar 2019 18:52:40 +0000 Subject: Windows release quality In-Reply-To: <5C912D7F.5040400@gmx.at> References: <5C912D7F.5040400@gmx.at> Message-ID: Hi Andreas, GHC 8.6.4 not supporting profiling libs was the first thing mentioned in the release email - A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible to #16071. #16071 will be fixed in GHC 8.8.1. It was also stated that it would be back in 8.8.1. At this point there was no way to get profiling libs on 8.6.x without a major backport of linker changes from master. The choice was made to revert the change and release 8.6.4 without profiling libraries because of a stack allocation bug that was dormant for years but completely killed the 32 bit distribution. That said the changelog linked to the wrong issue, the second two should have been #15934 but that's not hard to figure out by looking at the ticket. This was not an oversight, both the choice to release GHC 8.6.4 without profiling libs (which really to the average user is not mission critical) and the fact to release 8.6.4 at all were thought out decisions. It could have been communicated better yes. That 8.6.3 wasn't removed I don't know. I pulled it from chocolatey at least. 8.6 is more production ready than 8.4 was, it just doesn't support profiling libs for a while till 8.8 yes. Tamar. On Tue, Mar 19, 2019 at 5:57 PM Andreas Klebinger wrote: > Hello Devs, > > After running into #16408 today I realized there is as of yet no released > bindist > of the 8.6 series which I would consider stable for windows. > > GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to > multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 > GHC 8.6.3 loops forever if compiling certain code using TH on windows. > This affects some very popular hackage packages: (#16057) > > GHC 8.6.4 (marked stable) currently ships without profiling libraries, > making profiling impossible. > > Being stuck with 8.4 is one thing, and if properly communicated not too > bad. > But it requires work to even find out about these (major) issues and to > discover that 8.6 is NOT production ready for windows. > > We offered the broken 8.6.3 as stable for weeks without any indication > that it was broken. > We still serve GHC 8.6.4 as stable without any hint about the missing > profiling libraries. > > I can't offer solutions in this case but I feel like something about the > release management has to change if . > Having to check the GHC bugtracker to find out if the current stable > release is actually stable is just not sustainable. > > > > > _______________________________________________ > 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 ben at smart-cactus.org Tue Mar 19 19:41:44 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 19 Mar 2019 15:41:44 -0400 Subject: Windows release quality In-Reply-To: References: <5C912D7F.5040400@gmx.at> Message-ID: <877eculki9.fsf@smart-cactus.org> Phyx writes: > Hi Andreas, > > GHC 8.6.4 not supporting profiling libs was the first thing mentioned in > the release email > > - A regression resulting in segmentation faults on Windows introduced > by the fix for #16071 backported in 8.6.3. This fix has been reverted, > meaning that 8.6.4 is once again susceptible to #16071. #16071 will > be fixed in GHC 8.8.1. > > It was also stated that it would be back in 8.8.1. At this point there > was no way to get profiling libs on 8.6.x without a major backport of > linker changes from master. The choice was made to revert the change > and release 8.6.4 without profiling libraries because of a stack > allocation bug that was dormant for years but completely killed the 32 > bit distribution. That said the changelog linked to the wrong issue, > the second two should have been #15934 but that's not hard to figure > out by looking at the ticket. > I will reiterate that having functional profiling in 8.6.4 was never in the cards (unless a contributor was willing to step up to backport Phyx's linker patch). However, I will also say that the fact that the omission of the profiling libraries and haddock from the release tarball (#16408) was not my intention. Rather this was an accidental side-effect of an oversight in the release CI job. This is something I only realized rather recently (leading to !516) and thought I would fix after when I re-spun the Windows tarballs to include an i386 build. In hindsight I should have advertised this more widely and perhaps even pulled the bindist. However, in my defense I did not expect it to more than a few days to get the fixes through CI and have a new set of bindists ready for release. On the whole I agree that it is not fair to users to expect them to discover this sort of thing by browsing the issue tracker. This is something that I will improve on in the future. In general I'm not sure how to handle signalling of release stability. Tamar has done an absolutely amazing job keeping the Windows boat afloat (and even improving it, c.f. his new IO manager), However, I cannot deny that there are indeed issues, as evidenced by the fact that my patch making Windows a mandatory-green CI platforms needs to disable quite a number of flaky or failing tests. Should we be signalling that this is stable? It's hard to say; many of these cases are rather niche. Needless to say if there's consensus that this doesn't constitute a production ready compiler then I will advocate adjusting the priorities of our efforts at Well-Typed to put more weight on fixing the Windows issues. 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 klebinger.andreas at gmx.at Tue Mar 19 20:48:47 2019 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Tue, 19 Mar 2019 21:48:47 +0100 Subject: Windows release quality In-Reply-To: <877eculki9.fsf@smart-cactus.org> References: <5C912D7F.5040400@gmx.at> <877eculki9.fsf@smart-cactus.org> Message-ID: <5C9155AF.6090606@gmx.at> Just to make this clear it's not my intention to blame anyone or point fingers. Given the resources at hand I think Phyx and you have done an amazing job so far to keep things working! The core of the issue is that if someone sits down and installs a "stable" GHC today he will either get a version that hangs on any dependency using TH (8.6.3) or run into weird errors if he tries to profile an executable. Both of which I would call rather mundane development activities. But what I take issue with is not that there is some brokenness. It's how we deal with that fact from a user perspective. Pretty much all distribution channels currently provide 8.6.3 or 8.6.4 as stable. Haskell Platform: "The latest version of the Haskell Platform for Windows is 8.6.3." Stackage: * LTS 13.13 for GHC 8.6.4 , published 3 days ago * LTS 13.11 for GHC 8.6.3 , published a week ago haskell.org: Current Stable Release: 8.6.4 And none of the download pages give any indication of issues. Neither does the user guide. How much effort can we really expect from a user to find out something basic like profiling or TH is simply broken in a release marked as stable? I've actually got hit by both issues despite at least following ghc development somewhat. We don't have to be debian. But as a windows user a release being stable has lost all meaning to me. And I imagine it's worse for people not looking behind the curtain. Ben Gamari schrieb: > Phyx writes: > >> Hi Andreas, >> >> GHC 8.6.4 not supporting profiling libs was the first thing mentioned in >> the release email >> >> - A regression resulting in segmentation faults on Windows introduced >> by the fix for #16071 backported in 8.6.3. This fix has been reverted, >> meaning that 8.6.4 is once again susceptible to #16071. #16071 will >> be fixed in GHC 8.8.1. >> >> It was also stated that it would be back in 8.8.1. At this point there >> was no way to get profiling libs on 8.6.x without a major backport of >> linker changes from master. The choice was made to revert the change >> and release 8.6.4 without profiling libraries because of a stack >> allocation bug that was dormant for years but completely killed the 32 >> bit distribution. That said the changelog linked to the wrong issue, >> the second two should have been #15934 but that's not hard to figure >> out by looking at the ticket. >> > I will reiterate that having functional profiling in 8.6.4 was never > in the cards (unless a contributor was willing to step up to backport > Phyx's linker patch). > > However, I will also say that the fact that the omission of the > profiling libraries and haddock from the release tarball (#16408) was > not my intention. Rather this was an accidental side-effect of an > oversight in the release CI job. This is something I only realized > rather recently (leading to !516) and thought I would fix after when I > re-spun the Windows tarballs to include an i386 build. > > In hindsight I should have advertised this more widely and perhaps even > pulled the bindist. However, in my defense I did not expect it to more > than a few days to get the fixes through CI and have a new set of > bindists ready for release. On the whole I agree that it is not fair to > users to expect them to discover this sort of thing by browsing the > issue tracker. This is something that I will improve on in the future. > > In general I'm not sure how to handle signalling of release stability. > Tamar has done an absolutely amazing job keeping the Windows boat afloat > (and even improving it, c.f. his new IO manager), However, I cannot deny > that there are indeed issues, as evidenced by the fact that my patch > making Windows a mandatory-green CI platforms needs to disable quite a > number of flaky or failing tests. Should we be signalling that this is > stable? It's hard to say; many of these cases are rather niche. Needless > to say if there's consensus that this doesn't constitute a production > ready compiler then I will advocate adjusting the priorities of our > efforts at Well-Typed to put more weight on fixing the Windows issues. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Thu Mar 21 11:10:50 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Thu, 21 Mar 2019 12:10:50 +0100 Subject: GHC wiki fixup Message-ID: <20190321111049.qzjmx7t7aiyozmx5@nibbler> Hello all, I am about to push a relatively large set of semi-automatic changes to the GHC wiki on GitLab (https://gitlab.haskell.org/ghc/ghc/wikis). This changeset is the result of re-running the original Trac import, with a few bugfixes applied to it, and then cherry-picking the resulting changes to the wiki onto the live wiki. Among other things, this fixes the following issues: - Mangled table layouts (GitLab's Markdown implementation does not support inline markup inside tables): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/45 - Mangled code blocks (for some reason, the original import threw away significant whitespace inside syntax-highlighted code blocks): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/37 - Some links to GHC source files pointing to gitlab.haskell.org/ghc/ghc/wikis/trac/ghc/browse/..., which is of course nonsense, now point to the correct location in the GitLab source code viewer: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/53 - Some remaining links to the old Trac install have been fixed: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/26 - Some incorrectly quoted blocks may or may not be fixed by this as well: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/46 - During the original import, we experienced HTTP errors on some pages, leading to "CONVERSION ERROR" pages being rendered instead. The re-run should have fixed these by sheer virtue of GETting those pages again now that there is less load on the Trac server. Since we used the wiki in its pre-migration state (as currently seen on https://trac.haskell.org/ghc) as the data source, we have to be careful not to accidentally undo changes made to the GitLab wiki in the meantime. I tried to mitigate this by manually picking changes, and I think I got it right, but as with all manual efforts, it is possible that I made a mistake here or there. The changeset is pretty large, and most of it is perfectly boring, so I applied quite a bit of automation to keep it manageable. So if you find anything broken on the wiki that looked OK so far, or if you see any of your edits disappear, please holler, and I'll do my best to fix it. Fortunately, this is a git repo, so nothing is permanently lost either way. And of course I apologize for any inconvenience in advance. Cheers, Tobias From tdammers at gmail.com Thu Mar 21 12:57:20 2019 From: tdammers at gmail.com (Tobias Dammers) Date: Thu, 21 Mar 2019 13:57:20 +0100 Subject: GHC wiki fixup In-Reply-To: <20190321111049.qzjmx7t7aiyozmx5@nibbler> References: <20190321111049.qzjmx7t7aiyozmx5@nibbler> Message-ID: <20190321125719.xaqwav4bteq3gnwf@nibbler> On further inspection, it turns out that the commit isn't quite right; it does not contain all the expected fixes. I'll dive in to figure out why that is. Apologies for the line noise. From matthewtpickering at gmail.com Fri Mar 22 10:32:34 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 22 Mar 2019 10:32:34 +0000 Subject: How to access a wiki page? Message-ID: I made a wiki page for something I am working on but now I can't access the page anymore. The search thankfully displays the page as the first result. https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=core+representation&group_id=&project_id=1&scope=wiki_blobs&repository_ref= But if I click on the page then it takes me to a UI which asks me to create a new page. This is obviously a bug in gitlab but how can I get to the page anyway? Cheers, Matt From krz.gogolewski at gmail.com Fri Mar 22 10:49:20 2019 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Fri, 22 Mar 2019 11:49:20 +0100 Subject: How to access a wiki page? In-Reply-To: References: Message-ID: The search link goes to https://gitlab.haskell.org/ghc/ghc/wikis/Core-Representation-of-Typed-Template-Haskell-Quotes but it should go to https://gitlab.haskell.org/ghc/ghc/wikis/template-haskell/Core-Representation-of-Typed-Template-Haskell-Quotes On Fri, Mar 22, 2019 at 11:33 AM Matthew Pickering < matthewtpickering at gmail.com> wrote: > I made a wiki page for something I am working on but now I can't > access the page anymore. > > The search thankfully displays the page as the first result. > > > https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=core+representation&group_id=&project_id=1&scope=wiki_blobs&repository_ref= > > But if I click on the page then it takes me to a UI which asks me to > create a new page. > > This is obviously a bug in gitlab but how can I get to the page anyway? > > Cheers, > > Matt > _______________________________________________ > 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 ben at smart-cactus.org Fri Mar 22 17:39:01 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 22 Mar 2019 13:39:01 -0400 Subject: How to access a wiki page? In-Reply-To: References: Message-ID: <87r2aykdvx.fsf@smart-cactus.org> Matthew Pickering writes: > I made a wiki page for something I am working on but now I can't > access the page anymore. > > The search thankfully displays the page as the first result. > > https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=core+representation&group_id=&project_id=1&scope=wiki_blobs&repository_ref= > > But if I click on the page then it takes me to a UI which asks me to > create a new page. > > This is obviously a bug in gitlab but how can I get to the page anyway? > Indeed, and a pretty bad one at that. I think I'll need to look into fixing this myself; not having functional search over the wiki is not acceptable. 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 smart-cactus.org Fri Mar 22 18:17:04 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 22 Mar 2019 14:17:04 -0400 Subject: How to access a wiki page? In-Reply-To: <87r2aykdvx.fsf@smart-cactus.org> References: <87r2aykdvx.fsf@smart-cactus.org> Message-ID: <87o962kc4r.fsf@smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> I made a wiki page for something I am working on but now I can't >> access the page anymore. >> >> The search thankfully displays the page as the first result. >> >> https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=core+representation&group_id=&project_id=1&scope=wiki_blobs&repository_ref= >> >> But if I click on the page then it takes me to a UI which asks me to >> create a new page. >> >> This is obviously a bug in gitlab but how can I get to the page anyway? >> > Indeed, and a pretty bad one at that. I think I'll need to look into > fixing this myself; not having functional search over the wiki is not > acceptable. > I have opened gitlab-ce#59367 [1] to track this and nearly have a workaround. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/59367 -------------- 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 Sat Mar 23 15:13:14 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 23 Mar 2019 15:13:14 +0000 Subject: GitLab seems quite poorly Message-ID: I don't know what has changed since yesterday but pushing new branches to GitLab is broken. The two most recent branches pushed to origin 404 when you click on the link. https://gitlab.haskell.org/ghc/ghc/branches https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 I also pushed some commits to a fork and the MR which they appear on didn't update at all. Perhaps a symptom of the same problem. Also a recent MR by Ben complains of the source branch for the MR not existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 The summary is that GitLab seems unusable at the moment. Did you fiddle with anything recently Ben? Cheers, Matt From ben at smart-cactus.org Sat Mar 23 16:39:57 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 23 Mar 2019 12:39:57 -0400 Subject: GitLab seems quite poorly In-Reply-To: References: Message-ID: <87h8btk0iv.fsf@smart-cactus.org> Matthew Pickering writes: > I don't know what has changed since yesterday but pushing new branches > to GitLab is broken. > > The two most recent branches pushed to origin 404 when you click on the link. > > https://gitlab.haskell.org/ghc/ghc/branches > > https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 > > I also pushed some commits to a fork and the MR which they appear on > didn't update at all. Perhaps a symptom of the same problem. > > Also a recent MR by Ben complains of the source branch for the MR not > existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 > > The summary is that GitLab seems unusable at the moment. Did you > fiddle with anything recently Ben? > Yes, I am aware of these issues have been working in the background to resolve or report them. In short, I updated to 11.9.0 yesterday. This seems to have introduced a bug in the handling of branches whose names contain forward slashes. Unfortunately it hasn't been easy to nail down precisely what broke. I have tried rolling back to 11.8.2 but sadly the issues seem to persist. 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 smart-cactus.org Sat Mar 23 22:13:14 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 23 Mar 2019 18:13:14 -0400 Subject: GitLab seems quite poorly In-Reply-To: <87h8btk0iv.fsf@smart-cactus.org> References: <87h8btk0iv.fsf@smart-cactus.org> Message-ID: <87d0mhjl3e.fsf@smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> I don't know what has changed since yesterday but pushing new branches >> to GitLab is broken. >> >> The two most recent branches pushed to origin 404 when you click on the link. >> >> https://gitlab.haskell.org/ghc/ghc/branches >> >> https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 >> >> I also pushed some commits to a fork and the MR which they appear on >> didn't update at all. Perhaps a symptom of the same problem. >> >> Also a recent MR by Ben complains of the source branch for the MR not >> existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 >> >> The summary is that GitLab seems unusable at the moment. Did you >> fiddle with anything recently Ben? >> > Yes, I am aware of these issues have been working in the background to > resolve or report them. In short, I updated to 11.9.0 yesterday. This > seems to have introduced a bug in the handling of branches whose names > contain forward slashes. Unfortunately it hasn't been easy to nail down > precisely what broke. > > I have tried rolling back to 11.8.2 but sadly the issues seem to persist. > For what it's worth, I managed to come up with a patch that appears to avoid the issue. It appears to be due to caching within GitLab, although I can't say I understand precisely how it is going wrong. I have reported the regression as gitlab-ce#59403 [1]. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/59403 -------------- 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 Sun Mar 24 19:29:45 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 24 Mar 2019 19:29:45 +0000 Subject: GitLab seems quite poorly In-Reply-To: <87d0mhjl3e.fsf@smart-cactus.org> References: <87h8btk0iv.fsf@smart-cactus.org> <87d0mhjl3e.fsf@smart-cactus.org> Message-ID: Gitlab is still broken unfortunately. * Forking new projects doesn't work (according to deepfire) * MRs are not updated when the branch is pushed to I added a broadcast message to gitlab to inform people of the problem. Cheers, Matt On Sat, Mar 23, 2019 at 10:13 PM Ben Gamari wrote: > > Ben Gamari writes: > > > Matthew Pickering writes: > > > >> I don't know what has changed since yesterday but pushing new branches > >> to GitLab is broken. > >> > >> The two most recent branches pushed to origin 404 when you click on the link. > >> > >> https://gitlab.haskell.org/ghc/ghc/branches > >> > >> https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 > >> > >> I also pushed some commits to a fork and the MR which they appear on > >> didn't update at all. Perhaps a symptom of the same problem. > >> > >> Also a recent MR by Ben complains of the source branch for the MR not > >> existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 > >> > >> The summary is that GitLab seems unusable at the moment. Did you > >> fiddle with anything recently Ben? > >> > > Yes, I am aware of these issues have been working in the background to > > resolve or report them. In short, I updated to 11.9.0 yesterday. This > > seems to have introduced a bug in the handling of branches whose names > > contain forward slashes. Unfortunately it hasn't been easy to nail down > > precisely what broke. > > > > I have tried rolling back to 11.8.2 but sadly the issues seem to persist. > > > For what it's worth, I managed to come up with a patch that appears to > avoid the issue. It appears to be due to caching within GitLab, although > I can't say I understand precisely how it is going wrong. I have > reported the regression as gitlab-ce#59403 [1]. > > Cheers, > > - Ben > > > [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/59403 From ben at well-typed.com Sun Mar 24 19:39:36 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 24 Mar 2019 15:39:36 -0400 Subject: GitLab seems quite poorly In-Reply-To: References: <87h8btk0iv.fsf@smart-cactus.org> <87d0mhjl3e.fsf@smart-cactus.org> Message-ID: <5C3A57F5-DBF3-472D-9B59-41253D89BF2C@well-typed.com> Thanks Matt. I did my best to make things as functional but I'm off skiing today so there won't be any further progress until tonight. On March 24, 2019 3:29:45 PM EDT, Matthew Pickering wrote: >Gitlab is still broken unfortunately. > >* Forking new projects doesn't work (according to deepfire) >* MRs are not updated when the branch is pushed to > >I added a broadcast message to gitlab to inform people of the problem. > >Cheers, > >Matt > >On Sat, Mar 23, 2019 at 10:13 PM Ben Gamari >wrote: >> >> Ben Gamari writes: >> >> > Matthew Pickering writes: >> > >> >> I don't know what has changed since yesterday but pushing new >branches >> >> to GitLab is broken. >> >> >> >> The two most recent branches pushed to origin 404 when you click >on the link. >> >> >> >> https://gitlab.haskell.org/ghc/ghc/branches >> >> >> >> https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 >> >> >> >> I also pushed some commits to a fork and the MR which they appear >on >> >> didn't update at all. Perhaps a symptom of the same problem. >> >> >> >> Also a recent MR by Ben complains of the source branch for the MR >not >> >> existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 >> >> >> >> The summary is that GitLab seems unusable at the moment. Did you >> >> fiddle with anything recently Ben? >> >> >> > Yes, I am aware of these issues have been working in the background >to >> > resolve or report them. In short, I updated to 11.9.0 yesterday. >This >> > seems to have introduced a bug in the handling of branches whose >names >> > contain forward slashes. Unfortunately it hasn't been easy to nail >down >> > precisely what broke. >> > >> > I have tried rolling back to 11.8.2 but sadly the issues seem to >persist. >> > >> For what it's worth, I managed to come up with a patch that appears >to >> avoid the issue. It appears to be due to caching within GitLab, >although >> I can't say I understand precisely how it is going wrong. I have >> reported the regression as gitlab-ce#59403 [1]. >> >> Cheers, >> >> - Ben >> >> >> [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/59403 >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Mar 25 16:31:11 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 25 Mar 2019 12:31:11 -0400 Subject: GitLab seems quite poorly In-Reply-To: References: Message-ID: <87a7hikjat.fsf@smart-cactus.org> Matthew Pickering writes: > I don't know what has changed since yesterday but pushing new branches > to GitLab is broken. > I managed to roll back the upgrade and appear to be stable again. 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 ryan.gl.scott at gmail.com Mon Mar 25 17:57:52 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 25 Mar 2019 13:57:52 -0400 Subject: GitLab seems quite poorly Message-ID: Things still appear not to work whenever I try to push a new branch: fatal: unable to access 'https://gitlab.haskell.org/RyanGlScott/ghc.git/': The requested URL returned error: 500 Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Mar 25 19:08:17 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 25 Mar 2019 15:08:17 -0400 Subject: GitLab seems quite poorly In-Reply-To: References: Message-ID: <877ecmkc0z.fsf@smart-cactus.org> Ryan Scott writes: > Things still appear not to work whenever I try to push a new branch: > > fatal: unable to access 'https://gitlab.haskell.org/RyanGlScott/ghc.git/': > The requested URL returned error: 500 > Sigh; it looks like this is due to a change in the database schema left over from the upgrade. I have opened gitlab-migration#62 to track this [1]. Note, however, that SSH access is unaffected. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/issues/62 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 483 bytes Desc: not available URL: From davide at well-typed.com Wed Mar 27 11:53:43 2019 From: davide at well-typed.com (David Eichmann) Date: Wed, 27 Mar 2019 11:53:43 +0000 Subject: Hadrian Transitive Dependencies Message-ID: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295 . This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M  -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M  -include-pkg-deps`. This is because they are not direct, but /transitive/ dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either:     * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR     * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Wed Mar 27 15:05:44 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Wed, 27 Mar 2019 15:05:44 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: · Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. · Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. · Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide at well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell ; Andrey Mokhov ; GHC developers Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Mar 27 15:06:25 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Mar 2019 15:06:25 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: The underlying think I don’t understand is this: * I assume that the shared cloud cache (SCC) maps input files + command line to outputs. * To have a SCC we really have to list all the input files that a compilation step consults – and that may be many more than the direct imports of the module. If we compile M which imports A, we will read A.hi; but then we may now have to read B.hi and so on. Let’s say that M has a deep dependency on B.hi. Listing all the inputs is a soundness issue: if the SCC is simply a cached map from those inputs to outputs, then missing out an input would be fatal (i.e. unsound). It’s sound to list too many inputs, but doing will reduce the usefulness of the cache. * In contrast, to get a correct Hadrian build, it suffices to list all the direct imports (= shallow depdendencies) of the thing being compiled. We’ll bring those up to date and, by implication, all the things it depends on will now also be up to date. Listing only the direct imports is much less onerous; that’s what ghc -M does. * Early cutoff has something in common with the SCC. E.g. if we compile A and produce an identical A.hi, we still need to recompile M because B.hi has changed. GHC already accommodated this by putting B.hi’s fingerprint in A.hi, so if B.hi changes then so will A.hi. So maybe we don’t need to record those transitive dependencies in the SCC? It would be extremely onerous to write Hadrian code to make all deep dependencies explicit. Do we really need to? Simon From: ghc-devs On Behalf Of David Eichmann Sent: 27 March 2019 11:54 To: Neil Mitchell ; Andrey Mokhov ; GHC developers Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Mar 27 15:19:42 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Mar 2019 15:19:42 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. Well, ok, then we need a new definition! Suppose * Module M imports A * A.hi mentions (in a type or unfolding) B.T * Hence, to find out about B.T we need to read B.hi So you would say that B is a direct dependency of M. Fine. I’ll call B.hi a “deep dependency” of M, but A.hi is a “shallow dependency” of M. But it’s very hard to predict deep dependencies. Whether M deep-depends on B.hi depends on * the contents of A.hi * the optimisation level at which M is compiled * perhaps even the contents of some apparently unrelated X.hi, directly imported by M, which influences the extent to which GHC’s optimiser dives into A’s exprots So no ghc -M is going to do the job. To get the real answer you must compile M! Happily, * we already list the deep dependencies in M.hi * and, as I mentioned earlier, if a deep dependency changes (such as B.hi) then GHC guarantees that a shallow dependency (such as A.hi) will change. Does that help? Simon From: ghc-devs On Behalf Of Andrey Mokhov Sent: 27 March 2019 15:06 To: David Eichmann ; Neil Mitchell Cc: GHC developers Subject: RE: Hadrian Transitive Dependencies Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: * Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. * Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. * Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide at well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell >; Andrey Mokhov >; GHC developers > Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Wed Mar 27 15:56:34 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Wed, 27 Mar 2019 16:56:34 +0100 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: <9fe7f072-98a0-9664-292c-c5056d3f3770@well-typed.com> https://gitlab.haskell.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&search=%22ghc+-M%22 seems to suggest this never made it into a ticket. I searched in the Hadrian github repo as well, no luck there either. It certainly came up in various discussions I've had though. On 27/03/2019 16:05, Andrey Mokhov wrote: > > Hi David, > > We had a discussion about this with Neil some time ago, and I think we > had the following list of progressively more complex invariants for > different types of build systems: > > ·Non-cloud build systems: **all direct inputs must be declared**. If > you miss a direct input dependency then a build may complete > successfully but with an incorrect result. > > ·Cloud build systems: **all direct inputs and direct outputs must be > declared**. If you miss a direct output then a build may fail because > the cloud will not be able to restore the corresponding output. > > ·Cloud build systems with shallow (deferred) materialisation of build > artefacts: **all transitive inputs and direct outputs must be > declared**. Let’s say you’d like to download the resulting GHC binary > directly, without materialising any intermediate artefacts. Then > you’ll need to know GHC’s ultimate transitive inputs. > > I think for now we are really keen to make Hadrian a cloud build > system, but whether shallow builds are valuable enough is not clear. > Maybe not. Therefore, I’d say we don’t need to track transitive inputs > right now. Furthermore, if we were to track all transitive inputs, we > would lose the desirable early cutoff property, which prevents > rebuilding after adding a comment in a file on which a lot of other > files transitively depend on. > > Having said that, if we really access a file during compilation, then > I think it is **not** a transitive dependency by definition! Any file > which is accessed during a build rule is a direct dependency. > > > GHC is reading *.hi files that are not reported as dependencies by > > > `ghc -M  -include-pkg-deps`. This is because they are not direct, but > transitive > > > dependencies! > > So, here I’m confused. If we read a file A when compiling a file B, > then it’s by definition a direct dependency. Perhaps we just read too > much? Maybe the solution is to switch to fine-grained `ghc -M` mode, > to analyse import dependencies for a single module instead of doing it > transitively, which I believe was discussed in a ticket some time ago? > I can’t find this ticket, but I think Alp was looking into it at some > point. Alp: do you remember it? > > Thank you for all your work on Hadrian! > > Cheers, > > Andrey > > *From:*David Eichmann [mailto:davide at well-typed.com] > *Sent:* 27 March 2019 12:54 > *To:* Neil Mitchell ; Andrey Mokhov > ; GHC developers > *Subject:* Hadrian Transitive Dependencies > > Hello Shake/Hadrian contributors and the like, > > Recently I've been putting Hadrian's fsatrace linting feature to good > use, tracking down missing dependencies in Hadrian. Ultimately, we > want to use shake's cloud build / shared cache feature and ensure it > works across CI builds. Unfortunately the feature isn't working > smoothly with Hadrian: see #16295 > . This is very > desirable to improve CI build times. It is my understanding that in > order to get caching to work: > > 1. All accessed files must declared with `need` AND > 2. All created files must be declared with `produces` (or be the > target of the build rule) > > Is my understanding correct? Or is there a weaker condition (perhaps > only 2 is necessary)? > > If I'm correct, this amounts to fixing all fsatrace lint errors. See > here for > a breakdown of lint errors / missing dependencies. A large portion of > these are Haskell interface files (i.e. *.hi files). Before building a > Haskell object file, dependencies are discovered via `ghc` using the > `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace > linting complains about other *.hi files being accessed! For example > when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` > we get the following dependencies from ghc: > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi > > And shake complains of the following missing deps: > > _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags > Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: >   Used:  _build/HEAD_default/stage0/lib/settings >   Used:  _build/HEAD_default/stage0/lib/platformConstants >   Used:  _build/HEAD_default/stage0/lib/llvm-targets >   Used:  _build/HEAD_default/stage0/lib/llvm-passes >   Used:  _build/HEAD_default/stage0/lib/package.conf.d/package.cache >   Used:  _build/HEAD_default/stage1/lib/package.conf.d/package.cache >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi > > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M  -include-pkg-deps`. This is because they are not direct, but > /transitive/ dependencies! How do we fix these lint errors (again with > the goal of using shakes shared cache feature)? Some ideas: > > * Wildly over approximate dependencies. This may be easier to > implement but cause unneeded recompilation (when a false dependency > changes). Either: >     * `need` all dependent packages' interface files recursively as > well as transitive dependencies reported by `ghc -M  > -include-pkg-deps` within the current package. OR >     * OR `need` all transitive dependencies reported by `ghc -M  > -include-pkg-deps`. This will likely result in fewer dependencies but > requires a bit more work in recovering dependent packages' dependency > graphs. > * Perhaps transitive dependencies are not important for shared caching > to work. Change shakes linting feature to allow (untracked?) > transitive dependencies to be accessed. > > Feed back would be greatly appreciated. > > 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 -- 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 matthewtpickering at gmail.com Wed Mar 27 16:00:34 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 27 Mar 2019 16:00:34 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: <9fe7f072-98a0-9664-292c-c5056d3f3770@well-typed.com> References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> <9fe7f072-98a0-9664-292c-c5056d3f3770@well-typed.com> Message-ID: I also remember this discussion.. I think it was in the context of optimising hadrian. On Wed, 27 Mar 2019, 15:56 Alp Mestanogullari, wrote: > > https://gitlab.haskell.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&search=%22ghc+-M%22 > seems to suggest this never made it into a ticket. I searched in the > Hadrian github repo as well, no luck there either. It certainly came up in > various discussions I've had though. > On 27/03/2019 16:05, Andrey Mokhov wrote: > > Hi David, > > > > We had a discussion about this with Neil some time ago, and I think we had > the following list of progressively more complex invariants for different > types of build systems: > > > > · Non-cloud build systems: **all direct inputs must be declared**. > If you miss a direct input dependency then a build may complete > successfully but with an incorrect result. > > > > · Cloud build systems: **all direct inputs and direct outputs must > be declared**. If you miss a direct output then a build may fail because > the cloud will not be able to restore the corresponding output. > > > > · Cloud build systems with shallow (deferred) materialisation of > build artefacts: **all transitive inputs and direct outputs must be > declared**. Let’s say you’d like to download the resulting GHC binary > directly, without materialising any intermediate artefacts. Then you’ll > need to know GHC’s ultimate transitive inputs. > > > > I think for now we are really keen to make Hadrian a cloud build system, > but whether shallow builds are valuable enough is not clear. Maybe not. > Therefore, I’d say we don’t need to track transitive inputs right now. > Furthermore, if we were to track all transitive inputs, we would lose the > desirable early cutoff property, which prevents rebuilding after adding a > comment in a file on which a lot of other files transitively depend on. > > > > Having said that, if we really access a file during compilation, then I > think it is **not** a transitive dependency by definition! Any file which > is accessed during a build rule is a direct dependency. > > > > > GHC is reading *.hi files that are not reported as dependencies by > > > `ghc -M -include-pkg-deps`. This is because they are not direct, but > transitive > > > dependencies! > > > > So, here I’m confused. If we read a file A when compiling a file B, then > it’s by definition a direct dependency. Perhaps we just read too much? > Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse > import dependencies for a single module instead of doing it transitively, > which I believe was discussed in a ticket some time ago? I can’t find this > ticket, but I think Alp was looking into it at some point. Alp: do you > remember it? > > > > Thank you for all your work on Hadrian! > > > > Cheers, > > Andrey > > > > *From:* David Eichmann [mailto:davide at well-typed.com > ] > *Sent:* 27 March 2019 12:54 > *To:* Neil Mitchell ; Andrey > Mokhov ; > GHC developers > *Subject:* Hadrian Transitive Dependencies > > > > Hello Shake/Hadrian contributors and the like, > > Recently I've been putting Hadrian's fsatrace linting feature to good use, > tracking down missing dependencies in Hadrian. Ultimately, we want to use > shake's cloud build / shared cache feature and ensure it works across CI > builds. Unfortunately the feature isn't working smoothly with Hadrian: see > #16295 . This is very > desirable to improve CI build times. It is my understanding that in order > to get caching to work: > > 1. All accessed files must declared with `need` AND > 2. All created files must be declared with `produces` (or be the target of > the build rule) > > Is my understanding correct? Or is there a weaker condition (perhaps only > 2 is necessary)? > > If I'm correct, this amounts to fixing all fsatrace lint errors. See here > for a > breakdown of lint errors / missing dependencies. A large portion of these > are Haskell interface files (i.e. *.hi files). Before building a Haskell > object file, dependencies are discovered via `ghc` using the `-M > -include-pkg-deps` options. Unfortunately, shake's fsatrace linting > complains about other *.hi files being accessed! For example when building > `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following > dependencies from ghc: > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi > > And shake complains of the following missing deps: > > _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags > > Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: > > Used: _build/HEAD_default/stage0/lib/settings > > Used: _build/HEAD_default/stage0/lib/platformConstants > > Used: _build/HEAD_default/stage0/lib/llvm-targets > > Used: _build/HEAD_default/stage0/lib/llvm-passes > > Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache > > Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi > > Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi > > GHC is reading *.hi files that are not reported as dependencies by `ghc > -M -include-pkg-deps`. This is because they are not direct, but > *transitive* dependencies! How do we fix these lint errors (again with > the goal of using shakes shared cache feature)? Some ideas: > > * Wildly over approximate dependencies. This may be easier to implement > but cause unneeded recompilation (when a false dependency changes). Either: > * `need` all dependent packages' interface files recursively as well > as transitive dependencies reported by `ghc -M -include-pkg-deps` within > the current package. OR > * OR `need` all transitive dependencies reported by `ghc -M > -include-pkg-deps`. This will likely result in fewer dependencies but > requires a bit more work in recovering dependent packages' dependency > graphs. > * Perhaps transitive dependencies are not important for shared caching to > work. Change shakes linting feature to allow (untracked?) transitive > dependencies to be accessed. > > Feed back would be greatly appreciated. > > 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 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Wed Mar 27 17:12:28 2019 From: davide at well-typed.com (David Eichmann) Date: Wed, 27 Mar 2019 17:12:28 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: Hello, To reiterate some definitions consider this scenario: * A.hs imports B.hs and B.hs imports C.hs * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi There seems to be some confusion about the term "Direct Dependency" I'll use these definitions: "Shallow Dependency": With respect to a haskell object file X.o, the shallow dependencies are the source file X.hs and interface files Y.hi for all modules Y imported by X. * These are the dependencies of X.o as reported by `ghc -M X.hs` * In the above scenario: o A.o depends on: A.hs, B.hi "Deep Dependency": With respect to a haskell object file X.o, the deep dependencies are all hi files required by ghc to build X.o excluding direct dependencies: * This is a subset of modules transitively imported by X * These dependencies are NOT reported by `ghc -M X.hs` "Direct Dependency": if the command to create file X accesses file Y, then X directly depends on Y (= Y is a direct dependency of X). * In the above scenario: o A.o directly depends on: A.hs, B.hi, and C.hi * SPJ noted that .hi files list direct dependencies. * The direct dependencies of a haskell object file is the union of its shallow and deep dependencies. "Direct Output": All files created by a rule. With that in mind, and considering a cloud build system where "*all direct inputs and direct outputs must be declared*" (where this agrees with the definitions above) can we do the following for the build rule of a haskell object file X.o? 1. `need` the shallow dependencies as reported by `ghc -M`. This guarantees that all shallow and deep dependencies (i.e. all direct dependencies) are built. 2. build X.o and X.hi 3. Inspect X.hi to derive the direct dependencies (and hence deep dependencies) 4. `needed` the deep dependencies Is there already an easy way to inspect *.hi files in this way? Is this use of `needed` valid? - David E On 3/27/19 3:05 PM, Andrey Mokhov wrote: > > Hi David, > > We had a discussion about this with Neil some time ago, and I think we > had the following list of progressively more complex invariants for > different types of build systems: > > ·Non-cloud build systems: **all direct inputs must be declared**. If > you miss a direct input dependency then a build may complete > successfully but with an incorrect result. > > ·Cloud build systems: **all direct inputs and direct outputs must be > declared**. If you miss a direct output then a build may fail because > the cloud will not be able to restore the corresponding output. > > ·Cloud build systems with shallow (deferred) materialisation of build > artefacts: **all transitive inputs and direct outputs must be > declared**. Let’s say you’d like to download the resulting GHC binary > directly, without materialising any intermediate artefacts. Then > you’ll need to know GHC’s ultimate transitive inputs. > > I think for now we are really keen to make Hadrian a cloud build > system, but whether shallow builds are valuable enough is not clear. > Maybe not. Therefore, I’d say we don’t need to track transitive inputs > right now. Furthermore, if we were to track all transitive inputs, we > would lose the desirable early cutoff property, which prevents > rebuilding after adding a comment in a file on which a lot of other > files transitively depend on. > > Having said that, if we really access a file during compilation, then > I think it is **not** a transitive dependency by definition! Any file > which is accessed during a build rule is a direct dependency. > > > GHC is reading *.hi files that are not reported as dependencies by > > > `ghc -M  -include-pkg-deps`. This is because they are not direct, but > transitive > > > dependencies! > > So, here I’m confused. If we read a file A when compiling a file B, > then it’s by definition a direct dependency. Perhaps we just read too > much? Maybe the solution is to switch to fine-grained `ghc -M` mode, > to analyse import dependencies for a single module instead of doing it > transitively, which I believe was discussed in a ticket some time ago? > I can’t find this ticket, but I think Alp was looking into it at some > point. Alp: do you remember it? > > Thank you for all your work on Hadrian! > > Cheers, > > Andrey > > *From:*David Eichmann [mailto:davide at well-typed.com] > *Sent:* 27 March 2019 12:54 > *To:* Neil Mitchell ; Andrey Mokhov > ; GHC developers > *Subject:* Hadrian Transitive Dependencies > > Hello Shake/Hadrian contributors and the like, > > Recently I've been putting Hadrian's fsatrace linting feature to good > use, tracking down missing dependencies in Hadrian. Ultimately, we > want to use shake's cloud build / shared cache feature and ensure it > works across CI builds. Unfortunately the feature isn't working > smoothly with Hadrian: see #16295 > . This is very > desirable to improve CI build times. It is my understanding that in > order to get caching to work: > > 1. All accessed files must declared with `need` AND > 2. All created files must be declared with `produces` (or be the > target of the build rule) > > Is my understanding correct? Or is there a weaker condition (perhaps > only 2 is necessary)? > > If I'm correct, this amounts to fixing all fsatrace lint errors. See > here for > a breakdown of lint errors / missing dependencies. A large portion of > these are Haskell interface files (i.e. *.hi files). Before building a > Haskell object file, dependencies are discovered via `ghc` using the > `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace > linting complains about other *.hi files being accessed! For example > when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` > we get the following dependencies from ghc: > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi > > And shake complains of the following missing deps: > > _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags > Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: >   Used:  _build/HEAD_default/stage0/lib/settings >   Used:  _build/HEAD_default/stage0/lib/platformConstants >   Used:  _build/HEAD_default/stage0/lib/llvm-targets >   Used:  _build/HEAD_default/stage0/lib/llvm-passes >   Used:  _build/HEAD_default/stage0/lib/package.conf.d/package.cache >   Used:  _build/HEAD_default/stage1/lib/package.conf.d/package.cache >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi > > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M  -include-pkg-deps`. This is because they are not direct, but > /transitive/ dependencies! How do we fix these lint errors (again with > the goal of using shakes shared cache feature)? Some ideas: > > * Wildly over approximate dependencies. This may be easier to > implement but cause unneeded recompilation (when a false dependency > changes). Either: >     * `need` all dependent packages' interface files recursively as > well as transitive dependencies reported by `ghc -M  > -include-pkg-deps` within the current package. OR >     * OR `need` all transitive dependencies reported by `ghc -M  > -include-pkg-deps`. This will likely result in fewer dependencies but > requires a bit more work in recovering dependent packages' dependency > graphs. > * Perhaps transitive dependencies are not important for shared caching > to work. Change shakes linting feature to allow (untracked?) > transitive dependencies to be accessed. > > Feed back would be greatly appreciated. > > 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 -- 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 Wed Mar 27 17:27:36 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Mar 2019 17:27:36 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com> Message-ID: With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" But I question that assumption. As I mentioned, with GHC at least, the if a deep dependency changes then one of the shallow dependencies will change. So I claim that even for cloud build it should be enough to depend only on shallow dependencies. This is only true because GHC offers this guarantee. We’d need to be sure that every deep dependency was either ‘needed’ or was reflected in the contents (perhaps via a fingerprint) another ‘needed’ thing. Simon From: ghc-devs On Behalf Of David Eichmann Sent: 27 March 2019 17:12 To: Andrey Mokhov ; Neil Mitchell Cc: GHC developers Subject: Re: Hadrian Transitive Dependencies Hello, To reiterate some definitions consider this scenario: * A.hs imports B.hs and B.hs imports C.hs * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi There seems to be some confusion about the term "Direct Dependency" I'll use these definitions: "Shallow Dependency": With respect to a haskell object file X.o, the shallow dependencies are the source file X.hs and interface files Y.hi for all modules Y imported by X. * These are the dependencies of X.o as reported by `ghc -M X.hs` * In the above scenario: * A.o depends on: A.hs, B.hi "Deep Dependency": With respect to a haskell object file X.o, the deep dependencies are all hi files required by ghc to build X.o excluding direct dependencies: * This is a subset of modules transitively imported by X * These dependencies are NOT reported by `ghc -M X.hs` "Direct Dependency": if the command to create file X accesses file Y, then X directly depends on Y (= Y is a direct dependency of X). * In the above scenario: * A.o directly depends on: A.hs, B.hi, and C.hi * SPJ noted that .hi files list direct dependencies. * The direct dependencies of a haskell object file is the union of its shallow and deep dependencies. "Direct Output": All files created by a rule. With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" (where this agrees with the definitions above) can we do the following for the build rule of a haskell object file X.o? 1. `need` the shallow dependencies as reported by `ghc -M`. This guarantees that all shallow and deep dependencies (i.e. all direct dependencies) are built. 2. build X.o and X.hi 3. Inspect X.hi to derive the direct dependencies (and hence deep dependencies) 4. `needed` the deep dependencies Is there already an easy way to inspect *.hi files in this way? Is this use of `needed` valid? - David E On 3/27/19 3:05 PM, Andrey Mokhov wrote: Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: * Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. * Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. * Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide at well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell ; Andrey Mokhov ; GHC developers Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -- 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 andrey.mokhov at newcastle.ac.uk Wed Mar 27 17:38:15 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Wed, 27 Mar 2019 17:38:15 +0000 Subject: Hadrian Transitive Dependencies References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com> Message-ID: Simon's insight is great: if deep dependencies are captured by shallow dependencies then the cloud build system is correct even if only direct shallow inputs are tracked. That's a very non-trivial invariant, and I guess this means we can't rely on fsatrace linting for GHC compilation rules, because all deep dependencies will be reported as untracked. Cheers, Andrey On 27 Mar 2019 18:27, Simon Peyton Jones wrote: With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" But I question that assumption. As I mentioned, with GHC at least, the if a deep dependency changes then one of the shallow dependencies will change. So I claim that even for cloud build it should be enough to depend only on shallow dependencies. This is only true because GHC offers this guarantee. We’d need to be sure that every deep dependency was either ‘needed’ or was reflected in the contents (perhaps via a fingerprint) another ‘needed’ thing. Simon From: ghc-devs On Behalf Of David Eichmann Sent: 27 March 2019 17:12 To: Andrey Mokhov ; Neil Mitchell Cc: GHC developers Subject: Re: Hadrian Transitive Dependencies Hello, To reiterate some definitions consider this scenario: * A.hs imports B.hs and B.hs imports C.hs * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi There seems to be some confusion about the term "Direct Dependency" I'll use these definitions: "Shallow Dependency": With respect to a haskell object file X.o, the shallow dependencies are the source file X.hs and interface files Y.hi for all modules Y imported by X. * These are the dependencies of X.o as reported by `ghc -M X.hs` * In the above scenario: * * A.o depends on: A.hs, B.hi "Deep Dependency": With respect to a haskell object file X.o, the deep dependencies are all hi files required by ghc to build X.o excluding direct dependencies: * This is a subset of modules transitively imported by X * These dependencies are NOT reported by `ghc -M X.hs` "Direct Dependency": if the command to create file X accesses file Y, then X directly depends on Y (= Y is a direct dependency of X). * In the above scenario: * * A.o directly depends on: A.hs, B.hi, and C.hi * SPJ noted that .hi files list direct dependencies. * The direct dependencies of a haskell object file is the union of its shallow and deep dependencies. "Direct Output": All files created by a rule. With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" (where this agrees with the definitions above) can we do the following for the build rule of a haskell object file X.o? 1. `need` the shallow dependencies as reported by `ghc -M`. This guarantees that all shallow and deep dependencies (i.e. all direct dependencies) are built. 2. build X.o and X.hi 3. Inspect X.hi to derive the direct dependencies (and hence deep dependencies) 4. `needed` the deep dependencies Is there already an easy way to inspect *.hi files in this way? Is this use of `needed` valid? - David E On 3/27/19 3:05 PM, Andrey Mokhov wrote: Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: * Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. * Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. * Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide at well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell ; Andrey Mokhov ; GHC developers Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -- 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 davide at well-typed.com Wed Mar 27 18:03:34 2019 From: davide at well-typed.com (David Eichmann) Date: Wed, 27 Mar 2019 18:03:34 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com> Message-ID: <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com> Ah! I see. This is a bit disappointing as it reduces the utility of fsatrace linting: the programmer is forced to decide if shallow dependencies are sufficient (changes in deep dependencies always change shallow dependencies). Hopeful similar scenarios are rare. Perhaps the best step forward is to simply silence the linting using `trackAllow ["//*.hi"]` for haskell object rules. Then I can continue tracking down other missing dependencies in Hadrian with fsatrace linting. On 3/27/19 5:38 PM, Andrey Mokhov wrote: > Simon's insight is great: if deep dependencies are captured by shallow > dependencies then the cloud build system is correct even if only > direct shallow inputs are tracked. > > That's a very non-trivial invariant, and I guess this means we can't > rely on fsatrace linting for GHC compilation rules, because all deep > dependencies will be reported as untracked. > > Cheers, > Andrey > > On 27 Mar 2019 18:27, Simon Peyton Jones wrote: > > With that in mind, and considering a cloud build system where > "*all direct inputs and direct outputs must be declared*" > > *But I question that assumption*.   As I mentioned, with GHC at > least, the if a deep dependency changes then one of the shallow > dependencies will change.  So I claim that even for cloud build it > should be enough to depend only on shallow dependencies. > > This is only true because GHC offers this guarantee.  We’d need to > be sure that every deep dependency was either ‘needed’ or was > reflected in the contents (perhaps via a fingerprint) another > ‘needed’ thing. > > Simon > > *From:*ghc-devs *On Behalf Of > *David Eichmann > *Sent:* 27 March 2019 17:12 > *To:* Andrey Mokhov ; Neil Mitchell > > *Cc:* GHC developers > *Subject:* Re: Hadrian Transitive Dependencies > > Hello, > > To reiterate some definitions consider this scenario: > > * A.hs imports B.hs and B.hs imports C.hs > * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi > * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi > > There seems to be some confusion about the term "Direct > Dependency" I'll use these definitions: > > "Shallow Dependency": With respect to a haskell object file X.o, > the shallow dependencies are the source file X.hs and interface > files Y.hi for all modules Y imported by X. > > * These are the dependencies of X.o as reported by `ghc -M X.hs` > * In the above scenario: > > * > o A.o depends on: A.hs, B.hi > > "Deep Dependency": With respect to a haskell object file X.o, the > deep dependencies are all hi files required by ghc to build X.o > excluding direct dependencies: > > * This is a subset of modules transitively imported by X > * These dependencies are NOT reported by `ghc -M X.hs` > > "Direct Dependency": if the command to create file X accesses file > Y, then X directly depends on Y (= Y is a direct dependency of X). > > * In the above scenario: > > * > o A.o directly depends on: A.hs, B.hi, and C.hi > > * SPJ noted that .hi files list direct dependencies. > * The direct dependencies of a haskell object file is the union > of its shallow and deep dependencies. > > "Direct Output": All files created by a rule. > > With that in mind, and considering a cloud build system where > "*all direct inputs and direct outputs must be declared*" (where > this agrees with the definitions above) can we do the following > for the build rule of a haskell object file X.o? > > 1. `need` the shallow dependencies as reported by `ghc -M`. This > guarantees that all shallow and deep dependencies (i.e. all > direct dependencies) are built. > 2. build X.o and X.hi > 3. Inspect X.hi to derive the direct dependencies (and hence deep > dependencies) > 4. `needed` the deep dependencies > > Is there already an easy way to inspect *.hi files in this way? Is > this use of `needed` valid? > > - David E > > On 3/27/19 3:05 PM, Andrey Mokhov wrote: > > Hi David, > > We had a discussion about this with Neil some time ago, and I > think we had the following list of progressively more complex > invariants for different types of build systems: > > * Non-cloud build systems: **all direct inputs must be > declared**. If you miss a direct input dependency then a > build may complete successfully but with an incorrect result. > > * Cloud build systems: **all direct inputs and direct > outputs must be declared**. If you miss a direct output > then a build may fail because the cloud will not be able > to restore the corresponding output. > > * Cloud build systems with shallow (deferred) > materialisation of build artefacts: **all transitive > inputs and direct outputs must be declared**. Let’s say > you’d like to download the resulting GHC binary directly, > without materialising any intermediate artefacts. Then > you’ll need to know GHC’s ultimate transitive inputs. > > I think for now we are really keen to make Hadrian a cloud > build system, but whether shallow builds are valuable enough > is not clear. Maybe not. Therefore, I’d say we don’t need to > track transitive inputs right now. Furthermore, if we were to > track all transitive inputs, we would lose the desirable early > cutoff property, which prevents rebuilding after adding a > comment in a file on which a lot of other files transitively > depend on. > > Having said that, if we really access a file during > compilation, then I think it is **not** a transitive > dependency by definition! Any file which is accessed during a > build rule is a direct dependency. > > > GHC is reading *.hi files that are not reported as dependencies by > > > `ghc -M -include-pkg-deps`. This is because they are not direct, but > transitive > > > dependencies! > > So, here I’m confused. If we read a file A when compiling a > file B, then it’s by definition a direct dependency. Perhaps > we just read too much? Maybe the solution is to switch to > fine-grained `ghc -M` mode, to analyse import dependencies for > a single module instead of doing it transitively, which I > believe was discussed in a ticket some time ago? I can’t find > this ticket, but I think Alp was looking into it at some > point. Alp: do you remember it? > > Thank you for all your work on Hadrian! > > Cheers, > > Andrey > > *From:*David Eichmann [mailto:davide at well-typed.com] > *Sent:* 27 March 2019 12:54 > *To:* Neil Mitchell > ; Andrey Mokhov > > ; GHC developers > > *Subject:* Hadrian Transitive Dependencies > > Hello Shake/Hadrian contributors and the like, > > Recently I've been putting Hadrian's fsatrace linting feature > to good use, tracking down missing dependencies in Hadrian. > Ultimately, we want to use shake's cloud build / shared cache > feature and ensure it works across CI builds. Unfortunately > the feature isn't working smoothly with Hadrian: see #16295 > . > This is very desirable to improve CI build times. It is my > understanding that in order to get caching to work: > > 1. All accessed files must declared with `need` AND > 2. All created files must be declared with `produces` (or be > the target of the build rule) > > Is my understanding correct? Or is there a weaker condition > (perhaps only 2 is necessary)? > > If I'm correct, this amounts to fixing all fsatrace lint > errors. See here > > for a breakdown of lint errors / missing dependencies. A large > portion of these are Haskell interface files (i.e. *.hi > files). Before building a Haskell object file, dependencies > are discovered via `ghc` using the `-M  -include-pkg-deps` > options. Unfortunately, shake's fsatrace linting complains > about other *.hi files being accessed! For example when > building > `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get > the following dependencies from ghc: > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi > > _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi > > And shake complains of the following missing deps: > > _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags > > Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: > >   Used:  _build/HEAD_default/stage0/lib/settings > >   Used:  _build/HEAD_default/stage0/lib/platformConstants > >   Used:  _build/HEAD_default/stage0/lib/llvm-targets > >   Used:  _build/HEAD_default/stage0/lib/llvm-passes > >   Used:  _build/HEAD_default/stage0/lib/package.conf.d/package.cache > >   Used:  _build/HEAD_default/stage1/lib/package.conf.d/package.cache > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi > >   Used:  _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi > > GHC is reading *.hi files that are not reported as > dependencies by `ghc -M -include-pkg-deps`. This is because > they are not direct, but /transitive/ dependencies! How do we > fix these lint errors (again with the goal of using shakes > shared cache feature)? Some ideas: > > * Wildly over approximate dependencies. This may be easier to > implement but cause unneeded recompilation (when a false > dependency changes). Either: >     * `need` all dependent packages' interface files > recursively as well as transitive dependencies reported by > `ghc -M -include-pkg-deps` within the current package. OR >     * OR `need` all transitive dependencies reported by `ghc > -M  -include-pkg-deps`. This will likely result in fewer > dependencies but requires a bit more work in recovering > dependent packages' dependency graphs. > * Perhaps transitive dependencies are not important for shared > caching to work. Change shakes linting feature to allow > (untracked?) transitive dependencies to be accessed. > > Feed back would be greatly appreciated. > > 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 > > -- > > 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 Wed Mar 27 23:04:05 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Mar 2019 23:04:05 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com> References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com> <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com> Message-ID: This is a bit disappointing But it’s also Absolutely Great because it means that zillions of very-hard-to-predict dependencies don’t need to be explicitly ‘needed’. Perhaps the remaining un-tracked dependencies will be fewer and easier to nail? Simon From: David Eichmann Sent: 27 March 2019 18:04 To: Andrey Mokhov ; Simon Peyton Jones Cc: Neil Mitchell ; GHC developers Subject: Re: Hadrian Transitive Dependencies Ah! I see. This is a bit disappointing as it reduces the utility of fsatrace linting: the programmer is forced to decide if shallow dependencies are sufficient (changes in deep dependencies always change shallow dependencies). Hopeful similar scenarios are rare. Perhaps the best step forward is to simply silence the linting using `trackAllow ["//*.hi"]` for haskell object rules. Then I can continue tracking down other missing dependencies in Hadrian with fsatrace linting. On 3/27/19 5:38 PM, Andrey Mokhov wrote: Simon's insight is great: if deep dependencies are captured by shallow dependencies then the cloud build system is correct even if only direct shallow inputs are tracked. That's a very non-trivial invariant, and I guess this means we can't rely on fsatrace linting for GHC compilation rules, because all deep dependencies will be reported as untracked. Cheers, Andrey On 27 Mar 2019 18:27, Simon Peyton Jones wrote: With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" But I question that assumption. As I mentioned, with GHC at least, the if a deep dependency changes then one of the shallow dependencies will change. So I claim that even for cloud build it should be enough to depend only on shallow dependencies. This is only true because GHC offers this guarantee. We’d need to be sure that every deep dependency was either ‘needed’ or was reflected in the contents (perhaps via a fingerprint) another ‘needed’ thing. Simon From: ghc-devs On Behalf Of David Eichmann Sent: 27 March 2019 17:12 To: Andrey Mokhov ; Neil Mitchell Cc: GHC developers Subject: Re: Hadrian Transitive Dependencies Hello, To reiterate some definitions consider this scenario: * A.hs imports B.hs and B.hs imports C.hs * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi There seems to be some confusion about the term "Direct Dependency" I'll use these definitions: "Shallow Dependency": With respect to a haskell object file X.o, the shallow dependencies are the source file X.hs and interface files Y.hi for all modules Y imported by X. * These are the dependencies of X.o as reported by `ghc -M X.hs` * In the above scenario: · * A.o depends on: A.hs, B.hi "Deep Dependency": With respect to a haskell object file X.o, the deep dependencies are all hi files required by ghc to build X.o excluding direct dependencies: * This is a subset of modules transitively imported by X * These dependencies are NOT reported by `ghc -M X.hs` "Direct Dependency": if the command to create file X accesses file Y, then X directly depends on Y (= Y is a direct dependency of X). * In the above scenario: · * A.o directly depends on: A.hs, B.hi, and C.hi * SPJ noted that .hi files list direct dependencies. * The direct dependencies of a haskell object file is the union of its shallow and deep dependencies. "Direct Output": All files created by a rule. With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" (where this agrees with the definitions above) can we do the following for the build rule of a haskell object file X.o? 1. `need` the shallow dependencies as reported by `ghc -M`. This guarantees that all shallow and deep dependencies (i.e. all direct dependencies) are built. 2. build X.o and X.hi 3. Inspect X.hi to derive the direct dependencies (and hence deep dependencies) 4. `needed` the deep dependencies Is there already an easy way to inspect *.hi files in this way? Is this use of `needed` valid? - David E On 3/27/19 3:05 PM, Andrey Mokhov wrote: Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: * Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. * Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. * Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide at well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell ; Andrey Mokhov ; GHC developers Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. 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 -- 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 andrey.mokhov at newcastle.ac.uk Wed Mar 27 23:23:29 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Wed, 27 Mar 2019 23:23:29 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com> <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com> Message-ID: Simon: > Perhaps the remaining un-tracked dependencies will be fewer and easier to nail? There are a few other cases where we `need` only a subset of direct dependencies that "cover" all others. For example, `setup-config` files produced when configuring a package are used to signal the completion of package configuration, which might produce a few other hard-to-predict files, such as “build/include/HsBaseConfig.h”. I just realised that if one wants to have “hermetic builds”, where build commands are executed in a sandbox, then it is absolutely necessary to declare all direct dependencies without exception, because they will need to be made available in the sandbox for the build command to succeed. David: > Perhaps the best step forward is to simply silence the linting > using `trackAllow ["//*.hi"]` for haskell object rules. Then > I can continue tracking down other missing dependencies in > Hadrian with fsatrace linting. Yes, this looks like the best approach for now. Cheers, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Mar 28 10:08:47 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 28 Mar 2019 10:08:47 +0000 Subject: Proposal: Don't read environment files by default Message-ID: Hi all, Environment files have caused a large amount of pain for users because they are read by default by GHC. For example: https://github.com/haskell/cabal/issues/4542 Cabal developers have indicated that they are not going to stop generating them by default despite the overwhelming user pressure. Therefore I propose that users should opt-in to using environment files by having to explicitly pass a flag to enable the search behavior. This will provide a much better user experience overall and will stop tooling having to isolate itself from their existence. Cheers, Matt From hvriedel at gmail.com Thu Mar 28 12:24:39 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 28 Mar 2019 13:24:39 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: (Matthew Pickering's message of "Thu, 28 Mar 2019 10:08:47 +0000") References: Message-ID: <878swzjiew.fsf@gmail.com> Matthew, I realize this to be a controversial issue, but what you're suggesting is effectively an attempt at cutting this cabal V2 feature off at the knees ("If Cabal won't change its default let's cripple this feature on GHC's side by rendering it pointless to use in cabal"). If ghc environment aren't read anymore by default they fail to have the purpose they were invented for in the first place! At the risk of repeating things I've tried to explain already in the GitHub issue let me motivate (again) why we have these env files: We want to be able to provide a stateful interface providing the common idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` already provided in the past; e.g. ,---- | $ cabal v1-install lens lens-aeson | | $ ghc --make MyProgUsingLens.hs | [1 of 1] ... | ... | | $ ghci | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help | Prelude> import Control.Lens | Prelude Control.Lens> `---- or similarly, when you had just `cabal v1-build` something, you'd get access to your projects dependencies which were installed into ghc's user pkg-db. This is also a workflow which has been well documented for over a decade in Haskell's literature and instructions *and* this is the same idiom as used by many popular package managers out there ("${pkgmgr} install somelibrary") So `cabal v1-build` made use of the user package-db facility to achieve this; but now with `cabal v2-build` the goal was to improve this workflow, but the user pkg-db facility wasn't a good fit anymore for the nix-style pkg store cache which can easily have dozens instances for the same lens-4.17 pkg-id cached (I just checked, I currently have 9 instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). So ghc environment files were born as a clever means to provide a thinned slice/view into the nix-style pkg store. And with these we can provide those workflows *without* the needed to pass extra flags or having to prefix each `ghc` invocation with `cabal repl`/`cabal exec`: ,---- | $ cabal v2-install --lib lens lens-aeson | | $ ghc --make MyProgUsingLens.hs | Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default | [1 of 1] ... | ... | | $ ghci | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help | Loaded package environment from /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default | Prelude> import Control.Lens | Prelude Control.Lens> `---- (and respectively for the `cabal v2-build` workflow) However, if we now had to explicitly pass a flag to ghc in order to have it pick up ghc env files, this would severly break this workflow everytime you forget about it, and it would certainly cause a lot of confusion (of e.g. users following instructions such as `cabal install lens` and then being confused that GHCi doesn't pick it up) and therefore a worse user experience for cabal users. Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6 have been picking up ghc env files by default (and finally we've reached the point where the pkg-env-file-agnostic GHC versions are old enough to have moved outside the traditional 3-5 major ghc release support-windows!), and now you'd have to remember which GHC versions don't do this anymore and instead require passing an additional flag. This would IMO translate to a terrible user experience. And also tooling would still need to have the logic to "isolate themselves" for those versions of GHC that picked up env files by default unless they dropped support for older versions. Also, how much tooling is there even that needs to be aware of this and how did it cope with GHC's user pkg db which can easily screw up things as well by providing a weird enough pkg-db env! And why is it considered such a big burden for tooling to invoke GHC in a robust enough way to not be confused by the user's configuration? IMO, shifting the cost of passing an extra flag to a tool which doesn't feel any pain is the better tradeoff than to inconvience all cabal users to have rememeber to pass an additional flag for what is designed to be the default UI/workflow idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix environment which already controls environment vars can easily override GHC's or cabal's defaults to tailor them more towards Nix's specific assumptions/requirements. Long story short, I'm -1 on changing GHC's default as the resulting downsides clearly outweight IMO. From rae at richarde.dev Thu Mar 28 13:49:48 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 28 Mar 2019 09:49:48 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: I have spent quite a bit of time debugging this issue, being utterly surprised about the existence of these files. Furthermore, until today, I had been unable to find a way to turn the feature off. I now understand (https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented mechanism for doing so in GHC. It's still frustrating that there is no similar mechanism to globally (i.e., in ~/.cabal/config) disable these files in cabal. While I expect "project-based" tools to care about their directory (e.g., git, cabal, stack), I would never expect a compiler (which is intended to be a low-level utility) to do so. Richard > On Mar 28, 2019, at 6:08 AM, Matthew Pickering wrote: > > Hi all, > > Environment files have caused a large amount of pain for users because > they are read by default by GHC. > > For example: https://github.com/haskell/cabal/issues/4542 > > Cabal developers have indicated that they are not going to stop > generating them by default despite the overwhelming user pressure. > > Therefore I propose that users should opt-in to using environment > files by having to explicitly pass a flag to enable the search > behavior. > > This will provide a much better user experience overall and will stop > tooling having to isolate itself from their existence. > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From b at chreekat.net Thu Mar 28 13:55:01 2019 From: b at chreekat.net (Bryan Richter) Date: Thu, 28 Mar 2019 15:55:01 +0200 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: I am +1 on not reading them by default. I dislike implicit configuration (that's enough reason there), and it interacts poorly with other tools that use ghc. Like Richard Eisenberg, I also think of ghc as a low-level utility, but I recognize that intuition is already wrong in various ways. (ghc is really quite clever.) For me that's not reason enough to disable this. The tight coupling with Cabal, however, seems unwise, and implicit configuration seems like something from the 20th century. If we want Nix-style builds, let's do them Nix style, and use a shell. On Thu, Mar 28, 2019 at 3:50 PM Richard Eisenberg wrote: > I have spent quite a bit of time debugging this issue, being utterly > surprised about the existence of these files. Furthermore, until today, I > had been unable to find a way to turn the feature off. I now understand ( > https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an > undocumented mechanism for doing so in GHC. It's still frustrating that > there is no similar mechanism to globally (i.e., in ~/.cabal/config) > disable these files in cabal. > > While I expect "project-based" tools to care about their directory (e.g., > git, cabal, stack), I would never expect a compiler (which is intended to > be a low-level utility) to do so. > > Richard > > > On Mar 28, 2019, at 6:08 AM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > > > Hi all, > > > > Environment files have caused a large amount of pain for users because > > they are read by default by GHC. > > > > For example: https://github.com/haskell/cabal/issues/4542 > > > > Cabal developers have indicated that they are not going to stop > > generating them by default despite the overwhelming user pressure. > > > > Therefore I propose that users should opt-in to using environment > > files by having to explicitly pass a flag to enable the search > > behavior. > > > > This will provide a much better user experience overall and will stop > > tooling having to isolate itself from their existence. > > > > Cheers, > > > > Matt > > _______________________________________________ > > 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 oleg.grenrus at iki.fi Thu Mar 28 13:58:07 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 28 Mar 2019 15:58:07 +0200 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: There is. Add     write-ghc-environment-files: never to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. - Oleg On 28.3.2019 15.49, Richard Eisenberg wrote: > I have spent quite a bit of time debugging this issue, being utterly surprised about the existence of these files. Furthermore, until today, I had been unable to find a way to turn the feature off. I now understand (https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented mechanism for doing so in GHC. It's still frustrating that there is no similar mechanism to globally (i.e., in ~/.cabal/config) disable these files in cabal. > > While I expect "project-based" tools to care about their directory (e.g., git, cabal, stack), I would never expect a compiler (which is intended to be a low-level utility) to do so. > > Richard > >> On Mar 28, 2019, at 6:08 AM, Matthew Pickering wrote: >> >> Hi all, >> >> Environment files have caused a large amount of pain for users because >> they are read by default by GHC. >> >> For example: https://github.com/haskell/cabal/issues/4542 >> >> Cabal developers have indicated that they are not going to stop >> generating them by default despite the overwhelming user pressure. >> >> Therefore I propose that users should opt-in to using environment >> files by having to explicitly pass a flag to enable the search >> behavior. >> >> This will provide a much better user experience overall and will stop >> tooling having to isolate itself from their existence. >> >> Cheers, >> >> Matt >> _______________________________________________ >> 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 hvriedel at gmail.com Thu Mar 28 14:31:49 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 28 Mar 2019 15:31:49 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: (Bryan Richter's message of "Thu, 28 Mar 2019 15:55:01 +0200") References: Message-ID: <874l7njciy.fsf@gmail.com> On 2019-03-28 at 15:55:01 +0200, Bryan Richter wrote: [...] > If we want Nix-style builds, let's do them Nix style, and use a shell. Cabal supports multiple workflows/idioms. Sometimes you want a transient sub-shell (which is the one you're e.g. limited to when using Stack), while sometimes you want to use cabal to set up an implicit stateful environment after which you want cabal to be completely out of the picture and operate in a non-Nix-style idiom... I for one would hate to remove what I consider a useful feature (which I happen to use a lot myself and I also show it off when teaching Haskell; and which we spent a lot of effort designing and implementing in ghc and cabal over the last couple years...) just to satisfy another group of people who don't appreciate it and request that those who like it shall not have it anymore... :-/ From davide at well-typed.com Thu Mar 28 15:21:27 2019 From: davide at well-typed.com (David Eichmann) Date: Thu, 28 Mar 2019 15:21:27 +0000 Subject: Hadrian Transitive Dependencies In-Reply-To: References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com> <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com> Message-ID: <6bbb3fa3-5aab-e892-a9ab-6570d948d0b0@well-typed.com> I've started a wiki page to document some of this discussion https://gitlab.haskell.org/ghc/ghc/wikis/Developing-Hadrian. We'll also need to deal with ouputs as well as inputs (dependencies) soon. Hence I've expanded a bit on my understanding of rule *outputs* and added the terms "vital input" and "vital output" (does it make sense? is there a better name here?). I've slightly changed the definition of "shallow dependencies" so that by definition it is a (minimal) subset of direct dependencies such that "/no change in the shallow dependencies -> no change in the vial output/" The important part to take away is that rules must: * `need` all shallow dependencies. * |`produces|` all vital outputs (excluding the rule target). David E On 3/27/19 11:23 PM, Andrey Mokhov wrote: > > Simon: > > > Perhaps the remaining un-tracked dependencies will be fewer and > easier to nail? > > There are a few other cases where we `need` only a subset of direct > dependencies that "cover" all others. For example, `setup-config` > files produced when configuring a package are used to signal the > completion of package configuration, which might produce a few other > hard-to-predict files, such as “build/include/HsBaseConfig.h”. > > I just realised that if one wants to have “hermetic builds”, where > build commands are executed in a sandbox, then it is absolutely > necessary to declare all direct dependencies without exception, > because they will need to be made available in the sandbox for the > build command to succeed. > > David: > > > Perhaps the best step forward is to simply silence the linting > > > using `trackAllow ["//*.hi"]` for haskell object rules. Then > > > I can continue tracking down other missing dependencies in > > > Hadrian with fsatrace linting. > > Yes, this looks like the best approach for now. > > Cheers, > > Andrey > -- 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 rae at richarde.dev Thu Mar 28 15:49:24 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 28 Mar 2019 11:49:24 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: <874l7njciy.fsf@gmail.com> References: <874l7njciy.fsf@gmail.com> Message-ID: <19DC4B66-7CF4-4555-9035-06EA35074277@richarde.dev> > On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel wrote: > > I for one would hate to remove what I consider a useful feature I don't see anyone is asking for a feature removal here. This thread seems to be more about how to set a default. I personally find it surprising for a tool like a compiler to be directory-sensitive. But I've now learned that with `export GHC_ENVIRONMENT=-` in my profile, my compiler indeed isn't directory-sensitive. Furthermore, I've learned how to suppress the env files entirely with `write-ghc-environment-files: never` in my ~/.cabal/config. So I'm not actually all too bothered by this anymore. I retain my opinion that directory-sensitivity is a poor design (it's precisely what threw me off Stack the first time I tried it) for compiler-like tools, but perhaps that ship has sailed, as I agree that changing this now may lead to a poor user experience. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Thu Mar 28 16:17:53 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 28 Mar 2019 09:17:53 -0700 Subject: Proposal: Don't read environment files by default In-Reply-To: <19DC4B66-7CF4-4555-9035-06EA35074277@richarde.dev> References: <874l7njciy.fsf@gmail.com> <19DC4B66-7CF4-4555-9035-06EA35074277@richarde.dev> Message-ID: I used to be confused by the environment files too until I figured out what they are, and now I use them all the time. It is really nice to be able to have the "old fashioned" way of just running ghci and having it be aware of the current project your are in. To me, it really makes sense to be aware of the context by default. To reduce confusion, we could make GHCi be more explicit about telling the user that it loaded a context, but I think 99% of the time I want it to so. So I'd prefer to have a flag to disable the behavior for the 1%, but the default should load the context IMHO Iavor On Thu, Mar 28, 2019, 08:49 Richard Eisenberg wrote: > > > On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel > wrote: > > I for one would hate to remove what I consider a useful feature > > > I don't see anyone is asking for a feature removal here. This thread seems > to be more about how to set a default. > > I personally find it surprising for a tool like a compiler to be > directory-sensitive. But I've now learned that with `export > GHC_ENVIRONMENT=-` in my profile, my compiler indeed isn't > directory-sensitive. Furthermore, I've learned how to suppress the env > files entirely with `write-ghc-environment-files: never` in my > ~/.cabal/config. So I'm not actually all too bothered by this anymore. I > retain my opinion that directory-sensitivity is a poor design (it's > precisely what threw me off Stack the first time I tried it) for > compiler-like tools, but perhaps that ship has sailed, as I agree that > changing this now may lead to a poor user experience. > > Richard > _______________________________________________ > 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 spam at scientician.net Thu Mar 28 17:01:44 2019 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 28 Mar 2019 18:01:44 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: On 28/03/2019 14.58, Oleg Grenrus wrote: > There is. Add > >     write-ghc-environment-files: never > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. > That doesn't really work if you actually want to be able to use both ways of working, does it? That same thing applies to export GHC_ENVIRONMENT=- which someone else posted, but at least that can be done by tooling before invoking ghc. It's odd to have to change a global setting to avoid this. (However, thanks for the hints -- I'll be setting that GHC_ENVIRONMENT from now on.) +1 for changing the default. It seems really weird to force other tooling to opt out when this could easily be solved by just having cabal ghci cabal ghc commands which set up the environment properly and tell users to use that if they want to use cabal's environment files. FWIW, I also see e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not something users should really be running unless they know what they're doing *and* it should be as tooling-friendly as possible. Regards, From shayne.fletcher at daml.com Thu Mar 28 17:37:04 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Thu, 28 Mar 2019 13:37:04 -0400 Subject: gitlab.haskell.org is down Message-ID: Hi, It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage? -- 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 smart-cactus.org Thu Mar 28 17:40:16 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 28 Mar 2019 13:40:16 -0400 Subject: GitLab down Message-ID: <87o95uj3t1.fsf@smart-cactus.org> Hi everyone, Due to unplanned maintenance gitlab.haskell.org is currently down. Sorry for the inconvenience. I'll post updates as appropriate. 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 smart-cactus.org Thu Mar 28 17:43:47 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 28 Mar 2019 13:43:47 -0400 Subject: gitlab.haskell.org is down In-Reply-To: References: Message-ID: <87k1gij3n2.fsf@smart-cactus.org> Shayne Fletcher via ghc-devs writes: > Hi, > > It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage? > Yes, I just sent notification of this. A routine service restart ended up going wrong. In touch with our infrastructure company's support team. More updates coming soon. 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 iavor.diatchki at gmail.com Thu Mar 28 18:09:45 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 28 Mar 2019 11:09:45 -0700 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want. What is the workflow that this proposal optimizes? The default behavior should be what's commonly useful and, in my experience, when I run GHCi in the context of a project, I pretty much always want it to load the environment associated with the project. It is incredibly useful when you are working on a project where there are multiple broken modules (e.g., during refactoring), and you want to fix them one at a time, in the order that makes sense to you. -Iavor On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson wrote: > On 28/03/2019 14.58, Oleg Grenrus wrote: > > There is. Add > > > > write-ghc-environment-files: never > > > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. > > > > That doesn't really work if you actually want to be able to use both > ways of working, does it? That same thing applies to > > export GHC_ENVIRONMENT=- > > which someone else posted, but at least that can be done by tooling > before invoking ghc. It's odd to have to change a global setting to > avoid this. (However, thanks for the hints -- I'll be setting that > GHC_ENVIRONMENT from now on.) > > +1 for changing the default. > > It seems really weird to force other tooling to opt out when this could > easily be solved by just having > > cabal ghci > cabal ghc > > commands which set up the environment properly and tell users to use > that if they want to use cabal's environment files. FWIW, I also see > e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas > e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not > something users should really be running unless they know what they're > doing *and* it should be as tooling-friendly as possible. > > Regards, > > _______________________________________________ > 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 duncan at well-typed.com Thu Mar 28 18:22:12 2019 From: duncan at well-typed.com (Duncan Coutts) Date: Thu, 28 Mar 2019 18:22:12 +0000 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: <1553797332.22450.39.camel@well-typed.com> As one of the culprits who implemented this idea in ghc and cabal the first place, I think that if it turns out this is just too surprising for everyone then we should indeed change the default, and provide another easy way to use it. The intention of course is exactly what Iavor described: > The default behavior should be what's commonly useful and, in my > experience, when I run GHCi in the context of a project, I pretty > much always want it to load the environment associated with the > project.   It is incredibly useful when you are working on a project > where there are multiple broken modules (e.g., during refactoring), > and you want to fix them one at a time, in the order that makes sense > to you. The intention was to not force everyone to use "stack ghci" and "cabal ghci" all the time, and for tutorials etc that just say "ghci" to actually work. It's nice to be able to work with those tools directly. Afterall, they're not that low level (like gcc); ghc/ghci have --make functionality built in and can be used directly (i.e. without a ton of flags). But fair enough, there seems to be a very large number of users where this behaviour is surprising, including reports I hear about the intro tutorial setting. Perhaps the next best thing is a "cabal shell" feature, that enters a new system shell environment where ghc/ghci etc do pick up the project environment. This would rely on ghc continuing to use the environment variables to select an package file, but we could disable ghc reading the files by default. Thoughts? On Thu, 2019-03-28 at 10:08 +0000, Matthew Pickering wrote: > Hi all, > > Environment files have caused a large amount of pain for users > because > they are read by default by GHC. > > For example: https://github.com/haskell/cabal/issues/4542 > > Cabal developers have indicated that they are not going to stop > generating them by default despite the overwhelming user pressure. > > Therefore I propose that users should opt-in to using environment > files by having to explicitly pass a flag to enable the search > behavior. > > This will provide a much better user experience overall and will stop > tooling having to isolate itself from their existence. From vanessa.mchale at iohk.io Thu Mar 28 18:23:03 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Thu, 28 Mar 2019 13:23:03 -0500 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: I use cabal new-repl. I actually kind of like having GHC environment files (maybe not as a default) but they remind me of "vim turds" in that they end up littering your projects. Cheers, Vanessa McHale On 3/28/19 1:09 PM, Iavor Diatchki wrote: > I am quite confused as to how people are using `ghci` without loading > the environment files, at least in the context of cabal v2 (aka "new > cabal").   When you run `ghci` on its own, unless you load an > environment file, you would only have access to globally installed > packages, which is almost never what you want.   What is the workflow > that this proposal optimizes? > > The default behavior should be what's commonly useful and, in my > experience, when I run GHCi in the context of a project, I pretty much > always want it to load the environment associated with the project.  >  It is incredibly useful when you are working on a project where there > are multiple broken modules (e.g., during refactoring), and you want > to fix them one at a time, in the order that makes sense to you. > > -Iavor > > > On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson > > wrote: > > On 28/03/2019 14.58, Oleg Grenrus wrote: > > There is. Add > > > >     write-ghc-environment-files: never > > > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 > or later. > > > > That doesn't really work if you actually want to be able to use both > ways of working, does it? That same thing applies to > >   export GHC_ENVIRONMENT=- > > which someone else posted, but at least that can be done by tooling > before invoking ghc. It's odd to have to change a global setting to > avoid this. (However, thanks for the hints -- I'll be setting that > GHC_ENVIRONMENT from now on.) > > +1 for changing the default. > > It seems really weird to force other tooling to opt out when this > could > easily be solved by just having > >    cabal ghci >    cabal ghc > > commands which set up the environment properly and tell users to use > that if they want to use cabal's environment files. FWIW, I also see > e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas > e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not > something users should really be running unless they know what they're > doing *and* it should be as tooling-friendly as possible. > > Regards, > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From me at michaelpj.com Thu Mar 28 18:33:58 2019 From: me at michaelpj.com (Michael Peyton Jones) Date: Thu, 28 Mar 2019 18:33:58 +0000 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used by many other tools that handle this kind of thing. For example: - nix-shell - virtualenv - rbenv - sbt - jenv The advantage is that the scoping of the special configuration is very clear: it's the shell that the command launches. Programmers are very used to this, and changes in shell environments are expected to change the behaviour of programs. Plus, as functional programmers this is just the sort of idiom we use all the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`. On the negative side: I've helped ~6 people at my company alone debug issues due to environment files. Two of those were novice users (the people whom this feature is supposed to help). In my experience it breaks people's assumptions about what sort of things influence compiler invocations. People don't expect a stateful dependency from a previous run of a build tool to a later run of a lower-level compiler. Moreover, the failures can be mystifying, and I was only able to help because I already knew "get rid of any environment files" as a solution to "weird dependency issues". *However*, I think Herbert is quite right that this particular proposal amounts to "remove this feature". The following might be a compromise solution: we can introduce `cabal ghc` as a parallel feature, and then in a few releases we can assess the popularity of the two approaches, and potentially stop generating environment files from Cabal if people aren't using them. I think there are enough people that feel strongly about environment files that we could get together the manpower to write `cabal ghc`. > This is also a workflow which has been well documented for over a decade in Haskell's literature and instructions *and* this is the same idiom as used by many popular package managers out there ("${pkgmgr} install somelibrary") This is an interesting bit of background. FWIW, I would feel a lot better about this feature if it wasn't a side-effect of `cabal build`. If you had to run `cabal save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects` that wouldn't bother me (I still wouldn't use it, though). The current situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`, which is a bit surprising. M On Thu, Mar 28, 2019 at 5:02 PM Bardur Arantsson wrote: > On 28/03/2019 14.58, Oleg Grenrus wrote: > > There is. Add > > > > write-ghc-environment-files: never > > > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. > > > > That doesn't really work if you actually want to be able to use both > ways of working, does it? That same thing applies to > > export GHC_ENVIRONMENT=- > > which someone else posted, but at least that can be done by tooling > before invoking ghc. It's odd to have to change a global setting to > avoid this. (However, thanks for the hints -- I'll be setting that > GHC_ENVIRONMENT from now on.) > > +1 for changing the default. > > It seems really weird to force other tooling to opt out when this could > easily be solved by just having > > cabal ghci > cabal ghc > > commands which set up the environment properly and tell users to use > that if they want to use cabal's environment files. FWIW, I also see > e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas > e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not > something users should really be running unless they know what they're > doing *and* it should be as tooling-friendly as possible. > > Regards, > > _______________________________________________ > 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 hvriedel at gmail.com Thu Mar 28 19:09:21 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 28 Mar 2019 20:09:21 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: <1553797332.22450.39.camel@well-typed.com> (Duncan Coutts's message of "Thu, 28 Mar 2019 18:22:12 +0000") References: <1553797332.22450.39.camel@well-typed.com> Message-ID: <87tvfmizoe.fsf@gmail.com> On 2019-03-28 at 18:22:12 +0000, Duncan Coutts wrote: > The intention was to not force everyone to use "stack ghci" and "cabal > ghci" all the time, And it's important to note that those who *want* to be forced to "cabal ghci" all the time, can still subject themselves to that idiom by configuring their cabal installation accordingly. However, the point here is that there's also those of us who don't want to be denied the ability to *not* be forced to use that idiom, and instead use the CWD-sensitive idiom which nobody complains about when using Git or make. With GHC/Cabal as it stands we are ahead of other ecosystems as we're in the advantageous position to be able to support *more* workflows than other ecosystems can support. IMO we should embrace and leverage the flexibility rather than to trying to artificially limit our possibilities just because we're doing something different. I mean, with that attitude we can just stop trying to do anything new... ;-) > Perhaps the next best thing is a "cabal shell" feature, that enters a > new system shell environment where ghc/ghci etc do pick up the project > environment. We already have this don't we? That's basically what `cabal v2-exec` does; but having to remember to invoke `cabal v2-exec bash` to enter a sub-shell is basically just a variant of "force everyone to use "cabal ghci" all the time where you have to go through cabal as a middleman even though you shouldn't have to. Don't get me wrong, it's good that we have `cabal v2-exec` as yet another tool in our toolbox and it can do a few extra things in that workflow and is useful for those who have opt-ed out of the automatic per-project CWD-driven-env-file management; *however*, it doesn't meet the needs for workflows of being able to invoke `ghci` without cursing like a sailor every time we end up in a useless GHCi session because we forgot to throw ourselves into a `cabal v2-exec` subshell in our n-th xterm (or [1]) even though other tooling like `make` or `git` which I'm used to as a developer does the right thing because they honor the common DWIM design principle/idiom for shell-oriented tooling... That being said, I'd be more interested to know the actual problems people are having and trying to address those without throwing the baby out with the bathwater, cause I think many of the problems are of the XY-problem variety here or simply because we did a terrible job at explaining, providing tutorials, or documenting how this feature works, what it is and what it isn't, how it can be used, and what cool new workflows are at our disposal with the upcoming major cabal 3.0 milestone... [1]: ...or even worse, being in the *wrong* subshell while you've already `cd`ed to a different project folder... imagine the amount of cursing you'd exhibit wondering for 5 minutes before you notice you're picking up another project's pkg env... From lonetiger at gmail.com Thu Mar 28 19:20:16 2019 From: lonetiger at gmail.com (Phyx) Date: Thu, 28 Mar 2019 19:20:16 +0000 Subject: Proposal: Don't read environment files by default In-Reply-To: References: Message-ID: > I am quite confused as to how people are using `ghci` without loading the environment files, at least in the context of cabal v2 (aka "new cabal"). When you run `ghci` on its own, unless you load an environment file, you would only have access to globally installed packages, which is almost never what you want. What is the workflow that this proposal optimizes? That's precisely how I use ghci. In quite a few of my use-cases all I care or want are the boot libraries and nothing else. I can appreciate that I may not be the common case here but I definitely use it this way. I'm agnostic on whether this change or not of reading the environment files by default. But I am very much against the cabal ghci or cabal ghc interfaces. It's one of the things I loathe the most about stack. I don't care what the compiler does by default on his own but I don't want to add another layer to the onion. I find this very hard to debug. Perhaps cabal should just ask you what you want the first time and that'll be your default. Tamar Sent from my Mobile On Thu, Mar 28, 2019, 18:10 Iavor Diatchki wrote: > I am quite confused as to how people are using `ghci` without loading the > environment files, at least in the context of cabal v2 (aka "new cabal"). > When you run `ghci` on its own, unless you load an environment file, you > would only have access to globally installed packages, which is almost > never what you want. What is the workflow that this proposal optimizes? > > The default behavior should be what's commonly useful and, in my > experience, when I run GHCi in the context of a project, I pretty much > always want it to load the environment associated with the project. It is > incredibly useful when you are working on a project where there are > multiple broken modules (e.g., during refactoring), and you want to fix > them one at a time, in the order that makes sense to you. > > -Iavor > > > On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson > wrote: > >> On 28/03/2019 14.58, Oleg Grenrus wrote: >> > There is. Add >> > >> > write-ghc-environment-files: never >> > >> > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. >> > >> >> That doesn't really work if you actually want to be able to use both >> ways of working, does it? That same thing applies to >> >> export GHC_ENVIRONMENT=- >> >> which someone else posted, but at least that can be done by tooling >> before invoking ghc. It's odd to have to change a global setting to >> avoid this. (However, thanks for the hints -- I'll be setting that >> GHC_ENVIRONMENT from now on.) >> >> +1 for changing the default. >> >> It seems really weird to force other tooling to opt out when this could >> easily be solved by just having >> >> cabal ghci >> cabal ghc >> >> commands which set up the environment properly and tell users to use >> that if they want to use cabal's environment files. FWIW, I also see >> e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas >> e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not >> something users should really be running unless they know what they're >> doing *and* it should be as tooling-friendly as possible. >> >> Regards, >> >> _______________________________________________ >> 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 rae at richarde.dev Thu Mar 28 19:26:00 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 28 Mar 2019 15:26:00 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: <87tvfmizoe.fsf@gmail.com> References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: > On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel wrote: > > That being said, I'd be more interested to know the actual problems > people are having I've run into two problems. I don't expect others to run into these particular problems, as my workflows are likely different than others', but both of these bit me independently. 1. I use two different machines regularly. I keep my files in sync between them using Dropbox. Yet, the Haskell installations between are not identical. Even if the GHC version is the same, it's quite likely that some library, etc., has been installed at a different version on the two machines. (Sometimes, even the GHC is different.) I did some work on a project on machine 1; this produced an environment file. Then, machine 2's window happened to be in the project directory. I wanted to spin up GHCi to check the type of, e.g., traverse. But GHCi wouldn't launch! This is because machine 1's work produced the environment file which invisibly got copied to machine 2 (via Dropbox) and then GHCi tried to respect the environment file, even though I had no interest in interacting with that particular project at the moment. Frustration and confusion ensued. 2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones. This is because, usually, I'm compiling individual Haskell files and not projects. These Haskell files are snippets of code I look at in order to spot a GHC bug and files students email me seeking help on. I therefore like to build up a healthy set of libraries in my global package database so I can just test-drive these files, without worrying about managing dependencies. (It is true that I sometimes run into old-style "cabal hell", but I also accept that this is an unavoidable consequence of using the global package database. By the time this happens, a new GHC has been released anyway, and I use the outdated package database as an excuse to upgrade.) The actual relevant scenario is this: I open GHCi to load some files from a project, and I want to experiment with them. But I realize that I want to import a few modules from packages not otherwise used in the project (e.g., the 'extra' package) in order to conduct my experiments. But I can't do this, because the env file tells me I can't. Frustration and confusion ensued. I have a better understanding of all this now -- and the knowledge to disable these features -- but this is how I came to dislike these env files. In both cases, it was because I wanted to interact with Haskell in a way that wasn't fully encapsulated within a project. Perhaps in a "real company", this wouldn't happen, but many Haskellers are not in real companies. :) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Mar 28 19:33:41 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 28 Mar 2019 20:33:41 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: (Michael Peyton Jones's message of "Thu, 28 Mar 2019 18:33:58 +0000") References: Message-ID: <87o95uiyju.fsf@gmail.com> On 2019-03-28 at 18:33:58 +0000, Michael Peyton Jones wrote: > +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used > by many other tools that handle this kind of thing. For example: ..just because everyone else does it this way doesn't mean that it's the best way.. I'd argue it might be a sign of lack of imagination ;-) In fact, personally I never liked `virtualenv` much as it required me [...] > The advantage is that the scoping of the special configuration is very > clear: it's the shell that the command launches. Programmers are very used > to this, and changes in shell environments are expected to change the > behaviour of programs. I'm a programmer. I'm very used to devel tooling I'm expected to invoke as a programmer to be affected by what's in scope as a function of the CWD, e.g. `cabal`, `git`, `make` to name a few. And to me GHCi falls into the same category, it's a tool I'm expected to interact directly with -- otherwisw it's CLI would be designed a lot different; as a matter fact it's been supported for ages to pick up a `.ghci` by walking up your fs system starting at CWD until one is found... So there's clearly precedent for the logical next step that ghc env files represent... > Plus, as functional programmers this is just the sort of idiom we use all > the time! `cabal ghc` is like writing `withProjectGhc $ \ghc -> ...`. Sure, but then again, we're talking about the unix shell which leans towards different idioms than the functional programming paradigm; and insisting to impose one paradigm on a language which isn't rooted in that paradigm is often not a good idea either... > On the negative side: I've helped ~6 people at my company alone debug > issues due to environment files. Which GHC versions was this with? [...] > *However*, I think Herbert is quite right that this particular proposal > amounts to "remove this feature". The following might be a compromise > solution: we can introduce `cabal ghc` as a parallel feature, and then in a > few releases we can assess the popularity of the two approaches, and > potentially stop generating environment files from Cabal if people aren't > using them. > > I think there are enough people that feel strongly about environment files > that we could get together the manpower to write `cabal ghc`. Sure, but this totally misses the point. We already have `cabal ghc` but the point was (as Duncan also pointed out in an earlier reply) to *not* have to require cabal as a middleman. I want to be able to invoke `ghc` and `ghci` directly, without having to invoke `cabal` everytime. If I wanted to always invoke `cabal ghci` I wouldn't have needed to invest time to help with the ghc-env feature... ;-) >> This is also a workflow which has been well documented for over a decade >> in Haskell's literature and instructions *and* this is the same idiom as >> used by many popular package managers out there ("${pkgmgr} install >> somelibrary") > > This is an interesting bit of background. FWIW, I would feel a lot better > about this feature if it wasn't a side-effect of `cabal build`. If you had > to run `cabal > save-my-local-dependencies-for-use-by-other-programs-yes-I-know-this-has-side-effects` > that wouldn't bother me (I still wouldn't use it, though). The current > situation is a bit like having `${pkgmgr} build` imply `${pkgmgr} install`, > which is a bit surprising. You can tweak your global cabal config to have `cabal` behave just like that, i.e. then you'd have to explictly opt-in either by writing write-ghc-environment-files: always into your current `cabal.project` configuration, or pass it adhoc on the CLI cabal v2-build --write-ghc-environment-files=always and as outlined earlier, the per-user env-files (which are picked up when you are *not* in any project context) are already explicitly managed (i.e. you have to explcitly invoke `cabal v2-install` to have them be created/modified) PS: There's two categories of pkg-env files (the per-HOME ones and the per-CWD ones) and I'm not sure if people are only complaining about the CWD ones or also the HOME ones... From ben at smart-cactus.org Thu Mar 28 21:46:23 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 28 Mar 2019 17:46:23 -0400 Subject: gitlab.haskell.org is down In-Reply-To: <87k1gij3n2.fsf@smart-cactus.org> References: <87k1gij3n2.fsf@smart-cactus.org> Message-ID: <87ftr6iset.fsf@smart-cactus.org> Ben Gamari writes: > Shayne Fletcher via ghc-devs writes: > >> Hi, >> >> It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage? >> > Yes, I just sent notification of this. A routine service restart ended > up going wrong. In touch with our infrastructure company's support team. > More updates coming soon. > Gitlab.haskell.org is back up. 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 hexagoxel at hexagoxel.de Thu Mar 28 23:20:44 2019 From: hexagoxel at hexagoxel.de (lennart spitzner) Date: Fri, 29 Mar 2019 00:20:44 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: <87o95uiyju.fsf@gmail.com> References: <87o95uiyju.fsf@gmail.com> Message-ID: <1dfc3e46-2b8f-b916-ab11-943d6a624047@hexagoxel.de> On 28/03/2019 13:24, Herbert Valerio Riedel wrote: > [..] We > want to be able to provide a stateful interface providing the common > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` > already provided in the past; [..] On 28/03/2019 19:33, Michael Peyton Jones wrote: > +1 to the `cabal ghc`/`cabal ghci` etc. solution. This is the approach used > by many other tools that handle this kind of thing. For example: > - nix-shell > - virtualenv > - rbenv > - sbt > - jenv On 28/03/2019 20:33, Herbert Valerio Riedel wrote: > ..just because everyone else does it this way doesn't mean that it's the > best way.. I'd argue it might be a sign of lack of imagination ;-) So we want to provide the common idiom users are used to, exactly up to the point where we don't, at which point what users are used to suddenly becomes irrelevant? Because.. imagination. Smileyface. On 28/03/2019 13:24, Herbert Valerio Riedel wrote: > However, if we now had to explicitly pass a flag to ghc in order to have > it pick up ghc env files False dichotomy. Matt's proposal was to make the feature opt-in. This can, but need not be, via a commandline flag. There are other, less obtrusive ways of allowing users to opt-in. The behaviour of the cabal maintainers is hurtful to the ecosystem, and it displays disrespect towards their own userbase. Herbert's arguments presented in this thread are logically faulty. The cabal maintainers have assumed an arrogant position of prescribing their perceived "best way" despite overwhelming proof to the contrary. +1 to Matt's proposal -- lennart From amindfv at gmail.com Fri Mar 29 03:36:31 2019 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 28 Mar 2019 23:36:31 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg escribió: > [...] > 2. I get pilloried every time I say it, but I vastly prefer global package databases to local ones. I'll second this in one specific context. v2-build has been amazing at work and in general for project-based development, but – and maybe simply because I don't know the right incantations – a step backwards for impromptu coding where I don't want to set up a whole project to start messing with an idea. I've actually fallen back to v1-install for this specific usecase: I have a set of ~15 packages, all installed from local git repos, some of which depend on others, that I *always* want when I'm in GHCi. It's basically my base. I may simply be doing it wrong but I've been unable to use the "global ghc.env file" trick successfully. Tom From allbery.b at gmail.com Fri Mar 29 03:44:14 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 Mar 2019 23:44:14 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: FWIW I've run into this one myself, and use (clones, if necessary, of) v1 sandboxes for it currently. I've also been both bitten by, and helped by, environment files. The former is somewhat nastier, especially if you have multiple versions of ghc around and a given environment file was generated by a different ghc. I also have a somewhat weird setup, because of how I ended up cobbling this machine together: the global and user package dbs for my default ghc are more or less "owned" by xmonad development, anything else is in v2, a sandbox, or otherwise a different ghc version. Including nix, also operating as a sandbox (that is, I use an alias to set up nix within specific shells, rather than unconditionally loading its config). Plus that "default ghc" is via wrappers around hvr's ghc repos for Ubuntu. Which means I have lots of different ghcs around, depending on which shell window I'm in. Not that I'm expecting anyone to directly support this mess, but environment files seem to play especially badly with multiple ghc versions with different packages installed. On Thu, Mar 28, 2019 at 11:33 PM wrote: > > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg > escribió: > > > > [...] > > > 2. I get pilloried every time I say it, but I vastly prefer global > package databases to local ones. > > I'll second this in one specific context. v2-build has been amazing at > work and in general for project-based development, but – and maybe simply > because I don't know the right incantations – a step backwards for > impromptu coding where I don't want to set up a whole project to start > messing with an idea. > > I've actually fallen back to v1-install for this specific usecase: I have > a set of ~15 packages, all installed from local git repos, some of which > depend on others, that I *always* want when I'm in GHCi. It's basically my > base. I may simply be doing it wrong but I've been unable to use the > "global ghc.env file" trick successfully. > > Tom > _______________________________________________ > 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 omeragacan at gmail.com Fri Mar 29 06:19:53 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 29 Mar 2019 09:19:53 +0300 Subject: gitlab.haskell.org is down In-Reply-To: <87ftr6iset.fsf@smart-cactus.org> References: <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org> Message-ID: I'm still getting 500. Ömer Ben Gamari , 29 Mar 2019 Cum, 00:46 tarihinde şunu yazdı: > > Ben Gamari writes: > > > Shayne Fletcher via ghc-devs writes: > > > >> Hi, > >> > >> It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage? > >> > > Yes, I just sent notification of this. A routine service restart ended > > up going wrong. In touch with our infrastructure company's support team. > > More updates coming soon. > > > Gitlab.haskell.org is back up. > > 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 Fri Mar 29 08:46:29 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 29 Mar 2019 08:46:29 +0000 Subject: gitlab.haskell.org is down In-Reply-To: References: <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org> Message-ID: Yes, I'm getting 500 too. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 29 March 2019 06:20 | To: Ben Gamari | Cc: GHC developers | Subject: Re: gitlab.haskell.org is down | | I'm still getting 500. | | Ömer From daniel.trstenjak at gmail.com Fri Mar 29 08:47:07 2019 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 29 Mar 2019 09:47:07 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: <87o95uiyju.fsf@gmail.com> References: <87o95uiyju.fsf@gmail.com> Message-ID: <20190329084707.GA6654@octa> Hi Herbert, On Thu, Mar 28, 2019 at 08:33:41PM +0100, Herbert Valerio Riedel wrote: > I'm a programmer. I'm very used to devel tooling I'm expected to invoke > as a programmer to be affected by what's in scope as a function of the CWD, > e.g. `cabal`, `git`, `make` to name a few. I think the difference here is, that tools like 'git' create and use the environment by themselves. So it's IMHO a lot easier to get an intuition about the behaviour of these tools. That's not the case for 'cabal' creating an environment and 'ghc' using it. Greetings, Daniel From oleg.grenrus at iki.fi Fri Mar 29 09:46:14 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 29 Mar 2019 11:46:14 +0200 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: To clarify: You mean different installations of same-version GHC? E.g. /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which both happen to be 8.4.4 (so some other version)? - Oleg On 29.3.2019 5.44, Brandon Allbery wrote: > FWIW I've run into this one myself, and use (clones, if necessary, of) > v1 sandboxes for it currently. > > I've also been both bitten by, and helped by, environment files. The > former is somewhat nastier, especially if you have multiple versions > of ghc around and a given environment file was generated by a > different ghc. > > I also have a somewhat weird setup, because of how I ended up cobbling > this machine together: the global and user package dbs for my default > ghc are more or less "owned" by xmonad development, anything else is > in v2, a sandbox, or otherwise a different ghc version. Including nix, > also operating as a sandbox (that is, I use an alias to set up nix > within specific shells, rather than unconditionally loading its > config). Plus that "default ghc" is via wrappers around hvr's ghc > repos for Ubuntu. Which means I have lots of different ghcs around, > depending on which shell window I'm in. Not that I'm expecting anyone > to directly support this mess, but environment files seem to play > especially badly with multiple ghc versions with different packages > installed. > > On Thu, Mar 28, 2019 at 11:33 PM > wrote: > > > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg > escribió: > > > > [...] > > > 2. I get pilloried every time I say it, but I vastly prefer > global package databases to local ones. > > I'll second this in one specific context. v2-build has been > amazing at work and in general for project-based development, but > – and maybe simply because I don't know the right incantations – a > step backwards for impromptu coding where I don't want to set up a > whole project to start messing with an idea. > > I've actually fallen back to v1-install for this specific usecase: > I have a set of ~15 packages, all installed from local git repos, > some of which depend on others, that I *always* want when I'm in > GHCi. It's basically my base. I may simply be doing it wrong but > I've been unable to use the "global ghc.env file" trick successfully. > > Tom > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From alp at well-typed.com Fri Mar 29 12:32:22 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Fri, 29 Mar 2019 13:32:22 +0100 Subject: gitlab.haskell.org is down In-Reply-To: References: <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org> Message-ID: <41fe60d5-7c7d-82b4-c3e5-e0bc588eb902@well-typed.com> GitLab should be back now, seems to be working fine for me (both using the web UI and fetching from ghc/ghc.git). On 29/03/2019 09:46, Simon Peyton Jones via ghc-devs wrote: > Yes, I'm getting 500 too. > > Simon > > | -----Original Message----- > | From: ghc-devs On Behalf Of Ömer Sinan > | Agacan > | Sent: 29 March 2019 06:20 > | To: Ben Gamari > | Cc: GHC developers > | Subject: Re: gitlab.haskell.org is down > | > | I'm still getting 500. > | > | Ömer > _______________________________________________ > 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 From iavor.diatchki at gmail.com Fri Mar 29 16:42:35 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 29 Mar 2019 09:42:35 -0700 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: Hi Richard, For use case 1) we should probably make GHCi be more robust, and make it notice that an environment file has become unusable, say so, and ignore it, rather than refusing to work. It is a bit of an odd way to synchronize build artifacts though. For 2), I like global databases too, and I think that this system is very compatible with it---you can think of the "global" environment as a default project that GHCi uses when there is no other project around. I believe something like that is already being developed. In the mean-time, however, I've just been using one "sand-box" cabal project that has just a cabal file, and no source files---when I want to try stuff out, I just go to that project and fire up `ghci`. It avoids cabal hell as you can easily control the versions of the libraries you need, if you care. It is also cool, in that you can put it on github, and be able to easily recreate the same environment on different machines. And having used that for a while, I've noticed that perhaps I don't really want a global project, as I've evolved a couple of different "sand-boxes" for different topics that I commonly play around with. As for your relevant scenario: couldn't you just add the packages you want to use to your cabal file and ask it to build them for you? Then you'd know what version of the package you are actually experimenting with. I haven't actually run into this issue much, so I can't recall what GHCi says if you try to use a module from a package that is not part of the current context, but it sounds like we may want to improve its message, if the current situation is confusing. On Thu, Mar 28, 2019 at 12:26 PM Richard Eisenberg wrote: > > > On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel > wrote: > > That being said, I'd be more interested to know the actual problems > people are having > > > I've run into two problems. I don't expect others to run into these > particular problems, as my workflows are likely different than others', but > both of these bit me independently. > > 1. I use two different machines regularly. I keep my files in sync between > them using Dropbox. Yet, the Haskell installations between are not > identical. Even if the GHC version is the same, it's quite likely that some > library, etc., has been installed at a different version on the two > machines. (Sometimes, even the GHC is different.) I did some work on a > project on machine 1; this produced an environment file. Then, machine 2's > window happened to be in the project directory. I wanted to spin up GHCi to > check the type of, e.g., traverse. But GHCi wouldn't launch! This is > because machine 1's work produced the environment file which invisibly got > copied to machine 2 (via Dropbox) and then GHCi tried to respect the > environment file, even though I had no interest in interacting with that > particular project at the moment. Frustration and confusion ensued. > > 2. I get pilloried every time I say it, but I vastly prefer global package > databases to local ones. This is because, usually, I'm compiling individual > Haskell files and not projects. These Haskell files are snippets of code I > look at in order to spot a GHC bug and files students email me seeking help > on. I therefore like to build up a healthy set of libraries in my global > package database so I can just test-drive these files, without worrying > about managing dependencies. (It is true that I sometimes run into > old-style "cabal hell", but I also accept that this is an unavoidable > consequence of using the global package database. By the time this happens, > a new GHC has been released anyway, and I use the outdated package database > as an excuse to upgrade.) > > The actual relevant scenario is this: I open GHCi to load some files > from a project, and I want to experiment with them. But I realize that I > want to import a few modules from packages not otherwise used in the > project (e.g., the 'extra' package) in order to conduct my experiments. But > I can't do this, because the env file tells me I can't. Frustration and > confusion ensued. > > I have a better understanding of all this now -- and the knowledge to > disable these features -- but this is how I came to dislike these env > files. In both cases, it was because I wanted to interact with Haskell in a > way that wasn't fully encapsulated within a project. Perhaps in a "real > company", this wouldn't happen, but many Haskellers are not in real > companies. :) > > Richard > _______________________________________________ > 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 Fri Mar 29 16:52:32 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 29 Mar 2019 12:52:32 -0400 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: Nix instead of system, but roughly yes. On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus wrote: > To clarify: You mean different installations of same-version GHC? E.g. > /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which > both happen to be 8.4.4 (so some other version)? > > - Oleg > > On 29.3.2019 5.44, Brandon Allbery wrote: > > FWIW I've run into this one myself, and use (clones, if necessary, of) > > v1 sandboxes for it currently. > > > > I've also been both bitten by, and helped by, environment files. The > > former is somewhat nastier, especially if you have multiple versions > > of ghc around and a given environment file was generated by a > > different ghc. > > > > I also have a somewhat weird setup, because of how I ended up cobbling > > this machine together: the global and user package dbs for my default > > ghc are more or less "owned" by xmonad development, anything else is > > in v2, a sandbox, or otherwise a different ghc version. Including nix, > > also operating as a sandbox (that is, I use an alias to set up nix > > within specific shells, rather than unconditionally loading its > > config). Plus that "default ghc" is via wrappers around hvr's ghc > > repos for Ubuntu. Which means I have lots of different ghcs around, > > depending on which shell window I'm in. Not that I'm expecting anyone > > to directly support this mess, but environment files seem to play > > especially badly with multiple ghc versions with different packages > > installed. > > > > On Thu, Mar 28, 2019 at 11:33 PM > > wrote: > > > > > > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg > > escribió: > > > > > > > [...] > > > > > 2. I get pilloried every time I say it, but I vastly prefer > > global package databases to local ones. > > > > I'll second this in one specific context. v2-build has been > > amazing at work and in general for project-based development, but > > – and maybe simply because I don't know the right incantations – a > > step backwards for impromptu coding where I don't want to set up a > > whole project to start messing with an idea. > > > > I've actually fallen back to v1-install for this specific usecase: > > I have a set of ~15 packages, all installed from local git repos, > > some of which depend on others, that I *always* want when I'm in > > GHCi. It's basically my base. I may simply be doing it wrong but > > I've been unable to use the "global ghc.env file" trick successfully. > > > > Tom > > _______________________________________________ > > 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 > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Mar 29 17:59:40 2019 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Mar 2019 13:59:40 -0400 Subject: GHC label conventions Message-ID: <87d0m9imt4.fsf@smart-cactus.org> Hello everyone, I have documented our current conventions regarding GitLab label usage on the Wiki [1]. Please do keep this up-to-date if you create, remove, or rename a label. As always, feedback is welcome Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/GitLab-Labels/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From chrisdone at gmail.com Sat Mar 30 14:05:15 2019 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 30 Mar 2019 14:05:15 +0000 Subject: Newtypes in STG Message-ID: Hi all, Could you offer some insight into newtypes at the STG level? Here’s the context: 1. I’m working on this interpreter for STG (https://github.com/chrisdone/prana) and I’m trying to generate a pristine AST where all names in it are resolved to something known to me. 2. I’ve compiled ghc-prim and integer-gmp without issue, and I’m compiling base and there remains one last frontier which is newtypes. These are the culprits pointed out if I compile base: chris at precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch Preprocessing library for base-4.11.1.0.. Building library for base-4.11.1.0.. [1 of 244] Compiling GHC.Base [2 of 244] Compiling GHC.IO [3 of 244] Compiling GHC.Real [4 of 244] Compiling Data.Semigroup.Internal ... [snip] ... [242 of 244] Compiling Data.Functor.Compose [243 of 244] Compiling Data.Fixed [244 of 244] Compiling Data.Complex Errors in Data.Foldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in Foreign.Marshal.Pool: Variable name not found: base:Foreign.Marshal.Pool.Pool Errors in GHC.ExecutionStack.Internal: Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace Errors in Data.Bifoldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in System.Timeout: Variable name not found: base:System.Timeout.Timeout Errors in Data.Data: Variable name not found: base:Foreign.Ptr.WordPtr Variable name not found: base:Foreign.Ptr.IntPtr Variable name not found: base:Data.Semigroup.Internal.Any Variable name not found: base:Data.Semigroup.Internal.All I looked these up, and they all appear to be *uses* of a newtype. For example, in the Timeout function: http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.html#timeout I printed out the full [StgTopBinding] list and got: let { sat_s27NC [Occ=Once] :: IO Timeout [LclId] = [] \u [] fmap $fFunctorIO Timeout newUnique; } in >>= $fMonadIO sat_s27NC sat_s27NT; Oddly (or not?), they’re used as values, not constructors. This error comes from this part of my code: StgSyn.StgApp occ arguments -> AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments If it was used as a constructor, it’d appear in this position, where looking up the ID would produce a “Data constructor name not found” error: StgSyn.StgConApp dataCon arguments types -> ConAppExpr <$> lookupDataConId dataCon <*> traverse fromStgGenArg arguments <*> pure (map (const Type) types) My understanding of newtypes at this stage is hazy. It seems like: - They ought to be erased and replaced with coercions by now. If they’re not replaced, it’s because they’re in a not-quite-id position like fmap Timeout .... (Arguably these could be fixed in base with a Data.Coerce.coerce?) - However, the CoreTidy/PrepPgm processing modules don’t seem to have removed or replaced these, or introduced a binding that would do something. At this stage what would you recommend? At this point type-checking is done, and I only care about interpreting the code. So I suppose they could be id for all it matters to the interpreter? I imagine they aren’t actually supposed to allocate something here. And I’m certain that any pattern matching on a newtype is also erased away by this point. Cheers! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Sat Mar 30 14:07:26 2019 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 30 Mar 2019 14:07:26 +0000 Subject: Newtypes in STG In-Reply-To: References: Message-ID: Oh, also my complete pipeline is here: https://github.com/chrisdone/prana/blob/0cbb7b4b96bbfdb4f0d6a60e08f4b1f53abdfb15/prana-ghc/src/Prana/Ghc.hs#L106-L154 Parse/typecheck/desugar, tidy, prep, core-to-stg (ripped from HscMain) and then I try to resolve all names in the AST and that leads me to this. On Sat, 30 Mar 2019 at 14:05, Christopher Done wrote: > Hi all, > > Could you offer some insight into newtypes at the STG level? Here’s the > context: > > 1. > > I’m working on this interpreter for STG > (https://github.com/chrisdone/prana) and I’m trying to generate a > pristine AST where all names in it are resolved to something known to > me. > 2. > > I’ve compiled ghc-prim and integer-gmp without issue, and I’m > compiling base and there remains one last frontier which is newtypes. > > These are the culprits pointed out if I compile base: > > chris at precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch > Preprocessing library for base-4.11.1.0.. > Building library for base-4.11.1.0.. > [1 of 244] Compiling GHC.Base > [2 of 244] Compiling GHC.IO > [3 of 244] Compiling GHC.Real > [4 of 244] Compiling Data.Semigroup.Internal > ... [snip] ... > [242 of 244] Compiling Data.Functor.Compose > [243 of 244] Compiling Data.Fixed > [244 of 244] Compiling Data.Complex > > Errors in Data.Foldable: > Variable name not found: base:Data.Semigroup.Internal.All > Variable name not found: base:Data.Semigroup.Internal.Any > > Errors in Foreign.Marshal.Pool: > Variable name not found: base:Foreign.Marshal.Pool.Pool > > Errors in GHC.ExecutionStack.Internal: > Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace > > Errors in Data.Bifoldable: > Variable name not found: base:Data.Semigroup.Internal.All > Variable name not found: base:Data.Semigroup.Internal.Any > > Errors in System.Timeout: > Variable name not found: base:System.Timeout.Timeout > > Errors in Data.Data: > Variable name not found: base:Foreign.Ptr.WordPtr > Variable name not found: base:Foreign.Ptr.IntPtr > Variable name not found: base:Data.Semigroup.Internal.Any > Variable name not found: base:Data.Semigroup.Internal.All > > I looked these up, and they all appear to be *uses* of a > newtype. > > For example, in the Timeout function: > > > http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.html#timeout > > I printed out the full [StgTopBinding] list and got: > > let { > sat_s27NC [Occ=Once] :: IO Timeout > [LclId] = > [] \u [] fmap $fFunctorIO Timeout newUnique; > } in >>= $fMonadIO sat_s27NC sat_s27NT; > > Oddly (or not?), they’re used as values, not constructors. This error > comes from this part of my code: > > StgSyn.StgApp occ arguments -> > AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments > > If it was used as a constructor, it’d appear in this position, where > looking up the ID would produce a “Data constructor name not found” > error: > > StgSyn.StgConApp dataCon arguments types -> > ConAppExpr <$> lookupDataConId dataCon <*> traverse fromStgGenArg > arguments <*> > pure (map (const Type) types) > > My understanding of newtypes at this stage is hazy. It seems like: > > - > > They ought to be erased and replaced with coercions by now. If > they’re not replaced, it’s because they’re in a not-quite-id position > like fmap Timeout .... (Arguably these could be fixed in base with a > Data.Coerce.coerce?) > - > > However, the CoreTidy/PrepPgm processing modules > don’t seem to have removed or replaced these, or introduced a binding > that would do something. > > At this stage what would you recommend? At this point type-checking is > done, and I only care about interpreting the code. So I suppose they > could be id for all it matters to the interpreter? > > I imagine they aren’t actually supposed to allocate something here. And > I’m certain that any pattern matching on a newtype is also erased away > by this point. > > Cheers! > > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Mar 31 00:56:07 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 30 Mar 2019 20:56:07 -0400 Subject: GHC HEAD documentation once again available Message-ID: <87zhpbhnfh.fsf@smart-cactus.org> 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lonetiger at gmail.com Sun Mar 31 03:52:36 2019 From: lonetiger at gmail.com (Phyx) Date: Sun, 31 Mar 2019 04:52:36 +0100 Subject: GitHub Mirror is broken In-Reply-To: <87sgwkwart.fsf@smart-cactus.org> References: <87sgwkwart.fsf@smart-cactus.org> Message-ID: Hi Ben, I think the mirror is stuck again. Hasn't updated in 8 days. Cheers, Tamar On Tue, Feb 19, 2019 at 6:30 AM Ben Gamari wrote: > Artem Pelenitsyn writes: > > > Hello devs, > > > > This is just to let you know that the latestes commit on GitHub ghc/ghc > > repo dates back to 22th of January. Personally, I find GitHub mirror > quite > > useful for ocasional searches over the code base. Therefore, I'd > > appreciated repairing the mirror. > > > Fixed. It seems like the mirroring service got stuck. > > Cheers, > > - Ben > _______________________________________________ > 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 vladislav at serokell.io Sun Mar 31 05:08:16 2019 From: vladislav at serokell.io (Vladislav Zavialov) Date: Sun, 31 Mar 2019 08:08:16 +0300 Subject: GHC HEAD documentation once again available In-Reply-To: <87zhpbhnfh.fsf@smart-cactus.org> References: <87zhpbhnfh.fsf@smart-cactus.org> Message-ID: <9C045F20-725C-45FE-847E-06A87B0124A6@serokell.io> Hi Ben, The generated Libraries page contains the following line: For documentation on the GHC API, see ghc-8.9.20190330/index.html The link is dead and should be ghc-8.9/index.html instead. All the best, - Vlad > On 31 Mar 2019, at 03:56, 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 takenobu.hs at gmail.com Sun Mar 31 09:30:36 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 31 Mar 2019 18:30:36 +0900 Subject: GHC HEAD documentation once again available In-Reply-To: <87zhpbhnfh.fsf@smart-cactus.org> References: <87zhpbhnfh.fsf@smart-cactus.org> Message-ID: Thank you for the useful link. It may not be related to this, but the following URL is not displayed correctly. NG URL: - https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html -> redirect to https://ghc.gitlab.haskell.org/ghc/doc/ OK URL: - https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html - https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?highlight=inline#inline-and-noinline-pragmas Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sun Mar 31 12:44:22 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 31 Mar 2019 15:44:22 +0300 Subject: Can't build HEAD with the old build system Message-ID: I just updated a few-days-old repo and `make` no longer works: $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/ghc-heap/ghc.mk:3: libraries/ghc-heap/dist-boot/build/.depend-v.haskell: No such file or directory libraries/ghci/ghc.mk:3: libraries/ghci/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:437: compiler/stage1/build/.depend-v.haskell: No such file or directory "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -outputdir utils/hsc2hs/dist/build -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o /usr/bin/ld.gold: internal error in find_view, at ../../gold/fileread.cc:336 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/hsc2hs/ghc.mk:21: recipe for target 'utils/hsc2hs/dist/build/tmp/hsc2hs' failed make[1]: *** [utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 I tried a custom build.mk and with no build.mk, got the same error either way. I also tried to build with hadrian and it worked. Is anyone here able to build with the old build system? If this is about my system, any ideas what might be the problem? Ömer From chak at justtesting.org Sun Mar 31 13:10:01 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sun, 31 Mar 2019 15:10:01 +0200 Subject: GitHub Mirror is broken In-Reply-To: References: <87sgwkwart.fsf@smart-cactus.org> Message-ID: <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org> I think, it also only mirrors master, but not other branches, which is unfortunate especially for release branches. Manuel > Am 31.03.2019 um 05:52 schrieb Phyx : > > Hi Ben, > > I think the mirror is stuck again. Hasn't updated in 8 days. > > Cheers, > Tamar > > On Tue, Feb 19, 2019 at 6:30 AM Ben Gamari > wrote: > Artem Pelenitsyn > writes: > > > Hello devs, > > > > This is just to let you know that the latestes commit on GitHub ghc/ghc > > repo dates back to 22th of January. Personally, I find GitHub mirror quite > > useful for ocasional searches over the code base. Therefore, I'd > > appreciated repairing the mirror. > > > Fixed. It seems like the mirroring service got stuck. > > Cheers, > > - Ben > _______________________________________________ > 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 Sun Mar 31 13:19:42 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 31 Mar 2019 22:19:42 +0900 Subject: Can't build HEAD with the old build system In-Reply-To: References: Message-ID: Hi, At least I was able to build with old build system in my Ubuntu on Friday. How about trying the following? : $ make maintainer-clean $ ./boot $ ./configure $ make Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Mar 31 15:09:01 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 31 Mar 2019 11:09:01 -0400 Subject: GitHub Mirror is broken In-Reply-To: <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org> References: <87sgwkwart.fsf@smart-cactus.org> <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org> Message-ID: <87wokfgjxz.fsf@smart-cactus.org> Manuel M T Chakravarty writes: > I think, it also only mirrors master, but not other branches, which is unfortunate especially for release branches. > Fixed on both counts. The GitHub mirror should be both up-to-date and include all branches. 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 omeragacan at gmail.com Sun Mar 31 16:20:22 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 31 Mar 2019 19:20:22 +0300 Subject: Can't build HEAD with the old build system In-Reply-To: References: Message-ID: I was able to build with the system linker instead of gold.ld (configure with --disable-ld-override). I guess I triggered a gold.ld bug. Ömer Takenobu Tani , 31 Mar 2019 Paz, 16:19 tarihinde şunu yazdı: > > Hi, > > At least I was able to build with old build system in my Ubuntu on Friday. > > How about trying the following? : > > $ make maintainer-clean > $ ./boot > $ ./configure > $ make > > Regards, > Takenobu > From chak at justtesting.org Sun Mar 31 16:27:05 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sun, 31 Mar 2019 18:27:05 +0200 Subject: GitHub Mirror is broken In-Reply-To: <87wokfgjxz.fsf@smart-cactus.org> References: <87sgwkwart.fsf@smart-cactus.org> <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org> <87wokfgjxz.fsf@smart-cactus.org> Message-ID: Thanks! Manuel > Am 31.03.2019 um 17:09 schrieb Ben Gamari : > > Manuel M T Chakravarty writes: > >> I think, it also only mirrors master, but not other branches, which is unfortunate especially for release branches. >> > Fixed on both counts. The GitHub mirror should be both up-to-date and > include all branches. > > Cheers, > > - Ben > > _______________________________________________ > 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 Sun Mar 31 16:41:28 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 31 Mar 2019 12:41:28 -0400 Subject: Can't build HEAD with the old build system In-Reply-To: References: Message-ID: <05957AA0-7548-40FA-AB9C-DBE39ADCD04D@smart-cactus.org> On March 31, 2019 12:20:22 PM EDT, "Ömer Sinan Ağacan" wrote: >I was able to build with the system linker instead of gold.ld >(configure with >--disable-ld-override). I guess I triggered a gold.ld bug. > >Ömer > >Takenobu Tani , 31 Mar 2019 Paz, 16:19 >tarihinde şunu yazdı: >> >> Hi, >> >> At least I was able to build with old build system in my Ubuntu on >Friday. >> >> How about trying the following? : >> >> $ make maintainer-clean >> $ ./boot >> $ ./configure >> $ make >> >> Regards, >> Takenobu >> >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs Which binutils version are you using? From ben at well-typed.com Sun Mar 31 17:55:45 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 31 Mar 2019 13:55:45 -0400 Subject: GHC HEAD documentation once again available In-Reply-To: References: <87zhpbhnfh.fsf@smart-cactus.org> Message-ID: <87tvfjgc84.fsf@smart-cactus.org> Takenobu Tani writes: > Thank you for the useful link. > > It may not be related to this, but the following URL is not displayed > correctly. > Thanks for pointing this out. This was due to a configuration mistake which I had fixed, but apparently the CDN hadn't caught up. I have purged the affected URL from the CDN so things should be fine now. Unfortunately there is no easy way to do a more comprehensive purge so if there are any other affected URLs we will simply need to purge them as we find them. 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 mail at nh2.me Sun Mar 31 20:11:26 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sun, 31 Mar 2019 22:11:26 +0200 Subject: Can't build HEAD with the old build system In-Reply-To: References: Message-ID: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> Can you reproduce this reliably? Googling the error message "internal error in find_view" yields: https://www.mail-archive.com/bug-binutils at gnu.org/msg28716.html where somebody encountered it, but only in proprietary code. It would probably be very useful if we could provide a repro of it in an open-source code base like GHC. By the way, the attachment there is called "Corrupt elf file which causes linker to crash", so perhaps you also have a corrupt ELF file somewhere? Niklas From mail at joachim-breitner.de Sun Mar 31 20:43:32 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 31 Mar 2019 22:43:32 +0200 Subject: GHC HEAD documentation once again available In-Reply-To: <87zhpbhnfh.fsf@smart-cactus.org> References: <87zhpbhnfh.fsf@smart-cactus.org> Message-ID: Hi, great work! (Not only this, of course. I just felt it was time to express praise.) Cheers, Joachim Am Samstag, den 30.03.2019, 20:56 -0400 schrieb Ben Gamari: > 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 -- 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: