Re: Fixing type synonyms to Uniq(D)FM newtypes

[Ben Gamari]

Richard Eisenberg  writes:

> One advantage of the phantom-parameter approach is that it allows for nice 
> polymorphism.
>
>> lookupEnv :: Uniquable dom => UniqFM dom rng -> dom -> Maybe rng
>
> Now, we don't need lookupVarEnv separately from lookupNameEnv, but we
> get the type-checking for free.
>
This is true but some consider the fact that the function name captures
the environment type to be a good thing. I don't have a strong opinion
one way of the other on this.

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: Windows testsuite failures

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> Both Tamar and Omer are right.
>
>   * Not doing CI on Windows is bad. It means that bugs get introduced,
> and not discovered until later. This is Tamer’s point, and it is
> valid.
>   * Holding up MRs because a failures in Windows CI that is unrelated
> to the MR is also bad. It a frustrating waste of time, and
> discourages all authors. (In contrast, holding up an MR because it
> introduces a bug on Windows is fine, indeed desirable.) This is
> Omer’s point, and it is valid.
>
> The obvious solution is: let’s fix Windows CI, so that it doesn’t fail
> except when the MR genuinely introduces a bug.
>
> How hard would it be to do that? Do we even know what the problem is?
>
This latest issue was quite tricky since the root cause was in an
unexpected place (it seems that some of the Windows GitLab runners
somehow no longer had symlink permission, perhaps due to an operating
system update; I had expected the problem to be in the testsuite driver
due to previous issues in that area [1]). Given the relative scarcity of
Windows CI capacity and the difficulty of hitting the issue to begin
with, it took quite a while to realized the problem.

However, this morning I identified the issue and, as a workaround,
temporarily disabled forced usage of symlinks on Windows CI. I have also
opened #17706, which should allow us to use symlinks without fear of
this potential breakage.

Cheers,

- Ben


[1] 
https://gitlab.haskell.org/ghc/ghc/commit/e35fe8d58f18bd179efdc848c617dc9eddf4478b


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

Re: Windows testsuite failures

[Ben Gamari]

Ömer Sinan Ağacan  writes:

>> Now we have rewritten the CI and it's pointing out actual issues in the
>> compiler. And your suggestion is well let's just ignore it.
>
> When is the last time Windows CI caught an actual bug? All I see is random
> system failures [1, 2, 3].
>
> It must be catching *some* bugs, but that's a rare event in my experience.
>
It's unfortunately not nearly as rare as you would hope. However, it is
likely that these cases aren't widely seen as I have been working on
marking broken tests as expect_broken over the last few months.

Only recently (for roughly a month now, IIRC) has Windows been a
mandatory-green platform and it took a significant amount of effort and
several false-starts to get to this point.

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: Windows testsuite failures

[Ben Gamari]

Ömer Sinan Ağacan  writes:

> Hi Ben,
>
> Can we please disable Windows CI? I've spent more time fighting the CI than
> doing useful work this week, it's really frustrating.
>
Yes, this recent spate is issues indeed took too long to solve.
Unfortunately this particular issue took quite a while to isolate since
I had trouble reproducing it as it depended upon which CI builder the
job ran on.

However, I eventually found and pushed a patch to fix the root cause
this morning.

> Since we have no idea how to fix it maybe we should test Windows only before a
> release, manually (and use bisect in case of regressions).
>
As pointed out by Tamar, this really is not a viable option. In truth,
the pain we are experiencing now is precisely because we neglected
Windows support for so long. I am now making a concerted effort to fix
this and, while it has been painful, we are gradually approaching a
half-way decent story for Windows. x86-64 is, as of this morning,
believed to be mostly stable; I'm now working on i386.

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: submodule instructions?

[Ben Gamari]

Richard Eisenberg  writes:

> Hi devs,
>
> Are there up-to-date instructions on how to deal with submodules in GHC?
>
> https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules
> 
> does give nice information. It refers to
> https://gitlab.haskell.org/ghc/ghc/wikis/repositories
>  to learn about
> specific repositories. But is that second page correct? It refers to
> e.g. GitHub as the upstream for Haddock. Will our new GitLab-based CI
> pull from GitHub's Haddock? And what if a contributor doesn't have
> commit access?
>
Indeed GitHub is still the upstream for Haddock (although I think we
talk to the Haddock maintainers about this).

> Maybe it's all there, but I don't quite see how a contributor can
> ensure that CI has access to patches on submodules.

I have added a bit of language to [submodules] explaining how to
accomplish this. Do let me know if this is still unclear.

Cheers,

- Ben



[submodules]: 
https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules



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

Re: [ANNOUNCE] GHC 8.8.2 is now available

[Jens Petersen]

On Fri, 17 Jan 2020, 00:35 Ben Gamari,  wrote:

> The GHC team is proud to announce the release of GHC 8.8.2.
>

Congrats

I have built it already for the Fedora ghc:8.8 module stream: it should go
into updates-testing-modular soon for F30, F31, and Rawhide.

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

submodule instructions?

[Richard Eisenberg]

Hi devs,

Are there up-to-date instructions on how to deal with submodules in GHC?

https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules 
 
does give nice information. It refers to 
https://gitlab.haskell.org/ghc/ghc/wikis/repositories 
 to learn about specific 
repositories. But is that second page correct? It refers to e.g. GitHub as the 
upstream for Haddock. Will our new GitLab-based CI pull from GitHub's Haddock? 
And what if a contributor doesn't have commit access?

Maybe it's all there, but I don't quite see how a contributor can ensure that 
CI has access to patches on submodules.

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

RE: Find constraints over type

[Simon Peyton Jones via ghc-devs]

Starting from any point in the typechecked syntax tree, you can look outwards 
to find binding sites for enclosing constraints, and then use whatever method 
you like to decide if they are relevant. Binding sites are:


  *   ConPatOut; binds dictionaries from GADT matches
  *   AbsBinds: abs_ev_vars binds dictionaries from let-bindings

Simon

From: Alejandro Serrano Mena 
Sent: 17 January 2020 08:26
To: Simon Peyton Jones 
Cc: GHC developers 
Subject: Re: Find constraints over type

My goal is to add type information on hover within `ghcide`. Right now, when 
you select a variable, we give back the type as reported in the corresponding 
Var. However, when this type involved a type variable, it misses a lot of 
important information about the typing context in which we are working. So the 
goal is to report back some of this typing context.

Going back to my original example:

f :: Eq a => [a] -> Bool
f xs = xs == []

It would be great if by hovering over the 'xs', one would get '[a] where Eq a', 
or some other representation of the known constraints.

Since this is intended to be a help for the programmer, it doesn't really 
matter whether we get "too many" constraints (for example, if we had "Ord a" 
it's OK to get "Eq a" too, since that's interesting constraint information).

Right now I am working with TypecheckModules most of the time.

Regards,
Alejandro

El jue., 16 ene. 2020 a las 19:47, Simon Peyton Jones 
(mailto:simo...@microsoft.com>>) escribió:
There is definitely no pure way to get from ‘a’ to its constraints.

  *   It is far from clear what “its constraints” are.   Is (C a b) such a 
constraint?  C [a] b?  What about superclasses?
  *   Constraints vary depending on where  you are.  GADT matches can bring 
into scope extra constraints on existing type variables.

So as Ben says, to give a sensible response you’ll need to explain more about 
your goal

Simon

From: ghc-devs 
mailto:ghc-devs-boun...@haskell.org>> On Behalf 
Of Alejandro Serrano Mena
Sent: 16 January 2020 16:19
To: GHC developers mailto:ghc-devs@haskell.org>>
Subject: Find constraints over type

Dear GHC devs,
I am trying to figure out a way to obtain the constraints that hold over a 
type. Let me give you an example: suppose that I write the following function:

f :: Eq a => [a] -> Bool
f xs = xs == []

If I ask for the type of the Var ' xs', I get back '[a]'. This is correct, but 
I am missing the crucial information that '[a]' must be Eq.

Is there an easy way to get it? It seems that 'varType' doesn't give me enough 
information.

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

RE: Windows testsuite failures

[Simon Peyton Jones via ghc-devs]

Both Tamar and Omer are right.


  *   Not doing CI on Windows is bad.   It means that bugs get introduced, and 
not discovered until later. This is Tamer’s point, and it is valid.
  *   Holding up MRs because a failures in Windows CI that is unrelated to the 
MR is also bad. It a frustrating waste of time, and discourages all authors.  
(In contrast, holding up an MR because it introduces a bug on Windows is fine,  
indeed desirable.)   This is Omer’s point, and it is valid.

The obvious solution is: let’s fix Windows CI, so that it doesn’t fail except 
when the MR genuinely introduces a bug.

How hard would it be to do that?   Do we even know what the problem is?

Simon

From: ghc-devs  On Behalf Of Phyx
Sent: 17 January 2020 06:49
To: Ömer Sinan Ağacan 
Cc: ghc-devs 
Subject: Re: Windows testsuite failures

Oh I spent a non-insignificant amount of time back in the phabricator days to 
make the CI stable. Now because people were committing to master directly 
without going through CI it was always a cat and mouse game and I gave up 
eventually.

Now we have rewritten the CI and it's pointing out actual issues in the 
compiler. And your suggestion is well let's just ignore it.

How about you use some of that energy to help I stead of taking the easy way? 
And I bet you're going to say you don't care about Windows to which I would say 
I don't care about the non-threaded runtime and wish we would get rid of it. 
But can't always get what you want.

And to say we'll actually fix anything before release doesn't align with what 
I've seen so far, which had me scrambling last minute to ensure we can release 
Windows instead of making releases without it.

Quite frankly I don't need you to tell me to submit MRs to fix it since that's 
what I spent again a lot of time doing. Or maybe you would like to pay my 
paycheck so I can spend more than a considerable amount of my free time on it.

Kind regards,
Tamar

Sent from my Mobile

On Fri, Jan 17, 2020, 06:17 Ömer Sinan Ağacan 
mailto:omeraga...@gmail.com>> wrote:
We release more often than once in 6 months.

We clearly have no idea how to test on Windows. If you know how to do it then
feel free to submit a MR. Otherwise blocking every MR indefinitely is worse than
testing Windows less frequently.

Ömer

Phyx mailto:loneti...@gmail.com>>, 17 Oca 2020 Cum, 09:10 
tarihinde şunu yazdı:
>
> Sure because only testing once every 6 months is a very very good idea...
>
> Sent from my Mobile
>
> On Fri, Jan 17, 2020, 06:03 Ömer Sinan Ağacan 
> mailto:omeraga...@gmail.com>> wrote:
>>
>> Hi Ben,
>>
>> Can we please disable Windows CI? I've spent more time fighting the CI than
>> doing useful work this week, it's really frustrating.
>>
>> Since we have no idea how to fix it maybe we should test Windows only before 
>> a
>> release, manually (and use bisect in case of regressions).
>>
>> Ömer
>>
>> Ben Gamari mailto:b...@smart-cactus.org>>, 14 Oca 
>> 2020 Sal, 14:30 tarihinde şunu yazdı:
>> >
>> > Hi all,
>> >
>> > Currently Windows CI is a bit flaky due to some unfortunately rather 
>> > elusive testsuite driver bugs. Progress in resolving this has been a bit 
>> > slow due to travel over the last week but I will be back home tomorrow and 
>> > should be able to resolve the issue soon thereafter.
>> >
>> > 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Find constraints over type

[Alejandro Serrano Mena]

My goal is to add type information on hover within `ghcide`. Right now,
when you select a variable, we give back the type as reported in the
corresponding Var. However, when this type involved a type variable, it
misses a lot of important information about the typing context in which we
are working. So the goal is to report back some of this typing context.

Going back to my original example:

f :: Eq a => [a] -> Bool
f xs = xs == []

It would be great if by hovering over the 'xs', one would get '[a] where Eq
a', or some other representation of the known constraints.

Since this is intended to be a help for the programmer, it doesn't really
matter whether we get "too many" constraints (for example, if we had "Ord
a" it's OK to get "Eq a" too, since that's interesting constraint
information).

Right now I am working with TypecheckModules most of the time.

Regards,
Alejandro

El jue., 16 ene. 2020 a las 19:47, Simon Peyton Jones (<
simo...@microsoft.com>) escribió:

> There is definitely no pure way to get from ‘a’ to its constraints.
>
>- It is far from clear what “its constraints” are.   Is (C a b) such a
>constraint?  C [a] b?  What about superclasses?
>- Constraints vary depending on where  you are.  GADT matches can
>bring into scope extra constraints on existing type variables.
>
>
>
> So as Ben says, to give a sensible response you’ll need to explain more
> about your goal
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Alejandro
> Serrano Mena
> *Sent:* 16 January 2020 16:19
> *To:* GHC developers 
> *Subject:* Find constraints over type
>
>
>
> Dear GHC devs,
>
> I am trying to figure out a way to obtain the constraints that hold over a
> type. Let me give you an example: suppose that I write the following
> function:
>
>
>
> f :: Eq a => [a] -> Bool
>
> f xs = xs == []
>
>
>
> If I ask for the type of the Var ' xs', I get back '[a]'. This is correct,
> but I am missing the crucial information that '[a]' must be Eq.
>
>
>
> Is there an easy way to get it? It seems that 'varType' doesn't give me
> enough information.
>
>
>
> Regards,
>
> Alejandro
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs