Can Gitlab's "issue was closed by ..." mails be improved?

Hi, Currently Gitlab doesn't give any details of why an issue was closed, it just says "Issue was closed by ...". You have to go to the issue page to see that it was closed because of a closing merge request was merged. I'm wondering if this could be improved so that in the email it says "issue

Re: Defining a wired-in type of a different kind

Hi Jan, mkAlgTyCon is good for making an algebraic datatype -- like Maybe or Bool or Either. It's not what you want for RNil, which is really a data constructor. Instead, rowKindCon should be the algebraic datatype, and RNil should be one of its constructors. Then you get the RNil TyCon via

Re: Introducing bugs that are caught by slow validate?

Where I work we use marge, and I wound up adding a patch to run an especially expensive "on merge only" CI run. The two pieces are: - patch marge to add a --require-ci-run-by-me flag, which makes marge want to see a CI completion by margebot and start one otherwise - modify the .gitlab-ci.yml

Re: Debug printing inside the typechecker knot

> On Apr 4, 2019, at 3:13 PM, Ryan Scott wrote: > >> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs >> returns a [TyVar] -- this won't end well. If you look further in >> zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` >> (roughly), making the

Re: Debug printing inside the typechecker knot

> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs > returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, > you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making > the equivalent to be TcMType.zonkTyCoVarKind. Ah. I was led

Re: Debug printing inside the typechecker knot

> On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote: > > Good to know, thanks. I assume that TcMType.zonkTcTypes is to > TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to > TcHsType.zonkTyBndrs? No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] --

Re: Debug printing inside the typechecker knot

Good to know, thanks. I assume that TcMType.zonkTcTypes is to TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to TcHsType.zonkTyBndrs? Also, what exactly is the optimization that ZonkEnv performs in types? And why don't the functions in TcMType make use of this optimization? Ryan S.

Re: Debug printing inside the typechecker knot

Though a ZonkEnv does some important work when zonking *terms*, it's just an optimization when zonking *types*. You want TcMType.zonkTcType. I hope this helps! Richard > On Apr 4, 2019, at 10:38 AM, Ryan Scott wrote: > > I've recently found myself wanting to add some pprTrace statements in >

Re: Introducing bugs that are caught by slow validate?

Ömer Sinan Ağacan writes: > Hi all, > > I just run slow validate and it actually catches bugs (#16529) and some > configuration problems in the test definitions (#!700). These are not caught > by > the CI jobs because they run normal validate instead of slow. > > (Actually they don't even run

Re: In-tree invocation of GHC built with Hadrian

Issue tracked at https://gitlab.haskell.org/ghc/ghc/issues/16534 Somehow the stage 2 GHCs (_build/stage1/bin/ghc) that we build _don't_ have this problem. I will post an update here when I have a comprehensive explanation and a fix. On 04/04/2019 17:40, Simon Peyton Jones wrote: OK, that’s

RE: In-tree invocation of GHC built with Hadrian

OK, that's great - it's not just me. I'll await further guidance, and revert to "sh validate" meanwhile. Thanks Simon From: ghc-devs On Behalf Of Alp Mestanogullari Sent: 04 April 2019 16:25 To: ghc-devs@haskell.org Subject: Re: In-tree invocation of GHC built with Hadrian I can reproduce

Re: In-tree invocation of GHC built with Hadrian

I can reproduce this problem. This doesn't come up when building stage2 with that executable (stage1) because the commands that Hadrian emits all do something along the lines of `-no-user-package-db -package-db _build/stage0/lib/package.conf.d`, which masks the problem. I'm looking into this,

Debug printing inside the typechecker knot

I've recently found myself wanting to add some pprTrace statements in typechecker-related code but unable to do so, as the code would pull on knot-tied TyCons (leading to an infinite loop if actually ran). In particular, I want to print some code [1] in TcTyClsDecls.tcConDecl: ; (ze, tkvs)

Re: Cannot fetch array @ 58a7ea

Hi, Takenobu, It worked! Thank you. This was the case mentioned in https://gitlab.haskell.org/ghc/ghc/issues/16513. URL of GHC in `README.md` has been fixed today. So there will be no problem. Best, Taku 2019年4月4日(木) 21:53 Takenobu Tani : > Hi, > > Did you clone from gitlab.haskell.org ? >

RE: Help with cabal

Ah, so you installed the `cabal-install-3.0` package? Yes I attached your repo and then said apt install cabal-install and lo! cabal 3.0 appeared in /opt/cabal/bin I did this because the vanilla Ubuntu distro only had cabal 1.24. And I could not update by saying “cabal install cabal-install”

Re: Cannot fetch array @ 58a7ea

Hi, Did you clone from gitlab.haskell.org ? Both github.com and git.haskell.org are already old domains. There may be a better way, but I'm cloning like this: -- clone from gitlab $ git clone g...@gitlab.haskell.org:YOUR_NAME/ghc.git -- fix submodules $ mv .gitmodules .gitmodules.org

RE: In-tree invocation of GHC built with Hadrian

simonpj@MSRC-9870733:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags","") ,("C compiler link flags"," -fuse-ld=gold") ,("C

RE: In-tree invocation of GHC built with Hadrian

No, setting GHC_ENVIRONMNT to "-" doesn't change anything tmp$ GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190404", got

RE: In-tree invocation of GHC built with Hadrian

No, definitely not in the current directory. There is only one file in the directory, Foo.hs Simon | -Original Message- | From: Matthew Pickering | Sent: 04 April 2019 12:46 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: In-tree invocation of GHC built with

Re: In-tree invocation of GHC built with Hadrian

Do you have any .ghc-environment files in your working directory? Matt On Thu, Apr 4, 2019 at 12:21 PM Simon Peyton Jones via ghc-devs wrote: > > How can I run the inplace binary built by Hadrian. I tried this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > but I got this > >

In-tree invocation of GHC built with Hadrian

How can I run the inplace binary built by Hadrian. I tried this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs but I got this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched

RE: Help with cabal

ok thanks. But still, how can I tell it to look at fpcomplete instead? And why does it do so automatically on one machine but not on another? From: ghc-devs On Behalf Of Sylvain Henry Sent: 04 April 2019 10:56 To: ghc-devs@haskell.org Subject: Re: Help with cabal Hi Simon, Hackage on

Re: Help with cabal

Hi Simon, Hackage on haskell.org is down: https://www.reddit.com/r/haskell/comments/b99cef/hackage_downtime/ Sylvain On 04/04/2019 11:51, Simon Peyton Jones via ghc-devs wrote: I’m setting up my GHC builds on a new machine, and this time I’m using WSL (windows subsystem for Linux).

Help with cabal

I'm setting up my GHC builds on a new machine, and this time I'm using WSL (windows subsystem for Linux). Small problem. I've installed cabal-3.0, and say "cabal update". But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json And indeed, that's what a web browser says

Introducing bugs that are caught by slow validate?

Hi all, I just run slow validate and it actually catches bugs (#16529) and some configuration problems in the test definitions (#!700). These are not caught by the CI jobs because they run normal validate instead of slow. (Actually they don't even run the validate script, but they run "test"