Re: Hadrian questions
In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too. Maybe I'm not really on the devel2 flavor? > On Jan 24, 2019, at 11:02 PM, Richard Eisenberg wrote: > > As suggested, I'm trying out Hadrian. I have a few questions. > > - After building GHC the first time, I often go into the /ghc directory and > then do `make 2` to build just the stage-2 compiler. Is that now the same as > `build --freeze1`? It would seem not (I haven't tested), because running > `make 2` builds only the compiler, not the libraries. Can this workflow be > replicated in Hadrian? > > - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. > But I see build artifacts during compilation of stage-2 that have dyn_o and > p_o extensions. I don't want these. Have I done something wrong? Or are these > artifacts now necessary? > > - I have quite a few ghc directories. What are the dependencies of Hadrian so > that I can install these into my global package database and avoiding > rebuilding them for each ghc tree? (Please don't tell me that the global > package database is bad for my health. I know that, and I know why, but it's > still terribly convenient, and I'm happy to pay the occasional price for that > convenience.) > > I'm sure I'll have more questions. > > Thanks! > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Hadrian questions
As suggested, I'm trying out Hadrian. I have a few questions. - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make 2` builds only the compiler, not the libraries. Can this workflow be replicated in Hadrian? - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs file. But I see build artifacts during compilation of stage-2 that have dyn_o and p_o extensions. I don't want these. Have I done something wrong? Or are these artifacts now necessary? - I have quite a few ghc directories. What are the dependencies of Hadrian so that I can install these into my global package database and avoiding rebuilding them for each ghc tree? (Please don't tell me that the global package database is bad for my health. I know that, and I know why, but it's still terribly convenient, and I'm happy to pay the occasional price for that convenience.) I'm sure I'll have more questions. Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[ANNOUNCE] You should try Hadrian
Dear GHC developers, Summary: You should try to use Hadrian as the GHC build system, because it will (hopefully!) become the default around GHC 8.8. What is Hadrian and how can I try it? = Hadrian is a new build system for GHC written in Haskell. It lives in the directory "hadrian" in the GHC tree, and we have been actively developing it in the past year to reach feature and correctness parity with the existing Make-based build system. While we haven't quite reached this goal (more on this below), Hadrian is already working well and we run Hadrian jobs alongside the Make ones in our CI pipelines since the recent move to GitLab. At this point, we would like to encourage everyone to try using Hadrian for their usual GHC development tasks. Hadrian's documentation resides in GHC's source tree, and below are the documents you will be most interested in: *https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md: The root of Hadrian's documentation. It explains the basics and points to more specific documents where appropriate. *https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/make.md: A cheatsheet-style document for GHC developers used to the Make build system (that is, most/all of you), showing equivalent Make/Hadrian commands for many tasks. * https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md: A description of the "user settings" mechanism in Hadrian, which is where you can customise the build flavour, choose the packages to build, add file/package/platform-specific command line flags, etc. * https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md: A description of the "test" rule and all the options it supports. The documentation can surely be improved, so please do not hesitate to send us feedback and suggestions here, or even better on Trac: make sure you choose the component "Build System (Hadrian)" when creating a new ticket. You need Hadrian Hadrian is new, requires time to learn, and still has rough edges, but it has been developed to make your lives better. Here are a few advantages of Hadrian over the Make-based build system: 1) Hadrian is more reliable. Hadrian can capture build dependencies more accurately, which means you rarely (if ever) need to do a clean rebuild. 2) Hadrian is faster. Hadrian is faster for two reasons: (i) more accurate build dependencies, (ii) tracking of file contents instead of file modification times. Both allow you to avoid a lot of unnecessary rebuilds. Building Hadrian itself may take a while but needs to be done only once. 3) Hadrian is easier to understand and modify. You no longer need to deal with Make's global namespace of mutable string variables. Hadrian is written in the language you love; it has modules, types and pure functions. If you come across a situation where Hadrian is worse than the Make build system in any of the above aspects, this is a bug and you should report it. Helping Hadrian === The best way to help is to try Hadrian, and let us know how it goes, what doesn't work, what's missing for you, what you think should be easier, and so on. Below is a list of known issues that we are in the process of fixing or that we will be tackling soon: *Stage 2 GHC should be dynamically linked most of the time, but it never is, currently. See https://ghc.haskell.org/trac/ghc/ticket/15837 *There are about a dozen of failing tests in the GHC testsuite, some related to #15837. *Binary distributions haven't been thoroughly tested on many platforms (only some Linux flavours). There will definitely be some issues here. For example, the binary distribution rule currently fails on Windows: https://ghc.haskell.org/trac/ghc/ticket/16073. *There is no "validate" rule yet, only "test", but we have all the pieces to make this happen and it has a very high priority. *There are issues with building cross compilers: see https://ghc.haskell.org/trac/ghc/ticket/16051. We are likely missing some features compared to the Make build system, but none of them should take a lot of time to implement at this point. If you spot one, let us know! We'll do our best to implement it (or help you do it) as soon as we can. It is useful to look at the existing Hadrian tickets before submitting new ones, to make sure that the issue or idea that you would like to talk about hasn't been brought up yet: https://ghc.haskell.org/trac/ghc/query?status=!closed=Build+System+(Hadrian). Of course, we welcome your code contributions too! Several GHC developers have a good understanding of Hadrian codebase and will be able to help you. To find their names, have a look at the list of recent Hadrian commits: https://gitlab.haskell.org/ghc/ghc/commits/master/hadrian. As you can see, Hadrian is actively developed by many people, and we hope
Re: "resource exhausted" in CI
Um, also this seems to have jumped threads; the subject of this message was a different issue, about disk space. Is that part of the confusion? On Thu, Jan 24, 2019 at 5:53 PM Brandon Allbery wrote: > Rebase is more or less stashing and removing all local commits, upgrading > the underlying branch to current, then re-applying the local commits. This > changes the commit hashes for any re-applied commit that lands on a change > to the underlying branch, meaning that old commit hashes can be invalid > afterward. > > (This is also why force-pushing causes problems, since this is only > visible in a local tree *unless* force-pushed upstream, meaning now those > changed/deleted commits affect anyone else who has checked out that > upstream branch. The normal process of upstreaming commits can't expose > local changes like that, since it all goes upstream as a group and becomes > a permanent part of the branch's history. Unless someone force-pushes the > branch afterward, forcibly overwriting that history with a different one > and leaving anyoneelse who'd checked out the branch with dangling commits > that no longer exist.) > > Here, CI is making a copy of someone's branch and testing each commit in > turn to ensure consistency between multiple branches that touch the same > code, whose commits may end up interleaved. If the branch is rebased or > force-pushed during that testing, intermediate commits may become invalid > as above and CI would need to start over with a new list of commits. > > On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > >> | Ah, yes -- I did push a rebase. OK: good to know that this is expected >> | behavior after rebasing (makes sense). >> >> Does not make sense (yet) to me. >> >> Can someone explain (and perhaps document) the workflow here? >> >> Simon >> >> | -Original Message- >> | From: ghc-devs On Behalf Of Richard >> | Eisenberg >> | Sent: 24 January 2019 19:22 >> | To: Ben Gamari >> | Cc: GHC developers >> | Subject: Re: "resource exhausted" in CI >> | >> | Ah, yes -- I did push a rebase. OK: good to know that this is expected >> | behavior after rebasing (makes sense). >> | >> | Thanks, >> | Richard >> | >> | > On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote: >> | > >> | > Richard Eisenberg writes: >> | > >> | >> Something is awry: >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha >> | skell.org%2Frae%2Fghc%2F- >> | %2Fjobs%2F16908data=02%7C01%7Csimonpj%40microsoft.com >> %7C375c6daea23444 >> | >> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 >> | >> 1260172sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D >> | reserved=0 never got off the ground. >> | >> >> | > It is possible that you pushed a rebase? This error generally means >> that >> | > the commit is no longer accessible which may happen when you push a >> | > rebase. >> | > >> | > I believe I cited the job for the current version of the patch [1] in >> my >> | > previous email. Note that the commit SHA is different between [1] and >> | > the job you cited. >> | > >> | > Cheers, >> | > >> | > - Ben >> | > >> | > >> | > [1] >> | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha >> | skell.org%2Frae%2Fghc%2F- >> | %2Fjobs%2F16913data=02%7C01%7Csimonpj%40microsoft.com >> %7C375c6daea23444 >> | >> 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 >> | >> 1260172sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3Dre >> | served=0 >> | >> | ___ >> | ghc-devs mailing list >> | ghc-devs@haskell.org >> | >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske >> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- >> | devsdata=02%7C01%7Csimonpj%40microsoft.com >> %7C375c6daea234447c3d2808d68 >> | >> 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172 >> | >> ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3Dreserved=0 >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > brandon s allbery kf8nh > allber...@gmail.com > -- brandon s allbery kf8nh allber...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: "resource exhausted" in CI
Rebase is more or less stashing and removing all local commits, upgrading the underlying branch to current, then re-applying the local commits. This changes the commit hashes for any re-applied commit that lands on a change to the underlying branch, meaning that old commit hashes can be invalid afterward. (This is also why force-pushing causes problems, since this is only visible in a local tree *unless* force-pushed upstream, meaning now those changed/deleted commits affect anyone else who has checked out that upstream branch. The normal process of upstreaming commits can't expose local changes like that, since it all goes upstream as a group and becomes a permanent part of the branch's history. Unless someone force-pushes the branch afterward, forcibly overwriting that history with a different one and leaving anyoneelse who'd checked out the branch with dangling commits that no longer exist.) Here, CI is making a copy of someone's branch and testing each commit in turn to ensure consistency between multiple branches that touch the same code, whose commits may end up interleaved. If the branch is rebased or force-pushed during that testing, intermediate commits may become invalid as above and CI would need to start over with a new list of commits. On Thu, Jan 24, 2019 at 5:43 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > | Ah, yes -- I did push a rebase. OK: good to know that this is expected > | behavior after rebasing (makes sense). > > Does not make sense (yet) to me. > > Can someone explain (and perhaps document) the workflow here? > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Richard > | Eisenberg > | Sent: 24 January 2019 19:22 > | To: Ben Gamari > | Cc: GHC developers > | Subject: Re: "resource exhausted" in CI > | > | Ah, yes -- I did push a rebase. OK: good to know that this is expected > | behavior after rebasing (makes sense). > | > | Thanks, > | Richard > | > | > On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote: > | > > | > Richard Eisenberg writes: > | > > | >> Something is awry: > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha > | skell.org%2Frae%2Fghc%2F- > | %2Fjobs%2F16908data=02%7C01%7Csimonpj%40microsoft.com > %7C375c6daea23444 > | > 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 > | > 1260172sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D > | reserved=0 never got off the ground. > | >> > | > It is possible that you pushed a rebase? This error generally means > that > | > the commit is no longer accessible which may happen when you push a > | > rebase. > | > > | > I believe I cited the job for the current version of the patch [1] in > my > | > previous email. Note that the commit SHA is different between [1] and > | > the job you cited. > | > > | > Cheers, > | > > | > - Ben > | > > | > > | > [1] > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha > | skell.org%2Frae%2Fghc%2F- > | %2Fjobs%2F16913data=02%7C01%7Csimonpj%40microsoft.com > %7C375c6daea23444 > | > 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 > | > 1260172sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3Dre > | served=0 > | > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devsdata=02%7C01%7Csimonpj%40microsoft.com > %7C375c6daea234447c3d2808d68 > | > 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172 > | > ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3Dreserved=0 > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allber...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: "resource exhausted" in CI
| Ah, yes -- I did push a rebase. OK: good to know that this is expected | behavior after rebasing (makes sense). Does not make sense (yet) to me. Can someone explain (and perhaps document) the workflow here? Simon | -Original Message- | From: ghc-devs On Behalf Of Richard | Eisenberg | Sent: 24 January 2019 19:22 | To: Ben Gamari | Cc: GHC developers | Subject: Re: "resource exhausted" in CI | | Ah, yes -- I did push a rebase. OK: good to know that this is expected | behavior after rebasing (makes sense). | | Thanks, | Richard | | > On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote: | > | > Richard Eisenberg writes: | > | >> Something is awry: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha | skell.org%2Frae%2Fghc%2F- | %2Fjobs%2F16908data=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea23444 | 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 | 1260172sdata=8OYI5PAk7B6P%2B%2BoJbqgeqPbTR%2BMH6F8Wm34ThdBhRL0%3D | reserved=0 never got off the ground. | >> | > It is possible that you pushed a rebase? This error generally means that | > the commit is no longer accessible which may happen when you push a | > rebase. | > | > I believe I cited the job for the current version of the patch [1] in my | > previous email. Note that the commit SHA is different between [1] and | > the job you cited. | > | > Cheers, | > | > - Ben | > | > | > [1] | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha | skell.org%2Frae%2Fghc%2F- | %2Fjobs%2F16913data=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea23444 | 7c3d2808d682314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683954552 | 1260172sdata=wM0hlN60tQmsDtsXS%2BIqLzeAqhgK6RmUoEDzYG2b%2FhI%3Dre | served=0 | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devsdata=02%7C01%7Csimonpj%40microsoft.com%7C375c6daea234447c3d2808d68 | 2314861%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636839545521260172 | ;sdata=R2PHyXMyWDG4mmusi1KLmklGR0b%2FXAE%2BNp%2BwS4ZOmp8%3Dreserved=0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: "resource exhausted" in CI
Ah, yes -- I did push a rebase. OK: good to know that this is expected behavior after rebasing (makes sense). Thanks, Richard > On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got >> off the ground. >> > It is possible that you pushed a rebase? This error generally means that > the commit is no longer accessible which may happen when you push a > rebase. > > I believe I cited the job for the current version of the patch [1] in my > previous email. Note that the commit SHA is different between [1] and > the job you cited. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: access failed CI artifacts
Richard Eisenberg writes: > A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807 > > The failures are just some output changes. I could delicately use the > log to extract the changes and commit them, but it would be better to > have direct access to, say, the *.run.stderr files and then commit > those. Is this possible? Note that I do not have a build of this tree > locally, as it's the result of a rebase that affected the output. Of > course, I could build locally, but it would be nice to skip that step. > Unfortunately it's not possible to gain access to the resulting stderr files; the working directory is blown up at the end of the build. However, one thing I've been wanting to do for quite some time is to teach the testsuite driver to report the actual test output in the JUnit file it produces. With this you could in principle grab in the JUnit file (which is one of the artifacts emitted by the job) and reliably scrape the output from it. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: "resource exhausted" in CI
Richard Eisenberg writes: > Something is awry: https://gitlab.haskell.org/rae/ghc/-/jobs/16908 never got > off the ground. > It is possible that you pushed a rebase? This error generally means that the commit is no longer accessible which may happen when you push a rebase. I believe I cited the job for the current version of the patch [1] in my previous email. Note that the commit SHA is different between [1] and the job you cited. Cheers, - Ben [1] https://gitlab.haskell.org/rae/ghc/-/jobs/16913 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
access failed CI artifacts
A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807 The failures are just some output changes. I could delicately use the log to extract the changes and commit them, but it would be better to have direct access to, say, the *.run.stderr files and then commit those. Is this possible? Note that I do not have a build of this tree locally, as it's the result of a rebase that affected the output. Of course, I could build locally, but it would be nice to skip that step. Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
"resource exhausted" in CI
Hi Ben, The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says: HC [stage 1] compiler/stage2/build/TcForeign.o HC [stage 1] compiler/stage2/build/TcRules.o /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device) compiler/ghc.mk:445: recipe for target 'compiler/stage2/build/TcTyClsDecls.o' failed make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1 make[1]: *** Waiting for unfinished jobs Is there a way to avoid this? Or should I just restart the CI? And what does Marge think of it all? (As in, if I ask her to take another spin, will she do so on the same commit?) Thanks, Richard___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why are nested brackets disallowed?
I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety. I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile. One question: how would staging work between nesting levels of brackets? Richard > On Jan 24, 2019, at 12:42 PM, Ben Gamari wrote: > > Matthew Pickering writes: > >> There is a check in `RnSplice` which errors on the following program >> with nested brackets. >> > It might be good to explicitly include Geoff Mainland in this thread. > I'm not sure he'll see it otherwise. > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why are nested brackets disallowed?
Matthew Pickering writes: > There is a check in `RnSplice` which errors on the following program > with nested brackets. > It might be good to explicitly include Geoff Mainland in this thread. I'm not sure he'll see it otherwise. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Groups and projects
Simon Peyton Jones via ghc-devs writes:
>> Alright, I believe I have found the issue: you are a member of
>> the GHC group and GitLab's default notification behavior is that
>> you will receive notifications for all events of repositories in
>> groups to which you belong.
>
> OK thanks, that's helpful.
>
> When you say "repository" could you also have said "project". That is,
> are "projects" and "repositories" in 1-1 correspondence?
>
Yes, exactly. A project has a git repository, a wiki, an issue tracker
(although this is currently disabled in the case of the ghc project),
and can accept pull requests. I have been guilty of using the words
"repository" and "project" interchangeably, which likely doesn't make
things any clearer.
> So, to understand the semantics, you can belong to
>
> * A project.
> * A group
>
> What's the difference? The group seems to be "Glasgow Haskell
> Compiler"; the project seems to be "Glasgow Haskell Compiler / GHC".
> Does that imply that
>
> * every project is part of a group; but
> * a group may have many projects?
>
Almost. Projects have owners. An owner may be either a group or a user.
For instance,
* https://gitlab.haskell.org/ghc/ghc is a project (named `ghc`)
belonging to the `ghc` group.
* https://gitlab.haskell.org/bgamari/ghc is a project belonging to the
`bgamari` user.
Groups may nest. https://gitlab.haskell.org/ghc/packages is a subgroup
(named `packages`) of the `ghc` group.
https://gitlab.haskell.org/ghc/packages/haskeline is a project
(`haskeline`) owned by that group.
Users can be "members" of both groups and projects. There are a few
flavours of membership ("reporter", "developer", "maintainer", and
"owner") which all imply different sets of permissions (documented here
[1]). If a user is a member of a group then they are granted permissions
to all projects of that group (and its subgroups).
As you discovered, membership also implies a few things about the
notifications you will receive about a project or group of projects.
[1] https://docs.gitlab.com/ee/user/permissions.html
> Or maybe a project can be part of more than one group?
>
> The "Custom settings" on a project seem to be identical to the "custom
> settings" for a group. If Gitlab is deciding whether to send me a
> notification N, is it clear whether it's a "project notification" or a
> "group notification"? If so, then it can consult the appropriate
> settings; but if not, it's not clear.
>
> Sorry for all these questions. It's astonishingly common for large
> software systems to describe the surface knobs without describing the
> underlying model that makes sense of all those knobs!
>
Yes, this is quite true. I do hope I could help clear up the fog. Do ask
if things are still hazy.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Why are nested brackets disallowed?
There is a check in `RnSplice` which errors on the following program with nested brackets. ``` prog = [| [| True |] |] T.hs:4:11: error: • Template Haskell brackets cannot be nested (without intervening splices) • In the Template Haskell quotation [| True |] In the Template Haskell quotation [| [| True |] |] | 4 | prog = [| [| True |] |] | ^^ ``` As far as I can see the check was added in 2013 in this commit, https://github.com/ghc/ghc/commit/d0d47ba76f8f0501cf3c4966bc83966ab38cac27#diff-58794f81a415f148d011de563988c2b5R170 But there is no note, no tests and no comment about why it was added. I removed the check and added a `BracketE` constructor to the template-haskell AST and the code compiles fine. I can also construct a program which needs to be spliced twice and this also works fine. ``` func Add = [| (+) |] func Mul = [| (*) |] f1 "+" = [| Add |] f1 "*" = [| Mul |] comb s = [| func $(f1 s) |] ``` ``` res = $($(comb "*")) ``` So it seems the restriction is quite arbitrary but I was wondering if I was missing some limitation which meant this check was added. I would not be surprised if something more complicated goes wrong with splicing. Cheers, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Groups and projects
> Alright, I believe I have found the issue: you are a member of > the GHC group and GitLab's default notification behavior is that > you will receive notifications for all events of repositories in > groups to which you belong. OK thanks, that's helpful. When you say "repository" could you also have said "project". That is, are "projects" and "repositories" in 1-1 correspondence? So, to understand the semantics, you can belong to * A project. * A group What's the difference? The group seems to be "Glasgow Haskell Compiler"; the project seems to be "Glasgow Haskell Compiler / GHC". Does that imply that * every project is part of a group; but * a group may have many projects? Or maybe a project can be part of more than one group? The "Custom settings" on a project seem to be identical to the "custom settings" for a group. If Gitlab is deciding whether to send me a notification N, is it clear whether it's a "project notification" or a "group notification"? If so, then it can consult the appropriate settings; but if not, it's not clear. Sorry for all these questions. It's astonishingly common for large software systems to describe the surface knobs without describing the underlying model that makes sense of all those knobs! Simon -Original Message- From: Ben Gamari Sent: 24 January 2019 03:30 To: Simon Peyton Jones Subject: RE: GHC | hWaitForInput-accurate-pipe test (!21) Simon Peyton Jones writes: > Yes, tons of them! I attach a dozen that arrived in the last few hrs. > Alright, I believe I have found the issue: you are a member of the GHC group and GitLab's default notification behavior is that you will receive notifications for all events of repositories in groups to which you belong. You can view and modify these settings yourself here but I have changed them to be a bit more selective. You should now only receive notifications of new merge requests and new comments on merge requests on which you have previously commented. Do let me know if you receive any more unwanted mail. Cheers, - Ben signature.asc Description: signature.asc ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Thoughts on the Contributing page
On Wed, Jan 23, 2019 at 12:54:51PM -0500, Ben Gamari wrote: > > > Sounds like we are largely in agreement. Let's start on this after the > Trac migration is finished. I can in fact start working on this already while the migration is pipelined. It's just markdown in git, so writing a draft and then merging it into the wiki is perfectly straightforward. > I was going to recommend we rather just use something off-the-shelf to > avoid reinventing the wheel. I use linkchecker [1] elsewhere and it > works quite well. I believe you can use its -W flag to catch > non-existent wiki pages (which won't return a 404). Ofc, if we can do it without any extra coding effort, all the better. I do think doing it as part of the migration script might make it easier to capture those "redirect" pages (e.g. https://ghc.haskell.org/trac/ghc/wiki/Newcomers): we're scraping anyway, so I think detecting the shape of those pages shouldn't be overly difficult, and might be something an off-the-shelf link checker isn't as suitable for. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
