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

[Ömer Sinan Ağacan]

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 was closed by ... via
commit ..." or something like that.

Anyone know if there's already a ticket for this in Gitlab issue tracker?

Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Richard Eisenberg]

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 promotion, as Matt suggested.

I hope this helps!
Richard

> On Apr 3, 2019, at 7:06 AM, Jan van Brügge  wrote:
> 
> 
> Hi,
> 
> when trying to get familiar with the GHC code base for my Bachelor's
> thesis. I followed the GHC Wiki, especially the case study about the
> bool type.
> Now I wanted to add a new kind and a new type inhabiting this kind
> (without having to expose a data constructor, so without datatype
> promotion).
> 
> So in TysWiredIn.hs I added the new TyCons and added them to the list of
> wired-in types:
> 
> -- data Row a b
> rowKindCon :: TyCon
> rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] []
> 
> rowKind :: Kind
> rowKind = mkTyConTy rowKindCon
> 
> -- data RNil :: Row a b
> rnilTyCon :: TyCon
> rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing []
> (mkDataTyConRhs [])
> (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName))
> False
> 
> rnilTy :: Type
> rnilTy = mkTyConTy rnilTyCon
> 
> 
> I also added two new empty data decls to ghc-prim, but if I inspect the
> kind of RNil it is not Row, but Type. So I think I am either
> understanding res_kind wrong or I have to do something completely different.
> I am also not sure how to verify that the code in TysWiredIn.hs is
> working at all, from all what I can tell it could just be the
> declarations in ghc-prim that result in what I see in ghci.
> 
> Thank you and sorry for my beginner question
> Jan
> 
> ___
> 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: Introducing bugs that are caught by slow validate?

[Evan Laforge]

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 to put the expensive CI under 'only:
variables: [$GITLAB_USER_LOGIN == "marge-bot"]'

It has the side-effect that marge-bot insists on running an extra CI
on each merge (since she no longer wants to reuse your CI run), but
since we have caching, we only pay for extra tests implied by the
heavy version of the CI run.

You could probably get the same thing by making the test outputs shake
targets, at which point it should only run tests affected by your
changes, and reuse test outputs if there hasn't been a change.  I'm
not sure if ghc tests do that... but last I recall it was a monolithic
"test everything" script that always ran all the tests.

On Thu, Apr 4, 2019 at 1:21 AM Ömer Sinan Ağacan  wrote:
>
> 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" instead
> of "slowtest", which I think is the main difference between normal validate 
> and
> slow validate)
>
> As far as I can see we have nightly job definitions in .gitlab-ci.yml, which 
> do
> slow validate, but I'm not sure if those are used?
>
> Would it be possible to switch over to slow validate in CI jobs? If slow
> validate takes too long on the CI servers, could we maybe configure CI tasks 
> so
> that if the MR submitter is Marge, we run slow validate, otherwise we run fast
> validate?
>
> The problem with nightly jobs (assuming they're used) is that it's too late by
> the time they catch a test failure because the commits are already in the 
> tree,
> and because nothing's blocked the bugs are more likely to stay unfixed.
>
> Ömer
> ___
> 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: Debug printing inside the typechecker knot

[Richard Eisenberg]

> 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 equivalent to be TcMType.zonkTyCoVarKind.
> 
> Ah. I was led astray because there is a TcMType.zonkTyCoVarKind
> function, but not a TcMType.zonkTyCoVarKinds function (with an -s at
> the end). Similarly strange is that there is a TcHsType.zonkTyBndrs
> function, but not a TcHsType.zonkTyBndr function (without an -s at the
> end).
> 
> Out of curiosity, is a TcHsType counterpart to TcMType.zonkTcTyVar(s)?

Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"?

TcHsSyn.zonkTyVarOcc, naturally. :)

> 
>> Clearly, it would behoove use to rename these functions to be more 
>> systematic.
> 
> Indeed. What would be better names for these? It looks like we've
> identified at least a couple things that could be cleaned up in
> TcMType and TcHsType, so if you suggest a more consistent naming
> scheme, I would be willing to implement it.

No particular wisdom here. We really should just bite the bullet and do this, 
though.

> 
> My eventual goal is to write up this wisdom in a GHC wiki page simply
> because I keep getting frustrated any time I have to debug code in the
> typechecker knot, and I'd like to codify this solution somewhere where
> I can look it up in the future if (when) I eventually forget it.

I will point out that this knot is *much* *much* smaller than it once was. But 
it's never a bad idea to document more.

Richard

> 
> Ryan S.
> 
> On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg  wrote:
>> 
>> 
>> 
>>> 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] -- 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.
>> 
>> Clearly, it would behoove use to rename these functions to be more 
>> systematic.
>> 
>>> 
>>> Also, what exactly is the optimization that ZonkEnv performs in types?
>>> And why don't the functions in TcMType make use of this optimization?
>> 
>> Suppose we have
>> 
>> forall (a :: kappa). ... a ...
>> 
>> We laboriously discover that kappa should be (Type -> Type). The ZonkEnv 
>> stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in 
>> the body of the forall, we don't have to repeat the zonk -- we just do a 
>> lookup. But, of course, zonking the occurrence of `a` would also work.
>> 
>> Why don't we do this in TcMType? There's likely no good reason -- it would 
>> be effective there, too. But it would be less effective. The code in TcHsSyn 
>> generally starts with *closed* types/terms, meaning that all type variables 
>> will be brought into scope somewhere. In contrast, TcMType functions can 
>> work over *open* terms, so we have less opportunity to extend the ZonkEnv.
>> 
>> Richard
>> 
>>> 
>>> Ryan S.
>>> ___
>>> 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: Debug printing inside the typechecker knot

[Ryan Scott]

> 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 astray because there is a TcMType.zonkTyCoVarKind
function, but not a TcMType.zonkTyCoVarKinds function (with an -s at
the end). Similarly strange is that there is a TcHsType.zonkTyBndrs
function, but not a TcHsType.zonkTyBndr function (without an -s at the
end).

Out of curiosity, is a TcHsType counterpart to TcMType.zonkTcTyVar(s)?

> Clearly, it would behoove use to rename these functions to be more systematic.

Indeed. What would be better names for these? It looks like we've
identified at least a couple things that could be cleaned up in
TcMType and TcHsType, so if you suggest a more consistent naming
scheme, I would be willing to implement it.

My eventual goal is to write up this wisdom in a GHC wiki page simply
because I keep getting frustrated any time I have to debug code in the
typechecker knot, and I'd like to codify this solution somewhere where
I can look it up in the future if (when) I eventually forget it.

Ryan S.

On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg  wrote:
>
>
>
> > 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] -- 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.
>
> Clearly, it would behoove use to rename these functions to be more systematic.
>
> >
> > Also, what exactly is the optimization that ZonkEnv performs in types?
> > And why don't the functions in TcMType make use of this optimization?
>
> Suppose we have
>
> forall (a :: kappa). ... a ...
>
> We laboriously discover that kappa should be (Type -> Type). The ZonkEnv 
> stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in 
> the body of the forall, we don't have to repeat the zonk -- we just do a 
> lookup. But, of course, zonking the occurrence of `a` would also work.
>
> Why don't we do this in TcMType? There's likely no good reason -- it would be 
> effective there, too. But it would be less effective. The code in TcHsSyn 
> generally starts with *closed* types/terms, meaning that all type variables 
> will be brought into scope somewhere. In contrast, TcMType functions can work 
> over *open* terms, so we have less opportunity to extend the ZonkEnv.
>
> Richard
>
> >
> > Ryan S.
> > ___
> > 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: Debug printing inside the typechecker knot

[Richard Eisenberg]

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

Clearly, it would behoove use to rename these functions to be more systematic.

> 
> Also, what exactly is the optimization that ZonkEnv performs in types?
> And why don't the functions in TcMType make use of this optimization?

Suppose we have

forall (a :: kappa). ... a ...

We laboriously discover that kappa should be (Type -> Type). The ZonkEnv stores 
a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in the body 
of the forall, we don't have to repeat the zonk -- we just do a lookup. But, of 
course, zonking the occurrence of `a` would also work.

Why don't we do this in TcMType? There's likely no good reason -- it would be 
effective there, too. But it would be less effective. The code in TcHsSyn 
generally starts with *closed* types/terms, meaning that all type variables 
will be brought into scope somewhere. In contrast, TcMType functions can work 
over *open* terms, so we have less opportunity to extend the ZonkEnv.

Richard

> 
> Ryan S.
> ___
> 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: Debug printing inside the typechecker knot

[Ryan Scott]

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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debug printing inside the typechecker knot

[Richard Eisenberg]

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
> 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) <- zonkTyBndrs tkvs
>   ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs
>   ; arg_tys <- zonkTcTypesToTypesX ze arg_tys
>   ; ctxt<- zonkTcTypesToTypesX ze ctxt
>   ; res_ty  <- zonkTcTypeToTypeX   ze res_ty
> 
>   ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst)
>   = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty
> 
> In [2], goldfire claimed that there is a way to work around this problem now:
> 
>> But you can do this. It just has to be before the final zonk. I
> see that rejigConRes is used after the final zonk. But there's nothing
> about that function that requires things be in their final state. The
> arguments need to be zonked, but they can be zonked by zonkTcType and
> friends, not zonkTcTypeToType and friends. So, for debugging: zonk
> everything with the functions in TcMType (not those in TcHsSyn). Then
> rejigConRes. Then print all the output you like. Then do the final
> zonk. This double-zonk is redundant, so it's not good to keep going
> forward, but it shouldn't cause other trouble.
> 
> Unfortunately, this advice doesn't seem to pan out in practice. I
> started off by looking for a TcMType equivalent of this function:
> 
>zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type
> 
> However, I am utterly unable to find anything defined in TcMType with
> a similar type signature. Actually, it's worse than that: there isn't
> a single mention of ZonkEnv anywhere in TcMType! So as far as I can
> tell, this advice is completely unimplementable, unless I'm missing
> something obvious. Any tips?
> 
> Ryan S.
> -
> [1] 
> https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc49406/compiler/typecheck/TcTyClsDecls.hs#L2312-2318
> [2] https://phabricator.haskell.org/D4974#137224
> ___
> 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: Introducing bugs that are caught by slow validate?

[Ben Gamari]

Ö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 the validate script, but they run "test" instead
> of "slowtest", which I think is the main difference between normal validate 
> and
> slow validate)
>
> As far as I can see we have nightly job definitions in .gitlab-ci.yml, which 
> do
> slow validate, but I'm not sure if those are used?
>
> Would it be possible to switch over to slow validate in CI jobs? If slow
> validate takes too long on the CI servers, could we maybe configure CI tasks 
> so
> that if the MR submitter is Marge, we run slow validate, otherwise we run fast
> validate?
>
See !710.

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: In-tree invocation of GHC built with Hadrian

[Alp Mestanogullari]

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 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 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, I will open a ticket soon with the 
information that I can gather.


On 04/04/2019 13:21, 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

~/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 "80920190403",
got "8064")

  |

1 | module Foo where

  |    ^^^

simonpj@MSRC-3645512:~/tmp$

Somehow the inplace binary built by Hadrian is looking for library
files in completely the wrong place.

What should I do?

Simon



___

ghc-devs mailing list

ghc-devs@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


--
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: In-tree invocation of GHC built with Hadrian

[Simon Peyton Jones via ghc-devs]

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 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, I will open a ticket soon with the information that I can gather.
On 04/04/2019 13:21, 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

~/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 "80920190403", got "8064")

  |

1 | module Foo where

  |^^^

simonpj@MSRC-3645512:~/tmp$
Somehow the inplace binary built by Hadrian is looking for library files in 
completely the wrong place.
What should I do?
Simon



___

ghc-devs mailing list

ghc-devs@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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: In-tree invocation of GHC built with Hadrian

[Alp Mestanogullari]

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, I will open a ticket soon with the information that I can gather.


On 04/04/2019 13:21, 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

~/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 "80920190403", got 
"8064")


  |

1 | module Foo where

  |    ^^^

simonpj@MSRC-3645512:~/tmp$

Somehow the inplace binary built by Hadrian is looking for library 
files in completely the wrong place.


What should I do?

Simon


___
ghc-devs mailing list
ghc-devs@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

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Debug printing inside the typechecker knot

[Ryan Scott]

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) <- zonkTyBndrs tkvs
   ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs
   ; arg_tys <- zonkTcTypesToTypesX ze arg_tys
   ; ctxt<- zonkTcTypesToTypesX ze ctxt
   ; res_ty  <- zonkTcTypeToTypeX   ze res_ty

   ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst)
   = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty

In [2], goldfire claimed that there is a way to work around this problem now:

> But you can do this. It just has to be before the final zonk. I
see that rejigConRes is used after the final zonk. But there's nothing
about that function that requires things be in their final state. The
arguments need to be zonked, but they can be zonked by zonkTcType and
friends, not zonkTcTypeToType and friends. So, for debugging: zonk
everything with the functions in TcMType (not those in TcHsSyn). Then
rejigConRes. Then print all the output you like. Then do the final
zonk. This double-zonk is redundant, so it's not good to keep going
forward, but it shouldn't cause other trouble.

Unfortunately, this advice doesn't seem to pan out in practice. I
started off by looking for a TcMType equivalent of this function:

zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type

However, I am utterly unable to find anything defined in TcMType with
a similar type signature. Actually, it's worse than that: there isn't
a single mention of ZonkEnv anywhere in TcMType! So as far as I can
tell, this advice is completely unimplementable, unless I'm missing
something obvious. Any tips?

Ryan S.
-
[1] 
https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc49406/compiler/typecheck/TcTyClsDecls.hs#L2312-2318
[2] https://phabricator.haskell.org/D4974#137224
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help with cabal

[Herbert Valerio Riedel]

On Thu, Apr 4, 2019 at 2:56 PM Simon Peyton Jones 
wrote:

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


Ok, so here's the weird thing... I don't have any "cabal-install" package
in my PPA; I do however have a "cabal-install-3.0" package (i.e. the 3.0 is
part of the version number, because I supply one package per major version
of cabal).

So I'd expect you'd find something like

ii  cabal-install-3.0
 3.0+git20190317.1.b3d6d0b-6~16.04amd64Command-line
interface for Cabal and Hackage

if you executed `dpkg -l | grep cabal-install`... (i.e. the "version" is
that monstrous "3.0+git20190317.1.b3d6d0b-6~16.04"  thing)


>
>
> In the meantime you can just keep using your current cabal 3.0 exe; does
> `cabal --version` currently have any noticeable startup latency for you on
> WSL?
>

>
> No, no noticeable startup latency.
>

Interesting. I'll investigate... maybe I'll be able to discontinue the WSL
ppa at last... :-)


>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot fetch array @ 58a7ea

[autotaker]

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 ?
> 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
>   $ sed -e 's/\.\./https:\/\/gitlab.haskell.org\/ghc/' .gitmodules.org >
> .gitmodules
>   $ git submodule update --init
>   $ git checkout .gitmodules
>
> Regards,
> Takenobu
>
>
>
>
> On Thu, Apr 4, 2019 at 8:23 AM autotaker  wrote:
>
>> Hi devs,
>>
>> I pulled ghc gitlab repository by
>> ```
>> git pull --recurse-submodules
>> ```
>>
>> But it failed with the following error.
>> ```
>> error: Server does not allow request for unadvertised object
>> 58a7ea0336363b29513164487190f6570b8ea834
>> Fetched in submodule path 'libraries/array', but it did not contain
>> 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit
>> failed.
>> ```
>> It seems the latest commit `58a7ea` of `array` library is not found on
>> the server.
>> Are there any help on this?
>>
>> Best,
>> Taku Terao
>> ___
>> 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: Help with cabal

[Simon Peyton Jones via ghc-devs]

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” because cabal 1.24 fell over 
with that “futex error”.

In the meantime you can just keep using your current cabal 3.0 exe; does `cabal 
--version` currently have any noticeable startup latency for you on WSL?

No, no noticeable startup latency.

I’ll do the reinstall thing in a few hrs, after you’d done your update.  Thanks!

SImon

From: Herbert Valerio Riedel 
Sent: 04 April 2019 13:45
To: Simon Peyton Jones 
Subject: Re: Help with cabal



On Thu, Apr 4, 2019 at 2:25 PM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
But how do I "recompile your cabal 3.0 executable with the new GHC"?  The 
cabal-3.0 I have is (I believe) installed by
apt install cabal-install
and so I suppose if I "upgrade", the new 'cabal' binary will WSL'd, no?


Ah, so you installed the `cabal-install-3.0` package?  If so, yes, it *will* be 
updated to the WSL version in about one hour... because it turns out I 
forgot to push the 3.0 packages to the WSL ppa... and I've just triggered a new 
build of cabal 3.0 packages which will take about one hour to show up there... 
:-)

In the meantime you can just keep using your current cabal 3.0 exe; does `cabal 
--version` currently have any noticeable startup latency for you on WSL?



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot fetch array @ 58a7ea

[Takenobu Tani]

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
  $ sed -e 's/\.\./https:\/\/gitlab.haskell.org\/ghc/' .gitmodules.org >
.gitmodules
  $ git submodule update --init
  $ git checkout .gitmodules

Regards,
Takenobu




On Thu, Apr 4, 2019 at 8:23 AM autotaker  wrote:

> Hi devs,
>
> I pulled ghc gitlab repository by
> ```
> git pull --recurse-submodules
> ```
>
> But it failed with the following error.
> ```
> error: Server does not allow request for unadvertised object
> 58a7ea0336363b29513164487190f6570b8ea834
> Fetched in submodule path 'libraries/array', but it did not contain
> 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit
> failed.
> ```
> It seems the latest commit `58a7ea` of `array` library is not found on the
> server.
> Are there any help on this?
>
> Best,
> Taku Terao
> ___
> 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: In-tree invocation of GHC built with Hadrian

[Simon Peyton Jones via ghc-devs]

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 compiler supports -no-pie","YES")

,("Haskell CPP command","gcc")

,("Haskell CPP flags","-E -undef -traditional")

,("ld command","ld.gold")

,("ld flags","")

,("ld supports compact unwind","YES")

,("ld supports build-id","YES")

,("ld supports filelist","NO")

,("ld is GNU ld","YES")

,("ar command","ar")

,("ar flags","q")

,("ar supports at file","YES")

,("ranlib command","ranlib")

,("touch command","touch")

,("dllwrap command","/bin/false")

,("windres command","/bin/false")

,("libtool command","libtool")

,("cross compiling","NO")

,("target os","OSLinux")

,("target arch","ArchX86_64")

,("target word size","8")

,("target has GNU nonexec stack","True")

,("target has .ident directive","True")

,("target has subsections via symbols","False")

,("target has RTS linker","YES")

,("Unregisterised","NO")

,("LLVM llc command","llc")

,("LLVM opt command","opt")

,("LLVM clang command","clang")

,("Project version","8.9.20190404")

,("Project Git commit id","51fd357119b357c52e990ccce9059c423cc49406")

,("Booter version","8.6.4")

,("Stage","1")

,("Build platform","x86_64-unknown-linux")

,("Host platform","x86_64-unknown-linux")

,("Target platform","x86_64-unknown-linux")

,("Have interpreter","YES")

,("Object splitting supported","NO")

,("Have native code generator","YES")

,("Support SMP","YES")

,("Tables next to code","YES")

,("RTS ways","v thr")

,("RTS expects libdw","NO")

,("Support dynamic-too","YES")

,("Support parallel --make","YES")

,("Support reexported-modules","YES")

,("Support thinning and renaming package flags","YES")

,("Support Backpack","YES")

,("Requires unified installed package IDs","YES")

,("Uses package keys","YES")

,("Uses unit IDs","YES")

,("Dynamic by default","NO")

,("GHC Dynamic","NO")

,("GHC Profiled","NO")

,("Leading underscore","NO")

,("Debug on","False")

,("LibDir","/home/simonpj/code/HEAD/_build/stage0/lib")

,("Global Package 
DB","/home/simonpj/code/HEAD/_build/stage0/lib/package.conf.d")

]

simonpj@MSRC-9870733:~/tmp$

From: Herbert Valerio Riedel 
Sent: 04 April 2019 13:41
To: Simon Peyton Jones 
Subject: Re: In-tree invocation of GHC built with Hadrian

Hi,

I haven't tried this with Hadrian yet, but maybe the output from

~/code/HEAD/_build/stage0/bin/ghc --info

might provide a hint.

As for the ghc-environment theory: if there was a ghc-env file, GHC would tell 
you it has picked one up...


On Thu, Apr 4, 2019 at 1:21 PM Simon Peyton Jones via ghc-devs 
mailto:ghc-devs@haskell.org>> 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

~/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 "80920190403", got "8064")

  |

1 | module Foo where

  |^^^

simonpj@MSRC-3645512:~/tmp$
Somehow the inplace binary built by Hadrian is looking for library files in 
completely the wrong place.
What should I do?
Simon
___
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: In-tree invocation of GHC built with Hadrian

[Simon Peyton Jones via ghc-devs]

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 "8064")
  |
1 | module Foo where
  |^^^

| -Original Message-
| From: Moritz Angermann 
| Sent: 04 April 2019 12:47
| To: Simon Peyton Jones 
| Subject: Re: In-tree invocation of GHC built with Hadrian
| 
| Yes, that looks wrong indeed. It shouldn't pick up the ghc-8.6.4 library.
| 
| After the recent env files discussion, maybe it's picking up some env
| files?
| It's just a wild guess though, I've never had ghc do that to me yet(!).
| Does
| 
| GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs
| 
| yield any better results?
| 
| Cheers,
|  Moritz
| > On Apr 4, 2019, at 7: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
| >
| > ~/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 "80920190403", got
| "8064")
| >   |
| > 1 | module Foo where
| >   |^^^
| > simonpj@MSRC-3645512:~/tmp$
| >
| > Somehow the inplace binary built by Hadrian is looking for library files
| in completely the wrong place.
| >
| > What should I do?
| >
| > Simon
| >
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7C350a796ae8db4e3f8fc708d6
| b8f34549%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899752311716865&a
| mp;sdata=FCMavvoIcAGUQVO0ggOxNJwIKZw2EC%2BSbmhZFSacywg%3D&reserved=0

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: In-tree invocation of GHC built with Hadrian

[Simon Peyton Jones via ghc-devs]

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 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
| >
| > ~/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 "80920190403", got
| > "8064")
| >
| >   |
| >
| > 1 | module Foo where
| >
| >   |^^^
| >
| > simonpj@MSRC-3645512:~/tmp$
| >
| > Somehow the inplace binary built by Hadrian is looking for library files
| in completely the wrong place.
| >
| > What should I do?
| >
| > Simon
| >
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
| > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01
| > %7Csimonpj%40microsoft.com%7Cf54dbe96df5f405e689c08d6b8f33015%7C72f988
| > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899752031269186&sdata=Llg1
| > 19jpY9JjiYxgWoca3b7Z%2BvZXruKbQVHIW1okxo4%3D&reserved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: In-tree invocation of GHC built with Hadrian

[Matthew Pickering]

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
>
> ~/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 "80920190403", got "8064")
>
>   |
>
> 1 | module Foo where
>
>   |^^^
>
> simonpj@MSRC-3645512:~/tmp$
>
> Somehow the inplace binary built by Hadrian is looking for library files in 
> completely the wrong place.
>
> What should I do?
>
> Simon
>
> ___
> 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

In-tree invocation of GHC built with Hadrian

[Simon Peyton Jones via ghc-devs]

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 interface file versions (wanted "80920190403", got "8064")

  |

1 | module Foo where

  |^^^

simonpj@MSRC-3645512:~/tmp$
Somehow the inplace binary built by Hadrian is looking for library files in 
completely the wrong place.
What should I do?
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Help with cabal

[Simon Peyton Jones via ghc-devs]

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

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 for that same URL.

What do to?

Oddly, on another also-new Windows machine, I do exactly the same thing, and 
with 'cabal update -v' I can see that it gets the same error, but then moves on 
to try hackages.fpcomplete.com, which works.

Why does the behaviour differ?  And, at least for now, how can I get the first 
machine to look at hackage.fpcomplete.com?

Thanks

Simon



___

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: Help with cabal

[Sylvain Henry]

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


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 for that same URL.

What do to?

Oddly, on another also-new Windows machine, I do exactly the same 
thing, and with ‘cabal update –v’ I can see that it gets the same 
error, but then moves on to try hackages.fpcomplete.com, which works.


Why does the behaviour differ?  And, at least for now, how can I get 
the first machine to look at hackage.fpcomplete.com?


Thanks

Simon


___
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

Help with cabal

[Simon Peyton Jones via ghc-devs]

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 for that same URL.

What do to?

Oddly, on another also-new Windows machine, I do exactly the same thing, and 
with 'cabal update -v' I can see that it gets the same error, but then moves on 
to try hackages.fpcomplete.com, which works.

Why does the behaviour differ?  And, at least for now, how can I get the first 
machine to look at hackage.fpcomplete.com?

Thanks

Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Introducing bugs that are caught by slow validate?

[Ömer Sinan Ağacan]

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" instead
of "slowtest", which I think is the main difference between normal validate and
slow validate)

As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do
slow validate, but I'm not sure if those are used?

Would it be possible to switch over to slow validate in CI jobs? If slow
validate takes too long on the CI servers, could we maybe configure CI tasks so
that if the MR submitter is Marge, we run slow validate, otherwise we run fast
validate?

The problem with nightly jobs (assuming they're used) is that it's too late by
the time they catch a test failure because the commits are already in the tree,
and because nothing's blocked the bugs are more likely to stay unfixed.

Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs