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: <A3629F88-317D-4F21-9262-42AB3FAEE8E3@leviston.net>

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 <tdammers at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190302/2294e647/attachment.html>

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 <rae at cs.brynmawr.edu> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190301/2d932b79/attachment.sig>

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: <CAH6fHQme5mK906sQ5_qFXxnfTOuZDAQ1D7JibngxYx=yVPSMxQ@mail.gmail.com>
References: <20190227100657.b3qodmep4ymvrade@nibbler>
 <CAH6fHQme5mK906sQ5_qFXxnfTOuZDAQ1D7JibngxYx=yVPSMxQ@mail.gmail.com>
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 <Alp's nix derivation>, otherwise you need
> <all this> installed [in particular, no sectioning of the dependencies!],
> see <the relevant place> 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: <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <ghc-tickets-bounces at haskell.org> 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&amp;data=02%7C01%7Csimonpj%40m
| icrosoft.com%7C50e6bec9985e4121351808d6a0d2a90f%7C72f988bf86f141af91ab2d7cd
| 011db47%7C1%7C0%7C636873224010230414&amp;sdata=SvX8wLsObYmasJTvB6yT9CQbxoFK
| ZkdGpv7ZHfDRqYs%3D&amp;reserved=0
| -------------------------------------+-------------------------------------
| 
| Comment (by Matthew Pickering <matthewtpickering@…>):
| 
|  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:
| <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske
| ll.org%2Ftrac%2Fghc%2Fticket%2F16348%23comment%3A7&amp;data=02%7C01%7Csimon
| pj%40microsoft.com%7C50e6bec9985e4121351808d6a0d2a90f%7C72f988bf86f141af91a
| b2d7cd011db47%7C1%7C0%7C636873224010230414&amp;sdata=Hmm1p52EqBpdLX1sFkutPm
| Z8hSjY%2FtzS1FZqlFYCxYI%3D&amp;reserved=0>
| GHC
| <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haske
| ll.org%2Fghc%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C50e6bec9985e41
| 21351808d6a0d2a90f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687322401
| 0230414&amp;sdata=AuTz%2BM22brpeoXARiWrhvqlGd4w2myu1YNobnhj16L8%3D&amp;rese
| rved=0>
| 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: <A3629F88-317D-4F21-9262-42AB3FAEE8E3@leviston.net>
References: <20190227100657.b3qodmep4ymvrade@nibbler>
 <A3629F88-317D-4F21-9262-42AB3FAEE8E3@leviston.net>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/695c9b8f/attachment.sig>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/0b05a926/attachment.sig>

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: <CADdQpRCd8UFbw8uHbfpr7tHvDKnY+Onuu4N6CXc+n4pwzaniZA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/ea129844/attachment.html>

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: <CADdQpRCd8UFbw8uHbfpr7tHvDKnY+Onuu4N6CXc+n4pwzaniZA@mail.gmail.com>
References: <CADdQpRCd8UFbw8uHbfpr7tHvDKnY+Onuu4N6CXc+n4pwzaniZA@mail.gmail.com>
Message-ID: <87lg1truss.fsf@smart-cactus.org>

Ryan Scott <ryan.gl.scott at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/9e559a5c/attachment.sig>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/bb142ea0/attachment.sig>

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 <ben at well-typed.com> 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: <CABHktDW4QJWUsgXufejQo1fXfJ9Q+snHOV4oFWDESM6WXCqtSg@mail.gmail.com>

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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/3d1e92e4/attachment.html>

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: <CABHktDW4QJWUsgXufejQo1fXfJ9Q+snHOV4oFWDESM6WXCqtSg@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CABHktDW4QJWUsgXufejQo1fXfJ9Q+snHOV4oFWDESM6WXCqtSg@mail.gmail.com>
Message-ID: <877eddro34.fsf@smart-cactus.org>

Phyx <lonetiger at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/18034434/attachment.sig>

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 <rae at cs.brynmawr.edu> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/270086e7/attachment.sig>

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>
 <CABHktDW4QJWUsgXufejQo1fXfJ9Q+snHOV4oFWDESM6WXCqtSg@mail.gmail.com>
 <877eddro34.fsf@smart-cactus.org>
Message-ID: <CABHktDU+q9yMRNSaP9sqs=8gFr8LgknK9T1Z88H2v9zNAphR2A@mail.gmail.com>

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 <ben at well-typed.com> wrote:

> Phyx <lonetiger at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/bc1615e5/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/abd778b3/attachment.sig>

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: <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org>
 <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org>
 <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <87va0wr6xd.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/ca3f8007/attachment.sig>

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: <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>

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 <ben at well-typed.com>, 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>
 <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <87va0wr6xd.fsf@smart-cactus.org>
Message-ID: <CAH9BU=zVWOPaac7Qn4O+28m-MweymP1B9Rj9Pq9nESu_cj7X-w@mail.gmail.com>

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, <ben at well-typed.com> wrote:

> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/c5e765b2/attachment.html>

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: <CABHktDU+q9yMRNSaP9sqs=8gFr8LgknK9T1Z88H2v9zNAphR2A@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CABHktDW4QJWUsgXufejQo1fXfJ9Q+snHOV4oFWDESM6WXCqtSg@mail.gmail.com>
 <877eddro34.fsf@smart-cactus.org>
 <CABHktDU+q9yMRNSaP9sqs=8gFr8LgknK9T1Z88H2v9zNAphR2A@mail.gmail.com>
Message-ID: <CANma=H8A-auy61QCN0AeZ3k5rTCHyymTWPL+hD45CQdG7xnpNQ@mail.gmail.com>

I'm impressed, 'stack setup 8.6.4` brings it down already.

Alan

On Tue, 5 Mar 2019 at 23:58, Phyx <lonetiger at gmail.com> 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 <ben at well-typed.com> wrote:
>
>> Phyx <lonetiger at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/a32148e3/attachment.html>

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>
 <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <87va0wr6xd.fsf@smart-cactus.org>
Message-ID: <DB7PR83MB0298841A30479D521D6E8911AD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>

|   * 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 <ben at well-typed.com>
|  Sent: 06 March 2019 03:58
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Matthew Pickering
|  <matthewtpickering at gmail.com>
|  Cc: ghc-devs at haskell.org
|  Subject: RE: [GHC] #16348: GHC HEAD regression: tyConAppArgs
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <DB7PR83MB02987805A3488BAA114EE8ACAD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/d5a6a75b/attachment.html>

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: <DB7PR83MB02987805A3488BAA114EE8ACAD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB02987805A3488BAA114EE8ACAD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAMQQO3kYp6pSUr24QPeJ1SiW9GQt1wQNHDcxjKzCCnwqhd-1xg@mail.gmail.com>

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 <ghc-devs at haskell.org>, 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: <CAMQQO3kYp6pSUr24QPeJ1SiW9GQt1wQNHDcxjKzCCnwqhd-1xg@mail.gmail.com>
References: <DB7PR83MB02987805A3488BAA114EE8ACAD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAMQQO3kYp6pSUr24QPeJ1SiW9GQt1wQNHDcxjKzCCnwqhd-1xg@mail.gmail.com>
Message-ID: <DB7PR83MB0298DCD90CABA32C795F75EAAD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <omeragacan at gmail.com>
|  Sent: 06 March 2019 10:05
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  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 <ghc-devs at haskell.org>, 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&amp;data=02%7C01
|  > %7Csimonpj%40microsoft.com%7Cc8487e1fe20546d89ada08d6a21b4bd8%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636874635457691388&amp;sdata=q%2F
|  > Fex6QsoPl9IkBydNUGcWLbf2dlrgbzltMAkTHtA5g%3D&amp;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: <CAH9BU=zVWOPaac7Qn4O+28m-MweymP1B9Rj9Pq9nESu_cj7X-w@mail.gmail.com>
References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org>
 <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org>
 <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <87va0wr6xd.fsf@smart-cactus.org>
 <CAH9BU=zVWOPaac7Qn4O+28m-MweymP1B9Rj9Pq9nESu_cj7X-w@mail.gmail.com>
Message-ID: <2FD63404-E902-48C3-AF3D-0BC692EE151B@well-typed.com>



On March 6, 2019 2:06:25 AM EST, Bryan Richter <b at chreekat.net> 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, <ben at well-typed.com> wrote:
>
>> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
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: <DB7PR83MB0298841A30479D521D6E8911AD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org>
 <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@haskell.org>
 <DB7PR83MB0298709DAD6604F9210D86A9AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <87va0wr6xd.fsf@smart-cactus.org>
 <DB7PR83MB0298841A30479D521D6E8911AD730@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <FC01E1A7-62F3-4659-99CA-5C61A4AE42EC@well-typed.com>



On March 6, 2019 4:23:37 AM EST, Simon Peyton Jones <simonpj at microsoft.com> 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: <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
Message-ID: <FD0756EA-AABF-4D15-991F-10BD371F3DCB@well-typed.com>



On March 6, 2019 1:32:44 AM EST, "Ömer Sinan Ağacan" <omeragacan at gmail.com> 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>
 <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
 <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 <tdammers at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/1bf6cf62/attachment.html>

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: <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>

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 <ben at well-typed.com> 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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/2ee1a618/attachment.html>

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: <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
Message-ID: <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>



On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
Message-ID: <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>

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 <ben at well-typed.com> wrote:
> 
> 
> 
>> On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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: <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
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 <ben at well-typed.com> wrote:
>>
>>
>>
>>> On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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>
 <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
 <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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
Message-ID: <87sgw0qk8b.fsf@smart-cactus.org>

Ryan Scott <ryan.gl.scott at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/0d3c9def/attachment.sig>

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: <CAPB_Nvw9F4G7aF7X0ouS0tiANDKbLOEGnbxdLjUmqThX=ALS1w@mail.gmail.com>

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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/ef14da24/attachment.html>

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: <CAPB_Nvw9F4G7aF7X0ouS0tiANDKbLOEGnbxdLjUmqThX=ALS1w@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAPB_Nvw9F4G7aF7X0ouS0tiANDKbLOEGnbxdLjUmqThX=ALS1w@mail.gmail.com>
Message-ID: <87pnr4qjjl.fsf@smart-cactus.org>

Takenobu Tani <takenobu.hs at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/0306f268/attachment.sig>

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>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
 <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr>
Message-ID: <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>

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 <sylvain at haskus.fr> 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 <ben at well-typed.com> wrote:
> >>
> >>
> >>
> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/b19e25c8/attachment-0001.html>

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: <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
 <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr>
 <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
Message-ID: <CACPahm1aDj7AZ-ZWwTXJrKvbzLaP6gaSJxCo2zhKTKQ_stcZ+A@mail.gmail.com>

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 <matthewtpickering at gmail.com>
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 <sylvain at haskus.fr> 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 <ben at well-typed.com> wrote:
>> >>
>> >>
>> >>
>> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/c1a60be2/attachment.html>

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>
 <CAMQQO3nwjQUjK81uGH+Q5q7i=btrpiavddM31doNZZnEh8XoqQ@mail.gmail.com>
 <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>
 <CAPB_Nvw9F4G7aF7X0ouS0tiANDKbLOEGnbxdLjUmqThX=ALS1w@mail.gmail.com>
 <87pnr4qjjl.fsf@smart-cactus.org>
Message-ID: <CAPB_Nvxnp+Mc3KV11hY7wb3p5HqP=5y9199cN3CBWz=N2cCJ9A@mail.gmail.com>

> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/989850aa/attachment.html>

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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
Message-ID: <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>

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 <ryan.gl.scott at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/23e1dff8/attachment.html>

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: <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
Message-ID: <87lg1sqcaa.fsf@smart-cactus.org>

Sylvain Henry <sylvain at haskus.fr> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/77e0c3df/attachment.sig>

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: <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>

Hi Ben,

On Tue, Mar 5, 2019 at 3:53 PM Ben Gamari <ben at well-typed.com> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/6923e0e4/attachment.html>

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: <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
Message-ID: <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>

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 <ben at well-typed.com> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/e6d3bd61/attachment.html>

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: <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
 <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
Message-ID: <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>

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 <ben at well-typed.com> 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 <emnet at digitalasset.com> 
Digital Asset Holdings, LLC
4 World Trade Center                                                        150
Greenwich Street, 47th Floor
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/ca29498c/attachment.html>

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: <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
 <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
 <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>
Message-ID: <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>

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 <ben at well-typed.com> 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 <emnet at digitalasset.com> 
Digital Asset Holdings, LLC
4 World Trade Center                                                        150
Greenwich Street, 47th Floor
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/9829cf83/attachment.html>

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: <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
 <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
 <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>
 <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>
Message-ID: <CALuQ0m9A73tRGZr7e8dn+_gffPg2JxTg1BwmkhVrsOBpj2Fb5w@mail.gmail.com>

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 <ben at well-typed.com> 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 <emnet at digitalasset.com> 
> Digital Asset Holdings, LLC
> 4 World Trade Center
>   150 Greenwich Street, 47th Floor
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/6cf582a0/attachment.html>

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: <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>
References: <87h8chrqkl.fsf@smart-cactus.org>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
 <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
 <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>
 <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>
Message-ID: <87imwwq7nx.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/dbc20638/attachment.sig>

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: <CACPahm1aDj7AZ-ZWwTXJrKvbzLaP6gaSJxCo2zhKTKQ_stcZ+A@mail.gmail.com>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
 <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr>
 <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
 <CACPahm1aDj7AZ-ZWwTXJrKvbzLaP6gaSJxCo2zhKTKQ_stcZ+A@mail.gmail.com>
Message-ID: <87fts0q7fz.fsf@smart-cactus.org>

Ara Adkins <me at ara.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/1a441360/attachment.sig>

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>
 <CAKe9RREsY3aqt1gcam-Pmm7-w73driJz3ogHNu8C62EZZYRpKQ@mail.gmail.com>
 <CAKe9RRE9oEgFhxJDMEu7Pbq8647vtb_g1zDvFihWb=pdTLfoYQ@mail.gmail.com>
 <CAKe9RRHiHnY=+=D5tNZ2G+P9xkrbZXPdKUkCmRoEm+0BvcTEeQ@mail.gmail.com>
 <CAKe9RRHZjGGxwtHGYV_0qmNnErTSjGqMZwW+3v+p=4eW+wDWKQ@mail.gmail.com>
 <87imwwq7nx.fsf@smart-cactus.org>
Message-ID: <CAKe9RRELiAp-OWRHaDOp=2E40UUyJLEzYmmjSxsH-dZ-zZFm0Q@mail.gmail.com>

On Wed, Mar 6, 2019 at 11:39 AM Ben Gamari <ben at well-typed.com> wrote:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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 <ben at well-typed.com> 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 <emnet at digitalasset.com> 
Digital Asset Holdings, LLC
4 World Trade Center                                                        150
Greenwich Street, 47th Floor
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/a3762835/attachment-0001.html>

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>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
 <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr>
 <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
 <CACPahm1aDj7AZ-ZWwTXJrKvbzLaP6gaSJxCo2zhKTKQ_stcZ+A@mail.gmail.com>
 <87fts0q7fz.fsf@smart-cactus.org>
Message-ID: <CACPahm1faKypjpmxWVFxd12J3DJcisexzP7j81=UoTgcVVAfKA@mail.gmail.com>

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 <ben at well-typed.com> wrote:

> Ara Adkins <me at ara.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/c6a86f95/attachment.html>

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: <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
References: <8736o0ssqo.fsf@smart-cactus.org>
 <E52D6104-07D4-4CFB-A56F-69BD3E0BD22E@ara.io>
 <91121787-E6C0-45E4-BB7B-B25FBF2B440E@well-typed.com>
 <CE8C4FAB-4CB1-4CC3-859C-B3C580030EE6@ara.io>
 <3c7f2f24-09f6-1ae2-cc31-b1cb4be85b5c@haskus.fr>
 <CALuQ0m-Jv9kgufrkU+59qHQ6aN=mjYaCSzojuP1F_AU9_S0w1w@mail.gmail.com>
Message-ID: <CABHktDWYsUmc59L3f7SRuuT8=Ycgw3vZ-Uk4rHvXu1hpX-ue8w@mail.gmail.com>

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 <matthewtpickering at gmail.com>
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 <sylvain at haskus.fr> 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 <ben at well-typed.com> wrote:
>> >>
>> >>
>> >>
>> >>> On March 6, 2019 6:11:49 AM EST, Ara Adkins <me at ara.io> 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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/89919e92/attachment.html>

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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
Message-ID: <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>

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 <ben at smart-cactus.org> wrote:

> Sylvain Henry <sylvain at haskus.fr> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/3abedb2f/attachment.html>

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: <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
Message-ID: <87a7i7r7ea.fsf@smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/480c2736/attachment.sig>

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: <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
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 <m at tweag.io> 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 <ben at smart-cactus.org <mailto:ben at smart-cactus.org>> wrote:
> Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>> 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 <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190306/4fbeb0b6/attachment.html>

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: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/3db93e33/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/3db93e33/attachment.sig>

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: <CADdQpRCbcWD_kn2x216MCz_tzpC7+gW0Kht2ankb9yf7rw33Uw@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/794c2046/attachment.html>

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: <CAKe9RREMe4=qTLO7vyrbvurAAYS6hzqb7na7CnF+X3DSNqUasw@mail.gmail.com>

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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/43b46fcd/attachment.html>

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: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>
References: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>
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: <CAKe9RREMe4=qTLO7vyrbvurAAYS6hzqb7na7CnF+X3DSNqUasw@mail.gmail.com>
References: <CAKe9RREMe4=qTLO7vyrbvurAAYS6hzqb7na7CnF+X3DSNqUasw@mail.gmail.com>
Message-ID: <871s3iqjp4.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/6b9f45bd/attachment.sig>

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: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>
 <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/5d06757c/attachment.sig>

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: <CAKe9RREMe4=qTLO7vyrbvurAAYS6hzqb7na7CnF+X3DSNqUasw@mail.gmail.com>
 <871s3iqjp4.fsf@smart-cactus.org>
Message-ID: <CAKe9RREmjqX5Hd+YyOZhnWgX151_mLfwxJWbYXNL1cojdcVtCA@mail.gmail.com>

Hi Ben,

On Thu, Mar 7, 2019 at 7:44 PM Ben Gamari <ben at well-typed.com> wrote:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190307/b7f2f6b9/attachment.html>

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: <CAKe9RREmjqX5Hd+YyOZhnWgX151_mLfwxJWbYXNL1cojdcVtCA@mail.gmail.com>
References: <CAKe9RREMe4=qTLO7vyrbvurAAYS6hzqb7na7CnF+X3DSNqUasw@mail.gmail.com>
 <871s3iqjp4.fsf@smart-cactus.org>
 <CAKe9RREmjqX5Hd+YyOZhnWgX151_mLfwxJWbYXNL1cojdcVtCA@mail.gmail.com>
Message-ID: <CAKe9RRH1bsxZYuKsLowcXX0z_T0X7mk2RvieD7ywzoi4mSMZUQ@mail.gmail.com>

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 <ben at well-typed.com> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/a69e5601/attachment.html>

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: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>
 <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu>
 <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com>
Message-ID: <CADdQpRB_92ed25e5P8+Nb2kRsvp9LnPV4Wx78wEwLuntfp0gEQ@mail.gmail.com>

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 <moritz.angermann at gmail.com>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/56fc6440/attachment.html>

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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>

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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/c710066d/attachment.html>

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: <CADdQpRB_92ed25e5P8+Nb2kRsvp9LnPV4Wx78wEwLuntfp0gEQ@mail.gmail.com>
References: <D04203B9-4E2A-4055-BB92-637F9C57567F@gmail.com>
 <56858A5B-9AF4-4B20-A0B0-CC695B24B304@cs.brynmawr.edu>
 <26174369-18ED-4D14-ACC2-47F2ABD62961@gmail.com>
 <CADdQpRB_92ed25e5P8+Nb2kRsvp9LnPV4Wx78wEwLuntfp0gEQ@mail.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
> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/69271e24/attachment.sig>

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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
Message-ID: <CAKe9RRFuDosMCdLHZwOcoX=hfAK-buOrjuakFmQC=ZNpDtiLcw@mail.gmail.com>

Hi y'all

On Fri, Mar 8, 2019 at 9:16 AM Shayne Fletcher <shayne.fletcher at daml.com>
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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/7d27cd1e/attachment.html>

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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
Message-ID: <87wol8pnwp.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/2f33452b/attachment.sig>

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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <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 <ben at well-typed.com> wrote:
> 
> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
Message-ID: <CAKe9RRGGqOLb6fxZ+HFExqRmoSSu+6Ca=_8vrTmaiREETexkUA@mail.gmail.com>

On Sat, Mar 9, 2019 at 1:23 AM Ben Gamari <ben at well-typed.com> wrote:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/0c10c07a/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/773c7324/attachment.sig>

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: <CAKe9RRGGqOLb6fxZ+HFExqRmoSSu+6Ca=_8vrTmaiREETexkUA@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAKe9RRGGqOLb6fxZ+HFExqRmoSSu+6Ca=_8vrTmaiREETexkUA@mail.gmail.com>
Message-ID: <fcba45f1-df88-9537-ca5f-001aba9c03a4@iki.fi>

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 <ben at well-typed.com
> <mailto:ben at well-typed.com>> wrote:
>
>     Shayne Fletcher via ghc-devs <ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org>> 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 <http://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
> <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/26249183/attachment.sig>

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: <fcba45f1-df88-9537-ca5f-001aba9c03a4@iki.fi>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAKe9RRGGqOLb6fxZ+HFExqRmoSSu+6Ca=_8vrTmaiREETexkUA@mail.gmail.com>
 <fcba45f1-df88-9537-ca5f-001aba9c03a4@iki.fi>
Message-ID: <CAKe9RREP6LAUs3QgsCW-UE20ubCQE5nbuvkxjxhH_=fXfDbzgA@mail.gmail.com>

On Sat, Mar 9, 2019 at 11:41 AM Oleg Grenrus <oleg.grenrus at iki.fi> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/6990290c/attachment.html>

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: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
Message-ID: <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>

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 <ben at well-typed.com> wrote:
>
> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>
Message-ID: <CAEDDsWeuiO-TNdQO3O6GOXim2tXUL_mo6cYQ5jwOJAaA1_s5Rg@mail.gmail.com>

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 <mgsloan at gmail.com> 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 <ben at well-typed.com> wrote:
> >
> > Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <CAEDDsWeuiO-TNdQO3O6GOXim2tXUL_mo6cYQ5jwOJAaA1_s5Rg@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>
 <CAEDDsWeuiO-TNdQO3O6GOXim2tXUL_mo6cYQ5jwOJAaA1_s5Rg@mail.gmail.com>
Message-ID: <CAKFCL4U1X4fV0aXkt=f=S-=RPBC0r0i-8yUojkC8th4UJ+Bwkw@mail.gmail.com>

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 <mgsloan at gmail.com> 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 <mgsloan at gmail.com> 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 <ben at well-typed.com> wrote:
> > >
> > > Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/dc732054/attachment.html>

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: <CAKFCL4U1X4fV0aXkt=f=S-=RPBC0r0i-8yUojkC8th4UJ+Bwkw@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>
 <CAEDDsWeuiO-TNdQO3O6GOXim2tXUL_mo6cYQ5jwOJAaA1_s5Rg@mail.gmail.com>
 <CAKFCL4U1X4fV0aXkt=f=S-=RPBC0r0i-8yUojkC8th4UJ+Bwkw@mail.gmail.com>
Message-ID: <CAEDDsWcRDaCrmA1XViow2UGbcuJ+63oXpxY7HyB44gxR3u6f2Q@mail.gmail.com>

Ah, probably so, thanks!

On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery <allbery.b at gmail.com> 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 <mgsloan at gmail.com> 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 <mgsloan at gmail.com> 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 <ben at well-typed.com> wrote:
>> > >
>> > > Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <CAEDDsWcRDaCrmA1XViow2UGbcuJ+63oXpxY7HyB44gxR3u6f2Q@mail.gmail.com>
References: <CAKe9RREFR0osHe8T2YZDwR2d9oCJxFv7Hx3Nao5LFvf32XHy5g@mail.gmail.com>
 <87wol8pnwp.fsf@smart-cactus.org>
 <CAEDDsWeOx6KU2vmLSQrTHVDkvF_FbZhk18KavU81=MJudoX06w@mail.gmail.com>
 <CAEDDsWeuiO-TNdQO3O6GOXim2tXUL_mo6cYQ5jwOJAaA1_s5Rg@mail.gmail.com>
 <CAKFCL4U1X4fV0aXkt=f=S-=RPBC0r0i-8yUojkC8th4UJ+Bwkw@mail.gmail.com>
 <CAEDDsWcRDaCrmA1XViow2UGbcuJ+63oXpxY7HyB44gxR3u6f2Q@mail.gmail.com>
Message-ID: <CAKe9RRGouUomHR2yDHHbjT6ezPAyJQdeqO3UMUfKVMvfArPT4Q@mail.gmail.com>

On Sat, Mar 9, 2019 at 9:09 PM Michael Sloan <mgsloan at gmail.com> wrote:

> Ah, probably so, thanks!
>
> On Sat, Mar 9, 2019 at 6:05 PM Brandon Allbery <allbery.b at gmail.com>
> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190309/76bf9638/attachment.html>

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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190310/1f7f8fe9/attachment.sig>

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: <PR2P264MB0560DB2E8E8A2CACD6980EC8FF4F0@PR2P264MB0560.FRAP264.PROD.OUTLOOK.COM>

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 <ghc-devs-bounces at haskell.org> on behalf of Ben Gamari <ben at well-typed.com>
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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190310/bad443f1/attachment.html>

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: <CAKe9RRGjD56=yWWU0xhhz3QOx6HtVq+uSrHrdJRpAZP_BV1FsQ@mail.gmail.com>

On Sun, Mar 10, 2019 at 5:38 PM Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> 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 
<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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190310/3aea4ad5/attachment.html>

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: <CAKe9RRGjD56=yWWU0xhhz3QOx6HtVq+uSrHrdJRpAZP_BV1FsQ@mail.gmail.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <CAKe9RRGjD56=yWWU0xhhz3QOx6HtVq+uSrHrdJRpAZP_BV1FsQ@mail.gmail.com>
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 <ghc-devs at haskell.org> wrote:
> 
> 
> 
>> On Sun, Mar 10, 2019 at 5:38 PM Ben Gamari <ben at well-typed.com> wrote:
>> Ben Gamari <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190310/f6eface1/attachment.html>

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: <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>

|  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/<page>, the new URL is "https://gitlab.haskell.org/ghc/ghc/wikis/<page>".

* 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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C48ce7f7334
|  c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878
|  507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo0sk4%3
|  D&amp;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: <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>

> * 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/<page>, the new URL is "https://gitlab.haskell.org/ghc/ghc/wikis/<page>".
>
> * 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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C48ce7f7334
> |  c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878
> |  507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo0sk4%3
> |  D&amp;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: <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
Message-ID: <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>

|  > * 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 <matthewtpickering at gmail.com>
|  Sent: 11 March 2019 09:37
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Ben Gamari <ben at well-typed.com>; 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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356
|  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
|  CdI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micro
|  soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
|  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
|  FJpNt6nkr%2BObzRAmk%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%
|  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
|  1UyIq4%3D&amp;reserved=0<page>, the new URL is
|  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
|  haskell.org%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
|  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
|  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
|  BUo5ABhqVo%3D&amp;reserved=0<page>".
|  >
|  > * Where has
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
|  ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
|  0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
|  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
|  Yk0DjFBxuKFkQbnyUeI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d
|  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
|  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micros
|  oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
|  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
|  D4DGorbNyz28%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008
|  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
|  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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&amp
|  ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319
|  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
|  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C48ce
|  > | 7f7334
|  > |
|  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  > | 636878
|  > |
|  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
|  > | 0sk4%3
|  > |  D&amp;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&amp;data=02%7C01
|  > %7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
|  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;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: <AM0PR83MB0289C7FDD467A4A3A345B0A3AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/d1679dca/attachment.html>

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: <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>

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
<simonpj at microsoft.com> 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 <matthewtpickering at gmail.com>
> |  Sent: 11 March 2019 09:37
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: Ben Gamari <ben at well-typed.com>; 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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356
> |  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> |  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
> |  CdI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micro
> |  soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
> |  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
> |  FJpNt6nkr%2BObzRAmk%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%
> |  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
> |  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
> |  haskell.org%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
> |  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
> |  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
> |  >
> |  > * Where has
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
> |  ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
> |  0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
> |  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d
> |  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
> |  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micros
> |  oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
> |  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
> |  D4DGorbNyz28%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008
> |  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
> |  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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&amp
> |  ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319
> |  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C48ce
> |  > | 7f7334
> |  > |
> |  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> |  > | 636878
> |  > |
> |  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
> |  > | 0sk4%3
> |  > |  D&amp;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&amp;data=02%7C01
> |  > %7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988
> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;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: <AM0PR83MB0289C7FDD467A4A3A345B0A3AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0289C7FDD467A4A3A345B0A3AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m9fJ0GXnRew3-9jJOdv2LZkPejLuw7OnOdj9PbypXDFGQ@mail.gmail.com>

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
<ghc-devs at haskell.org> 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: <CALuQ0m9fJ0GXnRew3-9jJOdv2LZkPejLuw7OnOdj9PbypXDFGQ@mail.gmail.com>
References: <AM0PR83MB0289C7FDD467A4A3A345B0A3AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9fJ0GXnRew3-9jJOdv2LZkPejLuw7OnOdj9PbypXDFGQ@mail.gmail.com>
Message-ID: <AM0PR83MB028911AC9AC6A5EE8013E9B0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>

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 <matthewtpickering at gmail.com>
|  Sent: 11 March 2019 10:19
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cd6f130325d1b4641570208d6a6
|  0af46b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708&amp
|  ;sdata=pW9%2Fu6XwR9MUxHDVaHzVmHz4sdICeOUVx5a92ItG4f4%3D&amp;reserved=0=
|  
|  On Mon, Mar 11, 2019 at 10:17 AM Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org> 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&amp;data=02%7C01%7Cs
|  > imonpj%40microsoft.com%7Cd6f130325d1b4641570208d6a60af46b%7C72f988bf86
|  > f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708&amp;sdata=7OWEef4q
|  > 1ccSiKV1DFWkndz2XT6gpy%2BD5sbuphUxCQA%3D&amp;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&amp;data=02%7C01
|  > %7Csimonpj%40microsoft.com%7Cd6f130325d1b4641570208d6a60af46b%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878963319322708&amp;sdata=OdHS
|  > SX6KLIX4oqGoKnCYOZ3hXrFHLYNUpCMwKfl2Jz0%3D&amp;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: <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
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 <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
> <simonpj at microsoft.com> 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 <matthewtpickering at gmail.com>
>> |  Sent: 11 March 2019 09:37
>> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>> |  Cc: Ben Gamari <ben at well-typed.com>; 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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356
>> |  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> |  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
>> |  CdI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micro
>> |  soft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
>> |  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
>> |  FJpNt6nkr%2BObzRAmk%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%
>> |  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
>> |  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
>> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
>> |  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
>> |  haskell.org%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
>> |  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
>> |  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
>> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
>> |  >
>> |  > * Where has
>> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
>> |  ell.org%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
>> |  0microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
>> |  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
>> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d
>> |  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
>> |  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micros
>> |  oft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
>> |  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
>> |  D4DGorbNyz28%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008
>> |  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
>> |  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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&amp
>> |  ;data=02%7C01%7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319
>> |  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
>> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C48ce
>> |  > | 7f7334
>> |  > |
>> |  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
>> |  > | 636878
>> |  > |
>> |  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
>> |  > | 0sk4%3
>> |  > |  D&amp;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&amp;data=02%7C01
>> |  > %7Csimonpj%40microsoft.com%7Cac356d50797a44abf82008d6a6053319%7C72f988
>> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
>> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;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>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
Message-ID: <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>

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 <rae at cs.brynmawr.edu> 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
> > <simonpj at microsoft.com> 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 <matthewtpickering at gmail.com>
> >> |  Sent: 11 March 2019 09:37
> >> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> >> |  Cc: Ben Gamari <ben at well-typed.com>; 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&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7Cac356
> >> |
> d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> >> |
> 36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
> >> |  CdI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micro
> >> |  soft.com
> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
> >> |
> db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
> >> |  FJpNt6nkr%2BObzRAmk%3D&amp;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&amp;data=02%7C01%7Csimonpj%
> 40microsoft.com%
> >> |
> 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> >> |
> 7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
> >> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
> >> |  "
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
> >> |  haskell.org
> %2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
> >> |
> com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
> >> |
> 7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
> >> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
> >> |  >
> >> |  > * Where has
> >> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
> >> |  ell.org
> %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
> >> |  0microsoft.com
> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
> >> |
> 7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
> >> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7Cac356d50797a44abf82008d
> >> |
> 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
> >> |
> amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micros
> >> |  oft.com
> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
> >> |
> b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
> >> |  D4DGorbNyz28%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7Cac356d50797a44abf82008
> >> |
> d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
> >> |
> &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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&amp
> >> |  ;data=02%7C01%7Csimonpj%40microsoft.com
> %7Cac356d50797a44abf82008d6a6053319
> >> |
> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
> >> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C48ce
> >> |  > | 7f7334
> >> |  > |
> >> |  > |
> c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> >> |  > | 636878
> >> |  > |
> >> |  > |
> 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
> >> |  > | 0sk4%3
> >> |  > |  D&amp;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&amp;data=02%7C01
> >> |  > %7Csimonpj%40microsoft.com
> %7Cac356d50797a44abf82008d6a6053319%7C72f988
> >> |  >
> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
> >> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/69e96fcc/attachment.html>

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: <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
Message-ID: <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>

This old ticket might be related: https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 <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 <a.pelenitsyn at gmail.com> 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 <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> 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 <mailto: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
> > <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> 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 <matthewtpickering at gmail.com <mailto:matthewtpickering at gmail.com>>
> >> |  Sent: 11 March 2019 09:37
> >> |  To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> >> |  Cc: Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>>; GHC developers <ghc-devs at haskell.org <mailto: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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fbgamari%2Fgitlab-
> >> |  migration%2Fissues%2F14&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356
> >> |  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> >> |  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
> >> |  CdI%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fissues%2F16417&amp;data=02%7C01%7Csimonpj%40micro
> >> |  soft.com <http://soft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
> >> |  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
> >> |  FJpNt6nkr%2BObzRAmk%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask>
> >> |  ell.org <http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%
> >> |  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> >> |  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
> >> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
> >> |  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab>.
> >> |  haskell.org <http://haskell.org/>%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
> >> |  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
> >> |  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
> >> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
> >> |  >
> >> |  > * Where has
> >> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask>
> >> |  ell.org <http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
> >> |  0microsoft.com <http://0microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
> >> |  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
> >> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Frichard-and-
> >> |  simon&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d
> >> |  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
> >> |  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Findex&amp;data=02%7C01%7Csimonpj%40micros
> >> |  oft.com <http://oft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
> >> |  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
> >> |  D4DGorbNyz28%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type-
> >> |  errors&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008
> >> |  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
> >> |  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo&amp
> >> |  ;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319
> >> |  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
> >> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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 <http://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 <http://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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi>
> >> |  > | tlab.h
> >> |  > |  askell.org <http://askell.org/>%2Fbgamari%2Fgitlab-
> >> |  > |
> >> |  > | migration%2Fissues&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C48ce
> >> |  > | 7f7334
> >> |  > |
> >> |  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> >> |  > | 636878
> >> |  > |
> >> |  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
> >> |  > | 0sk4%3
> >> |  > |  D&amp;reserved=0
> >> |  > _______________________________________________
> >> |  > ghc-devs mailing list
> >> |  > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> >> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail>.
> >> |  > haskell.org <http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
> >> |  > %7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988
> >> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
> >> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;reserved=0
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/a916d2a6/attachment.html>

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: <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
 <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>
Message-ID: <CAPKAvQXXGeZzOrk0tSwNX06D=oFuRx9A+qZw0_WQUO1N9e6nGQ@mail.gmail.com>

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 <rae at cs.brynmawr.edu> 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 <a.pelenitsyn at gmail.com>
> 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 <rae at cs.brynmawr.edu>
> 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
>> > <simonpj at microsoft.com> 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 <matthewtpickering at gmail.com>
>> >> |  Sent: 11 March 2019 09:37
>> >> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>> >> |  Cc: Ben Gamari <ben at well-typed.com>; 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&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7Cac356
>> >> |
>> d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> >> |
>> 36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
>> >> |  CdI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micro
>> >> |  soft.com
>> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
>> >> |
>> db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
>> >> |  FJpNt6nkr%2BObzRAmk%3D&amp;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&amp;data=02%7C01%7Csimonpj%
>> 40microsoft.com%
>> >> |
>> 7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
>> >> |
>> 7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
>> >> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
>> >> |  "
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
>> >> |  haskell.org
>> %2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
>> >> |
>> com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
>> >> |
>> 7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
>> >> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
>> >> |  >
>> >> |  > * Where has
>> >> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
>> >> |  ell.org
>> %2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
>> >> |  0microsoft.com
>> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
>> >> |
>> 7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
>> >> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7Cac356d50797a44abf82008d
>> >> |
>> 6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
>> >> |
>> amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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&amp;data=02%7C01%7Csimonpj%40micros
>> >> |  oft.com
>> %7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
>> >> |
>> b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
>> >> |  D4DGorbNyz28%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7Cac356d50797a44abf82008
>> >> |
>> d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
>> >> |
>> &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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&amp
>> >> |  ;data=02%7C01%7Csimonpj%40microsoft.com
>> %7Cac356d50797a44abf82008d6a6053319
>> >> |
>> %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
>> >> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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&amp;data=02%7C01%7Csimonpj%40microsoft.com
>> %7C48ce
>> >> |  > | 7f7334
>> >> |  > |
>> >> |  > |
>> c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
>> >> |  > | 636878
>> >> |  > |
>> >> |  > |
>> 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
>> >> |  > | 0sk4%3
>> >> |  > |  D&amp;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&amp;data=02%7C01
>> >> |  > %7Csimonpj%40microsoft.com
>> %7Cac356d50797a44abf82008d6a6053319%7C72f988
>> >> |  >
>> bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
>> >> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/ea821cd6/attachment-0001.html>

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: <CAPKAvQXXGeZzOrk0tSwNX06D=oFuRx9A+qZw0_WQUO1N9e6nGQ@mail.gmail.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
 <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>
 <CAPKAvQXXGeZzOrk0tSwNX06D=oFuRx9A+qZw0_WQUO1N9e6nGQ@mail.gmail.com>
Message-ID: <EF61AC96-EAF3-47BE-9996-8A0D64113B61@richarde.dev>

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 <a.pelenitsyn at gmail.com> 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 <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> This old ticket might be related: https://gitlab.com/gitlab-org/gitlab-ce/issues/1734 <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 <a.pelenitsyn at gmail.com <mailto:a.pelenitsyn at gmail.com>> 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 <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> 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 <mailto: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
>> > <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> 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 <matthewtpickering at gmail.com <mailto:matthewtpickering at gmail.com>>
>> >> |  Sent: 11 March 2019 09:37
>> >> |  To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>> >> |  Cc: Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>>; GHC developers <ghc-devs at haskell.org <mailto: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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fbgamari%2Fgitlab-
>> >> |  migration%2Fissues%2F14&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356
>> >> |  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> >> |  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
>> >> |  CdI%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fissues%2F16417&amp;data=02%7C01%7Csimonpj%40micro
>> >> |  soft.com <http://soft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
>> >> |  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
>> >> |  FJpNt6nkr%2BObzRAmk%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask>
>> >> |  ell.org <http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%
>> >> |  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
>> >> |  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
>> >> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
>> >> |  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab>.
>> >> |  haskell.org <http://haskell.org/>%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
>> >> |  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
>> >> |  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
>> >> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
>> >> |  >
>> >> |  > * Where has
>> >> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask>
>> >> |  ell.org <http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
>> >> |  0microsoft.com <http://0microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
>> >> |  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
>> >> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Frichard-and-
>> >> |  simon&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d
>> >> |  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
>> >> |  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Findex&amp;data=02%7C01%7Csimonpj%40micros
>> >> |  oft.com <http://oft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
>> >> |  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
>> >> |  D4DGorbNyz28%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type-
>> >> |  errors&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008
>> >> |  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
>> >> |  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h>
>> >> |  askell.org <http://askell.org/>%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo&amp
>> >> |  ;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319
>> >> |  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
>> >> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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 <http://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 <http://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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi>
>> >> |  > | tlab.h
>> >> |  > |  askell.org <http://askell.org/>%2Fbgamari%2Fgitlab-
>> >> |  > |
>> >> |  > | migration%2Fissues&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C48ce
>> >> |  > | 7f7334
>> >> |  > |
>> >> |  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
>> >> |  > | 636878
>> >> |  > |
>> >> |  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
>> >> |  > | 0sk4%3
>> >> |  > |  D&amp;reserved=0
>> >> |  > _______________________________________________
>> >> |  > ghc-devs mailing list
>> >> |  > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> >> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail>.
>> >> |  > haskell.org <http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
>> >> |  > %7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988
>> >> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
>> >> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;reserved=0
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/31a63456/attachment.html>

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: <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <87bm2hqbqy.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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/<page>, the new URL is
> "https://gitlab.haskell.org/ghc/ghc/wikis/<page>".
>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/84150a62/attachment.sig>

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: <EF61AC96-EAF3-47BE-9996-8A0D64113B61@richarde.dev>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
 <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>
 <CAPKAvQXXGeZzOrk0tSwNX06D=oFuRx9A+qZw0_WQUO1N9e6nGQ@mail.gmail.com>
 <EF61AC96-EAF3-47BE-9996-8A0D64113B61@richarde.dev>
Message-ID: <AM0PR83MB0289534E8897D52FF5B28759AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>

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 <ghc-devs-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 11 March 2019 20:43
To: Artem Pelenitsyn <a.pelenitsyn at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
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 <a.pelenitsyn at gmail.com<mailto:a.pelenitsyn at gmail.com>> 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 <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> 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 <a.pelenitsyn at gmail.com<mailto:a.pelenitsyn at gmail.com>> 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 <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> 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<mailto: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
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> 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 <matthewtpickering at gmail.com<mailto:matthewtpickering at gmail.com>>
>> |  Sent: 11 March 2019 09:37
>> |  To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
>> |  Cc: Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>>; GHC developers <ghc-devs at haskell.org<mailto: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<http://askell.org/>%2Fbgamari%2Fgitlab-
>> |  migration%2Fissues%2F14&amp;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cac356
>> |  d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> |  36878938597242017&amp;sdata=XnY%2Fo62mCkz849XKLKe8V3stFe8sorBQkqI9%2FY%2By
>> |  CdI%3D&amp;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<http://askell.org/>%2Fghc%2Fghc%2Fissues%2F16417&amp;data=02%7C01%7Csimonpj%40micro
>> |  soft.com<http://soft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011
>> |  db47%7C1%7C0%7C636878938597242017&amp;sdata=s5%2FfsXsx5t%2FuRIeq6AJZU5sr8P
>> |  FJpNt6nkr%2BObzRAmk%3D&amp;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<http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%
>> |  7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%
>> |  7C0%7C636878938597242017&amp;sdata=vq0ZCkxOmaQp4vB3WPzc%2BovCn1oSSak5K6CYM
>> |  1UyIq4%3D&amp;reserved=0<page>, the new URL is
>> |  "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.
>> |  haskell.org<http://haskell.org/>%2Fghc%2Fghc%2Fwikis%2F&amp;data=02%7C01%7Csimonpj%40microsoft.
>> |  com%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%
>> |  7C1%7C0%7C636878938597242017&amp;sdata=ZbZf%2BlVa1rqrngh82QrJAIRmDFaGMp0Gb
>> |  BUo5ABhqVo%3D&amp;reserved=0<page>".
>> |  >
>> |  > * Where has
>> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.hask
>> |  ell.org<http://ell.org/>%2Ftrac%2Fghc%2Fwiki%2FRichardAndSimon&amp;data=02%7C01%7Csimonpj%4
>> |  0microsoft.com<http://0microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d
>> |  7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=xkERHLEyWh8yWLxRS2GUZ4iu
>> |  Yk0DjFBxuKFkQbnyUeI%3D&amp;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<http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Frichard-and-
>> |  simon&amp;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cac356d50797a44abf82008d
>> |  6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&
>> |  amp;sdata=X%2BOPbJn4zTiGNkH%2Ba5TVoge6dxZmGw0WSxrnxEpk0og%3D&amp;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<http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Findex&amp;data=02%7C01%7Csimonpj%40micros
>> |  oft.com<http://oft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988bf86f141af91ab2d7cd011d
>> |  b47%7C1%7C0%7C636878938597242017&amp;sdata=BZ337ak7obJlIGW4GK5R4FOl1uCCH2T
>> |  D4DGorbNyz28%3D&amp;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<http://askell.org/>%2Fghc%2Fghc%2Fwikis%2Fproposal%2Fcustom-type-
>> |  errors&amp;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cac356d50797a44abf82008
>> |  d6a6053319%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017
>> |  &amp;sdata=sueCHGV9aE36gaIqUgxBq1VZl4zOKhCYDOWwsnSgAss%3D&amp;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<http://askell.org/>%2Fghc%2Fghc%2Fissues%3Flabel_name%255B%255D%3DApplicativeDo&amp
>> |  ;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319
>> |  %7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata
>> |  =DM%2B9ZPFxUhJW%2B2EokkOJzXF6Ca6PlSgQf1TGsCt36Wc%3D&amp;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<http://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<http://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<http://askell.org/>%2Fbgamari%2Fgitlab-
>> |  > |
>> |  > | migration%2Fissues&amp;data=02%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C48ce
>> |  > | 7f7334
>> |  > |
>> |  > | c04a54549508d6a5a0cb40%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
>> |  > | 636878
>> |  > |
>> |  > | 507364801779&amp;sdata=DIxKgZy%2B%2BTYq0P%2BEkrxjefMQqUf43ObXi9CLOGo
>> |  > | 0sk4%3
>> |  > |  D&amp;reserved=0
>> |  > _______________________________________________
>> |  > ghc-devs mailing list
>> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
>> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
>> |  > haskell.org<http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%7C01
>> |  > %7Csimonpj%40microsoft.com<http://40microsoft.com/>%7Cac356d50797a44abf82008d6a6053319%7C72f988
>> |  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636878938597242017&amp;sdata=V5Xq
>> |  > iP3b87PRpJvS5KSxyM6qkpSnM3KMDtrIhdQhwB0%3D&amp;reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/fa9e571d/attachment-0001.html>

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>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
Message-ID: <874l89q7ad.fsf@smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/fa1a4bc0/attachment.sig>

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: <EF61AC96-EAF3-47BE-9996-8A0D64113B61@richarde.dev>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <CAPKAvQWkG4SSc57SdgNYKvHeXajhQ3u_-k+hTrf93sMLpDYVBw@mail.gmail.com>
 <E1323D34-34B8-4080-A1BC-BE23CE81EBA8@cs.brynmawr.edu>
 <CAPKAvQXXGeZzOrk0tSwNX06D=oFuRx9A+qZw0_WQUO1N9e6nGQ@mail.gmail.com>
 <EF61AC96-EAF3-47BE-9996-8A0D64113B61@richarde.dev>
Message-ID: <871s3dq735.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190311/161d7997/attachment.sig>

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: <CALuQ0m8C9Qk1eSbmsuOZoRg-7YfervHNyvRPWuDH9fc4MSP86g@mail.gmail.com>

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>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <87bm2hqbqy.fsf@smart-cactus.org>
Message-ID: <AM0PR83MB0289C69A8887990F16818884AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>

|  > * 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 <ben at well-typed.com>
|  Sent: 11 March 2019 22:37
|  To: Simon Peyton Jones <simonpj at microsoft.com>; GHC developers <ghc-
|  devs at haskell.org>
|  Subject: RE: Trac to GitLab migration underway
|  
|  Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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/<page>, the new URL is
|  > "https://gitlab.haskell.org/ghc/ghc/wikis/<page>".
|  >
|  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: <AM0PR83MB02891CB3C597E21E7FF709C0AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190312/234d9ab2/attachment.html>

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: <B67DD1D5-C5E4-4A3F-8573-A0A1D12326CD@cs.brynmawr.edu>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <874l89q7ad.fsf@smart-cactus.org>
 <B67DD1D5-C5E4-4A3F-8573-A0A1D12326CD@cs.brynmawr.edu>
Message-ID: <BE37F42F-79A9-47AB-AB1E-0B2FD09D2F6C@richarde.dev>


> On Mar 11, 2019, at 8:13 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Richard Eisenberg <rae at cs.brynmawr.edu> 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: <CALuQ0m8C9Qk1eSbmsuOZoRg-7YfervHNyvRPWuDH9fc4MSP86g@mail.gmail.com>
References: <CALuQ0m8C9Qk1eSbmsuOZoRg-7YfervHNyvRPWuDH9fc4MSP86g@mail.gmail.com>
Message-ID: <CAEDDsWcsgocLJSst6inVZwqmkMN3c9iPqeLHhmd_VAabB9tanw@mail.gmail.com>

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
<matthewtpickering at gmail.com> 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: <AM0PR83MB028911AC9AC6A5EE8013E9B0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <AM0PR83MB0289C7FDD467A4A3A345B0A3AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9fJ0GXnRew3-9jJOdv2LZkPejLuw7OnOdj9PbypXDFGQ@mail.gmail.com>
 <AM0PR83MB028911AC9AC6A5EE8013E9B0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <87k1h4otge.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190312/47402bce/attachment.sig>

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: <AM0PR83MB02891CB3C597E21E7FF709C0AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <AM0PR83MB02891CB3C597E21E7FF709C0AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALuQ0m_NpwdVPZpEsg-TY-jmFYiGxEWwJhgvbqnpH+BfMCLWTQ@mail.gmail.com>

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
<simonpj at microsoft.com> 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: <AM0PR83MB02891CB3C597E21E7FF709C0AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <AM0PR83MB02891CB3C597E21E7FF709C0AD490@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <87d0mvq0d1.fsf@smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190312/352f590b/attachment.sig>

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>
 <A3629F88-317D-4F21-9262-42AB3FAEE8E3@leviston.net>,
 <20190305115433.ftpp42evwatmgien@nibbler>
Message-ID: <PR2P264MB0560448B8BA3EBD1A3F2CE96FF490@PR2P264MB0560.FRAP264.PROD.OUTLOOK.COM>

Hello;

I’d like to ask something regarding this effort. Right now, GHC’s repository is mirrored in these locations:

  *   Phabricator<https://phabricator.haskell.org/diffusion/GHC/>
  *   git.haskell.org<https://git.haskell.org/>
  *   GitHub<https://github.com/ghc/ghc/>
  *   GitLab<https://gitlab.haskell.org/ghc/ghc/>



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 <ghc-devs-bounces at haskell.org> on behalf of Tobias Dammers <tdammers at gmail.com>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190312/4e85a533/attachment.html>

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: <PR2P264MB0560448B8BA3EBD1A3F2CE96FF490@PR2P264MB0560.FRAP264.PROD.OUTLOOK.COM>
References: <20190227100657.b3qodmep4ymvrade@nibbler>
 <A3629F88-317D-4F21-9262-42AB3FAEE8E3@leviston.net>
 <20190305115433.ftpp42evwatmgien@nibbler>
 <PR2P264MB0560448B8BA3EBD1A3F2CE96FF490@PR2P264MB0560.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <878sxjph2c.fsf@smart-cactus.org>

Alexandre Rodrigues <alexandreR_B at outlook.com> writes:

> Hello;
>
> I’d like to ask something regarding this effort. Right now, GHC’s
> repository is mirrored in these locations:
>
>   *   Phabricator<https://phabricator.haskell.org/diffusion/GHC/>
>   *   git.haskell.org<https://git.haskell.org/>
>   *   GitHub<https://github.com/ghc/ghc/>
>   *   GitLab<https://gitlab.haskell.org/ghc/ghc/>
>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190312/0c961c5e/attachment.sig>

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: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>

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: <BE37F42F-79A9-47AB-AB1E-0B2FD09D2F6C@richarde.dev>
References: <87tvgcow4d.fsf@smart-cactus.org> <87h8caqujm.fsf@smart-cactus.org>
 <AM0PR83MB0289C3249F2332C435B5E1E0AD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m9u-+dPSh1i8m+Bjr2XqhrQn40z-0N-m_gcshbicSbuVQ@mail.gmail.com>
 <AM0PR83MB0289397365606AD405E9FB8FAD480@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALuQ0m8dF7aKkhqX7KjWd8-bkGXw_H2__fWO9bh0Gg5EGHxq2g@mail.gmail.com>
 <39975663-65DC-4D05-B3E6-2E74B6617D9C@cs.brynmawr.edu>
 <874l89q7ad.fsf@smart-cactus.org>
 <B67DD1D5-C5E4-4A3F-8573-A0A1D12326CD@cs.brynmawr.edu>
 <BE37F42F-79A9-47AB-AB1E-0B2FD09D2F6C@richarde.dev>
Message-ID: <CABHktDUMd6a9a39xJ7hFR1N422V8g5oTEoQu0YRkpYueWqPXvQ@mail.gmail.com>

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 <rae at richarde.dev> wrote:

>
> > On Mar 11, 2019, at 8:13 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> >
> > Richard Eisenberg <rae at cs.brynmawr.edu> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/aeefbe7a/attachment.html>

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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
Message-ID: <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>

On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/11a52ca7/attachment.html>

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: <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
 <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
Message-ID: <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.gmail.com>

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 <arnaud.spiwack at tweag.io> wrote:
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com> 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: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>
References: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>
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 <matthewtpickering at gmail.com> 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: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>
References: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>
Message-ID: <871s3bovjy.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/09f9147f/attachment-0001.sig>

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: <CALuQ0m9zszMn9_EnuQxfiMFGzVJ6PTn5ZSr7tt8qSLpVhn6yeQ@mail.gmail.com>
 <871s3bovjy.fsf@smart-cactus.org>
Message-ID: <87y35jngcq.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/77366be3/attachment.sig>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/73088609/attachment.sig>

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: <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
 <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
 <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.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 <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 <arnaud.spiwack at tweag.io> wrote:
>> 
>> 
>> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/0d18f253/attachment.html>

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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
 <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
 <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.gmail.com>
 <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com>
Message-ID: <CALuQ0m8zQofVQcxuLG4-Nh4=AVUEJKWya25ONxRwMhfE=RUyCQ@mail.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?

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 <alec.theriault at gmail.com> 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 <arnaud.spiwack at tweag.io> wrote:
>
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com> 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: <CALuQ0m8zQofVQcxuLG4-Nh4=AVUEJKWya25ONxRwMhfE=RUyCQ@mail.gmail.com>
References: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
 <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
 <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.gmail.com>
 <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com>
 <CALuQ0m8zQofVQcxuLG4-Nh4=AVUEJKWya25ONxRwMhfE=RUyCQ@mail.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 <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 <alec.theriault at gmail.com> 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 <arnaud.spiwack at tweag.io> wrote:
>> 
>> 
>> 
>> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190313/48e66f1b/attachment.html>

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: <CADdQpRD9Ox_nt80N8gwDVyBkTwMKxCtqkdD1cxfCEPDVdMcsYQ@mail.gmail.com>
 <87sgw0qk8b.fsf@smart-cactus.org>
 <c76ce8e2-3cf9-1bc2-67bf-6edef318d9a1@haskus.fr>
 <87lg1sqcaa.fsf@smart-cactus.org>
 <CAJ0eudpSHmQFbrgccKFdCfZkOpANdwtok-4Do2dYaM3W-vSryQ@mail.gmail.com>
 <0D155BB3-4343-425D-BC7F-A0AAE8B21596@gmail.com>
 <CAH6fHQnsZ_-Wo0k4mqgsX80yVvizPNX7AYQt5NNEoTX13j07MA@mail.gmail.com>
 <CALuQ0m_uR_rrgV68QCGF9FzkNUX-n-AjX6AAcDoL8zoP3SS+5Q@mail.gmail.com>
 <14E8FD78-0773-454F-BC22-2ECC744FDF4A@gmail.com>
 <CALuQ0m8zQofVQcxuLG4-Nh4=AVUEJKWya25ONxRwMhfE=RUyCQ@mail.gmail.com>
 <12E2F656-672B-4079-A924-1EBC04F509D0@gmail.com>
Message-ID: <CAH6fHQnNnzp2HWTHMWQmO-SnqTAZ4R1iMe0DL0PFtksxhXjzGw@mail.gmail.com>

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 <alec.theriault 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?
>
>
> 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 <alec.theriault at gmail.com>
> 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 <arnaud.spiwack at tweag.io>
> wrote:
>
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/d9258ba6/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/02f08e1b/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
Message-ID: <CALuQ0m-7hdAHq25qFBx0R76CVJo7WjjM+6Sn8mrTpAGwCw3PMA@mail.gmail.com>

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 <arnaud.spiwack at tweag.io> 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: <CALuQ0m-7hdAHq25qFBx0R76CVJo7WjjM+6Sn8mrTpAGwCw3PMA@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CALuQ0m-7hdAHq25qFBx0R76CVJo7WjjM+6Sn8mrTpAGwCw3PMA@mail.gmail.com>
Message-ID: <CAH6fHQnsd_9nauLtVNvQwYp_Q25WmHdw1MMRg=r-akOb1KTs8w@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/df9fc2d9/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
Message-ID: <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>

On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/863c5b0a/attachment.html>

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: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>

`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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/3a7ec6a0/attachment.html>

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: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>
References: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>
Message-ID: <CAKFCL4W2TM0OvMJD=OaN0uTSofd2-zzuFwdTbkh7BFSjRnR-gg@mail.gmail.com>

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
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/ffa04b4a/attachment.html>

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: <CAKFCL4W2TM0OvMJD=OaN0uTSofd2-zzuFwdTbkh7BFSjRnR-gg@mail.gmail.com>
References: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>
 <CAKFCL4W2TM0OvMJD=OaN0uTSofd2-zzuFwdTbkh7BFSjRnR-gg@mail.gmail.com>
Message-ID: <CAKe9RRGtauFT6xUWFt6AKu8K2N69p44a_D4K19q5gtO-e+KZtQ@mail.gmail.com>

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 <allbery.b at gmail.com> 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
>> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
>> New York, NY 10007, USA
>> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
>> digitalasset.com <http://www.digitalasset.com/>
>>
>>
>> This message, and any attachments, is for the intended recipient(s) only,
>> may contain information that is privileged, confidential and/or proprietary
>> and subject to important terms and conditions available at
>> http://www.digitalasset.com/emaildisclaimer.html. 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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/b12eac74/attachment.html>

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: <CAKe9RRGtauFT6xUWFt6AKu8K2N69p44a_D4K19q5gtO-e+KZtQ@mail.gmail.com>
References: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>
 <CAKFCL4W2TM0OvMJD=OaN0uTSofd2-zzuFwdTbkh7BFSjRnR-gg@mail.gmail.com>
 <CAKe9RRGtauFT6xUWFt6AKu8K2N69p44a_D4K19q5gtO-e+KZtQ@mail.gmail.com>
Message-ID: <87ef79np54.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/c54d77a6/attachment.sig>

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: <CAKe9RRHyWLYTgihE6C1CgfV+ETsa9PTgxfPhyqRZiAp4b7vDJQ@mail.gmail.com>
 <CAKFCL4W2TM0OvMJD=OaN0uTSofd2-zzuFwdTbkh7BFSjRnR-gg@mail.gmail.com>
 <CAKe9RRGtauFT6xUWFt6AKu8K2N69p44a_D4K19q5gtO-e+KZtQ@mail.gmail.com>
 <87ef79np54.fsf@smart-cactus.org>
Message-ID: <CAKe9RRGrPP4u9ObXZuWvKvzR7t1R9rcNGxXcsxOvN+=MxVxX6w@mail.gmail.com>

Hi Ben,

On Thu, Mar 14, 2019 at 5:05 PM Ben Gamari <ben at well-typed.com> wrote:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/ea5e6c40/attachment.html>

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: <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
Message-ID: <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>



> On Mar 15, 2019, at 2:19 AM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> On Thu, Mar 14, 2019 at 4:20 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/42ac62fa/attachment.sig>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
Message-ID: <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>

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?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/b6f5e45b/attachment.html>

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: <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
Message-ID: <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>

Hi Arnaud,

> On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> 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 <your flags of choice>
./hadrian/build.sh -j<N> ...
./hadrian/build.sh -j<N> ...
./hadrian/build.sh -j<N> ...
./hadrian/build.sh -j<N> ...
...

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 <args> && 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/286e357b/attachment.sig>

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: <AM6PR0702MB3543E3BFA99A9E14BBC578E8A5440@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!dab7eeb4181ac34f870b8cc3925f8d2d4298236e06c05dc0348b6b01992af5a100414373e9016b6ef195ba79a5bc705a!@mailhub-mx1.ncl.ac.uk>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.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 <arnaud.spiwack at tweag.io> 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 <your flags of choice>
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ...
>
> 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 <args> && 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/6ad00250/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
Message-ID: <CAKFCL4WULAHnz40yo2a+ta9U-9sEG4D=3rufEjVrLrXj2WZRbA@mail.gmail.com>

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 <moritz.angermann at gmail.com>
wrote:

> Hi Arnaud,
>
> > On Mar 15, 2019, at 8:32 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> 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 <your flags of choice>
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ...
>
> 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
> <args> && 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/99addf5f/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
Message-ID: <875zsknj2x.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190315/3b983a8e/attachment.sig>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190316/cd2b5cd1/attachment.sig>

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: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>

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: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
References: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
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: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
References: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
Message-ID: <87o969nb02.fsf@smart-cactus.org>

Julian Leviston <julian at leviston.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/dcb971f1/attachment.sig>

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: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
 <2395CAF0-BA24-479E-8162-EBEED1F03ACC@leviston.net>
Message-ID: <87lg1dnaxk.fsf@smart-cactus.org>

Julian Leviston <julian at leviston.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/f12a7fa4/attachment.sig>

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: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>

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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/e865adfe/attachment.html>

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: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
Message-ID: <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>

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
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/18de642d/attachment.html>

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: <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
 <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>
Message-ID: <CAKe9RRFiO5YBRZHx6yqbN3o29zHZCMTM8C3fdtUW-wQL6EdFmQ@mail.gmail.com>

Hi Brandon,

On Sun, Mar 17, 2019 at 2:09 PM Brandon Allbery <allbery.b at gmail.com> 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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/c6a6c051/attachment.html>

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: <CAKe9RRFiO5YBRZHx6yqbN3o29zHZCMTM8C3fdtUW-wQL6EdFmQ@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
 <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>
 <CAKe9RRFiO5YBRZHx6yqbN3o29zHZCMTM8C3fdtUW-wQL6EdFmQ@mail.gmail.com>
Message-ID: <CAKFCL4UjSYmWXvN7ZXxhfic9m8sTrW1SyuJv8oyBG=0ck7Qw7g@mail.gmail.com>

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 <shayne.fletcher at daml.com>
wrote:

> Hi Brandon,
>
> On Sun, Mar 17, 2019 at 2:09 PM Brandon Allbery <allbery.b at gmail.com>
> 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
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/148e55fd/attachment.html>

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: <CAKFCL4UjSYmWXvN7ZXxhfic9m8sTrW1SyuJv8oyBG=0ck7Qw7g@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
 <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>
 <CAKe9RRFiO5YBRZHx6yqbN3o29zHZCMTM8C3fdtUW-wQL6EdFmQ@mail.gmail.com>
 <CAKFCL4UjSYmWXvN7ZXxhfic9m8sTrW1SyuJv8oyBG=0ck7Qw7g@mail.gmail.com>
Message-ID: <CAKe9RRGekKB166=zSYDpojdqbfr8tMTjxCoasgbthax9nBt7uA@mail.gmail.com>

On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery <allbery.b at gmail.com> 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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/b6768717/attachment.html>

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: <CAKe9RRGekKB166=zSYDpojdqbfr8tMTjxCoasgbthax9nBt7uA@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
 <CAKFCL4X+iAS+MiaLgTLEnBR+v=BwzEJLr0G1H+jhF0NvfSdr5A@mail.gmail.com>
 <CAKe9RRFiO5YBRZHx6yqbN3o29zHZCMTM8C3fdtUW-wQL6EdFmQ@mail.gmail.com>
 <CAKFCL4UjSYmWXvN7ZXxhfic9m8sTrW1SyuJv8oyBG=0ck7Qw7g@mail.gmail.com>
 <CAKe9RRGekKB166=zSYDpojdqbfr8tMTjxCoasgbthax9nBt7uA@mail.gmail.com>
Message-ID: <CAKFCL4VD4SUoG69M31i8jYbPurWik3p-JXBZEJKPvTygUdEvKQ@mail.gmail.com>

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 <shayne.fletcher at daml.com>
wrote:

>
> On Sun, Mar 17, 2019 at 2:23 PM Brandon Allbery <allbery.b at gmail.com>
> 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
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA
> <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
>
>
> This message, and any attachments, is for the intended recipient(s) only,
> may contain information that is privileged, confidential and/or proprietary
> and subject to important terms and conditions available at
> http://www.digitalasset.com/emaildisclaimer.html. 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/7e891e36/attachment.html>

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: <FF3D26BB-C01C-4A84-93FC-9CD9AB4AF923@leviston.net>
 <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 <ben at smart-cactus.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190318/30834a54/attachment.html>

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: <E2996E37-890D-44B1-863C-D75370024D4E@richarde.dev>

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 <http://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/ <http://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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/c591384d/attachment.html>

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: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
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/ <https://gitlab.haskell.org/ghc/ghc/issues/>

Thanks!
Richard

> On 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 <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 <mailto:shayne.fletcher at daml.com>
> Digital Asset Holdings, LLC
> 4 World Trade Center                                                        150 Greenwich Street, 47th Floor          <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
> digitalasset.com <http://www.digitalasset.com/>
> 
> This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message._______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190317/58ceef06/attachment.html>

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: <E2996E37-890D-44B1-863C-D75370024D4E@richarde.dev>
References: <E2996E37-890D-44B1-863C-D75370024D4E@richarde.dev>
Message-ID: <875zsgm9yb.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> 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
>> <http://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/
>> <http://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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190318/3c21a3be/attachment.sig>

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: <issue_15211@gitlab.haskell.org>
References: <issue_15211@gitlab.haskell.org>
Message-ID: <DB7PR83MB0298C4E407049B18AF4F9D95AD470@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <gitlab at gitlab.haskell.org>
Sent: 18 March 2019 21:39
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: GHC | Work out how to manage labels (#16458)


Currently ghc/ghc><https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542581319&sdata=akt90WXNG6MsBivPVz5cwp88pBaznwo7rya6YnzsBNg%3D&reserved=0> has nearly 100 labels. These fall into a variety of categories:

  1.  Labels that classify the ticket (bug<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dbug&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542581319&sdata=9MNxLK0oFIs9USZwpMpsb1rzwmgrTF8u4NkBf%2BIV8fc%3D&reserved=0>, feature request<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dfeature%2Brequest&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542591271&sdata=OmJmQv1iIwCX6rWPId8rLfrJG7Uo%2FdCXBd4lXFTvcSM%3D&reserved=0>, task<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dtask&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542591271&sdata=H6kaaFry7mYfhn2l%2F1bTLjD81z6spH0GWB%2Bhq21P1lE%3D&reserved=0>)
  2.  Labels that classify bugs by their manifestation: compiler perf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dcompiler%2Bperf&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542601263&sdata=k3iXjux%2BcCsjC6rMbpu1Ve4qzUDt%2FxG5lzqjbM6VHTw%3D&reserved=0>, compiler crash<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dcompiler%2Bcrash&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542601263&sdata=Tt0URbQJbjJ5u3wwi2i4055hI2%2FWDJRRGbtSQS9xvww%3D&reserved=0>, ghc build failure<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dghc%2Bbuild%2Bfailure&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542611257&sdata=R%2BhIllLcgo3pSu2TatvXLiskMCFMq2hm5sulZ3B0WeY%3D&reserved=0>
  3.  Labels that specify the environmental conditions under which an issue will manifest:

     *   architectures: ARM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DARM&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542611257&sdata=R%2BVaZUBT7AJyhrQhbDLm9ST5VWQ5%2F77lSAbJPI6aghI%3D&reserved=0>, SPARC<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DSPARC&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542621251&sdata=UeAiQXnnApKCHmuaGWrekwjNGgmg%2BlaiJFt0y6hRvcA%3D&reserved=0>, PowerPC<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DPowerPC&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542621251&sdata=OQCZBfAy4ip6Do7qNcrab5kYQ%2FAbZcpJ%2FcX9aWOUmQI%3D&reserved=0>
     *   operating system: ~OpenBSD, Windows<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DWindows&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542621251&sdata=KswyqP%2F4thzo8r27U5h6iKxosBwtwiSuN34vUi%2FOgjE%3D&reserved=0>, macOS<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DmacOS&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542631246&sdata=qopNjAcN8kEK%2BjlIl5gmBNOdsYqL3vwynUdMF8KuUDM%3D&reserved=0>

  1.  Labels that specify which compiler or program features are implicated in a bug

     *   language extensions: ImpredicativeTypes<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DImpredicativeTypes&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542631246&sdata=IwWi4SFkLtTrd6CCzYVjCY4uUumwli2c3p850GgYTzg%3D&reserved=0>, ~FlexibleContexts, UnboxedTuples<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DUnboxedTuples&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542641240&sdata=wHXY%2BWXE8UZYcneq1xWmaUzHF%2FN5A4dDFf00gsUkVTU%3D&reserved=0>
     *   program constructs: join points<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Djoin%2Bpoints&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542641240&sdata=QzXVIQoSLtpHGwg4i4FU0IinQ1Ol2vaLPbXvJ99GJFY%3D&reserved=0>, levity polymorphism<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dlevity%2Bpolymorphism&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542651234&sdata=3wwPs8olDQnFNAKM0mbir9IUi2uVBRMv%2BLXuWO5m3%2FQ%3D&reserved=0>, STM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DSTM&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542651234&sdata=03hTp12%2BVIx05xDMbqR1pAgDHgtFOj4B%2FMmSQ0kM4Ss%3D&reserved=0>
     *   compiler feature: recompilation checking<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Drecompilation%2Bchecking&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542661228&sdata=VGFbg3W4FrV0Elt0yal1fuHEzMrl0seYSrJB86uL7S0%3D&reserved=0>, cpp<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dcpp&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542661228&sdata=QVE%2BH1ZpcdABUUdNf9lfDzmQchsqnlMdHuq9h1dzTac%3D&reserved=0>, debug information<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Ddebug%2Binformation&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542671225&sdata=HD210%2Fv%2F9QsAUh6RuDK%2B0CvhHcxEafEcRUaqdejbO9c%3D&reserved=0>, ~"cross compilation"

  1.  Labels that specify which bit of implementation a bug is likely caused by:

     *   compiler subsystem: driver<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Ddriver&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542671225&sdata=I4%2FvIcOu9XQBESTW9J58u%2BZUmPhlYrxiSifVQE3XP6A%3D&reserved=0>, simplifier<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dsimplifier&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542671225&sdata=oKHwUqY8JtylL1CQYQidTAEq%2FCLKGllbBt4I4e8d0q8%3D&reserved=0>, demand analysis<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Ddemand%2Banalysis&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542681218&sdata=dXUK2Y1FqYTsgTSj5OiWlrzy1CjCnltggtgGvNYJrAs%3D&reserved=0>, RTS<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DRTS&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542681218&sdata=b1vjG0iWDXAZIprdmk1Sra4%2BIv2O%2FvHnYkUwpNeP5Q4%3D&reserved=0>, LLVM backend<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3DLLVM%2Bbackend&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542691211&sdata=7%2F7M75p25Hf%2B%2BMkhBqmLcKQXeHf3sqYfhrA7X6635XY%3D&reserved=0>
     *   related GHC project: ghc-pkg<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dghc-pkg&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542691211&sdata=iw1Q4m2w1oIWJki3Oj%2BkZcxPfJ5%2B7OoSXAfHFm%2B9sKU%3D&reserved=0>, integer-simple<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dinteger-simple&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542701205&sdata=UykmdKWcFF84s4WCHhqrdnTvasTF%2FNhfTRHHEq1cvAY%3D&reserved=0>, nofib<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dnofib&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542701205&sdata=XKhjKKQm8cPr%2FH17cVR286flFjqeHN7%2BCFbA9mSR594%3D&reserved=0>, core libraries<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dcore%2Blibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542701205&sdata=XF5%2FuxOtOzxDhsmdc22MocpIbRjIR1YvoZsgIomDxoI%3D&reserved=0>, infrastructure<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dinfrastructure&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542711201&sdata=maj3%2F65DsfCplUQRsz4%2FSqyD8PFeRzY2%2BeHcKcS5F5s%3D&reserved=0>
     *   external project: haddock<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dhaddock&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542711201&sdata=x30e6tTiooeJ1Kgk4HHoJSajrN3ygjJU9JRc8N7JnRI%3D&reserved=0>, hadrian<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dhadrian&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542721194&sdata=QhtxxmeHbyW0t%2FE5ty0XkScnzsaSl6VQxPkaCG9ln4k%3D&reserved=0>

  1.  Labels that specify other attributes of a ticket: newcomer<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dnewcomer&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542721194&sdata=9qW1g47iJgd7Ho%2BpaLth2tQOzkFEXB5V%2F%2BHiCwzDIgY%3D&reserved=0>, backport request<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%3Flabel_name%3Dbackport%2Brequest&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542731188&sdata=OeMoDAIMhxbeJvpmCZLYE1cUq62%2FrCASs1ciFWLIBVw%3D&reserved=0>, ~"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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16458&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542731188&sdata=wD%2BR1MgdfBGtSkfoKNiMqfa4fWR150JXDdfrLp3Woe0%3D&reserved=0>.
You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fsent_notifications%2Ff4227f3ba709316eecfc29a99b446961%2Funsubscribe&data=02%7C01%7Csimonpj%40microsoft.com%7C6a2447979c854125a26a08d6abea2932%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636885419542741183&sdata=dkgnhLo%2FkxKugbYeqQr7dN2VWcpd398uplCn8DfpgG4%3D&reserved=0> from this thread or adjust your notification settings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190318/b409505f/attachment.html>

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 <rsx at bluewin.ch> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190318/43b5a9e0/attachment.sig>

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: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
References: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
Message-ID: <87sgvjlkgu.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190318/e6ec96b0/attachment.sig>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
 <915c0bf9-c2e4-0141-2a54-7e6bee35856d@well-typed.com>
Message-ID: <CABHktDVwguimL0ddibOEgUEwvtpoXbCTEOeZSmWhcM96NHpb5A@mail.gmail.com>

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 <alp at well-typed.com> 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 <arnaud.spiwack at tweag.io> <arnaud.spiwack at tweag.io> wrote:
>
> On Thu, Mar 14, 2019 at 7:20 PM Herbert Valerio Riedel <hvriedel at gmail.com> <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> <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 <your flags of choice>
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ./hadrian/build.sh -j<N> ...
> ...
>
> 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 <args> && 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/578bef9f/attachment.html>

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: <CAKFCL4WULAHnz40yo2a+ta9U-9sEG4D=3rufEjVrLrXj2WZRbA@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
 <CAKFCL4WULAHnz40yo2a+ta9U-9sEG4D=3rufEjVrLrXj2WZRbA@mail.gmail.com>
Message-ID: <CAH6fHQ=cotLOFWD0ug6G3HPY7OcdPDwxKZ+wA7LVYNzDnTcOHg@mail.gmail.com>

On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery <allbery.b at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/d0c22308/attachment.html>

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: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.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  <<EOF
| #INTEGER_LIBRARY   = integer-simple
| BUILD_DOCBOOK_HTML = NO
| BUILD_DOCBOOK_PDF  = NO
| BUILD_DOCBOOK_PS   = NO
| BUILD_MAN          = NO
| BUILD_PROF_LIBS    = NO
| BUILD_SPHINX_HTML  = NO
| BUILD_SPHINX_PDF   = NO
| DYNAMIC_BY_DEFAULT   = NO
| DYNAMIC_GHC_PROGRAMS = NO
| GhcLibWays         = v dyn p
| HADDOCK_DOCS       = NO
| HSCOLOUR_SRCS      = NO
| LATEX_DOCS         = NO
| V                  = 0
| EOF
|
| ./boot
| ./configure --prefix /opt/ghc/HEAD ...otherflags...
|
| # the usual targets I use
|
| make clean
| make distclean
| make all
| make install
| make sdist
| make binary-dist
`----

From lonetiger at gmail.com  Tue Mar 19 10:17:38 2019
From: lonetiger at gmail.com (Phyx)
Date: Tue, 19 Mar 2019 11:17:38 +0100
Subject: Discussion: Hadrian's defaults
In-Reply-To: <CAH6fHQ=cotLOFWD0ug6G3HPY7OcdPDwxKZ+wA7LVYNzDnTcOHg@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
 <CAKFCL4WULAHnz40yo2a+ta9U-9sEG4D=3rufEjVrLrXj2WZRbA@mail.gmail.com>
 <CAH6fHQ=cotLOFWD0ug6G3HPY7OcdPDwxKZ+wA7LVYNzDnTcOHg@mail.gmail.com>
Message-ID: <CABHktDXxBuBEuXK-MmzO0LMWFS+CGw8G9RySDbEU6SQhd8Kdww@mail.gmail.com>

> 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 <arnaud.spiwack at tweag.io> wrote:

> On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery <allbery.b at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/e1641ab1/attachment.html>

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: <CAKe9RRGWCc=qrSxSqW15yTqqvL63SuWUKU3E4W1pXgWctepQXg@mail.gmail.com>
 <87sgvjlkgu.fsf@smart-cactus.org>
Message-ID: <CAKe9RRFVj5mc50P9dFoHT8c6w6OaFe2Ls7R3CCimgRhU8KfAFQ@mail.gmail.com>

On Mon, Mar 18, 2019 at 9:30 PM Ben Gamari <ben at smart-cactus.org> wrote:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/6ce9be65/attachment.html>

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: <CAH6fHQ=cotLOFWD0ug6G3HPY7OcdPDwxKZ+wA7LVYNzDnTcOHg@mail.gmail.com>
References: <CAH6fHQ=UTG07-nAJXBK89Ku00h4U-jmUTZUS9z-mqwoA2AnWjw@mail.gmail.com>
 <CAOFsAruR6Y4=QZjKko5yoO+x-NZO0YOC7bEQVg56MqVDVrt8iQ@mail.gmail.com>
 <467D8932-019A-4909-BB88-72E10C65AFEB@gmail.com>
 <CAH6fHQ=Tqaw07eRDK_LrPcXfcdJETUdVsBQAZQOKX1eynh5kng@mail.gmail.com>
 <4E5FE704-9590-4FD3-A355-168429CB1040@gmail.com>
 <CAKFCL4WULAHnz40yo2a+ta9U-9sEG4D=3rufEjVrLrXj2WZRbA@mail.gmail.com>
 <CAH6fHQ=cotLOFWD0ug6G3HPY7OcdPDwxKZ+wA7LVYNzDnTcOHg@mail.gmail.com>
Message-ID: <CAKFCL4UgJM1qFRZ8A=qgu8zfR=ovOajDsrbQ_1kG-2zFPg3ZFQ@mail.gmail.com>

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 <arnaud.spiwack at tweag.io>
wrote:

> On Fri, Mar 15, 2019 at 4:52 PM Brandon Allbery <allbery.b at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/7cc2dbf4/attachment.html>

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)
<https://gitlab.haskell.org/ghc/ghc/issues/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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/686f3eec/attachment.html>

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: <CABHktDWYwZN6GE33YT02SWFuOG+tSEy6Pjy-mJdZCTjHjiwR5A@mail.gmail.com>

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 <klebinger.andreas at gmx.at>
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)
> <https://gitlab.haskell.org/ghc/ghc/issues/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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/063e2b6b/attachment.html>

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: <CABHktDWYwZN6GE33YT02SWFuOG+tSEy6Pjy-mJdZCTjHjiwR5A@mail.gmail.com>
References: <5C912D7F.5040400@gmx.at>
 <CABHktDWYwZN6GE33YT02SWFuOG+tSEy6Pjy-mJdZCTjHjiwR5A@mail.gmail.com>
Message-ID: <877eculki9.fsf@smart-cactus.org>

Phyx <lonetiger at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/7b46fcf9/attachment.sig>

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>
 <CABHktDWYwZN6GE33YT02SWFuOG+tSEy6Pjy-mJdZCTjHjiwR5A@mail.gmail.com>
 <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 <https://stackage.org/lts-13.13>,
published 3 days ago
         * LTS 13.11 for GHC 8.6.3 <https://stackage.org/lts-13.11>,
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<lonetiger at gmail.com>  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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/42e08bde/attachment.html>

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: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>

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: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>
References: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>
Message-ID: <CA+h2LzkJ5TuWpK+1QQto2F0PYLGrsrk6BoA2LHX6iLnSSsbCfA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190322/29996434/attachment.html>

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: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>
References: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>
Message-ID: <87r2aykdvx.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190322/95e7fe8d/attachment.sig>

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: <CALuQ0m8YQ23QqTd3c2YZSFS-jL=3-UBa3Etn0jgMXuiMiAkhBA@mail.gmail.com>
 <87r2aykdvx.fsf@smart-cactus.org>
Message-ID: <87o962kc4r.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190322/f7a02299/attachment.sig>

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: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>

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: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
References: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
Message-ID: <87h8btk0iv.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190323/6bbdc030/attachment.sig>

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: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
 <87h8btk0iv.fsf@smart-cactus.org>
Message-ID: <87d0mhjl3e.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190323/2ca26977/attachment.sig>

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: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
 <87h8btk0iv.fsf@smart-cactus.org> <87d0mhjl3e.fsf@smart-cactus.org>
Message-ID: <CALuQ0m-jBzL8Pg+qXtJdAqXcGQvtrUc3TUgSRgZU0Hb61A51Sw@mail.gmail.com>

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 <ben at smart-cactus.org> wrote:
>
> Ben Gamari <ben at smart-cactus.org> writes:
>
> > Matthew Pickering <matthewtpickering at gmail.com> 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: <CALuQ0m-jBzL8Pg+qXtJdAqXcGQvtrUc3TUgSRgZU0Hb61A51Sw@mail.gmail.com>
References: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
 <87h8btk0iv.fsf@smart-cactus.org> <87d0mhjl3e.fsf@smart-cactus.org>
 <CALuQ0m-jBzL8Pg+qXtJdAqXcGQvtrUc3TUgSRgZU0Hb61A51Sw@mail.gmail.com>
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 <matthewtpickering at gmail.com> 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 <ben at smart-cactus.org>
>wrote:
>>
>> Ben Gamari <ben at smart-cactus.org> writes:
>>
>> > Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190324/9988c8b0/attachment.html>

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: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
References: <CALuQ0m-xLWeOHgcnUNfDBMsZqo=csaE6tA4bxRxobMqLBOWdpQ@mail.gmail.com>
Message-ID: <87a7hikjat.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190325/7e531e79/attachment.sig>

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: <CADdQpRBQm8dp+6HGDX-2x7E0LRD9Z1ky7c9GNLaxuJY1X3tXsA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190325/c1264f54/attachment.html>

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: <CADdQpRBQm8dp+6HGDX-2x7E0LRD9Z1ky7c9GNLaxuJY1X3tXsA@mail.gmail.com>
References: <CADdQpRBQm8dp+6HGDX-2x7E0LRD9Z1ky7c9GNLaxuJY1X3tXsA@mail.gmail.com>
Message-ID: <877ecmkc0z.fsf@smart-cactus.org>

Ryan Scott <ryan.gl.scott at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190325/a5cf4b45/attachment.sig>

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 <https://gitlab.haskell.org/ghc/ghc/issues/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 <https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/32af95e0/attachment.html>

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: <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>

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 <ndmitchell at gmail.com>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org>
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<https://gitlab.haskell.org/ghc/ghc/issues/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<https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/d76831b7/attachment.html>

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: <DB7PR83MB0298CA2C1DEC3063D05A63DBAD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <ghc-devs-bounces at haskell.org> On Behalf Of David Eichmann
Sent: 27 March 2019 11:54
To: Neil Mitchell <ndmitchell at gmail.com>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16295&data=02%7C01%7Csimonpj%40microsoft.com%7C1638b8b55cbf4ae2862a08d6b2aaeba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636892844511642155&sdata=RPU0zZ4fLhvEp4yrBuGVO7ZGtTASGL80qctso%2BcBrgU%3D&reserved=0>. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16400%23note_188901&data=02%7C01%7Csimonpj%40microsoft.com%7C1638b8b55cbf4ae2862a08d6b2aaeba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636892844511652163&sdata=G8kxo%2F7D%2Fx2TQHHfzZqcMmh2GyJVmqe%2FQ8kNY8YNHI8%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7C1638b8b55cbf4ae2862a08d6b2aaeba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636892844511662172&sdata=BIQVoE%2FaLNjUWBH4bYcNpvFxEESb56bsJ2d8dBDt0rk%3D&reserved=0>



Registered in England & Wales, OC335890

118 Wymering Mansions, Wymering Road, London W9 2NF, England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/c97f7c25/attachment.html>

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: <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
Message-ID: <DB7PR83MB0298EBE7C5C720BC055AAE84AD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <ghc-devs-bounces at haskell.org> On Behalf Of Andrey Mokhov
Sent: 27 March 2019 15:06
To: David Eichmann <davide at well-typed.com>; Neil Mitchell <ndmitchell at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
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 <ndmitchell at gmail.com<mailto:ndmitchell at gmail.com>>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk<mailto:andrey.mokhov at newcastle.ac.uk>>; GHC developers <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
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<https://gitlab.haskell.org/ghc/ghc/issues/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<https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/2c3ea1f7/attachment-0001.html>

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: <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
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 <ndmitchell at gmail.com>; Andrey Mokhov 
> <andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org>
> *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 
> <https://gitlab.haskell.org/ghc/ghc/issues/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 <https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/707c8ebb/attachment.html>

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>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
 <9fe7f072-98a0-9664-292c-c5056d3f3770@well-typed.com>
Message-ID: <CALuQ0m-5qZ_hyvFg48-A1mErghJp-yHOyrO=N2oXZ0x4wUUCJA@mail.gmail.com>

I also remember this discussion.. I think it was in the context of
optimising hadrian.

On Wed, 27 Mar 2019, 15:56 Alp Mestanogullari, <alp at well-typed.com> 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
> <davide at well-typed.com>]
> *Sent:* 27 March 2019 12:54
> *To:* Neil Mitchell <ndmitchell at gmail.com> <ndmitchell at gmail.com>; Andrey
> Mokhov <andrey.mokhov at newcastle.ac.uk> <andrey.mokhov at newcastle.ac.uk>;
> GHC developers <ghc-devs at haskell.org> <ghc-devs at haskell.org>
> *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 <https://gitlab.haskell.org/ghc/ghc/issues/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
> <https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/d71bb62f/attachment.html>

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: <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
Message-ID: <c5b4f566-dcdb-e8e0-29c1-e19f72a69af2@well-typed.com>

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 <ndmitchell at gmail.com>; Andrey Mokhov 
> <andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org>
> *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 
> <https://gitlab.haskell.org/ghc/ghc/issues/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 <https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/1ba50cd1/attachment-0001.html>

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: <c5b4f566-dcdb-e8e0-29c1-e19f72a69af2@well-typed.com>
References: <9d76372c-fdda-9bc7-1576-996d2fec35d5@well-typed.com>
 <WM!82fac871caedc593d38686fc89c69ab6aeb0d16c7f59554eb00c47b851a75484e5f70ebe0ecae24b9642502da1f62555!@mailhub-mx1.ncl.ac.uk>
 <AM6PR0702MB3543F62446D096C3CB43301CA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!f3c8982d552de135efb1c28e8e283cef2157f3ab77a106123518378495fa136af7ea12c279d2c23ff4b6cec9301b7aa7!@mailhub-mx5.ncl.ac.uk>
 <c5b4f566-dcdb-e8e0-29c1-e19f72a69af2@well-typed.com>
Message-ID: <DB7PR83MB02981F8EEA94A1848A188D94AD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <ghc-devs-bounces at haskell.org> On Behalf Of David Eichmann
Sent: 27 March 2019 17:12
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Neil Mitchell <ndmitchell at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
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 <ndmitchell at gmail.com><mailto:ndmitchell at gmail.com>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk><mailto:andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16295&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618959820&sdata=BomxywLkHm7mriTubSnCql6YJDJBR96K1tQbskKBMn4%3D&reserved=0>. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16400%23note_188901&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618969820&sdata=Kmnd%2B8%2FATQBw0AfCTvvl7oix5syXbPAeV7h473t8H7E%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618979828&sdata=ZUSCHtfKiOsTYbS%2Bo%2FAuhSuXwtM5TKnzVPubJjZd6RI%3D&reserved=0>



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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618989837&sdata=QxSKBt9C1rO8AwS0C8%2FIPhK43naICuuJ8ebdIzaudnQ%3D&reserved=0>



Registered in England & Wales, OC335890

118 Wymering Mansions, Wymering Road, London W9 2NF, England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/5ff82170/attachment.html>

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: <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>

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 <simonpj at microsoft.com> 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 <ghc-devs-bounces at haskell.org> On Behalf Of David Eichmann
Sent: 27 March 2019 17:12
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Neil Mitchell <ndmitchell at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
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 <ndmitchell at gmail.com><mailto:ndmitchell at gmail.com>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk><mailto:andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16295&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618959820&sdata=BomxywLkHm7mriTubSnCql6YJDJBR96K1tQbskKBMn4%3D&reserved=0>. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16400%23note_188901&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618969820&sdata=Kmnd%2B8%2FATQBw0AfCTvvl7oix5syXbPAeV7h473t8H7E%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618979828&sdata=ZUSCHtfKiOsTYbS%2Bo%2FAuhSuXwtM5TKnzVPubJjZd6RI%3D&reserved=0>



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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618989837&sdata=QxSKBt9C1rO8AwS0C8%2FIPhK43naICuuJ8ebdIzaudnQ%3D&reserved=0>



Registered in England & Wales, OC335890

118 Wymering Mansions, Wymering Road, London W9 2NF, England

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/1ff5c15f/attachment-0001.html>

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: <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>
References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com>
 <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>
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 <simonpj at microsoft.com> 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 <ghc-devs-bounces at haskell.org> *On Behalf Of
>     *David Eichmann
>     *Sent:* 27 March 2019 17:12
>     *To:* Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Neil Mitchell
>     <ndmitchell at gmail.com>
>     *Cc:* GHC developers <ghc-devs at haskell.org>
>     *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 <ndmitchell at gmail.com>
>         <mailto:ndmitchell at gmail.com>; Andrey Mokhov
>         <andrey.mokhov at newcastle.ac.uk>
>         <mailto:andrey.mokhov at newcastle.ac.uk>; GHC developers
>         <ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org>
>         *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
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16295&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618959820&sdata=BomxywLkHm7mriTubSnCql6YJDJBR96K1tQbskKBMn4%3D&reserved=0>.
>         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
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16400%23note_188901&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618969820&sdata=Kmnd%2B8%2FATQBw0AfCTvvl7oix5syXbPAeV7h473t8H7E%3D&reserved=0>
>         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  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618979828&sdata=ZUSCHtfKiOsTYbS%2Bo%2FAuhSuXwtM5TKnzVPubJjZd6RI%3D&reserved=0>
>
>           
>
>         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  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cbd87a25e08f441fe763d08d6b2d76b25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893035618989837&sdata=QxSKBt9C1rO8AwS0C8%2FIPhK43naICuuJ8ebdIzaudnQ%3D&reserved=0>
>
>       
>
>     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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/8e2e02d9/attachment.html>

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>
 <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>
 <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com>
Message-ID: <DB7PR83MB0298E018CB22F68FE4C04426AD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>

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 <davide at well-typed.com>
Sent: 27 March 2019 18:04
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Simon Peyton Jones <simonpj at microsoft.com>
Cc: Neil Mitchell <ndmitchell at gmail.com>; GHC developers <ghc-devs at haskell.org>
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 <simonpj at microsoft.com><mailto:simonpj at microsoft.com> 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 <ghc-devs-bounces at haskell.org><mailto:ghc-devs-bounces at haskell.org> On Behalf Of David Eichmann
Sent: 27 March 2019 17:12
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk><mailto:andrey.mokhov at newcastle.ac.uk>; Neil Mitchell <ndmitchell at gmail.com><mailto:ndmitchell at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>
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 <ndmitchell at gmail.com><mailto:ndmitchell at gmail.com>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk><mailto:andrey.mokhov at newcastle.ac.uk>; GHC developers <ghc-devs at haskell.org><mailto:ghc-devs at haskell.org>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16295&data=02%7C01%7Csimonpj%40microsoft.com%7C5547e9d3f2ac46e99f7608d6b2de8965%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893066265056843&sdata=pTvdTMtM1%2B4d%2BxCVaR3K%2BV%2FtqZgD%2BWQLXee7f5q53dk%3D&reserved=0>. 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F16400%23note_188901&data=02%7C01%7Csimonpj%40microsoft.com%7C5547e9d3f2ac46e99f7608d6b2de8965%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893066265056843&sdata=tazaF1KhCrosPrJ8wMw6xsyCWVLSYjpFkxHj0DS8%2B8w%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7C5547e9d3f2ac46e99f7608d6b2de8965%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893066265066852&sdata=RXD5uoyg3KKQx3wosnw5%2FOe9ha5ePVlJcFxkT%2FvHR60%3D&reserved=0>



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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7C5547e9d3f2ac46e99f7608d6b2de8965%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893066265076861&sdata=l5qjZq%2BVm6DEHxedjMxoqSogpbaXF0mto6TIUzrI6dQ%3D&reserved=0>



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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-typed.com&data=02%7C01%7Csimonpj%40microsoft.com%7C5547e9d3f2ac46e99f7608d6b2de8965%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636893066265076861&sdata=l5qjZq%2BVm6DEHxedjMxoqSogpbaXF0mto6TIUzrI6dQ%3D&reserved=0>



Registered in England & Wales, OC335890

118 Wymering Mansions, Wymering Road, London W9 2NF, England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/548b514d/attachment-0001.html>

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: <WM!a1c4d40fb288163798b96d65233119b29e398c44f3f4e5fb5c1bf9862f2cad284edb5ac297b73f5d8892c0ef80908f76!@mailhub-mx2.ncl.ac.uk>
References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com>
 <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>
 <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com>
 <DB7PR83MB0298E018CB22F68FE4C04426AD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <WM!a1c4d40fb288163798b96d65233119b29e398c44f3f4e5fb5c1bf9862f2cad284edb5ac297b73f5d8892c0ef80908f76!@mailhub-mx2.ncl.ac.uk>
 <AM6PR0702MB3543349EFC9562AABD3C53AAA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
Message-ID: <WM!0b3b0c94b1458adff71145ff7c4572eede9d9a667e21026155330ecc4a2bb4195356bc43fdaa6a823db622e05c1eb6c1!@mailhub-mx3.ncl.ac.uk>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190327/f0f22998/attachment.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 (Matthew Pickering's message of "Thu, 28 Mar 2019 10:08:47 +0000")
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
Message-ID: <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>

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


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: <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
Message-ID: <CAH9BU=zjOeOMXHJz+W0T2a7wfLo1Rf-+g4UYOCk-owvYWOmnNA@mail.gmail.com>

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 <rae at richarde.dev> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/fd2a6863/attachment.html>

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: <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
Message-ID: <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>

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 <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

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: <CAH9BU=zjOeOMXHJz+W0T2a7wfLo1Rf-+g4UYOCk-owvYWOmnNA@mail.gmail.com>
 (Bryan Richter's message of "Thu, 28 Mar 2019 15:55:01 +0200")
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <CAH9BU=zjOeOMXHJz+W0T2a7wfLo1Rf-+g4UYOCk-owvYWOmnNA@mail.gmail.com>
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: <WM!0b3b0c94b1458adff71145ff7c4572eede9d9a667e21026155330ecc4a2bb4195356bc43fdaa6a823db622e05c1eb6c1!@mailhub-mx3.ncl.ac.uk>
References: <194693ed-caec-4bcc-89e1-8292e3640645@email.android.com>
 <WM!fcaf66c3f9a6e867789c229ec2af1d4101f05732a33eabc3a5c95d8b36cee4c35e14b55a562511dd8fec271e476652ad!@mailhub-mx4.ncl.ac.uk>
 <129f5def-394c-9245-3bcf-85644fe523bf@well-typed.com>
 <DB7PR83MB0298E018CB22F68FE4C04426AD580@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <WM!a1c4d40fb288163798b96d65233119b29e398c44f3f4e5fb5c1bf9862f2cad284edb5ac297b73f5d8892c0ef80908f76!@mailhub-mx2.ncl.ac.uk>
 <AM6PR0702MB3543349EFC9562AABD3C53AAA5580@AM6PR0702MB3543.eurprd07.prod.outlook.com>
 <WM!0b3b0c94b1458adff71145ff7c4572eede9d9a667e21026155330ecc4a2bb4195356bc43fdaa6a823db622e05c1eb6c1!@mailhub-mx3.ncl.ac.uk>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/42780b63/attachment.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <CAH9BU=zjOeOMXHJz+W0T2a7wfLo1Rf-+g4UYOCk-owvYWOmnNA@mail.gmail.com>
 <874l7njciy.fsf@gmail.com>
Message-ID: <19DC4B66-7CF4-4555-9035-06EA35074277@richarde.dev>



> On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel <hvriedel at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/7a79cea5/attachment.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <CAH9BU=zjOeOMXHJz+W0T2a7wfLo1Rf-+g4UYOCk-owvYWOmnNA@mail.gmail.com>
 <874l7njciy.fsf@gmail.com> <19DC4B66-7CF4-4555-9035-06EA35074277@richarde.dev>
Message-ID: <CAGK9nur+0ynaNcG5cD5h9pfCMcLaHQGzc5U8cM2vhthaqzyN4Q@mail.gmail.com>

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 <rae at richarde.dev> wrote:

>
>
> On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/45705a6f/attachment.html>

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: <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
Message-ID: <q7iulo$5iao$1@blaine.gmane.org>

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: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>

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
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
New York, NY 10007, USA
<https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C2%A0+%C2%A0+%C2%A0+New+York,+NY+10007,+USA&entry=gmail&source=g>
digitalasset.com <http://www.digitalasset.com/>

-- 
This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html 
<http://www.digitalasset.com/emaildisclaimer.html>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/0eb86c65/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3a858136/attachment.sig>

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: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
References: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
Message-ID: <87k1gij3n2.fsf@smart-cactus.org>

Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3904864a/attachment.sig>

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: <q7iulo$5iao$1@blaine.gmane.org>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
Message-ID: <CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com>

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 <spam at scientician.net>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3f549866/attachment-0001.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
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: <CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
 <CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com>
Message-ID: <e35b5219-e069-14fd-d2e4-5dc5ec0535d6@iohk.io>

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
> <spam at scientician.net <mailto:spam at scientician.net>> 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 <mailto: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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/c2f7a8b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/c2f7a8b6/attachment.sig>

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: <q7iulo$5iao$1@blaine.gmane.org>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
Message-ID: <CAHnGs++Mhu8hT-Ukxir=pgZESvidX3xgwP6rt44hqWaXvCdp+A@mail.gmail.com>

+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 <spam at scientician.net>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/4b52f568/attachment.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <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: <CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
 <CAGK9nuozbxwckb5htvtJ7mc1nB6h86jZkbMWuRKuCipaOtXs8Q@mail.gmail.com>
Message-ID: <CABHktDWQ5hQaKwwL25SPJQ1vDc=U=uuEK4HAJg4O_4Kog5hJdQ@mail.gmail.com>

> 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 <iavor.diatchki at gmail.com> 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 <spam at scientician.net>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3164b3ce/attachment.html>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
Message-ID: <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>



> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <hvriedel at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/3bccc3fb/attachment.html>

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: <CAHnGs++Mhu8hT-Ukxir=pgZESvidX3xgwP6rt44hqWaXvCdp+A@mail.gmail.com>
 (Michael Peyton Jones's message of "Thu, 28 Mar 2019 18:33:58 +0000")
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
 <CAHnGs++Mhu8hT-Ukxir=pgZESvidX3xgwP6rt44hqWaXvCdp+A@mail.gmail.com>
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: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
 <87k1gij3n2.fsf@smart-cactus.org>
Message-ID: <87ftr6iset.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/18b3f650/attachment.sig>

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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
 <CAHnGs++Mhu8hT-Ukxir=pgZESvidX3xgwP6rt44hqWaXvCdp+A@mail.gmail.com>
 <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: <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
 <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
Message-ID: <EA3A4A2E-99D4-4B0C-B2A1-EA67155045DB@gmail.com>


> El 28 mar 2019, a las 3:26 PM, Richard Eisenberg <rae at richarde.dev> 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: <EA3A4A2E-99D4-4B0C-B2A1-EA67155045DB@gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
 <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
 <EA3A4A2E-99D4-4B0C-B2A1-EA67155045DB@gmail.com>
Message-ID: <CAKFCL4Vc20qum7z5igiWX7fx9MSK7uLBr1PFH+5+rdWks3Jtcg@mail.gmail.com>

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 <amindfv at gmail.com> wrote:

>
> > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg <rae at richarde.dev>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190328/fd214f8d/attachment.html>

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: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
 <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org>
Message-ID: <CAMQQO3ms7i_NA3v5eWZ9nWTYd_NNFQg6OvHVf+itjSqkLhXkVQ@mail.gmail.com>

I'm still getting 500.

Ömer

Ben Gamari <ben at smart-cactus.org>, 29 Mar 2019 Cum, 00:46 tarihinde şunu yazdı:
>
> Ben Gamari <ben at smart-cactus.org> writes:
>
> > Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> 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: <CAMQQO3ms7i_NA3v5eWZ9nWTYd_NNFQg6OvHVf+itjSqkLhXkVQ@mail.gmail.com>
References: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
 <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org>
 <CAMQQO3ms7i_NA3v5eWZ9nWTYd_NNFQg6OvHVf+itjSqkLhXkVQ@mail.gmail.com>
Message-ID: <DB7PR83MB0298BC0A0F4513CB5FA49BF4AD5A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Yes, I'm getting 500 too.

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 29 March 2019 06:20
|  To: Ben Gamari <ben at smart-cactus.org>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  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: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <BDAA14BD-7CD6-42CC-9CAC-4760ADE5A326@richarde.dev>
 <bce51a7a-1a5e-251c-f07b-6fb401e93500@iki.fi>
 <q7iulo$5iao$1@blaine.gmane.org>
 <CAHnGs++Mhu8hT-Ukxir=pgZESvidX3xgwP6rt44hqWaXvCdp+A@mail.gmail.com>
 <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: <CAKFCL4Vc20qum7z5igiWX7fx9MSK7uLBr1PFH+5+rdWks3Jtcg@mail.gmail.com>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
 <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
 <EA3A4A2E-99D4-4B0C-B2A1-EA67155045DB@gmail.com>
 <CAKFCL4Vc20qum7z5igiWX7fx9MSK7uLBr1PFH+5+rdWks3Jtcg@mail.gmail.com>
Message-ID: <d87c71f8-9306-b952-a0b9-b8239d5e61e0@iki.fi>

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 <amindfv at gmail.com
> <mailto:amindfv at gmail.com>> wrote:
>
>
>     > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
>     <rae at richarde.dev> 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 <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> -- 
> brandon s allbery kf8nh
> allbery.b at gmail.com <mailto: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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190329/0039dcb0/attachment.sig>

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: <DB7PR83MB0298BC0A0F4513CB5FA49BF4AD5A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CAKe9RRHVtiMg6aAYupHys_NH+Y_1Z56ar7AA1zsqiHjta+SRJQ@mail.gmail.com>
 <87k1gij3n2.fsf@smart-cactus.org> <87ftr6iset.fsf@smart-cactus.org>
 <CAMQQO3ms7i_NA3v5eWZ9nWTYd_NNFQg6OvHVf+itjSqkLhXkVQ@mail.gmail.com>
 <DB7PR83MB0298BC0A0F4513CB5FA49BF4AD5A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
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 <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
> |  Agacan
> |  Sent: 29 March 2019 06:20
> |  To: Ben Gamari <ben at smart-cactus.org>
> |  Cc: GHC developers <ghc-devs at haskell.org>
> |  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: <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
 <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
Message-ID: <CAGK9nuqHDJY8PuxdAdFu8BWCBi+ndTgEcgLnMYxajv28iww+HA@mail.gmail.com>

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 <rae at richarde.dev> wrote:

>
>
> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190329/d2b364e6/attachment.html>

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: <d87c71f8-9306-b952-a0b9-b8239d5e61e0@iki.fi>
References: <CALuQ0m-B3dsnbjoNr_FY-hv7snEKsLz-FWv8gQ30CUk1KtnOUw@mail.gmail.com>
 <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com>
 <B1958EAD-58C5-45D2-8FD6-FFA56164AC3E@richarde.dev>
 <EA3A4A2E-99D4-4B0C-B2A1-EA67155045DB@gmail.com>
 <CAKFCL4Vc20qum7z5igiWX7fx9MSK7uLBr1PFH+5+rdWks3Jtcg@mail.gmail.com>
 <d87c71f8-9306-b952-a0b9-b8239d5e61e0@iki.fi>
Message-ID: <CAKFCL4W16P16+FnS8j6vw=p=fJ+Djv8vANBawhCHPeby46qp2g@mail.gmail.com>

Nix instead of system, but roughly yes.

On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus <oleg.grenrus at iki.fi> 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 <amindfv at gmail.com
> > <mailto:amindfv at gmail.com>> wrote:
> >
> >
> >     > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg
> >     <rae at richarde.dev> 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 <mailto:ghc-devs at haskell.org>
> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > --
> > brandon s allbery kf8nh
> > allbery.b at gmail.com <mailto: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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190329/83043812/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190329/86fd45bd/attachment.sig>

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: <CAAJHNPBER0f+eB=r-OMH9=Wj-1ZncN8MQR7m7tmh3vGnfwgKXQ@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190330/b2b8ffd8/attachment.html>

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: <CAAJHNPBER0f+eB=r-OMH9=Wj-1ZncN8MQR7m7tmh3vGnfwgKXQ@mail.gmail.com>
References: <CAAJHNPBER0f+eB=r-OMH9=Wj-1ZncN8MQR7m7tmh3vGnfwgKXQ@mail.gmail.com>
Message-ID: <CAAJHNPCryso_KF9rXwKBK1Bt2WJs3yX7aJfgGG3sqkHqqEUysQ@mail.gmail.com>

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 <chrisdone at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190330/cef4f274/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190330/a64858d4/attachment.sig>

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: <CAPKAvQV-U9DmOAfsn9oYk2a_wO8du4RWWd3bXyYWCzD=amQbsg@mail.gmail.com>
 <87sgwkwart.fsf@smart-cactus.org>
Message-ID: <CABHktDUX6ppJn1MUoP3rtxPtmbrJiF8t7iQm97YuiV7Oukpm=Q@mail.gmail.com>

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 <ben at smart-cactus.org> wrote:

> Artem Pelenitsyn <a.pelenitsyn at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/1ca5443f/attachment.html>

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 <ben at well-typed.com> 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: <CAPB_NvyveDVjP1afsPYAmWqTV+sT0NswCfcYi00t4eQ=2m6kmA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/0478c490/attachment.html>

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: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>

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: <CABHktDUX6ppJn1MUoP3rtxPtmbrJiF8t7iQm97YuiV7Oukpm=Q@mail.gmail.com>
References: <CAPKAvQV-U9DmOAfsn9oYk2a_wO8du4RWWd3bXyYWCzD=amQbsg@mail.gmail.com>
 <87sgwkwart.fsf@smart-cactus.org>
 <CABHktDUX6ppJn1MUoP3rtxPtmbrJiF8t7iQm97YuiV7Oukpm=Q@mail.gmail.com>
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 <lonetiger at gmail.com>:
> 
> 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 <ben at smart-cactus.org <mailto:ben at smart-cactus.org>> wrote:
> Artem Pelenitsyn <a.pelenitsyn at gmail.com <mailto:a.pelenitsyn at gmail.com>> 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 <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/b2285ed5/attachment.html>

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: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
References: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
Message-ID: <CAPB_NvwX94dExUc8JktgZtNJCOmvuazhuZ0EGVzqtAX15AkydA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/253b81e9/attachment.html>

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: <CAPKAvQV-U9DmOAfsn9oYk2a_wO8du4RWWd3bXyYWCzD=amQbsg@mail.gmail.com>
 <87sgwkwart.fsf@smart-cactus.org>
 <CABHktDUX6ppJn1MUoP3rtxPtmbrJiF8t7iQm97YuiV7Oukpm=Q@mail.gmail.com>
 <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org>
Message-ID: <87wokfgjxz.fsf@smart-cactus.org>

Manuel M T Chakravarty <chak at justtesting.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/e2a4d62b/attachment.sig>

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: <CAPB_NvwX94dExUc8JktgZtNJCOmvuazhuZ0EGVzqtAX15AkydA@mail.gmail.com>
References: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
 <CAPB_NvwX94dExUc8JktgZtNJCOmvuazhuZ0EGVzqtAX15AkydA@mail.gmail.com>
Message-ID: <CAMQQO3kEmg5Wf+LKWhu7rZNkuALatbxQsn3v1tXDKv44SjSx3g@mail.gmail.com>

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 <takenobu.hs at gmail.com>, 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: <CAPKAvQV-U9DmOAfsn9oYk2a_wO8du4RWWd3bXyYWCzD=amQbsg@mail.gmail.com>
 <87sgwkwart.fsf@smart-cactus.org>
 <CABHktDUX6ppJn1MUoP3rtxPtmbrJiF8t7iQm97YuiV7Oukpm=Q@mail.gmail.com>
 <8B4CCB2E-F1BC-439F-A0D0-3857A4D3BD9A@justtesting.org>
 <87wokfgjxz.fsf@smart-cactus.org>
Message-ID: <C498681A-6930-48B7-B623-DD7D5D527C53@justtesting.org>

Thanks!
Manuel

> Am 31.03.2019 um 17:09 schrieb Ben Gamari <ben at well-typed.com>:
> 
> Manuel M T Chakravarty <chak at justtesting.org> 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: <CAMQQO3kEmg5Wf+LKWhu7rZNkuALatbxQsn3v1tXDKv44SjSx3g@mail.gmail.com>
References: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
 <CAPB_NvwX94dExUc8JktgZtNJCOmvuazhuZ0EGVzqtAX15AkydA@mail.gmail.com>
 <CAMQQO3kEmg5Wf+LKWhu7rZNkuALatbxQsn3v1tXDKv44SjSx3g@mail.gmail.com>
Message-ID: <05957AA0-7548-40FA-AB9C-DBE39ADCD04D@smart-cactus.org>

On March 31, 2019 12:20:22 PM EDT, "Ömer Sinan Ağacan" <omeragacan at gmail.com> 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 <takenobu.hs at gmail.com>, 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: <CAPB_NvyveDVjP1afsPYAmWqTV+sT0NswCfcYi00t4eQ=2m6kmA@mail.gmail.com>
References: <87zhpbhnfh.fsf@smart-cactus.org>
 <CAPB_NvyveDVjP1afsPYAmWqTV+sT0NswCfcYi00t4eQ=2m6kmA@mail.gmail.com>
Message-ID: <87tvfjgc84.fsf@smart-cactus.org>

Takenobu Tani <takenobu.hs at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/903534fd/attachment.sig>

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: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
References: <CAMQQO3kDJbGgUr3-ZcaGqNGaJqK5-o4=fnCLSq4nY24rJbjAXw@mail.gmail.com>
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: <c699d3c994d3152ddcc604c67e3203d7cee381fb.camel@joachim-breitner.de>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190331/d3d26607/attachment.sig>